2003 Monash IT Pty Ltd DataBase Design Lect 7 / 1 PHYSICAL DESIGN and IMPLEMENTATION

© 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 1

PHYSICAL DESIGN and IMPLEMENTATION



No relation


Physical and Implementation DesignPhysical and Implementation Design

Performed by Data Analysts and Database Administrators

Steps

1. Conceptual Model (ER Diagram) mapped onto a logical model dependent on the DBMS characteristics.

2. Optimise the logical model.


Map ERD to Relational ModelMap ERD to Relational Model

1. Convert the Normalised E-R Diagram to Tables

2. Transform the Attributes in the ER Diagram to columns(attributes)

3. Normalise the Table structure (data structure diagram)

4. Identify the Primary Keys

5. Identify the Referential Constraints


E/R Diagram

EMPLOYEEDEPARTMENT

PROJECTSUPERVISION

DEPENDENT

DEPENDENTS_OF

WORKS_ON

MANAGES

WORKS_FOR

CONTROLS

N 1

11

1 N1

N

NM

Fname Lname

NameGender

AddressSalary

Snn

Birthdate

StartDate

NameNumber

Locations

Hours

NameNumber

Location

Name Gender Birthdate


Each Entity becomes a Table

ENTITY TABLE PRIMARY KEY

Employee Employee Employee_SSNDepartment Department Department_NumberProject Project Project Number


1 : 1 Relationship Department Manager DeptCode(PK) EmpCode (PK)

DeptName EmpName DeptFloor EmpSalary DeptContact StartDate EmpCode (FK) AddressThe Manager Code is actually an Employee Code, but not all Employees are Managers.Only those ‘EmpCodes’ which are allocated to Managers appear in the Department table, and are the limited set of Foreign Key values (where Department.EmpCode = Manager.EmpCode)


1:M Relationships - Float the PK

For each 1:M relationship - float the PK from the from theentity on the 1 side to the entity on the N side where itwill become a foreign key

EMPLOYEE WORKS_FOR DEPARTMENT

M 1

Department Number is moved into the Employee entity

What would be the result if the Employee number was moved into Department entity ?


Weak Entities

Fundamental Metaobjects are: -

EntitiesRelationshipsAttributes

Another metaobject is the dependent entity (or weak entity)

Dependent entities cannot exist on their own, and must have a parent entity. They are identified in a M:N relation as the ‘intersect entity’ with the primary key the composite of the primary keys of the two (or more) other ‘strong entities’


Weak Entities become Tables

For each weak entity create a table

- include the Primary Key attribute(s) of the owner tables The Primary Key becomes the :-

owner key plus the weak entity key

Entity Table Primary Key

Dependent Dependent Employee_SSN + Dependent_No


M:N Relationships

For each M:N relationship create a new table with the Primary key being the the PK of both entities involvedin the relationship

EMPLOYEE WORKS_ON PROJECT

Empno Hours Projno

E1 P1 3E1 P2 4E2 P1 5E3 P2 3


The M:N (or M:M) Relationship

Items are Sold = 2 entities ( Items and Sale)

A Sale can consist of Many Items (depending on the budget)An Item can appear in Many Sales (good for business)

A third entity is created to link the entities through two 1:M relationships (known as a ‘associative’ or ‘intersect’ entity)In this example this entity name is ‘Line Item’

The Big question - why is it needed ?



Sale LineItem Item SaleNo LineNo ItemNo

SaleDate LineQty ItemName SaleText LinePrice ItemType SaleNo ItemColour

A Sales Order is a series of entries, and LineNo is unique to a particular order. The use of LineNo and SaleNo gives a Unique Identifier.

LineItem is a Weak or Dependent Entity - its content relies on another entity for its existence and identification



We need to store data about the items sold.

This data cannot be stored with SALE as a sale can be many items, and an entity can only store single-value facts

Storing data with the ITEMS table is not appropriate as an Item can appear in many sales

So the ‘Associative Table’ device is necessary


Multivalued Attributes

For each multivalued attribute create a new relation.The Primary Key is the PK of the entity plus the multivalued attribute.

DEPARTMENT LOCATION

TABLE PRIMARY KEY

DEPARTMENT_LOCATIONS DEPARTMENT LOCATION

D1 MELB D1 SYD D2 MELB


Transforming Attributes to Columns

Naming Standard

Entity.(Role_)Domain

Entity - the entity the attribute belongs in

Role - enables the attribute to participate in the relationship

Domain - data type

Employee.Age

Employee.Superssn - the role of the person is a manager


N-ary Relationships

For N-ary Relationships create a new entity and float thePrimary Key of each entity involved in the relationshipto the new entity

Supplier supplies Parts from Cities

TABLES PRIMARY KEY

SUPPLIER_PARTS_CITIES SNo PNo City S1 NUT MELB S1 NUT SYD


Include Volumes for each Table

Fname Lname Essn Bdate Address M/F Salary Superssn Dno

Dname Dnumber Mgrssn Mgrstartdate

Dnumber Dlocation

Essn Pnumber Hours

Pname Pnumber Plocation Dnumber

Essn Dependent_name M/F Bdate

EMPLOYEE (100)

DEPARTMENT(10)

DEPT_LOCATIONS (5)

WORKS_ON(500)PROJECT (20)

DEPENDENT (200)

p.k

f.k

p.k

f.k f.k

f.kNOTNULL

NOTNULL


Logical Access Paths and Loads

Trace all known outputs (reports, views, queries) through the tables required

Verify the Primary, Foreign key relationships

Verify the cardinality and modality

Calculate transaction loads and volumes


Business Rules

‘A Business Rule is a statement which defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behaviour of the business’.

Business Rule Group (BRG) ‘ Business Rules Project : Final Report, October 1997

A Business Rule will affect data (presence, absence, type, size, access)processes on data (insert, update, modification,

delete, calculations) integrity constraints, life of data


Implementation Issues

Recovery

Concurrency Control

Security and Integrity

Query Optimisation

Scalability

Transform to Operational State


Implementation Models

ProgramsandQueries

DataModelStructure

Logical DataModelStructure

Implementation model components

Converted to

Converted to

Used to determine

DDLExpressed in termsof

Converted toaccess the physicaldatabase

Conversion


Implementation Planning

Write ProgramsTest ProgramsInstall ProgramsInstall SystemPlan, Develop and Install SecurityPlan, Develop and Install RecoveryUser Acceptance StrategyUser Test StrategyDocumentationUser trainingConversions : Data Loading


Implementation and Acceptance Testing

Physical Implementation

Criteria:

1. Data availability2. Data reliability3. Data currency4. Data consistency5. Data flexibility6. Data efficiency



1. Data availability : The required data and relationships are stored in the database

2. Data reliability : The data will not be lost or corrupted3. Data currency : The data value is the latest value of the data

item4. Data consistency : The same data values will be obtained

for the same item in different queries at the same time5. Data flexibility : Extension can be made to meet new

requirements without rebuilding the database6. Data efficiency : Storage and retrieval are at minimum cost



The major components of the implementation model are :1. A data model structure2. Data definition languages to define the data model structure3. The data access commands. Access specifications are

embedded in programs, views, reports4. Physical structures - based on volumes, usage, frequency of

use, response times required, number of concurrent users..


Implementation and Acceptance TestingThe Enterprise Model Data Model Structure

Programs and enquiriesAccess Specifications to access the database

Logical data model structure

Database Specification Physical database structures

Quantitative data



4 Fundamental capabilities of a DBMS

1. The DBMS must provide a natural interface of user data

2. The interface must be independent of any physical storage structures

3. Different users should be able to access the same database using different views of the database

4. Changes to the database to be made without affecting programs which make no use of the change



The Operational Environment

Specialised use by one or a few people

The database is an integral part of a business operation and must be accessible to a large number of users who may be spread over many locations



Other considerations:

Concurrency control

Access controls

Recovery systems

Database privacy



A suggested Test Specification outline

Test the functional areas: Maintenance Analysis Tools Exit Procedures

Overall operation - menu navigation, forms opening, forms closing, button operation.

Transition to a new or former state



Maintenance : data entry

Forms navigation

Valid data entries

Valid / correct calculations

Tools - probably searching and sorting



Test each attribute in forms, views, reports

Order of presentation / appearance of input attributes

Navigation around or through forms - Tab key, Enter keyIs the progression accurate - what you expected - smooth

What is the ‘user’ reaction - the Quality Reviewer in your team is an excellent ‘user’.

Indicate ‘actions’, ‘Expected results’, Actual results or ‘OK’.



Test forwards and reverse cursor movements

What error messages occur ?

What triggers them ?

How are they cleared - a full restart ?

Do you have ‘standard’ error messages or is there a clear indication of the cause and correction of the error

Are attributes type protected ? Size protected ?



Do you have data presentation rules ?e.g. the first character of a string in Capitals punctuation

$ signs or identifiers on numeric values displayed decimal points included and positioned correctly dates in British form e.g. 12/09/2002 or 12-October-2002

How are empty attributes presented ? Blank, ??, ‘no value’ displayed ?



What is your policy on deletions ? Tag and retain, release, archive ?

Are there any warning messages ?

Is referential integrity affected ?

Are deletions logged or archived ?

Who can delete ?

Is there a choice to proceed or not ?



How do you intend to record successful tests

problems in tests

the action taken and the result of a re-test

who took part in the test who prepared the data who prepared the ‘control’ output who ran the test who investigated the fault, if any



What does the ‘user’ expect to see ?

Is the user impressed ?

Does the ‘user’ required changes (terms, progression, colours, positioning ..) (Quality reviewer + possibly the team co-ordinator)

When were the various tests performed

What was the equipment / software configuration

Is it compatible with the end-user’s equipment and operating system ?



What are the criteria for a a successful test

an unsuccessful test

Do you intend for a team walkthrough before a test is made or a revision test is made

Who certifies the test result

Who organises the test schedule - who monitors it ?



Do you intend to include a glossary of terms in your Acceptance Test Specification - what terms ?

Could these be superceded by a training session with the user ?

What if the user leaves, gets another job, ……

What form of certification are you going to present to the end-user ?



What is the recommended method of recovery ?Does it work ?

Is it automated or will the end user need to run through a series of keyboard operations

How ‘clear’ are the instructions - is it likely that the end user will overwrite critical data ?

Will you train the user as part of your delivery package ?



What are the security provisions ?

Who will administer them ?

How secure are they ?

What risk is there to the end user when the system fails ?

Is there any fall back position / procedure ?



Are you able, or do you intend that the end user will have access to ongoing support ?

How ?

What are your suggestions to the end user regarding software upgrades (e.g. Windows2000 to Windows2002) hardware upgrades on line connections to the container pool on line container/consignment tracking (e-commerce) customer on line access



How do you intend to load the initial working data for the client ?

Who supplies the effort and cost ?

How many rows / records are involved ?

Is there going to be a delay time prior to the system being operable ?

How would this gap be controlled - e.g. transactions occurring but not able to update ?


Other Aspects

Let’s have a few comments about :- Installing Referential Integrity, and some Optimising Aspects


The Personnel/Works Database

Fname Lname Essn Bdate Address M/F Salary Superssn Dno

Dname Dnumber Mgrssn Mgrstartdate

Dnumber Dlocation

Essn Pno Hours

Pname Pnumber Plocation Dnumber

Essn Dependent_name Gender Bdate

EMPLOYEE (100)

DEPARTMENT(10)

DEPT_LOCATIONS (5)

WORKS_ON(500)PROJECT (20)

DEPENDENT (200)

p.k

f.k

p.k

f.k f.k

f.kNOTNULL

NOTNULL


Referential Integrity

Delete/Update Restrict/Set Null/Cascades

Setting the Referential Integrity Constraint Actionscan be performed as follows:-

. if the Foreign Key is part of PK then you should useCASCADES - ESSN is PK in WORKS_ON

. if the participation constraint is total - use RESTRICT - MGRSSN (Depts must have a MGR)

. if the participation constraint is partial - use SET NULLDNUMBER in EMPLOYEE

Nb: These are guide-lines and the selection depends on theBusiness Rules.


Referential Integrity

As you have gathered, cascade (anything) can be a very dangerous command or function - many primary and foreign keys can be inserted, updated and deleted in a single transaction

For that reason it is never available to a user - it is definitely a Database Designer or Database Administrator’s tool


Integrity

That was an appetiser

There are many forms of Integrity

We will be looking at these next lecture.


Optimise the Logical Model

Optimisation - maximise/minimise a strength/weaknessof a resource

Therefore, we must know the characteristics of resources- cost/performance

List expensive resources

List cheap resources


Optimisation Criteria

Application Development Time

Execution Time

Data Storage

Flexibility

. trade-off between the above depending on the prioritiesof the user (User Level Agreement)


Optimisation of Development Time

- keep the design simple

- avoid complex relationships

- no tricks

- must have staff who are familiar with products e.g. Rapid Application Development techniques


Optimisation of Execution Time

Reduce the amount of energy used against critical paths(Translates to : - reduce the amount of work againstaccess paths)

Use Indexes (cautiously)

Use Controlled Redundancy

Split Attributes if Processing Requirements are Different


Controlled Redundancy

Tradeoff against flexibility - waste space, extra maintenance,more programming, more program work

> 20% redundancy - design problems

CUSTOMER

Custno, CustName, CustAddress, CustStatus

ORDER

Orderno, Custno, OrderTotal, OrderDate


Add Control Fields

CUSTOMER

Custno, CustName, CustAddress, CustStatus, CustBalance

ORDER


- totals are stored rather than calculated at query time


Add Key Data

CUSTOMER

Custno, CustName, CustAddress, CustStatus, Last_Orderno, Last_OrderDate

ORDER


- this will allow us to bring back the most recent orderand answer queries such as “What was the last date Customer Smith made an order?”


Elemental Redundancy

CUSTOMER

Custno, CustName, CustAddress, CustStatus

ORDER

Orderno, Custno, OrderTotal, OrderDate, Custaddress

- when we go to print out the Invoice we will not need togo to the Customer file to get the address


Split Attributes where Different Processing Required

CUSTOMER

Custno, CustName, CustAddress

CUSTOMER BATCH

Custno, CustStatus

- the status is only used by batch program‘update status’ - so removing it makes the record smaller


Optimisation of Storage

- not usually as high a priority as other factors

EMP(Empno C7, EmpAddress C60, EmpQualification C40) - 107 bytes

1000 emp x 107 bytes = 107000 bytes

Using a CODE TABLE

EMP(Empno C7, EmpAddress C60, EmpQual_Code C3) - 70 bytes

1000 x 70 = 70000 bytes

EmpQual(Qual_Code C3, Qual_Desc 40) 43 x 500 = 21500 bytes


Something Different


An Exercise

A B C D


An Exercise• In the previous slide there were 4 people (A,B,C,D) who

were attempting to move from 1 side of the bridge to the other.

• There are some constraintsPerson A takes 10 minutes (carries a heavy load)Person B takes 5 minutes (carries a lighter load)Person C takes 2 minutes ( Ditto)Person D takes 1 minute (very athletic)

• In addition, they must go in pairs (it’s night-time and one must carry a torch back for the next pair to proceed in safety)

• Arrange their movement so that ALL people have completed the move in 17 minutes

Documents

2003 Monash IT Pty Ltd DataBase Design Lect 7 / 1 PHYSICAL DESIGN and IMPLEMENTATION