Lesson 4: The Relational Model. Lesson Overview Database Design Entities Relationships E-R Diagrams.

Lesson 4: The Relational Model

Lesson Overview

• Database Design

• Entities

• Relationships

• E-R Diagrams

Database Design

LOGICAL DESIGN

PHYSICAL DESIGN

REQUIREMENTS ANALYSIS

Data Structure Design

Data Structure Refinement

E-R Diagrams

Data Models

Database Design

• The first step in database design is the requirement analysis where database designers interview prospective users to understand and document their data requirements.

Database Design

• Once the requirements have been analysed, the designer creates a conceptual schema for the database to make a graphic representation of the organisations’ data requirements independent of the DBMS and the hardware.

Database Design

• Steps in Database Design involve:• 1. Users’requirements analysis• 2. Creation of the conceptual schema by the

database designers in the logical design.• 2a. Design the Data Structure• 2b. Refine the Data Structure• The conceptual schema is a graphic

representation of the organisations’ data requirements independent of the DBMS and the hardware.

Database Design

• In the first phase of the logical design, i.e. the data structure design, the conceptual schema of the database is developed. This is DBMS-independent.

• One way of representing the logical design is by using the Entity-Relationship (E-R) Diagram

Database Design

• In Data Structure refinement the DBMS-independent logical design is transformed into a data model compatible with the chosen DBMS.

• An Entity is a real world object which exist and is distinguishable from other objects.

• An entity is represented by a set of attributes which are properties that described the entity’s characteristics.

Database Design

• The identifier of an entity instance is one or more attributes.

• This identifier may be unique or not unique.• A unique identifier identifies one and only one,

entity instance.• The unique identifier is known as a superkey. • The superkey can be one attribute or a

combination of attributes.

Entities• An Entity is a real world object

which exist and is distinguishable from other objects.

• We wish to record the data about these objects.

• An entity may be concrete such as a person, a book, a course etc.

Entity

• An entity may also be abstract or a concept such as a holiday, registration, a flight reservation etc.

• An entity set or an entity class is a set of all entities of the same type.

• It is the general form or description.

Entities

• The set of all students registered for a particular course for instance can be defined as the entity set STUDENT.

• The entity set CUSTOMER might represent the set of all persons having an account at a bank.

Entities

• Entity sets are not disjoint.

• For e.g.. we may define the entity set of all the customers of the bank, CUSTOMER, and the entity set of all employees of the bank, EMPLOYEE.

• A Person entity may be an EMPLOYEE entity, a CUSTOMER entity, both or neither.

Entities

• an entity instance is the representation of

a particular entity, e.g. customer with the

name Lim is an instance of the entity

CUSTOMER.

Attributes

• An entity is represented by a set of attributes.

• Attributes are properties which described the entity’s characteristics.

• For the entity employee, possible attributes are EMPLOYEENO, EMPLOYEENAME, DATEOFHIRE.

Attributes

• Attributes can be single or multiple valued, simple or composite, stored or derived.

• For each attribute there is a set of permitted values, called the domain of that attribute.

Attributes

• The domain of the attribute CustomerName may be the set of all text strings of length 50.

• Simple (atomic)

• Composite

• Single-valued

• Multi-valued

Attribute typesAttribute types

Simple Attributes (Atomic)

• A simple attribute is an attribute that cannot be further divided into its components.

• E.g.. ?

Composite Attribute

• An attribute that can be further subdivided is a composite attribute.

• E.g.?

Single-Valued Attribute

• A single valued attribute can only have one value.

• E.g.An employee can have only one date of birth, one First Name, one Social security number

• An employee can have more than one degree, so EMP_Degree is a multivalued attribute

• Tip: Good database designs ensure that only signle valued attributes are stored in the database.

Identifiers

• Entity instances have names that identify them.

• CUSTOMER has CustomerName or CustomerNO

• STUDENt has Name or StudentNo

• COURSE has CourseName or CourseNo

Identifiers

• The identifier of an entity instance is one or more attributes.

• The identifier may be unique or not unique.

• If it is unique, then, it identifies one and only one, entity instance.

• If it is not unique, the value will identify more than one instance.

Identifiers

CustomerNameCustomerName is not a unique identifier is not a unique identifier because it can produce a set of instances.because it can produce a set of instances.

Two or more customers may have the same Two or more customers may have the same name. name.

If If CustomerNameCustomerName is to be used then is to be used then additional data, such as additional data, such as AddressAddress, , TelephoneNoTelephoneNo or or DateOfBirthDateOfBirth is required to is required to find a unique instance.find a unique instance.

Relationships

• A relationship is an association between entities.

• A relationship set is a set of relationships of the same type.

• Relationship sets are associations between entity sets.

Relationships

• Relationship instances are association between entity instances.

• A relationship can have attributes.

Relationships

STUDENT

CourseCOURSE

Register

Relationships

• Register is a relationship between STUDENT and COURSE

• A possible attribute for Register is Date.

• Relationships have degrees and cardinalities.

• The number of entities in the relationship is the degree of the relationship.

Relationship Degrees : Binary(Degree 2)

LECTURER

STUDENT

Teach

Relationship Degrees: Ternary (Degree 3)

CHILD

MOTHER FATHER

Parent

Relationship Degrees

• In a binary relationship (degree 2) each relationship set involves two entity sets.

• In a ternary relationship each relationship set involves three entity sets.

Binary Relationships :Relationship

Types• There are three types of binary

relationships:

• one-to-one, one-to-many, many-to-one and many-to-many.

• These are the cardinalities of the relationships.

One-to-one Relationship (1:1)

a1

a2

a3

b1

b2

b3

A B

One-to-one Relationship (1:1)

• In a one-to-one relationship an entity in A is associated with one and only one entity in B.

• A relationship between a wife and a husband is a1:1 relationship.

WIFE HUSBAND

Marriage

has1 1

One-to-many Relationship (1:M)

a1

a2

a3

b1

b2

b3

AB

b4

b5

One-to-many Relationship (1:M)

• An entity in A is associated with any number of entities in B.

• The relationship between Faculty and Students is a 1:M relationship

FACULTY STUDENTEnrols

1 M

Many-to-one Relationship (M:1)

a1

a2

a3

b1

b2

b3

AB

a4

a5

Enrollment

Is-Enrolled

Many-to-one Relationship (M:1)

• An entity A is associated with at most one entity in B. An entity in B , however, can be associated with any number of entities in A.

• The relationship between Student and Faculty is M:1

STUDENT FACULTY

M 1

Many-to-many Relationship (M:M)

a1

a2

a3

b1

b2

b3

A B

Many-to-many Relationship (M:M)

• An entity in A is associated with many entities in B, and an entity in B is associated with many entities in A.

LECTURER STUDENT1:MTeach

M M

Many-to-many Relationship (M:M)

• The relationship between Lecturer and Student is M:M

• In the relational model, M:M relationships are broken into sets of 1:M relationships

LECTURERSTUDENT

LECT-STUD

1

M

1

M

Composite Entity

– Designed to transform an M:N relationship into two 1:M relationships

– Key comprises at least the primary keys of the entities that it connects

Weak Entity Sets• An entity set that does not have a

primary key is referred to as a weak entity set.

• The existance of a weak entity set depends on the existence of a strong entity set; it must relate to the strong set via a on-to-many relationship set.

• A weak entity cannot exist without the related entity’s presence.

• E.g. Dependent is a weak entity

EMPLOYEE DEPENDENTSHas

Weak Entity

• The primary key of a weak entity set is formed by the primary key of the strong entity set on which the weak entity set’s existence depends on.

Optional Relationship

• The relationship between Employee and Dependent is an optional one.

• An employee can have 0 or more dependents.

• Thus there will be cases of particular employee without dependents.

Mandatory Relationships

• The relationship between an EMPLOYEE and DEPARTMENT

• A Department must be occupied by an employee

• An employee must be the occupant of a department.

• 2nd e.g.: An EMPLOYEE must have one EMPLOYMENT_CONTRACT and each EMPLOYMENT _CONTRACT must have one EMPLOYEE associated with it.

Subtype/Supertype Relationship

• The relationship between EMPLOYEE and LECTURER is a 1:1 relationship.

• It is also a subtype/supertype relationship because the LECTURER entity contains attributes that are unique to LECTURERS while the EMPLOYEE entity contains the entity’s common attribute.

Recursive Relationship

• Happens when an entity is related to itself.

COURSE prerequisite

Entity-Relationship(E-R) Diagram

• The overall logical structure of a database is expressed graphically by an Entity-Relationship (E-R) diagram.

• The diagram consists of

• Rectangles which represent entity sets.

• Ellipses which represent attributes.

Entity-Relationship(E-R) Diagram

• Diamonds which represent relationship sets.

• Lines which link attributes to entity sets and entity sets to relationship sets.

Symbols

• Entity

• Relationship

• Composite Entity

• Optionality

CUSTOMER

generates

INV_LINE

DEPENDENT(Weak entity)

An ERD Segment

CUSTOMER generates INVOICE

1 M

(0,N) (1,1)

cardinalities

connectivities

Business rules: 1. One customer may generate many invoices 2. Each invoice is generated by one customer

3. Some customers have never generated an invoice (The customer list apparently includes potential customers. Therefore, INVOICE is optional to CUSTOMER.)

An expanded ERD segment

CUSTOMER generates INVOICE

INV_LINEPRODUCT

1 M

(0,N) (1,1)

(O,N) (1,1)

1 M

1:M Relationships

CUSTOMER generates INVOICE

1 M

(0,N) (1,1)

EMPLOYEE has DEPENDENT

1 M

(0,N) (1,1)

A supertype/subtype relationship

EMPLOYEE is a PILOT

1 1

(0,1) (1,1)

The supertype contains allcommon attributes such as

names, addresses, etc.

The subtype contains all specializedattributes, such as pilot license,

flight check dates, etc.

EMPLOYEE DEGREEEMP_DEGREE

1 M

(0,N) (1,1)(1,1)

M 1

Implementing multi-valued attributes

(1,N)

Business rules:Some employees do not have degrees. (Employees are not required to

have a degree.) Therefore, some employees do not occur in the EMP_DEGREE (composite) entity.

A degree is entered only if at least one employee has earned thatdegree. But a degree can be earned by many employees.

(1,1)

EMPLOYEE

1

(0,N)

(1,1)

MM

(1,1)

M M

(1,1)(1,N)

CUSTOMER

1

1

(1,N)

(0,N)

(0,N)

(1,1)

contracts coordinates

leads

PROJECT

PROJ_EMP

1

M

1

An ERD for a consulting company

1 M M1

CUSTOMER INVOICE LINE

(0,N) (1,1) (1,1)(1,N)

PRODUCT

generates

M

1

(1,1)

(0,N)

An Invoicing ERD: Composite Entity LINE

Relational Schema

1 M M1

CUSTOMER INVOICE LINE

(0,N) (1,1) (1,1)(1,N)

PRODUCT

generates

appears in

contains

M

1

(1,1)

(0,N)

An Invoicing ERD: Composite Entity LINEDecomposed Through Named Relationships

Relational Schema

1 1 M1

EMPLOYEE MECHANIC MAINT_LOG

(0,1) (1,1) (1,1)(1,N)

MAINT_LINE

is a

contains

writes

M

1(1,N)

(1,1)

1 M

CUSTOMER CAR

(0,N) (1,1)

owns

needs

1

M(1,1)

(0,N)

1

PART

(0,N)

is in

(0,1)

M

A Car Maintenance ERD

1

M

M

1TEAM

GAME

PLAYER(1,N)

(1,1)

(1,1)uses

(1,1)M

(1,N)(1,N)

1

M

CITY

(1,N)

(1,1)sponsors

1 A recursive M:Nrelationship. Implementedthrough the compositeentity GAME. (TEAM plays TEAM in a GAME.)

RelationalSchema

E-R Diagram for a BANK Database

BANK BRANCH

ACCOUNT

CUSTOMER

LOAN

Name

Code Add Addr

BrNo

LoanNoType Amt

AcctNo

Balance

Type

CustNo

Phone Name Add

ACCTS

A-C

LOANS

BRANCHES

Summary

• Steps in Database Design involve:• 1. Users’requirements analysis• 2. Creation of the conceptual schema by

the database designers in the logical design.

• 2a. Design the Data Structure• 2b. Refine the Data Structure• The conceptual schema is a graphic

representation of the organisations’ data requirements independent of the DBMS and the hardware.

Summary

• In the first phase of the logical design, i.e. the data structure design, the conceptual schema of the database is developed. This is DBMS-independent.

• One way of representing the logical design is by using the Entity-Relationship (E-R) Diagram.

Summary

• In Data Structure refinement the DBMS-independent logical design is transformed into a data model compatible with the chosen DBMS.

• An Entity is a real world object which exist and is distinguishable from other objects.

Summary

• An entity is represented by a set of attributes which are properties that described the entity’s characteristics.

• The identifier of an entity instance is one or more attributes.

Summary

• This identifier may be unique or not unique.

• A unique identifier identifies one and only one, entity instance.

Summary

• The unique identifier is known as a superkey.

• The superkey can be one attribute or a combination of attributes.

Summary

• {CustomerName, Address} is a superkey.

• Candidate keys are superkeys such that the subset of that key is not a superkey.

• {CustomerName, Address} is a candidate key.

• {CustomerNo, Address} is a superkey but not a candidate key.

Summary

• The candidate key chosen by the database designer as the identifier is called a primary key.

Summary

• A relationship is an association between entities.

• A binary relationship (degree 2) each relationship set involves two entity sets.

• binary relationships can be one-to-one, one-to-many, many-to-one and many-to-many.

Summary

• (E-R) diagram consists of

• Rectangles which represent entity sets.

• Ellipses which represent attributes.

• Diamonds which represent relationship sets.

• E-R diagrams are used to represent the logical structure of a database.

Next Lecture Lesson 5: Normalization I

Q & A

[email protected]