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

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

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

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

semesterclassRoomclassDayclassTimecourseCode(fk)tutorID(fk)

className

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

semesterclassRoomclassDayclassTimecourseCodetutorID(FK)

className

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

london deanery educational supervision a7 es slides

bath deanery

paducah deanery

ecumenism intro aurora deanery

dakota niobrara winyan omniciye deanery …

iii. deanery of cuddesden, ride the first

the wessex deanery

mission action plan christianity deanery 2009—2012

west of scotland deanery - homepage...

canterbury deanery mission plan 2020

march 2019 deanery

north holderness deanery

deanery brochure back with bleed finished · deanery...

deanery presentation welcome deanery presentations november...

ii computer engineering department faculty of engineering...

www.hope.ac.uk faculty of sciences and social sciences hope...

vacancy info - yorkshire and the humber deanery

functional requirements specification document for kss...

1 healthcare workforce deanery healthcare workforce deanery...

esr / deanery interface workshop – south central