1

Class Number – CS 304Class Number – CS 304

Class Name - DBMSClass Name - DBMS

Instructor – Sanjay Madria

Instructor – Sanjay Madria

Lesson Title – EER Model –21th June

Lesson Title – EER Model –21th June

2

Figure 3.15 ER diagram for the COMPANY schema, with all role names included and with structural constraints on relationships specified using the alternate notation

(min, max).

3

5 Relationships of Higher Degree

- Relationship types of degree 2 are called binary

- Relationship types of degree 3 are called ternary and of degree n are called n-ary

- In general, an n-ary relationship is not equivalent to n binary relationships

4

Figure 3.10 Some relationship instances of a ternary relationship SUPPLY

5

Figure 3.16 An ER diagram for an airline database.

6

Figure 3.17 An ER diagram for a BANK database.

7

Figure 3.18 An ER diagram for a database that keeps track of company and employee phones.

8

Figure 3.19 An ER diagram for a database that keeps track of textbooks used in courses.

9

6 Extended Entity-Relationship (EER)Model

10

Specialization and Generalization

• ER diagrams consider entity types to be primitive objects

• EER diagrams allow refinements within the structures of entity types

• Specialization: top-down refinement into (super)classes and subclasses

11

Figure 4.1 EER diagram notation for representing specialization and subclasses.

12

Figure 4.2 Some instances of the specialization of EMPLOYEE into the {SECRETARY, ENGINEER, TECHNICIAN} set of subclasses.

13

• Generalization groups entity types; bottom up synthesis

• Subclasses inherit the attributes and relationships of their superclasses

•

14

WHY

• Relationship types only partially applicable to the superclass

• Attributes only partially applying to superclasses

15

Figure 4.3 Examples of generalization. (a) Two entity types CAR and TRUCK. (b) Generalizing CAR and TRUCK into VEHICLE.

16

Disjointness Constraints

• Disjoint (d) • The subclasses must have disjoint sets of

entities

• Overlap (o) • The subclasses may have overlapping sets of

entities

17

Figure 4.4 An attribute-defined specialization on the JobType attribute of EMPLOYEE.

18

Completeness Constraints

• Partial • An entity may not belong to any of the

subclasses (single-line)

• Total • Every entity in the superclass must be a

member of some subclass (double-edge)

19

Membership Constraints

• Predicate defined subclasses • The subclass is defined through a predicate on

the attributes of the superclass • Attribute defined subclasses • The subclasses in the specialization are all

defined by the same attribute of the superclass • User defined subclasses • Membership in the subclasses is determined at

the insertion operation level

20

Figure 4.5 Notation for specialization with overlapping (nondisjoint) subclasses.

21

Structures in Specialization

• Multiple Specializations

• Specialization Hierarchy • Each subclass belongs to at most one class

• Lattice Specializations • A subclass may belong to more than one class

22

Figure 4.6 A specialization lattice with the shared subclass ENGINEERING_MANAGER.

23

Categories• Associate more than one superclass to a

subclass. • In categories, different entries of the

subclass may inherit attributes from different superclsses

• An entity in Category is a member of only one of its superclass

• In specializations, all the subclasses inherit all the attributes of the superclass

• Category types: Total or Partial

24

Figure 4.7 A specialization lattice (with multiple inheritance) for a UNIVERSITY database.

25

Figure 4.8 An illustration of how to represent the UNION of two or more entity types/classes using the category notation. Two categories are shown: OWNER and

REGISTERED_VEHICLE.

26

Class Number – CS 304Class Number – CS 304

Class Name - DBMSClass Name - DBMS

Instructor – Sanjay Madria

Instructor – Sanjay Madria

Lesson Title – ER to Relational –26th June

Lesson Title – ER to Relational –26th June

27

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 – Each strong Entity to a table- All simple attributes will become column in the table- Include only simple attributes of the composite attribute

in the table as columns- Derived attribute will not become part of the table- Choose key attribute as Primary key of the table-    -   -

28

-  STEP 2: Map Weak Entity Types to a table and draw identifier from parent entity type into weak entity type

- Key of weak entity will be partial key of weak entity and key attribute of the owner entity on which it depends.

29

Map Relationship Types (STEP 3):1:1 - options for setting up one, two or three

relations- Include PK of one of the entity T into other, say S,

better to choose the PK of the entity type T and include that in the entity S with total participation in the relation.

- Include attributes of R in S- No table for R- Or a table for R with PK of both plus its own

attributes or all the attributes into one relation

30

1:N – the many side of the relationship type T provides a PK to the one side, say S, no new relation

- include attributes of R into S M:N – need to set up a separate relation for the

relationship- include PKs of T and S , and attributes of R

into new table

STEP 4: Map multivalued attributes – set up a new relation for each multi-valued attribute and the PK of the corresponding entity type

  -

31

STEP 5: Mapping of generalization hierarchies and set-subset relationships – possiblity of collapsing into one relation vs. as many relations as the number of distinct classes.

Convert each subclass S and superclass C, where attributes of C are {k, a,b..} and k is PK of C into a relation using following

1. Create a table L for C with attributes of L are {k, a, b..} and PK(L) = k. Create a table for each subclass S, with attributes of S are {k} U attributes of S, with PK of S as {k}

2. Create a relation for S , with attributes of S as {k,a, b..} and its own attributes and PK = k.

32

Mapping Categories

• Specify a new key called a surrogate key when creating a relation for category.

(Because keys for all participating classes are different)

• Include any attribute of its own• Add the surrogate key as foreign key to all other

participating relations• If a category’s superclasses share the same key ,

there is no need for surrogate key

33

• .       Problem statement: Concise but thorough description of the application for which you propose to build a database system, and why the database system is essential.

2  System requirements: Define the scope of the system -- what it does, what it doesn’t do, and how the system will be used.

3  Conceptual database design: Documents the conceptual database design using ER/EER diagrams.

34

• 4. Functional requirements: Describe the various retrieval and update transactions and discuss how they collectively meet the database system requirements.

• 5.    Estimate of effort: Discuss the expected effort required (in terms of person-weeks) to complete the design and implementation of the complete system as proposed.

35

• Keep in mind that you have a limited amount of time to complete the project so you need to be aggressive but realistic in your design.

•