Download lecture 15

Entity-Relationship Model
ER-Diagrams
Weak entity sets
1
Outline: Conceptual modeling using ER-model
•Data modeling
•Entity-relationship model
- Entity types
- strong entities (regular)
- weak entities
- Relationships among entities
- Attributes - attribute classification
- Constraints
- degree
- cardinality constraints
- participation constraints
-…
2
Database design
Database design is an important and
challenging task.
The relational model is the model used by
RDMBS.
Is the relational model the best model
used by businessmen to describe their
business (logics)?
3
Is relational model suitable for
database designers?
While a simple data model that is
consisting of only a few tables can be
created "manually“, a large application
needs a more systematic approach.
While the relational data model of the
RDBMS still hides many details, it is
nonetheless closer to how the RDBMS
stores data than to how a user thinks
about the underlying enterprise.
4
Different levels call for
different data models
Good design requires a thorough
understanding the data associated with
an enterprise and how they are used,
as well as a solid understanding of the
functionalities of your DBMS (Oracle in
our case)
 At least two levels understanding
here!
• Application
• implementation
5
Conceptual Semantic data models are
needed to bridge the gap and assist the
database design process.
Being syntactically correct does not
mean being semantically correct.
6
Conceptual modeling
A high-level conceptual model provides
concepts for describing the database
structure that are close to the way users
perceive data.
A conceptual schema describes the structure
of the database by hiding the details of
physical storage structures.
Conceptual modeling is the process of
creating a conceptual schema using a highlevel conceptual model.
7
The main phases of database application Design
Functional Analysis
Functional Analysis
Mini World
Requirements
Collection and Analysis
Database Requirements
High level transaction specification
Conceptual Design
Conceptual Schema (high level)
DBMS-independent
Logical Design (Data Model Mapping)
DBMS-specific
APPLICATION PROGRAM DESIGN
Logical Schema
(in the data model of a sepcific DBMS)
Physical Design
TRANSACTION IMPLEMENTATION
Internal Schema
Application programs
8
Example
The company database keeps track of a company’s
employees, departments, and projects:
Requirements:
concerning the department:
1.
2.
3.
4.
5.
The company is organized into departments
Each department has a unique name, a unique number, and a specific
employee is its’ manager
we track the start date for the manager function
a department may be in several locations
a department controls a number of projects
concerning the project:
6.
a project has a unique name, a unique number, and is in a single
location
9
example continued
concerning the employee:
7.
each employee has a name, social insurance number,
address, salary, sex, and birth date
8. an employee is assigned to one department but may work on several
projects which are not necessarily controlled by the same department
9. we track the number of hours per week that an employee works on
each project
10. we keep track of the direct supervisor of each employee
11. we track the dependents of each employee (for insurance purposes)
concerning the dependent:
12. we record each dependent’s first name, sex, birth date,
and relationship to the employee
10
ER model concepts
 The Entity-Relationship (ER) model is a popular high-level
conceptual model which helps describe a real application
scenario in a pictorial format.
 It employees the notions of entities, attributes and
relationships, as well as constraints.
 This model and its variations are frequently used for the
conceptual design of database applications, and many database
design tools employ its concepts.
 It was introduced by P. Chen (bit.csc.lsu.edu/~chen) in "The
Entity-Relationship model - Toward a Unified Views of Data",
TODS 1:1, March 1976.
11
Purpose of E/R Model
The E/R model allows us to sketch the
design of a database informally.
Designs are pictures called entityrelationship diagrams.
Fairly mechanical ways to convert E/R
diagrams to real implementations like
relational databases exist.
12
Entity (entities)
Entity = “thing” or object.
An entity is a specific object or thing in the
mini-world (for instance, a company) with
an independent existence.
Example:
the EMPLOYEE entity David, the research
DEPARTMENT, the product X PROJECT
13
Entity Set & Entity type
Entity type defines the data type of a collection of
entities having the same attributes (that are of
the same type).
 Similar to a class in object-oriented languages.
Entity set = collection of similar entities of a
particular entity type in the database at any point
in time.
The same name is used for both the entity type
and its entity set. They are interchangeably used
when the context is clear.
14
Attributes
 Attribute = property of an entity set.
 Generally, all entities in a set have the same properties.
 Attributes are simple values, e.g. integers or character strings.
 Attributes are properties used to describe an entity.
Example: an EMPLOYEE entity may have a Name, SSN, Address,
Sex, BirthDate.
 A specific entity has a value for each of its attributes.
 Example: a specific EMPLOYEE entity may have





name='Kelly David',
SSN='12321312',
Address='733 Spruce str. Oneonta, NY',
Sex='M',
Birthdate='08-Jan-1980'.
15
Types of attributes
Simple (Atomic) Vs. Composite
(compound)
Single-valued vs. Multi-valued
Stored vs. Derived Attributes
Nesting composite and Multi-valued
attributes.
16
Atomic vs. Composite
 Atomic attri: Each entity has a single atomic value for
the attribute. These attributes are not divisible.
 Example: SSN or Sex
 Composite attribute: The attribute may be composed
of several components.
 Example:
• Address (Apt#, House#, Street, City, State, ZipCode, Country)
• Name (FirstName, MiddleName, LastName)
 The value of a composite attributes is the
concatenation of the values of its component simple
attributes.
17
Composition may form a hierarchy
where some components are
themselves composite.
18
Single-valued vs. Multivalued
Single-valued attri: It has a single value for a
particular entity.
 Example: Age.
Mutli-valued: An entity may have multiple
values for that attribute.
 Example: Color of a Car or PreviousDegrees of a
STUDENT.
 Set Notation: {color} or {previous degrees}
19
Stored vs. Derived Attributes
Derived attribute: An attribute whose value
can be derived from the value of another
attribute (the latter is called stored attribute).
 Example: Age(Derived) and BirthDate(Stored)
attributes.
Remark: The values of some attributes can
be derived from related entities.
 Example: The attribute NumberofEmployees of a
DEPARTMENT entity can be derived by counting
the EMPLOYEE entities of this department.
20
Nesting composite and Multivalued attributes
Depending on how you model
attributes, won’t be discussed here.
21
Null values
In some cases a particular entity may
not have an applicable value for an
attribute. In such situations a special
value NULL is used.
Example, for the ApartmentNumber
attribute of an address of a student
22
When NULL values will be used.
There are different meanings and
reasons for null values.

NULL
Not applicable
missing
unknown
Not known
23
E/R Diagrams
In an entity-relationship diagram, each
entity set is represented by a rectangle.
Each attribute of an entity set is
represented by an oval, with a line to
the rectangle representing its entity set.
24
Example
name
salary
Employee
Entity set (Entity type) employees has two
attributes, name and salary (manufacturer).
Each specific employee entity has values for
these two attributes (name an example).
25
The entities:
employee
dependent
department
project
26
The entities:
fname
minit
lname
name
sex
ssn
dependent
salary
address
employee
name
sex
birthdate
relationship
bdate
name number
location
department
project
name number
location
27
Relationship types
A relationship type among n entity types
E1,…,En defines a set of associations ( a
relationship set) among entities from these
types.
Example: For example, the WORKS_ON
relationship type in which EMPLOYEEs and
PROJECTs participate, or the MANAGES
relationship type in which EMPLOYEEs and
DEPARTMENTs participate.
28
Relationship Types
A relationship set is a set of relationship
instances where each relationship
instance associates entities, one from
each participating entity type.
29
Relationship Set
The current “value” of an entity set is
the set of entities that belong to it.
 Example: the set of all employees in our
database.
The “value” of a relationship is a set of
lists of currently related entities, one
from each of the related entity sets.
30
Example
For the relationship works_on, we
might have a relationship set like:
Employee
112322
Project
project1
31
Relationships
A relationship connects two or more
entity sets.
It is represented by a diamond, with
lines to each of the entity sets involved.
32
With relationships:
1
N
department
works for
1
1
employee
supervisee
manages
1
supervision
controls
N
supervisor
N
1
N
M
works on
1
project
dependents of
N
dependent
partial constraint
total constraint
33
name number
With attributes, etc:
fname
name
ssn
1
lname
minit
sex
startdate
employee
N
1
1
hours
supervisee
N
M
1
supervision
number of
employees
controls
manages
1
supervisor
department
works for
N
salary
address
bdate
degree
location
location
works on
dependents of
project
name number
location
N
dependent
name
sex
birthdate relationship
34
ERD symbols
Entity
Weak entity
Relationship
Identifying relationship
name
Attribute
name
Key attribute
35
ERD symbols
name
Composite attribute
name
Derived attribute
name
Mutlti-valued attribute
Partial participation
Total participation
1:N
Cardinality
36
There are several ways of classifying relationships, according
to the
degree,
cardinality,
participation constraint (mandatory or optional),
whether recursion is involved, and
whether or not relationship is identifying weak entities.
37
Relationship types
The degree of a relationship type is the
number of participating entity types.
When we speak of a student enrolling in a
course, we are discussing a relationship,
enroll in, where two entity sets (STUDENT
and COURSE) are involved; the relationship is
of degree 2 because each instance of enroll in
will always involve one student entity and one
course entity.
Both MANAGES and WORKS_ON are binary
relationship types.
38
Multiway Relationships
Sometimes, we need a relationship that
connects more than two entity sets.
Suppose that suppliers will provide
parts for projects.
binary relationships do not allow us to
make this distinction.
 But a 3-way (ternary) relationship would.
39
Example
name
license
addr
name
supplier
id
parts
supply
projects
name
addr
40
Cardinality ratio
The cardinality ratio for a binary
relationship specifies the number of
relationship instances an entity can
participate in.
Some times cardinality ratio is also
called “Multiplicity” or “cardinality”
Possible cardinality ratios for binary
relationships are 1:1, 1:N, M:N.
41
One-One Relationships
In a one-one relationship, each entity of
either entity set is related to at most one
entity of the other set.
Example: Relationship couple
42
Many-One Relationships
Some binary relationships are many one from one entity set to another.
Each entity of the first set is connected
to at most one entity of the second set.
But an entity of the second set can be
connected to zero, one, or many
entities of the first set.
43
Example
Let us assume manages, from
department to employee is many-one.
A department has at most one
employee as its head.
But an employee can head any number
of departments, including zero.
44
Many-Many Relationships
Think of a relationship between two
entity sets, such as works_on between
employees and projects.
In a many-many relationship, an entity
of either set can be connected to many
entities of the other set.
 E.g., an employee works on many projects;
a project needs many employees.
45
In Pictures
many-many
M:N
many-one
one-one
N:1
1:1
46
An example of an Entity Relationship Model:
Entities are indicated using rectangular shapes, and
relationships between entities are shown with a
diamond shape on a line connecting the entities.
m
n
Enroll-in
Students
Course
Entity sets are shown with a rectangular shape.
Relationship sets are shown with a diamond shape.
The "m" indicates that one course may have many
students enrolled in it.
The "n" indicates that one student may have enrolled in
many courses.
47
Suppose we know of four student entities and two
courses entities. For example, four students named
John, Amelia, Lee, and April, and two courses “Intro to
Art” and “Intro to History”. Information about these is
listed below.
48
Students
Name
Id#
Phone
John
Amelia
Lee
April
184
337
876
901
283-4984
838-3737
933-2211
644-3838
Course
Name
Course#
Dept
Intro to Art
661
Intro to History 765
Art
History
49
We can represent these two sets of entities using set
diagrams.
John
Intro to Art
Amelia
Intro to History
Lee
April
set of students
set of courses
Relationships describe how entities relate to one another
50
Suppose we have the two courses and four students listed
previously. Suppose also that
- John and Amelia are enrolled in Intro to Art
- John and Lee are enrolled in Intro to History
- April is not enrolled in any course.
Below, we depict a relationship set and show the four
instances of an enroll in relationship.
51
John
Amelia
Lee
Intro to Art
Intro to History
April
52
Participation Constraints
Two types: Total participation (also called
existence dependency) and Partial
participation.
The participation of an entity type E to a
relationship type is a total participation if
every instance of E is associated with an
instance of the relationship type. Otherwise,
it is a partial participation.
53
Participation
Example: The participation of
Department to manages is total; while
the participation of Employee to
Manages is partial.
54
Recursive Relationships
If an entity has a relationship with another entity of the same
entity set, then we have a recursive relationship.
Of the relationship types, these are the most difficult to master.
Some situations where recursive relationships can be used:
• An employee supervises other employees
• A person marries another person
• A person is a child of a person
• A course is a prerequisite for another course
• A team plays against another team
• Organizational units report to other organizational units
• A bill-of-materials system, where a part is composed of
other parts.
55
Recursion in a data model is an especially difficult topic.
We have a recursive relationship if the same entity set
appears more than once in a relationship.
superviser
Employee
1
N supervised
supervises
Any instance of this relationship involves two employees,
and so it is a recursive relationship. In this relationship,
one employee is designated the ‘supervisor’ and the other
as the ‘supervised’. Employee fills two roles in this
relationship.
56
Previously, we briefly examined the first case above:
“An employee supervises another employee”.
An instance of the supervises relationship involves two
entities from the same entity set. See the following figure,
where five examples of the supervise relationship are
depicted in a reporting hierarchy.
John
Lee
Peter
Don
Noel
Mary
The reporting hierarchy informs us:
John does not have supervisor
John supervises Lee
John supervises Peter
John supervises Noel
Lee does not supervise anyone
Noel does not supervise anyone
Peter supervises Don
Peter supervises Mary
Don does not supervise anyone
Mary does not supervise anyone
57
superviser
Employee
1
N supervised
supervises
ERD for the supervises relationship. Optionality
specifications allow for:
at least one employee does not have a supervisor
some employees do not supervise others
58
Now consider the second example listed above: “A person
marries another person”. You must be certain of the business
rules that are valid for the miniworld you are concerned with.
Depending on that miniworld, you model marries as
1:1, 1:m, or m:n. Is the relationship “A person marries
another person”, 1:1, 1:m, or m:n?
Person
1
1
marries
What is the cardinality of this relationship?
1:1 ?
1:m ?
m:m ?
59
Now consider the second example listed above: “A person
marries another person”. You must be certain of the business
rules that are valid for the miniworld you are concerned with.
Depending on that miniworld, you model marries as
1:1, 1:m, or m:n. Is the relationship “A person marries
another person”, 1:1, 1:m, or m:n?
Person
1
1
marries
What is the cardinality of this relationship?
1:1 ?
1:m ?
m:m ?
60
If you say 1:1, then only the current marriage for people is of interest in
your miniworld. A recursive 1:1 relationship allows two entities of the
same entity set to be related, but a given entity can only be related to
one other entity. Consider the following figure, where we illustrate 5
persons, and the relationship set showing two marriages involving two
people each. The fifth person is not related to another person through
this relationship.
Does the model allow for a person marrying themselves? Yes, it does,
but that would be against the ‘rules’. To ensure that no one accidentally
records such an instance in your database, you would need supporting
code in the database to ensure it doesn’t occur.
61
A person can be represented using the following diagram.
perFirstName
perInitials
personId
perName
perLastName
Person
perGender
62
Since marries is an association between two people (two
instances of Person) we understand marries is a recursive
relationship
perFirstName
perInitials
personId
perName
1
marries
perLastName
Person
1
perGender
Since we are only interested in
someone’s current marriage partner,
we understand that a person is
associated with at most one other
person via marries
63
John
April
Lee
Alex
Each person is involved
in no more than one
‘marries’ relationship
Amelia
Entity Set
Person
Relationship Set
marries
64
If you said m:n, then you are tracking of all marriages, past and present,
for people in your miniworld; you are allowing for people to remarry and
you are keeping track of all their marriages. The following figure shows
John and Amelia being involved in two marries relationships. A datum
that is recorded for marriages, is the date the ceremony occurred. Where
would that be kept in the model? We will address that soon, in the section
on attributes of relationships.
John
April
Two of these entities are
involved in more than one
‘marries’ relationship.
Lee
Alex
Amelia
Entity Set
Person
Relationship Set
marries
65
Since marries is an association between two people (two
instances of Person) we understand marries is a recursive
relationship
perFirstName
perInitials
personId
perName
N
marries
perLastName
Person
M
perGender
Since we are only interested in
someone’s current marriage partner,
we understand that a person is
associated with at most one other
person via marries
66
Weak Entity Sets
Occasionally, entities of an entity set
need “help” to identify them uniquely.
Entity set E is said to be weak if in
order to identify entities of E uniquely,
we need to follow one or more manyone relationships from E and include
the key of the related entities from the
connected entity sets.
67
Example
name is almost a key for football players, but
there might be two with the same name.
number is certainly not a key, since players
on two teams could have the same number.
But number, together with the Team related
to the player by Plays-on should be unique.
68
In E/R Diagrams
name
number
Players
n
name
Playson
Teams
1
• Double diamond for supporting many-one relationship.
• Double rectangle for the weak entity set.
69
Weak Entity-Set Rules
The key for a weak entity set is its own
underlined attributes and the keys for
the supporting entity sets.
 E.g., player-number and team-name is a
key for Players in the previous example.
70
Weak entity types
An entity type that does not have a key
attribute
A weak entity type must participate in an
identifying relationship type with an owner or
identifying entity type.
Entities are identified by the combination of:
 A partial key of the weak entity type.
 The particular entity they are related to in the
identifying entity type.
71
One more example of weak entity
type
Suppose that a DEPENDENT entity is
identified by the dependent’s first
name, and the specific employee that
the dependent is related to.
DEPENDENT is a weak entity type with
EMPLOYEE as its identifying entity type
via the identifying relationship type
DEPENDENT_OF.
72
Attributes on Relationships
Sometimes it is useful to attach an
attribute to a relationship.
Think of this attribute as a property of
tuples in the relationship set.
73
A convention some modelling tools and designers use is
shown below. In this case, they are using a composite entity
set (the relationship symbol is enclosed in the entity set
symbol). Their intention is to show that marries is both a
relationship and an entity set. We will be using
this notation.
MarDate
Person
N
M
marries
MarLocn
MarOfficial
74
Example
Employees
Works_on
Projects
Hours
Hours is an attributes of works_on, not …
75
Roles (related to recursion)
Sometimes an entity set appears more
than once in a relationship.
Label the edges between the
relationship and the entity set with
names called roles.
76
Example
Relationship Set
Husband
Bob
Joe
…
Married
husband
Wife
Ann
Sue
…
wife
1 employees
1
77
Example
Relationship Set
Buddies
B
A
Buddya
Bob
Joe
Ann
Joe
…
Buddyb
Ann
Sue
Bob
Moe
…
employees
78
Keys
A key is a set of attributes for one entity set
such that no two entities in this set agree on
all the attributes of the key.
 It is allowed for two entities to agree on some, but
not all, of the key attributes.
We must designate a key for every regular
entity set.
A weak entity set alone might not have keys.
79
Keys in E/R Diagrams
Underline the key attribute(s).
80
Example: name is Key for Beers
SSN
employee
name
81
Example: a Multi-attribute Key
dept
number
hours
room
Courses
• Note that hours and room could also serve as a
key, but we must select only one key.
82
remarks
A key of an entity type is a constraint
that all instances of the entity type have
to satisfy.
83
Example: Good
name
projects
ssn
Works_on
name
Employee
This design gives the name of each manufacturer
exactly once.
84
Example: Bad
name
projects
ssn
Works_on
name
employee
Employee name
This design states the employee name twice.
85
Example: Bad
Projct name
ssn
Employees name
Works_on
This design repeats the projects name once for
each participating employee; loses the project if
there are temporarily no participants.
86
Entity, Relationship or
attributes
How deep you understand ER model
Rule of Thumb, (informal rules)
 a noun could be modeled as entity or an attributes
 An action (transitive verb) could be modeled as an
relationship.
 An action (intransitive verb) could be an attributes
or an relationship
Practice & Experience
87
Various constraints
Degree
Cardinality
Participation
Weak entity
Roles
…
88
Design Techniques
1. Avoid redundancy.
2. Minimum null values in tuples
3. Limit multivalued attributes
1. If you have to, make sure how to map them to
tables, attribute values should be atomic.
4. Limit the use of weak entity sets.
1. If you have to, make sure how to map them to
tables.
5. Don’t use an entity set when an attribute
will do.
89
Avoiding Redundancy
Redundancy occurs when we say the
same thing in two different ways.
Redundancy wastes space and (more
importantly) encourages inconsistency.
 The two instances of the same fact may
become inconsistent if we change one and
forget to change the other, related version.
90