The Entity-Relationship Model

Databases Model the Real World

• “Data Model” allows us to translate real world things into structures computers can store

• Many models: Relational, E-R, O-O, Network, Hierarchical, etc.

• Relational– Rows & Columns– Keys & Foreign Keys to link Relations

Conceptual Design

• 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 map an ER diagram into a relational schema.

ER Model Basics

• Entity: Real-world object, distinguishable from other objects. An entity is described using a set of attributes.

• Entity Set: A collection of similar entities. E.g., all employees. – All entities in an entity set have the same set

of attributes. – Each entity set has a key (underlined).– Each attribute has a domain.

Employees

ssnname

lot

ER Model Basics (Contd.)

• Relationship: Associat ion among two or more entit ies. E.g., Att ishoo works in Pharmacy department.– relationships can have their own attributes.

• Relationship Set: Collect ion of similar relationships.– An n-ary relationship set R relates n entity sets E1 ... En ;

each relationship in R involves entities e1 ∈ E1, ..., en ∈ En

lot

name

Employees

ssn

Works_In

sincedname

budgetdid

Departments

ER Model Basics (Cont.)

• Same entity set can participate in different relationship sets, or in different “roles” in the same set.

subor-dinate

super-visor

Reports_To

since

Works_In

dname

budgetdid

Departments

lot

name

Employees

ssn

Relational definitions

• A relat ion is a named, two-dimensional table of data

• Every relation has a unique name, and consists of a set of named columns and an arbitrary number of unnamed rows

• An attr ibute is a named column of a relation, and every attr ibute value is atomic.

• Every row is unique, and corresponds to a record that contains data attr ibutes for a single entity.

• The order of the columns is irrelevant.• The order of the rows is irrelevant.

Relational structure

• We can express the structure of a relat ion by a Tuple, a shorthand notation

• The name of the relation is followed (in parentheses) by the names of the attr ibutes of that relat ion, e.g.:

• EMPLOYEE1(Emp_ID,Name,Dept,Salary)

Relational keys

• Must be able to store and retrieve a row of data in a relat ion, based on the data values stored in that row

• A primary key is an attr ibute (or combination of attr ibutes) that uniquely identif ies each row in a relation.

• The primary key in the EMPLOYEE1 relat ion is EMP_ID (this is why it is underlined) as in:

• EMPLOYEE1(Emp_ID,Name,Dept,Salary)

Composite and foreign keys

A Composite key is a primary key that consists of more than one attr ibute.

e.g., the primary key for the relation DEPENDENT would probably consist of the combination Emp-ID and Dependent_Name

A Foreign key is used when we must represent the relat ionship between two tables and relations

A foreign key is an attr ibute (possibly composite) in a relation of a database that serves as the primary key of another relat ion in the same database

Foreign keys

Consider the following relations:EMPLOYEE1(Emp_ID,Name,Dept_Name,Salary)DEPARTMENT(Dept_Name,Location,Fax)The attribute Dept_Name is a foreign key in

EMPLOYEE1. It allows the user to associate any employee with the department they are assigned to.

Removing multivalued attributes from tables

• In the table, an entry at the intersection of each row and column is atomic (single-valued) - there can be no multivalued attributes in a relation, an example of this would be if each employee had taken more than one course, e.g.:

Emp_ID Name Dept_Name CourseA1 Fred Bloggs Info Sys Delphi

VB

Removing multivalued attributes from tables

To avoid this, we should create a new relation (EMPLOYEE2) which has a new instance for each course the employee has taken, e.g.:

A1 Fred Bloggs Info Sys DelphiA1 Fred Bloggs Info Sys VB

Example database

• The structure of the database is described by the use of a conceptual schema, which is a descript ion of the overall logical structure of a database. There are two common methods for expressing a conceptual schema:

• A) Short text statements, in which each relation is named and the names of i ts attr ibutes follow in parentheses

• B) A graphical representation, in which each relation is represented by a rectangle containing the attr ibutes for the relat ion.

Expressing the conceptual schema

• Text statements have the advantage of simplicity, whilst the graphical representation provides a better means of expressing referential integrity constraints (discussed later)

• Here is a text description for four relations:• CUSTOMER(Customer_ID, Customer_Name,

Address, City, State, Zip)• ORDER(Order_ID, Order_Date, Customer_ID)• ORDER_LINE(Order_ID, Product_ID, Quantity)• PRODUCT(Product_ID, Product_Description,

Product_Finish, Standard_Price, On_Hand)

Expressing the conceptual schema

• Note that the primary key for ORDER_LINE is a composite key consisting of the attr ibutes Order_ID and Product_ID

• Also, Customer_ID is a foreign key in the ORDER relation, allowing the user to associate an order with a customer

• ORDER_LINE has two foreign keys, Order_ID and Product_ID, allowing the user to associate each l ine on an order with the relevant order and product

• A graphical representation of this schema is shown in the fol lowing Fig.

Schema for four relations

Primary Key

Foreign Key (implements 1:M relationship between customer and order)

Combined, these are a composite primary key (uniquely identifies the order line)…individually they are foreign keys (implement M:M relationship between order and product)

Integrity constraints

• These help maintain the accuracy and integrity of the data in the database

• Domain Constraints - a domain is the set of allowable values for an attr ibute.

• Domain definit ion usually consists of 4 components: domain name, meaning, data type, size (or length), allowable values/allowable range (if applicable)

• Entity Integrity ensures that every relation has a primary key, and that all the data values for that primary key are valid. No primary key attr ibute may be null.

Entity integrity

• In some cases a part icular attr ibute cannot be assigned a data value, e.g. when there is no applicable data value or the value is not known when other values are assigned

• In these situations we can assign a null value to an attr ibute (null signif ies absence of a value)

• But sti l l primary key values cannot be null – the entity integrity rule states that “no primary key attr ibute (or component of a primary key attr ibute) may be null

Integrity constraints

• A Referential Integrity constraint is a rule that maintains consistency among the rows of two relations – it states that any foreign key value (on the relation of the many side) MUST match a primary key value in the relation of the one side. (Or the foreign key can be null)

• In the following Fig., an arrow has been drawn from each foreign key to its associated primary key. A referential integrity constraint must be defined for each of these arrows in the schema

Referential integrity constraints

Referential integrity constraints are drawn via arrows from dependent to

parent table

Referential integrity

• How do you know if a foreign key is al lowed to be null?

• In this example, as each ORDER must have a CUSTOMER the foreign key of Customer_ID cannot be null on the ORDER relation

• Whether a foreign key can be null must be specif ied as a property of the foreign key attr ibute when the database is designed

Referential integrity

Whether foreign key can be null can be complex to model, e.g. what happens to order data if we choose to delete a customer who has submitted orders? We may want to see sales even though we do not care about the customer anymore. 3 choices are possible:

Restrict – don’t allow delete of “parent” side if related rows exist in “dependent” side, i.e. prohibit deletion of the customer until all associated orders are first deleted

Referential integrity

Cascade – automatically delete “dependent” side rows that correspond with the “parent” side row to be deleted, i.e. delete the associated orders, in which case we lose not only the customer but also the sales history

Set-to-Null – set the foreign key in the dependent side to null if deleting from the parent side - an exception that says although an order must have a customer_ID value when the order is created, Customer_ID can become null later if the associated customer is deleted [not allowed for weak entities]

Key Constraints An employee can

work in many departments; a dept can have many employees.

1-to-11-to ManyMany-to-Many

since

Manages

dname

budgetdid

Departments

since

Works_In

lot

name

ssn

Employees

In contrast, each dept has at most one manager, according to the key constraint on Manages.

A Database Schema

Tables Indexes Procedures

Views Constraints

Schema Owner

schema objects

Table

A Database with Multiple Tables

Publishers Books Customers

Authors Inventory Orders

[1]

TableCustomers

Field (Column)

a field

Customers

Record (Row)

a record

Customers

Primary Key

primary key field

Customers

Primary key is a unique identifier of records in a table.Primary key values may be generated manually or automatically.

Primary Key

primary key fields

Roles (Performances)

A primary key can consist of more than one field.

Foreign Key

foreign key field

primary key fieldparent table

Directors

Movieschild tablerelationship

Relationship Types

• One-to-one

• One-to-many

• Many-to-many

Data Types

• Alphanumeric (Text, Memo)• Numeric (Number, Currency, etc.)• Date/Time• Boolean (Yes/No)

Ternary Relationships

– S “can-supply” P, D “needs” P, and D “deals-with” S does not imply that D has agreed to buy P from S.

– How do we record qty?

Suppliers

qty

DepartmentsContractParts

ISA (`is a’) Hierarchies

Contract_Emps

namessn

Employees

lot

hourly_wages

ISA

Hourly_Emps

contractid

hours_worked

� As in C++, or other PLs, attributes are inherited.� If we declare A ISA B, every A entity is also considered to be a B entity.

• Overlap constraints: Can Simon be an Hourly_Emps as well as a Contract_Emps entity? (Allowed/disallowed)

• Covering constraints : Does every Employees entity also have to be an Hourly_Emps or a Contract_Emps entity? (Yes/no)

• Reasons for using ISA: – To add descriptive attributes specific to a subclass.

• i.e. not appropriate for all entities in the superclass– To identify entities that participate in a particular relationship

• i.e., not all superclass entities participate

AggregationUsed to model a

relationship involving a relationship set.

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

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.

until

Employees

Monitors

lotname

ssn

budgetdidpid

started_on

pbudgetdname

DepartmentsProjects Sponsors

since