CS34311 The Entity- Relationship Model Part 4.
CS34312 Coming up with a good design for your application Guidelines via examples
CS34313 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)
CS34314 Coming up with a good design for your application Give good names to entity types, relationship types, attributes and roles
CS34315 Good Design: Attribute or entity type? Should we represent something as an attribute or entity type? (or) How should dept be represented?
Design Choice: Entity vs. Attribute Should address be an attribute of Employees or an entity (connected to Employees by a relationship)?
Entity vs. Attribute Depends upon the use we want to make of address information and its semantics : If we have several addresses per employee and/or addresses are shared by many people, then address should be an entity If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic). And, other trade-offs
Entity vs. Relationship? Manages name dname budget did Employees Departments ssn lot dbudget since (0:1)
Entity vs. Relationship What if a manager gets a separate discretionary budget for each dept ? What if a manager gets a discretionary budget that covers all managed depts? Manages name dname budget did Employees Departments ssn lot budget since (0:1)
Entity vs. Relationship What if a manager gets a separate discretionary budget for each dept ? Manages name dname budget did Employees Departments ssn lot budget since (0:1)
Entity vs. Relationship What if a manager gets a discretionary budget that covers all managed depts? Redundancy: dbudget stored for each dept managed by manager. Misleading: Suggests dbudget associated with department-mgr combination. Manages2 name dname budget did Employees Departments ssn lot dbudget since
Entity vs. Relationship Discretion -ary budget of manager that covers all managed depts? Manages2 name dname budget did Employees Departments ssn lot dbudget since dname budget did Departments Manages2 Employees name ssn lot since Managersdbudget ISA This fixes the problem!
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 Often many ways to model a given scenario! Not one correct ER design Analyzing alternatives can be tricky, especially for a large enterprise. 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)