Www.hope.ac.uk Deanery of Business & Computer Sciences Transformation of Logical Diagram into...
-
Upload
jack-houston -
Category
Documents
-
view
218 -
download
3
Transcript of Www.hope.ac.uk Deanery of Business & Computer Sciences Transformation of Logical Diagram into...
www.hope.ac.uk Deanery of Business & Computer Sciences
Transformation of Logical Diagram into Database Design Language
Lecture 6
Database Technology Level I
2 www.hope.ac.uk Deanery of Business & Computer Sciences
Aims
To introduce the production of Database Design Language (DDL) from a Logical diagram.
To introduce referential integrity rules. An overview of Normalisation
– First Normal Form (1NF)– Second Normal Form (2NF)– Third Normal Form (3NF)
3 www.hope.ac.uk Deanery of Business & Computer Sciences
Database Design Language (DDL)
Given an entity, “EntityName” with n attributes, the DDL structure is as follows
– EntityName (PrimaryKey(s), attribute1, attribute2,…, attributen)
We can also define foreign keys (FK) as follows with restrictions on operations we can/cant do :
– FK ForeignKeyAttributeName →ParentEntityName Update→Cascade or Restrict Delete→Cascade or Restrict
4 www.hope.ac.uk Deanery of Business & Computer Sciences
Delete Rules – Applies to parent entity with related child entity instances
tblPractice
PID Practice name
P122 Cherry Tree
P144 South Street
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
Cascade: Always permits deletion of parent entity instance and deletes all matching instances in the child entity
5 www.hope.ac.uk Deanery of Business & Computer Sciences
Delete Cascade
tblPractice
PID Practice name
P122 Cherry Tree
P144 South Street
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
Delete
DeleteDelete
Delete
To Cascade is to “track stages in succession ”Delete rule cascades down to child instances inThis case
6 www.hope.ac.uk Deanery of Business & Computer Sciences
Delete Rules
tblPractice
PID Practice name
P134 Concourse
P144 South Street
tblPatient
NHSNo PSname PrID
NH455 Jones P134
7 www.hope.ac.uk Deanery of Business & Computer Sciences
Delete Restrict
tblPractice
PID Practice name
P122 Cherry Tree
P144 South Street
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
Delete
You may not delete the practice entity instance only, as there are related records in table tblPatient
Restrict: Permits deletion of parent entity instance only if there are no matching child entity instances
8 www.hope.ac.uk Deanery of Business & Computer Sciences
Delete Rules
tblPractice
PID Practice name
P122 Cherry Tree
P144 South Street
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
Delete
Restrict: Permits deletion of parent entity “P144, South Street” instance since there are no matching child entity instances with P144
9 www.hope.ac.uk Deanery of Business & Computer Sciences
Delete Rules
tblPractice
PID Practice name
P122 Cherry Tree
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
10 www.hope.ac.uk Deanery of Business & Computer Sciences
Update Cascade- Applies to parent entity primary key with related child entity instances
tblPractice
PID Practice name
P122 Cherry Tree
P144 South Street
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
P333
P333
P333
P333
Note: The foreign key in the child is created by migrating the primary Key from the parent entity. Restrict: only allowed if a parent record to be updated doesn’t get child orphansCascade: Parent to child entities if they exist
11 www.hope.ac.uk Deanery of Business & Computer Sciences
Update Restrict tblPractice
PID Practice name
P122 Cherry Tree
P144 South Street
P134 Concourse
tblPatient
NHSNo PSname PrID
NH223 Parkinson P122
NH564 Parkinson P122
NH453 Dickenson P122
NH455 Jones P134
P333
You may not update only the primary key of a practice entity instance if there are related records in table tblPatient
12 www.hope.ac.uk Deanery of Business & Computer Sciences
Logical to Database Design Language
DDL (Schema) for Tutor
Tutor (tutorID, firstName, surname, address1,address2, postcode, contractType, hourlyRate)
firstNamesurnameaddress1address2postcodecontractTypehourlyRate
tutorID
Tutor
semesterclassRoomclassDayclassTimecourseCode(fk)tutorID(fk)
className
Class
Note that Sometimes the DDL is called a “schema”
ALWAYS UNDERLINE the primary key(s) or Foreign keys
13 www.hope.ac.uk Deanery of Business & Computer Sciences
Logical to DDL
DDL for ClassClass (className, semester, classRoom, classDay,classTime,
courseCode, tutorID) FK tutorID→Tutor update cascade delete restrict
firstNamesurnameaddress1address2postcodecontractTypehourlyRate
tutorID
Tutor
semesterclassRoomclassDayclassTimecourseCodetutorID(FK)
className
Class
14 www.hope.ac.uk Deanery of Business & Computer Sciences
Cumulative DesignStudent (studentID, sFirstName, sSurname, sAdd1, sAdd2, sAdd3,
sPostcode, sTelephone, lastApplicationDate)Course (courseCode, title, cost)Tutor (tutorID, firstName, surname, address1, address2, postcode,
contractType, hourlyRate)Class (className, semester, classroom, classDay, classTime, courseCode, tutorID)
FK tutorID→Tutor Update Cascade, Delete Restrict FK courseCode→course Update Cascade, Delete Restrict
StudentCourse (studentID, courseCode) FK studentID→Student Update Cascade, Delete Restrict FK courseCode→course Update Cascade, Delete Restrict
StudentClass (StudentID, className) FK studentID→Student Update Cascade, Delete Restrict FK className→ Class Update Cascade, Delete Restrict
15 www.hope.ac.uk Deanery of Business & Computer Sciences
Normalisation
What is normalisation? Normalisation is
– a set of criteria– Each criteria is a rule for designing entities
16 www.hope.ac.uk Deanery of Business & Computer Sciences
Normalisation
Why normalisation? Normalisation helps us to
– improve the quality of entities– produce entities that have as little redundancy as possible– accommodate multiple values for types of data that require
them– permit efficient updates of the data in the database– avoid the danger of losing data unknowingly
17 www.hope.ac.uk Deanery of Business & Computer Sciences
Normalisation
How we use it in this course! We will use the normalisation rules up to third
normal form.
18 www.hope.ac.uk Deanery of Business & Computer Sciences
First Normal Form (1NF)
Definition of INF: Take an unnormalised relation and remove
any repeating group to form a new entity, combining the original primary key with the primary key in the repeating group to form a new compound primary key.
19 www.hope.ac.uk Deanery of Business & Computer Sciences
First Normal form (1NF)
You will need to check that each attribute will only need to hold one value, if more than one value is needed the entity is not in first normal form.
20 www.hope.ac.uk Deanery of Business & Computer Sciences
Example
We record for the Medical Staff all the procedures they are qualified to carry out
MedicalStaff
MedStaffID
MSFNameMSSNameMSAddMSTypeMSProcedureIDMSProcedureDeptIDDeptName
Database Design Language
MedStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, MSProcedureID, MSProcedure, DeptID, DeptName)
21 www.hope.ac.uk Deanery of Business & Computer Sciences
Example
Database Design Language
ONFMedicalStaff (MedStaffID, MSFName, MSSName,MSAdd, MSType,
DeptID, DeptName, (MSProcedureID, MSProcedure))
The entity is split into two separate entities. Both of which are in first normal form. Foreign Keys will be dealt with later.
INFMedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, Deptname)StaffProcedure (MedStaffID, MSProcedureID, MSProcedure)
22 www.hope.ac.uk Deanery of Business & Computer Sciences
Second Normal Form (2NF)
Definition of 2NF: "ensure that all non-key attributes are fully
dependent on the whole of the primary key" i.e. remove all partial dependencies through the creation of new tables where there was a compound key.
23 www.hope.ac.uk Deanery of Business & Computer Sciences
Second Normal Form (2NF)
Any entity with a single primary key is automatically second normal form.
We apply the rule to any entity with a compound key.
24 www.hope.ac.uk Deanery of Business & Computer Sciences
Second Normal Form (2NF)Entities in first Normal Form
MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName)
MedicalStaff is automatically 2NF as it has a single primary key.
StaffProcedure (MedStaffID, ProcedureID, MSProcedure)
StaffProcedure may not be in 2NF as it has a compound key and needs to be checked.
25 www.hope.ac.uk Deanery of Business & Computer Sciences
Second Normal FormEntities in first Normal Form
MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName)
StaffProcedure (MedStaffID, ProcedureID, MSProcedure)
The StaffProcedure entity is split into two separate entities. Both of which are in second normal form.
2NFMedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName)
StaffProcedure (MedStaffID, ProcedureID)
Procedure (ProcedureID, MSProcedure)
26 www.hope.ac.uk Deanery of Business & Computer Sciences
Third Normal Form
Definition of 3NF: "ensure that all non-key attributes are
mutually independent apart from candidate attributes" i.e. remove the dependencies between the non-key attributes through the creation of new tables.
27 www.hope.ac.uk Deanery of Business & Computer Sciences
Third Normal Form (3NF)
An entity with no non key attributes is automatically in third normal form.
An entity with only one non key attribute is automatically in third normal form.
28 www.hope.ac.uk Deanery of Business & Computer Sciences
Third Normal FormEntities in second Normal Form
MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName)
StaffProcedure (MedStaffID, ProcedureID)
Procedure (ProcedureID, MSProcedure)
Medical Staff has more than one non key field so we must consider it against the rule for 3NF.
StaffProcedure has no non key fields so is in 3NF.
Procedure has one non key field so is in 3NF.
29 www.hope.ac.uk Deanery of Business & Computer Sciences
Third Normal FormEntities in second Normal Form
MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID, DeptName)
StaffProcedure (MedStaffID, ProcedureID)
Procedure (ProcedureID, MSProcedure)
In MedicalStaff there is a dependency between DeptID and DeptName therefore MedicalStaff is not in 3NF.
DeptID DeptName
30 www.hope.ac.uk Deanery of Business & Computer Sciences
Third Normal FormEntities in third Normal Form
MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID)
Department (DeptID, DeptName)
StaffProcedure (MedStaffID, ProcedureID)
Procedure (ProcedureID, MSProcedure)
We must now deal with the foreign keys in the relations.
31 www.hope.ac.uk Deanery of Business & Computer Sciences
Entities in Third Normal FormDepartment (DeptID, DeptName)
MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID)
FK DeptID→DepartmentUpdate Cascade, Delete Restrict
Procedure (ProcedureID, MSProcedure)
StaffProcedure (MedStaffID, ProcedureID)FK MedStaffID→MedicalStaffUpdate Cascade, Delete Restrict
FK ProcedureID→ProcedureUpdate Cascade, Delete Restrict
32 www.hope.ac.uk Deanery of Business & Computer Sciences
Summary
Introduction to Database design language. Use of update and delete rules Normalisation
– First normal form– Second normal form– Third normal form
Specification of Foreign keys in DDL
33 www.hope.ac.uk Deanery of Business & Computer Sciences
NEXT WEEK
Noun identification table Conceptual E-R Diagram Conceptual Diagram script Business Rules Operations Logical model Database Design Language Normalisation.