CXB 3104 Advanced Database Systems

Entity-Relationship (E-R) Modeling

Peter Chen introduced the E-R model in 1976 Has many variations

Lecture 2 - ERD

Entity-Relationship (E-R) Modeling

Depicting Entities and Attributes

Entity-Relationship (E-R) Diagram

A detailed, logical representation of the entities, associations and data elements for an organization or business

Notation uses three main constructs

Data entities Relationships Attributes

10.3
3 4

Entity
A person, place, object, event or concept in the user environment about which the organization wishes to maintain data Represented by a rectangle in E-R diagrams Naming Conventions should follow an established standard E.g. capitalize the names of entities

Entity

Attribute
also termed as Properties they are characteristics of an entity Can be included as named bubbles attached to the entity multi-valued attributes are often shown in a diagram by the use of a double circle multi-valued attributes may have multiple values

Attribute

Primary Key Attribute

denoted by underlining an attribute usually a single attribute may be a comprised of a concatenation of attributes primary key selection criteria

Key should not change its value over the life of each entity instance. Key should be guaranteed to not be NULL. Avoid intelligent-keys (stored data as part of a key such as a code). Substitute single-attribute surrogate keys for large composite keys.
9

Multi-valued Attributes

During database modeling, it is often desirable to decompose this situation into two separate entities since a multi-valued attribute often results when we capture only a single data attribute of what would otherwise be modeled as an entity.

10

Multi-valued Attributes

Relationship
An association between the instances of one or more entity types that is of interest to the organization Association indicates that an event has occurred or that there is a natural link between entity types Relationships are always labeled with verb phrases

11

12

Naming and Defining Relationships

Relationship name is a verb phrase Avoid vague names Guidelines for defining relationships Definition explains what action is being taken and why it is important Give examples to clarify the action Optional participation should be explained Explain reasons for any explicit maximum cardinality

10.14
13

Naming and Defining Relationships

Guidelines for defining relationships

Explain any restrictions on participation in the relationship Explain extent of the history that is kept in the relationship Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

14

Degree of Relationship
Degree Number of entity types that participate in a relationship Three cases Unary A relationship between two instances of one entity type Binary A relationship between the instances of two entity types Ternary A simultaneous relationship among the instances of three entity types Not the same as three binary relationships

Example relationships of different degrees

15

16

The two models

Binary Relationship
1

Chen Model
1 to represent one. M to represent many
M

involves two entities. degree is equal to 2 because two entities

participate in the relationship

Crows Foot
One many Mandatory one , means (1,1)

One or many

17

18

Unary Relationships

Ternary Relationships

represents an association between occurrences of a single entity.

association between occurrences of three entities at the same time

19

20

Cardinality

Weak Entity
an occurrence of one entity cannot exist unless

Maximum cardinality
expresses the number of occurrences of one entity related to another entity. E,g, 1:1, 1:M, M:N

there is an occurrence of a related entity.

A weak entity set is indicated by a doubly-outlined

box.

Minimum cardinality
expresses the number of occurrences of one entity related to another entity. expresses how many occurrences of one entity must, at a minimum, be associated with occurrences of another entity
21 22

Examples

Examples cont

23

24

Example COMPANY Database

Example COMPANY Database (Contd.)

We store each EMPLOYEEs social security number, address, salary, sex, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of DEPENDENTs. For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee.
26

We need to create a database schema design based on the following (simplified) requirements of the COMPANY Database: The company is organized into DEPARTMENTs. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location.
25

Initial Design of Entity Types for the COMPANY Database Schema

Based on the requirements, we can identify four initial entity types in the COMPANY database: DEPARTMENT PROJECT EMPLOYEE DEPENDENT Their initial design is shown on the following slide The initial attributes shown are derived from the requirements description

Slide 3- 27

Initial Design of Entity Types:

EMPLOYEE, DEPARTMENT, PROJECT, DEPENDENT

28

Problem with ER model

Chasm Trap
A model suggests the existence of a relationship between entities, but the pathway does not exist between certain entity occurrences. It occurs where there is a relationship with partial participation, which forms part of the pathway between entities that are related.

Chasm trap Fan trap

29

30

Chasm trap - Example

Chasm trap - Example

Cannot tell which branch staff S0003 works at.

31

32

Chasm trap - Solution

Chasm trap - Solution

33

34

Fan trap - Example

A fan trap occurs when a model represents a relationship between entity types, but the pathway between certain entity occurrences is ambiguous. It occurs when 1:m relationships fan out from a single entity.

Fan trap - Example

35

36

Fan trap - Example

Fan trap - Solution

Cannot tell which member of staff uses car SH34

37 38

Fan trap - Solution

39