Journal of Technology Research Volume 6 – December, 2014
Doing database design, page 3
The forward-engineering case presented below (Case 1) is destined to provide the
students with a good-practice instruction set that is expected to help particularly with the
transformation of the problem definition into a logical data model and into the physical database.
The reverse-engineering case (Case 2) serves as an example of documenting an existing
physical database by means of its Entity Relationship Diagram (ERD).
DATABASE DESIGN BRIEF
It is not uncommon to interpret the database design process as logical rather than physical
design (Date 2009, p. 285). The physical design is concerned more with how logical designs are
mapped into physical databases. Case 1 shows how to implement such mapping using MySQL
Workbench. Some database professionals consider logical design more of an art than a science.
Nonetheless, there are general guidelines that are helpful in structuring logical data models.
As mentioned, a logical data model is expected to capture entity types, attributes,
relationships, and constraints. According to (Elmasri, at al., 2004, p. 53) “The basic object of the
ER model represents an entity, which is a “thing” in the real world with an independent
existence.” At this point, it is important to distinguish between entity type and entity, since in
many situations these terms are used interchangeably. The notion of the entity type is similar to
the notion of class, used in object-oriented design. An entity type is a collection of entities
(entity instances) much like a class is a collection of objects (class instances). Going forward, in
a physical database, entity types become tables and entity instances—records (or table rows).
Typical examples of entity types are: Person, Student, Company, Department, Product, Location,
Tournament, etc. Identification of the entities is considered to be the first task in developing a
logical data model. In what follows, term “entity” is used wherever it can unambiguously
represent an “entity type”.
Descriptive properties of an entity are referred to as attributes (Elmasri, at al., 2004, p.
54). They represent relevant characteristics of entities (within the same entity type) that are
expected to persist in a data store (database). Each attribute has its own type (a domain of values
it can take on). For example, an age of a person comes from the set of integers (if the age is to be
expressed in whole years); a student standing is one element of the set of text tokens (strings)
{‘Freshman’,’Sophomore’,’Junior’,’Senior’}; a product price is a non-negative real number; etc.
Ideally, a logical data model should provide all relevant attributes of the entity types (already
identified). A high-level design (data model) may not show all the required attributes but it
should include at least the so called keys. A key of an entity type is a subset of its attributes that
uniquely identifies each of its instances. An entity may have more than one key. The key that is
chosen to formally represent unique entity instances is referred to the primary key. For example,
in a college database system, social security numbers or other natural unique identifiers (e.g.
passport number) are used to uniquely identify each student. However, because of privacy and/or
security restrictions, the system generates [artificial] keys that are uniquely mapped into the
natural keys. Such keys are referred to a surrogate keys and they are used in daily operations as
primary keys.
Probably the most interesting pieces of the logical data model are relationships. As
defined in (Elmasri, at al., 2004, p. 61) ,“A relationship type R among entities E
1
, E
2
, …, E
n
defines a set of associations—or a relationship set—among entities from these entity types.” It is
important to note that, while relationship types are defined among entity types, actual
relationship happen among entity instances.