2. Entity Relationship(ER) Model

1

DATABASE MANAGEMENT SYSTEMS

THE RELATİON MODEL

Relational databases are based on the relational model of data. Code defined the term ‘data model’ to consist of there element:

• Definitions of the structure of the data• Definition of the types of operations allowed

on the data• Integrity constraints used to ensure the data

is as accurate as possible. For example, constraints can be specified to ensure that data fails within a set of values.

2

BASİC CONCEPT

A database can be modeled as a collection of entities relationship among entities

An entity is an object that exists independently and is distinguishable from other objects. an employee, a company, a car, etc. color, age, etc. are not entities A relation is a table or flat file with columns

and rows which has certain properties A tuple is a row of a relation and represents an

instance of a relation 3

An attribute is a named column of a relation

A domain is the set of allowable values for one or more attributes

The degree of a relation is the number of attributes it contains

The cardinality of relation is the number of tuples it contains

4

BASİC CONCEPT

AN ENTİTY SET İS A SET OF ENTİTİES OF THE SAME TYPE

E.g., a set of employees, a set of departments also called entity types

5

EmployeeEntity Type :

e1

e2

e3

Entity set:…

The actual employees

A general specificati

on

ATTRİBUTES

6

• Properties of an entity or a relationship• name, address, weight, height are properties of a Person entity.

• date of marriage is a property of the relationship Marriage.

• ER models are usually represented graphically. The language we are going to use represents entity types as rectangles.

TYPES OF ATTRİBUTES

Simple attribute: contains a single value.

7

Employee

EmpNo

Name

Address

CONPOSİTE ATTRİBUTE:CONSİST OF SEVERAL COMPONENTS

8

Country

Employee

Address

Street

City

EmpNo

Name

MULTİVALUE ATTRİBUTE :CONTAİNS MORE THAN ONE VALUE

9

Employee

Phone

Email

DERİVED ATTRİBUTE:COMPUTED FROM OTHER ATTRİBUTES

10

Employee

Age

Bonus

KEY ATTRİBUTES

A set of attributes that can uniquely identify an entity

11

EmployeeEmpNo

Name

EmpNo Name . . .123456 John Wong . . .

456789 . . .

146777 . . .John Wong

Mary Cheung

ERD

tabular

KEY ATTRİBUTES Composite key: Name or Address alone

cannot uniquely identify an employee, but together they can!

12

Employee

Name

Address

KEY ATTRİBUTES An entity may have more than one key

e.g., EmpNo, (Name, Address) only one is selected as the key. (sometimes

called the Primary key)

13

Employee

EmpNo

Name

Address

In many cases, a key is artificially introduced (e.g., EmpNo) to make applications more efficient.

RELATİONSHİP

A relationship is an association between one or more entities.Given a customer and an account,

the relationship depositor between them indicates that the customer deposits money into the account.

The language we are going to use represents entity types relationships as diamonds.

14

15

• A relationship may have attributes• A relationship type or relationship set identifies relationships of the same properties

Customer

depositor

Account

Amount

CusNoName

AccNo Name

Question: Could Amount be an attribute of Customer? Or an attribute of Account?What does Amount mean? How many values you want to keep?

REPRESENTATİON OF RELATİONSHİP

16

• Tabular: Depositor

Note: this is NOT an ERD

The amount in

each deposit.

CustomerNo

A123456

B456789

B456789

AccountNo

A-101

A-201

A-302

Amount

500

900

700

A123456

B456789

A-101

A-201

A-202

500

900

700

Graph:

TRY AN ALTERNATİVE

17

• Represent Amount as an attribute of Account

AccountNo

A-101

A-201

A-302

Name

Current

Saving

Current

Amount

500

900

700

Consider Amount as the balance of an account (I.e., one value per account) or as the last deposit amount.

“Multivalue” attribute, though allowed in ER model, is difficult to implement

CARDİNALİTY OF RELATİONSHİPS Number of entities that can be associated

together in a relationship set. 1 : 1 One entity of type X can be associated

with, at most, one entity of type Y. One entity of type Y can be associated with, at most, one entity of type X.

18

Customer LoanBorrows

A customer can borrow 1 loan and vice versa

1 : N

19

Customer Loan

Customer Borrow Loan

A Customer can borrow more than 1 loan, whereas a loan has only one borrower.

One entity of type X can be associated with many entities of type Y. One entity of type Y can be associated with, at most, one entity of type X.

N : M

20

Customer Borrow loan

A customer can borrow more than one loan A loan can have more than one borrower.

One entity of type X can be associated with many entities of type Y. One entity of type Y can be associated with many entities of type X.

NOTES

21

• Cardinality specifies the maximum condition.

1 : 1 N : M

1 : N The minimum is specified by

existence constraints (explained later)

Conditions must be satisfied at all times

DEGREES OF A RELATİONSHİPS SET

22

• Number of entity sets participating in a relationship set.

Customer LoanBorrow- Binary

Relationships with degree >3 is very rare. Hint: translate a ternary relationship into

one sentence. Can you break it up into two or more

sentences?

A customer borrows a loan from a branch.

A customer borrows a loan. A loan is made at a branch.

Customer LoanBorrow

Branch

- Ternary

RECURSİVE RELATİONSHİPS

23

• A relationship relating entitles of the same type

Employees play different roles: manager or worker Without role names, you can’t tell whether 1 employee manages n

other employees or n employees manages 1 employee You can “unfold” a recursive relationship to understand it:

manager worker

Employee work-for Employee

manager

worker

Employee work-for

TABULAR REPRESENTATİON OF RECURSİVE RELATİONSHİPS

24

• Without Role Names

• With Role Names

Where ManagerNo and WorkerNo are Valid EmployeeNo

ManagerNo WorkerNo

A1234 A6543

A1234 A8734

EmployeeNoEmployeeNo

A1234 A8734

A1234 A6543

OPTİONAL VERSUS MANDATORY Assume there is an entity type called

person, and entity subtypes called customer and employee. When a person is created, the designer of the database has two options:

mandatory He/she can demand that the person be

classified as one of the subtypes. optional He/she can allow a person to be created

without classifying the person as any subtype.

25

OPTİONAL VERSUS MANDATORY

26

Neither one is preferable to the other. The proper one to choose depends on the business situation.

Mandatory sub-typing is represented by creating a double line from the super-type (person in the following ER diagram) to the circle.

Optional sub-typing is represented by leaving a single line from the super-type to the circle.

AGGREGATİON OF ENTİTY TYPES Subtypes are generally thought of in terms

of X is a Y (which is why these are commonly referred to as is-a relationships). Another type of relationship that needs to be represented in a database is the part of relationship, more formally called aggregation. When an entity is made up of several different types of other entities, an aggregation relationship may be called for.

27

AGGREGATİON OF ENTİTY TYPES

28

Consider the relationship between a car and its engine and body. The engine and body are both part of the car. The relationship is represented as follows in an ER diagram.

PARALLEL RELATİONSHİPS

Two entities can have more than one type of relationship. This is not surprising; further, it is not difficult to represent in a database or in an ER diagram. Consider the entity types person and insurance policy and the relationships between them of pays for and is insured under.

29

PARALLEL RELATİONSHİPS

30

A person pays for zero or more insurance policies. An insurance policy is paid for by exactly one person.

A person is insured by zero or more insurance policies. An insurance policy insures one or more persons.

EXİSTENCE DEPENDENCE

The existence of an entity depends on the existence of another entity

31

Customer Loanloan

borrow

CusNo LoanNo

A loan cannot exist if there is no borrower.

WEAK ENTİTİES

A weak entity cannot be identified with its own attributes no key

A weak entity implies existence dependency but NOT vice versa

32

33

LoanNo Amount Date_payPaymentNo

Payment

• A loan may have 240 payments, each identified by a payment no 1 - 240.

•The PaymentNo is unique given a particular loan but not unique globally

• PaymentNo is called partial key• The primary key of Payment is the combination of

LoanNo and PaymentNo.

Loanpayment

Question: Why not combine loan and payment into one entity type?

AmountLoan

WEAK ENTİTY VS EXİSTENCE CONSTRAİNTS

In the existence constraint example, LoanNo can uniquely identify a Loan in the database so it is not a weak entity.

The existence constraint means that you cannot create a Loan record without first knowing who borrowed the loan.

34

ANOTHER EXAMPLE OF WEAK ENTİTY TYPE

35

• A child may not be old enough to have a HKID number

• Even if he/she has a HKID number, the company may not be interested in keeping it in the database.

EmpNo Name

DependentEmp_Dep

AgeEmployee

TERNARY RELATİONSHİPS

36

Customer LoanBorrow

Branch

A customer borrows a loan from a branch.

Customer LoanBorrow

Branch

Issue

A customer borrows a loan. A loan is issued from a branch.

WHAT ARE THE DİFFERENCES?

37

A customer borrows a loan from a branch.

A customer borrows a loan. A loan is issued from a branch.

CusNo LoanNo Branch

A12345 L-001 CentralB56789 L-001 Wanchai

CusNo LoanNo

A12345 L-001B56789 L-001 LoanNo Branch

L-001 CentralL-001 Wanchai

Imagine a bank allows borrowers of the same loan to go to difference branches for signing documents, deposit payments, etc.

The two schemes are not the same. The binary relationships capture less information.

Adding a third relationship won’t help.

38

Customer LoanBorrow

Branch

IssueCus_Br

CusNo Branch

A12345 CentralB56789 Wanchai

WHY?

Customer, Loan and Branch have a N:M:P relationship

39

A12345

B56789 A12345

A12345

L-001

N:N:1 relationship can be decomposed (A loan is issued by ONE BRANCH ONLY)

John borrows a loan which is issued from Wanchai branch

BİNARY RELATİONSHİPS TO TERNARY?

Binary relationships may have different meanings so that they can’t be combined into ternary relationships.

40

Customer LoanBorrow

Branch

IssueBuy_stock

You may have a ternary relationshipCustomer-Loan-Branchand other binary relationships between Customer, Loan and Branch

A CASE STUDY

41

A primary school student writes a composition about a picnic: Today is Sep 9, the weather is fine. My classmates, John, Mary and I go to a picnic in Sai Kung. Our teacher is Ms Wong

Picnic

weather

destination

date

Students

Name

Teacher

Name

Initial Design:

QUESTİONS ?

Why “John”, “Mary”, “Miss Wong” are not in the ER diagram ?

What do these names tell us ? What are the keys of Student, Picnic &

Teacher ? What are the cardinalities of the relationships

?

42

Every student has an ID number, it is better to keep it in the database and use it as a key

I bet that there won’t be teachers with the same name; otherwise, I’ll add employee number and use it as a key

goes is N:M, why ? A picnic has more than one student participating; also, a student can go to more than 1 picnic. However, this N:M relationship allows a student to go to more than one picnic on the same date

leading is N:1 , why? Depends on your assumptions I assume a teacher can only lead 1 picnic on a certain date, so given

the teacher name and the date, I can identify a picnic Picnic is made a weak entity. I could have added a PicnicNo, but it

would be very awkward.

43

My solution

Student

StudentNo Name weatherdate

destination

Picnicgoes leading Teacher

Name

Question:How to record number of students in a picnic?

E-R DESİGN DECİSİONS

The use of an attribute or entity set to represent an object. Should an address be an attribute or entity?

Whether a real-world concept is best expressed by an entity set or a relation set. Should marriage be an entity or relationship? Should picnic be an entity or relationship?

The use of a ternary relationship versus a pair of binary relationships. See the borrow-loan-branch example

The use of a strong or weak entity set. See the employee-dependent example

44

E-R DİAGRAM FOR COMPANY DATABASE

45

EMPLOYEE

WORKS_FOR

MANAGESCONTROLS

StartdateDEPARTMENT

WORKS_ON PROJECT

Hours

DEPENDENTS_OF

DEPENDENT

SUPERVISION

superviseesupervisor

Fname Minit Lname

Name SexAddress

SalarySsn

Bdate

Number Of Employees

Name

NumberLocations

Name

NumberLocation

RelationshipBirthdateSexName Can you translate it back into English?

LİMİTATİONS OF ER MODEL Consider representing Part-time and Full-time

employees in the company database: Either you have two entity types will lots of

similarity Or you have a single entity type with redundancy

for most of the entities within it ER model is extended to support other

features such as generalization

46

REDUCTİON OF AN E-R SCHEMA TO TABLES

Primary keys allow entity sets and relationship sets to be expressed uniformly as tables which represent the contents of the database.

A database which conforms to an E-R diagram can be represented by a collection of tables. Always!

Converting an E-R diagram to a table format is the basis for deriving a relational database design from an E-R diagram. 47

REPRESENTİNG ENTİTY SETS AS TABLES

48

Composite key

• A weak entity set becomes a table that includes a column for the primary key of the identifying strong entity set

• A strong/regular entity set reduces to a table with the same attributes.

payment loan-no payment-datepayment-no payment-amount

L-17

L-15

L-23

5

22

11

10 May 1999

23 May 1999

17 May 1999

50

300

75

customer customer-name customer-streetcustomer-id

Jones

Hayes

Smith

321-12-3123

677-89-9011

019-28-3746

Main

Main

North

customer-city

Harrison

Rye

Harrison

REPRESENTİNG RELATİONSHİP SETS AS TABLES

49

cust-no loan-no share%

…. …. ….

depositor

•A many-to-many relationship set is represented as table with columns for the primary keys of the two participating entity sets, and any descriptive attributes of the relationship set.

customer borrow loan

loan-nocust-no share%

date

cust-name

For 1:N and 1:1 relationships, you can create a table for each relationship

But it is more concise to merge the relationship-table with the entity-table on the “N” side

50

customer

cust-no cust-name

A12345

B56789

Peter Wong

Mary Cheung loan

loan-no L-001

L-002

date

Sep 2000

Aug 2001

customer borrow loan

cust-nocust-name

date

loan-no

cust-no

A12345

B56789

indicates who borrowed the

loan

WEAK ENTİTİESSince a weak entity has to include the primary key

of the identifying entity, the 1:N relationship is already captured. E.g., The payment table already contains information about the Loan (I.e., loan_no)

51

Already indicates the1:N relationship

between loan-no and payment-no

payment loan-no payment-datepayment-no payment-amount

L-17

L-17

L-17

5

7

6

10 May 1999

23 May 1999

17 May 1999

50

300

75