CS3431 1

The Entity-Relationship Model

Part III.

CS3431 2

Cardinality Constraints

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

(1) Each Supplier supplies at least some Product to some Consumer(2) A Consumer gets a Product from only one and same Supplier(3) A Supplier supplies some Product to at least two Consumers(4) Each Supplier supplies exactly two different Products

CS3431 3

Cardinality Constraints

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

price

Product

pName pNumber

qty

(1, *) (0, *)

(0, *)

CS3431 4

ER Model Constraints Summary Key Constraints

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

1:1 1:many many:many

CS3431 5

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? • Prof teaches courses, students take

courses, graduate students are TA-ing for courses

• Cardinality for relationship types ?

CS3431 6

Possible Solution

Student

sNumber

sName

Course

cNumber

title

IsTaking

Professor

pNumber

pName

IsTeaching

GradStudent

gSNumber

gSName

IsTAFor

CS3431 7

Possible Solution

Student

sNumber

sName

Course

cNumber

title

IsTaking

Professor

pNumber

pName

IsTeaching

GradStudent

gSNumber

gSName

IsTAFor

(0, 1)

(1, 1)

(0, *)

(0, 1)

(0, *)(1, *)

CS3431 8

More ER Modeling Constructs: ISA Relationship Types

Similar to “subclass” concept in OO languages

Students can be UGStudents or GradStudents

UGStudents take Classes

GradStudents are TAs for Classes

GradStudents are advised by Professors

CS3431 9

Student

GradStudent

Course

sNamesNumber

ISA ISA

UGStudent

IsTAFor

cNumber title

IsTaking

programyear

ProfessorIs

AdvisedBy

pNumber pName

CS3431 10

Student

GradStudent

(0, *)(0, *)

(1, *)

Course

sNamesNumber

ISA ISA

UGStudent

IsTAFor

cNumber title

IsTaking

(0, 1)

programyear

ProfessorIs

AdvisedBy

pNumber pName

(1, 1) (0, *)

CS3431 11

ISA Relationship

Student

sNamesNumber

ISA

UGStudent

yearQuestions:1. Keys for supertypes and subtypes ?2. Attributes of types?3. Cardinalities on relationship?

CS3431 12

ISA Relationship

Student

sNamesNumber

ISA

UGStudent

year

(1, 1)

(0, 1)

Notes:Key for subtype is same as key for supertypeSubtypes can have additional attributesImplicit 1:1 relationship

CS3431 13

Student

GradStudent

sNamesNumber

ISA ISA

UGStudent

programyear

ProfessorIs

AdvisedBy

pNumber pName

(1, 1) (0, *)

Disjoint/Overlapping: UGStudent can (cannot) also be a GradStudent, or vice versa

Covering/Virtual: Students must be either UGStudent or GradStudent, or both

Is-A Relationship Constraints

CS3431 14

Weak Entity TypesThe Courses offered by a Dept are identified by Cnumber

Course is weak entity typeIts identifying relationship is OffersIts identifying entity type is Dept

Dept Offers Course

dNamedNumber cNamecNumber

(1, 1)(0, *)

Note: Cardinality of weak entity type in a identifying relationship type is (1, 1)

CS3431 15

Summary of ER Structures

Entity Types Relationship types – binary, ternary, n-ary.

recursive Attributes

For entity types or relationship types Simple, composite or multi-valued

Constraints – key, cardinality Roles of entity types in a relationship type ISA relationship types Weak Entity Types – identifying relationship

type, identifying entity type

CS3431 16

Coming up with a good design for your application

Guidelines via examples

CS3431 17

Towards a Good Design

Convey “real” application requirements Utilize meaningful names Try simpler construct first Avoid redundancy Be as precise as possible (constraints) Don’t over specify (limits input)

CS3431 18

Coming up with a good design for your application Give good names to entity types, relationship

types, attributes and roles

C

P

a1 a2

r1r2

q

(0, *)(0, *)

CS3431 19

Good Design: Attribute or entity type?

Should we represent something as an attribute or entity type?

Person

pNumber

pName

dNumber

(or)

Person

pNumber

pName

Dept

dNumber

WorksFor

(1, 1) (0, *)

How should dept be represented?

CS3431 20

KISS Principle: Keep It Simple StupidDo not introduce unnecessary entity types

Person

pNumber

pName

Dept

dNumber

WorksFor

(1, 1) (0, *)

Dept

dNumber

IsWith

(0, *)Contract (1, 1)

Person

pNumber

(1, 1)

pName

(1, 1)

HasContract

(or)

Is Entity type ContractUn-necessary ??

CS3431 21

Good Design: Determine correct cardinality constraints

Person

pNumber

pName

Dept

dNumber

dName

WorksFor

(1, 1) (0, *)

Person

pNumber

pName

Dept

dNumber

dName

WorksFor

(1, *) (0, *)

(or)

CS3431 22

Good Design: Try to avoid redundancy

Any Redundant attribute ?Attribute dNum is redundant

Person

pNumber

pName

Dept

dNumber

WorksFor

(1, 1) (0, *)

dNum

CS3431 23

Good Design: Try to Avoid redundancy

Any Redundant relationship type ?Relationship Type IsObtainedBy is redundant

Supplier

sName

sLoc

Consumer

cName

cLoc

Supply

Product

pName pNumber

(1, *) (0, *)

(0, *)

IsObtainedBy

(0, *)

(0, *)

CS3431 24

Towards a Good Design

Convey “real” application requirements Utilize meaningful names Try simpler construct first Avoid redundancy Be as precise as possible (constraints) Don’t over specify (limits input)