Databases

Topic 7: Database Design

© NCC Education Limited

 Database Design Topic 7 - 7.2

Systems Analysis

• The art of understanding and documenting the

requirements of a given set of users within the
context of an organisation.
 Database Design Topic 7 - 7.3

Systems Development

• The development of the whole system from

beginning to end. This might include a database,
applications, a network etc.
 Database Design Topic 7 - 7.4

Approaches

• Traditional systems development lifecycle (SDLC)

or ‘waterfall’ approach

• Iterative approaches
 Database Design Topic 7 - 7.5

The Waterfall Lifecycle

Strategy and
Planning

Feasibility Study

Systems Analysis
 Database Design Topic 7 - 7.6

Generic Systems Development Lifecycle - 1

1. Strategy and planning

2. Feasibility study
3. Systems analysis (or analysis)
4. Design
5. Implementation
6. Maintenance
 Database Design Topic 7 - 7.7

Generic Systems Development Lifecycle - 2

1. Strategy and planning

2. Feasibility Study
3. Systems Analysis (or Analysis)
4. Design
5. Implementation
6. Maintenance
 Database Design Topic 7 - 7.8

Problems with Waterfall Approach

• Users have not communicated requirements

properly
• Users have not understood their own needs
• Analyst misunderstood
• Omission

Very expensive to fix changes to the

requirements
 Database Design Topic 7 - 7.9

Iteration
Evaluation

Design and Analysis

Prototyping

Design and
Analysis Prototyping

Evaluation
 Database Design Topic 7 - 7.10

Prototypes and Prototyping

• Prototype – a first or original example of

something from which others have or will be
developed
• Prototyping – the process whereby a model is
built of part of the envisaged system and user
feedback is gathered. Part of the requirements
gathering process
• Note: a prototype is a thing. Prototyping is
something we do.
 Database Design Topic 7 - 7.11

Database Design - 1

Analyst Programmer

Systems Analyst Database Developer

Good communications skills – reading,

writing, listening. Interview skill.
Knowledge of techniques to document
requirements etc. etc. etc.
 Database Design Topic 7 - 7.12

Database Design - 2
Moving from a set of requirements

To implementing these with Database Technology

 Database Design Topic 7 - 7.13

Phases of Database Design

• Conceptual design

• Logical design

• Physical design

https://online.visual-paradigm.com/knowledge/visual-
modeling/conceptual-vs-logical-vs-physical-data-model
 Database Design Topic 7 - 7.14

Conceptual Database Design

• Investigation of data needed to support system

• Does not take account of physical implementation
or data model
In what format
is the data?

How is this
What data is held? the data
used?
 Database Design Topic 7 - 7.15

Logical Design

• Data is investigated and design is undertaken

without regard to the DBMS product that will be
used, but that data model (usually the relational
model) is known.
Normalisation Entity relationship
diagram

Design transactions
 Database Design Topic 7 - 7.16

Physical Design
• From entities to tables
• Designing the base relations

Indexing Denormalisation

Query tuning View creation

 Database Design Topic 7 - 7.17

Where We Are Now

• Logical design
– identifying entities, normalisation

• Physical design
– Move from entities to tables is one of the key activities
here involving what is known as designing the base
relations.
– Also involves indexing, denormalisation, view creation
and query tuning
 Database Design Topic 7 - 7.18

Data Dictionary
Domains
Domain StudentType varchar, length 30, must be ‘Overseas’,’Home’
Domain City varchar length 30
Base Relations
student(student_id Number NOT NULL,
address_line1 Varchar (30) NOT NULL
address_line2 Varchar (30) NOT NULL
city City
student_type StudentType NOT NULL DEFAULT ‘Home’
PRIMARY KEY (StudentID)
FOREIGN KEY (City) REFERENCES City (City_name));
 Database Design Topic 7 - 7.19

CASE Tools
• Computer Aided Software Engineering
– Design tools
– Documentation tools
– Code generators
• Enable developers to store entity definitions,
domain definitions etc.
• From these, the base relations can automatically
be generated.
• Can also generate the scripts to create the physical
data
 Databases
Topic 8: Supporting Transactions

© NCC Education Limited

 Database Design Topic 7 - 7.21

Scope and Coverage

This topic will cover:

• Business rules
• Identifying and documenting transactions
• ACID Criteria
• CRUD analysis
• Views and de-normalisation
 Database Design Topic 7 - 7.22

Boat Rental System - 1

1 0...N 0...N 1
BOAT RENTAL CUSTOMER

1
0...N

DAMAGE
 Database Design Topic 7 - 7.23

Boat Rental System - 2

Domain Base Relation
DamageType varchar length 30 Rental(
boat_id NUMBER NOT NULL,
Base Relation customer_id NUMBER NOT NULL,
Boat( rental_start_date DATE NOT NULL,
boat_id NUMBER NOT NULL, rental_end_date DATE NOT NULL,
boat_name VARCHAR(30) NOT NULL PRIMARY KEY(boat_id, customer_id,
PRIMARY KEY(boat_id); rental_start_date),
FOREIGN KEY(boat_id) REFERENCES Boat
Base Relation (boat_id),
Customer( FOREIGN KEY (customer_id) REFERENCES
customer_id NUMBER NOT NULL, Customer(customer_id));
customer_name VARCHAR(30) NOT
NULL, Base Relation
customerAddress VARCHAR(60) NOT Damage(
NULL, boat_id NUMBER NOT NULL,
PRIMARY KEY (customer_id); customer_id NUMBER NOT NULL,
rental_start_date DATE NOT NULL,
damage_type DamageType);
 Database Design Topic 7 - 7.24

What is a Business Rule?

• A procedure/ process/ way of doing something/

custom/ method that is particular to a business
and needs to be taken account of in the
structure of data and/or the design of an
application.
 Database Design Topic 7 - 7.25

Transactions
• Transactions are the units of work in a database system.
• ACID: A transaction must be
– Atomic
• either complete in its entirety or have no effect whatsoever
– Consistent
• conform to existing constraints in the database,
– Isolated
• not affect other transactions
– Durable
• it must get written to persistent storage
 Database Design Topic 7 - 7.26

Transactions
• Transactions can be made up of one or more
operations. Operations are usually defined as:

• CREATE or INPUT
• RETRIEVE
• UPDATE
CRUD or IRUD
• DELETE
 Database Design Topic 7 - 7.27

Identify Transactions

What are they? What tables do they affect?

How often do they run?

What do they do?

How many rows do they affect? What attributes do they affect?

 Database Design Topic 7 - 7.28

What to Look at
• Transactions that are frequent and could affect the
efficiency and performance of the database
• Critical transactions vital to the running of the business
• Transactions that take place in peak periods

• How to Investigate:
– Look at each transaction and work out what tables it will affect.
– Work out if there are tables that are used by many transactions.
– Look at how the data is affected by the transaction.
 Database Design Topic 7 - 7.29

Transactions in the Boat Hire System

a. Enter the details of all the boats. Update any details for
customers. Delete boats.
b. Enter the details for customers. Update any details for
customers.
c. Enter the details for hiring of boats.
d. Enter the details for any damage to boats.
e. List the details of all the boats.
f. List the details of all the customers; their hire and for which
boats.
g. List the details for damage, to which boats, during which
hire periods and for which customers.
h. Provide a summary of the hires for a particular period.
 Database Design Topic 7 - 7.30

Discussion Session
Transaction/ A B C D E F G H
Relations
Boat
Customer

Rental
Damage

Draw this diagram and then look at the transactions

again.
 Database Design Topic 7 - 7.31

Competed CRUD Matrix

Transaction
A B C D E F G H
/Relations
Boat CD R R R

Customer U CU R R

Rental C R R R
Damage C R
 Database Design Topic 7 - 7.32

Attribute Level

• A transaction may affect some attributes in a table

but not others.
• Or it may affect different attributes in the same
table in different ways, e.g. updating one and
deleting another.
 Database Design Topic 7 - 7.33

Analysing Tranactions

• CRUD
• Does the transaction involve any predicates?
– specific conditions in the where clause
• Attributes
– Which attributes are involved
• Frequency
– It might affect performance. Will the transactions
perform the same during periods of high activity?
 Database Design Topic 7 - 7.34

Transaction Analysis Form

Transaction Analysis Form
1st Jan 2010
Transaction (e) List the details of all boats
Transaction volume
Average 1 per day
Peak 100 times per day during production of promotional literature (June)
Select boatID, boatName
From Boats

Boats (50) Boats

(50)
Access Entity Type of Access Average Number
Peak Number
1 Boats R 1 * 50
100 * 50
 Database Design Topic 7 - 7.35

Indexes

• Improve performance
– Transaction time
• Creating entries in a special structure, so that
makes it easier to find a record.
 Database Design Topic 7 - 7.36

Performance

• Increasingly, databases contain large amounts of

data...
– Performance may be good with small number of records
– Scalability
• The rate at which a query can return an answer, can be slowed
when it has to sort through large numbers of records.
• Performance becomes an issue...
 Database Design Topic 7 - 7.37

Applications
• The software that is used to access the data in
a database...

Websites Forms

Queries Types of
Application

Reports Batch processes

 Database Design Topic 7 - 7.38

Roles in a System

• Not every user is the same.

• Users will need to access different parts of the

system and access it in different ways.
 Database Design Topic 7 - 7.39

Boat Hire System - Roles

• Manager
– should be able to access all parts of the system, because
their role means that they might have to add and delete any
data and be able to see anything.
• Admin Assistant
– just carries out routine tasks, such as adding any new
customers and recording damage to boats.
Table/User Boat Customer Rental Damage

Manager CRUD CRUD CRUD CRUD

Admin
R CRU CRU CRU
Assistant
 Database Design Topic 7 - 7.40

SQL Facilities to Manage Roles

• Grant – gives a particular role or user in the

database system access to an object (such as a
table).

• Revoke – removes access to an object (such as a

table) from a particular role or user in the database
system.
 Database Design Topic 7 - 7.41

Grant

• Grant create on Boat to Admin

• Grant all on Boat to Manager

 Database Design Topic 7 - 7.42

Revoke

• Revoke all on Boat from Admin

• Revoke delete on Boat to Manager

 Database Design Topic 7 - 7.43

De-Normalisation

• We have created a database following all the rules

of normalisation.

• Now we can break them to make the database

work quicker and perform better!
 Database Design Topic 7 - 7.44

Improving Performance with the Use of Views

A view is a virtual table Query

Table 1
View of
selected rows
Table 2
or columns of
these tables
Table 3
 Database Design Topic 7 - 7.45

View in the Boat Hire System

• What view would support the Transaction G?

– List the details for damage: which boats, during which
hire periods and for which customers?
• Without a view, this query has to access all 4
tables.
• Do this as part of self study.
 Database Design Topic 7 - 7.46

Topic 8 – Supporting
Transactions
Any Questions?