CS34311 The Entity- Relationship Model Part III.

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

CS34313 Cardinality Constraints

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

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 ?

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

CS34317 Possible Solution

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

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

CS343110

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

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

CS 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

CS 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)

CS 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

CS Coming up with a good design for your application Guidelines via examples

CS 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)

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

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

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

CS Good Design: Determine correct cardinality constraints (or)

CS Good Design: Try to avoid redundancy Any Redundant attribute ? Attribute dNum is redundant

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

CS 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)