Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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