Physical design

1. Physical design

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

3. Physical Process Specification • Investigate software facilities and establish strategy • Create function component implementation map • Define and specify procedural processing • Consolidate the process data interface

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

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

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

7. Function Component Implementation Matrix (FCIM) • Make out a matrix, mapping function components against categories of implementation routes (i.e. A method of software construction)

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

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

10. FCIM

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

12. 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?

13. 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?

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

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

16. 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)

17. 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).

18. 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)

19. 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).

20. 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?

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

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

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

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

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

26. More checking and optimising • Identify performance and space constraints from the requirements catalogue • Estimate the required space • Estimate likely performance

27. 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) Handle problems with …