Download Physical design

Physical design
Stage 6 - Physical Design
•
•
•
•
•
•
Retrieve the target physical environment
Create physical data design
Create function component implementation map
Optimise physical data design
Complete function specification
Consolidate process/ data interface
Physical Process Specification
• Investigate software facilities and establish
strategy
• Create function component implementation
map
• Define and specify procedural processing
• Consolidate the process data interface
Investigate and Establish Strategy
• Evaluate physical options available using
– Expertise in the software tool(s)
– Understanding of the organisation
– Understanding of the required system
• Considerations:– Minimise development and maintenance staff costs.
– Make the implementation structures as simple as
possible
– Make the interface between the users and the stored
data straightforward
Evaluating Options
• Use a decision tree.
– What sort of components are used in the IS? What are the
important features?
– What hardware and software options are available? Make out a
processing system classification for each tool considered.
– Which tools are suitable for which components?
– Can the components of a function be treated separately or are they
indivisible?
• Work out a naming strategy for the components.
– Provide the user with adequate performance levels.
Function Types
• Functions are made up of components
• Universal function model consists of
components for Input, Main, Output and
Error processing
• Special function models are those which do
not follow this pattern
• Some functions will use shared re-usable
processes
Function Component
Implementation Matrix (FCIM)
• Make out a matrix, mapping function
components against categories of
implementation routes (i.e. A method of
software construction)
FCIM
• When designing the FCIM, implementation routes
could be grouped according to:– their component types
• e.g. on-line input and output together
– the tools used to implement them
– the function types (update, enquiry, etc).
• At system level, look for reuse
• Functions which can be shared become superfunctions.
FCIM
• Low-level routines can be shared as can some
input, output or database processes.
– Treat each function in detail.
– Define the amount of processing that constitutes a
success unit, which usually represents an event.
– Specify detail of error, input, output and control
processing
Order via Web
*
*
*
*
*
*
ys
t
S
L
*
Database triggers
in
g
/S
ra
t
O
pe
++
C
Ja
va
ss
cc
e
*
Data access
Data transfer
A
*
*
Data transfer
Business Rules
/J
S
SP
A
O
D
*
Business Rules
Input validation
P
C
/J
D
B
al
*
Database triggers
Input layout
Q
B
ic
C
V
is
u
Server side
*
Input validation
Data access
V
Ja
H
s
te
TM
va
L
ou
R
Sc
ri
p
t/
n
tio
ta
Components
Screen layout
Order Locally
Se
r
B
S
en
m
ve
r
cr
ip
t
e
pl
Client side
B
as
Im
FCIM
Remainder
• Define and specify procedural processing
– Logical components become physical fragments
– Specify in detail and write software
• Consolidate the process data interface (PDI)
– Define interfaces between physical data and
processing units (i.e. what middleware?)
– Record all validation routines or special
processing modules
Processing System Classification
• What type of objects can this tool create?
• Can procedural and non-procedural fragments be
mixed?
• Can on-line and off-line fragments be mixed?
• What options exist for defining success units?
• What options exist for defining error processing?
• How are run time processing modules
constructed?
• What database access facilities are provided?
Processing System Classification
• Can update or enquiry only processes be created?
• Can data be grouped together for I/O, with screens
or reports?
• What types of dialogues can be created?
• How can navigation through dialogues be
constructed?
• Can the tool support the creation of a customised
PDI? How?
• To what extent does the tool mask the designer
from the physical distribution of data?
Physical Data Design
• Keep in mind:
– Keep development/maintenance costs to a
minimum.
– Make the interface between the users and the
stored data straightforward.
– Provide the users with adequate performance
levels.
• ERD translates to DBMS being used
Physical Data Design
• Assume, that the DBMS uses:–
–
–
–
Records, to store entity occurrences
Blocks, of physical storage
A mechanism to relate master to detail entities
Some other mechanisms for other types of
relationships
• Use same staff for logical and physical data
design
Data Storage Classification
• How are relationships stored?
– Table - the DBMS has a table holding the key
values for all detail records for each occurrence
of the master, beside the master. (e.g. Relational
database)
– List - master records and their details are
chained together. (e.g. network database)
– Phantom - there is no physical relationship,
only a relationship due to a foreign key (e.g.
indexed sequential files, with the master key
existing as a foreign or secondary key in the
detail file).
• Where are relationships stored?
– Separately from the data in a table or list or
alongside the data records (either the master or
the detail data).
Data storage classification
• Are the keys to relationships symbolic or
physical?
– The keys may consist of one or more informational
attributes of the entity, or they may just indicate the
location of the record in the file.
• What strategies are provided to locate records?
– Searching sorted records, hashing or indexing are
possibilities.
• What are the overheads for transaction logging?
• What are the overheads for recording snapshots?
(backups, before and after update images)
DBMS Performance Classification
• What is the commit strategy?
– (At commit time, all updates may be done, or if rolled
back, some may be undone)
• Overhead for physical space management?
– (Dynamic storage management may move data around)
• Overhead for recording the context of dialogues?
– (i.e. From what DBMS context a user performed an
operation).
• Standard timing data needed (read/write/overflow)
• Performance characteristics of sorts?
• Can records be placed physically near to other
records and if so, how?
• In what ways might the DBMS restrict the
implementation of the LDM?
Design the physical data
•
•
•
•
•
•
•
Extract information from the Logical Data Model
Add entry points to the diagram
Define group roots
Group entities around the roots
Select root, if there is a choice of root
Establish group size
Fit the groups into blocks
• Extract information from the LDM
– Copy entities, replacing soft boxes with rectangles
– Include volume data and relationship ratios
– Draw the relationships as continuous lines, omitting
names
– Record optionality, only from the detail end, with circle
– Ignore exclusive arcs, from masters to details and
details to masters
Design the physical data
• Add entry points to the diagram
– (taken from ECDs and EAPs) as a list of key fields
alongside an arrow pointing to the entry entity.
– Non-key fields which are entry points are shown in an
oval.
• Define group roots
– A root of a group either has no master, or is an entry
point, where its key does not contain its master's key, if
its master is a root
Design the physical data
• Group the entities around roots
– A non-root entity may be grouped with a root entity if
it is its mandatory master or it has a mandatory master
which has already been grouped with that root
• Select groups where there is a choice
– If the entity is a direct entry point, but not a root,
group it with the master which is a root, and whose
key is contained in its key.
– Put entities in the groups where they occur least
Physical data design
• Establish the group size
– using the entity descriptions and attribute descriptions
in the data dictionary, as well as ratios between masters
and details
• Fit groups into physical blocks
– Derive a block size, taking into account the memory
buffer size and record locking level. The block size
should hold the group, without being too large
• Follow manufacturers guidelines
More checking and optimising
• Identify performance and space constraints
from the requirements catalogue
• Estimate the required space
• Estimate likely performance
Handle problems with …
• Space
– change the constraints,
– change the groups
– use a compression
technique
• Timing
– change the constraints
– Change the physical
data design
• (record groupings,
transaction logging,
security copying, etc)