1. CS34311 The Entity- Relationship Model Part III.

2. CS34312 Cardinality Constraints (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

3. CS34313 Cardinality Constraints

4. CS34314 ER Model Constraints Summary Key Constraints Cardinality Constraints Expressed using (min, max) Binary relationship types are called: 1:1 1:many many:many

5. CS34315 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 ?

6. CS34316 Possible Solution Student sNumber sName Course cNumber title Is Taking Professor pNumber pName Is Teaching GradStudent gSNumber gSName Is TAFor

7. CS34317 Possible Solution

8. CS34318 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

9. CS34319 Student GradStudent Course sName sNumber ISA UGStudent Is TAFor cNumbertitle Is Taking programyear Professor Is AdvisedBy pNumberpName

10. CS343110

11. CS343111 ISA Relationship Student sNamesNumber ISA UGStudent year Questions: 1.Keys for supertypes and subtypes ? 2.Attributes of types? 3.Cardinalities on relationship?

12. CS343112 ISA Relationship Notes: Key for subtype is same as key for supertype Subtypes can have additional attributes Implicit 1:1 relationship

13. CS343113 Student GradStudent sName sNumber ISA UGStudent programyear Professor Is AdvisedBy pNumberpName (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

14. CS343114 Weak Entity Types The Courses offered by a Dept are identified by Cnumber Course is weak entity type Its identifying relationship is Offers Its identifying entity type is Dept Note: Cardinality of weak entity type in a identifying relationship type is (1, 1)

15. CS343115 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

16. CS343116 Coming up with a good design for your application Guidelines via examples

17. CS343117 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)

18. CS343118 Coming up with a good design for your application Give good names to entity types, relationship types, attributes and roles

19. CS343119 Good Design: Attribute or entity type? Should we represent something as an attribute or entity type? (or) How should dept be represented?

20. CS343120 KISS Principle: Keep It Simple Stupid Do not introduce unnecessary entity types (or) Is Entity type Contract Un-necessary ??

21. CS343121 Good Design: Determine correct cardinality constraints (or)

22. CS343122 Good Design: Try to avoid redundancy Any Redundant attribute ? Attribute dNum is redundant

23. CS343123 Good Design: Try to Avoid redundancy Any Redundant relationship type ? Relationship Type IsObtainedBy is redundant

24. CS343124 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)