Unit 4 Normalisationand Relational Database Management Systems

Files, records and fields Information in computer-based filing systems is stored in data files. A file is a collection of related records. Related records means that each record in a file will contain the same sort of information as all the other records. A record must have at least one field. A field contains one individual item of data.

Computerised databases A database is a organised collection of related data. Use a database when you need to store lots of data Key Field In this table, each column is a different field Each row is a record Data is organised into FIELDS and RECORDS. The KEY FIELD contains an item of data that is UNIQUE to that record.

FLAT-FILE or RELATIONAL? A Flat-file database has all the data organised into ONE table. Many modern databases are described as being relational. A relational database stores data in tables that are linked together using common fields. A database is a structured collection of related data.

Members No ForenameSurnameAddress 1Address 2Tel NoVideo No 122EvansDaniel7 High StAberaeron LeesAnna2 Bridge St Lampeter EvansDaniel7 High StAberaeron Title Certificate Category Cost per day Date loaned Length of loan Date due Total cost Crash12 Comedy £3.0012/09/051 day13/09/05£3.00 Emma12Drama£3.0012/09/051 day13/09/05£3.00 War of the Worlds PGSci FI£3.5914/09/052 days16/09/05£3.50 Duplication in Flatfile

Linked data tables in a relational database Primary Key Foreign Key Primary Key Loans ID Primary Key

Normalisation

First Normal Form (1NF) A table is in first normal form if all the data values are atomic values In English, this means that there can only be one value per attribute –The following table records managers of shoe shops. One manager can be a manager of more than one shop ManagerShop ShawGloucester, Bristol JonesTrafalgar SmithAshford, Canterbury GregBrighton, Hove This is not in 1NF because each attribute does not contain a single value. For example, Shaw is manager of Gloucester and Bristol. To be in 1NF these values need to be separated

First Normal Form (Cont.) This is not in 1NF because the values are not atomic ManagerShop ShawGloucester, Bristol JonesTrafalgar SmithAshford, Canterbury GregBrighton, Hove  This is in 1NF because each cell has only 1 value ManagerShop ShawGloucester ShawBristol JonesTrafalgar SmithCanterbury SmithAshford GregBrighton GregHove

First Normal Form - Difficulties Terminology differences: –Atomic –Indivisible –Scalar Attributes to be careful of include: –Address – e.g 24 The Grange, Oxford. OX4 6JP is not scalar –Telephone – e.g is not scalar (code and number) –Atomic does not only refer to the data, but to the use of data. Just because you can split data does not means that you should. Telephone should only be split if you need to sort by code for example

Terminology: Primary Key A primary key is a unique value which allows each record to be identified CustomerIDFirstNameLastName 1BrianSmith 2HarryAdams 3JoeJones 4HarrySmith  FirstName or LastName cannot be primary keys as they contain duplicate and un-unique data. CustomerID uniquely identifies a row and is therefore suitable

Sometimes there is no single field appropriate as a primary key. In these circumstances, it is possible to select two fields which, when taken together create a unique value: OrderNoItemNoEmployeeNoCustomerNoItemNameQuantity Nut Bolt Washer Bolt Washer4 There are no unique fields, so the Primary Key is best suited by OrderNo and ItemNo taken together

Functional Dependence Functional Dependency –If you know the length, height and width of a room, you can calculate its volume: Volume = width x height x length –Volume is functionally dependent on the length, height and width –Consider the following database, which holds orders. Each order is entered by a specific employee (only one employee is allowed to enter an order)

Functional Dependency OrderNoItemNoEmployeeNoCustomerIDItemNameQuantity Nut Bolt Washer Bolt Washer4 EmployeeNo is functionally dependent on OrderNo OrderNo functionally determines EmployeeNo OrderNo is the determinant The relationship is only one way

Functional Dependency Functional Dependency – More examples –A table containing PupilName and PupilID PupilName is functionally dependent on PupilID PupilIDPupilName 34Smith 65Sams 87Hodd 654Smith  If you know the PupilID you can find any PupilName, but if you only have the name, it is not always possible to find the PupilID

Second Normal Form (2NF) To be in 2NF a table must: –Be in 1NF (obviously) –Have all non key fields fully functionally dependant on the primary key In English: –A non key field is one that is not part of the primary key –It means that you need to use the primary key to determine the value of the other fields in the table If you can find the value of other fields without using the primary key, you should remove that field from the table and place it in a separate table

Second Normal Form This table is not in 2NF –The primary key is OrderNo and ItemNo (combined) –The quantity is functionally dependant on the Primary Key The ItemName is functionally dependant on the ItemNo not the primary key The CustomerID is functionally dependant on the OrderNo, not the Primary Key The EmployeeNo is functionally dependant on the OrderNo, not the primary key OrderNoItemNo EmployeeNoCustomerID Item Name Quantity Bolt Washer Nut Bolt4

Second Normal Form (Cont.) We need to remove ItemName, CustomerID and EmployeeNo from the table – this involves setting up new tables OrderNo*ItemNo*EmployeeNoCustomerIDItemNameQuantity Bolt Washer Nut Bolt4

Second Normal Form (Cont.) EmployeeNo and CustomerNo are functionally dependant on the OrderNo, therefore they are suited for a new table: Orders OrderNo* EmployeeNo CustomerNo  The Quantity is functionally dependant on both the OrderNo and the ItemNo, therefore they have a new table: OrderSpec OrderNo* ItemNo* Quantity  We are left with the ItemName. This is functionally dependent on the item number only, therefore a new table is required: Stock ItemNo* ItemName

Second Normal Form (Cont.) Do not be afraid to create new tables as appropriate but make sure that you are not breaking tables down for the sake of doing so. It should be appropriate and have advantages Make sure that each table you create is in both 1NF and 2NF as appropriate Ensure the original table can be rebuilt from the data contained in the new table

Second Normal Form A slightly different approach: –Each relation should only contain information about a single entity. If it contains information about more than one entity, then the table needs to be broken down –For example: HOUSE(HouseName, Street, Town, City, Postcode, CityPopulation) –The CityPopulation is a separate entity to the house details, so it needs to be removed to a separate table –To create a separate table, remove the attribute and a copy of the attribute on which it is dependent. The copy becomes the link between the two tables HOUSE(HouseName, Street, Town, City, Postcode) CITY(City,CityPopulation)

Third Normal Form (3NF) To be in 3NF a table must: –Be in second (and therefore also first) normal form –Have all non key fields non transitively dependent on the primary key In English: –Fields which do not form part of the primary key must always be solely dependent on the primary key and not on anything else, such as another non key field –Aside: it is usually difficult to create a table which is not in 3NF – usually you will jump straight from 1NF to 3NF!

Third Normal Form (Cont.) In the following example, the company keeps data on its employees. Each employee is allocated a city where they work and each city is given a CityID. Their salary is dependent on the type of job they do. Initially check the table below to ensure it is in 2NF before continuing EmployeeNoLastNameFirstNameCityCityIDTypeSalary 1TaylorSarahCanterburyCBManager£22,000 2JonesSamLondonLNSales Person£15,000 3SmithSallyBirminghamBMAdmin Assistant£13,500

Third Normal Form (Cont.) CityID is dependent on City Salary is dependent on Type Therefore this table is not in 3NF EmployeeNoLastNameFirstNameCityCityIDTypeSalary 1TaylorSarahCanterburyCBManager£22,000 2JonesSamLondonLNSales Person£15,000 3SmithSallyBirminghamBMAdmin Assistant£13,500

Third Normal Form (Cont.) Remove City from the table and create a new cities table Remove Salary from the table and create a job type table Staff EmployeeID* LastName FirstName CityID TypeID Cities CityID* City JobTypes TypeID* Salary