MS Access

Most A2 projects use MS Access Has sufficient depth to support a significant project. Relational Databases. Fairly easy to develop a good user interface. It’s widely available !

MS Access However, it is a complex package ! ALWAYS more than one way to do a task. Books on it are hundreds of pages long and daunting for students (and staff). To do some tasks VBA is required and again books on VBA are hundreds of pages long.

Database Design

The user should only see the User Interface. Good, consistent design is important here. But, encourage students to concentrate on what gets the marks – not too much time on “eye-candy”. However, the heart of a good database application is the data itself and getting the design of this right, at the start, is the key to a successful project.

Lets get NORMAL The concept of Normalisation is covered in the theory element of all boards. Normal Forms First normal form Second normal form Third normal form Also you may come across – but not required for the course ! Boyce-Codd normal form Fourth normal form Fifth normal form Domain/key normal form Sixth normal form More info on NF1-6 If interested.

Data NOT Normalised Simple HOTEL BOOKING – Flat file database. Click to Open Database The initial Flat file is not normalised and includes many of the problems associated with such an approach. Open the database and spot them - view the video for my observations. FIELD LIST Click to Run Video Access Examples>Normalising>UnNormalised Data

First to Third Normal Forms First Normal Form (If NOT in 1NF then searching becomes difficult and space is often wasted.) Data should be “atomic” – each field should store a single item of data there must be no repeated fields. So to get data into 1NF Make a separate table for each set of related attributes give each table a primary key.

Starting point This may be the first attempt however there are still problems: Party leaders can make multiple bookings and each room can be booked by many leaders. We still have the repeated fields for rooms booked. Party Leaders Bookings

Dealing with the repeated data Rooms Create a new Entity – Rooms A new key RoomID has been created to allow flexibility in room naming while maintaining a simple compact key.

We still have a Many to Many Relationship to remove. Each customer may make many bookings Each booking may have many rooms Each room may be in many bookings Party Leaders Bookings Rooms Foreign Key

Introduce Booking_Details Entity Now in FIRST NORMAL Form Party Leaders Bookings Rooms Booking_Details has a compound key. Foreign Key Booking_Details

In Second Normal Form if is already in first normal form has no fields that aren't dependent on the whole of the key Only entities with a composite key need to be checked. Is a non-key field dependent on only part of the key?

Party Leaders Bookings Rooms Only Booking_Details has a compound key and because we had resolved the repeated fields with the Rooms Table first NO non-key field in Booking_Details is dependent on part of the key. So we are already in SECOND Normal Form ! Foreign Key Booking_Details

However, to illustrate the point If we had structured the Bookings_Details like this Bookings_Details Then the RoomName and Capacity would only have been dependent on part of the key (RoomID) and we would not have reached SECOND Normal Form.

Resolve it by: Bookings_Detail s Removing the dependent fields to a new table Copy the partial key into the new table and link back through this. Bookings_Details Rooms Foreign Key

Access Relationships table in SECOND Normal Form version

Party Leaders A database is in THIRD Normal Form if it: is already in second normal form it has no non-key dependencies i.e. there are no fields that are dependent on fields that are not part of the key. In the Party Leaders table : Town and County could be determined from the PostCode. So, to reach THIRD Normal Form remove them to a new table and link via postcode. Foreign Key

THIRD Normal Form BUT… Party Leaders Bookings Rooms Foreign Key Booking_Details Foreign Key

Don’t store what can be easily calculated when needed. So remove Number_of_Nights from Bookings Party Leaders Bookings Rooms Foreign Key Booking_Details Foreign Key

Final Access Relationship Diagram

Alternative - why might this be better in practice?

Final Thoughts In practice, thinking about the Entities involved usually will get you to 3NF directly. So don’t start from a flat file and work through ! [But, students do need to know the theory.] Few large scale commercial databases operate fully Normalised – keeping frequently used data in the same table (Postcode, and postal town?) can save considerable lookup time. So, De-normalisation can sometimes be justified. But, NOT often within the scale of an A level project. {Is it worth an extra table for PostCode & if so should PostCode be split into Area and Street codes????}

For all entities “Every attribute is dependent on the key, the whole key and nothing but the key” So help me Codd. END

Full List of Normal Forms 1NF Eliminate Repeating Groups - Make a separate table for each set of related attributes, and give each table a primary key. 2NF Eliminate Redundant Data - If an attribute depends on only part of a multi-valued key, remove it to a separate table. 3NF Eliminate Columns Not Dependent On Key - If attributes do not contribute to a description of the key, remove them to a separate table. BCNF Boyce-Codd Normal Form - If there are non-trivial dependencies between candidate key attributes, separate them out into distinct tables. 4NF Isolate Independent Multiple Relationships - No table may contain two or more 1:n or n:m relationships that are not directly related. 5NF Isolate Semantically Related Multiple Relationships - There may be practical constrains on information that justify separating logically related many-to-many relationships. ONF Optimal Normal Form - a model limited to only simple (elemental) facts, as expressed in Object Role Model notation. DKNF Domain-Key Normal Form - a model free from all modification anomalies.