Database Modeling Using the Entity-Relationship Model (Continued)

Database ManagementCOP4540, SCS, FIU

Database Modeling Using the Entity-Relationship Model

(Continued)


Usage of Weak Entities

• Weak Entity can be used when converting a n-ary relationship to a number of binary relationships.

• The basic algorithm can be found in the previous lecture note.

• The additional ENTITY CLASS is actually a weak entity.


An Example of Ternary Relationship

SUPPLIER PROJECT

PART

SNameProjName

PartNo

SUPPLY

Quantity


Converted E-R Diagram

SUPPLIER PROJECT

PART

SNameProjName

PartNo

Quantity

SUPPLYSS SPJ

SP

1 N 1N

1

N


What if defining a cardinality constraint

SUPPLIER PROJECT

PART

SNameProjName

PartNo

SUPPLY

Quantity

1 M

N


Converted E-R Diagram

SUPPLIER PROJECT

PART

SNameProjName

PartNo

Quantity

SUPPLYSS SPJ

SP

1 1 1N

1

N


Design Principles

• Faithfulness

• Avoiding redundancy

• Keep it simple

• Picking the right kind of element


Faithfulness

• Include everything needs to be described.

• Avoid meaningless descriptions.

• Enforce as many constraints as possible.– Cardinality Ratios.– Participation Constraints – Existence Dependency.


Cardinality Ratios

• The cardinality ratios for binary relationships– 1:1, 1:N, N:1, and M:N

• Attributes of 1:1 relationship types can be migrated to either of the participating entity types.

• Attributes of 1:N or N:1 relationship types can be migrated only to the entity type at N-side of the relationship.

• Attributes of M:N relationship types must be specified as relationship attributes.


Examples

EMPLOYEE Manages1 1

Starting date

DEPARTMENTEMPLOYEE Manages1 1

Starting date

DEPARTMENTEMPLOYEE Manages1 1

Starting date

DEPARTMENT


Examples

PROJECTEMPLOYEE Works_on 1N

Hours

PROJECTEMPLOYEE Works_on1N

Hours

Note: IF we assumed that each employee can only work on one project, and theremay be many employees working on the same project, THEN:The attribute Hours can be migrated to EMPLOYEE, but not PROJECT.


Examples

EMPLOYEE Works_onM N

PROJECT

Hours

Note: IF we assume that each employee may work on multiple projects at the same time, and there may be many employees working on the same projects, THEN:The attribute Hours can not be migrated to either PROJECT orEMPLOYEE.


Participation Constraints

• It specifies whether the existence of an entity depends on its being related to another entity via relationship type.

• Two types– total participation (Using double line connecting the

participating entity type)– partial participation

• Total participation is also called Existence Dependency.


Examples

DEPARTMENTEMPLOYEE

Works_for 1N

Note: IF we assume that every employee should be assigned to certain department.

THEN:There is a total participation constraint defined on EMPLOYEE via therelationship Works_for.


Examples

DEPARTMENTEMPLOYEE

Works_for 1N

Note: IF we assume that each department should have at least one employeebeing assigned, THEN:There is a total participation constraint defined on DEPARTMENT via therelationship Works_for.


Examples

DEPARTMENTEMPLOYEE

Manages1 1

Note: IF we assume that should have exactly one manager, but not every employee could be a manager of certain department, THEN:There is a total participation constraint defined on DEPARTMENT via therelationship type Manages. However, EMPLOYEE partially participates the relationship type Manages.


Alternative Notations for Constraints

• A pair of integer (min, max) with each participation of entity type E in a relationship type R. ( max min 0, max 1)

• min: at least min; max: at most max

• min = 0 implies partial participation.

• min 1 implies total participation.


Examples

DEPARTMENTEMPLOYEE

Works_for (4,N)(1,1)

This example implies that each employee is assigned to one and only one department. Each department has at least four employees, and there is no upper limit of the number of employees in a department.

DEPARTMENTEMPLOYEE

Works_for 1N


Examples

DEPARTMENTEMPLOYEE Manages(0,1) (1,1)

What does this example imply?

DEPARTMENTEMPLOYEE

Manages1 1



Examples

DEPENDENT

name sex birthdate relationship

EMPLOYEE Dependents_of(0,N)

(1,1)

SSN



Avoiding Redundancy

• Problem with redundancy– Wastes space.– Encourages inconsistency.

• Principle: describe and store everything once only.

• Intuition: something is redundant if it could be hidden from view, and you could still figure out what it is from the other data.


Examples

BEERS MANFSManfBy

namename address

BEERS

namemanf

manfadd

Question: Which one is better?


KISS: Keep It Simple, Student

• Avoid intermediate concepts if unnecessary.

BEERS MANFSManfBy

namename

Database Modeling Using the Entity-Relationship Model (Continued)

Documents

Transcript of Database Modeling Using the Entity-Relationship Model (Continued)