Database Fundamentals Lecture 5

The Design Process continued

cardriver cardriver cardriver cardriver 1:1 A car can only have one driver; a driver can have only one car. 1:M A car can have more than one driver; a driver can only have one car. 1:M A car can have only one driver; a driver can have more than one car. M:N A car can have more than one driver; a driver can have more than one car.

many-to-many relationship A many-to-many relationship cannot be represented in a relational database. Take the example from last week:

Sales Staff Customer take orders Sales StaffCustomer Order acceptsplaces This many-to-many relationship does not enable mapping between a particular order and a particular member of the sales staff The entity Order uniquely defines an instance involving both Sales Staff and Customer. From a single many-to-many relationship two one-to-many relationships have been created.

Sales Staff Staffid Name DOB Employ start date Order Orderid Staffid* Customerid* Order details Customer Customerid Name Address Contact name Telephone Foreign keys

Take another example: takes student module Each student has enrolled for one or more modules AND Each module has enrolled on it zero or more students This creates the following problem:

STUDENT(studentid,student name,pathway,module1, module2, module3,module4……..) MODULE(moduleid,moduleName, student1,student2, student3,student4………..)

The solution to this problem is to create a third relation that represents the relationship itself. Such relations are called intersection relations because each row documents the intersection of a particular student with a particular module.

StudentModule Enrolment is involvedis for Each student is involved in one or more enrolments and Each enrolment involves one student and and Each enrolment is for one module and Each module is involved in zero or more enrolments Enrolment is an intersection table.

The entity and attributes are represented below: STUDENT(studentid,studentName,pathway) MODULE(moduleid,moduleName) ENROLMENT(moduleid,studentid) PRIMARY KEY - is an attribute or group of attributes that uniquely identifies each entity type, and each record in the corresponding database table. COMPOSITE KEY – is when two fields together form the unique identifier.

Entity-Relationship modelling is a top down approach to database development. It begins with study of the strategic goals of the organisation. From such a study, an abstract model is constructed. The higher level model is transformed into lower-level models. From these the application is developed. Top-Down Development

Bottom-up Development Reverse of top-down development. Begins with the need to develop a specific system. Requirements specification established from which a data model is built. The database is then designed and implemented.

Putting all data into one file or table led to logic problems when trying to manipulate the contained data. Normalisation is a technique for analysing relations based on: Primary keys Functional dependencies Series of rules Normalisation (Bottom-up development)

For example: Orders database OrderDate OrderNumber OrderQuantity1 Productid1 ProductDetail1 ProductName1 ProductPrice1 OrderQuantity2 Productid2 ProductDetail2 ProductName2 ProductPrice2 Customerid CustomerName First Normal Form (1NF) Rule: All repeating groups should be eliminated and put into separate tables Order

OrderDate OrderNo OrderQuantity1 Productid1 ProductDetail1 ProductName1 ProductPrice1 OrderQuantity2 Productid2 ProductDetail2 ProductName2 ProductPrice2 Customerid CustomerName Order FROM THISTO THIS Order OrderNo OrderDate Customerid CustomerName OrderDetail Productid ProductDetail ProductPrice OrderQuantity

Eliminating Data Repetition in a Database Order OrderNo OrderDate Customerid CustomerName To enable these tables to relate to one another it is necessary that both contain a common field. OrderDetail ItemNo Productid ProductDetail ProductPrice OrderQuantity

First Normal Form (1NF) - continued Order Now a one-to-many relationship has been established. You are no longer obliged to add a new order every time you add a new order item. One row in the OrderDetail table needs both ProductName & OrderNumber to identify it. Both fields are the primary key i.e. composite key OrderNo OrderDate Customerid CustomerName OrderDetail Productid OrderNo ProductDetail ProductPrice OrderQuantity

Order OrderDetail OrderNo OrderDate Customerid CustomerName Productid OrderNo ProductDetail ProductPrice OrderQuantity Second Normal Form(2NF) Rule: All partial dependencies must be eliminated and separated into their own tables.

Eliminating Partial Dependencies - Second Normal Form 2NF Order OrderNo OrderDate Customerid CustomerName OrderDetail OrderNo Productid OrderQuantity The OrderDetail table now contains a composite key (two fields become the primary key – OrderNo and Productid. OrderQuantity is dependent on both the fields of the composite key Product Productid ProductDetail ProductPrice

Third Normal Form (3NF) Rule: to eliminate and separate any data that is not key. All values must be uniquely identified by the key. In this example the Order table contains the Customerid and CustomerName. This data could be separated from the current table and put in to its own table. Order OrderNo OrderDate Customerid CustomerName OrderNo Productid OrderQuantity OrderDetail Product Productid ProductDetail ProductPrice

Uniquely Identifying all values - Third Normal Form (3NF) Customerid CustomerName Customer Order OrderNo OrderDate Customerid* OrderNo Productid OrderQuantity OrderDetail Product Productid ProductDetail ProductPrice Customerid links the Order table with The Customer table. Customerid is the primary key in the Customer table and Foreign key in the Order table

Places Item on Contains Entity Relationship Model (E-RM) Customer OrderDetailOrder Product

Take the Unnormalised student table below to 3NF. Studentid StudentName Pathway PathwayTutorid PathwayTutorName PathwayTutorOffice ModuleCode1 ModuleName1 FinalGrade1 ModuleCode2 ModuleName2 FinalGrade2

Possible answer Studentid StudentName Pathway PathwayTutorid PathwayTutorName PathwayTutorOffice ModuleCode ModuleName FinalGrade

1NF - Eliminating Repeating groups Studentid StudentName Pathway PathwayTutorid PathwayTutorName PathwayTutorOffice Studentid ModuleCode ModuleName FinalGrade StudentGrade

2NF- Eliminating partial dependencies. Studentid StudentName Pathway PathwayTutorid PathwayTutorName PathwayTutorOffice ModuleCode Studentid FinalGrade StudentGrade Module ModuleCode ModuleName

3NF - Uniquely Identifying all values Studentid StudentName Pathway PathwayTutorid* ModuleCode Studentid FinalGrade Student Grade PathwayTutorid PathwayTutorName PathwayTutorOffice Tutor Module ModuleCode ModuleName

Takes PathwayTutorsResults in Obtains StudentModule Grade Tutor E-RM

Practical 5 Artworks Database (Written senario included with Practical 5 details)

Artworks Database CUSTOMER (customerid, lastname, firstname, address1, address2, address3, postcode, telephone) WORK (workid, artistid, copy, description, boughtDate, boughtPrice) TRANSACTION (transactionid, workid, customerid, saleDate, salePrice) ARTIST (artistid, lastname, firstname, nationality, dob, dod) CUSTOMER-ARTIST-INT (customerid, artistid)

makes 1N creates produces interests interested in Artworks Gallery E-R Model Transaction Customer Customer-Artist-Int Artist Work