ERD

ERDEntity (Rectangle) and Attributes (Oval)

ERD

Attributes Types

Composite VS Simple:

Simple: is not divisible (first name)?

Composite: Divided into smaller independent subparts (Address)

ERDSingle-Valued vs Multivalued Attributtes (Double oval)

Age single value

Color of a cars (white & black)

should have upper and lower limit

two colours per car at most

ERD

Derived vs Stored attribute

Age could be derived from birthdate and today’s date

Birth date attribute is stored attribute

ERD

Null Values: Not applicable for this person

Complex attributes: nested multivalued or composite attribute

EntityDB contains group of entities that are similar

Entity share the same attributes but each entity has its own value

Entity type: defines a collection of entities that have the same attributes

Each entity type is described by its name and attributes

Entity

Key Attributtes:

Entity has one or more attribute with distinct values

Each key attribute has underline

Relationships

Relationswhen an attribute of one entity type refers to another entity type:

A relationship exists.

For example:

Manager at DEPARTMENT refers to an employee who manages the department

Controlling Department At PROJECT refers to the department that controls the project;

RelationsExamples Contin.

Supervisor at EMPLOYEE refers to another employee (the one who supervises this employee);

Department at EMPLOYEE refers to the department for which the employee works

In the ER model, these references should not be represented as attributes but as relationships

!

Relationships types, sets and InstanceA relationship type R:

Among n entity types E1, E2, ..., En

Defines a set of associations (or a relationship set) among entities from these entity types.

R is a set of relationship instances ri

Each ri associates n individual entities (e1, e2, ..., en)

Each entity ej in ri is a member of entity set Ej, 1 =< j < =n.

Each relationship instance ri in R is an association of exactly one entity from each participating entity type

Relationships types, sets and InstanceA relationship type work for between:

Employee & Department

Associates each employee with the department that he works in the corresponding entity set

Each relationship instance in Works_For associates one EMPLOYEE entity and one DEPARTMENT entity

Employees e1, e3, and e6 work for department d1

Employees e2 and e4 work for department d2

Employees e5 and e7 work for department d3

E1

E2

R

Relationship set

Relationship Instance

Relationships types, sets and Instance

Relationship types are displayed as diamond-shaped boxes,

Connect participating entities by straight lines.

The relationship name is displayed in the diamond-shaped box

Relationship Degree, Role Names, and Recursive Relationships

Degree of Relationship:

Number of entity in a relationship

Work_For is of order 2 (Binary)

Relation of order 3 called ternary

Supply Relationship is ternary

Each relationship instance ri associates three entities:

A supplier s,

A part p, and

A project j

s supplies part p to project j

Relationship Degree, Role Names, and Recursive Relationships

Role Names

Each entity type in a relationship plays a role in the relationship.

The role name signifies the role that a participating entity from the entity type plays in each relationship instance, and

Helps to explain what the relationship means.

In WORKS_FOR relationship type,

EMPLOYEE plays the role of employee or worker and

DEPARTMENT plays the role of department or employer.

Relationship Degree, Role Names, and Recursive Relationships

Role Names

It is not important to write the role name if:

All participant in entity type play the same role

Work_For:

All employee work as workers or employees at the department

No single employee could play any other role in this relationship

Relationship role name

Relationship Degree, Role Names, and Recursive Relationships

Recursive relationship

Same entity type participates more than once in a relationship type in different roles.

Hence, the role name becomes essential for distinguishing the meaning of the role for each participating

The SUPERVISION relationship type relates an employee to a supervisor,

Both employee and supervisor entities are members of the same EMPLOYEE entity set.

The EMPLOYEE entity type participates twice in SUPERVISION:

In the role of supervisor (or boss), and

In the role of supervisee (or subordinate).

Each instance accept two roles

Supervisor

employee

e1 supervise e2

Constraints on Binary Relationship Types

Specifies the maximum number of relationship instances that an entity can participate in.

For example, in the WORKS_FOR binary relationship type, DEPARTMENT:EMPLOYEE is of cardinality ratio 1:N:

Each department can be related to (employs) any number of employees -N- but an employee can be related to (work for) only one department.

The possible cardinality ratios for binary relationship types are:

1:1: Manage relationship

1:N, N:1, and

M:N Works_On project

1- Cardinality Ratios.

1:1 Relationship

Constraints on Binary Relationship Types

Specifies the minimum number of relationship instances that an entity can participate in.

Has Two types:

Total and

Partial

2- Participation Constraints

Constraints on Binary Relationship Types

Total participate example:

If a company policy states that:

Every employee must work for a department, then

An employee entity can exist only if it participates in at least one WORKS_FOR relationship instance.

Every entity in the total set of employee entities must be related to a department entity via WORKS_FOR.

Total participation is also called existence dependency.

Constraints on Binary Relationship Types

Partial participate example:

In Manage relation:

Not every employee manage a department

The participation of EMPLOYEE in the MANAGES relationship type is partial

Some or part of the set of employee entities are related to some department entity via MANAGES, but not necessarily all.

Partial participant

Constraints on Binary Relationship Types

The cardinality ratio and participation constraints, taken together, called the structural constraints of a relationship type.

Total participation (or existence dependency) is displayed as a double line connecting the participating entity type to the relationship.

Partial participation is represented by a single line

Weak entity

Entity that dont has key attributtes belongs to it

Entities belonging to a weak entity type are identified by:

Being related to specific entities from another entity type in combination with one of their attribute values.

We call this other entity type the identifying or owner entity type

The relationship type that relates a weak entity type to its owner the identifying relationship of the weak entity type.1

Weak entity

A weak entity type always has a total participation constraint (existence dependency)

With respect to its identifying relationship because

A weak entity can not be identified without an owner entity.

Weak entity is represented as double rectangle

Identifiny relation has double diamond in ER

!

Total Participant

Weak entity

Identifing relation

Cardinality