Normalisation

NoKats Dog Club A club formed since Keeps records of members and their dogs on index cards. Cards are managed by the secretary and used for reference e.g. to inform members of shows. Excellent system in the early days as there were only 100 or so members! Now membership has grown to well over This is proving a real headache for the secretary.

Customer Record for the NoKats Dog Club Record Number: Initial: Surname: Title: Sex: Postcode: Tel No: Dog Details: NameSexDofBBreedOrigen of Breed Breed life expectancy Woof!

Problems for the secretary Takes a long time to find an individual member’s record as there are now 5000 of them. –Especially true if you use multiple search criteria. Takes even longer to find a dogs record. –Especially if the member’s details are unknown for some reason. Finding all dogs born after a certain date. Sometimes records need to be sorted into a different order. When records are filled in some details are recorded over and over again. Details for letters have to be manually transferred from the cards (i.e. no mail merging!!!) New records sometimes contain spelling mistakes or errors in details about the dog, such as life expectancy etc.

Why would a computerised system help? New records can be monitored for errors using validation rules. All records can be easily sorted by different fields and multiple fields. Easy to search and find records. Reports can be generated showing search results. Mail merge is possible thus making letter writing a lot easier.

The flat file db IDInitialLast Name TitlePost code TelDog Name GenDofBBreedOriginL/E Years 1AFishMrsCV35QW BongoM21/08/99PoodleChina5 1AFishMrsCV35QW HiccupF08/08/98PoodleChina5 1AFishMrsCV35QW RizlaF09/09/00PoodleChina5 1AFishMrsCV35QW GovF11/01/01AlsatianGermany10 2CHereMrsCV27RF DLapidatedMrCV14RR ManicM11/01/01PoodleChina5 3DLapidatedMrCV14RR BlipF02/02/01SpanielFrance7 4XRayMsCV12YY YNottMrCV24TT RuffM08/08/00PoodleChina5 5YNottMrCV24TT AddiM10/02/00PoodleChina5 5YNottMrCV24TT CatnipF10/03/99PoodleChina5 5YNottMrCV24TT EmmiF11/03/01PoodleChina5 5YNottMrCV24TT GovF11/01/01AlsatianGermany10 ……………………………… ……………………………… ………………………………

Good points about flat files Quick and easy to set up. Ideal for smaller databases. They provide many of the searching and sorting tools required by most users of databases.

Problems with flat files Lots of repeated data makes the database larger. Searching becomes inefficient if using repeated data. Dogs don’t have their unique ID. –Can’t add a new breed until a member introduces one to the club. Lots of details are held over and over again. If one of the members changed their name ALL their records would need to be changed. If a member joined with lots of dogs their records would have to be added over and over again. –Adding an anomaly.

Improving the flat file design Having two smaller tables is no different to having one large one…as long as we link them. Each member can own many dogs. Each dog is owned by one member. A table for members’ details A table for dogs’ details owns is owned by

Member IDInitialLast NameTitlePost codeTel 1AFishMrsCV35QW CHereMrsCV27RF DLapidatedMrCV14RR XRayMsCV12YY YNottMrCV24TT

Dog DogIDDog NameGenDofBBreedOriginL/E YearsID 1BongoM21/08/99PoodleChina51 2HiccupF08/08/98PoodleChina51 3RizlaF09/09/00PoodleChina51 4GovF11/01/01AlsatianGermany101 5ManicM11/01/01PoodleChina53 6BlipF02/02/01SpanielFrance75 7RuffM08/08/00PoodleChina55 8AddiM10/02/00PoodleChina55 9CatnipF10/03/99PoodleChina55 10EmmiF11/03/01PoodleChina55 11GovF11/01/01AlsatianGermany105

How has it improved? Each member’s details are now only stored once. Each dog is now identified by their own unique identity number. A new member now has their details entered only once into the database. Changes to their record only need to happen once. Records that need to be deleted only need to be deleted once.

Can we improve further? At present, we still need to record dog details repeatedly. We still can’t add a breed unless a member introduces one to the club. We can try splitting up the dog table into two…

Like this… A table for members’ details A table for dogs’ details owns is owned by A table for breeds’ details is a particular appears in Each member can own many dogs Each dog can be owned by only one owner Each dog can only be one particular breed Each breed can appear in many different dogs

What we have now DogIDDog NameGenDofBIDBreedID 1BongoM21/08/9911 2HiccupF08/08/9811 3RizlaF09/09/0011 4GovF11/01/0112 5ManicM11/01/0131 6BlipF02/02/0133 7RuffM08/08/0051 8AddiM10/02/0051 9CatnipF10/03/ EmmiF11/03/ GovF11/01/0152 BreedIDBreedOriginL/E Years 1PoodleChina5 2AlsatianGermany10 3SpanielFrance7 IDInitialLast NameTitlePost codeTel 1AFishMrsCV35QW CHereMrsCV27RF DLapidatedMrCV14RR XRayMsCV12YY YNottMrCV24TT

Even better improvements Each member’s details are now only stored once. Each dog is now identified by their own unique identity number. A new member now has their details entered only once into the database. Changes to their record only need to happen once. Records that need to be deleted only need to be deleted once. And now… We can store information about each breed only once. We can add a new breed to the database without needing a member to introduce a new breed to the club.

Question Define a flat file. A flat file is… A flat file is a file where all the data in the database is stored in only one table. The rows in the table correspond to records whilst the columns correspond to fields. Click to reveal

ER Diagrams Entity Relationship Diagrams They give a quick idea of how relationships are formed within a database system. They can show: –One-to-One –One-to-Many –Many-to-Many

One-to-One A shop may sell CD’s and Fish. The product table will store details of the items they sell. The _Info tables give information about the product. A shop can sell one type of COD and that particular type of COD can only have one description and price. Product CD_Info Fish_Info

One-to-Many A owner can have many dogs A dog can be owned by only one owner Owner Pet owns is owned by

Many-to-Many A student can study many A-Levels An A-Level subject can have many students studying it. Student A-Level studies is studied by

Fixing a Many-to-Many This: Converts to this: By adding a linking table which uses both original primary keys as its primary key. –Known as a compound primary key. Primary Key = XXYPrimary Key = Y Entity AEntity B New Table Primary Key = XPrimary Key = Y Entity AEntity B

Our previous example of Many-to-Many Many-to-Many Problem Resolved! Each record in the Pupil_A-Level table relates to only one A- Level and one pupil. There are no duplicating records! Pupil_IDName 1Smith 2Jones 3Ali 4Potts 5Kanu 6Stay A-Level_IDCode 1Maths 2ICT 3Eng 4Graphics 5Bus_Stud 6History Pupil_IDA-Level_ID …… …… …… PupilPupil_A-LevelA-Level

Normalisation There are 3 stages of normalisation that you need to know about: –First Normal Form (1NF) –Second Normal Form (2NF) –Third Normal Form (3NF) Minimise redundant data Minimise the chance of making data inconsistent. –Think about flat files and how you have to change all the records if a member’s name changes…you may miss one in the flat file…but not in a relational database!!

The Analysis Table Create a table with 5 columns. This table will be used to help you work through the normalisation process. UNF1NF2NF3NFName Here you write down all the attributes which are contained in the flat file database. Write down the attributes as they would appear in first normal form. Write down the attributes as they would appear in second normal form. Write down the attributes as they would appear in third normal form. Here you put the names of the tables that will be in your 3NF relational database.

Example – DVD NOW! Member’s Record ID number:241 Surname:Smith Address 1:23 Jones Rd. Address 2:Walforth Phone: Joined:10/01/99 DVD_IDDVDNameDateDueBackCertCertDescription 323Roboteacher11/08/ and over only 6512Harrytron12/09/04PGParental Guidance 441The Brainbox30/09/04PGParental Guidance DVD Now!

UNF Un-normal form First stage…write down all the attributes that you need to store in your database in the first column of your analysis table. Underline the possible primary keys Put the repeating data together within brackets.

UNF Now we know what attributes we need to store…repeating attributes are in (brackets). Time to move onto first normal form! UNF1NF2NF3NFName MemID Surname Address1 Address2 Phone Join (DVD_ID DVDName Due Cert CertDescription)

Converting to 1NF A table is in 1NF if it contains: –No repeating groups. You need to copy the primary key of the non- repeating group into the table of the repeating group. –You will need to underline this foreign key as it will form part of a compound primary key. Copy the attributes into their own tables under the 1NF column.

1NF You now have two groups of attributes. Not just the one (like in UNF). Basically, you have created two tables that are linked by the MemID. UNF1NF2NF3NFName MemID Surname Address1 Address2 Phone Join (DVD_ID DVDName Due Cert CertDescription) MemID Surname Address1 Address2 Phone Join MemID DVD_ID DVDName Due Cert CertDescription

Converting to 2NF A database is in 2NF if it is in 1NF and the non-key attributes depend ENTIRELY on the primary key. If any table in 1NF has only one primary key then it is already in 2NF and can be copied to the 2NF column as it is. You will need to identify those attributes that are not related to the compound key. –E.g. If I wanted to find out the title of a DVD and I had the DVD_ID I would be able to find the DVD title. But If I gave you the Mem_ID I wouldn’t be able to find out the DVD title. –Again, giving the DVD_ID I would be able to find the certificate rating for it. The only attribute in our example that requires some thought is ‘Due’. A DVD can only be due if a member has it, which means we need both Mem_ID and DVD_ID to find this out.

Converting to 2NF What do you do now? Copy the non-key attributes that are dependant on DVD and put them in their own table. Copy part of the primary key that those non-key attributes depend upon from 1NF into the new table you just created in 2NF. –E.g. Copy DVD_ID attribute across. Underline this to show that it is the primary key of the new group. Finally, copy across any attributes left over from the old group in 1NF into 2NF, into their own table.

2NF You now have two groups of attributes. Not just the one (like in UNF). Basically, you have created two tables that are linked by the MemID. UNF1NF2NF3NFName MemID Surname Address1 Address2 Phone Join (DVD_ID DVDName Due Cert CertDescription) MemID Surname Address1 Address2 Phone Join MemID DVD_ID DVDName Due Cert CertDescription MemID Surname Address1 Address2 Phone Join MemID DVD_ID Due DVD_ID DVDName Cert CertDescription You have fixed the many- to-many problem!

Converting to 3NF Needs to be in 2NF first. Time to remove non-key dependencies –Attributes which are dependent on another attribute that isn’t a primary key. For example: –The certificate description is dependent on the certificate ID…but the certificate ID is not a primary key…it is an attribute of the DVD.

3NF This is now in 3NF because by definition it is in 2NF and doesn’t contain any non-key dependencies. UNF1NF2NF3NFName MemID Surname Address1 Address2 Phone Join (DVD_ID DVDName Due Cert CertDescription) MemID Surname Address1 Address2 Phone Join MemID DVD_ID DVDName Due Cert CertDescription MemID Surname Address1 Address2 Phone Join MemID DVD_ID Due DVD_ID DVDName Cert CertDescription MemID Surname Address1 Address2 Phone Join MemID DVD_ID Due DVD_ID DVDName CertID* CertID CertDescription MEMBER MEMBER_DVD DVD CERTIFICATE

What have we ended up with? Member can rent many DVDs. DVD can only be rented by a member at any one time. DVD can be rented many times. A rental can only be for a particular DVD. Certificate can be on many DVDs. DVD can only have one certificate. MemberDVDMember_DVD Certificate

Rules to remember 1NF –No repeating attributes and primary key of non repeating data must be placed in table of repeating data. 2NF –Look for non-key attributes that depend upon all the attributes in the compound primary keys i.e. does the attribute depend on both primary keys? 3NF –Look for non-key attributes that depend upon other non- key attributes.

Try for yourself… Normalise the following examples… The answers will be posted later in the VLE.

1. Bank Account Record Customer ID:43543 Surname:Jones Postcode:BA3 6TH Telephone: Account NumberAccount TypeDescriptionBalance GoldSavings Account£ PlatinumCurrent Account£ SilverInternet Account£ Normalise this data using the Analysis Table. Some of it has been done for you on the next slide.

1. Bank Account Record UNF1NF2NF3NFName Cust-ID Surname Postcode Telephone (AccountNumber AccountType Description Balance) Cust-ID Surname Postcode Telephone Cust-ID AccountNumber AccountType Description Balance Cust-ID Surname Postcode Telephone Cust-ID Surname Postcode Telephone AcountType Description CUSTOMER CUST_ACCOUNT ACCOUNT_DESC

2. Student Record Student ID: Surname:Patel Initial:A DofB:09/06/86 CourseNoCourseNameTeacherIDTeacherSurnameTeacherInitial 1Maths23HarrisP 2ICT18DolinskiA 3Drama23MorseB 4Business Studies 11WoodhallS Normalise this data using the Analysis Table. Some of it has been done for you on the next slide.

2. Student Record UNF1NF2NF3NFName CourseNumber CourseName TeacherID* STUDENT STUDENT_COURSE COURSE TEACHER

3. Camera Parts A database is to be kept that records all the parts that make up a particular model of digital camera. Following an analysis of the problem, it is found that these details are to be kept about each individual camera: –The camera model (which is unique for every camera) –The date the camera was released for sale. For each camera, the following details about every part needed to build it will be kept: –A part number. –A part name. –The ID of the manufacturer of the part. –The name of the manufacturer of the part. Your job is to produce a normalised design for the database. HINT: If you are unsure of how to start why not try sketching out a typical record card for one camera and then fill it in with some made-up data. It will help you visualise the problem.

3. Camera Parts UNF1NF2NF3NFName