Case Study 1

Normalisation - the easy way?

• Read Case Study 1 • produce a 3NF.• show consideration of UNF, 1NF and

2NF.

Normalisation

• Problems with database design before UNF/1NF– Non atomic data i.e. address

– Multi-valued cells/repeating groups

client_nbr

client_name

shipment_nbr

insurance_ref

from van_reg

2711 West Homes Ltd

0012 NT9238 15 Andrews CresDundeeDD76 8TT

P385 ASA

0010 RT8721 Arran HouseInvernessIV26 6TY

KY51 AFZ

0014 QW1211 267 Gill StStirlingFK78 1MN

YT71 7YE

0921 Great Arwoods Plc.

0012 NT9238 3 Abercrombie St, Aberdeen, AB15 7YU

KY51 AFZ

0010 RT8721 5 West Beach,FinchleyNW9 8YU

P385 ASA

0011 AD6701 The Lodge,HeathsvilleWest MooreWM8 3HJ

D842 YSA

Normalisation

• Only one way to normalise – the Structured Systems Analysis and Design Method (SSADM)

• Standardised across all units in framework.

• Progression from Int 2 to AH • Complexity of problems at Higher

clearly defined– UNF – 1 entity from 2 sources – 1NF – 2 entities– 2NF – 3 entities– 3NF – 4 entities

• AT MOST COMPLEX!

Normalisation - UNF

Making a UNF

1. List all attributesclient_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_personshipment_nbrinsurance_reffromtodatetimevan_reg

van_regmodelmakecapacityfuel_typerental_cost

Normalisation - UNF

2. Remove duplicate items

client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_personshipment_nbrinsurance_reffromtodatetimevan_regvan_regmodelmakecapacityfuel_typerental_cost

client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_personshipment_nbrinsurancefromtodatetimevan_regmodelmakecapacityfuel_typerental_cost

Normalisation - UNF

3. Choose a starting primary key– Any appropriate one will do!

client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_personshipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost

Normalisation - UNF

4. Indent repeating data to show the repeating group for the primary key selected

client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_person

shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost

Normalisation - UNF

5. Finally, to complete UNF give the relation a name and enclose it in brackets.

client ( client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_person

shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost )

Normalisation – 1NF

• Making 1NF

1. Remove and name the repeating group

UNFclient ( client_nbr

client_nameclient_addressclient_telephoneclient_faxcontact_person

shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost )

towards 1NF client ( client_nbr

client_nameclient_addressclient_telephoneclient_faxcontact_person)

removal ( shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost )

Normalisation – 1NF

2. Create the relationship by adding the foreign key

client ( client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_person)

removal ( shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost *client_nbr)

Normalisation – 1NF

3. Show Primary and Foreign keys

client ( client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_person)

removal ( shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost *client_nbr)

Normalisation – why 2NF

Problems with database design• Data redundancy • Data redundancy refers to the amount

of data in a database that is not required. The aim of good relational database design is to reduce data redundancy by:– ensuring that each item of data is stored only once

within the database and– ensuring that only data that cannot be calculated

from other data held in the database is stored.

• Data duplication• Insertion, modification, deletion

problems

Normalisation – why 2NF?

• Insertion problem • Modification

problem• Deletion problem

shipment_nbr

insurance_ref

from to date

0012 NT9238 15 Andrews CresDundeeDD76 8TT

28 Westfield Pl.DundeeDD75 7YH

23/02/2004

0010 RT8721 Arran HouseInvernessIV26 6TY

Harbour HouseStonehavenAB22 8YU

24/02/2004

time van_reg model make capacity fuel_type

rental_cost

client_nbr

09:30 P385 ASA Transit Ford 11.89m3 Petrol £90.00 2711

08:30 KY51 AFZ Convoy LDV 16.85m3 Diesel £100.00 2711

Normalisation – 2NF

• Only applies to compound keys (we no longer refer to keys as concatenated)

• “Is the key needed to find all the values in the relation or will just part of the key do?”

• 1NF copies the foreign key, 2NF & 3NF leave it behind!

Normalisation – 2NF

1NF before 2NF

client ( client_nbrclient_nameclient_addressclient_telephoneclient_faxcontact_person)

removal ( shipment_nbrinsurance_reffromtodatetimevan_regmodelmakecapacityfuel_typerental_cost *client_nbr)

Normalisation – 2NF

2NF client ( client_nbr

client_nameclient_addressclient_telephoneclient_faxcontact_person)

shipment ( shipment_nbrinsurance_ref )

removal ( *shipment_nbrfromtodatetimevan_regmodelmakecapacityfuel_typerental_cost*client_nbr )

Normalisation – why 3NF?

• There is still redundant data in the relations/tables and possible insertion, deletion and modification problems.

• Remove transitive dependency – dependencies which are non-key.

• Remove attributes and leave non-key item in existing relation

• Non-key item also primary key of new relation.

Normalisation - 3NF

3NF client ( client_nbr

client_nameclient_addressclient_telephoneclient_faxcontact_person)

shipment ( shipment_nbrinsurance_ref )

removal ( *shipment_nbrfromtodatetime*van_reg*client_nbr )

van ( van_regmodelmakecapacityfuel_typerental_cost)

2NF client ( client_nbr

client_nameclient_addressclient_telephoneclient_faxcontact_person)

shipment ( shipment_nbrinsurance_ref )

removal ( *shipment_nbrfromtodatetimevan_regmodelmakecapacityfuel_typerental_cost*client_nbr )

Normalisation – Surrogate

Keys

• Use surrogate keys

– Often the primary key for a relation will be unsuitable because:

• Primary key too complex• Not sufficiently unique (e.g. name)

– To remove meaningful keysvan ( van_reg

modelmakecapacityfuel_typerental_cost)

van ( van_nbrvan_regmodelmakecapacityfuel_typerental_cost)

Referential Integrity

• Referential Integrity• Foreign keys must exist as primary keys

or be NULLshipment_nbr

0012

0010

0014

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

3 Croft Court, Westhill, AB56 7YU

to

28 Westfield Pl.,Dundee, DD75 7YH

Harbour House, Stonehaven, AB22 8YU

18 Drummond Pl, Aberdeen, AB11 8TR

The Manor, Blairgowrie, FK89 7YU

date

23/02/2004

24/02/2004

23/02/2004

25/02/2004

time

09:30

08:30

08:30

08:30

van_id

001

002

002

003

client_nbr

2711

2711

0921

2281

client_nbr

2711

0921

client_name

West Homes Ltd

Great Arwoods Plc.

client_address

14 Argos St, Glasgow, G23 9UJ

18 New Parlie St, Edinburgh, EH87 9QQ

client_telephone

0312 123198

0327 989127

client_fax

0312 123199

0327 981111

contact_person

John Michael Osbourne

Vicky Kenn

Cascade Modifications

shipment_nbr

0012

0010

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

time

09:30

08:30

08:30

van_id

001

002

002

client_nbr

2711

2711

0921

client_nbr

2711

0921

client_name

West Homes Ltd

Great Arwoods Plc.

shipment_nbr

0012

0010

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

time

09:30

08:30

08:30

van_id

001

002

002

client_nbr

7812

7812

0921

client_nbr

7812

0921

client_name

West Homes Ltd

Great Arwoods Plc.

Modifications cascaded to maintain referential integrity between client and removal

shipment_nbr

0012

0010

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

time

09:30

08:30

08:30

van_id

001

002

002

client_nbr

2711

2711

0921

client_nbr

7812

0921

client_name

West Homes Ltd

Great Arwoods Plc.

Without cascading the modification the relationship between client 7812 and the related removals is lost.

Changed client_nbr 2711 to 7812

removal

removal

client

client

client

removal

Cascade Deletions

shipment_nbr

0012

0010

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

time

09:30

08:30

08:30

van_id

001

002

002

client_nbr

2711

2711

0921

client_nbr

2711

0921

client_name

West Homes Ltd

Great Arwoods Plc.

shipment_nbr

0012

0010

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

van_id

001

002

002

client_nbr

2711

2711

0921

client_nbr

2711

0921

client_name

West Homes Ltd

Great Arwoods Plc.

shipment_nbr

0012

0010

0014

from

15 Andrews Cres, Dundee, DD76 8TT

Arran House, Inverness, IV26 6TY267

3 Abercrombie St, Aberdeen, AB15 7YU

time

09:30

08:30

08:30

van_id

001

002

002

client_nbr

2711

2711

0921

client_nbr

2711

0921

client_name

West Homes Ltd

Great Arwoods Plc.

Without cascading the deletion, referential integrity is broken because there is no matching primary key value for the foreign key client_nbr in removal

time

09:30

08:30

08:30

Cascading the deletion maintains referential integrity.

• Case Study 2

Case Study 2

UNFcustomer( customer_id

customer_namecustomer_addresscustomer_postcode

order_numberorder_datedelivery_datequantityproduct_idproduct_nameproduct_descriptionunit_costproduct_photo )

1NFcustomer( customer_id

customer_name

customer_address . customer_ postcode)

order_detail ( order_number

order_date

delivery_date

quantity

product_id

product_name

. product_description

unit_cost

product_photo

*customer_id )

Case Study 2

1NFcustomer( customer_id

customer_namecustomer_addresscustomer_postcode)

order_detail ( order_numberorder_datedelivery_datequantityproduct_idproduct_nameproduct_descriptionunit_costproduct_photo*customer_id )

2NF/3NFcustomer( customer_id

customer_namecustomer_addresscustomer_postcode)

order_detail ( *order_numberquantity*product_id)

product ( product_idproduct_nameproduct_descriptionunit_costproduct_photo)

order ( order_numberorder_datedelivery_date*customer_id)

Simple guide

When presented with a scenario to normalise the following stages are required:

1. To get to UNFa) From the scenario list all the attributes you can identifyb) Identify any repeating group of attribute and indent them on the listc) Choose an attribute to act as a primary key d) Close the list with brackets and give it a name2. To get to 1NFa) Form a new entity from the repeating groupb) Include the primary key from UNF to act as foreign key in the new entityc) Identify the primary key in the new entityd) Add brackets and give it a name3. To get to 2NFa) Identify and remove partial dependences making sure that primary keys

are present as foreign keys in any new entitiesb) Note: this will only apply where there is a compound key (i.e. more than

one attribute) in a 1NF entity and where some non-key attributes are dependent only on part of the primary key

4. To get to 3NFa) Identify and remove transitive dependencies again ensuring theprimary/foreign key linkb) Note: transitive dependent attributes and dependent on the primary key

via a non-key attribute

E/R Diagram – Case Study 2

order

customer

product1

M

1

1

product id

product_name

product_description

unit_cost

product_ photo

product_id

order_number

order_date

customer_id

delivery_ date

customer_name

customer_id

customer_address

customer_postcode

order_detailhas MM

quantity

ordered

places

order_number

Weak Entities

• Strong key does not include attributes from other entities e.g. client_nbr

• Weak entities have compound keys which include attributes from other entities e.g. entity removal has key of shipment_nbr and client_nbr

• Weak entities are more complex to implement in an RDBMS. The weakness can be removed by using a surrogate key.

• Weak relationship links weak entity to source of key(s).

E/R Diagram showing weak entities and relationships

Implementation

Implementation

• Implementation of database system based on a data model, including entity/relationship diagram and data dictionary.

• Description and implementation of complex queries including: – sorting (multiple fields, ascending/descending) – searching (multiple fields, across linked/related

tables) – calculating and summarizing (including count, sum

and average)

Implementation

• Use of related tables as sources for data entry (including lookups).

• Enforcement of data integrity through validation.

• Implementation of simple macros and scripting for navigation

Graphical Query Tools

• Queries like this in MS Access are SELECT queries

Graphical Query Tools

• NaviCat for MySQL

List of available

tables

Area shows

tables in the

query

Relationship

between tables

Fields selected

for query

Reports

• Reports have a structure– Report Header/Footer– Page Header/Footer– Grouping header/footer– Detail band

• To get the best from a report, we need to understand how it is constructed

• Reports make use of functions– SUM– MAX/MIN– AVG– COUNT– Date/Time functions– Etc.

Report Header or Title -Information which identifies the report: title, organisation

Page Header -Information which appears at the top of each page in the report

Group Header -Segment which identifies data which is similar according to grouping criteria

Detail - Rows of data corresponding to records in table/view that have same grouping criteria

Group Footer – similar to a group header but after the detail of the report.

Page Footer – Information which appears at the botton of each page in the report

Summary or Report Footer – Information which is displayed in summary format is shown in the summary area. This appears at the end of the report and might include overall totals, averages etc.

User Interface Design

• Listing the User Interface Elements

Functionality required of user interface

Van Details Create, amend, delete and browse van details

Client and Removal Details

Create, amend, delete and browse client details and related removals.

Shipment Information Create, amend, delete and browse Shipment details

Removal Bookings Create, amend, delete and browse removal records

Client Details Create, amend, delete and browse client records

List of Shipments Display and print List of shipments report

Client List Display and print Client List

Clients and Removals Report

Display and print a report detailing all clients and related removals after a specific date.

Vans Booked Report Display and print a list of all Vans booked on jobs for a particular day.

Types of user interface

• Forms• Menus• Switchboards• Command Line• Direct Manipulation

Implementation

• Implementation Demos–Microsoft Access–Apache/PHP/MySQL

• Uses free opensource software• Download a windows installable version from

http://www.perfectpapers.net

Course Planning

• Sample Plan for Relational Database Systems unit

– Plan using Higher Information Systems textbook – Week 1 – Information and Information Systems

(Chapter 1) and Database Fundamentals (Chapter 2)

– Week 2 – Database Fundamentals (Chapter 2) and Data Modelling – Building Blocks (Chapter 3)

– Week 3 – Data Modelling – Tools (Chapter 4)– Week 4 and Week 5 – Normalisation (Chapter 5)– Week 6, Week 7 and Week 8 – Implementation and

coverage of Queries (Chapter 6), Reports (Chapter 7) and User Interface Design (Chapter 8). Including completion of Checklist for NAB

– Week 9 - Revision and NAB Assessment