Database Systems Module Review Tutor: Ian Perry Tel: 01723 35 7287 E-mail: I.P.Perry@hull.ac.uk Web: http://itsy.co.uk/units/dbs0203/ 1 1 1 1

Data  Information

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.

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.

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.

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

The Data Modelling ‘Stack’

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.

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

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.

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

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

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

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.

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 =>

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

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

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

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

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

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

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

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

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

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

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, ...; 20 20

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

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

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

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.

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

Physical Implementation (using Microsoft Access)

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.

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.