1. Chapter 14 Semantic Modeling

2. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-2 Topics in this Chapter The Overall Approach The E/R Model E/R Diagrams Database Design with the E/R Model A Brief Analysis

3. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-3 Semantic Modeling Semantic modeling is ever evolving toward greater ability to represent formally the meaning of data User defined types are more robust than scalar types in representing meaning Domains, candidate keys, and foreign keys are all elements of formal semantic modeling The available DBMSs are weak in implementing a robust semantic model

4. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-4 An Approach to Semantic Modeling The world is made up of entities Entities can be classified into entity types Entities of a given type will have certain properties in common Every entity has an identity Entities relate to each other via relationships

5. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-5 Semantic Modeling In the model, entities and their relationships are represented by symbolic objects We can define integrity rules, or metaconstraints to apply to these objects We need a set of operators to manipulate them In addition to entities, properties, and relationships, it is useful to allow subtypes We will need to map the terms of the semantic model to those used so far in developing the relational model

6. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-6 The E/R Model The E/R model, introduced by Chen, includes a diagramming technique An entity can be represented by a rectangle Weak entities are existence-dependent on some other entity; regular entities are independent A property may be simple or composite, key or nonkey, single or multi-valued, populated or missing, base or derived

7. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-7 Relationships A relationship is an association among entities The entities are participants in the relationship The number of participants is the degree Participation may be total or parital A relationship may be one-to-one, one-to- many, or many-to-many

8. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-8 Entity Subtypes and Supertypes An entity may be of one or more types Ex.: an entity may be a programmer as well as an employee Properties may be inherited by the subtype from the supertype The result is an entity type hierarchy Dissimilar from a traditional hierarchy, e.g. IMS: not that an employee (parent) has one or more programmers (children), but an employee can be zero or one programmer

9. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-9 E/R Diagrams An entity is represented by a rectangle; if it is weak, the border of the rectangle is doubled A property is represented by an ellipse connected by a solid line to the entity If the property is derived, the ellipse border is dotted or dashed If the property is multi-valued, the ellipse border is doubled

10. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-10 E/R Diagrams – Relationships A relationship type is represented as a diamond containing its name; participants are connected to the relationship by a solid line If the relationship type connects a weak entity type to one on which its existence depends, the diamond border is doubled Each participant is connected by a solid line labeled “1” or “M” The line is doubled if participation is total

11. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-11 Diagramming Entity Subtypes and Supertypes If entity type Y is a subtype of X, then draw a solid line from the X rectangle to the Y rectangle, marked with an arrowhead at the Y end Denotes an “isa” relationship Every Y “isa” X The set of all Ys is a subset of the set of all Xs Programmer is a subtype of employee

12. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-12 Database Design with the E/R Model Draw the entities and their relationships Many-to-many relationships will be implemented with a base relvar The primary key of the relationship relvar may be a composite of the primary keys of each of the participants, or else a surrogate Each of the primary keys of the participants will be a foreign key in the relationship relvar

13. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-13 Database Design with the E/R Model – Continued Many-to-one relationships are implemented via a foreign key on the many side of the relationship that references the one side Weak entity types require CASCADE when the entity types on which they depend are deleted or updated Properties are not attributes per se, but in translating from the E/R model to the relational model, they may map to attributes

14. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-14 Database Design with the E/R Model – Entity Subtypes and Supertypes The subtype maps into a separate base relvar from the supertype, but they share the same primary key, which is also a foreign key in the subtype We need a view to join the supertype and subtype We can then access the the properties of each base relvar, or the view, as needed We can insert a new programmer into the view, and it will handle inserting an employee

15. Copyright © 2004 Pearson Addison-Wesley. All rights reserved.14-15 The E/R Model The relational model is a formal system; the E/R model is informal The E/R model addresses only the semantic concepts; it (so far) ignores devising formal objects, integrity rules, and operators It is useful but not sufficient to employ the E/R model in database design Relationships are no more than a special kind of entity; Mr. Date believes the E/R model fails to recognize this