3.6.b Relational Databases and Normalisation Consider the following delivery note from Easy Fasteners Ltd.

Easy Fasteners Ltd Old Park, The Square, Berrington, Midshire BN2 5RG To: Bill Jones London England Product No. 1 2 3 Fig. 3.6.b.1 In this example, the delivery note has more than one part on it. This is called a repeating group. In the relational database model, each record must be of a fixed length and each field must contain only one item of data. Also, each record must be of a fixed length so a variable number of fields is not allowed. In this example, we cannot say 'let there be three fields for the products as some customers may order more products than this and other fewer products. So, repeating groups are not allowed. At this stage we should start to use the correct vocabulary for relational databases. Instead of fields we call the columns attributes and the rows are called tuples. The files are called relations (or tables). We write the details of our delivery note as DELNOTE(Num, CustName, City, Country, (ProdID, Description)) where DELNOTE is the name of the relation (or table) and Num, CustName, City, Country, ProdID and Description are the attributes. ProdID and Description are put inside parentheses because they form a repeating group. In tabular form the data may be represented by Fig. 3.6.b.2. Num 005 CustName Bill Jones City London Country England ProdID 1 2 3 Description Table Desk Chair No.: 005 Date: Description Table Desk Chair 14/08/01

Fig. 3.6.b.2

This again shows the repeating group. We say that this is in un-normalised form (UNF). To put it into 1st normal form (1NF) we complete the table and identify a key that will make each tuple unique. This is shown in Fig. Fig. 3.6.b.3. Num 005 005 005 CustName Bill Jones Bill Jones Bill Jones City London London London Country England England England ProdID 1 2 3 Description Table Desk Chair

To make each row unique we need to choose Num together with ProdID as the key. Remember, another delivery note may have the same products on it, so we need to use the combination of Num and ProdID to form the key. We can write this as DELNOTE(Num, CustName, City, Country, ProdID, Description) To indicate the key, we simply underline the attributes that make up the key. Because we have identified a key that uniquely identifies each tuple, we have removed the repeating group. Definition of 1NF A relation with repeating groups removed is said to be in First Normal Form (1NF). That is, a relation in which the intersection of each tuple and attribute (row and column) contains one and only one value. However, the relation DELNOTE still contains redundancy. Do we really need to record the details of the customer for each item on the delivery note? Clearly, the answer is no. Normalisation theory recognises this and allows relations to be converted to Third Normal Form (3NF). This form solves most problems. (Note: Occasionally we need to use Boyce-Codd Normal Form, 4NF and 5NF. This is rare and beyond the scope of this specification.) Let us now see how to move from 1NF to 2NF and on to 3NF. Definition of 2NF A relation that is in 1NF and every non-primary key attribute is fully dependent on the primary key is in Second Normal Form (2NF). That is, all the incomplete dependencies have been removed. In our example, using the data supplied, CustName, City and Country depend only on Num and not on ProdID. Description only depends on ProdID, it does not depend on Num. We say that Num determines CustName, City, Country ProdID determines Description and write Num CustName, City, Country

ProdID Description If we do this, we lose the connection that tells us which parts have been delivered to which customer. To maintain this connection we add the dependency Num, ProdID 0 (Dummy functional dependency) We now have three relations. DELNOTE(Num, CustName, City, Country) PRODUCT(ProdID, Description) DEL_PROD(Num, ProdID) Note the keys (underlined) for each relation. DEL_PROD needs a compound key because a delivery note may contain several parts and similar parts may be on several delivery notes. We now have the relations in 2NF. Can you see any more data repetitions? The following table of data may help. Num 005 005 005 008 008 014 002 002 002 CustName Bill Jones Bill Jones Bill Jones Mary Hill Mary Hill Anne Smith Tom Allen Tom Allen Tom Allen City London London London Paris Paris New York London London London Country England England England France France USA England England England ProdID 1 2 3 2 7 5 7 1 2 Description Table Desk Chair Desk Cabinet Cabinet Cupboard Table Desk

Country depends on City not directly on Num. We need to move on to 3NF. Definition of 3NF A relation that is in 1NF and 2NF, and in which no non-primary key attribute is transitively dependent on the primary key is in 3NF. That is, all non-key elements are fully dependent on the primary key. In our example we are saying Num CustName, City, Country but it is City that determines Country, that is City Country and we can write Num City Country Num CustName We say that Num transitively functionally determines Country.

Removing this transitive functional determinacy, we have DELNOTE(Num, CustName, City) CITY_COUNTRY(City, Country) PRODUCT(ProdID, Description) DEL_PROD(Num, ProdID) Let us now use the data above and see what happens to it as the relations are normalised. 1NF DELNOTE Num 005 005 005 008 008 014 002 002 002 CustName Bill Jones Bill Jones Bill Jones Mary Hill Mary Hill Anne Smith Tom Allen Tom Allen Tom Allen City London London London Paris Paris New York London London London Country England England England France France USA England England England Convert to 2NF DELNOTE Num CustName 005 Bill Jones 008 Mary Hill 014 Anne Smith 002 Tom Allen DEL_PROD Num 005 005 005 008 008 014 002 002 002 PRODUCT ProdID 1 2 3 7 5 ProdID 1 2 3 2 7 5 7 1 2 Description Table Desk Chair Desk Cupboard Cabinet Cupboard Table Desk

City London Paris New York London

Country England France USA England

Description Table Desk Chair Cupboard Cabinet

ProdID 1 2 3 2 7 5 7 1 2

Convert to 3NF

DELNOTE Num 005 008 014 002

CustName Bill Jones Mary Hill Anne Smith Tom Allen

City London Paris New York London

DEL_PROD Num ProdID 005 1 005 2 005 3 008 2 008 7 014 5 002 7 002 1 002 2

PRODUCT ProdID 1 2 3 7 5 Description Table Desk Chair Cupboard Cabinet

CITY_COUNTRY City London Paris New York Country England France USA

Now we can see that redundancy of data has been removed. In tabular form we have UNF 1NF 2NF DELNOTE(Num, CustName, City, Country) PRODUCT(ProdID, Description) DEL_PROD(Num, ProdID) 3NF DELNOTE(Num, CustName, City) CITY_COUNTRY(City, Country) PRODUCT(ProdID, Description) DEL_PROD(Num, ProdID) In this Section we have seen the data presented as tables. These tables give us a view of the data. The tables do NOT tell us how the data is stored in the computer, whether it be in memory or on backing store. Tables are used simply because this is how users view the data. We can create new tables from the ones that hold the data in 3NF. Remember, these tables simply define relations. DELNOTE(Num, CustName, City, Country, (ProdID, Description)) DELNOTE(Num, CustName, City, Country, ProdID, Description)

Users often require different views of data. For example, a user may wish to find out the countries to which they have sent desks. This is a simple view consisting of one column. We can create this table by using the following relations (tables). PRODUCT DEL_PROD DELNOTE CITY_COUNTRY to find ProdID for Desk to find Num for this ProdID to find City corresponding to Num to find Country from City

Here is another example of normalisation. Films are shown at many cinemas, each of which has a manager. A manager may manage more than one cinema. The takings for each film are recorded for each cinema at which the film was shown. The following table is in UNF and uses the attribute names FID Title CID Cname Loc MID MName Takings FID Title 15 Jaws 23 Tomb Raider Unique number identifying a film Film title Unique string identifying a cinema Name of cinema Location of cinema Unique 2-digit string identifying a manager Manager's name Takings for a film CID TF GH JK TF GH JK FB NM TF LM TF NM Cname Odeon Embassy Palace Odeon Embassy Palace Classic Roxy Odeon Odeon Odeon Roxy Loc Croyden Osney Lye Croyden Osney Lye Sutton Longden Croyden Sutton Croyden Longden MID 01 01 02 01 01 02 03 03 01 03 01 03 MName Smith Smith Jones Smith Smith Jones Allen Allen Smith Allen Smith Allen Takings 350 180 220 430 200 250 300 290 390 310 310 250

45 56

Cats & Dogs Colditz

Converting this to 1NF can be achieved by 'filling in the blanks' to give the relation FID 15 15 15 23 23 23 23 Title Jaws Jaws Jaws Tomb Raider Tomb Raider Tomb Raider Tomb Raider CID TF GH JK TF GH JK FB Cname Odeon Embassy Palace Odeon Embassy Palace Classic Loc Croyden Osney Lye Croyden Osney Lye Sutton MID 01 01 02 01 01 02 03 MName Smith Smith Jones Smith Smith Jones Allen Takings 350 180 220 430 200 250 300

23 45 45 56 56

Tomb Raider Cats & Dogs Cats & Dogs Colditz Colditz

NM TF LM TF NM

Roxy Odeon Odeon Odeon Roxy

Longden Croyden Sutton Croyden Longden

03 01 03 01 03

Allen Smith Allen Smith Allen

290 390 310 310 250

This is the relation R(FID, Title, CID, Cname, Loc, MID, MName, Takings) Title is only dependent on FID Cname, Loc, MID, MName are only dependent on CID Takings is dependent on both FID and CID Therefore 2NF is FILM(FID, Title) CINEMA(CID, Cname, Loc, MID, MName) TAKINGS(FID, CID, Takings) In Cinema, the non-key attribute MName is dependent on MID. This means that it is transitively dependent on the primary key. So we must move this out to get the 3NF relations FILM(FID, Title) CINEMA(CID, Cname, Loc, MID) TAKINGS(FID, CID, Takings) MANAGER(MID, MName) 3.6.c Entity-Relationship (E-R) Diagrams Entity-Relationship (E-R) diagrams can be used to illustrate the relationships between entities. In the earlier example we had the four relations DELNOTE(Num, CustName, City) CITY_COUNTRY(City, Country) PRODUCT(ProdID, Description) DEL_PROD(Num, ProdID) In an E-R diagram DELNOTE, CITY_COUNTRY, PRODUCT and DEL_PROD are called entities. Entities have the same names as relations but we do not usually show the attributes in E-R diagrams. We now consider the relationships between the entities. Each DELNOTE can be for only one CITY_COUNTRY because a City only occurs once on DELNOTE Each CITY_COUNTRY may have many DELNOTE because a City may occur on more than one DELNOTE Each DELNOTE will have many DEL_PROD

Num in DELNOTE could occur more than once in DEL_PROD Each DEL_PROD will be for only one DELNOTE because each Num in DEL_PROD can only occur once in DELNOTE Each PRODUCT will be on many DEL_PROD PRODUCT can occur more than once in DEL_PROD Each DEL_PROD will have only one PRODUCT because each ProdID in DEL_PROD can only occur once in PRODUCT The statements show two types of relationship. There are in fact four altogether. These are one-to-one one-to-many many-to-one many-to-many represented by represented by represented by represented by

Fig. 3.6.c.1 is the E-R diagram showing the relationships between DELNOTE, CITY_COUNTRY, PRODUCT and DEL_PROD.
DELNOTE

CITY_COUNT
RY

DEL_PROD

PRODUCT

Fig. 3.6.c.1 If the relations are in 3NF, the E-R diagram will not contain any many-to-many relationships. If there are any one-to-one relationships, one of the entities can be removed and its attributes added to the entity that is left. Let us now look at our solution to the cinema problem which contained the relations FILM(FID, Title) CINEMA(CID, Cname, Loc, MID) TAKINGS(FID, CID, Takings) MANAGER(MID, MName) in 3NF.

We have the following relationships.

FILM

is for

TAKINGS

connected by FID
takes

CINEMA

is for

TAKINGS

connected by CID
manages

MANAGER

managed by

CINEMA

connected by MID These produce the ERD shown in Fig. 3.6.c.2.

CINEMA

MANAGER

TAKINGS

FILM

Fig. 3.6.c.2 In this problem we actually have the relationship CINEMA shows many FILMs FILM is shown at many CINEMAs That is
CINEMA FILM

But this cannot be normalised to 3NF because it is a many-to-many relationship. Manyto-many relationships are removed by using a link entity as shown here.
CINEMA LINK_ENTITY FILM

If you now look at Fig. 3.6.c.2, you will see that the link entity is TAKINGS.