Database System For Obstetrics & Gynaecology at St. James s Hospital

Transcription

1 Database System For Obstetrics & Gynaecology at St. James s Hospital Tristan Sehgal BSc Computing (Cert. Ind) The candidate confirms that the work submitted is their own and the appropriate credit has been given where reference has been made to the work of others. I understand that failure to attribute material which is obtained from another source may be considered as plagiarism. (Signature of student) i

2 Summary The problem presented and solved in this project report is that of building an interactive database system for a new research project within the Obstetrics and Gynaecology department of St. James s Hospital, Leeds. The head of the research study is Dr. Nick Wood and he is the person who requested the system. A system was required to enter/edit and view all the information generated from and associated with the research study. This project has taken the requirements of the end user through to the final deployment of the system and this report describes the phases that achieved this. ii

3 Acknowledgements I would like to thank Dr. Nick Wood for placing his trust in me to produce the database system for his research project, his helpful comments throughout and being a pleasure to work with. I would also like to thank my project supervisor, Dr. Stuart Roberts for his constant support, guidance and encouragement throughout this project. Thanks also to Naomi Quinton at St. James s Hospital for helping to evaluate the system. Thanks to Chris O Hara for reviewing the code and thanks to Craig Lambert for lending me various books and computer equipment. iii

4 Table of Contents Summary...ii Acknowledgements...iii 1 Introduction Overview of problem Motivation for project Project Objectives Previous Attempts at Solving Problem Background Research Project Management Requirements Engineering Types of Requirement Requirement Gathering Requirement Documentation Data Modelling User Interface Design Participatory Design Presenting Data Data Entry Software Testing Security in Microsoft Access Methodologies Software Development Methodology Database Design Methodology Project Planning Milestones for completion Project scheduling Requirements Gathering Initial discussions with Nick Wood Data storage requirements Storyboarding Requirements Specification Hardware and Software decisions Hardware Software Choice of DBMS Choice of application development software Final System Architecture...18 iv

5 7 Database Design and Construction Conceptual Design: High Level Data Modelling Entities Relationships Entity Attributes Integrity Constraints Logical Design 1: Defining the database schema Identifying Primary Keys Foreign Keys and Referential Integrity Documenting the Initial Schema Logical Design 2: Normalisation Functional Dependencies Normalising to 1 st Normal Form Normalising to 2 nd Normal Form Normalising to 3 rd Normal Form Physical Design and Implementation Further iterations to the methodology Implementation GUI Creation Example: Saving a Patient s First Visit Details Selecting information from the database Selecting information from the database Checking the required information has been entered Saving From the GUI to the Database Error Handling Example: Editing a Patient s First Visit Details Testing Overview System testing User acceptance testing Deployment Installation Security and Backup Design Documentation Evaluation Defining project success Adjustments to the minimum requirements Minimum requirements Were the Minimum Requirements Met? How well were the Minimum Requirements Met? Extended requirements implemented User satisfaction Quality, maintainability and extendibility of code Software/Hardware choices Extending the solution further Data Analysis Tools...46 v

6 Mailmerge External Data Access Project management Conclusions...47 Bibliography Glossary of Terms Appendix A: Personal Reflection Appendix B: Summary of initial meeting with Nick Wood Appendix C: Initial Project Schedule Appendix D: Revised Project Schedule Appendix E: Requirements Specification Appendix F: Database Schema Appendix G: System Screenshots Appendix H: Example Test Script Appendix I: Change Requests Appendix J: End User Feedback vi

7 1 Introduction 1.1 Overview of problem Within the Obstetrics and Gynaecology department of St. James s Hospital, Leeds, a new research project has started, the leader of which is Dr. Nick Wood. The patients being studied in the research project are known as HNPCC patients (hereditary non-polypois colorectal cancer) as they have been identified as being at risk of this form of cancer. There are two principal aims of this research study. The first is to try and determine the medical factors which could be used to predict whether or not an HNPCC patient is likely to suffer from cancer. The second is to assess whether the study is acceptable to the patients who it is being carried out on. A significant amount of data will be generated from the research study in the form of patient details, results of examinations, tissue bank data and questionnaire results. The study leader wants this data to be easily accessible to all those involved with the study. In addition, he requires an easy method to view, edit and enter the data generated from the study. In order for this desire to be fulfilled, a database will need to be constructed together with a graphical user interface. 1.2 Motivation for project Without a database to store the data from the study, all the results would have to be stored on paper and stored in a filing cabinet. A number of problems with this paper based approach could be solved by introducing an electronic database system. Firstly, all the data can be well structured and strictly organised in a database. There is no risk for example of someone recording the same information for a patient twice because database constraints could be used to prevent this. With a database, the data is guaranteed to be put in the place it belongs. For example the results from one type of experiment won t get mixed up with those from another. The motivation for implementing a GUI on top of the database is that it will allow the users at St. James s Hospital to enter and edit data without any knowledge of the DBMS being used or the database schema. Technical details such as runtime SQL queries and referential integrity constraints need not concern the users at St. James s Hospital. Providing a GUI to view the data means that it is available easily and instantaneously to anyone who has the permission to view it. Storing the data on the database also means that it can be secured and that patient details remain strictly confidential. 1

8 1.3 Project Objectives In order to understand the full extent of the problem it was necessary to discuss the high level objectives of the system to decide if what was required would be too much to complete in the time given or too little. In addition, various implicit objectives such as ensuring data consistency needed to be made explicit as to effectively scope the work required. Most of the key objectives were made clear from the initial meeting with Nick Wood (see Appendix B) and are documented below: Gather and document a full set of requirements from the end users of the system. Produce a relational data model of the data that has been normalised to at least 3 rd Normal Form. Map the data model to tables in a DBMS. Enforce data integrity checking. Provide graphical user interfaces for data entry and modification. Produce an SQL query wizard so that users can quickly, group and filter required data. Ensure the database is secure and has backup mechanisms in place. Fully test and deploy the system so that it is ready for use by the end users. 1.4 Previous Attempts at Solving Problem Nick Wood had already created an MS Access 2000 database with one table and one form for entering data into that table. No functionality was present behind the form and the table contained attributes of everything to do with patients, their visits and results. Other than this no attempt had been made at producing a database, no requirements had been documented, no data model produced and no implementation were present. 2

9 2 Background Research 2.1 Project Management For this project to be successful deadlines must be meet and the end users of the system satisfied with what they get. If deadlines are to be meet then sensible time management is crucial which leads to the need for a project plan. O Connell (1996), provides an entire chapter on assessing project plans. Emphasis is placed on defining a critical path, i.e. the path that the project must follow to be meet its deadline, any deviations from which will lead to delay. The project schedule for this project will be in the form of a Gant Chart because this provides a clear view of the plan. O Connel (1996) provides a section detailing how these can be assessed. O Connel (1996) provides the following analysis for assessing a project plan: Shows what the main phases are and how long they should last. How the phases relate to each other. The amount of work required in each phase. 2.2 Requirements Engineering No previous attempts have been made in solving the problem so no formal set of requirements exists. Research was therefore taken to review the process for gathering, classifying and documenting system requirements. Requirements documentation is needed to form the basis of an agreement between the developer (Tristan Sehgal) and client (Nick Wood) as to what work should be completed (Kotonya and Sommerville (1998)) Types of Requirement All the literature reviewed relating to requirements discusses two broad classification of requirement, functional and non-functional. Functional requirements define the tasks that the system must perform, i.e. its functionality. Non-functional requirements define the safety, security, usability, reliability and performance requirements (Kotonya and Sommerville (1998)). For this project, usability and security issues are important because several users will need to use the system without difficulty and only certain users should have access to the system Requirement Gathering Because there is no clear set of requirements, techniques will have to be employed to gather them. Kotonya and Sommerville (1998) discuss several elicitation techniques: Interviews, scenarios, soft 3

10 system methods and observational analysis. Interviews are appropriate to this project because there is only on key user that will decide what is required from the system. Scenarios involve discussing with the users how the system would typically need to interact with them, this again would be useful because it is the key end user who will know how the system should behave. In order to ascertain how the system should work, real life examples and situations where the system shall be used are a good method of elicitation. This technique is good because end-users can relate to it and developers can clarify the existing requirements (Kotonya and Sommerville (1998)). Observation and social analysis techniques can t be used because the research project at St. James s Hospital is not underway yet Requirement Documentation Requirements documentation should include: Product functions, user characteristics, general constraints, assumptions and dependencies (Kotonya and Sommerville (1998)). The Rational Requisite Pro tool was considered for documenting requirements but discarded due to its complexity and heavy orientation towards very large projects using the Rational Unified Process. 2.3 Data Modelling Data modelling is required in order to build robust, extensible databases (Mott and Roberts (1999)) which are both properties required for the database in this project. Data modelling will be required because the only form the data is in at the start of the project is a list of data fields. There is a significant amount of data involved with this project so it is important that it is modeled correctly so that the database constructed is valid. According to Watson (2002), there are two criteria for judging the quality of a data model: 1. It should be well formed and 2. It should have a high fidelity image. The key attributes (as identified by Watson (2000)) of a data model with a high-fidelity image are that it Correctly describes the world it is supposed to represent and be Complete, understandable, accurate and syntactically correct. There are a number of ways in which in which in an entity-relationship model can be documented. Kotonya and Sommerville (1998) discuss the disadvantages of using the standard Codd and Date model. Firstly it is not possible to assign types to relations and secondly it is poor at modelling the exact nature of relationships between entities. For this project the first problem is not an issue but the second is. There are many relationships which will require clear understanding as part of the requirements phase e.g. many blood samples can be taken from one blood test. 4

11 As an alternative, Rock-Evans notation allows the cardinality and relationship names to be shown clearly and so this is the notation that has been chosen to use for this project. There are two CASE (Computer Aided Software Engineering) tools that were discovered for producing an ER diagram, Dia on the Linux operating system and Microsoft Visio on the windows platform. Microsoft Visio was chosen as it provides full notation support and is easy to use. 2.4 User Interface Design This section outlines the literature reviewed in relation to designing and building the GUI (Graphical User Interface). This research has been done because it is anticipated that a large number of screens will be required for the final GUI. For example initial discussions with Nick Wood suggest that the first visit details could have between fifty and sixty fields. Several screens will therefore be required to avoid cramming all the data onto a small number of screens. As the system is to be used by end users to help them with their work, the system will need to be easy to use. As it is the GUI they will be interacting with, it must be designed with the end users in mind Participatory Design This project is heavily dependent on the needs of two to three key users so the following details how users can be participate in the design of the GUI. Dix et. al. (1998) outlines three methods in which to get the end users involved: Brainstorming, storyboarding, pencil and paper exercises and workshops. Brainstorming involves the users and developers sitting round bouncing ideas off each other and is informal. Storyboards are a means of describing the user s day-to-day activities, Dix et. al. (2002). Wood (1998) describes storyboarding as producing a series of walkthrough steps in relation to the various windows in the system. Unlike brainstorming sessions these provide a more focused view on design. The role of the designer is to question the user about their environment and the role of the users is to question the designer on technical issues and concepts. Wood (1998) describes user involvement rather than user participation, this involves providing the user with prototypes to evaluate, rather than the user directly having an influence on the precise layout of the GUI. The argument for user participation is that the user best knows the environment that the system will be involved in. The argument against it is that it can slow the development down due to the shift of power and responsibility, Wood (1998). In this project there is only one developer and two-three end users so it would seem sensible to involve the users as much as possible but not to the extent of actually designing the GUI because they will not have the time or knowledge to do so. 5

12 2.4.2 Presenting Data There will be many occasions when users will simply want to view information directly from the database or from the result of a query. Consistency of data displayed, efficient information assimilation by the user, minimal memory load on the user, compatibility of data display with data entry, and flexibility for user control of data display are the criteria for good data display interfaces that Schneiderman (1998) identifies Data Entry A lot of data will need to be entered for each patient so it is important this is well designed. There are number of criteria which Schneiderman(1998) identifies that can be used to judge how good the data entry interface is: Consistency of data-entry transactions, minimal input actions by user, minimal memory load on users, compatibility of data entry with data display, flexibility for user control of data entry. These criteria are highly relevant to this project as GUI s must provide an easy way to enter data into the system. 2.5 Software Testing To ensure that the system functions as specified it will need to be fully tested to remove errors in the software. According to Sommerville (1995): Users are most interested in the system meeting its requirements and testing should be planned so that all requirements are individually passed. It is therefore intended to cross reference each requirement to a specific test case when it comes to the writing of test plans. As this system is being built for users other than the developer, it will need to go through a process of user acceptance testing and this should be done using customer supplied data (Sommerville (1995)) so it is intended the users at St. James s will test the system with their own patient data. 2.6 Security in Microsoft Access 2000 It was stated at the start of the project. by Nick Wood that the database should be made as secure as possible. Because it was clear from the start that MS Access 2000 would also be the likely DBMS (described in detail in Chapter 6) research was carried out on securing MS Access databases. Microsoft has a Frequently Asked Questions page on security in MS Access 2000 which details the steps that are needed in order to secure an MS Access database (Microsoft (2000b). Principally this involves creating a new workgroup information file. This file contains a profile of the users of the system together with the permissions they do and don t have. Once this file has been set up, different users can be given different permissions on the objects within the database such as tables, forms and 6

13 reports (Microsoft (2000a). This is of relevance because Nick Wood wants some people to only be able to read data and others to able to edit it. 7

14 3 Methodologies This project will need to deliver a piece of software to St. James s Hospital which is robust, delivered on time, and meets the specified minimum requirements. A software methodology is therefore required to achieve this as it provides a structured and well tested approach that can be applied to solving a problem. As this project is based on an underlying database, a methodology will also be required for modelling the data and creating a valid database. 3.1 Software Development Methodology Having had initial discussions with Nick Wood (see Appendix B), it was clear that he wanted not just a database but a GUI and additional functionality built in as well. Designing and building the system immediately would not have been a sensible approach as the project in the initial stages had not been scoped, planned or linked together. A software development methodology was therefore chosen in order to help resolve these issues. The classic software development methodology is the waterfall lifecycle model (Krutchen (2000)) and is depicted in Figure 3.1: Requirements Design Implementation Testing Deployment Figure 3.1 Classic Waterfall model The link between the lifecycle model and this project is clear. Requirements analysis will involve meetings with Nick Wood. These meetings will aim to find out the precise details of what must be stored on the database and how the data is to be manipulated. The design phase will involve designing the database structure and GUI prototyping. The implementation phase will involve creating the database and complete GUI. Testing will involve unit testing and user acceptance testing. Deployment will involve installing the system at St. James s Hospital and building in security. 8

15 A number of problems however have been identified with relating this methodology to this project. Firstly the HNPCC project at St. James s Hospital is new in itself so there is a high probability that requirements will need to be modified, added and removed as the project progresses. The lifecycle model is not an iterative methodology and does not therefore allow multiple iterations of lifecycle phases. The success of this project will depend on the user s satisfaction of what is finally delivered. By demonstrating or even providing different versions of the software at the earliest possible stage there is a higher probability of problems being addressed earlier. As early feedback can be generated from the iterative approach, it minimises risk and is superior to the lifecycle model (Larmen (1997)). A more iterative approach is therefore required. Krutchen (2000) outlines such as approach which has been depicted in Figure 3.2: Initial Planning Analysis and Design Requirements Implementation Evaluation Testing Deployment Figure 3.2 Iterative and incremental development (Krutchen (2000)) Once an initial cycle of development has been carried out, evaluation can take place which will involve discussing the work done, what s wrong with it and what needs to be done next, at the regular meetings with Nick Wood. This process will involve prototyping which involves rapidly building small versions of the system for the purposes of user feedback (Atzeni et. al (1999)). Although the development will be iterative there are some constraints on the ordering of what can be designed and implemented first. Because the GUI will be highly dependant on the database (as its purpose is to manipulate the data), an initial database schema will be needed before GUI prototyping can begin. In addition, the functionality required to map the GUI to the database can only start once there is a database and GUI to start working with. 9

16 The Rapid Application Development (RAD) methodology for software development was also considered as it involves building quick prototypes of the GUI and refining it based on user needs. The characteristics of this project mean that RAD could be considered a suitable methodology because RAD can be used for systems which are interactive and the functionality is clear at the user interface (Davies (1998)). It is intended that rapid prototypes will be created and reviewed by Nick Wood so that he his happy with what gets delivered. In terms of the overall development however, RAD was discarded because the iterative lifecycle methodology clearly defines the ordering and phases that this project will need to take e.g. requirements will have to be initially gathered before any prototyping can begin. 3.2 Database Design Methodology Although the overall iterative approach to solving the problem is sufficient for the overall stages in the project, a large part of the project relies on a well structured and robust database, the processes and planning required to achieve this are not however part of the chosen software methodology. A process for designing the database was therefore chosen to ensure a structured and proven approach could be taken to ensure that the data storage requirements could be met. In terms of the overall development cycle, the database design fits into the system analysis and design while the database construction fits into the implementation phase (Atzeni et. al (1999)). The steps required for database construction outlined by Atzeni et. al (1999) is shown in Figure 3.3: Conceptual Design Conceptual Schema Logical Design Logical Schema Physical Design Physical Schema Figure 3.3 Database development process (Atzeni et. al (1999)). 10

17 This methodology is analogous to that referred to by Elmasri (2000). It is also the approach to database design described by Mott & Roberts (1999). The conceptual phase involves producing a very high level description of the data, the primary output being an entity relationship diagram. Many of Nick Wood s requirements are related to the data he wants to be stored so there will be overlap between the requirements phase of the overall development and building an image of the data. The logical design can be subdivided into the following processes: 1. Building an ER Model, 2. Identifying integrity constraints and 3. normalisation, (Atzeni et. al (1999)) all of which will be necessary to meet the data storage requirements of this project as is explained in Chapter 7. The physical design is concerned with mapping the logical schema onto the DBMS. As the development will be iterative in nature, it will follow that the database design will be iterative as it fits into the software lifecycle. If for example an HNPCC patient could only answer one type of questionnaire changes to the ER diagram down to the physical structure of the database would have to be modified. 11

18 4 Project Planning This chapter describes the processes taken to plan the duration and dates of the phases required to complete the system. 4.1 Milestones for completion Before any schedule could be devised, any hardware/software decisions made or any thought given to the design, an initial iteration of the requirements phase was needed in order for the system to be scoped and an acceptable solution agreed with the user. An initial milestone was to therefore create a formal requirements specification. The goal of the requirements phase and therefore this project milestone is to provide a clear communication between the client and developer the needs of the system (Larmen (1998)). The results of achieving this milestone and the steps taken to achieve this milestone have been explained in Chapter 5. Once an initial set of requirements has been agreed, iterations of the design phase can begin. The next milestone is to therefore build a sound data model (ER-Diagram and normalised schemas) which can be used as the basis for building the database structure and tables. In addition, the integrity constraints and business rules of the HNPCC project have to be established between myself and Nick Wood before the construction of the database can begin. Once the design for the database has been completed, the next milestone is to have the design implemented on the chosen DBMS. The completion of this milestone will mean that the necessary tables are present in the database with the necessary attributes and that the integrity constraints, business rules and referential integrity constraints have been enforced. The next step for completion is to provide a GUI which is able to manipulate the data as set out in the requirements specification. At this point all the implementation should have been completed so the next milestone has been identified as having the system fully tested and ready for an initial release to the client. The project can be considered complete when the users are happy with the system given and show that are the prepared to start using it for their HNPCC research project. Although reaching a milestone represents the completion of a certain task, the iterative nature of the development means that it is likely that what has been achieved to reach a milestone may need be reviewed and changed at a later stage. 12

19 4.2 Project scheduling The principal aim of creating the project schedule is to estimate the times required to achieve the various milestones. In addition a project schedule is used for checking that the project is running on time. The initial project schedule can be found in Appendix C. Creating the database design in this project is tightly coupled to the requirements specification as much of the requirements specification outlines the data requirements for the system. Once the data properties have been established, it is a relatively straightforward process to devise an ER diagram, normalised schema and constraints based on the system requirements. Time spans of days rather than weeks were therefore allocated to these data modelling tasks. For this project designing the GUI is a more complex task as great care and consideration need to be taken to ensure the GUI is as user friendly as possible and aesthetically satisfactory. In addition to this, there is a higher risk involved with developing the GUI. The risks of the user requesting modification and not being content with what is produced are much greater. A longer period of time (four weeks) was therefore reserved for the GUI implementation. For similar reasons to the GUI implementation, the query builder (which is part of the GUI as well) was also given a relatively long period of time as the requirements were broad for this piece of functionality and the design subject to user approval. The initial project schedule did not show the iterative nature of the development of this project that was intended. The reason for this being that it was originally based on the critical path that a project plan should take as identified by O Connell (1996) which was not a suitable approach for this project. This became apparent several weeks into the design phase of the project when it was clear the original requirements were changing frequently. In addition, parts of the implementation phase needed carrying out before the overall design had been completed in order to generate user feedback. The original schedule also gave no indication of the various consultations with Nick Wood. It was therefore necessary to revise the schedule which can be found in Appendix D. 13

20 5 Requirements Gathering This chapter outlines the steps taken and the outcome of the initial meetings with Nick Wood which were held to discuss the minimum and additional requirements for the system. 5.1 Initial discussions with Nick Wood The initial meetings with Nick Wood involved high level discussions about what was required. The purpose of these meetings was to gain a better understanding of the work Nick was involved in, what he wanted and whether what he wanted could be achieved in the time given. Various interview style questions were asked during these initial meetings such as if you want this, would you therefore also want this? in order to establish exactly what Nick Wood required from the system. 5.2 Data storage requirements During the initial meeting, a detailed description of the data required for patients, their medical details and test results was provided. This was simply in the form of a list of fields so some analysis would have to be performed in the database design phase of the project as described in Chapter 7. The first stage in gathering the data storage requirements was to identify in general terms what had to be stored such as tissue samples, maternity history etc. and then look at the details of each of these entities at later stages. Further meetings were held to discuss in detail the nature of the data provided such as whether certain data was mandatory or not and the format that the data for each of the fields should take. This is explained further in Chapter 7. Other details were provided at later stages in the project such as the data required relating to patients not part of the HNPCC study i.e. NE/EC patients. Some information about the data stored was not provided at all and had to be found out during the meetings by asking questions such as You say you want the system to store tissue samples, what information do you want recorded relating to these samples?. 5.3 Storyboarding Once the data storage requirements had been established it was fairly confusing as to how all the data would relate to each other and how a user using the database would typically want to manipulate the data. In order to have better understanding about how the system would interact with the users at St. James s, Nick Wood was asked to describe from start to finish the typical actions a user would take when using the system, the outcome is shown in Figure

21 Enter / Select a patient No First details entered on database? Yes Enter Questionnaire? Yes No First details known? Subsequent details known? Questionnaire results known? Yes Yes Yes Enter first visit details Enter subsequent visit details Enter questionnaire results Patient results known? Yes Questionnaire results complete Record patient results Patient sample details known? Yes Record patient blood and tissue samples Patient details complete Figure 5.1 Flowchart illustrating basic flow of events of user interaction A use-case diagram was first considered for documenting these processes because a use case describes a sequence of actions, performed by a system that yields a result of value to the user 15

22 (Lefingwell (2000)). However, looking at the text description from the meetings with Nick Wood this wouldn t be appropriate because he had given a very specific flow of events indicating that a flow chart would be a better method of documenting user interactions. Although the flow chart depicted in Figure 5.1 does not completely show all the actions that a user may take, it gives a clear view of the typical actions that would occur when a user of the system begins a session with it in order to enter a complete patient profile. Not only did this process provide a much easier format to visualise the system, it was used as the basis for designing the basic menu structure of the GUI. 5.4 Requirements Specification As described in Chapter 2, Section 2.2 a requirements specification is needed so that the requirements of the system are made explicit. It also forms a contract between client and developer. This was produced at an early stage in the project and can be found in Appendix E. The various additions and modifications to this original specification that were requested and implemented during the project can be found in Appendix I. 16

23 6 Hardware and Software decisions 6.1 Hardware The hardware decisions had been made before the project began and weren t open to change. Nick Wood stated clearly that he wanted the software to run on a standalone PC in an office at St. James s Hospital, the specification of which is given in Table 6.1. Processor RAM Free Hard Drive Space Monitor Intel Pentium 900 MHZ 128MB 20GB (approximately) 14 Inch SVGA Table 6.1 PC Specification for system The alternative suggested to Nick Wood was to have the database stored on a server machine on the University of Leeds network which all the PCs within Obstetrics and Gynaecology at St. James s Hospital are connected to. This would allow several users access to the database concurrently. It was made clear however that it was unlikely that a situation would occur whereby more than one person would need to use the database at a given point in time. Furthermore, Nick Wood was not happy with storing patient details on a machine other than in an office at St. James s Hospital. It was pointed out that measures could be taken to ensure the data would be secure but Nick Wood stated he was more concerned with having a database in place on one machine and saw moving to a networked architecture as unnecessary at present and something to be noted as a future enhancement. 6.2 Software Choice of DBMS A DMBS (database management system) is needed to store the physical database and is used to provide access to the data. The roles of a DBMS can be summarised as follows: Controlling Redundancy, restricting unauthorised access, enforcing integrity constraints and providing mechanisms for backup and recovery (Elmasri & Navathe (2000)). All these properties are required to meet the requirements of the HNPCC database. The decision as to what DMBS should be used was also restricted by St. James s Hospital. The only DBMS available on any machine Nick Wood was prepared to use was MS Access The only alternative was to use a DBMS available freely such as MySQL. MS Access 2000 was chosen for a number of reasons. Firstly it meets the DBMS requirements for this project. MySQL does not support 17

24 referential integrity implicitly, all rules most be enforced by the developer whereas they only need be defined in MS Access MS Access 2000 was also chosen because it is designed specifically to run on a Microsoft platform which is the only platform available at St. James s Hospital and provides easy connectivity to Microsoft development tools such as Microsoft Visual Basic Choice of application development software The choice of application software was not as clear. As long the software could be written to connect to the chosen DBMS, MS Access 2000, any development application tool could be used. In addition support for building a GUI and adding functionality behind it is also desirable to meet the data entry requirements of this project. Three development packages identified meeting these requirements and are summarised in Table 6.2. Application Development Software Microsoft VBA (Visual Basic for Access) Microsoft Visual Basic 6 Borland Delphi Advantages Provides an easy and efficient mechanism for working with tables in Microsoft Access. Provides the same functionality as VBA and additional features. Has object oriented features which allow code reuse and encapsulation. Disadvantages Not as extensive in terms of functionality as Visual Basic. Unlike VBA wasn t designed specifically to interact with Microsoft Access. Also more complex than VBA. Too complex for the needs of the HNPCC database system and does not connect as easily to Access 2000 as VBA or Visual Basic does. Table 6.2 Comparison of development software Microsoft VBA was chosen because it provides the best interaction with an MS Access 2000 databases and provides all the necessary functionality for this project. 6.3 Final System Architecture Although the system is to be exclusively developed and used in MS Access 2000, three distinct layers exist within the system architecture. As shown in Figure

25 System Users IBM PC Access 2000 Forms Changing the GUI to reflect user actions Processing the data entered by the user VBA Code Retrieving data that was requested for viewing Formulating and processing the data entered by the user into database commands. Access 2000 Tables Figure 6.1 System Architecture The forms in MS Access 2000 can directly manipulate the database tables directly but due to the need for user friendly error checking and data processing, an additional layer is required. As Figure 6.1 shows, this architecture maps onto the PAD (Presentation, Application and Data) model. 19

26 7 Database Design and Construction This chapter describes the processes taken and the outcome of deriving the necessary data model and physical database required to meet the data storage requirements of the HNPCC database. The chosen DBMS, Microsoft Access 2000 is a relational database system so it follows the database design is based on relational database principals. 7.1 Conceptual Design: High Level Data Modelling Entities The conceptual phase involves building a high level overview of the data. A large proportion of this had been completed from documenting the high level data storage requirements which describe the overall data requirements. However, as the key output of the conceptual phase is a high level entity relationship diagram, the processes used for obtaining this have been shown. Entities represent physical things in the real world (Elmasri & Navathe (2000)). In relation to this project they will correspond to the physical things related to the HNPCC project that need be stored such as tissue samples. Certain key entities were identified from the beginning and remained stable throughout the development of the project, examples are patient, visit, and blood test. Most of the entities were identified at the start of the initial iteration of the database design phase but others such as tissue slides were identified during later iterations. These entities were identified from the data initially provide by Nick Wood using a bottom up approach Relationships Having identified the various entities that will form the basis of the tables in the database, the next stage is to identify the relationships between these entities and the cardinality of these relationships. The cardinality of a relationship shows the number of relationship instances that an entity can participate in (Elmasri & Navathe (2000)). For example, a patient is only registered with one particular GP but a GP can have more than one patient registered with them, thus a 1:M (one to many) relationship between patient and GP is required. The other property of each relationship that must be identified is the participation (optional or mandatory) of entities in each relationship. The reason the relationships must be identified for this project are so that the database is constructed in way that it does not allow inconsistent data to be entered such as entering a patient s visit information for a patient that doesn t exist. The result of this process is an Entity Relationship (ER) diagram and is shown in Figure

27 21 Figure 7.1 High level entity relationship diagram

28 To explain this diagram and how it was derived, some examples are given. Taking the HNPCC patient entity, it had to be determined which entities an HNPCC patient is directly related to. Each patient has one or more subsequent study centre visits, this is depicted in the ER diagram using Rock Evans notation. The participation of relationships is also shown. For example a patient stored on the database does not necessarily have to have had a visit but a visit must have an associated patient. This is depicted by the dashed part of the relationship line originating from the patient and the solid line originating from the visit entity. A visit can only be held at one study centre and a study centre can hold several visits as shown by the one to many relationship between visit and study centres on the ER Diagram Entity Attributes Each entity has one or more attributes. Attributes are properties of the entit ies which define it. A number of meetings were held with Nick Wood in the earlier stages of the project involved finding not only the full list of attributes for each entity but also the data types for each attribute. A full list of the attributes associated with the key entities and their properties is given in Appendix H Integrity Constraints Once the attributes of each entity have been identified, integrity constraints need to be identified to ensure that invalid and inconsistent data can not be entered into the database. As a trivial example, the age of a patient (or indeed any person) must not be below zero, this must be made explicit at the conceptual stage so that it is enforced when physically building the database or at least checked at the GUI level. With each attribute, the first thing to decide is whether or not the attribute must have data entered for it in the database i.e. whether or not it is allowed to take a null value. This had to be discussed with Nick Wood as he hadn t previously provided this information. As an example, the additional comments attribute of a HADS questionnaire could take a null value as not every patient will choose to provide these. However each question in a HADS questionnaire must be answered and cannot therefore be allowed to be stored as a blank field on the database. The integrity constraints together with the acceptance of null values derived from discussions with Nick Wood are documented in Appendix F. Some complex constraints identified could not be enforced by MS Access s table system so they had to be checked and enforced at the GUI level. 22

29 7.2 Logical Design 1: Defining the database schema Once the entities, their attributes and relationships amongst the data have been established, the next phase of the database design is to define the logical database schema Identifying Primary Keys Every relation (a table in the physical database) must have a unique identifier for each record so that a record is not duplicated which leads to redundancy. Primary keys are also needed for referential integrity as described in section A primary key can be made up of one or more attributes and is guaranteed to be unique for each relation. As an example the Patient Study ID together with the visit number uniquely identifies a subsequent study centre visit Foreign Keys and Referential Integrity While integrity constraints ensure that records concerned with one relation are consistent, referential integrity is needed to ensure that the relationships between records related to more than one table are consistent (Elmasri & Navathe (2000)). With regards to the HNPCC project, no serum blood samples can be recorded for a visit unless a blood test has been recorded for that visit. Furthermore a blood sample can only be recorded if a patient has had at least one visit. To ensure this is reflected on the database, referential integrity is required. Foreign keys are needed so that relations can be mapped onto each other meaning referential integrity can be enforced by the DBMS. Foreign keys are copies of the primary key in the related table. Figure 7.2 shows four entities of the HNPCC database, the boldness of attributes signify that they are part of the primary key. In the blood test and serum blood sample tables, the primary key is also a foreign key. Reading from left to right, the Patient Study ID of the patient relation is posted into the Patient Visit entity. With referential integrity enforced no Patient Study ID can exist in the Patient Visit table unless there is a corresponding patient in the Patient relation. In similar fashion there can be no blood test recorded unless it relates to a particular visit. The Storage ID in the Serum blood sample entity represents a foreign key which must also be present as the primary key of the Storage Location entity. 23

30 Patient Patient Visit Blood Test Patient Study ID Patient Study ID Visit Number Patient Study ID Visit Number Storage Location Storage ID Serum Blood Sample Patient Study ID Visit Number Storage ID Figure 7.2, Example of referential integrity in the HNPCC database Referential integrity is enforced by the DBMS once the foreign keys and relationships have been defined, this is discussed further in section Documenting the Initial Schema Once all the foreign keys have been identified, the database schema can be documented. This takes the form of listing the relations together with their attributes and making the primary key for each relation explicit, for example the Serum Blood Sample relation would be defined as: Serum Blood Sample: (Patient Study ID, Visit Number, Label, Date Stored, Number of Aliquots, Location ID) Here Patient Study ID and Visit Number form the primary key of the relation as they uniquely define a record in that no one patient can have more than one serum blood sample taken at any one visit. The combination of Patient Study ID and Visit Number also forms the primary key of the majority of other entities because most entities relate to one patie nt visit. Location ID represents a foreign key in that it is the primary key of the location relation. In order to maintain referential integrity in this instance the Location ID field in the Serum Blood Sample relation must have an equivalent Location ID present in the Location relation. 7.3 Logical Design 2: Normalisation Once the initial database schema had been established the next stage was to normalise it to (or check that it is in) 3 rd Normal Form. This process represents the final stage of the logical design in the database design methodology. Normalisation is needed to avoid redundancy and avoid update and 24

31 insert anomalies (Roberts (2000)). Because users at St. James s Hospital will need to frequently insert and update their records, normalisation is important in relation to this project Functional Dependencies Normalastion is based on the functional dependencies that are identified in each relation (Elmasri & Navathe (2000)). A functional dependency exists if the value of one or more attributes determines the value of another attribute. In the HNPCC database for example, a patient s weight and height will determine their BMI (body mass index). Formally if a functional dependency between X and Y exists i.e. X Y, this implies that if t 1 (X) = t 2 (X) then t 1 (Y) = t 2 (Y) (Roberts (2000)). Continuing with the Serum Blood Sample example, the following functional dependencies can be identified: Patient Study ID, Visit Number Label, Date Stored, Number of Aliquots, Location ID A more complex example is that of the questionnaire schema: Questionnaire: (Patient Study ID, Months after first visit, Questionnaire type, Question number, Question, Answer number, Answer, Additional Comments) 1. Patient Study ID, Months after first visit, Questionnaire type Additional comments 2. Questionnaire type, Question_Number Question 3. Patient Study ID, Months after first visit, Questionnaire type, Question number Answer Number 4. Questionnaire type, Question_Number, Answer number Answer Normalising to 1 st Normal Form A relation is in 1NF if and only if all attributes are single valued (Roberts (2000)). This means that every attribute defined for the HNPCC database had to be checked so that it could not accept more than one value for one attribute in any one record. Not only is this important in terms of normalisation but the chosen DBMS, Microsoft Access 2000 does not accept multiple values for a given attribute. The majority of attributes provided by Nick Wood met this required property but some broke the 1NF rule. For example Current Use of COCP, how long? would take a Yes/No value and a time duration. This required decomposition into a boolean attribute showing whether or not the patient had ever used 25