lec 2 the entity-relationship model

7/29/2019 Lec 2 the Entity-Relationship Model

1/28

The Entity-RelationshipModel


2/28

Data Models

DBMS models real world. Data Modellinks users view of the world and

bits stored in computer.

We will ground ourselves in the Relationalmodel

But use the Entity-Relationship(ER) model as amiddle ground for design


3/28

Steps in Database Design

Requirements Analysis

user needs; what must database do?

Conceptual (Database) Design

high level (or semantic)description from users daily view.

often done with the ER model Logical (Database) Design

translate ER into DBMS data model (e.g., Relational Model)

Schema Refinement

consistency, normalization Physical (Database) Design - indexes, disk layout

Security Design - who accesses what, and how


4/28

Conceptual Design

What are the entities and relationships in the enterprise?

What information about these entities and relationships shouldwe store in the database?

What are the integrity constraints or business rules that hold?

A database `schema in the ER Model can be representedpictorially (ER diagrams).

Can map an ER diagram into a relational schema.


5/28

ER Model Basics

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 attributes.

Each entity set has a key(underlined).

Each attribute has a domain.


6/28

Representation of an Entity Set

Entity set Represented by

a rectangle.

Attribute: Represented by

an oval.

Key: Each attributein the primarykey isunderlined.

Employees

ssn

name

lot


7/28

Keys

Used to ensure that each row in a table isuniquely identifiable. For each entity set, we choose a key.

used to establish relationships amongtables and to ensure the integrity of thedata.

A key consists of one or more attributesthat determine other attributes e.g. an invoice number identifies all of the

invoice attributes, such as the invoice date and

the customer name


8/28

Determination of relationship

The principle of determination - define acentral relational database concept known asfunctional dependence.

The attribute B is functionally dependenton the attribute A if each value in columnA determines one and only one value incolumn B.

e.g. From Student table: Std_Num std_dept (but not opposite)

Used when -the determining attribute values

occur more than once in a table.


9/28

Full functional dependence

might take more than a single attributeto define functional dependence e.g.STU_LNAME, STU_FNAME, STU_INIT, STU_PHONESTU_HRS, STU_CLASS

or

STU_LNAME, STU_FNAME, STU_INIT, STU_PHONESTU_HRS, STU_CLASS, STU_GPA


10/28

A superkey is any key that uniquelyidentifies each row

STU_NUM

STU_NUM, STU_LNAME STU_NUM, STU_LNAME, STU_INIT

STU_NUM, with or without additional

attributes, can be a superkey


11/28

Candidate key

Can be described as a superkey without unnecessaryattributes

An entity set can have more than one key.

STU_LNAME, STU_FNAME, STU_INIT, STU_PHONE Might be canditate key

But STU_NUM, STU_LNAME is not bcoz STU_NUM iscanditate key

Primary key

We designate one of the candidate keys as the primary key.

uniquely identifies any given row.

Null is not permitted in the primary key.


12/28

ER Model Basics (Cont.)

Relationship: Association among two or moreentities. E.g., Attishoo works in Pharmacy department.

Represented by a diamond. relationships can have their own attributes.

A relationship must be uniquely identified by theparticipating entities, without reference to its

own attributes. Relationship Set: Collection of similar

relationships. An n-ary relationship set Rrelates nentity sets E1 ... En;

each relationship in Rinvolves entities e1E1, ..., enEn


13/28

the Works_In RelationshipSet

lot

name

Employees

ssn

Works_In

since dname

budgetdid

Departments


14/28

An Instance of the Works_InRelationship Set


15/28

A Ternary Relationship Set:Works_In2


16/28

ER Model Basics (Cont.)

Same entity set can participate indifferent relationship sets, or indifferent roles in the same relationshipset.

subor-

dinate

super-

visorReports_To

since

Works_In

dname

budgetdid

Departments

lot

name

Employees

ssn


17/28

Key ConstraintsAn employee can

work in manydepartments; a

dept can havemany employees.

1-to-1Many-to-

Many

since

Manages

dname

budgetdid

Departments

since

Works_In

lot

name

ssn

Employees

In contrast, each dept

has at most onemanager, accordingto the key constrainton Manages.

1-to-

Many

Many

-to-1


18/28

An Instance of the ManagesRelationship Set

violates the key constraint on MANAGES:A dept has at most one manager.

MANAGES is a kind ofWORKS_IN


19/28

Participation Constraints

Does every departmenthave a manager? If so, this is a

participationconstraint: theparticipation ofDepartments inManages is said to betotal (vs. partial). Every Departments

entity must appearin an instance of theManages relationship.

In contrast, notevery employeemanages adepartment.


20/28

Weak EntitiesA weak entitycan be identified uniquely only by

considering the primary key of another (owner)entity.

Owner entity set and weak entity set mustparticipate in a one-to-many relationship set (one

owner, many weak entities). Weak entity set must have total participation in

this identifyingrelationship set.

lot

nameagepname

DependentsEmployees

ssn

Policy

cost

Weak entities have only a partial key (dashed underline)


21/28

Class Hierarchies:Organizing Entities into ISA (`is a)

HierarchiesOverlap constraints:

Can Joe be an Hourly_Emps as

well as a Contract_Emps entity?

(Allowed / disallowed)

Covering constraints:

Does every Employees entity alsohave to be an Hourly_Emps or a

Contract_Emps entity?(Yes / no)


22/28

Aggregation

As defined so far, a relationship set is anassociation between entity sets.

Aggregation allows us to model arelationship set between entities andrelationships.

i.e., treat a relationship set as an entity setfor purposes of participation in (other)relationships.


23/28

An Example of Aggregation

Monitors is a relationship between entity Employees and relationship Sponsors.

A project issponsored by at least

1 department.

A department may

assign employees

to monitor a

sponsorship.


24/28

Aggregation vs. TernaryRelationshipSome attributes

are not easily

expressed without

aggregation, such

as until.

Here, the Monitors

relationship is not

clearly expressed.


25/28

Conceptual Design Using the ERModel ER modeling canget tricky!

Design choices:

Entity or attribute?

Entity or relationship? Relationships: Binary or ternary? Aggregation?

ER Model goals and limitations:

Lots of semantics can (and should) be captured. Some constraints cannotbe captured in ER.

Well refine things in our logical (relational) design


26/28

Entity vs. Attribute

Address: attribute of Employees?

Entity of its own?

It depends! Semantics and usage. Several addresses per employee?

must be an entity

atomic attribute types (no set-valued attributes!)

Care about structure? (city, street, etc.) must be an entity!

atomic attribute types (no tuple-valued attributes!)


27/28

Entity vs. Relationship

Separate discretionarybudget (dbudget) foreach dept.

What if managersdbudget is a SUM that

covers all manageddepts

Could repeat value

But redundancy areproblems

Better design:

Associate dbudget withthe appointment ofthe employee as

manager of a groupof depts.

Manages2

name dname

budgetdid

Employees Departments

ssn lot

dbudgetsince

Employees

since

name

dname

budgetdid

Departments

ssn lot

Mgr_Appts

is_manager

dbudget

apptnum

managed_by


28/28

Summary of the ER Model

Entities and Entity Set (boxes)

Relationships and Relationship sets(diamonds) binary

n-ary

Key constraints (1-1,1-N, M-N, arrows)

Participation constraints (bold for Total) Weak entities - require strong entity for

key

lec 2 the entity-relationship model

Documents