Data Modeling Using the Entity-Relationship Model

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

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

2. Database Design Process

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.

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.

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

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

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

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.

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)

Initial conceptual design of the Company database

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.

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

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

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.

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

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.

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.

1 – Supervisor 2 - Supervisee

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)

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.

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

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

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

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

ER Diagram Notation