0% found this document useful (0 votes)
37 views

Chapter 4 EER

The document discusses enhanced entity-relationship (EER) diagrams and inheritance. It explains that EER diagrams allow entities to be related in an "is-a" relationship where one entity is a subtype of another. Subtypes inherit all attributes and relationships of the supertype. The document provides examples of disjoint, covering, and non-disjoint inheritance relationships between entities. It also discusses using notation like circles and triangles to indicate inheritance and whether subtypes are disjoint or overlapping.

Uploaded by

Ayele Nugusie
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views

Chapter 4 EER

The document discusses enhanced entity-relationship (EER) diagrams and inheritance. It explains that EER diagrams allow entities to be related in an "is-a" relationship where one entity is a subtype of another. Subtypes inherit all attributes and relationships of the supertype. The document provides examples of disjoint, covering, and non-disjoint inheritance relationships between entities. It also discusses using notation like circles and triangles to indicate inheritance and whether subtypes are disjoint or overlapping.

Uploaded by

Ayele Nugusie
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPT, PDF, TXT or read online on Scribd
You are on page 1/ 35

Enhanced Entity-Relationship

Diagrams
REVIEW
 Extended Entity-Relationship Model
adds Inheritance
 indicates that one entity type is
an extension of another entity type
 often referred to as an IS-A relationship
http://www.agilemodeling.com/artifacts/classDiagram.htm
Inheritance defines a subclass relationship
 A subclass inherits all properties (members) of the super class
This is the perspective of most modern
programming languages
B ⊂ A, C ⊂ A everything true about a member
Every B is also an A of a set is also true about any
Every C is also an A member of its subsets.

all entities

A
B C
Phone
Name PERSON
ID

IsA

STUDENT PROFESSOR

Major Class Dept Office


Phone
Name PERSON
ID

STUDENT PROFESSOR

Major Class Dept Office

preferred notation: shows directionality of inheritance


Phone
Name PERSON
ID

STUDENT PROFESSOR

Major Class Dept Office

The circle may be omitted when not needed.


Student and professor entities have all
attributes defined for a person,
plus additional attributes
Keys are also inherited.
Subtypes should not define new keys.
Phone
Name PERSON
ID

STUDENT PROFESSOR

Major Class Dept Office


Relationships are also inherited by subtypes

Every mouse
must be sold with
a computer? TRUE

Every computer
must be sold with
a mouse? FALSE
Disjointness: an entity can be
a member of at most one subtype
 a person may be a student or may be a professor, but not both

Covering: every entity of the supertype


must also be a member of at least one subtype
 every person must be a professor or a student
B ⊂ A, C ⊂ A no entity is in both B and C
B ∩ C = ∅

all entities

A
B C
an entity may be in both B and C

overlapping = non-disjoint

all entities

A
B C
B ⊂ A, C ⊂ A every entity in A is also in B or C
B ∪ C = A

all entities
A

B C
some entities in A are not in B or C

all entities

A
B C
IsA (triangle) notation:

write “disjoint” and/or “covering”


next to the triangle

Subset notation,

‘d’ in the circle  disjointness


‘o’ in the circle  no disjointness (overlap)

required participation from supertype


indicates a covering constraint
Every A can also be a B or a C, or both, or neither

A A

IsA o

B C B C
Every A can also be a B or a C or but not both

A A

disjoint
IsA d

B C B C
Every A must be a B or a C or both

A A

covering
IsA o

B C B C
Every A must be a B or a C, but not both

A A

disjoint,
IsA d
covering

B C B C
disjoint, covering inheritance:
every car is a vehicle
every truck is a vehicle
every vehicle is either a car or a truck
no vehicle is both a car and a truck
disjoint, non-covering inheritance:
employees may be secretaries, technicians or
engineers, but not more than one of these
non-disjoint, covering inheritance:
every part is a manufactured part,
or a purchased part,
or both (a purchased, manufactured part)

** How many attributes does a purchased, manufactured part have?


** How would we model this in UML (C++ or Java)?
** Interpret this schema.

** Can you find a real-world example?


Inheritance Lattice

Multiple inheritance gives us a lattice,


rather than a hierarchy

** Could we have engineering managers without defining the E_M class?


(compare to previous example)
Union defines a type as the union of other types
OWNER = PERSON ∪ COMPANY
OWNER is called a union type or category
 OWNER is the subtype of the union of PERSON and COMPANY
Not multiple inheritance
 an OWNER does not need all the PERSON COMPANY
attributes from
both PERSON and COMPANY ∪

OWNER
B and C are subtypes of A A is a subtype of B∪C
B⊂A
B⊂A A ⊂ B∪C
B∪C ⊂ A

A A

d ∪

B C B C

You might also like