CS 564 Database Management Systems: Design and Implementation Lecture 1: Entity-Relationship...

29
CS 564 Database Management Systems: Design and Implementation Lecture 1: Entity-Relationship Modeling Chapter 2 in Cow Book Slide ACKs: AnHai Doan, Jeff Naughton, and Jignesh Patel Arun Kumar 1

Transcript of CS 564 Database Management Systems: Design and Implementation Lecture 1: Entity-Relationship...

1

CS 564Database Management Systems: Design and Implementation

Lecture 1: Entity-Relationship Modeling

Chapter 2 in Cow Book

Slide ACKs: AnHai Doan, Jeff Naughton, and Jignesh Patel

Arun Kumar

2

Database Design Process: ~6 steps

1. Requirements Analysis

2. Conceptual Database Design

3. Logical Database Design

4. Schema Refinement

5. Physical Database Design

6. Application and Security Design

3

Database Design Process: ~6 steps

1. Requirements Analysis

2. Conceptual Database Design

3. Logical Database Design

4. Schema Refinement

5. Physical Database Design

6. Application and Security Design

EntityRelationshipModeling

RelationalModel andNormalization

Indexing, etc.

4

ER Model Basics: Entity

Entity: Distinguishable abstract real-world object

An entity has several “Attributes”

An attribute has a “Domain”

A collection of similar entities is an “Entity Set”

An entity set might have a “Key” attribute

Student

Name AgeSID

5

ER Model Basics: Relationship

Relationship: Association among ≥ 2 entities

“Relationship Set” defined similarly

Student

Name AgeSID

Department

Name AddressDID

Major

EnrollDate

6

ER Model Basics: Relationship Set

Mathematically, given entity sets A and B, a relationship set on A and B is a subset of A X B

Student

s2s3

d2

d3

Department

d1s1

s4

Enroll relation:{(s1, d1), (s2, d1),(s3, d2), (s4, d3)}

7

Relationships in ER

Multiple Relationships

Multiplicity of Relationships

Multi-way Relationships

Self Relationships

Multi-way to Binary Conversion

8

Multiple Relationships

Student

Name AgeSID

Department

Name AddressDID

Major

Professor

Name AgePID

Advise Employ

9

Multiplicity of Relationships

a2a3

b2

b3

b1a1

a4

Student DepartmentMany-to-one

a2a3

b2

b3

b1a1

a4

Professor DepartmentMany-to-many

a2a3

b2

b3

b1a1

a4

Student Citizen

One-to-one

10

Many-to-One and One-to-One in ER

Student

Name AgeSID

Department

Name AddressDID

Major

Arrow: Each Student appears at most once in Enroll, i.e., given a Student, the Department is unique (no double majors!)

Student

Name AgeSID

Citizen

Name AddressDID

Match

Q: How is Many-to-Many depicted?

11

CAUTION: Difference with the Book

Student

Name AgeSID

Department

Name AddressDID

Major

The Cow Book denotes the above as follows:

Student

Name AgeSID

Department

Name AddressDID

Major

12

Multi-way (n-ary) Relationships

Professor

Name AgePID

Course

Name CreditsCID

Room

Number SeatsDID

Teach

13

Multi-way (n-ary) Relationships

Professor

Name AgePID

Course

Name CreditsCID

Room

Number SeatsDID

TeachQ: What does this mean?

14

Self Relationships

Professor

Name AgePID

Course

Name CreditsCID

Room

Number SeatsDID

Teach

Collaborate

PI Co-PI

If “roles” are different,label the edges

15

Multi-way to Binary Conversion

Professor Course

Room

Teach

Professor

Course

RoomInRoom

ByProf

OfCourseTeach

Q: Why do we need these arrows?

16

Apart from types of Relationships, ER

model can also capture Constraints

17

Constraints in ER

Key: Uniquely identifies an entity

Participation: Total or Partial

Referential Integrity: Relationship “validity”

Single-value Constraint

Domain Constraints

18

Constraints: Key

Student

Name AgeSID

Q: What does this mean?

Room

Number SeatsDID

19

Constraints: Participation

Student

Name AgeSID

Department

Name AddressDID

Major

Thick: Each Professor must appear at least once in Employ

Professor

Name AgePID

Department

Name AddressDID

Employ

Q: So, what does this mean?

20

Constraints: Referential Integrity

Curve: Each Professor must have a valid Department in Employ

Q: So, what does this mean?

Professor

Name AgePID

Department

Name AddressDID

Employ

Student

Name AgeSID

Department

Name AddressDID

Major

21

Advanced ER Concepts

Weak Entities: an entity dependent on another

Hierarchies: “Is a” relationships among entities

22

Advanced: Weak Entity

Floor

Number NumRooms

Department

Name AddressDID

PartOf

Thick/double lined shapes: Weak Entity and “dependency”

Q. Why arrow, curve, and think line from Floor to PartOf?

Q: Is a floor number ever meaningful without the Department?

DID and Number together are the Key for Floor

23

Advanced: “Is A” Hierarchy

Student

Name AgeSID

Undergrad DoctoralMasters

Analogy: Sub-class Inheritance in PL

IsAIsHonors QualScore

ByThesis

24

General ER Design Philosophy

1. Follow Conventions

2. Convey All App Constraints

3. Avoid Redundancy

4. Prefer Attributes over Trivial Entities

25

1. Follow Conventions

Student DepartmentMajor

Student DepartmentMajor

Student DepartmentMajor

Student DepartmentMajor

26

2. Convey All Application Constraints

Q. What all constraints are missing here?

Professor

Name AgePID

Department

Name AddressDID

Employ

27

3. Avoid Redundancy

Student

Name AgeSID

Department

Name AddressDID

Major

DeptNAme

28

4. Prefer Attributes over Trivial Entities

Student

Name AgeSID

Department

Name

Major

Student

Name AgeSID

MajorDeptName

Q. What is wrong with the above?

29

Review: ER Model

1. Entity, Relationships

2. Constraints

3. Weak Entities; “IsA” Hierarchies

4. Design Philosophy