This action might not be possible to undo. Are you sure you want to continue?
A compound key consists of more than one attribute to uniquely identify an entity occurrence.
Each attribute, which makes up the key, is also a simple key in its own right. For example, we have an entity named enrolment, which holds the courses on which a student is enrolled. In this scenario a student is allowed to enrol on more than one course. This has a compound key of both student number and course number, which is required to uniquely identify a student on a particular course.
Student number and course number combined is a compound primary key for the enrolment entity.
A composite key consists of more than one attribute to uniquely identify an entity occurrence. This differs from a compound key in that one or more of the attributes, which make up the key, are not simple keys in their own right. For example, you have a database holding your CD collection. One of the entities is called tracks, which holds details of the tracks on a CD. This has a composite key of CD name, track number.
Classroom classroom id. Update Anomalies . Department department no. but track number is not a simple key in its own right. time The Process of Normalisation Normalisation is a data analysis technique to design a database system. Attendance ntity Primary Key Student student no. Result. Unit unit no Result student no. if any. Attendance student no. it aids any future changes and enhancements to the system.CD name in the track entity is a simple key. Furthermore. linking to the CD entity. Normalisation is a technique for producing relational schema with the following properties: • • No Information Redundancy No Update Anomalies The end result of normalisation is a set of entities. unit no. Course. Student. It allows the database designer to understand the current data structures in an organisation. For each of the entities below. Lecturer lecturer no. unit no. Lecturer. Course course no. Then. date. which removes unnecessary redundancy (ie duplication of data) and avoids the anomalies which will be discussed next. Classroom. Department. list possible primary keys. suggest secondary keys. SQA no.. NI no. Unit.
For example.you need to update all instances of Jones's address.An Update Anomaly exists when one or more instances of duplicated data is updated. but not all. StudentNum S21 S21 S24 S30 S30 CourseNum 9201 9267 9267 9201 9322 Student Name Jones Jones Smith Richards Richards Address Edinburgh Edinburgh Glasgow Manchester Manchester Course Accounts Accounts physics Computing Maths Insert Anomalies An Insert Anomaly occurs when certain attributes cannot be inserted into the database without the presence of other attributes. For example this is the converse of delete anomaly . consider Jones moving address . StudentNum S21 S21 S24 S30 S30 CourseNum 9201 9267 9267 9201 9322 Student Name Jones Jones Smith Richards Richards Address Edinburgh Edinburgh Glasgow Manchester Manchester Course Accounts Accounts physics Computing Maths Delete Anomalies A Delete Anomaly exists when certain attributes are lost because of the deletion of other attributes. consider what happens if Student S30 is the last student to leave the course . For example.we can't add a new course unless we have at least one student enrolled on the course.All information about the course is lost. StudentNum S21 S21 S24 S30 S30 CourseNum 9201 9267 9267 9201 9322 Student Name Jones Jones Smith Richards Richards Address Edinburgh Edinburgh Glasgow Manchester Manchester Course Accounts Accounts physics Computing Maths .
the data may still be subject to anomalies in third normal form.Normalisation Stages Process involves applying a series of tests on a relation to determine whether it satisfies or violates the requirements of a given normal form. • When a test fails. Three Normal forms: 1NF. eg reports. Normalisation is a bottom-up technique for database design. • • • Normalisation follows a staged process that obeys a set of rules. 2NF and 3NF were initially proposed by Codd. This report is to be 'normalised'. We start by analysing the documentation. All these normal forms are based on the functional dependencies among the attributes of a relation. The steps of normalisation are: Step 1: Select the data source and convert into an unnormalised table (UNF) Step 2: Transform the unnormalised data into first normal form (1NF) Step 3: Transform data in first normal form (1NF) into second normal form (2NF) Step 4: Transform data in second normal form (2NF) into third normal form (3NF) Occasionally. In this case. Each of the first four normalisation steps is explained. . • • • Transform third normal form to Boyce-Codd normal form (BCNF) Transform Boyce-Codd normal form to fourth normal form (4NF) Transform fourth normal form to fifth normal form (5NF) Normalisation Example We will demonstrate the process of normalisation (to 3NF) by use of an example. The higher the normal form the less vulnerable to update anomalies the relations become. normally based on an existing system (which may be paper-based). We will begin with the Project Management Report. we may have to perform further transformations. the relation is decomposed into simpler relations that individually meet the normalisation tests. screen layouts from that system. which describes projects being worked upon by employees.
• • • . associated with each project code. In this example it shows several employees working on several projects. is removed.Step 1 Select the data source (ie the report from the previous page) and convert into an unnormalised table (UNF). Do not confuse duplicate data with repeating attributes which is descibed in the next step. the values for Project Code. In this company the same employee can work on different projects and at a different hourly rate. Project Manager and Project Budget are duplicated if there are two or more employees working on the same project. Project Title. Remove duplicate data. A calculated field is one that can be derived from other information on the form. Project Code chosen for the key and duplicate data. (This data is not simply the data on the report but a representative sample. The process is as follows: • Create column headings for the table for each data item on the report (ignoring any calculated fields). In this case total staff and average hourly rate. Enter sample data into table.) Identify a key for the table (and underline it). (In this example. for the chosen key of Project Code.
Remove these repeating attributes to a new table together with a copy of the key from the UNF table. A repeating attribute is a data field within the UNF relation that may occur with multiple values for a single value of the key. In the previous table the Employee No. any repeating attributes to a new table. Department Name and Hourly Rate attributes are repeating. A compound key is created. That is. Department No. • Notes: • • After removing the duplicate data the repeating attributes are easily identified. there is potential for more than one occurrence of these attributes for each project code. . Assign a key to the new table (and underline it). The process is as follows: • • Identify repeating attributes. Employee Name. The value for this key must be unique for each entity occurrence.UNF: unnormalised table Step 2 Transform a table of unnormalised data into first normal form (1NF). The key from the original unnormalised table always becomes part of the key of the new table.
The process is as follows: . A and B should be put into a new relation with A becoming the primary key.50 16.00 21.These are the repeating attributes and have been to a new table together with a copy of the original key (ie: Project Code).50 17.50 Employee Name A Smith L Jones P Lewis B Jones A Smith T Gilbert W Richards T Gilbert P Lewis B James Department No. Ignore tables with (a) a simple key or (b) with no non-key attributes (these go straight to 2NF with no conversion). This combination is unique for each row in the table. • A key of Project Code and Employee No has been defined for this new table.50 21.25 17. Remove any -key attributes (partial Dependencies) that only depend on part of the table key to a new table. do we then have only one possible value for B. What has to be determined "is field A dependent upon field B or vice versa?" This means: "Given a value for A.75 18. and vice versa?" If the answer is yes.00 23.00 25. 1NF Tables: Repeating Attributes Removed Project Code Project Title PC010 Pensions System PC045 Salaries System PC064 HR System Project Code PC010 PC010 PC010 PC045 PC045 PC045 PC045 PC064 PC064 PC064 Employee No.00 18. A should be left in the original relation and marked as a foreign key. L004 L023 L004 L004 L004 L028 L008 L028 L004 L009 Step 3 Transform 1NF data into second normal form (2NF). S10001 S10030 S21010 S10010 S10001 S31002 S13210 S31002 S21010 S10034 Project Manager M Phillips H Martin K Lewis Project Budget 24500 17400 12250 Department Name IT Pensions IT IT IT Database Salary Database IT HR Hourly Rate 22.
Therefore. • • Notes: • • The first table went straight to 2NF as it has a simple key (Project Code). However. Underline the key in this new table. Rate S10001 22. Therefore it remained in the original table.00 S31002 23. Hourly Rate is dependent upon both Project Code and Employee No as an employee may have a different hourly rate depending upon which project they are working on. keep attribute in current table. Department No and Department Name are dependent upon Employee No only. check against other part of the key and repeat above process If still no. they were moved to a new table with Employee No being the key.25 S21010 17. The key it is dependent upon becomes the key in the new table.50 S13210 17. remove the attribute to a new table with a copy of the part of the key it is dependent upon.50 S10034 16.75 S10001 18.00 S31002 25.50 Project Manager M Phillips H Martin K Lewis Employee No.00 S10030 18.50 S21010 21. ie: not dependent on either part of the key.00 S10010 21. If no. S10001 S10030 S21010 S10010 S31002 S13210 S10034 Project Budget 24500 17400 12250 Department No. L004 L023 L004 L004 L028 L008 L009 Department Name IT Pensions IT IT Database Salary HR Employee Name A Smith L Jones P Lewis B Jones T Gilbert W Richards B James .Take each non-key attribute in turn and ask the question: is this attribute dependent on one part of the key? • If yes. Employee name. • 2NF Tables: Partial Key Dependencies Removed Project Code PC010 PC045 PC064 Project Code PC010 PC010 PC010 PC045 PC045 PC045 PC045 PC064 PC064 PC064 Project Title Pensions System Salaries System HR System Employee Hourly No.
upon which it is dependent. • 3NF Tables: Non-Key Dependencies Removed Project Code PC010 PC045 PC064 Project Title Pensions System Salaries System HR System Project Manager M Phillips H Martin K Lewis Project Budget 24500 17400 12250 . Leave the non-key attribute. then A and B should be put into a new relation. in the original table and mark it a foreign key (*). • • Notes: • The project team table went straight from 2NF to 3NF as it only has one non-key attribute. the key in the new table. do we then have only one possible value for B. and vice versa?" If the answer is yes. What has to be determined is "is field A dependent upon field B or vice versa?" This means: "Given a value for A. upon which it is dependent. Make the non-key attribute. A should be left in the original relation and marked as a foreign key. Underline the key in this new table. to a new table.Step 4 data in second normal form (2NF) into third normal form (3NF). The process is as follows: If a non-key attribute is more dependent on another non-key attribute than the table key: • Move the dependent attribute. with A becoming the primary key. Ignore tables with zero or only one non-key attribute (these go straight to 3NF with no conversion). Department No is the key in this new table and a foreign key in the Employee table. together with a copy of the non-key attribute upon which it is dependent. Remove to a new table any non-key attributes that are more dependent on other non-key attributes than the table key. Department Name is more dependent upon Department No than Employee No and therefore was moved to a new table.
00 18. L004 L023 L028 L008 L009 Department Name IT Pensions Database Salary HR Summary of Normalisation Rules That is the complete process.00 25. then you should arrive at the correct solution. * L004 L023 L004 L004 L023 L008 L0009 Employee Name A Smith L Jones P Lewis B Jones T Gilbert W Richards B James Department No. S10001 S10030 S21010 S10010 S31002 S13210 S10034 Employee No.00 21. if you follow the rules completely. You will notice that duplication has been removed (apart from the keys needed to establish the links between those tables). Having started off with an unnormalised table we finished with four normalised tables in 3NF.50 21.75 18.50 17. S10001 S10030 S21010 S10010 S10001 S31002 S13210 S31002 S21010 S10034 Hourly Rate 22.Project Code PC010 PC010 PC010 PC045 PC045 PC045 PC045 064 PC064 PC064 Employee No.50 16. However. The process may look complicated. and donot miss out any steps. .00 23. If you omit a rule there is a high probability that you will end up with too few tables or incorrect keys.25 17.50 Department No.
Second normal form: A table is in the second normal form if it is in the first normal form and contains only columns that are dependent on the whole (primary) key. Lecturer Grade. First normal form: A table is in the first normal form if it contains no repeating columns. Subject Level 1NF Lecturer Number. 3. If the value of a non-key column is dependent on the value of another non-key column we have a situation known as transitive dependency. Third normal form: A table is in the third normal form if it is in the second normal form and all the non-key columns are dependent only on the primary key. This can be resolved by removing the columns dependent on non-key items to another table. Subject Code. These details comprise: • • • • • • • • Lecturer Number Lecturer Name Lecturer Grade Department Code Department Name Subject Code Subject Name Subject Level Assume that each lecturer may teach many subjects but may not belong to more than one department. Department Code.The following normal forms were discussed in this section: 1. Normalise this data to Third Normal Form. 2. Subject Name. Lecturer Grade. Lecturer Name. SAQ 1 A college maintains details of its lecturers' subject area skills. Subject Name and Subject Level are repeating fields. Department Code. Slution : UNF Lecturer Number .Lecturer Name. Subject Code.Department Name. Department Name .
Subject Name. Subject Name. Project Code. Subject Code Subject Code. Project Description and Project Supervisor are repeating fields. Each employee may work on one or more projects. Department Code. Normalise this data to Third Normal Form. Lecturer Name. Each department has a single department code.Lecturer Number .Subject Level 2NF Lecturer Number. These details comprise: • • • • • • • • Employee Number Employee Name Date of Birth Department Code Department Name Project Code Project Description Project Supervisor Assume the following: • • • • • • Each employee number is unique. Subject Code. Lecturer Grade. Subject Code Subject Code. Solution:== . Employee names need not necessarily be unique. Subject Level 3NF Lecturer Number.Subject Name. Department Name Lecturer Number.Lecturer Name.Subject Level A software contract and consultancy firm maintains details of all the various projects in which its employees are currently involved.Lecturer Grade *Department Code Department Code. Each project has a single code and supervisor. Department Name Lecturer Number.
Project Description.Project Code. Date of Birth. Department Code. Project Description. Project Description. Project Supervisor . Employee Name. Project Supervisor 2NF Employee Number. Project Code. Project Code. Department Name Employee Number. Employee Name. Project Supervisor 1NF Employee Number. Project Description. Department Code. Project Code Project Code. Project Code. *Department Code Department Code. Department Name.UNF Employee Number. Employee Name. Department Name Employee Number. Department Name Employee Number.Date of Birth.Project Supervisor 3NF Employee Number. Date of Birth. Employee Name. Date of Birth Department Code.
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.