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

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)