Chapter 6

“Databases reside at the heart of most software applications” (SD Chapter 6, pg 168). This week’s readings cover Chapter 6 of our textbook, Client-Centered Software Development. Whereas Chapter 5 focuses on domain classes, Chapter 6 focuses on databases, making a distinction between the two structures. A database is comparable to a domain class but holds data in permanent storage rather than program memory.

Software applications utilize databases to carry information about their users and history. I have gotten some first-hand experience with databases as they relate to applications through work. A live SQL database powers the application and the information displayed on all of its pages. It’s clear to me in that case that the application simply wouldn’t run without the database. We also use queries for operations projects. The chapter describes a query as a manipulation of a database that retrieves data meeting specific criteria.

Of course, in order to get such a large database as certain software companies have, programs within the application must add data. One topic the chapter discusses that I was unfamiliar with is “collision”. In a client-server application, it’s possible for multiple clients to access the same database table at one time. Different types of databases have different concurrency control mechanisms. When multiple sessions are involved, databases may implement access control strategies such as table or row-level locking. These will, respectively, lock the table or row for writing for all other sessions when a session is already writing to that part of the database. To support this, sessions should only be connected when they are actively querying. Queries should run in a reasonable amount of time.

Databases contain the most sensitive information about the application and its users. Naturally, then, the usage of a database to power software introduces many new vulnerabilities. The chapter describes a secure database as one that presents valid information and prevents unauthorized read or write access. Achieving this goal involves, among several strategies, proper encryption of data and assignment of appropriate users privileges. Users can be assigned read or write privileges at several different levels such as server, database, table, and column. I would imagine that leadership at software companies has to make extremely careful decisions about how to assign these privileges. For example, read privileges may be unnecessary for most developers and also happen to pose the most risk for a confidentiality breach. If too many developers have read access, it may become difficult to trace malicious acts to the perpetrator. However, developers need write access to perform data cleanup.

We take a look at database testing at the end of this chapter. As such a crucial part of the application, the database naturally must be included in the testing framework. I had not considered the importance of restoring the database to its original state after running tests. Of course, cases that test even simple CRUD (create, read, update, delete) will have to alter the database. Hence, it must involve a three-step setup, testing, and teardown process that ensures this. Finally, the layering principle caries into database design. This says that all queries in the software “that affect the database should originate from one of the modules”. This encourages developers to complete modules so they won’t be tempted to query the table from anywhere in the code but the related module.

Overall, it was super interesting to read about how databases and software mix while working with open source software for this class and within a software company that runs on a SQL database! I look forward to looking for applications of these principles within my work in both areas.

• 2021 11
• 2020 22