44271: Database Design & Implementation Physical Data Modelling Ian Perry Room: C49 Tel Ext.: 7287

44271: Database Design & Implementation

Physical Data Modelling

Ian PerryRoom: C49 Tel Ext.: 7287E-mail: [email protected]

http://itsy.co.uk/ac/0405/sem3/44271_DDI/

mailto:[email protected]

Ian Perry Slide 244271: Database Design & Implementation: Physical Data Modelling

The ‘Data Modelling Stack’Conceptual Overview of things

that are perceived to be of ‘interest’ in the ‘real’ world.

Model of the Business System. (ER 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)


What is a Physical Data Model?

The Physical Implementation (hardware & software) of a Logical Data Model: it is useless to progress to this stage of database

development if your Logical Data Model is NOT demonstrably ‘robust’.

Physical Data Model must enable: data to be stored (& maintained) in structured

manner. an ‘accurate’ implementation of the logical data

model. retrieval of specific groupings of data

(information?). refer back to the original business requirements.

There may be several software constraints: depending upon the software application chosen.


Our Physical ‘World’? RDBMS Software:

Microsoft Access In this physical world we must be able

to: Create

Translate our Relational Schema into a Database.

Populate This Database with ‘test’ data.

Query Ask questions of the Database.


Properties of RDBMS Software Modification:

To Schema: creating & deleting relations (i.e. Tables). adding attributes to, or removing attributes

from, existing relations. To Data:

creating & deleting tuples (i.e. Records) updating attribute values in a tuple (i.e. Data

held in Fields) Interrogation:

Relational Algebra Relational Calculus (SQL)


Logical => Physical i.e. translate our Relational Schema

into a Database Storage Model: Schema => Database Relations => Tables Attributes => Field Names Domains => Data Type

Field SizeInput MaskValidation Ruleetc.

Key Fields=> Relationships


The SSC Database

Relations Staff (StaffID, FirstName, SurName, ScalePoint, DOB) Student (EnrolNo, FirstName, SurName, OLevelPoints, Tutor)

Course (CourseCode, Name, Duration) Team (CourseCode, StaffID) Pay (ScalePoint, RateOfPay)

ER Diagram

Staff Course Student1 MM M


Physical Implementation


Relational Algebra With most (all?) Relational DataBase

Management Systems the means of database interrogation is based upon: Relational Algebra (E. F. Codd, 1972)

As represented by the 3 primary functions of: SELECT PROJECT JOIN


Example Relations (Relational Algebra)

EmpNo EName ESalary Dept

JName EmpNo Hours

Employee (EmpNo, EName, ESalary, Dept)

Assignment (JName, EmpNo, Hours)

Job (JName, Budget)

JName Budget


SELECT Extracts TUPLES (Rows) from a relation

subject to required conditions on attributes in that relation. e.g.:

SELECT Employee WHERE ESalary > 13000

EmpNo EName ESalary Dept

146 Harvey 15000 Sales 468 Mendoza 14000 Planning

NB.SELECT Employee WHERE ESalary > 13000 GIVING Temp1

Would ‘create’ a new relation, i.e. Temp1


PROJECT Extracts COLUMNS from a relation in

a named order by attribute. e.g.: PROJECT Employee OVER EName,

DeptEName Dept

Harvey SalesJones PlanningMendoza PlanningSmith Sales


JOIN COMBINES RELATIONS which have a

common attribute to generate a temporary relation containing all of the attributes from both relations. e.g: JOIN Employee AND Assignment OVER EmpNo

EmpNo EName ESalary Dept JName Hours134 Smith 12000 Sales ProjB 9.0146 Harvey 15000 Sales ProjA 3.4468 Mendoza 14000 Planning ProjB 5.2

NB. This temporary relation contains only one instance of the ‘EmpNo’ Attribute.


Asking ‘Complex’ Questions What are the Names, Jobs and Hours

worked by those in the Sales Dept?PROJECT ( SELECT (

JOIN Employee AND Assignment OVER EmpNo) WHERE Dept = 'Sales') OVER EName, JName, Hours

EName JName HoursSmith ProjB 9.0Harvey ProjA 3.4

NB. The final relation is constructed by working from the innermost nesting outwards.


Structured Query Language SQL is the most often used method for

accessing relational databases. A ‘software interpretation’ of Codd's Relational

Algebra. Remember:

SELECT - extracts TUPLES from a relation subject to required conditions on attributes in the relation.

PROJECT - extracts COLUMNS from a relation in a named order by attribute.

JOIN - COMBINES RELATIONS which have a common attribute to generate a temporary relation containing all of the attributes from both relations.

SQL ‘works’ for all RDBMS applications: e.g. Access, Oracle, MySQL, etc.


The SQL ‘SELECT’ Statement SQL Syntax

SELECT {column_name [, column_name, ... ] } FROM table_name [ table_alias ] [ WHERE condition [ AND/OR condition [, AND/OR condition, ... ] ] ] [ GOUP BY column_name [, column_name, ... ] [ HAVING condition ] ] [ ORDER BY {column_name/column_number [, ... ] }

]

Don’t worry, it is not a frightening as it looks!


Example Relations (SQL)

Surname

Name Dept Position Age

Staff (Surname, Name, Dept, Position, Age)

Course (CourseNo, CourseName, Level, Surname)

CourseNo CourseName Level Surname


The ‘simplest’ SELECT

SELECT *FROM staff ;

A SELECT of all Tuples (rows) from a Table called staff.


A ‘more useful’ SELECTSELECT name, surname, age, positionFROM staffWHERE age > 35OR position = 'CLERK'GROUP by age ;

A PROJECT of specific columns of the staff Table (in a named order), with some SELECTion of conditions.


Previous SQL Statement Produces:


SELECTing from 2 TablesSELECT S.name, S.surname, S.age,

C.coursenoFROM staff S, course CWHERE S.surname = C.surnameAND age > 50 ;

JOINs the Tables staff and course to create a temporary table and PROJECTs columns from this new table based on the SELECTion criteria.


Previous SQL Statement Produces:


Query-By-Example (QBE) SQL can be difficult to learn, however, most

RDBMS software has a QBE interface: which presents the user with ‘lists’ of

things to choose from. Using this 'point-&-click' QBE interface, we

don’t have to know (much) about: Field Names, Logical Operators, etc.

can easily set up relationships between tables: Staff.SURNAME = Course.SURNAME

and apply criteria for selection, e.g.: Staff.AGE > 50


This Week’s Workshop Provides a ‘gentle’ Introduction to

Microsoft Access Showing you how to build, and then ask

questions of, relatively simple Relational Databases.

i.e.: Databases consisting of two, or three,

Tables.

Documents

44271: Database Design & Implementation Physical Data Modelling Ian Perry Room: C49 Tel Ext.: 7287