1 / 30

Chapter 4 Extended Entity-Relationship (EER)Model

Chapter 4 Extended Entity-Relationship (EER)Model. Incorporates Set-subset Relationships Incorporates Generalization Hierarchies Constraints: Coverage Constraints: partial vs. total Disjointedness Constraint: disjoint vs. overlapping. Limitations of ER Models.

huy
Télécharger la présentation

Chapter 4 Extended Entity-Relationship (EER)Model

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. Chapter 4Extended Entity-Relationship (EER)Model • Incorporates Set-subset Relationships • Incorporates Generalization Hierarchies • Constraints: • Coverage Constraints: partial vs. total • Disjointedness Constraint: disjoint vs. overlapping

  2. Limitations of ER Models • ER model is sufficient for representing many database schema for traditional database applications. • Since 1970s, many newer applications of database technology have become commonplace. (CAD/CAM, GIS, ETC). • Representing database schema for these applications is more complex and requires additional semantic data modeling.

  3. Limitations of ER Models(continued) • No relationship may be defined between an entity type and a relationship type • No relationship may be defined between an entity type and a collection of entity types from which any one type may participate (e.g. Entity type1 : POLICY-HOLDER may be an individual, multiple individuals , one organization, or many organizations Entity type2 : POLICY ) • No constraints (exclusion, co-existence etc. ) among relationship types. (NIAM model, UML class diagrams allow them).

  4. Some attributes and relationship belong to a subset of an entity type Three Specializations

  5. The subclasses are subsets of the superclass

  6. This is partial participation

  7. This is a total participation

  8. This indicates an engineering manager must be engineer

  9. Generalization is reverse of specialization A generalization A catrgory U

  10. Conceptual Object Modeling Using UML Class Diagrams • There is some similarities between UML and EER model. • class diagrams are similar to EER diagrams in many ways. • Unfortunately, the terminology often differs. • We briefly review some of the notation, terminology, and concepts used in UML class diagrams, and compare them with EER terminology and notation. • Figure 4.11 (UML) VS Figure 3.15 (EER). • The entity types in EER are modeled as classes in UML. • An entity in ER/EER corresponds to an object in UML.

  11. In UML class diagrams, a class is displayed as a box that includes three sections: • the top section gives the class name. • the middle section includes the attributes for individual objects of the class. • the last section includes operations that can be applied to these objects. • Operations are not specified in EER diagrams. • A composite attribute is modeled as a structured domain.

  12. continued • A multivalued attribute will generally be modeled as a separate class, as illustrated by the LOCATION class. • Relationship types are called associations in UML terminology. • relationship instances are called links. • A binary association (binary relationship type) is represented as a line connecting the participating classes (entity types). • An association may (optional) have aname. • A relationship attribute, called a link attribute, is placed in a box that is connected to the association's line by a dashed line. • The (min, max) notation described in Section 3.7.4 is used to specify relationship constraints, which are called multiplicities in UML.

  13. continued • Multiplicities are specified in the form min.. max, and an asterisk (*) indicates no maximum limit on participation. • The multiplicities are placed on the opposite ends of the relationship when compared to the notation discussed in EER. • In UML, a single asterisk indicates a multiplicity of 0..*, and a single 1 indicates a multiplicity of 1..1. • A recursive relationship is called a reflexive association in UML, and the role names-like the multiplicities-are placed at the opposite ends of an association when compared to the placing of role names EER. • In UML, there are two types of relationships: • association and aggregation. • Aggregation is meant to represent a relationship between a whole object and its component parts, and has a distinct diagrammatic notation.

  14. The association between the locations of a department and the single location of a project is shown as aggregations. • In the EER model, both are represented as relationship. • UML also distinguishes between unidirectional associations/aggregations-which displayed with an arrow to indicate that only one direction for accessing related objects is needed • and bi-directional associations/aggregations-which are the default. • Relationship (association) names are optional in UML, • The relationship attributes are displayed in a box attached with a dashed line to the line representing the association/aggregation.

  15. Weak entities can be modeled using the construct called qualified association (or qualified aggregation) in UML this can represent both the identifying relationship and the partial key, which is placed in a box attached to the owner class. • Week entity is illustrated by the DEPENDENT class and its qualified aggregation to EMPLOYEE. • A blank trian- gle indicates a disjoint specialization/generalization, and a filled triangle indicates overlapping.

  16. 7. Mapping ER and EER Schemas into the Relational Model • Steps Of The Algorithm • (Chapter 9 – pages 290 to 296, Elmasri/Navathe ed. 3) • STEP 1: Map Entity Types • STEP 2: Map Weak Entity Types – draw identifier from parent entity type into weak entity type • Map Relationship Types (STEPS 3 – 5): • 1:1 - options for setting up one, two or three relations • 1:N – the many side provides a key to the one side, no new relation • M:N – need to set up a separate relation for the relationship • STEP 6: Map multivalued attributes – set up a new relation for each multi-valued attribute • STEP 7: Map higher order relationships (ternary, 4-way, etc.) – each higher order relationship become separate relations. • STEP 8: Mapping of generalization hierarchies and set-subset relationships – possiblity of collapsing into one relation vs. as many relations as the number of distinct classes.

More Related