Database SystemsModule Review

Tutor: Ian Perry

Tel: 01723 35 7287

E-mail: I.P.Perry@hull.ac.uk

Web: http://itsy.co.uk/units/dbs0203/

Ian Perry Slide 2

Data Information

Ian Perry Slide 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.

Ian Perry Slide 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.

Ian Perry Slide 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.

Ian Perry Slide 6

Example Models

• Model Duck: – 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).

Ian Perry Slide 7

The Data Modelling ‘Stack’

Conceptual Input documents, Daily/Weekly reports, Output documents, Volumes, Peaks, etc.

Model of the Business System. (EAR Model)

Logical Data elements & the relationships between those elements in a tabular form.

Model of Data Storage Theory (Db Schema)

Physical Actual data held in a database & the means to manipulate that data.

Physical Implementation (RDBMS)

Ian Perry Slide 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.

Ian Perry Slide 9

Conceptual Data Modelling

1. Identify ALL of the relevant Entities.• must play a necessary role in the business system.

2. Identify those Attributes that adequately describe each Entity.

• remember to choose ‘key’ attribute(s).

3. 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.

Ian Perry Slide 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.

Ian Perry Slide 11

Occurrence Diagrams?

• 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

WardWard 1

Ward 2

Ward 3

Ian Perry Slide 12

Degree, Type & Participation?

• One-to-Many, Mandatory (compulsory)

Hospital Wardhas =>1 M

<= are in

• One-to-Many, Contingent (compulsion one side)

Patient Operationis booked for =>1 M

<= performed on

Staff Wardwork in =>M N

<= have

• Many-to-Many, Optional (no compulsion)

Ian Perry Slide 13

Complex Relationships?

WardKeyStaffKey StaffKey

WardKey

• Which MUST be decomposed into 2 x one-to-many Relationships - like this:

Staff WardWard TeamM 1M1

<= haswork in =>

Staff Wardwork in =>M N

<= have

• Can’t have any many-to-many Relationships - for example this one:

Ian Perry Slide 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.

Ian Perry Slide 15

An Example ER Diagram

has =

>

1

M

Hospital

Ward

<=

are in

Staff Ward Team

M

1

M1

work in =>

has =

>

Patient<= has beds for

1M stay in =>

Clinic

caters for =

>

1

M

<=

attend

Operation

bo

oke

d f

or

=>

1

M

perfo

rmed

on

=>

Ian Perry Slide 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.

Ian Perry Slide 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.

Ian Perry Slide 18

Example Relations

• Staff (SCode, Name, Address, DoB, DoE)

SCode Name Address DoB DoE 9491 Smith 6 Shaw St 130265 031098 7416 Day 2 Sale St 140157 031192

CCode Site Begin End Super 279 Hull 270699 030702 9491 665 York 140901 020203 7416

• Contract (CCode, Site, Begin, End, Super)

Ian Perry Slide 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.

Ian Perry Slide 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.

Ian Perry Slide 21

A Conceptual Model

• Consider the following ‘simple’ conceptual data model:

Staff(Staff-ID, Name, Address, ScalePoint, RateOfPay, DOB, ...)

Student(Enrol-No, Name, Address, OLevelPoints, ...)

Course(CourseCode, Name, Duration, ...)

Staff Course Student1 MN M

Ian Perry Slide 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.

Ian Perry Slide 23

5 Relations from 3 Entities

Student Enrol-No Name Address OLevelPoints Tutor

Team CourseCode Staff-ID

Course CourseCode Name Duration

Pay ScalePoint RateOfPay

Staff Staff-ID Name Address ScalePoint DOB

Ian Perry Slide 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.

Ian Perry Slide 25

Document Relations as a Database Schema

• 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.

Ian Perry Slide 26

Logical Schema 1 - Domains

• Schema College• Domains

– StudentIdentifiers = 1 - 9999;– StaffIdentifiers = 1001 - 1199;– PersonNames = TextString (15 Characters);– Addresses = TextString (25 Characters);– CourseIdentifiers = 101 - 110;– CourseNames = Comp, IS, Law, Mkt, ...;– OLevelPoints = 0 - 100;– ScalePoints = 1 - 12;– StaffBirthDates = Date (dd/mm/yyyy), >21 Years before Today;– PayRates = £14,005, £14,789, £15,407, ...;

Ian Perry Slide 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

Ian Perry Slide 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

Ian Perry Slide 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)

Ian Perry Slide 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.

Ian Perry Slide 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 SizeInput MasksValidation Rulesetc.

– Key Fields => Relationships

Ian Perry Slide 32

Physical Implementation(using Microsoft Access)

Ian Perry Slide 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.

Ian Perry Slide 34

Answer the Questions I have set!(noting the weighting of Parts 1 & 2)

• Part 1 (40%)– 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.