1 / 36

Database Systems: Design, Implementation, and Management Tenth Edition

Database Systems: Design, Implementation, and Management Tenth Edition. Chapter 5 Advanced Data Modeling. The Extended Entity Relationship Model. Result of adding more semantic constructs to original entity relationship (ER) model Diagram using this model is called an EER diagram (EERD).

areagan
Télécharger la présentation

Database Systems: Design, Implementation, and Management Tenth Edition

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Database Systems: Design, Implementation, and ManagementTenth Edition Chapter 5 Advanced Data Modeling

  2. The Extended Entity Relationship Model • Result of adding more semantic constructs to original entity relationship (ER) model • Diagram using this model is called an EER diagram (EERD) Database Systems, 10th Edition

  3. Entity Supertypes and Subtypes • Entity supertype • Generic entity type related to one or more entity subtypes • Contains common characteristics • Entity subtype • Contains unique characteristics of each entity subtype Database Systems, 10th Edition

  4. Database Systems, 10th Edition

  5. Specialization Hierarchy • Depicts arrangement of higher-level entity supertypes and lower-level entity subtypes • Relationships described in terms of “IS-A” relationships • Every subtype has only one supertype to which it is directly related • Can have many levels of supertype/subtype relationships Database Systems, 10th Edition

  6. Database Systems, 10th Edition

  7. Inheritance • Enables entity subtype to inherit attributes and relationships of supertype • All entity subtypes inherit their primary key attribute from their supertype • At implementation level, supertype and its subtype(s) maintain a 1:1 relationship • Lower-level subtypes inherit all attributes and relationships from all upper-level supertypes Database Systems, 10th Edition

  8. Database Systems, 10th Edition

  9. Subtype Discriminator • Attribute in supertype entity • Determines to which entity subtype each supertype occurrence is related • Default comparison condition for subtype discriminator attribute is equality comparison • Subtype discriminator may be based on other comparison condition Database Systems, 10th Edition

  10. Disjoint and Overlapping Constraints • Disjoint subtypes • Also called nonoverlapping subtypes • Subtypes that contain unique subset of supertype entity set • Overlapping subtypes • Subtypes that contain nonunique subsets of supertype entity set Database Systems, 10th Edition

  11. Database Systems, 10th Edition

  12. Database Systems, 10th Edition

  13. Completeness Constraint • Specifies whether entity supertype occurrence must be a member of at least one subtype • Partial completeness • Symbolized by a circle over a single line • Some supertype occurrences are not members of any subtype • Total completeness • Symbolized by a circle over a double line • Every supertype occurrence must be member of at least one subtype Database Systems, 10th Edition

  14. Database Systems, 10th Edition

  15. Specialization and Generalization • You can use various approaches to develop entity supertypes and subtypes. • Specialization • Identifies more specific entity subtypes from higher-level entity supertype • Top-down process • Based on grouping unique characteristics and relationships of the subtypes Database Systems, 10th Edition

  16. Specialization and Generalization(cont’d.) • Generalization • Identifies more generic entity supertype from lower-level entity subtypes • Bottom-up process • Based on grouping common characteristics and relationships of the subtypes Database Systems, 10th Edition

  17. Entity Clustering • “Virtual” entity type used to represent multiple entities and relationships in ERD • Considered “virtual” or “abstract” because it is not actually an entity in final ERD • Temporary entity used to represent multiple entities and relationships Database Systems, 10th Edition

  18. Database Systems, 10th Edition

  19. Entity Integrity: Selecting Primary Keys • Primary key is the most important characteristic of an entity • Single attribute or some combination of attributes • Primary key’s function is to guarantee entity integrity • Primary keys and foreign keys work together to implement relationships • Properly selecting primary key has direct bearing on efficiency and effectiveness Database Systems, 10th Edition

  20. Natural Keys and Primary Keys • Natural key is a real-world identifier used to uniquely identify real-world objects • Familiar to end users and forms part of their day-to-day business vocabulary • For example, you use class numbers to register for classes, invoice numbers to identify specific invoices, account numbers to identify credit cards, and so on. • Generally, data modeler uses natural identifier as primary key of entity being modeled Database Systems, 10th Edition

  21. Database Systems, 10th Edition

  22. When To Use Surrogate Primary Keys • Especially helpful when there is: • No natural key • Selected candidate key has embedded semantic contents • Selected candidate key is too long or cumbersome Database Systems, 10th Edition

  23. When To Use Surrogate Primary Keys (cont’d.) • If you use surrogate key: • The surrogate key has no meaning in the user’s environment - it exists only to distinguish one entity instance from another. • Use “unique index” and “not null” constraints Database Systems, 10th Edition

  24. Given the data shown in Table 5.4, you would model the EVENT entity as: EVENT (DATE, TIME_START, TIME_END, ROOM, EVENT_NAME, PARTY_OF) What primary key would you suggest? In this case, there is no simple natural key that could be used as a primary keyin the model. You might suggest one of these options: Database Systems, 10th Edition

  25. Design Cases: Learning Flexible Database Design • Data modeling and design requires skills acquired through experience • Experience acquired through practice • Four special design cases that highlight: • Importance of flexible design • Proper identification of primary keys • Placement of foreign keys Database Systems, 10th Edition

  26. Design Case 1: Implementing 1:1 Relationships • Foreign keys work with primary keys to properly implement relationships in relational model • Put primary key of the “one” side on the “many” side as foreign key • Primary key: parent entity • Foreign key: dependent entity Database Systems, 10th Edition

  27. Database Systems, 10th Edition

  28. Database Systems, 10th Edition

  29. Design Case 2: Maintaining History of Time-Variant Data • Normally, existing attribute values are replaced with new value without regard to previous value • Time-variant data: • Values change over time • Must keep a history of data changes • Keeping history of time-variant data equivalent to having a multivalued attribute in your entity • Must create new entity in 1:M relationships with original entity • New entity contains new value, date of change Database Systems, 10th Edition

  30. Database Systems, 10th Edition

  31. Database Systems, 10th Edition

  32. Design Case 3: Fan Traps • Design trap occurs when relationship is improperly or incompletely identified • Represented in a way not consistent with the real world • Most common design trap is known as fan trap • Fan trap occurs when one entity is in two 1:M relationships to other entities • Produces an association among other entities not expressed in the model Database Systems, 10th Edition

  33. For example, assume the JCB basketball league has many divisions. Each division has many players, and each division has many teams. Given those incomplete・business rules, you might create an ERD that looks like the one in Figure 5.11.Although that representation is semantically correct, the relationships are not properly identified. For example, thereis no way to identify which players belong to which team. Figure 5.11 also shows a sample instance relationship Database Systems, 10th Edition

  34. Given the design in Figure 5.12, note how easy it is to see which players play for which team. To find outwhich players play in which division, you first need to see what teams belong to each division; then you need to findout which players play on each team. There is a transitive relationship between DIVISION and PLAYER via the TEAM entity. Database Systems, 10th Edition

  35. Design Case 4: Redundant Relationships • Redundancy is seldom a good thing in database environment • Occurs when there are multiple relationship paths between related entities • Main concern is that redundant relationships remain consistent across model • Some designs use redundant relationships to simplify the design Database Systems, 10th Edition

  36. In Figure 5.13, note the transitive 1:M relationship between DIVISION and PLAYER through the TEAM entity set.Therefore, the relationship that connects DIVISION and PLAYER is, for all practical purposes, redundant. In that case,the relationship could be safely deleted without losing any information-generation capabilities in the model. Database Systems, 10th Edition

More Related