1. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 1 PHYSICAL DESIGN and IMPLEMENTATION

2. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 2

3. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 3 No relation

4. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 4 Physical and Implementation Design Performed by Data Analysts and Database Administrators Steps 1. Conceptual Model (ER Diagram) mapped onto a logical model dependent on the DBMS characteristics. 2. Optimise the logical model.

5. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 5 Map ERD to Relational Model 1. Convert the Normalised E-R Diagram to Tables 2. Transform the Attributes in the ER Diagram to columns(attributes) 3. Normalise the Table structure (data structure diagram) 4. Identify the Primary Keys 5. Identify the Referential Constraints

6. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 6 E/R Diagram EMPLOYEE DEPARTMENT PROJECT SUPERVISION DEPENDENT DEPENDENTS_OF WORKS_ON MANAGES WORKS_FOR CONTROLS N 1 11 1N 1 N N M FnameLname Name Gender Address Salary Snn Birthdate StartDate Name Number Locations Hours Name Number Location NameGenderBirthdate

7. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 7 Each Entity becomes a Table ENTITY TABLE PRIMARY KEY Employee Employee Employee_SSN Department Department Department_Number Project Project Project Number

8. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 8 1 : 1 Relationship Department Manager DeptCode(PK) EmpCode (PK) DeptName EmpName DeptFloor EmpSalary DeptContact StartDate EmpCode (FK) Address The Manager Code is actually an Employee Code, but not all Employees are Managers. Only those ‘EmpCodes’ which are allocated to Managers appear in the Department table, and are the limited set of Foreign Key values (where Department.EmpCode = Manager.EmpCode)

9. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 9 1:M Relationships - Float the PK For each 1:M relationship - float the PK from the from the entity on the 1 side to the entity on the N side where it will become a foreign key EMPLOYEE WORKS_FOR DEPARTMENT M 1 Department Number is moved into the Employee entity What would be the result if the Employee number was moved into Department entity ?

10. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 10 Weak Entities Fundamental Metaobjects are: - Entities Relationships Attributes Another metaobject is the dependent entity (or weak entity) Dependent entities cannot exist on their own, and must have a parent entity. They are identified in a M:N relation as the ‘intersect entity’ with the primary key the composite of the primary keys of the two (or more) other ‘strong entities’

11. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 11 Weak Entities become Tables For each weak entity create a table - include the Primary Key attribute(s) of the owner tables The Primary Key becomes the :- owner key plus the weak entity key Entity Table Primary Key Dependent Dependent Employee_SSN + Dependent_No

12. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 12 M:N Relationships For each M:N relationship create a new table with the Primary key being the the PK of both entities involved in the relationship EMPLOYEE WORKS_ON PROJECT Empno Hours Projno E1 P1 3 E1 P2 4 E2 P1 5 E3 P2 3

13. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 13 The M:N (or M:M) Relationship Items are Sold = 2 entities ( Items and Sale) A Sale can consist of Many Items (depending on the budget) An Item can appear in Many Sales (good for business) A third entity is created to link the entities through two 1:M relationships (known as a ‘associative’ or ‘intersect’ entity) In this example this entity name is ‘Line Item’ The Big question - why is it needed ?

14. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 14 The M:N (or M:M) Relationship Sale LineItem Item SaleNo LineNo ItemNo SaleDate LineQty ItemName SaleText LinePrice ItemType SaleNo ItemColour A Sales Order is a series of entries, and LineNo is unique to a particular order. The use of LineNo and SaleNo gives a Unique Identifier. LineItem is a Weak or Dependent Entity - its content relies on another entity for its existence and identification

15. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 15 The M:N (or M:M) Relationship We need to store data about the items sold. This data cannot be stored with SALE as a sale can be many items, and an entity can only store single-value facts Storing data with the ITEMS table is not appropriate as an Item can appear in many sales So the ‘Associative Table’ device is necessary

16. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 16 Multivalued Attributes For each multivalued attribute create a new relation. The Primary Key is the PK of the entity plus the multivalued attribute. DEPARTMENT LOCATION TABLE PRIMARY KEY DEPARTMENT_LOCATIONS DEPARTMENT LOCATION D1 MELB D1 SYD D2 MELB

17. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 17 Transforming Attributes to Columns Naming Standard Entity.(Role_)Domain Entity - the entity the attribute belongs in Role - enables the attribute to participate in the relationship Domain - data type Employee.Age Employee.Superssn - the role of the person is a manager

18. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 18 N-ary Relationships For N-ary Relationships create a new entity and float the Primary Key of each entity involved in the relationship to the new entity Supplier supplies Parts from Cities TABLES PRIMARY KEY SUPPLIER_PARTS_CITIES SNo PNo City S1 NUT MELB S1 NUT SYD

19. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 19 Include Volumes for each Table Fname Lname Essn Bdate Address M/F Salary Superssn Dno Dname DnumberMgrssn Mgrstartdate Dnumber Dlocation Essn Pnumber Hours Pname Pnumber Plocation Dnumber Essn Dependent_name M/F Bdate EMPLOYEE (100) DEPARTMENT(10) DEPT_LOCATIONS (5) WORKS_ON(500) PROJECT (20) DEPENDENT (200) p.k f.k p.k f.k NOT NULL NOT NULL

20. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 20 Logical Access Paths and Loads Trace all known outputs (reports, views, queries) through the tables required Verify the Primary, Foreign key relationships Verify the cardinality and modality Calculate transaction loads and volumes

21. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 21 Business Rules ‘ A Business Rule is a statement which defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behaviour of the business’. Business Rule Group (BRG) ‘ Business Rules Project : Final Report, October 1997 A Business Rule will affect data (presence, absence, type, size, access) processes on data (insert, update, modification, delete, calculations) integrity constraints, life of data

22. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 22 Implementation Issues Recovery Concurrency Control Security and Integrity Query Optimisation Scalability Transform to Operational State

23. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 23 Implementation Models Programs and Queries Data Model Structure Logical Data Model Structure Implementation model components Converted to Used to determine DDL Expressed in terms of Converted to access the physical database Conversion

24. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 24 Implementation Models specification Logical Design Physical Design Develop Access programs User Programs Physical Database Definition DDL Enterprise Model Access Requirements Implementation Model Languages Structure Physical Device Characteristics and Access Methods Chosen Logical Structure Implementation Model Structures Chosen Logic Database Design Techniques

25. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 25 Implementation Models user interface User Interface Software Access Method DatabasePhysical Storage Devices Physical Record Interface Logical Record Interface File Definitions and Access Commands Data Model Structure Database Access Commands Data Definitions DBMS File Processor File Processing Commands in a Programming Language Embedding SQL Operating System Disk Access Software Special Routines to Support Database Management Implementation Model Levels

26. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 26 Implementation Planning Write Programs Test Programs Install Programs Install System Plan, Develop and Install Security Plan, Develop and Install Recovery User Acceptance Strategy User Test Strategy Documentation User training Conversions : Data Loading

27. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 27 Implementation and Acceptance Testing Physical Implementation Criteria: 1. Data availability 2. Data reliability 3. Data currency 4. Data consistency 5. Data flexibility 6. Data efficiency

28. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 28 Implementation and Acceptance Testing 1. Data availability : The required data and relationships are stored in the database 2. Data reliability : The data will not be lost or corrupted 3. Data currency : The data value is the latest value of the data item 4. Data consistency : The same data values will be obtained for the same item in different queries at the same time 5. Data flexibility : Extension can be made to meet new requirements without rebuilding the database 6. Data efficiency : Storage and retrieval are at minimum cost

29. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 29 Implementation and Acceptance Testing The major components of the implementation model are : 1. A data model structure 2. Data definition languages to define the data model structure 3. The data access commands. Access specifications are embedded in programs, views, reports 4. Physical structures - based on volumes, usage, frequency of use, response times required, number of concurrent users..

30. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 30 Implementation and Acceptance Testing The Enterprise Model Data Model Structure Programs and enquiries Access Specifications to access the database Logical data model structure Database Specification Physical database structures Quantitative data

31. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 31 Implementation and Acceptance Testing 4 Fundamental capabilities of a DBMS 1. The DBMS must provide a natural interface of user data 2. The interface must be independent of any physical storage structures 3. Different users should be able to access the same database using different views of the database 4. Changes to the database to be made without affecting programs which make no use of the change

32. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 32 Implementation and Acceptance Testing The Operational Environment  Specialised use by one or a few people  The database is an integral part of a business operation and must be accessible to a large number of users who may be spread over many locations

33. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 33 Implementation and Acceptance Testing Other considerations: Concurrency control Access controls Recovery systems Database privacy

34. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 34 Implementation and Acceptance Testing A suggested Test Specification outline Test the functional areas:  Maintenance  Analysis  Tools  Exit Procedures Overall operation - menu navigation, forms opening, forms closing, button operation. Transition to a new or former state

35. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 35 Implementation and Acceptance Testing Maintenance : data entry Forms navigation Valid data entries Valid / correct calculations Tools - probably searching and sorting

36. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 36 Implementation and Acceptance Testing Test each attribute in forms, views, reports Order of presentation / appearance of input attributes Navigation around or through forms - Tab key, Enter key Is the progression accurate - what you expected - smooth What is the ‘user’ reaction - the Quality Reviewer in your team is an excellent ‘user’. Indicate ‘actions’, ‘Expected results’, Actual results or ‘OK’.

37. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 37 Implementation and Acceptance Testing Test forwards and reverse cursor movements What error messages occur ? What triggers them ? How are they cleared - a full restart ? Do you have ‘standard’ error messages or is there a clear indication of the cause and correction of the error Are attributes type protected ? Size protected ?

38. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 38 Implementation and Acceptance Testing Do you have data presentation rules ? e.g. the first character of a string in Capitals punctuation $ signs or identifiers on numeric values displayed decimal points included and positioned correctly dates in British form e.g. 12/09/2002 or 12-October-2002 How are empty attributes presented ? Blank, ??, ‘no value’ displayed ?

39. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 39 Implementation and Acceptance Testing What is your policy on deletions ? Tag and retain, release, archive ? Are there any warning messages ? Is referential integrity affected ? Are deletions logged or archived ? Who can delete ? Is there a choice to proceed or not ?

40. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 40 Implementation and Acceptance Testing How do you intend to record  successful tests  problems in tests  the action taken and the result of a re-test  who took part in the test  who prepared the data  who prepared the ‘control’ output  who ran the test  who investigated the fault, if any

41. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 41 Implementation and Acceptance Testing What does the ‘user’ expect to see ? Is the user impressed ? Does the ‘user’ required changes (terms, progression, colours, positioning..) (Quality reviewer + possibly the team co- ordinator) When were the various tests performed What was the equipment / software configuration Is it compatible with the end-user’s equipment and operating system ?

42. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 42 Implementation and Acceptance Testing What are the criteria for a  a successful test  an unsuccessful test Do you intend for a team walkthrough before a test is made or a revision test is made Who certifies the test result Who organises the test schedule - who monitors it ?

43. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 43 Implementation and Acceptance Testing Do you intend to include a glossary of terms in your Acceptance Test Specification - what terms ? Could these be superceded by a training session with the user ? What if the user leaves, gets another job, …… What form of certification are you going to present to the end- user ?

44. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 44 Implementation and Acceptance Testing What is the recommended method of recovery ? Does it work ? Is it automated or will the end user need to run through a series of keyboard operations How ‘clear’ are the instructions - is it likely that the end user will overwrite critical data ? Will you train the user as part of your delivery package ?

45. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 45 Implementation and Acceptance Testing What are the security provisions ? Who will administer them ? How secure are they ? What risk is there to the end user when the system fails ? Is there any fall back position / procedure ?

46. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 46 Implementation and Acceptance Testing Are you able, or do you intend that the end user will have access to ongoing support ? How ? What are your suggestions to the end user regarding  software upgrades (e.g. Windows2000 to Windows2002)  hardware upgrades  on line connections to the container pool  on line container/consignment tracking (e-commerce)  customer on line access

47. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 47 Implementation and Acceptance Testing How do you intend to load the initial working data for the client ? Who supplies the effort and cost ? How many rows / records are involved ? Is there going to be a delay time prior to the system being operable ? How would this gap be controlled - e.g. transactions occurring but not able to update ?

48. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 48 Other Aspects Let’s have a few comments about :- Installing Referential Integrity, and some Optimising Aspects

49. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 49 The Personnel/Works Database Fname Lname Essn Bdate Address M/F Salary Superssn Dno Dname DnumberMgrssn Mgrstartdate Dnumber Dlocation Essn Pno Hours Pname Pnumber Plocation Dnumber Essn Dependent_name Gender Bdate EMPLOYEE (100) DEPARTMENT(10) DEPT_LOCATIONS (5) WORKS_ON(500) PROJECT (20) DEPENDENT (200) p.k f.k p.k f.k NOT NULL NOT NULL

50. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 50 Referential Integrity Delete/Update Restrict/Set Null/Cascades Setting the Referential Integrity Constraint Actions can be performed as follows:-. if the Foreign Key is part of PK then you should use CASCADES - ESSN is PK in WORKS_ON. if the participation constraint is total - use RESTRICT - MGRSSN (Depts must have a MGR). if the participation constraint is partial - use SET NULL DNUMBER in EMPLOYEE Nb: These are guide-lines and the selection depends on the Business Rules.

51. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 51 Referential Integrity As you have gathered, cascade (anything) can be a very dangerous command or function - many primary and foreign keys can be inserted, updated and deleted in a single transaction For that reason it is never available to a user - it is definitely a Database Designer or Database Administrator’s tool

52. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 52 Integrity That was an appetiser There are many forms of Integrity We will be looking at these next lecture.

53. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 53 Optimise the Logical Model Optimisation - maximise/minimise a strength/weakness of a resource Therefore, we must know the characteristics of resources - cost/performance List expensive resources List cheap resources

54. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 54 Optimisation Criteria Application Development Time Execution Time Data Storage Flexibility. trade-off between the above depending on the priorities of the user (User Level Agreement)

55. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 55 Optimisation of Development Time - keep the design simple - avoid complex relationships - no tricks - must have staff who are familiar with products e.g. Rapid Application Development techniques

56. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 56 Optimisation of Execution Time Reduce the amount of energy used against critical paths (Translates to : - reduce the amount of work against access paths) Use Indexes (cautiously) Use Controlled Redundancy Split Attributes if Processing Requirements are Different

57. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 57 Controlled Redundancy Tradeoff against flexibility - waste space, extra maintenance, more programming, more program work > 20% redundancy - design problems CUSTOMER Custno, CustName, CustAddress, CustStatus ORDER Orderno, Custno, OrderTotal, OrderDate

58. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 58 Add Control Fields CUSTOMER Custno, CustName, CustAddress, CustStatus, CustBalance ORDER Orderno, Custno, OrderTotal, OrderDate - totals are stored rather than calculated at query time

59. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 59 Add Key Data CUSTOMER Custno, CustName, CustAddress, CustStatus, Last_Orderno, Last_OrderDate ORDER Orderno, Custno, OrderTotal, OrderDate - this will allow us to bring back the most recent order and answer queries such as “What was the last date Customer Smith made an order?”

60. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 60 Elemental Redundancy CUSTOMER Custno, CustName, CustAddress, CustStatus ORDER Orderno, Custno, OrderTotal, OrderDate, Custaddress - when we go to print out the Invoice we will not need to go to the Customer file to get the address

61. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 61 Split Attributes where Different Processing Required CUSTOMER Custno, CustName, CustAddress CUSTOMER BATCH Custno, CustStatus - the status is only used by batch program ‘update status’ - so removing it makes the record smaller

62. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 62 Optimisation of Storage - not usually as high a priority as other factors EMP(Empno C7, EmpAddress C60, EmpQualification C40) - 107 bytes 1000 emp x 107 bytes = 107000 bytes Using a CODE TABLE EMP(Empno C7, EmpAddress C60, EmpQual_Code C3) - 70 bytes 1000 x 70 = 70000 bytes EmpQual(Qual_Code C3, Qual_Desc 40) 43 x 500 = 21500 bytes

63. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 63 Something Different

64. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 64 An Exercise A B C D

65. © 2003 Monash IT Pty Ltd DataBase Design Lect 7 / 65 An Exercise In the previous slide there were 4 people (A,B,C,D) who were attempting to move from 1 side of the bridge to the other. There are some constraints Person A takes 10 minutes (carries a heavy load) Person B takes 5 minutes (carries a lighter load) Person C takes 2 minutes ( Ditto) Person D takes 1 minute (very athletic) In addition, they must go in pairs (it’s night-time and one must carry a torch back for the next pair to proceed in safety) Arrange their movement so that ALL people have completed the move in 17 minutes