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 fromvan_reg 2711West Homes Ltd 0012NT Andrews Cres Dundee DD76 8TT P385 ASA 0010RT8721Arran House Inverness IV26 6TY KY51 AFZ 0014QW Gill St Stirling FK78 1MN YT71 7YE 0921Great Arwoods Plc. 0012NT92383 Abercrombie St, Aberdeen, AB15 7YU KY51 AFZ 0010RT87215 West Beach, Finchley NW9 8YU P385 ASA 0011AD6701The Lodge, Heathsville West Moore WM8 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 attributes client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost

Normalisation - UNF 2.Remove duplicate items client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance from to date time van_reg model make capacity fuel_type rental_cost

Normalisation - UNF 3.Choose a starting primary key –Any appropriate one will do! client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost

Normalisation - UNF 4.Indent repeating data to show the repeating group for the primary key selected client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost

Normalisation - UNF 5.Finally, to complete UNF give the relation a name and enclose it in brackets. client (client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost )

Normalisation – 1NF Making 1NF 1.Remove and name the repeating group UNF client (client_nbr client_name client_address client_telephone client_fax contact_person shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost ) towards 1NF client (client_nbr client_name client_address client_telephone client_fax contact_person) removal (shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost )

Normalisation – 1NF 2.Create the relationship by adding the foreign key client (client_nbr client_name client_address client_telephone client_fax contact_person) removal (shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost *client_nbr )

Normalisation – 1NF 3.Show Primary and Foreign keys client (client_nbr client_name client_address client_telephone client_fax contact_person) removal (shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_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 fromtodate 0012NT Andrews Cres Dundee DD76 8TT 28 Westfield Pl. Dundee DD75 7YH 23/02/ RT8721Arran House Inverness IV26 6TY Harbour House Stonehaven AB22 8YU 24/02/2004 timevan_regmodelmakecapacityfuel_ type rental_ cost client_ nbr 09:30P385 ASATransitFord11.89m 3 Petrol£ :30KY51 AFZConvoyLDV16.85m 3 Diesel£

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_nbr client_name client_address client_telephone client_fax contact_person) removal (shipment_nbr insurance_ref from to date time van_reg model make capacity fuel_type rental_cost *client_nbr )

Normalisation – 2NF 2NF client (client_nbr client_name client_address client_telephone client_fax contact_person) shipment (shipment_nbr insurance_ref ) removal (*shipment_nbr from to date time van_reg model make capacity fuel_type rental_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_name client_address client_telephone client_fax contact_person) shipment (shipment_nbr insurance_ref ) removal (*shipment_nbr from to date time *van_reg *client_nbr ) van (van_reg model make capacity fuel_type rental_cost) 2NF client (client_nbr client_name client_address client_telephone client_fax contact_person) shipment (shipment_nbr insurance_ref ) removal (*shipment_nbr from to date time van_reg model make capacity fuel_type rental_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 keys van (van_reg model make capacity fuel_type rental_cost) van (van_nbr van_reg model make capacity fuel_type rental_cost)

Referential Integrity Foreign keys must exist as primary keys or be NULL

Cascade Modifications

Cascade Deletions

Case Study 2

UNF customer(customer_id customer_name customer_address customer_postcode order_number order_date delivery_date quantity product_id product_name product_description unit_cost product_photo ) 1NF customer( 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 1NF customer(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 ) 2NF/3NF customer(customer_id customer_name customer_address customer_postcode) order_detail (*order_number quantity *product_id) product (product_id product_name product_description unit_cost product_photo) order (order_number order_date delivery_date *customer_id)

Simple guide When presented with a scenario to normalise the following stages are required: 1. To get to UNF a) From the scenario list all the attributes you can identify b) Identify any repeating group of attribute and indent them on the list c) Choose an attribute to act as a primary key d) Close the list with brackets and give it a name 2. To get to 1NF a) Form a new entity from the repeating group b) Include the primary key from UNF to act as foreign key in the new entity c) Identify the primary key in the new entity d) Add brackets and give it a name 3. To get to 2NF a) Identify and remove partial dependences making sure that primary keys are present as foreign keys in any new entities b) 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 3NF a) Identify and remove transitive dependencies again ensuring the primary/foreign key link b) Note: transitive dependent attributes and dependent on the primary key via a non-key attribute

E/R Diagram – Case Study 2

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 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

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.

User Interface Design Listing the User Interface Elements Functionality required of user interface Van DetailsCreate, amend, delete and browse van details Client and Removal Details Create, amend, delete and browse client details and related removals. Shipment InformationCreate, amend, delete and browse Shipment details Removal BookingsCreate, amend, delete and browse removal records Client DetailsCreate, amend, delete and browse client records List of ShipmentsDisplay and print List of shipments report Client ListDisplay 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 ReportDisplay 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

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