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)


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


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


NH453 Dickenson P122

NH455 Jones P134

Cascade: Always permits deletion of parent entity instance and deletes all matching instances in the child entity


Delete Cascade

tblPractice

PID Practice name

P122 Cherry Tree

P144 South Street

P134 Concourse

tblPatient

NHSNo PSname PrID




NH455 Jones P134

Delete

DeleteDelete

Delete

To Cascade is to “track stages in succession ”Delete rule cascades down to child instances inThis case


Delete Rules

tblPractice

PID Practice name

P134 Concourse

P144 South Street

tblPatient

NHSNo PSname PrID

NH455 Jones P134


Delete Restrict

tblPractice

PID Practice name

P122 Cherry Tree

P144 South Street

P134 Concourse

tblPatient

NHSNo PSname PrID




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


Delete Rules

tblPractice

PID Practice name

P122 Cherry Tree

P144 South Street

P134 Concourse

tblPatient

NHSNo PSname PrID




NH455 Jones P134

Delete

Restrict: Permits deletion of parent entity “P144, South Street” instance since there are no matching child entity instances with P144


Delete Rules

tblPractice

PID Practice name

P122 Cherry Tree

P134 Concourse

tblPatient

NHSNo PSname PrID




NH455 Jones P134


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




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


Update Restrict tblPractice

PID Practice name

P122 Cherry Tree

P144 South Street

P134 Concourse

tblPatient

NHSNo PSname PrID




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


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


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


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


Normalisation

What is normalisation? Normalisation is

– a set of criteria– Each criteria is a rule for designing entities


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


Normalisation

How we use it in this course! We will use the normalisation rules up to third

normal form.


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.


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.


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)


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)


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.


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.


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.


Second Normal FormEntities in first Normal Form


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)


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.


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.


Third Normal FormEntities in second Normal Form




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.


Third Normal FormEntities in second Normal Form




In MedicalStaff there is a dependency between DeptID and DeptName therefore MedicalStaff is not in 3NF.

DeptID DeptName


Third Normal FormEntities in third Normal Form

MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID)

Department (DeptID, DeptName)



We must now deal with the foreign keys in the relations.


Entities in Third Normal FormDepartment (DeptID, DeptName)

MedicalStaff (MedStaffID, MSFName, MSSName, MSAdd, MSType, DeptID)

FK DeptID→DepartmentUpdate Cascade, Delete Restrict


StaffProcedure (MedStaffID, ProcedureID)FK MedStaffID→MedicalStaffUpdate Cascade, Delete Restrict

FK ProcedureID→ProcedureUpdate Cascade, Delete Restrict


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


NEXT WEEK

Noun identification table Conceptual E-R Diagram Conceptual Diagram script Business Rules Operations Logical model Database Design Language Normalisation.

www.hope.ac.uk deanery of business & computer sciences transformation of logical diagram into...

Documents