The Entity-Relationship Diagram

Overview of Database Design

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

ER Diagram

• Entity Relationship (ER) Diagram

– A detailed, logical representation of the entities,

associations and data elements for an organization or

business

– An entity-relationship (ER) diagram is a specialized graphic

that illustrates the interrelationships between entities in a

database.

Framework for E/R

• The E/R model allows us to sketch database schema

designs

• Design is a serious business.

• The “boss” knows they want a database, but they

4

• The “boss” knows they want a database, but they

don’t know what they want in it.

• Sketching the key components is an efficient way to

develop a working database.

Main constructors of ER

– Data entities

– Relationships– Relationships

– Attributes

ER Model Basics

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

• An entity is shown in a rectangle.

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

attributes. (Until we consider ISA hierarchies, anyway!)

Entities

• Examples of entities:– Person: EMPLOYEE, STUDENT, PATIENT

– Place: STORE, WAREHOUSE

– Object: MACHINE, PRODUCT, CAR

– Event: SALE,REGISTRATION, RENEWAL

– Concept: ACCOUNT, COURSE– Concept: ACCOUNT, COURSE

• Guidelines for naming and defining entity types:– An entity type name is a singular noun

– An entity type should be descriptive and specific

– An entity name should be concise

– Event entity types should be named for the result of the event, not the

activity or process of the event.

An entity’s name should be:• Unique in the entire organization; furthermore, try to avoid similar

names for different entities, such as PROJECT and P ROJECTION.

Choose a non-confusing name for both.

PROJECT PROJECTION

If different terms are used to define the same thin g underdifferent departments synonyms can be defined. For example,some departments may call it a CUSTOMER while other s maycall a CLIENT.

Finally one has to be chosen in database but when s peaking toFinally one has to be chosen in database but when s peaking todifferent people we must choose their terms.

Instances of entitiesIf you are not certain whether something is an enti ty or not, itmay help to ask yourself the question,

“What are the instances (examples) of this entity?”

To make sure your list includes real entities,

Here are some other ways:

Validate Entities

Is its name a noun? Not all nouns represent entitie s, but all entity names should be nouns.

To make sure your list includes real entities,

Here are some other ways:

Validate Entities

Does this entity have any attributes?

For example, if you think you have an entity named STUDENT, do you need to store facts about students?

Name, Student Number, Address, Birth Date .... YES, IT IS AN ENTITY.

To make sure your list includes real entities,

Here are some other ways:

Validate Entities

If you think you have an entity called CUSTOMER NAM E, ask the same question: Does it have any facts, attributes t o store? The country of origin, number of wovels, meaning of the name ....

Are these really important facts to store in your d atabase?

NOT! Then CUSTOMER NAME is not an entity.

Summary

• An entity is a thing of significance about which information needs to be stored; a class or category of thing; a named thing.

• When considering whether something is an entity or not, it helps to ask yourself the question, “What would some instances of this entity be?”

• An entity’s name should be unique in the entire organization and familiar to all.

• Once you have identified an entity and named it, you should diagram it; the diagram pictorially represents entities, the vital business relationships between them and the attributes to describe them.

• An attribute is any detail that serves to qualify, identify, classify, quantify, or express the state of an entity.

Logical DB Design: ER to Relational

• Entity sets to tables:

CREATE TABLE Employees (ssn CHAR(11),name CHAR(20),lot INTEGER,

ssnname

lotlot INTEGER,PRIMARY KEY (ssn))

Employees

Attributes

• An attribute is a property or characteristic for an entity

or a relationship type.

• It is shown in an oval.

• Example of entity types and associated attributes:

STUDENT: Student_ID, Student_Name,

Home_Address, Phone_Number, Major

Guidelines for naming attributes

– An attribute name is a noun.

– An attribute name should be unique

– To make an attribute name unique and clear, each – To make an attribute name unique and clear, each

attribute name should follow a standard format

– Similar attributes of different entity types should

use similar but distinguishing names.

Simple and Composite attributes

• A simple(atomic) attribute is an attribute composed

of a single component with an independent

existence.

• can not be further subdivided into smaller

components.

• A composite attribute, sometimes called a group

attribute, is an attribute composed of multiple

components, each with an independent existence.

• The names chosen for composite attributes should

be descriptive and general

Composite Attribute

Single-valued and Multi-valued attribute

• Single-valued attribute that holds a single value for each occurrence of an entity type.

• Multi-valued attribute that holds multiple values for each occurrence of an entity type.

• Multi-valued attributes are mapped by using additional • Multi-valued attributes are mapped by using additional relation schema. For each multi-valued attribute A, create a new relation R.

• This relation will include attribute corresponding to A plus the primary key K of the entity type or relationship type that has A as attribute. Combination of A and K becomes primary key of R.

Example: multivalued attribute

Multivalued attribute… an employee

may have more than one skill.

Derived attributes

• An attribute that represents a value that is derivable

from the value of a related attribute or set of

attributes, not necessarily in the same entity type.

• The values are held by some attributes may be

derived.

• The oval representing a derived attribute is drawn

with a dash line

Candidate Keys

• Some tables contain more than one column (or combination of columns –composite key) that can act as a primary key. These columns all possess the uniqueness property of a primary key. Here, the uniqueness property of a primary key. Here, also, null values are not allowed. These columns are called candidate keys. However, only one is designated as the primary key

• All candidate keys which are not chosen as "primary key" are Alternate keys.

Primary Key

• A primary key is used to uniquely identify each row in a table.

• this key does not allow null values and also does not allow duplicate values.not allow duplicate values.

• Primary keys can be specified either when the table is created (using CREATE TABLE) or by changing the existing table structure (using ALTER TABLE).

Example

• CREATE TABLE Student

(SID integer,

Last_Name varchar(30), Last_Name varchar(30),

First_Name varchar(30),

PRIMARY KEY (SID));

Foreign Key

• A foreign key is a field (or fields) that points to

the primary key of another table. The purpose

of the foreign key is to ensure referential

integrity of the data. In other words, only integrity of the data. In other words, only

values that are supposed to appear in the

database are permitted.

Example

• create table Enroll (Student_SID integer,

Courses_CID char(10),

Foreign Key(Student_SID) references

Student(SID),Student(SID),

Foreign Key(Courses_CID)references

Courses(CID)

);

Entity Type Key

• Every (regular) entity type has at least one key

• The entity type key is defined in a similar way as the relation

schema key

• To denote the primary key, underlining is used

• If a key has more than one attribute, it should be represented • If a key has more than one attribute, it should be represented

as a composite attribute

• e.g.Course

CourId

Subject

CourNoPNameNoOfpts

Relationships

Relationship: Association among two or more entities

Relationship Set: Collection of similar relationships.

Author Book

Relationship name:

writes

An author writes one or more books

A book can be written by one or more authors.

Guidelines for naming relationship

– Explain any restrictions on participation in the relationship

– Explain extent of the history that is kept in the relationship

– Explain whether an entity instance involved in a – Explain whether an entity instance involved in a relationship instance can transfer participation to another relationship instance

– Graphically, a relationship is represented by a diamond shaped box connecting associated entity types

ER Model Basics

lot

dname

budgetdid

sincename

Works_In DepartmentsEmployees

ssn

CREATE TABLE Works_In(ssn CHAR(11),did INTEGER,since DATE,PRIMARY KEY (ssn, did),FOREIGN KEY (ssn) REFERENCES Employees,

FOREIGN KEY (did) REFERENCES Departments)

Attributes on relationships

Sometimes it is useful to attach attributes to

a relationship

• to represent a certain characteristic or • to represent a certain characteristic or

property of that relationship

Degree of Relationships

• Degree: number of entity types that participate in a relationship

• Three cases

– Unary: between two instances of one entity type

– Binary: between the instances of two entity types

– Ternary: among the instances of three entity types

– Quaternary: among the instances of three entity types– Quaternary: among the instances of three entity types

Recursive Relationships

• A relationship may be defined between entities of the same entity set

• Associations between entities of the same set are called recursiveare called recursive

• Every entity in a relationship has a role

• In the case of a recursive relationship, the roles should be shown explicitly

Example :Unary

Example: Ternary

Example-Quaternary

Cardinality and Connectivity

• Relationships can be classified as either

• one – to – one

• one – to – many

• many – to –manyConnectivity

• many – to –one

• Cardinality : minimum and maximum number of

instances of Entity B that can (or must be) associated

with each instance of entity A.

Connectivity

• Chen Model

– 1 to represent one.

– M to represent many

• Crow’s Foot

1

M

• Crow’s Foot

many

One

One or many

Mandatory one , means (1,1)

Cardinality Ratio

• The cardinality ratio of R is an expression of the form

R E2E1

b2 b1

• The cardinality ratio of R is an expression of the form

b1 :b2

where b1 is the maximal number of E2 instances that may be associated with an E1 instance, b2 is the maximal number of E1 instances that may be associated with an E2 instance, and b∈{1, N }

Cardinality Limits

Mapping Cardinalities

One to one One to many

Note: Some elements in A and B may not be mapped to any elements in the other set

Mapping Cardinalities

Many to one Many to many

Note: Some elements in A and B may not be mapped to any elements in the other set

Crow’s foot modell

ManMan WomanWoman

One-to-one (1:1)

One-to-many (1:n)

CustomerCustomer OrderOrder

CourseCourse SubjectSubject

Many-to-many (n:m)

NOTE: Every many to many relationship consists of two one to

many relationships working in opposite directions

Participation Constraint

• The participation constraint specifies whether existence of an entity

depends on its association with another entity

• A participation constraint can be:

– Total when it models existence dependence,

– Partial

• Graphic representation ( | partial, || total)• Graphic representation ( | partial, || total)

• Mind that participation constraint is placed on that side of the relationship

where the considered entity belongs

Manages SchoolHeadOfSchool1 1

HOS

total partial

Question for you

• Cardinality ratio and participation constraint are together

called structural constraint

• Cardinality ratio can be either 1 : 1, 1 : N, or M : N

• participation constraint can be either total or partial

• How many different structural constraints are there:• How many different structural constraints are there:

– 2

– 4

– 8

– 12

Participation: Full/Partial

• It is likely that on any campus, not all students will drive an automobile

• To show that every automobile is driven by a student, but not every

student drives an automobile, we will enhance our model of ER diagrams

by putting a double line between the relationship diamond and the

AUTOMOBILE entity to indicate that every automobile is driven by oneAUTOMOBILE entity to indicate that every automobile is driven by one

student. Put another way, every automobile in the database participates

in the relationship.

• From the student side, we leave the line between the STUDENT entity and

the relationship as a single line to indicate that not every student drives an

automobile. Some students will not participate in the drive relationship

because they do not drive a car on campus. The single/double lines are

called participation constraints.

Relationships of the Degree > 2

CourseStudent SPL

LecturerLecturer

Instances of the SPL relationship type are triples (s, c, l ). The structuralconstraints are determined by considering associations between:• a (s, c ) pair and a l to determine cardinality ratio next to Lecturer, andbetween a l and a (s, c ) pair to determine the participation constraint of the Lecturer

• the same applies to a (s, l ) pair and a c for a Course instance, and a •(l, c ) pair and a s for a Student instance

Relationships of the Degree > 2

CourseStudent SPL

Lecturer

1

N N

Lecturer

Suppose each Course c is taught by only one lecturer l and each lecturer teaches at least one Course. Then:• each (s, c ) pair is associated with exactly one l, so the cardinalityratio next to Lecturer will be 1, and the Lecturer has a total participation constraint,

• it is natural to expect that each (l, c ) pair is associated with zero or morethan one students, and

• each (s, l ) pair with zero or more than one Course