Database Principles Entities and Relationships. Database Principles What is a Relationship? An association between or among entities. Can be binary, ternary,

Database Principles

Entities and Relationships

Database Principles

What is a Relationship?

• An association between or among entities. Can be binary, ternary, quartic, etc.

• Because entities are “types” of things, relationships also have to be “types” of associations.

• Entities have instances and relationships have occurrences. Entities are while relationships happen.

• In sentences, relationships often show up as verbs.

• Is a relationship between the entities PERSON and AUTOMOBILE.

is an occurrence of this relationship.

Most People own Automobiles

Andrew Pletch owns a VW Passat with VIN: 1234567890987654321

Database Principles

How do we picture a Relationship?

As a line joining the related entities with a diamond in the middle

The name of the relationship goes in or on top of the diamond

PERSON AUTOMOBILEOWNS

The relationship name tends to make grammatical sense in one direction only

?

Database Principles

Just to make it clear:

This is a relationship


This is a collection of occurrences of this relationship

Database Principles

Can Relationships have Properties?

• Yes! • They are also called attributes.• They appear in the diagram underneath the diamond.

• Why can’t PurchaseDate be an attribute of AUTOMOBILE? – Reason 1: Because the same car can be sold several times and

so have a list of PurchaseDates– Reason 2: Because PurchaseDate only makes sense in the

context of “what car?” and “who bought it?”


PurchaseDate

?

Database Principles

Attributes Don’t Get Copied.

• The fact that a vehicle has an owner who has a name is modeled by the <owns> relationship.

• We do NOT replicate this fact by also putting an extra attribute in the VEHICLE entity.


SSNFNameLNameDOB

VINOwnerNameMakeModelYear

NOT permitted/recommended

Database Principles

Does a Relationship have a Key?

• Yes, but they are not documented in the relationship.• Typically it is the combined keys of the participating

entities.

• The key to <owns> is the pair (PersonID,VIN).• We do NOT duplicate these atrributes anywhere else in

the diagram.• No two occurrences of <owns> have the same key

values.

AUTOMOBILEOWNS

PurchaseDate

PERSONVINPersonID

Database Principles

Exercise:

• What does <owns> mean?• What are some occurrences of <owns>?• Describe a general occurrence of <owns>.• Based on the model, can the same person <own> the

same vehicle more than once? Why not?• What would it mean to <own> the same vehicle more

than once? Give a couple of examples.• How would we change the model if this kind of multiple

ownership needed to be modeled?

Database Principles

What if you CAN <own> the same car more than once?

• That’s possible!• But you need the purchase date to tell these two events

apart

• Key to <owns> now: (PersonID,VIN,PurchaseDate).• No two occurrences of <owns> have the same key

values.• We underscore any attribute of a relationship that is part

of the relationship key.


PurchaseDate

PersonID VIN

Database Principles

Exercise:

• How do the two versions of <owns> differ?• What are some occurrences of the new <owns>?• Describe a general occurrence of the new <owns>.

Database Principles

Relationship Cardinalities:

• Read the notes:

• Enterprise Rules are used by the database designer determine what things are entities, what things are relationships and what things are attributes.

www.cs.newpaltz.edu/~pletcha/DB/ThreeQuestions.html

Example: Every Employee earns one and only one salary

EMPLOYEE

ID. . .Salary single-valued fact about all employees

so is modeled as an attribute of EMPLOYEE

Database Principles

Relationship Enterprise Rules:

• How do we model the following rules?

• The answer seems to boil down to asking how many times each PERSON or each AUTOMOBILE can participate in the <owns> relationship.

AUTOMOBILEOWNS

purchase_date

PERSONVINPersonID

Rule 1: A person can own one and only one AUTOMOBILERule 2: A person can own many automobiles acquired at any timeRule 3: Some people do not own automobiles at allRule 4: Every automobile has at least one and possibly many owners.

Database Principles

How many vehicles can a person own?

• Rule 1 and Rule 2 on the previous slide are mutually exclusive but our picture doesn’t allow us to say which of these is the rule that applies in this case.

• That is because the picture is not complete.• We complete the picture by adding what we call

Participation Numbers to each entities participation in each relationship.

Database Principles

Minimum Participation Numbers:

• Does every PERSON own at least one AUTOMOBILE?

• Is every AUTOMOBILE owned by at least one PERSON?

AUTOMOBILEOWNS

purchase_date

PERSONVINPersonID

no – min participation number (mPN) is 0yes – min participation number (mPN) is 1

no – min participation number (mPN) is 0yes – min participation number (mPN) is 1

(0,?) (1,?)

√

√

Database Principles

Maximum Participation Numbers:

• Does any PERSON own more than one AUTOMOBILE?

• Is any AUTOMOBILE owned by more than one PERSON?

AUTOMOBILEOWNS

purchase_date

PERSONVINPersonID

no – max participation number (MPN) is 1yes – max participation number (MPN) is n

no – max participation number (MPN) is 1yes – max participation number (MPN) is n

(0,n) (1,1)

√

√

(0,n) (1,1)

Database Principles

Interpreting Participation Numbers:

AUTOMOBILEOWNS

purchase_date

PERSONVINPersonID

(1,1) (0,n)

mPN = 1:

MPN = 1:

mPN = 0:

MPN = n:

Every PERSON <owns> at least one AUTOMOBILE

No PERSON <owns> more than one AUTOMOBILE

Not every AUTOMOBILE <is owned by> a PERSON

Some AUTOMOBILES <may be owned by> more than one PERSON

Database Principles

Participation Numbers and Keys

• Compare

• and

AUTOMOBILEOWNS

PurchaseDate

PERSONVINPersonID

AUTOMOBILEOWNS

PurchaseDate

PERSONVINPersonID

(0,n) (1,n)

(0,n) (1,n)

The first lets a PERSON own multiple AUTOMOBILES but notthe same AUTOMOBILE twice.The latter allows both things to happen.

Database Principles

An Example:

A library keeps records of current loans of books to borrowers.

Each borrower has a borrower# and each copy of a book has an accession# (there may be several copies of the same book).

The library keeps the name and address of each borrower so that overdue reminders can be sent if necessary.

For each book, the library keeps the title, authors, publisher, publication date, ISBN, purchase price and current list price.

Borrowers can have one of two statuses - junior and senior. There are restrictions on the number of books a borrower may take out at one time depending on his/her status.

Books which are out on loan may be reserved by other borrowers.

The library does not buy paperbacks. When a new edition of a book is acquired, all copies of earlier editions are removed from the shelves.

Database Principles

List all Nouns:

A library keeps records of current loans of books to borrowers.

Each borrower has a borrower# and each copy of a book has an accession# (there may be several copies of the same book).

The library keeps the name and address of each borrower so that overdue reminders can be sent if necessary.

For each book, the library keeps the title, authors, publisher, publication date, ISBN, purchase price and current list price.

Borrowers can have one of two statuses - junior and senior. There is a loan limit on the number of books a borrower may take out at one time depending on his/her status.

Books which are out on loan may be reserved by other borrowers.

When a book is returned the person who made the earliest Reservation for he book is notified.

LibraryLoanBookBorrowerBorroweridCopyAccession_noB_nameB_addressReminderTitleAuthorPublisherPub_dateISBNP_priceC_priceB_statusLoan_limitReservation

Database Principles

Which Nouns are Entities and Which are Attributes?

LibraryLoanBookBorrowerBorroweridCopyAccession_noB_nameB_addressReminderTitleAuthorPublisherPub_dateISBNP_priceC_priceB_statusLoan_limitReservation

Why is Author not an entity? (i) It certainly is a property of Book. (ii) All we know about authors are their name. (iii) Authors do nothing but author books. (iv) In a Publishing House database Authors would be entities. (v) In a Library database, Authors only exist as authors of Books so do not have “independent” existence.

Database Principles

List Entities and their Attributes:

Loan l_date -- how else do we know if it is overdueBook ISBN Author Title Pub_date C_priceBorrower Borrowerid B_name B_address B_status Loan_limitPublisher Pub_nameReminderCopy Accession_no P_priceReservation R_date -- how else do we send a notice to the earliest reservation

Why is Library dropped altogether?

(i) Although certainly an entity, there is only one instance. (ii) All other entities have multiple instances. (iii) No properties exist for Library other than its name. (iv) If our application was a library system with many libraries then it would make sense to make Library an entity.

Database Principles

First Look at a List of Entities:

LOAN

l_date

Borrower

BorroweridB_nameB_addrB_statusLoan_limit

Book

ISBNAuthorTitlePub_dateC_price

Publisher

Pub_name

Reminder

Copy

Accession_noP_price

Reservation

R_date

NOTES:1: Things that have keysthat belong to them arelikely to be entities.2: Nouns that are missingkeys and seem to relate toother things are likely to berelationships and not entities.

Database Principles

Now Add Some Relationships

Borrower


Book

ISBNAuthorTitlePub_dateC_price

Publisher

Pub_name

Reminder

Reserves

r_date

Borrows

l_date

Copy

Accession_noP_price

pub_date??

? 1: Reminder is more ofa transaction or activity than a thing. All the infoneeded for a Reminderis found in other things.

2: Pub_name can be an attribute of Book if we dropthe Publisher entity

Database Principles

Final Version (without mMpn):

Borrower


Book

ISBNAuthorTitlePub_namePub_dateC_price

Reserves

r_date

Borrows

l_date

Copy

Accession_noP_price

Database Principles

Final Version (with mMpn)

Cardholder


Book

ISBNAuthorTitlePub_namePub_dateC_price

Reserves

r_date

Borrows

l_date

Copy

Accession_noP_price

(0,n)

(0,n)

(0,n)

(1,n)

(1,1)

(0,1)

1: Cardholder notBorrower (more accurate)

Does every Cardholder reserve a book? Does any Cardholder reserve more than one book? Is every Book reserved by at least one Cardholder?Is any Book reserved by more than one Cardholder? Does every Cardholder borrow a book? Does any Cardholder borrow more than one book? Is every Copy borrowed by at least one Cardholder? Is any Cardholder borrowed by more than one Cardholder? [current loans only]Does every Book exist as a copy in the Library? Does any Book have more than one copy in the Library? Is every Copy a copy of some Book? Is any Copy a copy of more than one Book? (n=1)

(n=0)

y=n

(n=0)

(y=n)(n=0)

(y=n)

(n=0)

(n=1)

(y=1)

(y=1)(y=n)

Database Principles

A Practical Approach to ER Design

• Read the “Ten Steps to Database Design” web page. It shows how to complete the task of preparing an External View ER diagram in a systematic fashion.

http://www.cs.newpaltz.edu/~pletcha/DB/TenSteps2DBDesign.html

Database Principles

More on Participation Numbers:

• Some relationships are ternary: Consider vaccines produced by different manufacturers and sold in different countries.

• The problem is, how to ask the PN questions.

VACCINE

V_ID

MANUFACTURER

Man_ID

COUNTRY

Name

distributed by, in

Database Principles

Asking the Right Question:

VACCINE

V_ID

MANUFACTURER

Man_ID

COUNTRY

Name

distributed by, in

(a,b)

a? : Does every VACCINE participate at least once in the <distributed by, in> relationship? (n=0, y=1)b? : Does any VACCINE participate more than once in the <distributed by, in> relationship? (n=1, y=n)

c? :

d? :

e? :

f? :

(c,d)

(e,f)

Does every MANUFACTURER <distribute> at least one VACCINE in some COUNTRY? Does any MANUFACTURER <distribute> more than one VACCINE in some COUNTRY?

Is every COUNTRY the recipient of at leastone VACCINE manufactured by someone?Is any COUNTRY the recipient of more thanone VACCINE manufactured by someone?

(1,n)

(1,n)

(1,n)

Database Principles

A Class Example: Part A:

An Airline has planes that are used to fly scheduled flights.

Flight segments are between two airports – departure and arrival. They are scheduled to depart at a certain time and arrive at a certain time. The type of plane to be used is also known.

Scheduled flights are a sequence of flight segments.

Actual flights occur on particular dates using a particular plane flown by a particular pilot and co-pilot. They take off at a given time (perhaps) different from the scheduled departure time and have an ETA.

Pilots have names, SSNs, addresses, DOB.

Planes have unique numbers, capacities – both1st class and economy

This database doesn’t deal with passengers.

Database Principles

A Class Example: Part B:

An Airline reservation system keeps information about customers, their reservations, tickets, seat assignments for scheduled flights.

Scheduled flights are between two airports – departure and arrival. They are scheduled to depart at a certain time and arrive at a certain time. The type of plane to be used is also known. Scheduled flights have flight numbers.

Customer info includes name, address, email address, phone number

A reservation is for a certain customer on a sequence of scheduled flights. It has a locator number. Each reservation has a single source and single destination airport.

A ticket is a paid reservation. It has a ticket number and a payment method Including credit card info

Database Principles

Weak Entities

• An entity is weak if it depends on another entity for part of its key.

• Remember, we can’t copy keys around an ER diagram.• We can’t do the following

• But because the key to an Order Line is really the combination of (OrderNumber,LineNumber), Line instances depend on the key to Order for part of their key.

Line

OrderNumLineNum

Order

OrderNum (1,n) (1,1)

Not allowed

Database Principles

Weak Entities (cont):

• Instead we draw a double line around the weaker (dependent) entity and the relationship that it depends on.

• This picture says that Line is a weak entity whose key consists of the pair (OrderNumber, LineNumber).

• Weak entities always have a (1,1) participation number pair linking to the entity they depend upon. Why?

Line

LineNum

Order

OrderNum (1,n) (1,1)

Database Principles

Weak Entity – Another Example

• Some times a relationship from one department’s point a view is an entity in some other department.

• For the Registrar’s Office, Enrollment as a relationship between two entities – Student and Course:

• For the Bursar’s Office, Enrollment is an entity that relates to a Chargeable Item.

• Why are <enrolls> and Enrollment are the same thing???

Course

CourseNum

Student

StudentNum(1,n) (1,n)

enrolls

ChargeableItem

ItemNumAmountOwedAmountPaid

Enrollment

StudentNumCourseNum

(1,1) (1,1)

charges_forStudentAccount

AccountNum(1,1) (1,n)

Database Principles

How to merge the two diagrams?

Course

CourseNum

Student


enrolls

become NOTE: We converted arelationship into a weak-entity relationship

Registrar’s View

Bursar’s View

ChargeableItem


Enrollment

StudentNumCourseNum

(1,1) (1,1)



Course

CourseNum

Student


enrolls

ChargeableItem


Enrollment

Grade

(1,1)

(1,1)



(1,1)

Database Principles

A New Model for an Old Idea

• The previous example used to be called aggregation. It used to be modeled as:

• The box labeled Enrollment turned the <enrolls> relationship into an entity with the same key.

• We don’t use this method any more because most modeling tools don’t support it.

Course

CourseNum

Student


enrolls

ChargeableItem


(1,1)

(1,1)



Enrollment

Database Principles

IS_A

• Before inheritance became popular because of OOP there was IS_A.

• Both Professor and Student possess the attributes ID, Name and DOB by “inheritance”.

• The key to Professor and the key to Student is the key to Person.

Person

IDNameDOB

Professor

OfficeNumber

Student

GPA

is_a is_a(0,1) (0,1)

(1,1) (1,1)

Database Principles

Modeling History:

• The <borrows> relationship in the Library model only models current loans and not past loans.

• This is clear for two reasons:– The same Copy can not be loaned more than once

• Reason?– The same Cardholder can not borrow the same Copy

more than once. • Reason?

Cardholder

borrowerid

Copy

accession_no

borrows

(0,n) (0,1)

Database Principles

Modeling History 2:

• Suppose we wanted to model a complete loan history of all loans; past and present.

• To allow more than one loan of the same copy we would first need to change the copy Max PN to n.

• To allow the same Cardholder to borrow the same Copy more than once (but on different occasions) we need to add time to the key. To show that this is part of the key to <borrows> and not just another attribute we underline it.

Cardholder

borrowerid

Copy

accession_no

has_borrowed

(0,n) (0,n)

l_date

a copy can be loanedout more than onceadded to the key

Database Principles

• Some entities are related to themselves.

• This models what kind of a data structure?

Self-Related Entities:

Person

SSN

manages(0,n)

(0,1)

worker

manager

Role

Database Principles

More on Participation Numbers:

• Participation Numbers are concise representations of Enterprise Rules.

• A database designer, viewing mMPNs, can make positive declarations about the rules by which a business is run.

• Participation numbers are flexible enough (16 different ways to model a binary relationship) to handle all we need to do.

Documents

Database Principles Entities and Relationships. Database Principles What is a Relationship? An association between or among entities. Can be binary, ternary,