Database design, application development, and administration

The next book in my journey to understand database design is Database design, application development, and administration by Michael Mannino.

This is an university text-book. My main concern is to learn about logical database modelling. Fortunately, this book has a chapter on a design of a database.

Mannino (2004, 4) lists three (3) characteristics of a database:

  1. Persistent
  2. Shared
  3. Interrelated

The last one is interesting because of the following snippet in its description:

Databases contain both entities and relationships among entities. An entity is a cluster of data about a single topic that can be accessed together. (Mannino 2004, 5)

This gives a direction about how to approach database design. It is about finding and describing entities and a web of relationships between them. And, of course, the author uses Entity-Relationship Diagrams (ERD).

Based on Middleton (2002, 39), I see the discovery, assimilation, and understanding of relationships among the items of information in the logical database design process as the creation of knowledge.

Similar to Middleton (2002, 151), Mannino (2004, 16-17) puts forward a Three Schema Architecture which comprises of the following levels:

  1. Internal (or machine-storage view)
  2. External (or various user views of the data)
  3. Conceptual (which “defines the entities and relationships”)

The difference between Middleton and Mannino is in the conceptual level. Middleton (2002, 151) stresses the reconciliation between the various user views, while Mannino (2004, 16) stresses the emergence of entities and relationships. Can the emergence of knowledge can come from one or both of these ways? This would be an interesting direction of research to pursue.

Figure 4.1: Overview of student loan processing system

Mannino (2004, 124) puts forward a conceptual model of the student loan processing system in Figure 4.1. The interesting point about this model is the flow of information from the environment, its transformation by the application processes before flowing back into the environment. The database is seen as a store for the application processes.

This processing of information is the application of knowledge. The information is selected upon the current knowledge of the enterprise, and is transformed to conform to the existing world-view of the enterprise. This leads to another interesting question: what to do about information that does not conform to the world-view? How does a logical database design accomodate information that does not fit?

In the development process, Mannino (2004, 127) contends that:

Even though models of data, processes, and environment interactions are necessary to develop an information system, this book emphasizes data models only. In many information systems development efforts, the data model is the most important.

The goals of database development (Mannino 2004, 127-129) are listed as:

  1. Develop a Common Vocabulary
  2. Define the Meaning of Data
  3. Ensure Data Quality
  4. Find an Efficient Implementation

Data quality (Mannino 2004, 128) has the following characteristics:

Characteristic Meaning
Completeness Database represents all important parts of the information system
Lack of ambiguity Each part of the database has only one meaning
Correctness Database contains values perceived by the user
Timeliness Business changes are posted to the database without excessive delays
Reliability Failures or interference do not corrupt database
Consistency Different parts of the database do not conflict

Mannino (2004, 129-130) separates Conceptual Data Modelling from the Logical Database Design. The latter is complete when the relational database tables are produced in “format understandable by a commercial DBMS” (Mannino 2004, 130). I was of the opinion that this was part of the physical design. The Conceptual Data Modelling is complete when the ERD is produced (Mannino 2004, 130).

For large projects, Mannino (2004, 132-133) suggests that the whole be divided up into views for each user. These views are then integrated to resolve conflicts.

This methodology is explained further in Chapter 12. Mannino (2004, 441-452) uses the analysis of forms to determine user views. One could use a prototype to gather requirements through the use of forms. ERD diagrams are then generated for each of these views. The difficult part is to integrate these views into a consistent whole. A precedence relationship among the forms (Mannino 2004, 454-455) is really a workflow ordering of forms.

This reliance on the flow of work is made explicit in Chapter 13 (Database Development for Student Loan, Limited). We are really looking at a data flow diagram (DFD) on p. 465. In essence, we start with the flow of data. A form is then a snapshot of that flow at a particular point and at a particular time.

I think reading Mannino (2004) has opened up the idea of logical database design being about the flow of data through a system. An analogy would be that of a water-mill. A stream flows by and only part of the stream is diverted to power the mill to provide useful work. A database traps part of the data flowing in the universe and converts it to useful work.

Going back to the three schema architecture described above (Mannino 2004, 16), I see the logical database design process as converting the external schema into the conceptual schema.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s