Object models and Databases. Contents

Transcription

1 : Object models and Databases by Robin Beaumont Contents 2. LEARNING OUTCOMES CHECK LIST FOR THE SESSION INTRODUCTION A STRATEGY FOR SPECIFYING YOUR DATA REQUIREMENTS FOR A DATABASE MODELLING DATABASES Classes and tables, objects and records Associations and relational DBMSs One to many relationships Many to many relationships THE MEANING OF RELATIONSHIPS (SEMANTICS) THE CONSULTATIONS MODEL THE LOG BOOK MODEL THE HOSPITAL MODEL THE DENTISTS MODEL SUMMARY CHECK WHAT YOU HAVE LEARNT REFERENCES ANSWERS TO EXERCISES This handout is part of a course. For details of other material that should be read before this please see Section 7.1 at: Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 2-1

2 2. Learning outcomes check list for the session Each of these seminar sessions aims to provide you with a number of skills (the 'be able to's' below) and appropriate information (the 'know what's' below). These are listed below. After you have completed the session you should come back to these points ticking off those you feel happy with. Learning outcome Understand the relationship between a class and a table Understand the relationship between a object and a record Understand the relationship between an association in a object diagram and a relationship in a relational database (i.e. Access) Indicate in an object model where foreign keys will need adding to allow the creation of relationships in Access Understand how resolution tables relate to object models Be able to translate an object diagram into one or more tables Understand what the term 'semantics' refers to when discussing databases Be aware of the difference between data and knowledge bases Tick box Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 2-2

3 3. Introduction In database concepts 2 we discussed the concept of relationships in a Relational database Management System (RDBMS). Working through the session an attempt was made to work out the various relationships between tables and it became clear that some type of diagram would ease the problem significantly. Since that time we have looked at object modelling. This session brings together the object model diagram and the concept of the 'relationship' as found in a database. It describes the extremely important connection between a method of designing the blueprint for a database (the object model) and the actual implementation of it (the Access exercises). This session, like most of the course, only skims the surface of the topic. You can find out much more about linking Object models to database design in R Rumbaugh et al 1991 and more recently Blaha & Premerlani The Blaha et al book also provides an example in Access as well as a nice complex prescriptions example on p.203. This session begins by describing the link between Object modelling and database design and then moves on to discuss how exactly it is achieved. 4. A strategy for specifying your data requirements for a database The process of designing any computer system can be considered to consist of specifying two important aspects, the what, that is the data (i.e. remember garbage in garbage out), and the how, that is the what it does. Considering the process aspect; a system is worse than useless if it is difficult to use (i.e. for entering or retrieving information), or hinders rather than facilitates working practices (i.e. If a system is planned to be used in the consultation it should be easier rather than more difficult to prescribe and allow the user to collect data in the way they would normally). Whilst the process aspect is as important as the data side of things we will concentrate on the 'what' side of things in this session. Object model = Design blueprint Jargon Specifying When people first start developing databases they always make two fundamental errors. Firstly, they rush to a computer to play with the DBMS, and secondly, they believe they can create a perfect database by specifying a model without creating a prototype of some sort. It is vitally important to get the design right but his involves (Data dictionary) many revisions resulting partly from feedback from using the actual database. For each iteration the object model allows you to create a blueprint (model, specify, design whatever term you want) of the data and the DBMS allows you to create (implement, develop whatever) the actual database. Database Implementing (Access) In the diagram the data dictionary is shown as a half way house between the 'high level' object model(s) and the actual database. Depending upon your inclination it is often not necessary to produce a data dictionary as a detailed description of each object is adequate - it's basically up to you and whoever you may be working with (See Blaha & Premerlani 1998 for more detail). Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 4-3

4 5. Modelling databases We have already discussed object models ('Introduction to object modelling (1)'). In fact databases are simply a collection of objects themselves. More specifically the 'table' idea, which we have considered so far, is simply a way of allowing the computer, via a piece of software called a DBMS, to store attribute and instance details of objects. This all sounds rather abstract so I will now provide some examples. We will first consider classes individually then the associations between them. 5.1 Classes and tables, objects and records Class name Attributes Actions Class: Patient Patient ID First name Surname DOB Sex Address See doctor Database table Table name = Patient: ID First name Surname DOB Etc. Class name becomes table name (not always) Attributes in class model = fields in database The above diagram demonstrates the relationship between a class and a DBMS table structure. The attributes in the class diagram become fields in a table where the table name is the same as the class name. Taking this one step further a object (class instance) is equivalent to a record in a table in the database. Patient objects: (Patient) 214 John Smith 01/01/55 male 23 station st. (Patient) 023 Mary Allan 21/11/65 female 23 pink lane. ID First name Surname DOB Etc Database table Table name = Patient: John Mary Smith Allan 01/01/55 21/11/65 Class Instances (objects) become table records Value in object model = data item in database Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 5-4

5 5.2 Associations and relational DBMSs In 'Introduction to object modelling (1)' we discussed the idea of associations (e.g. one to one and one to many associations). In fact this is pretty much the same as a 'relationship' in a relational DBMS e.g. Access. Relational databases are based upon mathematical set theory. The standard book on the subject is Date C J (6th ed.) An introduction to database systems. The Relational database model was first described by Codd in He subsequently defined a set of rules based upon mathematical principles. His papers are referenced in Date Examples are given below of the relationship between associations in object models and relationships in relational DBMSs One to many relationships Consider the relationship between a doctor and patient. One doctor may have many patients. (forget the situation of a patient having more than one doctor for the moment). This can easy be draw using Rumbaugh s' standard symbols: Doctor Patient 'A doctor has zero or more patients' But how do we turn the above into something that can be represented as one or more tables. In other words something that can be used by a computer. In database concepts 2 the concept of the relationship and foreign key where introduced. A foreign key is a primary key in one table that is embedded in another (or the same) table. In the example given below doctor ID is the foreign key value in the patient object. It allows the implementation in a DBMS of the association shown in the above Rumbaugh class diagram. Dr Leg has two patients, John Smith and Mary Allan Doctor ID. (Doctor) Walter Leg male 01/04/70 (Patient) 023 Mary Allan 21/11/65 female 23 pink lane (Patient) 214 John Smith 01/01/55 male 23 station st Doctors ID in the patient object 'references' the doctor object. Exercise: Re-draw the object instances as records in two tables. If you have problems refer back to the previous section. Doctor Patient The foreign key is in this side of the relationship Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 5-5

6 5.2.2 Many to many relationships Now for the more complex situation. The one to many situation described above is rather restrictive as some patients may have more than one doctor. In other words the above model does not cater for all situations that could occur. The previous, database concepts (2) handout provided details how the many to many relationship situation is resolved by the creation of a separate resolution table. This does not affect the Object diagram as it is not really necessary to shown the table required in the database to solve the problem. However, some people do prefer you to do this and it may help you create the database. Dr Leg has two patients, John Smith and Mary Allan Dr Thomson has one patient, John Smith (Doctor) Walter Leg male 01/04/70 (Patient) 023 Mary Allan 21/11/65 female 23 pink lane. (Doctor) Dave Thomson male 06/04/50 How do we link them? (Patient) 214 John Smith 01/01/55 male 23 station st. A Dr has zero or more patients. A patient belongs to one or more Drs. Doctor 1+ The foreign keys added to a new 'resolution' table Patient Doctor Table: Patient Table: Walter Leg male 01/04/ Dave Thomson male 06/04/ Mary Allan 21/11/65 female 214 John Smith 01/01/55 male 'resolution' table Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 5-6

7 6. The meaning of relationships (semantics) Introduction to Health Informatics People get very excited by attributing a great deal of knowledge and meaning to databases. In the '80s a great deal of research went on in developing 'semantic models'. These were basically modelling techniques which had a wider range of modelling symbols, such as inheritance which we have come across in object oriented modelling. The standard semantics of models are entities (classes), properties (attributes =fields), relationships and subtypes (date p.350). Therefore the meaning, or rather the semantics of the model are these elements nothing more or nothing less. Date 1995 p , provides, for this area of work, an unusually lucid account of semantic modelling i.e. what we have been doing in this chapter with the models. Because no diagrammatic modelling technique can fully explain the complexity required in some databases, narratives are added which frequently take the form of sets of rules or constraints (e.g. if patient female and between years alert doctor to cervical screaming). They usually require programmers to implement, although a lot can be done with filtering out certain records and querying the records in some way. Such databases that contain these rules are frequently referred to as Knowledge bases. Although, nowadays the word is often used for any database regardless of its' complexity. It is possible to derive the models we have been using from a set of narrative statements. Such statements have in the past been called predicates (date p.97) but are now more commonly called 'business rules'. We have been doing this in a very simple way by providing a set of sentences (a narrative) describing the object model in each of the object diagrams in this handout. The 'meaning' of the data is also closely related to the very important idea of 'functional dependency'. Basically the dependency between various pieces of data (for example your can't have a blood result without first having a patient). This is closely related to a process known as normalisation which provides a method to ensure the data is correctly structured in terms of functional dependency which will be considered latter in the course. Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 6-7

8 7. The consultations model This model will be used as the basis for the practical sessions with Access. Mark this page as you will need to constantly refer back to it. Exercise 1: Mark on the relevant objects in the diagram below which foreign keys will need adding to them for the model to work in a referential DBMS. The answer can be found at the end of this handout. A doctor has zero or more patients. A patient can only belong to one doctor. A patient can have zero or more episodes. A episode is related to one patient. A episode has zero or more primary, secondary and other diagnoses associated with it. A diagnosis is only related to one episode. Doctor Patient Episode Other diagnosis Primary diagnosis Secondary diagnosis Notice this is what you were trying to describe in the exercise at the end of section 2.7 Database concepts (2). Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 7-8

9 8. The Log Book Model Exercise 2: Consider what information you would need to keep if you where to develop an electronic log book to allow you to analyse: Type of patients seen Type of procedures you were involved in Level of competence for each procedure Success of the interventions you were involved with Any other areas you might consider to be important 9. The Hospital Model Examples of other modes are given below. 1. The hospital conceptual model part A. A operating theatre has zero or more sessions allocated to it which are either routine or emergency. A theatre has one or more nurses allocated to it. Operating Theatre +1 Nurse Emergency session Routine session Adapted from OU M866 book 1 p52 Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 9-9

10 2. The hospital conceptual model part B (adapted from Open University M866 book 1 p52) A team of doctors provide treatment. A team is specific to one specialty. The team only has one consultant. A team has one or more junior doctors. Note: this diagram will be developed substantially through the course. Assumption: A doctor may provide zero treatments Team +1 Junior Dr Consultant Treatment Adapted from OU M866 book 1 p52 3. The hospital conceptual model part C (adapted from OU M866 book 1 p52) A ward has zero or more patients. Each ward has zero or more nurses. Each nurse and patient is allocated to only one ward. A patient has zero or more treatments. Each treatment is unique to a particular patient. A treatment may consist of zero or more prescriptions. A prescription is unique to a treatment A prescription has one or more drugs. A drug is related to one or more prescriptions. Adapted from OU M866 book 1 p52 Ward Treatment Patient Nurse Prescription Drug Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 9-10

11 Exercise 3: For the three models above indicate in which class (entity) the foreign keys will need to be added for implementation in a relational DBMS. 10. The Dentists Model Exercise 4: Draw the object model which is implied from the information given below. The answer is given at the end of this handout.. A dental practice has one or more dentists and zero or more dental nurses. Each dentist has zero or more clients. Each client receives zero or more treatment sessions. Each session has a cost associated with it. 11. Summary In this session we have investigated the idea of mapping 'relationships' from object models onto a DBMS On a more theoretical level we have discussed the 'semantics' of such models. 12. Check what you have learnt Now go back to the beginning of the material for the session and read the 'Learning outcomes check list' for the session. How many can you tick? If you are not sure about any particular ones read again through the relevant material if that fails please contact me. 13. References Blaha M Premerlani W 1998 Object-oriented Modeling and design for Database applications: Includes UML. Prentice Hall [web site: Date C J (6th ed.) An introduction to database systems Reingruber Michael C. Gregory William W 1994 The Data Modeling Handbook John Wiley & Sons Chichester Rumbaugh J Blaha M Premerlani W Eddy F Lorensen W 1991 Object Oriented Modeling and Design. Prentice Hall International. Open University 1993 Relational Database Systems M866 (Five books; Introduction to database technology, The Relational Modal, Normalisation, Using SQL, SQL database management) [These are excellent resources with many exercises and clear concise explanations]. Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 13-11

12 14. Answers to exercises Exercise 1: Mark on the relevant objects in the diagram below (consultations model) which foreign keys will need adding to them for the model to work in a referential DBMS. Answer: In patient object, Dr ID. In Episode object Dr ID and Patient ID. In each of the diagnosis tables episode ID. Exercise 4: Draw the object model which is implied from the information given below. A dental practice has one or more dentists and zero or more dental nurses. Each dentist has zero or more clients. Each client receives zero or more treatment sessions. Each session has a cost associated with it. A dental practice has one or more dentists and zero or more dental nurses. Each dentist has zero or more clients. Each client receives zero or more treatment sessions. Each session has a cost associated with it. Dental practice client dentist +1 Nurse Treatment session cost Document Info: Robin Beaumont Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Date: 28/03/00 Robin Beaumont 28/03/00 Tel: robin@robinbt2.free-online.co.uk Source: Laptop; C:\HIcourseweb new\chap7\s4\dbcon3.doc Page 14-12