1. Database Systems Module Review
Tutor: Ian Perry
Tel:
Web: 1 1 1 1

2. Data  Information

3. Data  Information
A clear understanding of difference between Data and Information is crucial if you are to be able to design and implement a database.
What is Data?
a series of observations, measurements, or facts.
What is Information?
data that have been transformed into a meaningful and useful form for people.
Information = Data + Structure + Context
the same data can give different information if a different structure and/or context is applied.

4. Data + Structure <= a Database
A database is:
an organised collection of data.
A database management system (DBMS) is:
software designed to assist in maintaining and utilising large collections of data.
A relational database management system (RDBMS) is:
a specific type of DBMS.

5. Modelling the ‘Real’ World
Requires us to focus on the critical aspects of the real world’s richness.
Models are not Real/Complete.
All models require decision of what to include & what to exclude.
These design decisions represent someone’s view of what is important (and what is not important) about a particular reality.
As such, there is no right answer!
All one might say is that this is a ‘good’ model, given the purpose we want to use it for.

6. Example Models Model Duck: Model Aeroplane: Data Model:
Purpose; to show shape, colour, size, etc.
Model Aeroplane:
Purpose; to show general structure, identification of parts, flight characteristics, etc.
Data Model:
Purpose; the representation of objects of interest to an enterprise, allowing data to be structured (i.e. given meaning) and manipulated (for specific purposes).

7. The Data Modelling ‘Stack’

8. Need to Capture ‘Real’ World Facts
Such as:
Customers place Orders.
Lecturers teach Students.
EAR Modelling lets us do so in way that:
is Data Driven.
encourages Thorough Analysis.
provides an effective means of Communication.
applies to ALL Database Theories.
is Independent of Software & Hardware.

9. Conceptual Data Modelling
Identify ALL of the relevant Entities.
must play a necessary role in the business system.
Identify those Attributes that adequately describe each Entity.
remember to choose ‘key’ attribute(s).
Identify the Relationships between Entities.
determine the Degree of each Relationship:
determine the Type of each Relationship.
attempt to decompose any many-to-many Relationships that you have identified. 21 20 22

10. Entities & Attributes Real World Situation:
Hospital
Entities = objects of interest, e.g.:
Doctor, Nurse, Ward, Patient, etc.
Attributes = describing each Entity, e.g.:
Patient = Name, Address, Date-of-Birth, Gender, etc.
Entity Definitions
Staff (StaffID, Role, Name, Room, Extension, Speciality, …)
Patient (FirstName, FamilyName, DOB, Address, Gender, …)
NB. ‘key’ Attribute(s) MUST be identified.

11. Occurrence Diagrams? Staff Ward
Use these to get straight how many occurrences of each Entity are on either side of a Relationship.
Staff
Fred Smith
Jane Bloggs
Arthur Jones
Angela Oust
Ward
Ward 1
Ward 2
Ward 3

12. Degree, Type & Participation?
One-to-Many, Mandatory (compulsory)
Hospital
Ward
has => 1 M
<= are in
One-to-Many, Contingent (compulsion one side)
Patient
Operation
is booked for => 1 M
<= performed on
Staff
Ward
work in => M N
<= have
Many-to-Many, Optional (no compulsion) 20 20 18

13. Complex Relationships?
Staff
Ward
work in => M N
<= have
Can’t have any many-to-many Relationships - for example this one:
Which MUST be decomposed into 2 x one-to-many Relationships - like this:
Staff
Ward
Ward Team M 1
<= has
work in =>
WardKey
StaffKey
StaffKey
WardKey 20 18 20

14. Drawing ER Diagrams Need to look good, so:
don’t draw them by hand!
Need to be well laid out, so that:
Entities with several Relationships are in the centre.
Related Entities are adjacent to each other.
Relationship lines do not cross.

15. An Example ER Diagram Clinic Operation Hospital Ward Patient Ward Team
has => 1 M
Hospital
Ward
<= are in
Staff
Ward Team
work in =>
Patient
<= has beds for
stay in =>
Clinic
caters for =>
<= attend
Operation
booked for =>
performed on =>

16. Logical Data Modelling
All about:
translating our Conceptual Data Model so that it might be implemented using software that matches a specific Database Theory.
Relational Database Theory, Codd (1970):
allows us to develop mathematically rigorous abstract data models, composed of a number of distinct Relations.
Tables are NOT Relations:
simply the way we choose to mentally give flesh to our Logical Data Model. 15 16

17. Relations Are defined by a list of Attributes (i.e. columns), that:
must be distinctly named.
contain data entries that are atomic, of the same type, from the same domain.
can be defined in any order.
Tuples (i.e. rows):
once again, ordering is irrelevant.
must be unique (so need a Key).
Relationships:
are made via Primary/Foreign Key mechanism. 14 15

18. Example Relations Staff (SCode, Name, Address, DoB, DoE)
Contract (CCode, Site, Begin, End, Super) 6 7

19. Need to avoid Database Anomalies
By building a ‘robust’ Logical Data Model. i.e.:
Transforming the Conceptual Data Model into a set of Relations.
Checking these Relations for any Anomalies.
Documenting them as a Database Schema. 2 2

20. What is an Anomaly?
Anything we try to do with a database that leads to unexpected (unpredictable) results.
Three types of Anomaly:
insert
delete
update
Need to check your logical database design carefully:
the only good database is an anomaly free database. 2 2 3 3 16

21. A Conceptual Model
Consider the following ‘simple’ conceptual data model:
Staff
Course
Student 1 M N
Staff(Staff-ID, Name, Address, ScalePoint, RateOfPay, DOB, ...)
Student(Enrol-No, Name, Address, OLevelPoints, ...)
Course(CourseCode, Name, Duration, ...) 8 8

22. The ‘Translation’ Process
Entities become Relations
Attributes become Attributes (?)
Entity Identifiers become Primary Keys
Relationships are represented by additional Foreign Key Attributes in those Relations that are at the ‘M’ end of a 1:M relationship.
Usually end up with more Relations than we originally defined as Entities:
Artificial Relations – to solve M:M problems.
Split-off Relations – to avoid dependency problems. 9 9

23. 5 Relations from 3 Entities
Student
Staff
Course
Team
Pay 17 17

24. Don’t change Conceptual Model
Remember, we can choose from one of a range of Database Theories with which to build our Logical Data Model:
Hierarchical
Relational
Object
Each of these Database Theories may need different compromises from the ‘pure’ meaning captured by your Conceptual Model. 18 18

25. Document Relations as a Database Schema
defines all Relations and their relevant Domains.
We should have ‘captured’ the Business situation (assumptions and constraints) in the Conceptual Data Model, e.g:
a College only delivers 10 Courses.
These assumptions and constraints become the Domains of the Database Schema. 19 19

26. Logical Schema 1 - Domains
Schema College
Domains
StudentIdentifiers = ;
StaffIdentifiers = ;
PersonNames = TextString (15 Characters);
Addresses = TextString (25 Characters);
CourseIdentifiers = ;
CourseNames = Comp, IS, Law, Mkt, ...;
OLevelPoints = ;
ScalePoints = ;
StaffBirthDates = Date (dd/mm/yyyy), >21 Years before Today;
PayRates = £14,005, £14,789, £15,407, ...; 20 20

27. Logical Schema 2 - Relations
Relation Student
Enrol-No: StudentIdentifiers;
Name: PersonNames;
Address: Addresses;
OLevelPoints: OLevelPoints;
Tutor: StaffIdentifiers;
Primary Key: Enrol-No.
Foreign Key Tutor references Staff.Staff-ID 21 21

28. Logical Schema 3 - Relations
Relation Staff
Staff-ID: StaffIdentifiers;
Name: PersonNames;
Address: Addresses;
ScalePoint: ScalePoints;
DOB: StaffBirthDates;
Primary Key: Staff-ID.
Foreign Key ScalePoint references Pay.ScalePoint 21 21

29. Logical Schema ... Relation Course
CourseCode: CourseIdentifiers;
Name: CourseNames;
… etc.
Continue to define each of the Relations in a similar manner.
NB. Make sure that you define ALL of the Relations, including:
‘artificial’ ones (e.g. Team)
‘split-off’ ones (e.g. Pay) 22

30. Moving to the Physical ‘World’?
In this Software specific world we must:
Create
Translate our Relational Schema into a Database.
Populate
This Database with ‘test’ data.
Query
Ask questions of the Database.

31. Logical => Physical
i.e. translate the Relational Schema into a Database Storage Model:
Schema => Database
Relations => Tables
Attributes => Field Names
Domains => Data Type
Field Size
Input Masks
Validation Rules
etc.
Key Fields => Relationships

32. Physical Implementation (using Microsoft Access)

33. The Assessment Method Read the Case Study carefully!
Your Database System must be able to answer the 10 questions at the back of the Case Study.
It is up to you to decide upon:
the overall structure/navigation of your system.
don’t try to be too clever - keep it simple!
the information that should appear on each screen.
don’t have to make it all Form based - can use Reports & Queries.
Do not begin the development of your Physical Data Model, until you have developed ‘good’:
Conceptual & Logical Data Models.

34. Answer the Questions I have set! (noting the weighting of Parts 1 & 2)
Develop; a conceptual data model, i.e. an ER Diagram.
Develop; a logical data model, i.e. a Database Schema.
Part 2 (60%)
Implement; a physical data model based on the logical data model, i.e. a Microsoft Access Database.
Manipulate; this physical data storage model, i.e. by developing a Database System (using Microsoft Access) that allows manipulation of this physical data model.