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 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

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)