Database Reference
In-Depth Information
Although the model can and likely will evolve over time, maintaining it in a diagram format or similar way is
important to ensure an efficient and cohesive design. It could be argued that for some applications either the domain
is limited enough or the objects representing the model are so well defined and documented that a model diagram is
unnecessary. In addition, it has been suggested that the time involved to create a model diagram can slow down the
development process.
However, most applications that start small will grow over time and the object code will—at some point—probably
be passed from the initial developers to a new set of developers. Without a diagram to quickly demonstrate all of the
data points represented within an application, the time and effort involved to explain the model will likely grow as
well as make it much more difficult to most efficiently add, update, or remove specific pieces of the model.
Data Model Components
The data model is developed in the first stage of the project and will evolve over time. Even as relational databases
have changed over the past forty years, they have retained certain design limitations, which, in turn, makes the initial
data modeling task a critical path within the scope of an application development project. Although NoSQL options
have helped the outcome of projects by lowering the risk of modifications to the model, the task of modeling is still
critical to successful application development.
In the data modeling stage, whether with an agile focus or otherwise, the project team, specifically analysts and
developers, will usually begin by having discussions with the application owners to understand the requirements
of the model. These discussions should yield at least one important result, which is an entity-relationship (ER)
diagram. The ER diagram is an important resource for an application project team because it provides a common
understanding of how the application's data will be represented.
Entity-Relationship Model
Although many variants of the theme existed prior to it, the entity-relationship model is credited to Peter Chen in his
1976 paper, “The Entity-Relationship Model: Toward a Unified View of Data.” 1 Chen's original description and design
was adapted to more common usage today for data analysts and administrators. The ER model is specifically useful
because of how well it maps to the structure of a relational model.
In addition, the ER model is fairly simple to create and can be understood by all members of the team and wider
organization with minimal instruction as well as act as the instructions to one or more team members on how to
specifically construct the database as it applies to the platform in use. Perhaps the most important aspect of the ER
model is that it acts as a universal way to communicate. Without its ubiquity, the method and manner of describing
and visualizing data models could vary from project to project.
Entities
Entities are characteristically viewed as the central objects within the ER model. Most often data modelers will
strive to use terms that are easily recognizable to each member of the project team in order to describe the entity.
Conversely, you should stay away from terminology that is not commonly used or not the default within the domain
or industry. For example, when modeling applications that deal with constructing residential areas, it would be more
common to use the word “house” rather than “abode”—even though they are synonyms.
We can see in Figure 3-1 that the model diagram employs the use of a box—a standard shape to symbolize
entities. In some model diagrams, the entities—as well as the relationships and attributes—will be shown in specific
colors to further visually distinguish each part of the model.
1 Peter Chen, “The Entity-Relationship Model: Toward a Unified View of Data,” September 22-24, 1975, ACM Transactions on
Database Systems, Vol. 1, No. 1 (March 1976), pp. 9-36.
 
Search WWH ::




Custom Search