14 Enhanced Entity Relationship Model

1

CS 338: Computer Applications in Business: Databases (Fall 2014)

©1992-2014 by Addison Wesley & Pearson Education, Inc., McGraw Hill, Cengage Learning Slides adapted and modified from Fundamentals of Database Systems (5/6) (Elmasri et al.), Database System Concepts (5/6) (Silberschatz et al.), Database Systems (Coronel et al.), Database Systems (4/5) (Connolly et al. ), Database Systems: Complete Book (Garcia-Molina et al.)

CS 338: Computer Applications in Business: Databases

The Enhanced ER (EER) Model

©1992-2014 by Addison Wesley & Pearson Education, Inc., McGraw Hill, Cengage Learning Slides adapted and modified from Fundamentals of Database Systems (5/6) (Elmasri et al.), Database System Concepts (5/6) (Silberschatz et al.), Database Systems (Coronel et al.), Database Systems (4/5) (Connolly et al. ), Database Systems: Complete Book (Garcia-Molina et al.) Rice University Data Center

Fall 2014

Chapter 8

Announcements

• Assignment 2 is due on Nov 7

• Midterm 2 is on Nov 12

• Mid-semester survey (extended to Nov 5)

• Start: what would you like me to start doing to help you excel in the course?

• Stop: what would you like me to stop doing that is not helping you learn?

• Continue: what am I doing that is helping you learn? I will try to do more of it.

5

2



Enhanced Entity-Relationship (EER) Model

• ER model concepts are sufficient for representing many database schemas for traditional database applications

• However, designers of database applications have tried to design more accurate database schemas that reflect the data properties and constraints more precisely

• This was particularly important for newer applications of database technology • Engineering design and manufacturing (CAD/CAM) • Telecommunications • Complex software systems • Geographic information systems (GIS)

6

Enhanced Entity-Relationship (EER) Model

• These types of databases have more complex requirements than traditional applications

• This has led to the development of additional semantic data modeling concepts that were incorporated into conceptual data models such as the ER model

• In this chapter, we describe features that have been proposed for semantic data model

• Can enhance ER model to include these concepts

• This has led to the creation of the Enhanced ER (EER) model

7

3



Outline

• EER model includes all the modeling concepts of ER that were presented on Lecture 13

• In addition, it includes concepts of subclass and superclass

• It also includes related concepts of specialization and generalization • Constraints and Characteristics

• Another concept included in the EER model is that of a category or union type used to represent a collection of objects (entities) • Union of different entity types

8

Subclasses, Superclasses and Inheritance

• First concept: subtype or subclass

• Earlier we discussed that an entity type is used to represent both a type of entity and the entity set or collection of entities of that type that exist on the database

• Example

EMPLOYEE describes the type (that is attributes and relationships) of each employee entity, and also refers to the current set of EMPLOYEE entities in the COMPANY database

• In many cases, an entity type has numerous subgroupings or subtypes of its entities that are meaningful and need to be represented explicitly • These subtypes are significant to the database application

9

4




• Example: EMPLOYEE entity type may be distinguished further into

• SECRETARY

• ENGINEER

• TECHNICIAN

• MANAGER

• SALARIED_EMPLOYEE

• HOURLY_EMPLOYEE

• Each subclass is a subset of entities that belong to the EMPLOYEE entity set (every entity that is a member of one of these subgroupings is also an employee)

10

subclass or subtype

.

.

.

superclass or supertype

EMPLOYEE entity type is called

Each of these subgroupings is


• We will call the relationship between a superclass and any one of its subclasses a • superclass/subclass

• supertype/subtype or

• class/subclass relationship

• Example: EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN are two class/subclass relationships

• Remember: a member entity of the subclass represents the same real-world entity as some member of the superclass

• That is, a SECRETARY entity „Joan Logano‟ is also the EMPLOYEE „Joan Logano‟ • Subclass member is the same as the entity in the superclass, but

in a distinct specific role 11

These are also called IS-A relationships SECRETARY IS-A EMPLOYEE, TECHNICIAN IS-A EMPLOYEE, ….

5




• Type inheritance • The type of an entity is defined by the attributes it possess

and the relationship types in which it participates

• Since an entity in the subclass represents the same real-world entity from the superclass, it should possess values for its specific attributes as well as values of its attributes as a member of the superclass

• An entity that is a member of a subclass inherits

• all the attributes of the entity as a member of the superclass

• all the relationships in which the superclass participates

12


• An Entity CANNOT exist in the database merely by being a member of a subclass; it must also be a member of the superclass

• A member of the superclass can be optionally included as a member of any number of its subclasses

13

6



Subclasses and Superclasses Example

• A salaried employee who is also an engineer belongs to the two subclasses:

• ENGINEER, and


• A salaried employee who is also an engineering manager belongs to the three subclasses:

• MANAGER,

• ENGINEER, and


• It is not necessary that every entity in a superclass be a member of some subclass

14

Specialization

• Specialization is the process of defining a set of subclasses of an entity type • The set of subclasses that forms a specialization is defined

on the basis of some distinguishing characteristic of the entities in the superclass

• We may have several specializations of the same entity type based on different characteristics

• Example: • {SECRETARY, ENGINEER, TECHNICIAN} is a specialization of the

superclass EMPLOYEE that distinguishes among employee entities based on the job type

• {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE} is another specialization that distinguishes among employees entities based on the method of pay

15

7



Specialization (Top-Down)

16

specific or local attributes

specific relationship

type

Subclass can define: • Specific attributes • Specific relationship types

The subset symbol on each

line connecting a subclass to

the circle indicates the

direction of the superclass /

subclass relationship


17

An entity that belongs to a subclass represents the same real-world entity connected to it in the EMPLOYEE superclass (even though it is shown twice)

8




• Why include class/subclass relationships and specialization in a data model?

1. Certain attributes may apply to some but not all entities of the superclass

• Example: SECRETARY subclass has local attribute Typing_speed where an ENGINEER has Eng_type

2. Some relationship types may be participated in only by entities that are members of the subclass

• Example: HOURLY_EMPLOYEE can belong to a trade union via the BELONGS_TO relationship type

18


• In summary, the specialization process allows us to do the 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 types or

other subclasses

19

9



Generalization (Bottom Up)

• We can think of a reverse process of abstraction in which • we suppress the differences among several entity types,

• identify their common features, and

• generalize them into a single superclass

• Generalization is functionally the inverse of the specialization process

• Generalization is the process of defining a more general entity type from given entity types

20

Generalization (Bottom Up)

• Example

• {CAR, TRUCK} can be viewed as a specialization of VEHICLE, rather than viewing VEHICLE as a generalization of CAR and TRUCK

• We can view EMPLOYEE as a generalization of SECRETARY, TECHNICIAN, and ENGINEER

21

10



Constraints on Specialization and Generalization

• In some specializations, we can determine exactly the entities that will become members of each subclass by placing a condition on the value of some attribute of the superclass

• These subclasses are called predicate-defined (or condition-defined) subclasses

• Example: EMPLOYEE entity type has an attribute Job_type, we can then specify the condition of membership in the SECRETARY subclass by the condition (Job_type = „Secretary‟) we call this defining predicate of the subclass

• This condition is a constraint specifying that exactly those entities of the EMPLOYEE entity type whose attribute value for Job_type is „Secretary‟ belong to the subclass

• Predicate condition is place next to the line that connects the subclass to the specialization circle

22


• Attribute-defined specialization:

• If all subclasses in a specialization have their membership condition on the same attribute of the superclass, the specialization is called an attribute-defined specialization

• The attribute is called the defining attribute of the specialization

• We display an attribute-defined specialization by placing the defining attribute name next to the arc from the circle to the superclass

• User-Defined subclass: when we do not have a condition for determining membership in a class

23

11




• Two other constraints may apply to a specialization

• Disjointness (or disjointedness) constraint

• Completeness (or totalness) constraint

24



1. Disjointness (or disjointedness) constraint

• Specifies that the subclasses of the specialization must be disjoint

• That is, an entity can be a member of at most one of the subclasses of the specialization

• Specified in EER diagram by d in the circle

• If the subclasses are not constrained to be disjoint, their sets of entities may be overlapping

• The same real-world entity may be member of more than one subclass of the specialization

• This case, which is the default, is displayed by placing an o in the circle

25

12





2. Completeness (or totalness) constraint

• Total specialization: specifies that every entity in the superclass must be a member of at least one subclass in the specialization

• On EER diagram: use double line to connect superclass to the circle

• Example: if every EMPLOYEE must be either an HOURLY_EMPLOYEE or a SALARIED_EMPLOYEE

• Partial specialization: allows an entity not to belong to any of the subclasses

• On EER diagram: use single line to connect superclass to the circle

• Example: if some EMPLOYEE entities do not belong to any of the subclasses {SECRETARY, ENGINEER, TECHNICIAN}

26


27

13




28

In general, a superclass that was identified through the generalization process is usually total, because the superclass is derived from the

subclasses and hence contains only the entities that are in the subclass


• Hence, we have four types of specialization/generalization:

1) Disjoint, total

2) Disjoint, partial

3) Overlapping, total

4) Overlapping, partial

29

14



Specialization/Generalization Hierarchies, Lattices

• A subclass may itself have further subclasses specified on it, forming a hierarchy or a lattice of specializations

• Specialization hierarchy has a constraint that every subclass has only one superclass (called single inheritance); this is basically a tree structure or strict hierarchy

• In a specialization lattice, a subclass can be subclass of more than one superclass (called multiple inheritance)

31


32

15




• Leaf node is a class that has no subclasses of its own

• A shared subclass is subclass in more than one distinct superclass/subclass relationships, where each relationships has a single superclass (multiple inheritance)

• Notice that the existence of at least one shared subclass leads to a lattice, otherwise, it‟s a hierarchy

33


34

16



Category (UNION TYPE)

• All of the superclass/subclass relationships we have seen so far have a single superclass

• In some cases, we need to model a single superclass/subclass relationship with more than one superclass

• Such a subclass is called a category or UNION TYPE

• Example: Database for vehicle registration, vehicle owner can be a person, a bank (holding a lien on a vehicle) or a company

• Category (subclass) OWNER is a subset of the union of the three super classes COMPANY, BANK and PERSON

• A category member must exist in at least one its super classes 35


36

17



Category (UNION TYPE) Comparison with Shared Subclass

• We can compare a UNION TYPE (OWNER) with shared subclass (ENGINEERING_MANAGER)

• The latte is a subclass of each of the three superclasses ENGINEER, MANAGER and SALARIED_EMPLOYEE

• So, an entity that is a member of ENGINEERING_MANAGER must exist in all three (e.g. an engineering manager must be an ENGINEER, a MANAGER, and a SALARIED_EMPLOYEE)

• However, a category is a subset of the union of its superclasses. That is, an entity that is a member of OWNER must exist in only one of the superclasses

37

Category (UNION TYPE) Shared Subclass “ENGINEERING_MANAGER”

38

18




• Attribute inheritance works more selectively in the case of union type or category.

• Can be total or partial

• For example, OWNER entity inherits attributes of a COMPANY, a PERSON OR a BANK

• A shared subclass such as ENGINEERING_MANAGER inherits ALL the attributes of its superclasses

• Some modeling methodologies do not have union types

39

EER Example

40

Documents

14 Enhanced Entity Relationship Model