Overview of the database design process

Data requirements Processing requirements

ENTITY-RELATIONSHIP ANALYSIS

INTRODUCTION – Conceptual Schema

OVERVIEW OF ER MODELLING AND ITS AIMS Transaction design
TERMINOLOGY
REPRESENTATION Logical design Frequencies,
EXAMPLE performance
constraints
References: Physical design

Connolly & Begg, Database Systems, Fourth Edition pp 441-451.

Fifth Edition pp195-219 Data definition language Data manipulation
statements language statements

1 2

TERMINOLOGY
An Entity is an object that exists and is distinguishable from other objects
Object . . Person, Car, City
Real world
Event . . Birth, Goal
Activity . . Oil production from a well
Concepts. . Supplies (a relationship!)

Labourer Day Hours An ENTITY TYPE is distinct from an INSTANCE

Conceptual
model Pat Mon 6
Attribute - A property of an Entity.
Pat Tue 8
Entity type: Purchase-order
Pat Wed 2
Mike Mon 5 Entity instance: A particular purchase order
Mike Tue 6 Attributes: Order Number
Supplier
Logical Date
Create table hours_worked (Labourer char(10), day char(4), hours number)
model
An Identifier is an attribute or set of attributes that uniquely identify each
Create table labourer (ID char(10), Labourer char(10)) instance of an entity type.
Physical
Create table work(ID char(10), day char(4), hours number) Single attribute identifier Car : Registration Number
model
Multiple attribute identifier Goal : Team1, Team2, Date, Time

3 4

1
 RELATIONSHIPS
A Relationship is an association between two or more entities
E.g. Relationship stores between product and warehouse. OCCURENCE DIAGRAM
Relationship type ... Stores
Relationship occurence ... Product 1 is stored in Warehouse 3
Relationship identifier ... A composite of identifiers of entities Warehouse Stores Product

Relationships have degree:

one-to-one ( 1 : 1) e.g. Team/Manager
one-to-many (1 : M) e.g. Match/Goal
many-to-many (N:M) e.g. Student/Class

Relationships have optionality

Obligatory Every entity instance participates in the relationship
Non-obligatory Entity instance may exist independently of relationship
Non-obligatory on Employee Vehicle/Employee
Non-obligatory on either Student/Class

5 6

Representation
ENTITY RELATIONSHIP MODELLING

EMPLOYEE Entity type HOW TO DO IT

1 Start with a system description

Name Attribute (In fact, it is best
to leave attributes out of ER 2 Deduce entities by searching for nouns or noun-phrases
diagrams be careful ……. attributes will also appear as noun/noun-phrases.
exclude nouns that are qualities of other objects
(subjective, iterative).
Leave out global variables.
Manages
TEAM MANAGER 1:1
3 Deduce the relationships by searching for phrases such as:

MATCH Scored GOAL 1:N HAS

in
IS COMPOSED OF
REQUIRE A NUMBER OF
Takes M:N
STUDENT CLASS ETC...

7 8

2
 The Bus Company: Important noun phrases

A bus company owns a number of buses. Each bus is

allocated to a particular route although some routes may
have several buses. Each bus has a unique bus number. It is
important to store information about the seating capacity and Entities BUS
the make/type of all buses. Each route , distinguished by a ROUTE
STAGE
route number, passes through a number of towns. DRIVER
Information is available on the average number of TOWN
passengers carried per day for each route.

One or more drivers are allocated to each stage of a route,

which corresponds to a journey through some or all of the
towns on a route. Drivers have an employee number, a
name, address and sometimes a telephone number.

9 10

The Bus Company: Potential relationship pointers.

Relationships
A bus company owns a number of buses. Each bus is allocated
to a particular route although some routes may have several Relationship name Entities Degree Optionality
buses. Each bus has a unique bus number. It is important to store ALLOCATED TO Route, Bus 1:N oblig (?)
information about the seating capacity and the make/type of all PASSES THROUGH 1 Route, Town M:N oblig (?)
buses. Each route , distinguished by a route number, passes PASSES THROUGH 2 Stage, Town M:N oblig(?)
through a number of towns. Information is available on the DRIVER ALLOCATED TO Stage, Driver 1:N oblig (?)
ROUTE HAS STAGE Route, Stage 1:N oblig(?)
average number of passengers carried per day for each route.

One or more drivers are allocated to each stage of a route,

which corresponds to a journey through some or all of the towns
on a route. Drivers have an employee number, a name, address
and sometimes a telephone number.

11 12

3
 Construct an entity-relationship diagram to show corresponding
entities and their relationships.
Construct an entity-relationship diagram to show corresponding
entities and their relationships.

Relationship name Entities Degree Optionality

ALLOCATED TO Route, Bus 1:N oblig (?)
PASSES THROUGH 1 Route, Town M:N oblig (?) Revise:
PASSES THROUGH 2 Stage, Town M:N oblig(?) check each pair of entities for a possible relationship (!)
DRIVER ALLOCATED TO Stage, Driver 1:N oblig (?) look for non-obligatory relationships
ROUTE HAS STAGE Route, Stage 1:N oblig(?) look for redundant relationships
decompose many to many relationships.

13 14

Design the database for a programming language support

environment. In this environment, programmers produce
programs, which are written in given programming
Deduce the attributes for the entities provided and add surrogates. (A surrogate is languages. Each program is written by a given programmer,
an artificial identifier).
can call other programs, and can be used by given users.
Users are recognised by their log-in name; programmers are
BUS Bus Number, Capacity, Make, Type recognised by their log-in name and by their code number;
ROUTE Route Number, Ave passengers programs have compound names that include the program’s
STAGE StageID, Stagename name, the extension, and the programmer’s code number.
DRIVER EmpID, Name, Address, Telephone No.
Programs have a version number, a date, and a short
TOWN TownID, Name
description; some programs interact with DBMSs. each
DBMS maintains stored data in the form of relations, with
several attributes and one primary key. Each database is
defined by a database administrator who is a programmer
specialized in data management.

15 16