Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database...

Department of Computer Science, HKUST 1

Comp 231 Database Management SystemsComp 231 Database Management Systems

2. Entity Relationship (ER) Model


Basic ConceptsBasic Concepts

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

Simplicity is Beauty

A Picture is Worth a Million Words


• An entity set is a set of entities of the same type.

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

EmployeeEntity Type :

e1

e2

e3

Entity set:…

The actual employees

A general specificati

on


AttributesAttributes

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


Types of AttributesTypes of Attributes

• Simple attribute: contains a single value.

Employee

EmpNo

Name

Address


• Composite attribute: consists of several components

Country

Employee

Address

Street

City

EmpNo

Name


• Multivalue attribute: contains more than one value

Employee

Phone

Email


• Derived attribute: computed from other attributes

Employee

Age

Bonus


Key AttributesKey Attributes

• A set of attributes that can uniquely identify an entity

EmployeeEmpNo

Name

EmpNo Name . . .123456 John Wong . . .

456789 . . .

146777 . . .John Wong

Mary Cheung

ERD

tabular



• Composite key: Name or Address alone cannot uniquely identify an employee, but together they can!

Employee

Name

Address



• An entity may have more than one key– e.g., EmpNo, (Name, Address)– only one is selected as the key. (sometimes called the Pri

mary key)

Employee

EmpNo

Name

Address

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

Question: does a desk has a key?


RelationshipRelationship

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


• 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?


• Tabular:

Representation of RelationshipRepresentation of Relationship

A123456

B456789

A-101

A-201

A-202

500

900

700

• Graph:

Depositor

Note: this is NOT an ERD

The amount in

each deposit.

CustomerNoA123456B456789B456789

AccountNoA-101A-201A-302

Amount500900700


• Represent Amount as an attribute of Account

Try an AlternativeTry an Alternative

AccountNoA-101A-201A-302

NameCurrent

Saving

Current

Amount500900700

• 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


Cardinality of RelationshipsCardinality of Relationships

• Number of entities that can be associated together in a relationship set.

• 1 : 1

Customer LoanBorrows

A customer can borrow 1 loan and vice versa


1:N

Customer Loan

Customer Borrow Loan

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


N : M Relationships

Customer Borrow loan

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


NotesNotes

• 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 Relationship SetDegrees of a Relationship Set

• 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


Recursive RelationshipRecursive Relationship

• 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 Representation of Recursive Relationships

Tabular Representation of Recursive Relationships

• Without Role Names

• With Role Names

Where ManagerNo and WorkerNo are Valid EmployeeNo

ManagerNo WorkerNo

A1234 A6543

A1234 A8734

EmployeeNoEmployeeNo

A1234 A8734

A1234 A6543


Existence DependenceExistence Dependence

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

Customer Loanloan

borrow

CusNo LoanNo

A loan cannot exist if there is no borrower.


Weak EntitiesWeak Entities

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

• A weak entity implies existence dependency but NOT vice versa


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 Entity vs Existence ConstraintWeak Entity vs Existence Constraint

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


• 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

Dependent

• Another example of weak entity type

Emp_DepAge

Employee


What does a DB Design do?What does a DB Design do?

Individual tools are easy to use, but using them together to solve a problem is difficult. Let’s examine a few problems...


Ternary RelationshipTernary Relationship

Customer LoanBorrow

Branch


Customer LoanBorrow

Branch

Issue

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

Note: these are all N:M relationships.


What are the Differences?What are the Differences?


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.

Customer LoanBorrow

Branch

IssueCus_Br

CusNo Branch

A12345 CentralB56789 Wanchai


Why?

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

Why?Why?

A12345

B56789 Central

Wanchai

L-001

• John borrows a loan which is issued from Wanchai branch

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

L-002

C54321


• In general, any non-binary relationship can be represented using binary relationships by creating an artificial entity set.– Replace R between entity sets A, B and C by an entity set E, and three

relationship sets:

1. RA relating E and A 2. RB relating E and B

3. RC relating E and C– Create a special identifying attribute for E– Add any attributes of R to E – For each relationship (ai , bi , ci) in R, create

1. a new entity ei in the entity set E 2. add (ei , ai ) to RA

3. add (ei , bi ) to RB 4. add (ei , ci ) to RC

Converting Non-Binary Relationships to Binary FormConverting Non-Binary Relationships to Binary Form


L-001

Customer

Dummy

A12345 x001

B56789 x002

B56789 x003

C54321 x004

ExampleExample

A12345

B56789 Central

Wanchai

L-002

C54321

Dummy

Loan

x001 L-001

x002 L-001

x003 L-002

x004 L-002

Dummy

Branch

x001 Wanchaix002 Central

x003 Wanchaix004 Wanchai

Loan

Issue

Customer DummyBorrow Cus_Br Branch


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

Binary relationships to Ternary?Binary relationships to Ternary?

Customer LoanBorrow

Branch

IssueBuy_stock

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


A case Study

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

My Initial Design:


Questions ?• 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 ?


• 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, s

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

My solution

Student

StudentNo Name weatherdate

destination

Picnicgoes leading Teacher

Name

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


E-R Design DecisionsE-R Design Decisions

• 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


E-R Diagram for Company DatabaseE-R Diagram for Company Database

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?


• 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 (but it won’t be covered in this course!)

Limitations of ER modelLimitations of ER model


Reduction of an E-R Schema to tablesReduction 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.


Translating ERDs into TablesTranslating ERDs into Tables


Representing Entity Sets as TablesRepresenting Entity Sets as Tables

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

customer customer-name customer-streetcustomer-idJones

HayesSmith

321-12-3123

677-89-9011 019-28-3746

Main

MainNorth

customer-cityHarrison

RyeHarrison

customer borrow loan

loan-nocust-id share%

date

cust-name

cust-no

cust-city


Composite key

Representing Weak Entity Sets as TablesRepresenting Weak Entity Sets as Tables

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

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

L-17

L-15

L-17

5

5

11

10 May 1999

23 May 1999

17 May 1999

50

300

75

loan Loan-payment

payment

payment-noLoan-no

dateAmount

Amount


Representing Relationship Sets as TablesRepresenting Relationship Sets as Tables

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


loan-nocust-no share%

date

cust-name

borrower cust-no shareloan-no

A12345

B45678

B45678

L-17

L-15

L-17

10 May 1999

23 May 1999

17 May 1999


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

customer

cust-no cust-name

A12345

B56789

Peter Wong

Mary Cheungloan

loan-no L-001

L-002

date

Sep 2000

Aug 2001


cust-nocust-name

date

loan-no

cust-no

A12345

B56789

indicates who borrowed the

loan

loan-recordCust-no A12345B56789

Loan-noL-001L-002

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


In a 1:N relationship, can we include the key from the “N” side in the table representing the entity in the “1” side? I.e., include Loan_no into the Customer table. Why and Why not?

Questions to Think AboutQuestions to Think About

CusNo Cust_name Loan_no

A12345 Peter Wong ...B56789 Mary Cheung ...

How can we express existence constraints on table?


Questions to Think About (Cont.)Questions to Think About (Cont.)

In a 1:1 relationship, we can include the key from either entity into the table representing the other entity. Suppose the Loan-Customer relationship is 1:1, would you include the Customer_no into Loan or Loan_no into Customer?


cust-nocust-name

date

loan-no

loan

loan-no L-001L-002

dateSep 2000Aug 2001

cust-noA12345B56789

customer

cust-no cust-nameA12345B56789

Peter WongMary Cheung

loan-no L-001L-002

Which one is better?


Questions to Think About (Cont.)Questions to Think About (Cont.)

How can we express existence constraints on table?


cust-nocust-name

date

loan-no

loan

loan-no L-001L-002

dateSep 2000Aug 2001

cust-noA12345

Not allowed; must be enforced by DBMS


Weak Entities

Since 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)

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


Questions to Think about: Relationship or attribute?Questions to Think about: Relationship or attribute?

Customerdepositor

Account

AmountCusNo Name

AccNo Name

We have seen this example before. Questions: Can I put every attribute on an entity type?

Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database...

Documents

Transcript of Department of Computer Science, HKUST 1 Comp 231 Database Management Systems Comp 231 Database...