Download Database Design Using Entity

Database Design Using Entity-Relationship Diagrams
Sikha Bagui
Richard Earp
AUERBACH PUBLICATIONS
A CRC Press Company
Preface
Data modeling and database design have undergone significant evolution in recent years. Today, the
relational data model and the relational database system dominate business applications. The
relational model has allowed the database designer to focus on the logical and physical
characteristics of a database separately. This book concentrates on techniques for database design,
with a very strong bias for relational database systems, using the ER (Entity Relationships) approach
for conceptual modeling (solely a logical implementation).
Intended Audience
This book is intended to be used by database practitioners and students for data modeling. It is also
intended to be used as a supplemental text in database courses, systems analysis and design
courses, and other courses that design and implement databases. Many present-day database and
systems analysis and design books limit their coverage of data modeling. This book not only
increases the exposure to data modeling concepts, but also presents a detailed, step-by-step
approach to designing an ER diagram and developing the relational database from it.
Introduction
This book was written to aid students in database classes and to help database practitioners in
understanding how to arrive at a definite, clear database design using an entity relationship (ER)
diagram. In designing a database with an ER diagram, we recognize that this is but one way to arrive
at the objective —the database. There are other design methodologies that also produce databases,
but an ER diagram is the most common. The ER diagram (also calledan ERD) is a subset of what are
called "semantic models." As we proceed through this material, we will occasionally point out where
other models differ from the ER model.
The ER model is one of the best-known tools for logical database design. Within the database
community it is considered to be a very natural and easy-to-understand way of conceptualizing the
structure of a database. Claims that have been made for it include: (1) it is simple and easily
understood by nonspecialists; (2) it is easily conceptualized, the basic constructs (entities and
relationships) are highly intuitive and thus provide a very natural way of representing a user's
information requirements; and (3) it is a model that describes a world in terms of entities and
attributes that is most suitable for computer-naïve end users. In contrast, many educators have
reported that students in database courses have difficulty grasping the concepts of the ER approach
and, in particular, applying them to the real-world problems (Gold-stein and Storey, 1990).
We took the approach of starting with an entity, and then developing from it in an "inside-out strategy"
(as mentioned in Elmasri and Navathe, 2000). Software engineering involves eliciting from (perhaps)
"naïve" users what they would like to have stored in an information system. The process we
presented follows the software engineering paradigm of requirements/specifications, withthe ER
diagram being the core of the specification. Designing a software solution depends on correct
elicitation. In most software engineering paradigms, the process starts with a requirements elicitation,
followed by a specification and then a feedback loop. In plain English, the idea is (1) "tell me what you
want" (requirements), and then (2) "this is what I think you want" (specification). This process of
requirements/specification can (and probably should) be iterative so that users understand what they
will get from thesystem and analysts will understand what the users want.
A methodology for producing an ER diagram is presented. The process leads to an ER diagram that
is then translated into plain (but meant to be precise) English that a user can understand. The iterative
mechanism then takes over to arrive at a specification (a revised ER diagram and English) that both
users and analysts understand. The mapping of the ER diagram into arelational database is
presented; mapping to other logical database models is not covered. We feel that the relational
database is most appropriate to demonstrate mapping because it is the most-used contemporary
database model. Actually, the idea behind the ER diagram is to produce a high-level database model
that has no particular logical model implied (relational, hierarchical, object oriented, or network).
We have a strong bias toward the relational model. The "goodness" of the final relational model is test
able via the ideas of normal forms. The goodness of the relational model produced by a mapping from
an ER diagram theoretically should be guaranteed by the mapping process. If a diagram is "good
enough," then the mapping to a "good" relational model should happen almostautomatically. In
practice, the scenario will be to produce as good an ER diagram as possible, map it to a relational
model, and then shift the discussion to "is this a good relational model or not?" using the theory of
normal formsand other associated criteria of "relational goodness."
The approach to database design taken will be intuitive and informal.We do not deal with precise
definitions of set relations. We use the intuitive"one/many" for cardinality and "may/must" for
participation constraints. Theintent is to provide a mechanism to produce an ER diagram that can be
presented to a user in English, and to polish the diagram into a specificationthat can then be mapped
into a database. We then suggest testing the produced database by the theory of normal forms and
other criteria (i.e., referential integrity constraints). We also suggest a reverse-mapping paradigm for
mapping a relational database back to an ER diagram for the purpose of documentation.
The ER Models We Chose
We begin this venture into ER diagrams with a "Chen-like" model, and most of this book (Chapters 2
through 9) is written using the Chen-like model. Why did we choose this model? Chen (1976)
introduced the idea of ER diagrams (Elmasri and Navathe, 2000), and most database texts use some
variant of the Chen model. Chen and others have improved the ER process over the years; and while
there is no standard ER diagram (ERD) model, the Chen-like model and variants there of are
common, particularly in comprehensive database texts. Chapter 10 briefly introduces the
"Barker/Oracle-like" model. As with the Chen model, we do not follow the Barker or Oracle models
precisely, and hence we will use the term Barker/Oracle-like models in this text.
There are also other reasons for choosing the Chen-like model over the other models. With the Chenlike model, one need not consider how the database will be implemented. The Barker-like model is
more intimately tied to the relational database paradigm. Oracle Corporation uses an ERD that is
closer to the Barker model. Also, in the Barker-like and Oracle-like ERD, there is no accommodation
for some of the features we present in the Chen-like model. For example, multi-valued attributes and
weak entities are not part of the Barker or Oracle-like design process.
The process of database design follows the software engineering paradigm; and during the
requirements and specifications phase, sketches of ER diagrams will be made and remade. It is not at
all unusual to arrive at a design andthen revise it. In developing ER models, one needs to realize that
the Chen model is developed to be independent of implementation. The Chen-like model is used
almost exclusively by universities in database instruction. The mapping rules of the Chen model to a
relational database are relatively straight forward, but the model itself does not represent any
particular logical model. Although the Barker/Oracle-like model is quite popular, it is implementation
dependent upon knowledge of relational databases. The Barker/Oracle model maps directly to a
relational database; there are no real mapping rules for that model.
References
Elmasri, R. and Navathe, S.B., Fundamentals of Database Systems, 3rd ed., Addison-Wesley,
Reading, MA, 2000.
Goldstein, R.C. and Storey, V.C., "Some Findings on the Intuitiveness of Entity Relationship
Constructs," in Lochovsky, F.H., Ed., Entity-Relationship Approach to Database Design and Querying,
Elsevier Science, New York, 1990.
List of Examples
Chapter 1: The Software Engineering Process and Relational
Databases
Checkpoint 1.1
Checkpoint 1.2
Checkpoint 1.3
Checkpoint 1.4
Chapter 2: The Basic ER Diagram—A Data Modeling Schema
Checkpoint 2.1
Checkpoint 2.2
Checkpoint 2.3
Chapter 3: Beyond the First Entity Diagram
Checkpoint 3.1
Checkpoint 3.2
Chapter 4: Extending Relationships/Structural Constraints
Checkpoint 4.1
Checkpoint 4.2
Checkpoint 4.3
Checkpoint 4.4
Chapter 5: The Weak Entity
Checkpoint 5.1
Checkpoint 5.2
Checkpoint 5.3
Chapter 6: Further Extensions for ER Diagrams with Binary
Relationships
Checkpoint 6.1
Checkpoint 6.2
Checkpoint 6.3 (Optional)
Checkpoint 6.4
Chapter 7: Ternary and Higher-Order ER Diagrams
Checkpoint 7.1
Checkpoint 7.2
Checkpoint 7.3
Chapter 8: Generalizations and Specializations
Checkpoint 8.1
Checkpoint 8.2
Chapter 9: Relational Mapping and Reverse-Engineering ER Diagrams
Checkpoint 9.1
Checkpoint 9.2
Chapter 10: A Brief Overview of the Barker/Oracle-Like Model
Checkpoint 10.1
Checkpoint 10.2
Checkpoint 10.3
Checkpoint 10.4