Presentation is loading. Please wait.

Presentation is loading. Please wait.

IFSC 3320 Enhanced Entity-Relationship

Similar presentations


Presentation on theme: "IFSC 3320 Enhanced Entity-Relationship"— Presentation transcript:

1 IFSC 3320 Enhanced Entity-Relationship
CH 4. Enhanced Entity-Relationship

2 CH 4. Enhanced Entity-Relationship
IFSC 3320 Why EER The ER modeling concepts are not sufficient for representing new database applications, which have more complex requirements than do the more traditional applications. Additional semantic data modeling concepts must be used to represent these requirements as accurately and clearly as possible. CH 4. Enhanced Entity-Relationship

3 CH 4. Enhanced Entity-Relationship
IFSC 3320 EER EER model concepts includes All modeling concepts of basic ER Additional concepts: subclasses/superclasses specialization/generalization categories (UNION types) attribute and relationship inheritance These are fundamental to conceptual modeling The additional EER concepts are used to model applications more completely and more accurately EER includes some object-oriented concepts, such as inheritance CH 4. Enhanced Entity-Relationship

4 CH 4. Enhanced Entity-Relationship
IFSC 3320 EER Modeling Subclasses, Superclasses and Inheritance Specialization and Generalization Constraints and Characteristics of Specialization and Generalization Modeling of UNION Types Using Categories CH 4. Enhanced Entity-Relationship

5 Subclasses and Superclasses
IFSC 3320 Subclasses and Superclasses An entity type may have additional meaningful subgroupings of its entities SECRETARY ENGINEER EMPLOYEE Superclasses: EMPLOYEE Subclasses: SECRETARY, ENGINEER, TECHNICIAN, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE TECHNICIAN SALARIED_EMPLOYEE HOURLY_EMPLOYEE Every entity that is a member of one of these subgroupings is also an employee CH 4. Enhanced Entity-Relationship

6 CH 4. Enhanced Entity-Relationship
IFSC 3320 Example Lname SSN Addr Fname WORKS DEPARTMENT EMPLOYEE d d TypingSpeed TGrade EngType MANAGER HOURLY_EMP SECRETARY TECHNICIAN ENGINEER SALARIED_EMP MANAGES BELONGS_TO EMPLOYEE: WORKS SECRETARY: WORKS TECHNICIAN: WORKS ENGINEER: WORKS MANAGER: WORKS, MANAGES SALARIED_EMP: WORKS HOURLY_EMP: WORKS, BELONGS_TO PROJECT TRADE_UNION CH 4. Enhanced Entity-Relationship

7 Why class/subclass relationships and specializations
IFSC 3320 Why class/subclass relationships and specializations Certain attributes may apply to some but not all entities of the superclass. A subclass is defined in order to group the entities to which these attributes apply. The members of the subclass may still share the majority of their attributes with the other members of the superclass. EMPLOYEE (Name, SSN, BirthDate, Address) SECRETARY (Name, SSN, BirthDate, Address, TypingSpeed) ENGINEER (Name, SSN, BirthDate, Address, EngineerType) TECHNICIAN (Name, SSN, BirthDate, Address, TGrade) CH 4. Enhanced Entity-Relationship

8 Why need class/subclass relationships and specializations
IFSC 3320 Why need class/subclass relationships and specializations Some relationship types may be participated in only by entities that are members of the subclass. CH 4. Enhanced Entity-Relationship

9 Subclasses vs. Superclasses
IFSC 3320 Subclasses vs. Superclasses The set of entities in each subclasses is a subset of the entities that belong to EMPLOYEE Each is called a subclass of EMPLOYEE EMPLOYEE is the superclass for each of these subclasses The relationship between a superclass and any one of its subclass is called a superclass/subclass or class/subclass relationship. e.g., EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN are two class/subclass relationships. CH 4. Enhanced Entity-Relationship

10 Properties of Superclasses and Subclasses
IFSC 3320 Properties of Superclasses and Subclasses A member entity of the subclass represents the same real-world entity as some member of the superclass. The subclass member is the same as the entity in the superclass, but in a distinct specific role. When implementing a superclass/subclass relationship, a member of the subclass may be represented as a distinct database object – a distinct record that is related via the key attribute to its superclass entity. When implementing a superclass/subclass relationship, a member of the subclass may be represented as a distinct database object – a distinct record that is related via the key attribute to its superclass entity. CH 4. Enhanced Entity-Relationship

11 Properties of Superclasses and Subclasses (cont.)
IFSC 3320 Properties of Superclasses and Subclasses (cont.) An entity CANNOT exist in the DB merely by being a member of a subclass. It must also be a member of the superclass. An entity can be a member of more than one subclass. Example: A salaried employee who is also an engineer belongs to the two subclasses ENGINEER and SALARIED_EMPLOYEE It is not necessary that every entity in a superclass be a member of some subclass Example: A technical writer is an employee but does not belong to any subclasses. If John Doe is an engineer (subclass member) of a company, then he should also be an employee (superclass member) of the company. CH 4. Enhanced Entity-Relationship

12 CH 4. Enhanced Entity-Relationship
IFSC 3320 Type inheritance The type of an entity is defined by the attributes it possesses and the relationship types which it participates. An entity that is a member of a subclass inherits all the attributes of the entity as a member of the superclass, as well as all the relationships in which the superclass participates. CH 4. Enhanced Entity-Relationship

13 Example    EMPLOYEE SECRETARY ENGINEER TECHNICIAN Lname SSN Addr
IFSC 3320 Example Lname SSN Addr Fname EMPLOYEE Fname, Lname, SSN, Addr SECRETARY Fname, Lname, SSN, Addr TypingSpeed EMPLOYEE TECHNICIAN Fname, Lname, SSN, Addr, TGrade d ENGINEER Fname, Lname, SSN, Addr, EngType TypingSpeed EngType TGrade SECRETARY ENGINEER TECHNICIAN CH 4. Enhanced Entity-Relationship

14 CH 4. Enhanced Entity-Relationship
IFSC 3320 Example WORKS DEPARTMENT EMPLOYEE d d TypingSpeed MANAGER TGrade EngType HOURLY_EMP SECRETARY TECHNICIAN ENGINEER SALARIED_EMP MANAGES BELONGS_TO Entity Type: Relationship Type EMPLOYEE: WORKS SECRETARY: WORKS TECHNICIAN: WORKS ENGINEER: WORKS MANAGER: WORKS, MANAGES SALARIED_EMP: WORKS HOURLY_EMP: WORKS, BELONGS_TO PROJECT TRADE_UNION CH 4. Enhanced Entity-Relationship

15 CH 4. Enhanced Entity-Relationship
IFSC 3320 Specialization The process of defining a set of subclass of an entity type (the superclass of the specialization). The set of subclasses that form a specialization is defined on the basis of some distinguishing characteristics of the entities in the superclass. {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of EMPLOYEE based on the job type of each entity. CH 4. Enhanced Entity-Relationship

16 Specialization (cont.)
IFSC 3320 Specialization (cont.) The same entity type may have several specializations based on different distinguishing characteristics. The EMPLOYEE entity type may have two specializations: Based on the methods of pay: {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} Based on the type of job: {SECRETARY, ENGINEER, TECHNICIAN} A subclass can participate in specific relationship typ A superclass/subclass relationship may resemble a 1:1 relationship at the instance level. The main difference is that In a 1:1 relationship two distinct entities are related, In a superclass/subclass relationship the entity in the subclass is the same real-world entity as the entity in the supercalss but playing a specialized role. CH 4. Enhanced Entity-Relationship

17 Diagrammatically representation of specialization in an EER diagram
IFSC 3320 Diagrammatically representation of specialization in an EER diagram Esuper Specific attributes Specific attributes E2 E1 CH 4. Enhanced Entity-Relationship

18 CH 4. Enhanced Entity-Relationship
IFSC 3320 Example EMPLOYEE d d MANAGER HOURLY_EMP SECRETARY TECHNICIAN ENGINEER SALARIED_EMP MANAGES BELONGS_TO PROJECT TRADE_UNION CH 4. Enhanced Entity-Relationship

19 CH 4. Enhanced Entity-Relationship
IFSC 3320 Specialization The specialization process allows us to do the following: Define a set of subclass of an entity type Establish additional specific attributes with each subclass Establish additional specific relationship types between each subclass and other entity types or other subclasses CH 4. Enhanced Entity-Relationship

20 CH 4. Enhanced Entity-Relationship
IFSC 3320 Generalization Generalization is the reverse of specialization process. It defines a generalized entity type from the given entity types. CH 4. Enhanced Entity-Relationship

21 Generalization (cont.)
IFSC 3320 Generalization (cont.) CAR LicensePlateNo Price MaxSpeed VehicleID NoOfPassengers TRUCK LicensePlateNo Price Tonnage VehicleID NoOfAxies VEHICLE LicensePlateNo Price VehicleID d CAR MaxSpeed NoOfPassengers TRUCK Tonnage NoOfAxies CH 4. Enhanced Entity-Relationship

22 Generalization (cont.)
IFSC 3320 Generalization (cont.) We can view {CAR, TRUCK} as a specialization of VEHICLE Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK CH 4. Enhanced Entity-Relationship

23 Generalization (cont.)
IFSC 3320 Generalization (cont.) Generalization suppresses the difference among several entity types, identifying their common features, and generalize them into a single superclass of which the original types are special subclasses. The decision as to which process, generalization or specialization, is more appropriate in a particular situation is often subjective. CH 4. Enhanced Entity-Relationship

24 Constraints on Specialization/Generalization
IFSC 3320 Constraints on Specialization/Generalization Disjointness vs. Overlap Constraints A total specialization vs. a partial specialization Specialization/Generalization hierarchies and lattices Utilizing specialization and generalization in Conceptual Data Modeling CH 4. Enhanced Entity-Relationship

25 Disjointness Constraint
IFSC 3320 Disjointness Constraint Disjointness(d) constraint specifies that the subclasses of the specialization must be disjointed (an entity can be a member of at most one of the subclasses of the specialization) In EER diagram, d in the circle stands for disjoint. CH 4. Enhanced Entity-Relationship

26 CH 4. Enhanced Entity-Relationship
IFSC 3320 Example EMPLOYEE Name SSN BirthDate Address SECRETARY d TypeSpeed TECHNICIAN TGrade ENGINEER EngType d Salary PayScale SALARIED_EMP HOURLY_EMP Disjoint subclasses Disjoint subclasses CH 4. Enhanced Entity-Relationship

27 CH 4. Enhanced Entity-Relationship
IFSC 3320 Overlap Constraint Overlap(o) specifies that the subclasses are not constrained to be disjoint, i.e., the same (real-world) entity may be a member of more than one subclass of the specialization. Overlap is the default constraint and displayed by placing an o in the circle. CH 4. Enhanced Entity-Relationship

28 Completeness constraint
IFSC 3320 Completeness constraint Completeness constraint may be total or partial. A total specialization constraint specifies that every entity in the superclass must be a member of some subclass in the specialization. Represented by a double line connecting the superclass to the circle. CH 4. Enhanced Entity-Relationship

29 Completeness constraint (cont.)
IFSC 3320 Completeness constraint (cont.) A partial specialization allows an entity not to belong to any of the subclasses, using a single line in EER. e.g., if some EMPLOYEE entities, for example, sales representatives, do not belong to any of the subclasses {SECRETARY, ENGINEER, TECHNICIAN}, then the specialization is partial. Represented by a single line connecting the superclass to the circle. CH 4. Enhanced Entity-Relationship

30 Four Possible Constraints
IFSC 3320 Four Possible Constraints The disjointness and completeness constraints are independent. There are four possible constraints on specialization: Disjoint, total Disjoint, partial Overlapping, total Overlapping, partial CH 4. Enhanced Entity-Relationship

31 CH 4. Enhanced Entity-Relationship
IFSC 3320 Some insertion and deletion rules applied to specialization/generalization Deleting an entity from a superclass implies that it is automatically deleted from all the subclasses to which it belongs Inserting an entity in a superclass implies that the entity is mandatorily inserted in all applicable subclasses. Inserting an entity in a superclass of a total specialization implies that the entity is mandatorily inserted in at least one of the subclasses of the specialization. CH 4. Enhanced Entity-Relationship

32 The differences between the specialization and generalization
IFSC 3320 The differences between the specialization and generalization The specialization process corresponds to a top-down conceptual refinement process during conceptual schema design. we typically start with an entity type and then define subclasses of the entity type by successive specialization; The generalization process corresponds to a bottom-up conceptual synthesis. we typically start with an entity type of subclasses and then define superclasses of the entity type by successive generalization. CH 4. Enhanced Entity-Relationship

33 Modeling of UNION Types Using Categories
IFSC 3320 Modeling of UNION Types Using Categories It is possible that single superclass/subclass relationship has more than one superclasses representing different entity types. In this case, the subclass will represent a collection of objects that is (a subset of) the UNION of distinct entity types; we call such a subclass a union type or a category. A category has two or more superclasses that may represent distinct entity types, whereas non-categorty superclass/subclass relationships always have a single superclass. CH 4. Enhanced Entity-Relationship

34 Modeling of UNION Types Using Categories (cont.)
IFSC 3320 Modeling of UNION Types Using Categories (cont.) BANK BAddress BName PERSON Address Name SSN DriverLicenseNo CName CAddress COMPANY U U LienOrRegular OWNER M PurchaseDate OWNS N CModel REGISTERED_VEHICLE TModel CMake U CYear TMake TYear CStyle Tonnage U VehicelId VehicleId CAR TRUCK CH 4. Enhanced Entity-Relationship

35 Modeling of UNION Types Using Categories (cont.)
IFSC 3320 Modeling of UNION Types Using Categories (cont.) Two categories in car registration database. OWNER is a subclass of the union of PERSON, BANK, and COMPANY REGISTRERED_VEHICLE is a subclass of the union of CAR and TRUCK An entity that is a member of OWNER must exist in only one of the superclass. Attribute inheritance works more selectively in the case of categories. e.g., each OWNER entity inherits the attributes of a COMPANY, a PERSON, or a BANK, depending on the superclass to which the entity belongs. CH 4. Enhanced Entity-Relationship

36 Partial vs. Total Categories
IFSC 3320 Partial vs. Total Categories A category can be total or partial PERSON BANK C1 C2 Partial category U U HAS_ ACCT BANK ACCOUNT_ HOLDER BUILDING LOT U Total category U PROPERTY CH 4. Enhanced Entity-Relationship

37 A category Or A Specialization
IFSC 3320 A category Or A Specialization The superclass of a category may have different key attributes. If a category is total (not partial), it may be represented alternatively as a specialization, and the choice of which representation to use is subjective. PROPERTY BUILDING LOT d U U U U PROPERTY BUILDING LOT Category Specialization CH 4. Enhanced Entity-Relationship

38 A category Or A Specialization (cont.)
IFSC 3320 A category Or A Specialization (cont.) If the two classes represent the same type of entities and share numerous attributes, including the same key attributes, specialization/generalization is preferred; otherwise, categorization is more appropriate. CH 4. Enhanced Entity-Relationship


Download ppt "IFSC 3320 Enhanced Entity-Relationship"

Similar presentations


Ads by Google