The Entity-Relationship Model

Chapter 2

Conceptual design: (ER Model is used at this stage.)

◦ What are the entities and relationships in the enterprise?

◦ What information about these entities and relationships should we store in the database?

◦ What are the integrity constraints or business rules that hold?

◦ A database `schema’ in the ER Model can be represented pictorially (ER diagrams).

◦ Can we map an ER diagram into a relational schema.

Overview of Database Design

The Entity relationship (ER) data model allows us to describe the data involved in a real-world enterprise in terms of objectives and their relationships and its widely used to develop an initial database design. It provides a movements from what users want into what can be implemented in a DBMS.

Database design can be divided into six steps. ER model is most relevant to the first three:1. Requirement analysis: to understand what data is to be

stored in the database, what application must be built on top of it, and what operations are most frequent and subject to performance requirements. (what the users want from the database)

2. Conceptual database design: The information gathered in the requirement analysis step is used to develop a high level description of the data to be stored in the database. This steps often uses ER model, that is one of several high level, or semantic data model.

Overview of Database Design

3. Logical database design: this task is to convert the conceptual database design (ER schema) into a relational database schema (logical schema).

4. Schema refinement: analyze the collection of relations in our relational database schema to identify potential problems, and to refine it.

5. Physical database design: we consider typical expected workloads that our database must support and further refine the database design to ensure that it meets desired performance criteria. (e.g. building indexes on some tables, clustering some tables or redesign of parts of database schema).

6. Application and security design: Design methodology like UML try to address complete software design and development cycle. Briefly, we must identify the entities, processes involved in the application, describe the role of each entity in every process and what part of the database that needs to be accessed by this role.

Overview of Database Design

The main construct for representing data in the relational model is a relation.

A relation consists of a relational schema and relational instance. The relational instance is a table and relational schema describes the column heads for the table.

Example of relational schema is : Student(Sid: string, name: string, age: integer).

An instance of a relation is a set of tuples, also called records, in which each tuple has the same number of fields as in the relational schema.

A relational database is a collection of relations with distinct relation names.

The relational database schema is the collection of schemas for the relations in the database.

Relational Model

The ER model is initial and high level database design. Entity: Real-world object distinguishable from other objects.

Entity Set: A collection of similar entities. E.g., MIS faculty and management faculty may both contain Dr Akram. Means we may have one entity set names faculty that may contain all faculty in these two departments ◦ All entities in an entity set have the same set of attributes. (Until we

consider ISA hierarchies, anyway!)◦ Each entity set has a key.◦ Each attribute has a domain.

Given an ER diagram, describing a database, a standard approach is taken to generating relational database schema.

The following SQL can be used for translating ER to Relational database schema:CREATE TABLE Employee (ssn CHAR (11),

NAME CHAR(30), age INTEGER, PRIMARY KEY (SSN));

ER Model Basics

Employees

ssn nameagessn name age

1223-133 Attishoo 48

1122-989 Danial 24

Relationship: Association among two or more entities. E.g., Works_In is a relationship set in which each relationship indicates a department in which an employee works.

Create table Works_In ( ssn Char(11),did Integer, Since Date

Primary Key (ssn, did)Foreign key (ssn) references EmployeeForeign Key (did) references

Departments

ER Model Basics (Contd.)

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

Ternary Relationship:Suppose that each department has offices in several locations and we want

to record the locations at which each employee works. This type of relationship called ternary because we must record an association between an employee, department and a location.

A relationship sometimes involve two entities in the same entity set. For example, Reports_To relationship shows that employee report to other employee. Every relationship in Report_To is of the form (emp1,emp2) where both emp1 and emp2 are entities in Employees entity sets. They play different role: emp1 reports to the managing employee emp2.

ER Model Basics (Contd.)

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

Locations CapacityAddressReports_To

lot

name

Employees

subordinatesupervisor

ssn

Key Constraints

Consider Works_In: An Employee can work in many departments; a dept can have many employees.

In contrast, check the Manages relationship in the above figure: each dept has at most one manager, although a single employee is allowed to manage more than one department. The restriction of each dept that has at most one manager is an example of a key constraint which implies that each department entity appears in at most one managers relationship.

dname

budgetdid

since

lot

name

ssn

ManagesEmployees Departments

Key Constraints for Ternary relationship

Each employee works in at most one department and at a single location. Each department can be associated with several employees and locations and each location can be associated with several departments and employees.

But each employee associated with a single department and location.

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

Locations CapacityAddress

The key constraint on manages tells us that a department has at most one manager. But, does every department have a manager?◦ If so, this is a participation constraint: the participation of Departments in

Manages is said to be total (otherwise it is partial). The participation of the entity set Employees in manages is partial ..

Why .. Because not every employee gets to manage a department. In works_In relationship set, it is natural to expect that each employee

works in at least one department and that each department has at least on employee. Means the participation of both employee and department in Works_In is total. (presented by thick line)

Participation Constraints

lot

name dnamebudgetdid

name dnamebudgetdid

since

Manages

since

DepartmentsEmployees

ssn

Works_In

Suppose that Employees can purchase insurance policies to cover their Dependents. We wish to record information about policies including who is covered by each policy, but this information is our only interest in the dependence of an Employees.

We might choose to identify a Dependent by name alone in this situation, since it is reasonable to expect that the dependants of a given employee have different names. So pname and age are only attributes in Dependents entity.

Therefore attribute pname dose not identify a dependant uniquely. Recall that the key for Employees is ssn, thus we might have two

employees called John and each might have a son called Joe. Dependents is an example of a weak entity set.

A weak entity can be identified uniquely only by considering some of its attributes (pname) in conjunction with the primary key (ssn) of another (owner) entity.◦ Owner entity set and weak entity set must participate in a one-to-many

relationship set (one owner, many weak entities).◦ Weak entity set must have total participation in this identifying

relationship set.◦ The arrow from Dependents to Policy indicates that each Dependents

entity appears in at least one policy relationship.

Weak Entities

Example: Dependent entity can be identifies uniquely only if we take the key of the owning Employee entity (ssn) and the pname of the dependents entity.

The set of attributes of a weak entity set that uniquely identify a weak entity for a given owner entity called a partial key of the weak entity set.

In our example, pname is a partial key for Dependents. The total participation of Dependants in Policy is indicated by linking

them with dark line. The arrow from Dependents to Policy indicates that each Dependents entity appears in at most one Policy relationship

To underscore the fact that Dependents is a weak entity and Policy is its identifying relationship, we draw both with dark lines. To indicate that pname is a partial key for Dependents, we underline it using a broken line. Means there may well be two dependents with the same pname value.

Weak Entities

lot

name

agepname

DependentsEmployees

ssn

Policy

cost

ISA (`is a’) Hierarchies

Overlap constraints: Can Joe be an Hourly_Emps as well as a Contract_Emps entity? Intuitively no

Covering constraints: Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? Intuitively no

Reasons for using ISA: ◦ To add descriptive attributes

specific to a subclass.◦ To identify entitities that

participate in a relationship.

Contract_Emps

namessn

Employees

lot

hourly_wages

ISA

Hourly_Emps

contractid

hours_worked

Some times it is natural to classify the entities into subclasses. E.g. Hourly_Emps entity with attributes like hourse_worked and hourly_wage set and Contract_Emps entity with attribute contractid to distinguish the basis on which they are paid.

We want the semantics that every entity in one of these sets is also in Employees entity, and as such must have all the attributes of Employees defined.

We say that attributes in Employee are inherited by the entity Hourly_Emps and Contract_Emps. (same as C++, Java, etc.)

If we declare A ISA B, every A entity is also considered to be a B entity.

Aggregation

Used when we have to model a relationship involving entities and a relationships.◦ Aggregation allows us

to treat a relationship set as an entity set for purposes of participation in (other) relationships.

Each project is sponsored by one or more departments, and each department sponsored by at least one project (total).

A department that sponsors a project might assign employees to monitor the sponsorship. Thus monitors should be a relationship set that associates a Sponsors relationship with an Employee entity. This relationship called aggregation.

Aggregation vs. ternary relationship: Monitors is a distinct relationship, with a descriptive attribute. Also, can say that each sponsorship is monitored by at most one

employee.

budgetdidpid

started_on

pbudgetdname

until

DepartmentsProjects Sponsors

Employees

Monitors

lotname

ssn

since

Design choices: Developing an ER diagram presents several

choices, including:◦ Should a concept be modeled as an entity or an

attribute?◦ Should a concept be modeled as an entity or a

relationship?◦ Identifying relationships: Binary or ternary?

Aggregation?

Conceptual Design Using the ER Model

Should address be an attribute of Employees or an entity (connected to Employees by a relationship)?

Depends upon the use we want to make of address information, and the semantics of the data:

If we have several addresses per employee, address must be an entity (since attributes cannot be set-valued).

If the structure (city, street, etc.) is important, e.g., we want to retrieve employees in a given city, address must be modeled as an entity (since attribute values are atomic).

Entity vs. Attribute

Entity vs. Attribute (Contd.) Works_In4 does not

allow an employee to work in a department for two or more periods.

Similar to the problem of wanting to record several addresses for an employee: We want to record several values of the descriptive attributes for each instance of this relationship. Accomplished by introducing new entity set, Duration.

name

Employees

ssn lot

Works_In4

from todname

budgetdid

Departments

dnamebudgetdid

name

Departments

ssn lot

Employees Works_In4

Durationfrom to

Entity vs. Relationship Suppose that each

department manager is given flexible budget (dbudget).

First ER diagram OK if a manager gets a separate discretionary budget for each dept.

What if a manager gets a discretionary budget that covers all managed depts?◦ Redundancy:

dbudget stored for each dept managed by manager.

◦ Misleading: Suggests dbudget associated with department-mgr combination.

Manages2

name dnamebudgetdid

Employees Departments

ssn lot

dbudgetsince

dnamebudgetdid

DepartmentsManages2

Employees

namessn lot

since

Managers dbudget

ISA

This fixes theproblem!

Conceptual design follows requirements analysis, ◦ Yields a high-level description of data to be stored

ER model popular for conceptual design◦ Constructs are expressive, close to the way people

think about their applications. Basic constructs: entities, relationships, and

attributes (of entities and relationships). Some additional constructs: weak entities, ISA

hierarchies, and aggregation. Note: There are many variations on ER model.

Summary of Conceptual Design

Several kinds of integrity constraints can be expressed in the ER model: key constraints, participation constraints, and overlap/covering constraints for ISA hierarchies. Some foreign key constraints are also implicit in the definition of a relationship set.◦ Some constraints (notably, functional dependencies)

cannot be expressed in the ER model.◦ Constraints play an important role in determining the

best database design for an enterprise.

Summary of ER (Contd.)

ER design is subjective. There are often many ways to model a given scenario! Analyzing alternatives can be tricky, especially for a large enterprise. Common choices include:◦ Entity vs. attribute, entity vs. relationship, binary or n-

ary relationship, whether or not to use ISA hierarchies, and whether or not to use aggregation.

Ensuring good database design: resulting relational schema should be analyzed and refined further. FD information and normalization techniques are especially useful.

Summary of ER (Contd.)

Explain the following terms briefly and give an example: attribute, domain, entity, relationship, one-to-many relationship, many-to-many relationship, participation constraint, overlap constraint, covering constraint, weak entity set, aggregation.

A university database contains information about professors (identified by SSN) and courses (identified by courseid). Professors teach courses; the following situation concerns the Teaches relationship set. Draw an ER diagram that describes it (assuming no further constraints hold).

1. Professors can teach the same course in several semesters, and each offering must be recorded.

End chapter exercises