CS3431 1

The Entity-Relationship Model

Part 4.

CS3431 2

Coming up with a good design for your application

Guidelines via examples

CS3431 3

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 4

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 5

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?

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 dnamebudgetdid

Employees Departments

ssn lot

dbudgetsince

(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 dnamebudgetdid

Employees Departments

ssn lot

budgetsince

(0:1)

Entity vs. Relationship

What if a manager gets a separate discretionary budget for each dept ?

Manages

name dnamebudgetdid

Employees Departments

ssn lot

budgetsince

(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 dnamebudgetdid

Employees Departments

ssn lot

dbudgetsince

Entity vs. Relationship

Discretion-ary budget of manager that covers all managed depts?

Manages2

name dnamebudgetdid

Employees Departments

ssn lot

dbudgetsince

dnamebudgetdid

DepartmentsManages2

Employees

namessn lot

since

Managers dbudget

ISA

This fixes theproblem!

CS3431 13

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 14

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 15

Good Design: Try to avoid redundancy

Any Redundant attribute ?Attribute dNum is redundant

Person

pNumber

pName

Dept

dNumber

WorksFor

(1, 1) (0, *)

dNum

CS3431 16

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 17

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)