1. Data Modeling Using the Entity-Relationship Model

2. Contents Introduction Database Design Process
An example of Database Application
Entity Types, Entity Sets, Attributes and Keys
Relationships, Relationship Types, Roles and Structural Constraints
Weak Entity Types
ER Diagrams, Naming Conventions and Design Issues
Ref: Chapter 3, Navathe

3. 1. Introduction
Conceptual modeling is an important phase in designing a successful database application.
Database application: which refers to particular database, e.g. BANK.

4. 2. Database Design Process

5. Requirement collection and analysis:
interviewing prospective database users to understand and document their data requirements.
Specifying known functional requirements (user defined operation that will be applied to the database and they include both retrievals and update) of the application.
Conceptual design:
Creating conceptual schema for the database using high level conceptual data model.
Conceptual schema is a concise description of data requirements of the user and includes detailed descriptions of the entity type, relationships and constraints.
Reference to ensures all users’ data requirements are meet and that the requirements do not include conflicts.
This enables database designers to concentrate on specifying the properties of the data rather than storage details.

6. Logical Design or Data modeling:
Actual implementation of database design using commercial DBMS.
Uses relational or object database model.
Result is a database schema in the implementation data model of the DBMS.
Physical Design:
Specify internal storage structures, access paths and file organization for the database files.
Application programs are designed and implemented as database transaction corresponding to the high-level transaction specifications.

7. 3. An example of Database Application
Database Application: Company
Requirements: Keeps track of a company’s employees, department, and projects
Departments
Unique name & number
A particular employee manages a department
Start date when the manager began managing
Department may have several locations
Projects
Single location
Controlled by a department

8. Employees Dependents Name SSN (IRD) Address Salary, sex & birth date
Assigned to one department, but may work on several projects
Track number of hours per week that an employee works on each project
Track the direct supervisor of each employee
Dependents
First name
Sex & birth date
Relationship to employee

10. 4. Entity Types, Entity Sets, Attributes and Keys
Entities and Attributes
Entity Types, Entity Sets, Keys and Value Sets
Initial conceptual design of the Company database
Entity:
which is a “thing” in the real world with an independent existence
It may be an object with a physical existence, e.g. person, car, house or employee.
It may be an object with a conceptual existence, e.g. a company, a job, or an university course.
Attribute:
The particular properties that describe entity, e.g. employee entity may be described by name, age, address, salary and job.
Attribute value

11. Types of Attributes: Entity Types:
Composite / Simple (Atomic): Address
Single-valued/ Multivalued: age / college degrees
Stored/ Derieved: Birth date / age
Null: e.g. apartment number, Null can also be used if we do not know the value of an attribute for a particular entity (e.g. Home phone)
Complex Attributes: Nesting composite and multivalued attribute in an arbitrary way. E.g. Attribute AddressPhone for PERSON entity
{AddressPhone({Phone(AreaCode, PhoneNumber)}, Address(StreetAddress(Number, Street, ApartmentNumber), City, State, Zip))}
Entity Types:
Collection or set of entities that have the same attributes.
Represented in ER diagram as a rectangular box enclosing the entity type name.
Attributes are enclosed in ovals, multivalued attribute are displayed in double ovals.
It describes the schema or intension for a set of entities that share the same structure.

12. Key Attributes of an Entity Type:
Entity Set:
The collection of all entities of a particular type in the database at any point in the time.
E.g. The set of all persons having an account at a bank is the entity set CUSTOMER. Set of all accounts in a particular bank is the entity set ACCOUNT.
Key Attributes of an Entity Type:
Uniqueness constraint on attributes
Attribute whose values are distinct for each individual entity in the collection.
Composite attribute as a key attribute.
In ER diagram key attribute are underlined.
Weak entity type: entity type with no key.
Value Sets (Domain) of attribute:
Set of values that may be assigned to attribute. E.g. Age (20-70), name(alphabetic and space)

13. Initial conceptual design of the Company database

14. Problem
Composite and multivalued attributes can be nested to any number of levels. Suppose we want to design an attribute for a STUDENT entity type to keep track of previous college education. Such an attribute will have one entry for each college previously attended and each such entry will be composed of college name, start and end dates, degree entries, and transcript entries. Each degree entry contains the degree name and the month and year the degree awarded, and each transcript entry contains a course name, semester, year, and grade. Design attribute to hold this information.

15. Relationships, Relationship Types, Roles and Structural Constraints
Introduction
Relationship Types, Sets and Instances
Relationship Degree, Role Names and Recursive Relationships
Constraints on Relationship Types
Attributes of Relationship Types

16. Introduction
Attribute of one entity type refers to another entity type.
The attribute Manager of DEPARTMENT refers to an employee who manages the department Department.
The attribute ControllingDepartment of PROJECT refers to the department that controls the project.
The attribute Supervisour of EMPLOYEE refers to another employee.
The attribute Department of EMPLOYEE refers to the department for which the employee works.
In the ER model, references (between entity types) should be represented as relationships, not attributes.
A relationship is an association among several entities.
Relationship will be shown as diamond-shaped boxes in the ER diagram

17. Relationship Types, Sets and Instances
A relationship type R among n entity types E1, E2, . . ., En defines a set of associations or a relationship set among entities from these types.
As for entity types and entity sets, relationship type and its corresponding relationship set are customarily referred to by the same name R.
Each of the entity types E1, E2, . . .,En is said to participate in the relationship type R.
Relationship set is a set of relationships of the same type.

18. CUSTOMER : ACCOUNT ; CustAcct
ri – relationship instances
CUSTOMER : ACCOUNT ; CustAcct

19. Relationship Degree, Role Names and Recursive Relationships
Degree of Relationship Type: number of participating entity type
WORKS_FOR relationship is of degree 2.
Relationship type of degree 2 is called binary and degree 3 is called ternary.

20. Relationships as Attributes:
WORKS_FOR relationship type represents attributes Department of EMLOYEE or Employees of DEPARTMENT.
Role Names and Recursive Relationships:
Each entity type that participates in a relationship type plays a particular role in the relationship.
Role Name
Signifies the role of the participating entity
Helps to explain what the relationship means
Not necessary where participating entity types are distinct (WORKS_FOR)
Recursive Relationships: Participation of the same entity types more than once in a relationship type.

21. 1 – Supervisor
2 - Supervisee

22. Constraints on Relationship Types:
Cardinality Ratio: Cardinality specifies the number of
relationship instances that an entity can participate in
1:N (DEPARTMENT : EMPLOYEE ; WORKS_FOR)
1:1 (EMPLOYEE : DEPARTMENT; MANAGES)
M:N (EMPLOYEE : PROJECT ; WORKS_ON)

23. Participation Constraints and Existence Dependencies:
Specifies whether the existence of an entity depends on its being related to another entity via the relationship type
Types
Total (Existence dependency)
If every employee must work for a department, then an employee entity can exist only if it participates in a WORKS_FOR relationship.
Every entity in “the total set” of employee entities must be related to a department entity by the WORKS_FOR relationship.
Total participation is also called existence dependency.

24. Total participation is shown as a double line
Partial
Every employee is not expected to manage a department.
A “part of the set” of employees are related to a department by the MANAGES relationship.
Total participation is shown as a double line
Partial participation is shown as a single line
Attributes of Relationship Types
Relationship types can have attributes
Consider the number of hours per week that an employee works on a particular project
Hours attribute on WORKS_ON relationship

25. Weak Entity Types:
Entity types that do not have key attributes of their own
Entities belonging to a weak entity type are identified by being related to specific entities from another entity type (identifying or owner entity type) in combination with some of the attribute values.
Has a total participation constraint with respect to its owning entity type
Consider the DEPENDENT entity type (two distinct employees may have the same value for attribute for DEPENDENT)
Partial key
A set of attributes that can uniquely identify the weak entities that are related to the same owner entity (no two dependents of the same employee ever have the same first name, “Name”-Partial key)
Boxes and diamonds are double lines

26. Refining the ER Design for the COMPANY Database
MANAGES
1:1 between EMPLOYEE & DEPARTMENT
EMPLOYEE participation is partial
DEPARTMENT participation is unclear
StartDate attribute
WORKS_FOR
1:N between DEPARTMENT & EMPLOYEE
Both participations are total
CONTROLS
1:N between DEPARTMENT & PROJECT
PROJECT participation is total
DEPARTMENT participation is partial

27. SUPERVISION
1:N between EMPLOYEE (in supervisor role) & EMPLOYEE (in supervisee role)
Both participations determined to be partial after users indicate not every employee has a supervisor.
WORKS_ON
M:N between EMPLOYEE & PROJECT
Both participations are total
Hours attribute
DEPENDENTS_OF
1:N between EMPLOYEE & DEPENDENT
EMPLOYEE participation is partial
DEPENDENT participation is total

28. ER Diagram Notation