May 8May 8

More on Data ModelingMore on Data Modeling

Types of Entities

Fundamental Entityregular rectangle (exist by themselves)

Attributive Entity only exists because of the existence of some other entity

Associative Entity result from many to many relationship

Many to Many relationships are not stable

Student CourseRegistersfor

JohnAhmedMaryNganSteve

CS211CS212CS255IS315

Solution

JohnAhmedMaryNganSteve

CS211CS212CS255IS315

Student Registration Course

ERD Concepts

AttributeA characteristic of an entity or relationship

Primary Key• Simple• Composite or concatenated

Nonkey• These are all of the other attributes

Multivalued• May contain two or more values• We use an Attributive Entity to resolve these

ERD Concepts

AttributeA characteristic of an entity or relationship

Primary Key• Simple• Composite or concatenated

Nonkey• These are all of the other attributes

Multivalued• May contain two or more values• We use an Attributive Entity to resolve these

Foreign Keys• Pointers to a record in another entity

Primary Key

Attribute

Multivalued Attribute

Attributes

Atomic Factcannot have attributes of its own

Single Valuecannot have more than one value

Persons Last_nameFirst_name

Some Attributes

Persons

Last_name

First_name

Address

Some Attributes

Persons

Last_name

First_name

Street

City

State

Zip

Last_name

First_name

Street

City

State

Zip

Same data shown as a table

FName

LName

Street City State

Zip

Steve Kerr 2 Main Lisle IL 60601

Tom Mix 7 Oak LA CA 97654

Jason Jones 3 Elm SF CA 92345

PERSONS

ID#

123

345

564

PERSONS

Marriage is an M:N proposition

Personsis

marriedto

Notice the functional dependency

Personsis

marriedto

marriage_date

Date becomes an attribute of the relation

Personsmarriage

_date

is married

toMarriage

Functional Dependence

For a relation R, attribute A is functionally dependent of attribute B if, for every valid instance, the value of B determines the value of A.

We draw this as:B --> A

In English, what all this means is…

Suppose we have a sales relation:

Year Sales (millions)

1998 $32.41999 $33.62000 $29.42001 $33.5

Then, Year --> Sales

$33.6

Date becomes an attribute of the relation

Personsmarriage

_date

is married

toMarriage

Student ClassRoster

Student(Student-ID, StudentLName, StudentFName, Address, Phone)Class(Department, Course-ID, Section-ID, Semester, Year, CourseTitle, Credits)Roster(Student-ID, Department, Course-ID, Section-ID, Semester, Year, Grade)

Student-ID

StudentLName

StudentFName

Address Phone

120453 Smith Tom 333 Main 445-2321

443645 Jones Tom 234 Pine 456-7632

347654 Jones Fred 123 Oak 232-9543

298764 Jones Mary 123 Oak 232-9543

Dept CourseID SectionID

Semester

Year Course Title

Credit

IS 315 803 Winter 2002 SA&D 4

IS 315 807 Winter 2002 SA&D 4

IS 315 807 Spring 2002 SA&D 4

Student-ID

Dept CourseID

SectionID

Semester

Year Grade

120453 IS 315 803 Winter 2002 A-

443645 IS 315 807 Winter 2002 B+

347654 IS 315 803 Winter 2002 A

298764 IS 315 803 Winter 2002 A-

DePaul UniversityGrade ReportFall Semester 1998

Name: James Jordan ID: 123456789Address: 1201 Peach DriveMajor: IS

Instructor InstructorCourse ID Title Name Location GradeIS 315 SA&D Valacich CST 440B A-IS 512 Groupware Tyran CST 430G B+

What are the functional dependencies on this report?

Student # Course #CourseTitle

InstructorInstructorLocation

Grade

A123 IS315 SA & D Valacich CST440B A-

O459 IS512 Groupware Tyran CST430G B+

L889 CS319 Database Gilson CST712 C-

Course Roster

KeysPrimary KeysForeign KeysHow keys work in Associative EntitiesHow keys work in Attributive Entities

Business rule: each customer has one sales rep, but sales reps can sell to many customers.

SNum Sname

S12 Tom

S13 Dick

S14 Harry CNum CName

C7 Huey

C8 Dewey

C9 Louis

?

?

Business rule: each customer has one sales rep, but sales reps can sell to many customers.

SNum Sname

S12 Tom

S13 Dick

S14 Harry CNum CName

C7 Huey

C8 Dewey

C9 Louis

For each salesman there can be many customers; for each customer there is only one salesman.

Business rule: each customer has one sales rep, but sales reps can sell to many customers.

SNum Sname

S12 Tom

S13 Dick

S14 Harry CNum CName SNum [fk]

C7 Huey S12

C8 Dewey S12

C9 Louis S14

For each salesman there can be many customers; for each customer there is only one salesman.

Business rule: each customer has one sales rep, but sales reps can sell to many customers.

SNum Sname CNum

S12 Tom C7

S12 Tom C8

S13 Dick

S14 Harry C9 CNum CName

C7 Huey

C8 Dewey

C9 Louis

For each salesman there can be many customers; for each customer there is only one salesman.

NEW Business rule: each customer has one sales rep, and each sales rep has only one customer.

SNum Sname CNum

S12 Tom C8

S13 Dick C7

S14 Harry C9 CNum CName SNum [fk]

C7 Huey S13

C8 Dewey S12

C9 Louis S14

For each salesman there is only one customer; for each customer there is only one salesman.

Review of the rules

KeysPrimary Keys•Every record has a unique primary key

Foreign Keys• In a 1:M relationship, the M side always

has the FK• In a 1:1 relationship, both sides have FKs

How keys work in Associative EntitiesHow keys work in Attributive Entities

Business rule: customers can buy from many salesmen; salesmen can sell to many customers.

SNum Sname

S12 Tom

S13 Dick

S14 Harry

CNum CName

C7 Huey

C8 Dewey

C9 Louis

In order to produce an efficient and stable database, this requires an Associative Entity

Business rule: customers can buy from many salesmen; salesmen can sell to many customers.

SNum Sname

S12 Tom

S13 Dick

S14 Harry

CNum CName

C7 Huey

C8 Dewey

C9 Louis

For each customer there can be many transactions; for each transaction there is only one customer; for each salesman there can be many transactions; for each transaction there is only one salesman.

SNum CNum

Date Prod

Qu

S12 C9 5/8/02 P2 4

S13 C7 5/9/02 P2 5

S14 C8 6/1/02 P3 2

S12 C7 6/3/02 P6 7

Business rule: each order can have many order items

SNum CNum

Date Prod Qu

S12 C9 5/8/02 P2 4

S13 C7 5/9/02 P2 5

S13 C7 5/9/02 P3 2

S12 C7 6/3/02 P6 7

In order to produce an efficient and stable database, this requires an Attributive Entity

Business rule: each order can have many order items

SNum CNum

Date

S12 C9 5/8/02

S13 C7 5/9/02

S12 C7 6/3/02

SNum CNum Line Prod Qu

S12 C9 1 P2 4

S13 C7 1 P2 5

S13 C7 2 P3 2

S12 C7 1 P6 7

In order to produce an efficient and stable database, this requires an Attributive Entity

Purchase OrderAcme Equipment Company

Butte, Montana 87654

PO#:

Date

Address

City, State, Zip

Phone

Customer

Unit PriceProduct# Product Description Quantity Total Price

6

5

4

3

2

1

Line #

$Order Total

Acme Equipment sells product using the purchase orders (Pos) shown at left. Draw the ERD that this PO suggests. Make sure to indicate your Primary and Foreign Keys and assign fields for each entity.

Review of the rules

KeysPrimary Keys

• Every record has a unique primary keyForeign Keys

• In a 1:M relationship, the M side always has the FK• In a 1:1 relationship, both sides have FKs

How keys work in Associative Entities• The Associative Entity takes the many side of all

1:M relationships. The key of the Associative Entity is a compound key of all primary entities.

How keys work in Attributive Entities• The Attributive Entity is the many side of the 1:M

relationship. The Attributive Entity has a compound key comprised of the key of the primary entity plus a unique marker of the attribute.

How do you build an ERD for your case project?

How do you build an ERD for your case project?

Here is a cookbook approachHere is a cookbook approach

Cookbook 1

Derive a high level, first cut data model

What are the techniques?• look at forms, look at existing database,

Identify data entitiesWhat are the entities of interest around which data must be stored?“Model the world” be more rather than less comprehensiveBe aware of the domain you are exploring

Requirements Determination Questions for Data Modeling

What people, places, and things are used in the business? How many of each are there? How do you differentiate them? Entities and attributes What unique characteristics distinguish one object from another? Attributes and primary keyWhat characteristics describe each object? Attributes and secondary keys

Requirements Determination Questions for Data Modeling

How do you use the data? What is the source of the data? Who controls it?Over what time periods are you interested in this data? If it changes over time, do you need to know that? Cardinality and time issuesWhat kinds of transactions do you keep track of? Relationships

Requirements Determination Questions for Data Modeling

Are transactions always handled the same way, or are there sometimes exceptions? Can only some of the attributes of an object change? CardinalityCan the associations or relationships among objects change over time?

ERD Data Sources

Data entry forms (paper and screen)Reports (paper and screen)Existing DatabasesInterviews

Cookbook 2

Identify likely attributes of those entities

• What are the keys? (Primary, Alternate, Foreign)

• How should you name them?• Determine constraints (cardinalities) of

attributes

Determine relationships among entities• How are they related? Optional or mandatory?• What are the cardinalities of the relationships?• Fundamental, attributive, and associative

entities

Cookbook 3

Balance the model into 1:N relationshipsFor each 1:1 relationship

• determine whether the 2 entities are truly separate, or can be combined

M:N relationships • can always be split into 1:N relationships by

discovering the associative entity

For each 1:N relationship• analyze whether there is dependency

– Is one entity dependent on the other, or are they independent?