cs34311 the entity- relationship model part iii
DESCRIPTION
CS34313 Cardinality ConstraintsTRANSCRIPT
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)