Lecture 2

Lecture 2
The Entity Relationship Diagram

Modeling
WHAT
Video Link: Chapter 2
https://mynsmclouddrive.uh.edu/public.php?service=files&t=5f7a4695c2c49398cc32594e2c9b27e0
In order to reinforce the concepts learned in this Lecture, please:
- watch the Video (link on first slide),

- review power point in animation mode,
- take the CLASS PARTICIPATION 10% Assessment,
-Database
work Management
on the Systems
HW 3ed, R. Ramakrishnan and J. Gehrke 1
Key Terms
 Conceptual design - WHAT
 Entity and Entity Sets and Attributes and Keys

 Relationship and Relationship Sets and Descriptive Atributes
 Multiplicity
 Key Constraint and Participation Constraint

 Multiway Relationship Sets
 Weak Entity Sets
 "Is-a" Relationships
 Aggregation
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 2
University Enterprise
(Exercise 2.3)
 Requirements
 ER Diagram
Requirements
ERD - WHAT
Textual Analysis: Entities & Attributes
E1
E2
E3
E4
How many entity sets? How many attributes?
4 17
ERD: Entities & Attributes
Error found; need a more rigorous approach
E1
E2
E4
E3
How many attributes?

17
Textual Analysis: Relationships & Attributes
R1
R1
R2
R3 R4
R5
R6
R8
R7
How many relationship sets?

How many descriptive attributes?
8 1
ERD: Relationships and Attributes
R2
R1
R6 R5 R4 R3
R7
R8
How many descriptive attributes?

1
When WHAT Modeling
1. MUST: Textual Analysis on Data Requirements
2. MUST: USE the TEXTBOOK ERD Language
Data Modeling and Data Models
 Data models
• Relatively simple representations of complex real-world data structures
• Often graphical
 Model: an abstraction of a real-world object or event

• Useful in understanding complexities of the real-world environment
 Data modeling is iterative and progressive

The Importance of Data Models
 Facilitate interaction among the designer, the

applications programmer, and the end user
 End users have different views and needs for data
 Data model organizes data for various users - actors
 Data model is an abstraction

• Cannot draw required data out of the data model

Data Model Basic Building Blocks
 Entity: anything about which data are to be collected
and stored
 Attribute: a characteristic of an Entity
 Relationship: describes an association among Entities

 One-to-many (1:M) relationship
 Many-to-many (M:N or M:M) relationship
 One-to-one (1:1) relationship
 Constraint: a restriction placed on the data

Business Rules
 Descriptions of policies, procedures, or principles within a
specific organization
• Apply to any organization that stores and uses data to generate information
 Description of operations to create/enforce actions within an

organization’s environment
 Must be in writing and kept up to date
 Must be easy to understand and widely disseminated
 Describe characteristics of data as viewed by the company

What - ERD
How - Relational
SQL

Overview of Database Design
 Conceptual design: (ER Model is used at this stage.) WHAT
 What are the Entities and Relationships in the enterprise?

 What information (attributes) about these Entities and
Relationships should we store in the database?
 What are the integrity constraints or business rules that hold?
 A database `schema’ in the ER Model can be represented

pictorially (ER Diagrams).
 Can map an ER Diagram into a relational schema. HOW

Symbols Dialect Used in ER Notation

In this diagram, the attribute Date_Completed is in a rectangle

connected to the Completes Relationship line.
It is interesting to note that an attribute cannot be associated with a

one- to- many Relationship
?????

ASSOCIATIVE ENTITIES The presence of one or more attributes on a Relationship
suggests to the designer that the Relationship should perhaps instead be represented as
an Entity type.
To emphasize this point, most ER drawing tools require that such attributes be placed
in an entity type. An associative entity is an entity type that associates the instances of
one or more entity types and contains attributes that are peculiar to the relationship
between those entity instances. The associative entity CERTIFICATE is represented
with the rectangle with rounded corners.
Most ER drawing tools do not have a special symbol for an associative entity.
?????
Associative entities are sometimes referred to as gerunds, because the relationship
name ( a verb) is usually converted to an entity name that is a noun.
Note in Figure that there are no relationship names on the lines between an
associative entity and a strong entity. This is because the Associative Entity
represents the Relationship.

Symbols Dialect Used in E-R Notation
Database System Concepts - 5th Edition, July 11, 2005 6.21 ©Silberschatz, Korth and Sudarshan
Entity Relationship Diagram

Pharmacy Enterprise (Exercise 2.7) Requirements
Requirements
Pharmacy Enterprise (Exercise 2.7) ER Diagram
Pharmacy Enterprise (Exercise 2.7) ER Diagram
HOW?
Database 1 Case Study
Requirements
XYZ Marketing Agency wants to track the
following information about drinkers (can be
buddies or husband and wifes) in bars and the
beers they like made by which beer
manufacturers.
How many data items?

Database 2 Case Study
Requirements
 A company database needs to store information about
employees, departments, and children of
employees(dependents).
 Employees work in a department; each department is managed

by an employee.
 Employees can purchase insurance policies to cover their

dependents; a child must be identified uniquely by name when
the parent (who is an employee; assume that only one parent works for the company) is
known.
How many data items?
Entity Sets
Entity = “thing” or object.
Entity set = collection of similar entities.

Similar to a class in object-oriented languages.
Attribute = property of an Entity set.

Attributes are simple values, e.g. integers or character or
strings.
Beers
ER Diagrams
In an Entity Relationship Diagram:
Entity set = rectangle.
Attribute = oval, with a line to the rectangle representing its entity set.
name manf
Beers
Example
name manf
Beers
Entity set Beers has two attributes, name and

manf (manufacturer).
Each Beers entity has values for these two
attributes, e.g. (Bud, Anheuser-Busch)
ER Model Basics ssn
name
lot
Employees
 Entity: Real-world object distinguishable from other objects. An

entity is described (in DB) using a set of attributes.
 Entity Set: A collection of similar entities. e.g., all employees.

 All entities in an Entity Set have the same set of attributes.
 Each Entity Set has a key.
 Each attribute has a domain.
What is the key?

Relationships
 A Relationship connects two or more Entity sets.
 It is represented by a diamond, with lines to

each of the Entity sets involved.
Example
name addr name manf
Bars Sells Beers Bars Sell some

Beers.
license
Drinkers Like
Frequents Likes some Beers.
Note:
license = Drinkers Frequent
beer, full,
none
some Bars.
name Drinkers addr
Relationship Set
The current “value” of an Entity set is the set
of Entities that belong to it.
Example: the set of all Bars in our database.
The “value” of a Relationship set is a set of

lists of currently related Entity Sets keys, one
from each of the related Entity sets.
Example
name addr name manf
Sells Beers Bars Sell some Beers.

Bars
license
For the Relationship Sells, we might
have a Relationship set values like:
Bar Beer
Joe’s Bar Bud
Joe’s Bar Miller
Sue’s Bar Bud
Sue’s Bar Pete’s Ale
Sue’s Bar Bud Lite
ER Model Basics name
name
ssn lot
ssn lot
since Employees
Employees
name dname
super- subor-
ssn lot did budget super-
visor subor-
visor dinate
dinate
Reports_To
Employees Works_In Departments Reports_To
 Relationship: Association among two or more Entities.

e.g., Attishoo Works_In Pharmacy Department.
 Relationship Set: Collection of similar Relationships.
 An n-ary Relationship Set R relates n entity sets E1 ... En; each
Relationship in R involves Entities e1 E1, ..., en En
• Same Entity Set could participate in different Relationship
Sets, or in different “roles” in same Entity Set.
ER Model Basics
since
name dname
ssn lot did budget
Employees Works_In Departments
Q: How many employees are in department 51?

A: 2
Database
Q: Management
How many attributesSystems 3ed, R. Ramakrishnan
does Works_In has? and J. Gehrke
A: 3 37
Multiway Relationships
Sometimes, we need a Relationship that

connects more than two Entity Sets.
Suppose that Drinkers will only drink certain

Beers at certain Bars.
Our three binary relationships Likes, Sells, and

Frequents do not allow us to make this distinction.
But a 3-way relationship (ternary) would.

Example
name addr name manf
license Bars Beers
Preferences
Drinkers
name addr
Q: How many attributes does Preferences has? A: 3
name addr name manf
license Bars Beers

Preferences
Drinkers
Preferences name addr
Bar Drinker Beer
Joe’s Bar Ann Miller
Sue’s Bar Ann Bud
Joe’s Bar Bob Bud
Joe’s Bar Bob Miller
Sue’s Bar Cal Bud Lite
Many-Many Relationships
Focus: binary Relationships, such

as Sells between Bars and Beers.
In a many-many relationship, an

Entity of either set can be
many-many connected to many Entities of the
other set.
e.g., a Bar sells many Beers; a Beer is

sold by many Bars.
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.
many-one
But an Entity of the second set can be

connected to zero, one, or many
Entities of the first set.
Example
Drinkers Beers
Favorite
Favorite, from Drinkers to Beers is many-one.
A Drinker has at most one favorite Beer.
But a Beer can be the favorite of any number

of Drinkers, including zero.
One-One Relationships
In a one-one Relationship, each Entity
of either Entity set is related to at
most one Entity of the other Entity set.
Example: Relationship best-seller

between Entity sets Manfs
one-one
(manufacturer) and Beers.
A Beer cannot be made by more than one
Manufacturer, and no Manufacturer can
have more than one best-seller Beer
(assume no ties).
Representing “Multiplicity”
Show a many-one Relationship by an arrow
entering the Relationship set towards the “one”
side.
arrow = “exactly one,” i.e., each Entity of the

first set is related to exactly one Entity of
the target set.
Key Constraints
since
name dname
ssn lot did budget
Employees Works_In Departments
Consider Works_In:
An Employee can work in many Departments;
A Department can have many Employees.
Many-to-Many
Key Constraints since
name dname
ssn lot did budget
Employees Manages Departments
In contrast:
Each department has at most one manager, according to the key
constraint on Manages.
1-to-Many
Textbook
“TEXTUAL
Database Notation
ANALYSIS
Management MUST
REQUIRED
Systems 3ed, BE USED
NOTATIONS
R. Ramakrishnan in
forHomeworks,
ERD Analysis or Projects
and J. Gehrke Data WHAT.docx”
47
Key Constraints
since
name dname
ssn lot did budget
????? Employees Manages Departments
Each department has at most one manager.
Does every Department have a Manager?
Database
Q: Management
How many attributesSystems 3ed, R. Ramakrishnan
does Manages has? and J. Gehrke
A: 3 48
Participation Constraints
 Does every Department have a Manager?
 If so, this is a participation constraint: the participation of
Departments in Manages is said to be total (vs. partial).
• Every did value in Departments table must appear in a
row of the Manages table (with a non-null ssn value!)
since
name dname
ssn lot did budget
Employees Manages Departments
Works_In
since
1. Given the Chen ERD below,
describe the Relationships (identify the business rules), by filing in the boxes:
The business rules are summarized in the following table:
ENTITY Relationship Type ENTITY Business Rules

PROFESSOR 1:M STUDENT A professor can advise many students.
Each student is advised by only one
professor.
PROFESSOR 1:M CLASS A professor can teach many classes.
Each class is taught by only one
professor.
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke Class Participation 501
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 many-one Relationships
from E and include the key of the related
entities from the connected Entity Sets.
In ER Diagrams
name number name
Plays- ?????
Players Teams
on
• Double diamond for supporting many-one Relationship.

• Double rectangle for the weak Entity set.
Example
Player number is almost a key for football Players,
but there are two Teams with the same
numbers.
Player name is certainly not a key, since Players
on same Team could have the same name.
But Player number, together with the Team name
related to the Player by Plays-on should be
unique.
name number name
Players Plays- Teams

on
Weak Entity-Set Rules
A weak Entity set has one or more many-one
Relationships to other (supporting) Entity sets.
Not every many-one Relationship from a weak Entity
set need be supporting.
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

Plays-on.
Weak Entities
 A Weak Entity Set can be identified uniquely only by considering
the primary key of another (owner) Entity Set.
 Owner Entity set and Weak Entity Set must participate in a
one-to-many Relationship Set (one owner Entity, many weak
Entities).
 Weak Entity Set must have total participation in this
identifying Relationship Set .
 The arrow from Dependents to Policy indicates that each Dependent Entity
appears in at most one (indeed, exactly one, because of the participation
constraint) Policy relationship.
name
cost pname age
ssn lot
Employees Policy Dependents
SEE
“TEXTUAL ANALYSIS REQUIRED NOTATIONS for ERD Analysis or Data WHAT.docx”
Subclasses
Subclass = special case = fewer Entities = more properties.
Example: Ales are a kind of Beer.

Not every Beer is an Ale, but some are.
Let us suppose that in addition to all the properties
(attributes and Relationships) of Beers, Ales also have
the attribute color.
?????
Subclasses in ER Diagrams
Assume subclasses form a tree.

i.e., no multiple inheritance.
isa triangles indicate the subclass relationship.

Point to the superclass.
isa
Example
name Beers manf
isa ?????
color Ales
ER vs. Object-Oriented Subclasses
In OO, objects are in one class only.

Subclasses inherit from superclasses.
In contrast, ER Entities have representatives

in all subclasses to which they belong.
Rule: if Entity e is represented in a subclass, then e
is represented in the superclass.
Example
Rule: if Entity e is represented in a subclass, then e
is represented in the superclass.
name Beers manf
Pete’s Ale
isa
color Ales
ISA (`is a’) Hierarchies ssn
name
lot
As in C++, or other OOPLs, attributes are inherited.

If we declare A ISA B, every A entity is also
Employees
considered to be a B entity.
hourly_wages hours_worked
ISA
contractid
Hourly_Emps Contract_Emps
 Overlap constraints: Can Joe be an Hourly_Emps as well as a

Contract_Emps entity? (Allowed/disallowed)
 Covering constraints: Does every Employees Entity also have to
be an Hourly_Emps or a Contract_Emps entity? (Yes/no)
 Reasons for using ISA:
 To add descriptive attributes specific to a subclass.
 To identify Entities that participate in a Relationship.

Database 2 Case Study Requirements
 A company database needs to store information about
employees, departments, and children of
employees(dependents).
 Employees work in a department; each department is managed

by an employee.
 Employees can purchase insurance policies to cover their

dependents; a child must be identified uniquely by name when
the parent (who is an employee; assume that only one parent works for the company) is
known.

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 Entity Set.

Keys in ER Diagrams
Underline the key attribute(s).
In an ISA hierarchy, only the root Entity set

has a key, and it must serve as the key for all
Entities in the hierarchy.
Example: name is Key for Beers
Please OBSERVE the underline!
One or more attributes HAVE TO BE UNDERLINED!
name Beers manf
isa
color Ales
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.
Candidate Keys (2) dept number & hours room

Primary Key (1) dept number (chosen by DBA)
Key (1) dept number
Aggregation ssn
name
lot
Used when we have to model a
Relationship involving (Entitity Employees
Sets and) a Relationship Set.

 Aggregation allows us to treat a Monitors until
Relationship Set as an Entity Set
for purposes of participation in
(other) Relationships.
started_on since
dname
pid pbudget did budget
Projects Sponsors Departments
Aggregation vs. ternary relationship:

 Monitors is a distinct Relationship, with a descriptive attribute.
 Also, can say that each Sponsorship is Monitored by at most one
Employee.
Design Techniques
 Avoid redundancy.
 Limit the use of weak Entity Sets.
 Don’t use an Entity Set when an attribute will do
Avoiding Redundancy
Redundancy occurs when we say the same
thing in two or more 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.
Data quality problems currently cost U.S.

businesses some $600 billion each year!
Good or Bad?
Example: Good
name name addr
Beers ManfBy Manfs
This design gives the address of each manufacturer exactly once.

Good or Bad?
Example: Bad
name name addr
Beers ManfBy Manfs
manf
This design states the manufacturer manf of a beer twice: as an

attribute and as a related Entity.
Good or Bad?
Example: Bad
name manf manfAddr
Beers
This design repeats the Manufacturer’s address once for each

beer and loses the address if there are temporarily no Beers for a
Manufacturer.
Entity Sets vs. Attributes
 An Entity Set should satisfy at least one of the

following conditions:
 It is more than the name of something; it has at

least one nonkey attribute.
or
 It is the “many” in a many-one or many-many
Relationship.
Good or Bad?
Example: Good
name name addr
Beers ManfBy Manfs
•Manfs deserves to be an Entity Set because of the nonkey

attribute addr.
•Beers deserves to be an Entity Set because it is the “many” of

the many-one Relationship ManfBy.
Good or Bad?
Example: Good
name manf
Beers
There is no need to make the Manufacturer an Entity Set, because

we record nothing about manufacturers besides their name.
Good or Bad?
Example: Bad
name name
Beers ManfBy Manfs
Since the Manufacturer is nothing but a name, and is not at the

“many” end of any Relationship, it should not be an Entity Set.
Don’t Overuse Weak Entity Sets
Beginning database designers often doubt that

anything could be a key by itself.
They make all Entity Sets Weak, supported by all
other Entity Sets to which they are linked.
In reality, we usually create unique ID’s for Entity Sets.

Examples include social-security numbers, automobile
VIN’s etc. (surrogate key)
When Do We Need Weak Entity Sets?
The usual reason is that there is no global

authority capable of creating unique ID’s.
Example: it is unlikely that there could be an

agreement to assign unique player numbers
across all football teams in the world.
Conceptual Design Using the ER Model
 Design choices:
 Should a concept be modeled as an Entity or an attribute?
 Should a concept be modeled as an Entity or a Relationship?
 Identifying Relationships: Binary or ternary? Aggregation?
 Limitations in the ER Model:

 A lot of data semantics can (and should) be captured.
 But some constraints cannot be captured in ER diagrams.

Entity vs. Attribute
 Should address be an attribute of Employees or an Entity

(connected to Employees by a relationship)?
 Depends upon the use we want to make of address

information, and the semantics of the data:
• If we have several addresses per employee, address must be
an Entity (since attributes cannot be set-valued).
• If the structure (city, street, etc.) is important, e.g., we want
to retrieve employees in a given city, address must be
modeled as an Entity (since attribute values are atomic).

Entity vs. Attribute
from to
 Works_In4 does not allow name dname
an Employee to work in a ssn lot did budget
Department for two or
more periods. Employees Works_In4 Departments
 Similar to the problem of

wanting to record several
Addresses for an Employee
name dname
ssn lot did budget
 We want to record several
values of the descriptive Works_In4 Departments
Employees
attributes for each instance of this
relationship.
from Duration to
 Accomplished by introducing
new Entity Set, Duration.
Entity vs. Relationship
ER diagram OK if a
Manager gets a
separate discretionary
budget dbudget for name
since dbudget
dname
each Department. ssn lot did budget
Employees Manages2 Departments

What if a Manager
gets a discretionary name
budget that covers ssn lot
all managed since dname
Departments? Employees did budget
 Redundancy: dbudget
Manages2 Departments
stored for each ISA
Department managed
by Manager.
 Misleading: Suggests Managers dbudget This fixes the
dbudget associated with problem!
Department-Manager
combination.
Binary vs. Ternary Relationships
 If each Policy is name
ssn lot pname age
owned by just 1
Employee, and each Employees Covers Dependents
Dependent is tied to
Bad design
the covering Policy, Policies
first diagram is policyid cost

inaccurate. name pname age
ssn lot
Dependents
Employees
Purchaser
Beneficiary
Better design Policies
policyid cost
Binary vs. Ternary Relationships
 Previous example illustrated a case when two binary
relationships were better than one ternary relationship.
 An example in the other direction: a ternary relation

Contracts relates entity sets Parts, Departments and
Suppliers, and has descriptive attribute qty.
 No combination of binary relationships is an adequate

substitute:
 S “can-supply” P, D “needs” P, and D “deals-with” S does
not imply that D has agreed to buy P from S.
 How do we record qty?
TEXTUAL ANALYSIS REQUIRED NOTATIONS for ERD Analysis or Data WHAT.docx.
MUST USE Microsoft WORD. Cut and Paste.

TEXTUAL ANALYSIS REQUIRED NOTATIONS for ERD Analysis or Data WHAT.docx.
MUST USE Microsoft WORD. Cut and Paste.

Use the Class Participation to challenge yourself.
90
2. Given the Requirement below, perform Textual Analysis to identify the Entities
and Relationships:
Employees (ssn, name) work in a Department (did,dname).

Each Department is managed by an Employee.
Draw the ERD:
and Relationships:

Draw the ERD:
M E1: Employee “Works”

2. Given the Requirement below, perform
M E2: Department Textual Analysis to identify the Entities
R1: Works
and Relationships: E2: Department: - A1: did
E1: Employee E1: Employee - A1: ssn E2: Department

E1: Employee - A2: name E2: Department - A2: dname
R2: Manages
Draw the ERD:
M E1: Employee “Manages” M E2: Department
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke Class Participation922

Select
and Relationships:
Employees (ssn, name) work in a Department (did,dname). Cut

Draw the ERD:
M E1: Employee “Works” M E2: Department
R1: Works
E1: Employee E1: Employee - A1: ssn E2: Department E2: Department: - A1: did
Paste
E1: Employee - A2: name E2: Department - A2: dname
R2: Manages
Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke Class Participation932

A1: ssn A2: name A1: did A2: dname
M E1: Employee “Works” M E2: Department
E1: Employee R1: Works

E2: Department
R2: Manages
Rearrange
Summary of Conceptual Design – WHAT
 Conceptual Design follows requirements analysis
(TEXTUAL ANALYSIS is a MUST!!!!)
 Yields a high-level description of data to be stored
 ER model popular for Conceptual Design

 Constructs are expressive, close to the way people think about
their applications.
 Basic constructs: Entities, Relationships, and attributes (of

Entities and Relationships).
 Some additional constructs: weak Entities, ISA hierarchies,
and aggregation.
Note:
 Database There are many variations on
Management Systems 3ed, R. Ramakrishnan and J. Gehrke
ER model. 95
Summary of ER
 Several kinds of integrity constraints can be expressed
in the ER model: key constraints, participation
constraints, and overlap/covering constraints for ISA
hierarchies. Some foreign key constraints are also
implicit in the definition of a Relationship Set.
 Some constraints (notably, functional dependencies)

cannot be expressed in the ER model.
 Constraints play an important role in determining the

best database design for an enterprise.
Summary of ER 60% of the effort
 ER Modeling is subjective. There are often many ways

to model a given scenario! Analyzing alternatives can
be tricky, especially for a large enterprise. Common
choices include:
 Entity vs. attribute, Entity vs. Relationship, binary or n-ary
Relationship, whether or not to use ISA hierarchies, and
whether or not to use aggregation.
 Ensuring good database design: resulting Relational

Schema – HOW should be analyzed and refined
further. FD information and normalization techniques
are especially useful.

The Entity Relationship Model
In 1976, Peter Chen proposed the ER diagrams

Relationship Participation
In 1990, Richard Barker proposed the “Crow’s Foot” ER diagrams

The Entity Relationship Model

Attributes

Weak Entities

Weak Entities
EMPLOYEE
DEPENDENT

Database Systems, 8th Edition
Database
Database Textbook Notation MUST BE USED in Homeworks
Management
Systems, 8th Edition Systems 3ed, R. Ramakrishnan and J. Gehrke 106
THE END
In order to reinforce the concepts learned in this Lecture, please:
- watch the Video (link on first slide),

- review power point in animation mode,
- take the CLASS PARTICIPATION 10% Assessment,
- work on the HW

Lecture 2

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Lecture 2

Enviado por

Direitos autorais:

Formatos disponíveis

Lecture 2

The Entity Relationship Diagram

In order to reinforce the concepts learned in this Lecture, please:

- watch the Video (link on first slide),

 Entity and Entity Sets and Attributes and Keys

 Key Constraint and Participation Constraint

How many entity sets? How many attributes?

How many attributes?

How many relationship sets?

How many descriptive attributes?

 Model: an abstraction of a real-world object or event

 Data modeling is iterative and progressive

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 11

 Facilitate interaction among the designer, the

 End users have different views and needs for data

 Data model organizes data for various users - actors

 Data model is an abstraction

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 12

 Attribute: a characteristic of an Entity

 Relationship: describes an association among Entities

 Constraint: a restriction placed on the data

 Description of operations to create/enforce actions within an

 Must be in writing and kept up to date

 Must be easy to understand and widely disseminated

 Describe characteristics of data as viewed by the company

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 14

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 15

 What are the Entities and Relationships in the enterprise?

 A database `schema’ in the ER Model can be represented

 Can map an ER Diagram into a relational schema. HOW

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 17

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 18

In this diagram, the attribute Date_Completed is in a rectangle

It is interesting to note that an attribute cannot be associated with a

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 19

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 20

Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 22

How many data items?

 Employees work in a department; each department is managed

 Employees can purchase insurance policies to cover their

Entity set = collection of similar entities.

Attribute = property of an Entity set.

Entity set Beers has two attributes, name and

 Entity: Real-world object distinguishable from other objects. An

 Entity Set: A collection of similar entities. e.g., all employees.

 Each Entity Set has a key.

 Each attribute has a domain.

What is the key?

 A Relationship connects two or more Entity sets.

 It is represented by a diamond, with lines to

name addr name manf

Bars Sells Beers Bars Sell some

The “value” of a Relationship set is a set of

Sells Beers Bars Sell some Beers.

 Relationship: Association among two or more Entities.

Employees Works_In Departments

Q: How many employees are in department 51?

Sometimes, we need a Relationship that

Suppose that Drinkers will only drink certain

Our three binary relationships Likes, Sells, and

But a 3-way relationship (ternary) would.

name addr name manf

license Bars Beers