Title: The Entity-Relationship Model
1Lecture 2
- The Entity-Relationship Model
2ER Model
- Conceptual Design answers
- What are the entities and relationships?
- What information about these entities and
relationships should we store in the database? - What are the integrity constraints or business
rules? - ER Model Concepts
- Entity types
- Relationship types
- Attributes
3Diagrammatic notation
- Use of UML class diagram for displaying ER
concepts. - UML class represents an entity type.
- First section include entity type name.
- Second section lists attributes.
- Third section is not displayed (or used for
derived attributes). - Relation types represented as lines connecting
entity types (classes). - Some UML terminology differs from ER terminology
(discussed later).
4Entity Type
- Entity type
- Define a group of objects with same properties or
attributes. - Examples EMPLOYEE, CUSTOMER, SUPPLIER entity
types. - Entity occurrence (or entity instance)
- Uniquely identifiable object of an entity type.
- Examples Employee John Doe, Customer Mike
Jordan, Supplier Office Depot. - Entity set is the set of entity occurrences.
5ER diagram of Staff and Branch entity types
An entity type is displayed in a rectangular box.
6Relationship Types
- Relationship type
- Define a set of meaningful associations among
entity types. - Examples A Branch HAS some Staff, An Employee
WORKS ON a Project. - Relationship occurrence
- Uniquely identifiable association, which includes
one occurrence from each participating entity
type. - Relationship set is the set of relationship
occurrences (current state of a relationship).
7Semantic net of Has relationship type
8ER diagram of Branch Has Staff relationship
Another notation
Has
Staff
Branch
9Relationship Types
- Degree of a Relationship
- Number of participating entities in
relationship. - Relationship of degree
- two is binary
- three is ternary
- four is quaternary.
10Binary and ternary relationships
Binary
Ternary
11Quaternary relationship called Arranges
12Relationship Types
- Recursive Relationship
- A relationship type where same entity type
participates more than once in different roles. - Relationships may be given role names to indicate
purpose that each participating entity type plays
in a relationship.
13Recursive relationship called Supervises with
role names
14Entities associated through two distinct
relationships with role names
15Attributes
- Attribute
- Property of an entity or a relationship type.
- Attribute Domain
- Set of allowable values for one or more
attributes. - Simple Attribute (or single-valued Attribute)
- An entity has a single atomic value for the
attribute. - Example Employee with SSN 123-45-6789
- Composite Attribute
- Attribute composed of multiple components.
- Examples Address, Name.
- It can be nested.
16Attributes
- Multi-valued Attribute
- Attribute that holds multiple values for each
occurrence of an entity type. - Example Previous jobs for an employee.
- Derived Attribute
- Attribute that represents a value that is
derivable from value of a related attribute, or
set of attributes, not necessarily in the same
entity type. - Example Age derived from DOB and Todays date.
17Keys
- Candidate Key
- Minimal set of attributes that uniquely
identifies each occurrence of an entity type. - Primary Key
- Candidate key selected to uniquely identify each
occurrence of an entity type. - Composite Key
- A candidate key that consists of two or more
attributes.
18ER diagram of Staff and Branch entities and
their attributes
19Entity Type
- Strong Entity Type
- Entity type that is not existence-dependent on
some other entity type. - Weak Entity Type
- Entity type that is existence-dependent on some
other entity type. - It does have a key attribute.
- Identified by a partial key of the weak entity
type and by the primary of the strong entity type
they are related to.
20Strong entity type called Client and weak entity
type called Preference
21Relationship called Advertises with attributes
22Structural Constraints
- Main type of constraint on relationships is
called multiplicity. - Multiplicity - number (or range) of possible
occurrences of an entity type that may relate to
a single occurrence of an associated entity type
through a particular relationship. - Represents policies (called business rules)
established by user or company.
23Structural Constraints
- The most common degree for relationships is
binary. - Binary relationships are generally referred to as
being - one-to-one (11)
- one-to-many (1 or 1M)
- many-to-many ( or MN)
24Semantic net of Staff Manages Branch relationship
type
One-to-one (11) relationship
25Multiplicity of Staff Manages Branch (11)
relationship
11
26Semantic net of Staff Oversees PropertyForRent
relationship type
One-to-many (1) relationship
27Multiplicity of Staff Oversees PropertyForRent
(1) relationship type
1M
28Semantic net of Newspaper Advertises
PropertyForRent relationship type
Many-to-many () relationship
29Multiplicity of Newspaper Advertises
PropertyForRent () relationship
30Structural Constraints
- Multiplicity for Complex Relationships
- Number (or range) of possible occurrences of an
entity type in an n-ary relationship when other
(n-1) values are fixed for the other
participating entity types.
31Semantic net of ternary Registers relationship
with values for Staff and Branch entities fixed
32Multiplicity of ternary Registers relationship
A staff/branch value pair registers zero or more
clients
33Summary of multiplicity constraints
34Structural Constraints
- Multiplicity actually consists of two types of
restrictions on relationships cardinality and
participation. - Cardinality
- Describes maximum number of possible relationship
occurrences for an entity participating in a
given relationship type. - Participation
- Determines whether all (total) or only some
(partial) entity occurrences participate in a
relationship.
35Multiplicity as cardinality and participation
constraints
36Enhanced Entity-Relationship Model
- Basic concepts of ER modeling are not sufficient
to represent more complex systems. - Semantic concepts incorporated into the original
ER model are called the Enhanced
Entity-Relationship (EER) model. - Examples of additional EER concepts are
- subclass / superclass
- specialization / generalization
- Categories (UNION types)
- aggregation
37Subclasses and Superclasses
- Superclass
- An entity type that includes one or more distinct
subgroupings of its occurrences. - Example Employee entity may be further grouped
into Secretary, Mechanic, Manager, etc. - Subclass
- A distinct subgrouping of occurrences of an
entity type. - Example Secretary is a subclass of Employee
38Subclasses and Superclasses (2)
- Superclass/subclass relationship is one-to-one
(11). - These are called IS-A relationships
- Superclass may contain overlapping or distinct
subclasses. - An engineering manager may become member of two
subclasses Manager and Engineer. - Not all members of a superclass need be a member
of a subclass. - Some employees may be unclassified.
39Specialization / Generalization
- Attribute Inheritance
- An entity in a subclass may possess
subclass-specific attributes, as well as those
associated with the superclass. - Specialization Top down process of defining a
set of subclasses of a superclass. - Identify unique characteristics of each subclass.
- Generalization Bottom up process that is the
reverse of the specialization process. - Identify common characteristics of the subclasses.
40AllStaff relation holding details of all staff
41Specialization/generalization of Staff entity
into subclasses representing job roles
42Specialization/generalization of Staff entity
into job roles and contracts of employment
43EER diagram with shared subclass and subclass
with its own subclass
44Constraints on Specialization / Generalization
- Two constraints that may apply to a
specialization/generalization - participation and disjoint constraints
- Participation constraint
- Determines whether every member in a superclass
must participate as a member of a subclass. - May be mandatory or optional.
- Also called total (for mandatory) or partial (for
optional) - Disjoint constraint
- Describes whether member of a superclass can be a
member of one, or more than one, subclass. - May be disjoint (Or) or nondisjoint (And).
45Constraints on Specialization / Generalization
- There are four categories of constraints of
specialization and generalization - mandatory and disjoint
- optional and disjoint
- mandatory and nondisjoint
- optional and nondisjoint.
- Reasons for using Specialization/Generalization
- To add descriptive attributes specific to a
subclass - To identify entities that participate in a
relationship
46EER diagram for a Real Estate organization with
specialization/generalization
47Categories (UNION type)
- A shared subclass is a subclass participating in
relationships with more than one superclass. - Shared class may have its own attributes
- This leads to multiple inheritance.
- A member of a shared subclass must be a member of
the associated superclasses. - A UNION type is a special shared subclass
- A UNION subclass must exist in at least one of
its superclasses (not in all). - Participation is usually optional
48Aggregation
- It is an abtraction concept.
- Similar to the is-part-of relationship in UML
- Use a box to include its components.
- Used when we have to model a relationship
involving a relationship type - Aggregation allows us to treat a relationship
type as a high level entity for purpose of
participation in other relationships.
49Example of Aggregation
Contact_Name Contact_Phone Date
Job_Applicant SSN Name Address Phone
Company Cname Caddress
1
11
Interview
11
Starting_Date Starting_Salary
Results_in
01
Job_Offer Position
50Example of incorrect design
Job_Applicant SSN Name Address Phone
Company Cname Caddress
11
11
Contact_Name Contact_Phone Date Starting_Date Star
ting_Salary
If an interview does not result in an offer, then
Starting_Date and Starting_Salary are
NULL. Multiplicities are different than those on
previous diagram. May show a wrong interview
instance that is not allowed by the aggregation.
01
Job_Offer Position
51Data Modeling Tools
- Several popular tools exist for conceptual design
and mapping to relational schema. - Examples ERWin, S-Designer, ER-Studio, MS Visio.
- Good for documenting database design.
- But, it may not follow ER notation.
- Original ER model did not support other concepts
- Such as specializations/generalizations and
aggregations. - They are discussed in next chapter.