CS34311 The Entity- Relationship Model Part III..
-
Upload
alvin-jackson -
Category
Documents
-
view
225 -
download
0
description
Transcript of CS34311 The Entity- Relationship Model Part III..
![Page 1: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/1.jpg)
CS3431 1
The Entity-Relationship Model
Part III.
![Page 2: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/2.jpg)
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
![Page 3: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/3.jpg)
CS3431 3
Cardinality Constraints
Supplier
sName
sLoc
Consumer
cName
cLoc
Supply
price
Product
pName pNumber
qty
(1, *) (0, *)
(0, *)
![Page 4: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/4.jpg)
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
![Page 5: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/5.jpg)
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 ?
![Page 6: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/6.jpg)
CS3431 6
Possible Solution
Student
sNumber
sName
Course
cNumber
title
IsTaking
Professor
pNumber
pName
IsTeaching
GradStudent
gSNumber
gSName
IsTAFor
![Page 7: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/7.jpg)
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, *)
![Page 8: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/8.jpg)
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
![Page 9: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/9.jpg)
CS3431 9
Student
GradStudent
Course
sNamesNumber
ISA ISA
UGStudent
IsTAFor
cNumber title
IsTaking
programyear
ProfessorIs
AdvisedBy
pNumber pName
![Page 10: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/10.jpg)
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, *)
![Page 11: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/11.jpg)
CS3431 11
ISA Relationship
Student
sNamesNumber
ISA
UGStudent
yearQuestions:1. Keys for supertypes and subtypes ?2. Attributes of types?3. Cardinalities on relationship?
![Page 12: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/12.jpg)
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
![Page 13: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/13.jpg)
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
![Page 14: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/14.jpg)
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)
![Page 15: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/15.jpg)
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
![Page 16: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/16.jpg)
CS3431 16
Coming up with a good design for your application
Guidelines via examples
![Page 17: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/17.jpg)
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)
![Page 18: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/18.jpg)
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, *)
![Page 19: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/19.jpg)
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?
![Page 20: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/20.jpg)
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 ??
![Page 21: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/21.jpg)
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)
![Page 22: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/22.jpg)
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
![Page 23: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/23.jpg)
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, *)
![Page 24: CS34311 The Entity- Relationship Model Part III..](https://reader034.fdocuments.in/reader034/viewer/2022051101/5a4d1b147f8b9ab059990b67/html5/thumbnails/24.jpg)
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)