Physical design. Stage 6 - Physical Design Retrieve the target physical environment Create physical...
-
date post
21-Dec-2015 -
Category
Documents
-
view
245 -
download
1
Transcript of Physical design. Stage 6 - Physical Design Retrieve the target physical environment Create physical...
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 super-
functions.
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
FCIM
Server side
Components
Client side
Screen layout *Input validation *Data access * *Database triggers *Business Rules *Data transfer *Input layout *Input validation *Data access *Database triggers *Business Rules *Data transfer *
Server side
Components
Ord
er v
ia W
eb
Ord
er L
oca
lly
Client side
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