Transcript Mitilec07

PHYSICAL DESIGN and IMPLEMENTATION
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 1
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 2
No relation
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 3
Physical 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.
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 4
Map 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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 5
E/R Diagram
Fname
Lname
Name
N
Gender
Salary
Address
WORKS_FOR 1
StartDate
Snn
EMPLOYEE
1
MANAGES
1
CONTROLS
Hours
1
Locations
DEPARTMENT
Birthdate
1
Number
Name
M
WORKS_ON
SUPERVISION N
N
PROJECT
DEPENDENTS_OF
Location
Name
N
Number
DEPENDENT
Name
© 2003 Monash IT Pty Ltd
Gender
Birthdate
DataBase Design Lect 7 / 6
Each Entity becomes a Table
ENTITY
TABLE
PRIMARY KEY
Employee Employee Employee_SSN
Department Department Department_Number
Project
Project
Project Number
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 7
1 : 1 Relationship
Department
Manager
DeptCode(PK)
EmpCode (PK)
DeptName
EmpName
DeptFloor
EmpSalary
DeptContact
StartDate
EmpCode (FK)
Address
The 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)
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 8
1:M Relationships - Float the PK
For each 1:M relationship - float the PK from the from the
entity on the 1 side to the entity on the N side where it
will become a foreign key
EMPLOYEE
M
WORKS_FOR
DEPARTMENT
1
Department Number is moved into the Employee entity
What would be the result if the Employee number was
moved into Department entity ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 9
Weak Entities
Fundamental Metaobjects are: -
Entities
Relationships
Attributes
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’
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 10
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 11
M:N Relationships
For each M:N relationship create a new table with the
Primary key being the the PK of both entities involved
in the relationship
EMPLOYEE
Empno
WORKS_ON
Hours
E1
E1
E2
E3
© 2003 Monash IT Pty Ltd
PROJECT
P1
P2
P1
P2
Projno
3
4
5
3
DataBase Design Lect 7 / 12
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 13
The M:N (or M:M) Relationship
Sale
SaleNo
SaleDate
SaleText
LineItem
LineNo
LineQty
LinePrice
SaleNo
Item
ItemNo
ItemName
ItemType
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 14
The M:N (or M:M) Relationship
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 15
Multivalued Attributes
For each multivalued attribute create a new relation.
The Primary Key is the PK of the entity plus the
multivalued attribute.
DEPARTMENT
TABLE
DEPARTMENT_LOCATIONS
LOCATION
PRIMARY KEY
DEPARTMENT LOCATION
D1
D1
D2
© 2003 Monash IT Pty Ltd
MELB
SYD
MELB
DataBase Design Lect 7 / 16
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 17
N-ary Relationships
For N-ary Relationships create a new entity and float the
Primary Key of each entity involved in the relationship
to the new entity
Supplier supplies Parts from Cities
TABLES
SUPPLIER_PARTS_CITIES
© 2003 Monash IT Pty Ltd
PRIMARY KEY
SNo
PNo
S1
S1
NUT
NUT
City
MELB
SYD
DataBase Design Lect 7 / 18
Include Volumes for each Table
EMPLOYEE (100)
Fname Lname Essn Bdate Address M/F Salary Superssn Dno
p.k
DEPARTMENT(10)
f.k
Dname Dnumber Mgrssn Mgrstartdate
p.k
DEPT_LOCATIONS (5)
Dnumber Dlocation
WORKS_ON(500)
f.k
f.k
Pname Pnumber Plocation Dnumber
Essn Pnumber Hours
NOT
NULL
© 2003 Monash IT Pty Ltd
NOT
NULL
PROJECT (20)
f.k
DEPENDENT (200)
Essn Dependent_name M/F
Bdate
DataBase Design Lect 7 / 19
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 20
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 21
Implementation Issues
Recovery
Concurrency Control
Security and Integrity
Query Optimisation
Scalability
© 2003 Monash IT Pty Ltd
Transform to Operational State
DataBase Design Lect 7 / 22
Implementation Models
Converted to
Converted to
Programs
and
Queries
Data
Model
Structure
Expressed in terms DDL
of
Logical
Data
Model
Structure
Converted to
access the physical
database
Used to determine
Implementation model components
Conversion
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 23
Implementation Planning
Write Programs
Test Programs
Install Programs
Install System
Plan, Develop and Install Security
Plan, Develop and Install Recovery
User Acceptance Strategy
User Test Strategy
Documentation
User training
Conversions : Data Loading
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 26
Implementation and Acceptance Testing
Physical Implementation
Criteria:
1. Data availability
2. Data reliability
3. Data currency
4. Data consistency
5. Data flexibility
6. Data efficiency
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 27
Implementation and Acceptance Testing
1. Data availability : The required data and relationships are
stored in the database
2. Data reliability : The data will not be lost or corrupted
3. Data currency : The data value is the latest value of the data
item
4. Data consistency : The same data values will be obtained
for the same item in different queries at the same time
5. Data flexibility : Extension can be made to meet new
requirements without rebuilding the database
6. Data efficiency : Storage and retrieval are at minimum cost
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 28
Implementation and Acceptance Testing
The major components of the implementation model are :
1. A data model structure
2. Data definition languages to define the data model structure
3. The data access commands. Access specifications are
embedded in programs, views, reports
4. Physical structures - based on volumes, usage, frequency of
use, response times required, number of concurrent users..
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 29
Implementation and Acceptance Testing
The Enterprise Model
Access Specifications
Data Model Structure
Programs and enquiries
to access the database
Logical data model structure
Database Specification
Physical database structures
Quantitative data
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 30
Implementation and Acceptance Testing
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 31
Implementation and Acceptance Testing
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 32
Implementation and Acceptance Testing
Other considerations:
Concurrency control
Access controls
Recovery systems
Database privacy
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 33
Implementation and Acceptance Testing
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 34
Implementation and Acceptance Testing
Maintenance : data entry
Forms navigation
Valid data entries
Valid / correct calculations
Tools - probably searching and sorting
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 35
Implementation and Acceptance Testing
Test each attribute in forms, views, reports
Order of presentation / appearance of input attributes
Navigation around or through forms - Tab key, Enter key
Is 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’.
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 36
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 37
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 38
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 39
Implementation and Acceptance Testing
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 40
Implementation and Acceptance Testing
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 coordinator)
When were the various tests performed
What was the equipment / software configuration
Is it compatible with the end-user’s equipment and operating
system ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 41
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 42
Implementation and Acceptance Testing
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 enduser ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 43
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 44
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 45
Implementation and Acceptance Testing
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 46
Implementation and Acceptance Testing
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 ?
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 47
Other Aspects
Let’s have a few comments about :Installing Referential Integrity,
and some Optimising Aspects
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 48
The Personnel/Works Database
EMPLOYEE (100)
Fname Lname Essn Bdate Address M/F Salary Superssn Dno
p.k
DEPARTMENT(10)
f.k
Dname Dnumber Mgrssn Mgrstartdate
p.k
DEPT_LOCATIONS (5)
Dnumber Dlocation
WORKS_ON(500)
f.k
f.k
Pname Pnumber Plocation Dnumber
Essn Pno Hours
f.k
NOT
NULL
© 2003 Monash IT Pty Ltd
NOT
NULL
PROJECT (20)
DEPENDENT (200)
Essn Dependent_name Gender Bdate
DataBase Design Lect 7 / 49
Referential Integrity
Delete/Update Restrict/Set Null/Cascades
Setting the Referential Integrity Constraint Actions
can be performed as follows:-
. if the Foreign Key is part of PK then you should use
CASCADES - 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 NULL
DNUMBER in EMPLOYEE
Nb: These are guide-lines and the selection depends on the
Business Rules.
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 50
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 51
Integrity
That was an appetiser
There are many forms of Integrity
We will be looking at these next lecture.
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 52
Optimise the Logical Model
Optimisation - maximise/minimise a strength/weakness
of a resource
Therefore, we must know the characteristics of resources
- cost/performance
List expensive resources
List cheap resources
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 53
Optimisation Criteria
Application Development Time
Execution Time
Data Storage
Flexibility
. trade-off between the above depending on the priorities
of the user (User Level Agreement)
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 54
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 55
Optimisation of Execution Time
Reduce the amount of energy used against critical paths
(Translates to : - reduce the amount of work against
access paths)
Use Indexes (cautiously)
Use Controlled Redundancy
Split Attributes if Processing Requirements are
Different
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 56
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 57
Add Control Fields
CUSTOMER
Custno, CustName, CustAddress, CustStatus, CustBalance
ORDER
Orderno, Custno, OrderTotal, OrderDate
- totals are stored rather than calculated at query time
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 58
Add Key Data
CUSTOMER
Custno, CustName, CustAddress, CustStatus,
Last_Orderno, Last_OrderDate
ORDER
Orderno, Custno, OrderTotal, OrderDate
- this will allow us to bring back the most recent order
and answer queries such as “What was the last date
Customer Smith made an order?”
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 59
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 to
go to the Customer file to get the address
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 60
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 61
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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 62
Something Different
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 63
An Exercise
A
© 2003 Monash IT Pty Ltd
B
C
D
DataBase Design Lect 7 / 64
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 constraints
Person 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
© 2003 Monash IT Pty Ltd
DataBase Design Lect 7 / 65