Database Modeling Using the Entity-Relationship Model (Continued)

Download Presentation

Database Modeling Using the Entity-Relationship Model (Continued)

Loading in 2 Seconds...

- 60 Views
- Uploaded on
- Presentation posted in: General

Database Modeling Using the Entity-Relationship Model (Continued)

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Database Modeling Using the Entity-Relationship Model(Continued)

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

SName

ProjName

Quantity

SUPPLY

PartNo

SUPPLIER

PROJECT

PART

SName

ProjName

Quantity

SUPPLY

SP

SS

SPJ

PartNo

N

1

N

1

SUPPLIER

PROJECT

N

1

PART

SName

ProjName

Quantity

SUPPLY

PartNo

1

M

SUPPLIER

PROJECT

N

PART

SName

ProjName

Quantity

SUPPLY

SP

SPJ

PartNo

N

1

1

1

SUPPLIER

PROJECT

SS

N

1

PART

- Faithfulness
- Avoiding redundancy
- Keep it simple
- Picking the right kind of element

- Include everything needs to be described.
- Avoid meaningless descriptions.
- Enforce as many constraints as possible.
- Cardinality Ratios.
- Participation Constraints
- Existence Dependency.

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

Starting date

Starting date

Starting date

Manages

DEPARTMENT

EMPLOYEE

1

1

Manages

DEPARTMENT

EMPLOYEE

1

1

Manages

DEPARTMENT

EMPLOYEE

1

1

Hours

Hours

Works_on

Works_on

N

1

EMPLOYEE

PROJECT

1

N

EMPLOYEE

PROJECT

Note: IF we assumed that each employee can only work on one project, and there

may be many employees working on the same project, THEN:

The attribute Hours can be migrated to EMPLOYEE, but not PROJECT.

Hours

Works_on

EMPLOYEE

PROJECT

N

M

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 or

EMPLOYEE.

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

Works_for

N

1

DEPARTMENT

EMPLOYEE

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

THEN:

There is a total participation constraint defined on EMPLOYEE via the

relationship Works_for.

Works_for

Examples

N

1

DEPARTMENT

EMPLOYEE

Note: IF we assume that each department should have at least one employee

being assigned, THEN:

There is a total participation constraint defined on DEPARTMENT via the

relationship Works_for.

Examples

1

1

Manages

DEPARTMENT

EMPLOYEE

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 the

relationship type Manages. However, EMPLOYEE partially participates the relationship type Manages.

- A pair of integer (min, max) with each participation of entity type E in a relationship type R. ( maxmin 0, max 1)
- min: at least min; max: at most max
- min = 0 implies partial participation.
- min 1 implies total participation.

Works_for

Works_for

(1,1)

(4,N)

DEPARTMENT

EMPLOYEE

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.

N

1

DEPARTMENT

EMPLOYEE

(0,1)

(1,1)

DEPARTMENT

Manages

EMPLOYEE

What does this example imply?

1

1

Manages

DEPARTMENT

EMPLOYEE

What does this example imply?

Dependents_of

DEPENDENT

sex

birthdate

(0,N)

EMPLOYEE

(1,1)

SSN

name

relationship

What does this example imply?

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

name

name

address

BEERS

ManfBy

MANFS

name

manf

manfadd

BEERS

Question: Which one is better?

- Avoid intermediate concepts if unnecessary.

name

name

BEERS

ManfBy

MANFS