CS3431 1

The Entity-Relationship Model

CS3431 2

Database Design StagesApplication

Requirements

ConceptualDesign

Logical Design

Physical Design

Conceptual Schema

Logical Schema

Physical Schema

CS3431 3

Conceptual Design

What is Conceptual Design? Concise representation of our DB application

requirements Why Conceptual Design ?

It helps us to understand application requirements better

It helps us to communicate our understanding of application

It helps us to come up with a ‘good’ design

CS3431 4

Conceptual Design

Conceptual Models ER (Entity Relationship) Model, UML (Unified Modeling Language), ORM (Object Role Modeling), etc

ER Model Structures: entities and relationships Constraints

An ER schema is represented as an ER diagram.

CS3431 5

ER Model: Entity Types and Attributes Entity: “Object” Entity Type: “Class” Attribute: property of an entity, has a domain In ER diagrams

Entity Type rectangle Attribute Oval.

Student

sNamesNumber

sAge

Entity Type Studentwith attributes (sNumber, sName, sAge)

CS3431 6

ER Example

Consider DB instance with 3 students

(1, Joe, 21),

(2, Mary, 20),

(3, Emily, 20)

s1

s2

s3

Student

1

2

3

Emily

Mary

Joe

21

20

CS3431 7

ER Model: Complex Attributes

Composite Attribute: address Multivalued Attribute: major

major

Student entity typewith all its attributes

sta testree t

address

city

Student

sN am esN um ber

sA ge

m ajor

sta testreet

address

city

CS3431 8

ER Model: Relationship Types Relationship: Association between entities Relationship Type: Class of relationships Representation: Use a diamond shape

Student

sNumber

sName

Course

cNumber

title

HasTaken

Relationship type HasTaken to represent Courses taken by Students

CS3431 9

ER Model: Relationship Types with Attributes

Student

sNumber

sName

Course

cNumber

title

HasTaken

project

Relationship HasTaken has an attribute project which is theproject the Student did for the Course

Student

sNumber

sName

Course

cNumber

title

HasTaken

CS3431 10

Example: Relationship Instances students {Hong, Song}, courses {DB1, DB2}, and relationships {(Hong, DB1, 98), (Song, DB1, 99), (Hong, DB2, 97)}

HasTaken

98

97

99

DB1

DB2

Hong

Song

Student Course

CS3431 11

More relationship types

Example :Model the relationship Supplier supplies Products to Consumers for a given price at a given quantity.

How would you model this ?

CS3431 12

More relationship types

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

Model the relationship Supplier supplies Products to Consumers

Could we make two binary (or three binary) relationships instead?

CS3431 13

Binary vs. Ternary Relationships

What about following binary relationships : S “can-supply” P, C “needs” P, and C “deals-with” S

No combination of binary relationships is an adequate substitute: Together 3 binary relationships don’t imply that C has

agreed to buy P from S. Also, how could we record qty and price?

CS3431 14

Recursive Relationship Types and Roles

Recursive relationship type : Part-Subpart

Roles: There are Parts that play the role of superPartThere are Parts that play the role of subPart

Contains

Part

pName pNumber

subPartsuperPart

quantityContains

bike

Part

frame

wheel

seat

tire

1

2

1

1

CS3431 15

ER Model so far

Structures Entity Types Relationship Types

Binary, ternary, n-ary Recursive

Attributes For entity types and relationship types Simple, composite, multivalued

Roles

CS3431 16

ER Model: Key ConstraintsHow : Underline the key attribute/attributes

Key for Student is sNumber Student

sNumber

sName

Key for Movie is <title, year>Movie

title

year

Note:We can represent key for an entity type consisting of more than 1 attribute (e.g.: Movie)We cannot represent multiple keys for an entity type (eg: key for Student can be either sNumber or sName)

CS3431 17

ER Model: Cardinality Constraints

How : Expressed using (min, max)

Student

sNumber

sName

Course

cNumber

title

HasTaken

(2, 3) (0, *)

Student can take >= 2 and <= 3 CoursesCourse can have >= 0 and <= * (infinity) Students

min and max are non-negative integersmax > min

CS3431 18

Cardinality Constraints

1:1 relationship type: A Dept has exactly one Manager, A Person can manage at most one Dept

Person

pNumber

pName

Dept

dNumber

dName

Manages

CS3431 19

Cardinality Constraints

1:1 relationship type: A Dept has exactly one Manager, A Person can manage at most one Dept

Person

pNumber

pName

Dept

dNumber

dName

Manages(0, 1) (1, 1)

CS3431 21

Cardinality Constraints

1:many (1:n) relationship type: A Person works for exactly one Dept, A Dept can have any number of Persons

Person

pNumber

pName

Dept

dNumber

dName

WorksFor

CS3431 22

Cardinality Constraints

1:many (1:n) relationship type: A Person works for exactly one Dept, A Dept can have any number of Persons

Person

pNumber

pName

Dept

dNumber

dName

WorksFor

(1, 1) (0, *)

CS3431 24

Cardinality Constraints

many:many (m:n) relationship type: A Person works for one or more Depts, A Dept can have any number of Persons

Person

pNumber

pName

Dept

dNumber

dName

WorksFor

CS3431 25

Cardinality Constraints

many:many (m:n) relationship type: A Person works for one or more Depts, A Dept can have any number of Persons

Person

pNumber

pName

Dept

dNumber

dName

WorksFor

(1, *) (0, *)

CS3431 26

Cardinality Constraints for n-ary relationships

A Supplier supplies at least one Product to some Consumer

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

CS3431 27

Cardinality Constraints for n-ary relationships

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

(1, *) (0, *)

(0, *)

A Supplier supplies at least one Product to some Consumer

CS3431 28

Cardinality Constraints for n-ary relationships

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

(1, *) (0, *)

(0, *)

What about the following constraints : (1) A Consumer gets a Product from only one Supplier(2) Each Supplier supplies exactly 2 Products

CS3431 29

Cardinality Constraints for Recursive Relationships

A Part can be subpart of one superPartA Part can have many subParts

Contains

Part

pName pNumber

subPartsuperPart

quantity

CS3431 30

Cardinality Constraints for Recursive Relationships

A Part can be subpart of one superPartA Part can have many subParts

C onta ins

Part

pN am e pN um ber

subPartsuperPart

quantity

(0 , 1 )(0 , *)

CS3431 31

Cardinality Constraints for Recursive Relationships

A Part can be subpart of one superPartA Part can have many subParts

A Part can be subpart of many superPartsA Part can have many subParts

C onta ins

P art

pN am e pN um ber

subP artsuperP art

quantity

(0 , 1 )(0 , *)

C onta ins

Part

pN am e pN um ber

subPartsuperPart

quantity

(0 , *)(0 , *)

CS3431 33

ER Model Constraints Summary

Key Constraints

Cardinality Constraints Expressed using (min, max) Binary relationship types are called 1:1, 1:many,

many:many

CS3431 34

An Application Example Courses offered in CS Dept, WPI, in B term

• What entity types? • Student, Professor, Course, GradStudent

• Attributes and key constraints for entity types ?

• What relationship types?

• Cardinality for relationship types ?

CS3431 35

An Application Example

Courses offered in CS Dept, WPI, in B term

Next time …