--The Entity Relationship Model(4)--1 Outline  ER model  Overview  Entity types Attributes, keys  Relationship types  Weak entity types  uses Integration DEFinition for Information Modeling (IDEF1X) notation in ERwin  EER model  Subclasses  Specialization/Generalization  Schema Design  Single DB  View integration in IS

--The Entity Relationship Model(4)--2 Subclasses And Superclasses  Grouping of the entities of an entity type into subgroups (forming an "IS-A" relationship).  Entities in a superclass are grouped into one or more subclasses.  An arbitrary number of levels is permitted in a class hierarchy.  An entity in a subclass exists in the superclass also (recursively).

--The Entity Relationship Model(4)--3 Subclasses/Superclasses Example  The Customer entity type has the subclasses PreferredCustomer and Employee.  All employees are customers. Customer O Employee Preferred Customer

--The Entity Relationship Model(4)--4 Inheritance Among Classes  Entities in a subclass inherit the attributes of the superclass.  A subclass may have its own attributes (termed the specific attributes).  Entities in a subclass may participate in relationships directly (termed specific relationships), and they may participate in relationships via their superclass(es).

5 Inheritance Example  A PreferredCustomer entity inherits the attributes Name, Address, CutomerID and Balance from Customer.  The PreferredCustomer subclass also has the attribute DiscountLevel. Customer O Employee Preferred Customer CustomerID Address Name Balance EmployeeIDDiscount Level

--The Entity Relationship Model(4)--6 Abstraction  Specialization and generalization are reverse processes of abstraction.  Specialization - process of defining a set of subclasses of an entity type.  Generalization - process of forming a single superclass for a set of entity types.  When to abstract  Attribute(s) relevant only to a subclass  Relationship type(s) relevant only to a subclass

--The Entity Relationship Model(4)--7 Specialization The specialization process allows us to do following  Define a set of subclasses of an entity type.  Establish additional specific attributes with each subclass.  Establish additional specific relationship types between each subclass and other entity type or other subclasses.

--The Entity Relationship Model(4)--8 Abstraction Example - Subclass Rel. Type  Entities in the subclass Employee participate in the Supervises relationship.  PreferredCustomer entities do not participate in this relationship. Customer O Employee Preferred Customer Super- vises Supervisee (1,1) Manager (0,5)

--The Entity Relationship Model(4)--9 A Example of Specialization

--The Entity Relationship Model(4)--10 A Example of Specialization

--The Entity Relationship Model(4)--11 Generalization A REVERSE PROCESS abstraction  Suppress the differences among several entity types, identify their common features.  Generalize them into a single superclass of which the original entity types are special subclasses.

--The Entity Relationship Model(4)--12 An Example of Generalization

--The Entity Relationship Model(4)--13 An Example of Generalization

--The Entity Relationship Model(4)--14 Constraints on Spec. and Gen.  When subclass membership is user-defined, class membership is determined individually for each entity.  Subclass membership can be defined by a predicate (termed predicate-defined or condition-defined). Class membership is predefined.  Attribute-defined specialization

--The Entity Relationship Model(4)--15 Constraints Example  The Film class (with a Kind attribute) can be specialized into a Music Video (Kind = “M”), Educational Film (Kind = “E”) or Foreign film (Kind = “F”). Film d Foreign Film Educational Film Music Video Spoken Language Subtitle Language Recommended Age “F”“M”“E” Kind

16 Subclass Participation  Subclass groupings  disjoint - no entity can be in more than one subclass diamond notation - represent with a (d) crow’s feet notation - represent with an (x)  overlapping - entities may be in several subclasses diamond notation - represent with an (o) crow’s feet notation - default representation  Completeness of subclass  total - all entities in the superclass are in some subclass diamond notation - represent with a double line crow’s feet - ??  partial - an entity in a superclass need not be in a subclass diamond and crow’s feet notation - default representation  Example:  The specialization of the Film class into MusicVideo, EducationalFilm, and ForeignFilm subclasses is disjoint and partial.

--The Entity Relationship Model(4)--17 Update for Specialization and Generalization  Deletion cascades to subclasses.  If a Customer entity that is also an employee is deleted from the Customer class, it is also deleted from the Employee class.  Insertions are cascaded automatically to subclasses when entity membership is predicate-defined.  Example: The insertion of an entity with a Kind of “E” into the Film class will result in that entity being inserted into the EducationalFilm  For total specializations, entities are cascaded to at least one subclass.  Other rules may be derived.

--The Entity Relationship Model(4)--18 Outline  ER model  Overview  Entity types Attributes, keys  Relationship types  Weak entity types  uses Integration DEFinition for Information Modeling (IDEF1X) notation in ERwin  EER model  Subclasses  Specialization/Generalization  Schema Design  Single DB  View integration in IS

--The Entity Relationship Model(4)--19 Schema Design Strategies  Top-down strategy  Start out with high-level, abstract concepts and apply step-wise refinements (e.g., specialization) to add "detail."  Bottom-up strategy  Start out with basic concepts and apply refinements (e.g., generalization).  Inside-out strategy  Start with a few central concepts and successively include additional concepts.  Mixed strategy  Combine the above strategies.

--The Entity Relationship Model(4)--20 Top-down Strategy Customer Checked Out VideoTape Title RentalPrice (0,m) Length CustomerID Name (0,n) Customer Checked Out VideoTape Film Copies TapeNum Title RentalPrice (0,m) (0,n) (1,1) (0,n) FilmID Status Length CustomerID Name

--The Entity Relationship Model(4)--21 Bottom-up Strategy  Example: discovering a new generalized entity type and relating it. Customer Cust Checked Out VideoTape Title RentalPrice (0,m) Length CustomerID Name Emp Checked Out Employee Name EmployeeID Length (0,m) (0,n)

--The Entity Relationship Model(4)--22 Bottom-up Strategy, cont.  This is converted to: Customer Checked Out VideoTape Title RentalPrice (0,m) Length CustomerID Name (0,n) EmployeeID O Employee Preferred Customer

--The Entity Relationship Model(4)--23 Conceptual Database Design Approaches  Centralized design approach  Integrate first the requirements for all applications and then design a single schema.  Assumes a centralized organization.  The DBA merges the multiple sets of requirements.  The DBA designs the schema.  View integration approach  Design first a schema for each application in isolation, then integrate the schemas into a single global schema.  Each user group can design its own schema.  The DBA designs the global schema.

--The Entity Relationship Model(5)-- View Integration Example  View 1  View 2 MoviePerformer Stars In Role Stage Name Date Director (0,n)(0,m) Spoken Language Subtitle Language Name Film Foreign Film Educational Film Music Video Recommended Age O TitleFilmID RentalPriceDistributor Kind “F”“M”“E” Kind

--The Entity Relationship Model(4)--25 View Integration Example, cont.  View 1 is modified to better fit View 2 as shown below. FilmPerformer Stars In Role Stage Name Date Director (0,n)(0,m) Title FilmID Foreign Film d Spoken Language Subtitle Language

View Integration Example, cont.  The two views are then integrated as shown below. FilmPerformer Stars In Role Stage Name Date Director (0,n) (0,m) Title FilmID Spoken LanguageSubtitle Language Foreign Film Educational Film Music Video Recommended Age O RentalPriceDistributor “F”“M”“E” Kind

--The Entity Relationship Model(4)--27 View Integration Methodology  Identify correspondences and conflicts among views.  Naming conflicts (synonyms, homonyms).  Type conflicts (e.g., entity vs. attribute vs. relationship).  Domain conflicts (e.g., integer vs. string).  Constraint conflicts.  Homogenize views.  Resolve (some) conflicts.  Merge views.  Create the global schema.  Restructure the global schema.  Remove redundancy and unnecessary complexity.  Different integration orders are possible using binary and n-ary integration.