ENTITY-RELATIONSHIP MODEL

The Entity-Relationship (E-R) Model

The E-R model is a detailed, logical representation of the data for an organization or business area It should be understandable to both the user and to the IT technologist The model must be as open as possible and not tied to any technology or to any particular business methodology It must be flexible enough so that it can be used and understood in practically any environment where information is modelled

The Entity-Relationship (E-R) Model

It is expressed in terms of entities in the business environment, the relationships (or associations) among those entities and the attributes (properties) of both the entities and their relationships An E-R model is normally expressed as an E-R diagram which is a graphical representation of an E-R model. It was introduced by Peter Chen in 1976.

Sample E-R Diagram

E-R Diagram Basic Symbols

Entity Relationship Attribute

E-R Diagram Terminologies

Entity a person, place, object, event, or concepts in the user environment about which the organization wishes to maintain data Entity type a collection of entities that share common properties or characteristics Entity instance a single occurrence of an entity type

E-R Diagram Terminologies

Examples of Entities: Person: EMPLOYEE, STUDENT, PATIENT Place: CITY, STATE, COUNTRY Object: MACHINE, BUILDING, AUTOMOBILE Event: SALE, REGISTRATION, RENEWAL Concept: ACCOUNT, COURSE, WORK CENTER

E-R Diagram Terminologies

Entity Type: STUDENT Entity Instances:
Student 1: 2006-167, BS-ICT, 1st Year, 1AIT Student 2: 2005-289, BSC-Accntg, 2nd Year, 2AAC Student 3: 2006-194, AB-Eco, 1st Year, 1AEC

Entity Type vs System Input, Output or User

Misconception: A common mistake is to confuse data entities with other elements of the Information System model Rule: A true data entity will have many possible instances, each with a distinguishing characteristic, as well as one or more other descriptive pieces of data.

Example: A client opening a bank account

Entities: Client, Account and Passbook (Some of you may be thinking that the Teller is an entity. Is it a source or a sink? No, he is the only one that processes the transaction.)
CLIENT opens ACCOUNT issues updates

PASSBOOK

Entity type vs System Input, Output or User

REMINDER: If we do not need to keep track of data about an ENTITY and is the person entering data and receiving the generated reports and also the user of the database then you do not have to identify it as an entity.

E-R Diagram Terminologies

Attribute is a property or characteristic of an entity type that is of interest to the organization. For example: STUDENT: Stud_No, Stud_Name, Stud_Course, Stud_Level and Stud_Section EMPLOYEE: Emp_ID, Emp_Name, Emp_Add, Emp_ Bdate, Emp_Hdate In ER diagrams place attributes name in an ellipse/oval with a line connecting it to its associated entity.

Classification of Attributes

Composite Simple (Atomic) Multivalued Derived

Composite Attributes

Is an attribute that can be broken down into component parts. For example: Address
Address

Street

City

Postal Code

Simple (or atomic) Attribute

Is an attribute that cannot be broken down into smaller components.

For example:
STUDENT - Stud_No EMPLOYEE - EMP_ID, EMP_Age

Multivalued Attribute
Is an attribute that may take on more than one value for a given instance. For example: Stud_Course: Acctng, LM, FM, ICT, Eco, PHRD, IBE, Mktng, Psych Stud_Level: 1st, 2nd, 3rd and 4th

Derived Attribute
Is an attribute whose values can be calculated from related attributed value. For example: Total fees (from adding the tuition fees and miscellaneous fees) Profit = Price * Cost

Identifier Attribute

Identifier attribute or Primary Key is an attribute (or combination of attributes) that uniquely identifies individual instances of an entity type, such as Student_ID To be a candidate identifier, each entity instance must have a single value for the attribute, and the attribute must be associated with each entity The identifier attribute is underlined, such as Student_ID

Identifier Attribute

Identify the given attributes (Composite, Simple, Multivalued & Derived )

Student_ID Age Student_Level Address Student_Name Total_Amount Outstanding_Balance E-mail_Address Net_Income Course_Schedule Course_Title

Relationships

Relationship is an association between the instances of one or more entity types. These are glue that holds together the various components of an E-R model. It is denoted by a diamond symbol. In a relational database, relationships enable you to prevent redundant data.

Relationships

For example, a student may be related to a class by being enrolled in that class. Another example is the link between mother and children. One mother may have many children, but each child has only one mother.

Relationships

A relationship between entities is given a relevant name. For example, there is a relationship between MANAGER and DEPARTMENT. A manager manages the department; on the other hand a department is managed by a manager. This leads to a relationship called "Manages" between MANAGER and DEPARTMENT.
MANAGER Manages DEPARTMENT

Relationships

There is also a relationship between AUTHOR and the BOOK. An author writes a book; on the other hand a Book is written by an Author. This leads to a relationship called "Writes" between AUTHOR and BOOK.

AUTHOR

Writes

BOOK

Relationships

The entities can be associated /connected to one another in different ways. For example, different possible and relevant relationships between BOOK STORE and BOOK(s) are as follows. A BOOK STORE orders BOOK(s) A BOOK STORE displays BOOK(s) A BOOK STORE stocks BOOK(s) A BOOK STORE sells BOOK(s) A BOOK STORE returns BOOK(s)

Degree of Relationships

The entities that are participating in a given relationship are known as participants. The degree of a relationship is the number of entity types that participate in the relationship. Thus, the relationship "writes" is of degree two because only two entities are participating in this relationship, i.e. AUTHOR and BOOK.

Types of Relationship

In E-R model, the most common relationship (with respect to degree of relationships) are:

(1) Binary relationship (2) Unary relationship (3) Ternary relationship

Binary Relationship

A relationship type of degree two is called binary relationship. A binary relationship is a relationship between the instances of two entity types. It is the most common type of relationship encountered in data modeling.

Binary Relationship

The binary relationship is further divided into:

a. One-to-one relationship b. One-to-many relationship c. Many-to-many relationship

One-to-One (1:1) Relationship:

In one-to-one relationship, two entity types are associated in a way that for each instance in First entity type, there is only one matching instance in Second entity type. On the other hand, for each instance in Second entity type, there is only one matching instance in First entity type.

One-to-One (1:1) Relationship Example:

Consider the relationship between COUNTRY and CAPITAL entities. 1 1 COUNTRY Has

CAPITAL

The above relationship shows that a country has only one capital. On the other hand, a capital belongs to only one country.

One-to-One (1:1) Relationship Example:

The sample data is given below.

Country Capital

England
Philippines China

London
Manila Beijing

One-to-One (1:1) Relationship Example:

The relationship between CHAIRPERSON and DEPARTMENT entities is given below:

1
CHAIRPERSON

1 Runs
DEPARTMENT

The above relationship shows that a chairperson runs one department. On the other hand, the department is run by only one chairperson.

One-to-Many (1:N) Relationship:

In one-to-many relationship, two entity types are associated in such a way that for each instance in First entity type, there can be many matching instances in Second entity type. On the other hand, for each instance in Second entity type, there is only one matching instance in First entity type. For example, a mother may have many children, but a child can have one-to-one mother. In the E-R diagram, Crow's paw is used to indicate many instances. Crows paw symbol:

One-to-Many (1:N) Relationship Example:

The relationship between STUDENT and TELEPHONE entities is given below: 1 STUDENT N

Has

TELEPHONE

The above relationship shows that a student may have many telephone numbers. On the other hand, a telephone number belongs to only one student.

One-to-Many (1:N) Relationship Example:

The relationship between DEPARTMENT and TEACHER entities is given below: 1 N

DEPARTMENT

Has

TEACHER

The above relationship shows that a department of a college may have many teachers. On the other hand, a particular teacher belongs to only one department.

Many-to-Many (M:N) Relationship:

In many-to-many relationship, two entity types are associated in such a way that for each instance in First entity type, there can be many matching instances in Second entity type. On the other hand, for each instance in Second entity type, there can also be many matching instances in First entity type.

Many-to-Many (M:N) Relationship Example:

The relationship between UNCLE and NEPHEW entities is shown below: N M Has NEPHEW UNCLE

The above relationship shows that an uncle may have many nephews, while a nephew may have many uncles.

Many-to-Many (M:N) Relationship Example:

The relationship between PATIENT and DOCTOR entities is given below: N M PATIENT

Checks

DOCTOR

The above relationship shows that a patient may be checked by many doctors. On the other hand, a doctor may check many patients.

Show and explain the relationship of the given entities below:

1. Entities: EMPLOYEE, PARKING SPACE; Relationship: Is Assigned 2. Entities: SUBJECT, OFFERING; Relationship: Has 3. Entities: TEACHER, SUBJECT; Relationship: Teaches 4. Entities: PERSON, PASSPORT; Relationship: Has 5. Entities: PRODUCT LINE, PRODUCT Relationship: Contains

Answer:
1. Entities: EMPLOYEE, PARKING SPACE; Relationship: Is Assigned
EMPLOYEE 1 Is assigned

PARKING SPACE

An employee is assigned to one parking space, on the other hand one parking space is allotted to only one employee.

Answer:
2. Entities: SUBJECT, OFFERING; Relationship: Has
1

N
Has OFFERING

SUBJECT

A subject can be offered many times. On the other hand, each offering belong to one subject.

Answer:
3. Entities: TEACHER, SUBJECT; Relationship: Teaches
M TEACHER Teaches N SUBJECT

A Teacher can teach many different Subjects while each Subject can be taught by many Teachers.

Answer
4. Entities: PERSON, PASSPORT; Relationship: Has
1 PERSON Has 1 PASSBOOK

One person has one passbook, on the other hand, a passbook is only belongs to one person

Answer
5. Entities: PRODUCT LINE, PRODUCT; Relationship: Contains
1 PRODUCT LINE Contains N PRODUCT

A product line may have many product, on the other hand, product belongs to only one product line.

Unary Relationship

The relationship between the instances of only one entity type (or single participant) It is also referred to as recursive relationship. This relationship has degree one.

Unary Relationship

Like binary relationship, unary relationship is also further divided into:

a. One-to-One relationship b. One-to-Many relationship c. Many-to-Many relationship

One-to-One Unary Relationship Example

The one-to-one unary relationship is represented in the similar way as one-to-one binary relationship. The recursive one-to-one relationship between the instances of DOCTOR entity type is given below:
DOCTOR Is treated

The above relationship shows that a doctor is treated by another doctor. On the other hand, a doctor treats another doctor.

One-to-One Unary Relationship Example

The recursive relationship between the instances of PERSON entity type is given below:
Is Married To

PERSON

The above relationship shows that a person is married to a person. On the other hand, a person is married by another person.

One-to-One Unary Relationship Example

Subjects may be prerequisites for other subjects.

SUBJECT

Is Prerequisite for

One-to-Many Unary Relationship

The one-to-many unary relationship is shown in figure below. This relationship is named as 'Manages' that associates employees of an organization with another employee who is their manager.

EMPLOYEE

Manages

Many-to-Many Unary Relationship

The many-to-many unary relationship "Treated-By" is given below. It represents the situation in which doctors give treatments to other doctors (doctors as patients).

DOCTOR

Treated By

The above relationship shows that a doctor is treated by many other doctors. On the other hand, a doctor treats many other doctors.

Ternary Relationship

A ternary relationship is a simultaneous relationship among instances of three entity types. This type of relationship has degree three.

Ternary Relationship
CLASS

TEACHER

Teaches

STUDENT

The above ternary relationship "Teaches" can be read as "Many teachers may teach many classes with many students".

Ways of Classifying Relationships

Relationships

Number of Entity Types

1 Unary 2 Binary 3 Ternary N - ary

Degree

Cardinality
1:1 1:N M:N

Modality
Optional Mandatory

Cardinalities of Relationships

Cardinality is defined as the number of instances of one entity type (entity A) that can be associated with each instance of another related entity type (entity B). Suppose there are two entity types A and B that are connected by a relationship R. If there are no cardinality constraints on R, then any number of instances of A can be associated with any number of instances of B.

Cardinalities of Relationships

Usually there are cardinality constraints such as: If there is one-to-one relationship between A and B, then each instance in A will be associated with exactly one instance in B. Conversely each instance in B will be associated with exactly one instance in A.

Cardinalities of Relationships

If there is one-to-many relationship between A and B, then each instance in A will be associated with many instances in B. On the other hand, each instance in B will be associated with exactly one instance in A. If there is many-to-many relationship between A and B, then each instance in A will be associated with many instances in B. On the other hand, each instance in B will also be associated with many instances in A.

Cardinalities of Relationships

The cardinality of one is denoted by a small vertical line ( | ) on the relationship line, next to the first entity type or before the second entity type. Similarly, the cardinality of many is denoted by crow's paw symbol.

Cardinalities of Relationships

For example, a department may have many teachers. On the other hand, a teacher belongs to one department.

DEPARTMENT

Has

TEACHER

The relationship between DEPARTMENT and TEACHER is shown above.

Modality of Relationship

The modality defines the nature of relationship as either it is: optional or mandatory. If the minimum instance in one entity is zero for an instance of another related entity, then the relationship is called optional. The optional relationship is denoted by small circle 'O' on the relationship line.

Modality of Relationship

Similarly, if the minimum instance in one entity is one for an instance of another related entity, then the relationship is referred to as mandatory. It is denoted by a small vertical line ' | ' on the relationship line. If minimum and maximum cardinalities are both one, it is known as Mandatory One Cardinality.

Modality of Relationship

For example, a relationship between STUDENT and TELEPHONE entities given below, which shows 'one optional' and 'one mandatory' cardinality.
STUDENT

Has

TELEPHONE

Figure shown: One Optional, One Mandatory Cardinality

Modality of Relationship

In the relationship STUDENT Has TELEPHONE, each instance of STUDENT entity may be zero or many associated instances in TELEPHONE entity. On the other hand, each instance of TELEPHONE belongs to exactly one instance in STUDENT entity.

Modality of Relationship
1. In the relationship "TEACHER Teaches CLASS", each teacher may teach one or many classes. On the other hand, each class is taught by only one teacher, i.e. each instance of Class belongs to exactly one Teacher. 2. In the relationship "PERSON Is Married To PERSON", there is an optional zero or one cardinality in both directions, since a person may or may not be married.

Cardinality Notations

Mandatory One (1:1)

One instance is to only One instance

Mandatory Many (1:M)

One instance is to Many instances

Optional One (0:1)

Zero instance is to One instance

Optional Many (0:M)

Zero instance is to Many instances

Skills Wrap-Up

Identify the degree, cardinality and modality of the given relationship (following slides)

Skills Wrap-Up
1. Degree

PERSON

Has

Birth Certificate

Skills Wrap-Up
2. Degree

PRODUCT LINE

Contains

PRODUCT

Skills Wrap-Up
3. Degree
DEPARTMENT

Has

TEACHER

4. Degree
UNCLE

Has

NEPHEW

Skills Wrap-Up
5. Degree
CHAIRPERSON

Runs

DEPARTMENT

6. Degree
EMPLOYEE Is assigned PARKING SPACE

Skills Wrap-Up
7. Degree
PATIENT

Checks

DOCTOR

How to make ERDs?

1.

2.

3.

4.

Identify the entities. (Source or sink of data) Identify the relationships between two entities. Glue the entities that interacts with one another. Use verbs in the relationships. (Do not hesitate to put another relationship if necessary.) Write the attributes for each entity. Underline the identifier/primary key. Draw the cardinalities between entities.

Sample of an ERD: Ordering System of a Furniture company

1.

Identify ENTITIES:
Customer a person or organization who has ordered or might order products Product a type of furniture made which may be ordered by customers Order the transaction associated with the sale of one or more products to a customer and identified by a transaction number from sales or accounting

Sample of an ERD: Ordering System of a Furniture company

1.

Identify ENTITIES:
Item (Raw materials) a type component which goes into making one or more products Supplier another company that may provide items to the Furniture company Shipment (Delivery) items received in the same package by the organization from the supplier

Sample of an ERD: Ordering System of a Furniture company

2.

Identify RELATIONSHIPS: A CUSTOMER may submit any number of ORDERS. However, each ORDER must be submitted by exactly one CUSTOMER. An ORDER must requests one (or more) PRODUCTS. A given PRODUCT may not be requested or may be requested many ORDERS. Each ITEM must be used in at least one PRODUCT in many products. A given PRODUCT must be used in at least one (or more) ITEM.

Sample of an ERD: Ordering System of a Furniture company

2.

Identify RELATIONSHIPS:
A SUPPLIER may supply many ITEMS. Each ITEM is supplied by any number of SUPPLIERS. A SUPPLIER may send many SHIPMENTS and each SHIPMENT must be sent by exactly one SUPPLIER. A SHIPMENT must include one or more ITEMS. An ITEM may be included on several SHIPMENTS.

Sample of an ERD: Ordering

sends

System of a Furniture company

SUPPLIER

supplies

SHIPMENT

includes

ITEM

CUSTOMER

Used in

submits

PRODUCT

requests

ORDER

Example 2: Prepare an ERD for a real estate firm that lists property for sale. The following describes this organization:

The firm has a number of SALES OFFICE in several states. Attributes of sales office include Office_Number (identifier) and Location. Each sales office is assigned one or more EMPLOYEES. Attributes of employees include Employee_ID (identifier) and Employee_Name. An employee must be assigned to only one sales office. For each sales office, there is always one employee assigned to manage that office. An employee may manage only one sales office to which she is assigned. The firm lists PROPERTY for sale. Attributes of property include Property_ID (identifier) and Location. Components of Location include Address, City, State and Zip_Code. Each unit of property must be listed with one (and only one) of the sales offices. A sales office may have any number of properties listed, or may have no properties listed. Each unit or property has one or more OWNER. Attributes of owners are Owner_ID (identifier) and Owner_Name. An owner may own one or more units of properties listed.

ERD for Example 2:

Office_Number Location

Note: The Firm does not have attributes mentioned in the problem so it is not an entity but it is the whole organization itself. Address
Property_ID Listed

Location

City State Zip_Code

SALES OFFICE

PROPERTY

manages

Is assigned

has

EMPLOYEE
Employee_ID Employee_Name

OWNER
Owner_ID Owner_Name

Thank you!

Prepared By: Prof. LRQ Natividad