GOOD TOP-DOWN DESIGN METHODOLOGIES TEND TO PRODUCE FULLY NORMALISED DESIGNS ANYWAY.

Transcription

1 GOOD TOP-DOWN DESIGN METHODOLOGIES TEND TO PRODUCE FULLY NORMALISED DESIGNS ANYWAY. Dr Bernadette Byrne School of Computing & I.T. University of Wolverhampton.UK ABSTRACT Many database curricula both in University and in As and A2 examining boards teach normalisation by decomposition as a method of arriving at a suitable set of tables for implementation in a relational database. This paper advocates that we need to move on from this position and move towards teaching database design by developing a high level data model (for example using the Extended Entity Model or UML design) and then mapping the model to a set of tables suitable for implementation in a relational, object/relational or object oriented database). The author believes that this is a much more straightforward method for students than struggling with normalisation by decomposition which can easily become torturous with anything but the most straightforward example. The top-down approach to database design also accommodates mapping to databases based on new technologies whereas normalisation by decomposition is primarily for relational databases. Keywords Entity Diagram, Normalisation, Fourth Normal Form, CASE tools.. 1. INTRODUCTION A top down approach to database design has developed using an entity relationship (ER) model. The ER model was originally put forward by Chen [1] and subsequently extensions have been added to add further semantics to the original model. The general mapping rules for mapping an extended entity relationship model (EER) to a relational representation was presented by Teorey et al [2] and subsequently by Elmasri & Navathe [3]. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission. Teaching, Learning and Assessment in Databases, Coventry LTSN Centre for Information and Computer Sciences The ER and EER models are also used to aid communication between the designer and the user at the requirements analysis stage. Although at the end of the design process all the data elements have to be considered with the ER model, and added to the model, the top down approach starts at a higher level of abstraction with the main items of significance and then gradually adds more detail. Past work has involved comparing the usability of the ER model with the relational model [4] and work has been ongoing to investigate the usability and quality of ER and EER models [5], [6], [7], [8], [9], [10]. At the University of Wolverhampton Normalisation by decomposition is taught in year one and year two courses. Manual normalisation with anything but simple or well-tried examples can be very difficult the difficulty usually caused by several repeating groups or nested repeating groups at first normal form. Normalisation is a bottom-up approach all the detail (functional dependencies) have to be considered at the beginning. This is obviously timeconsuming as well as being fraught with difficulty. In the year three module called Database Design we take a top-down approach. In the first half of the module we use Entity- diagrams and the second part of the module we use Object Role Modelling (ORM) and the Visiomodeler tool. A further paper has dealt with the teaching of ORM at the university [11]. As regards the top-down approach using entity-relationship diagrams we start with a conceptual model - an Entity (ER) diagram. We also use an extended or enhanced entity relationship model (EER) which also allows the use of supertypes entities and subtypes entities. (However, as regards this paper the term entity-relationship (ER) will be used to refer to any variation on the original ER model.) When we are satisfied that the ER diagram is correct (usually after several iterations) the diagram is mapped using a straight-forward algorithm to a set of tables which in this author s opinion will arrive in at least fourth normal form. To check for fifth normal form involves one further check on any tables which were the result of an nary relationship on the ER diagram. For those readers not familiar with the 13

2 mapping algorithm this is summarized in Appendix 1. Using this method designers can produce tables in fourth normal form without needing to consider normalization. A knowledge of normalization is useful to check that the tables are in the required normal form however the designer need not concern herself with the process of normalization and, in this author s opinion, if the model is correct the resulting tables will be in at least fourth normal form anyway. The top-down approach works very well if the final ER diagram is acceptable/correct. Therefore students need to have a lot of experience in drawing ER diagrams. They also need to be aware of problems which can occur in ER diagrams; for example connection traps in the form of fan traps and chasm traps, connection traps caused because of the incorrect mapping of nary relationships and problems in the use of transitive relationships. A previous paper has produced a set of heuristics for novice database designers to follow in order to avoid some of the above problems [12]. Although Normalisation is acknowledged as having a good theoretical foundation it is not a complete theory and does have some problems apart from being difficult to use in practice. In the next two sections the author points out two problems with normalisation which can be over-come with a topdown approach and in the final section gives other reasons why the top-down approach is preferred. 2. NORMALISATION FUNCTIONAL DEPENDENCIES Normalisation by decomposition is a difficult and time-consuming process. Although the deduction of some functional dependencies from others can be automised the designer still needs to start with a correct initial set of functional dependencies. However normalisation itself does have some theoretical problems. If we map Figure 1 to tables using the mapping algorithm (appendix 1) we get: Section (Section_no, section_name) Office (Office_no, max_occup, section_no*) Teacher (emp_no, name, office_no*) Section Office Teacher Figure 1 However, if the situation changes and now some teachers, for example part-time teachers, are not allocated to an office we cannot use the acceptable diagram of figure 1 as we will not have a path through the entities because the link has been broken. For teachers without an office we cannot trace their link from office to section. To account for this on the diagram we have to add an extra one-to-many link between section and teacher as in Figure 2. Section Office 2.1 Null values in dependencies Normalisation does not consider optionality among dependencies. Let us consider the following example: A section has many offices and employs many teachers. Teachers are allocated to offices. Each teacher has one office and will share that office with other colleagues. Each teacher only belongs to one section and there are many sections within the university. Each office only accommodates teachers from the same section. An acceptable solution to the exercise is the diagram below, figure 1. This diagram is drawn representing the natural hierarchy in the description given. A section has many offices and an office has many teachers. Teacher Figure 2: Optionality In this diagram we now have an extra optional relationship between office and teacher. The ER diagram deals with optionality, above in Figure 2, by introducing an extra relationship which can be mapped to a set of tables as follows: Section(section_no, section_name) Office(office_no, section_no*) Teacher(Emp_no, teacher_name, office_no [op], section_no*) [op] = optional field 14

3 These tables are acceptable as long as the user knows not to make the nonsense join of joining section_no in the teacher table to section_no in the office table as this gives spurious rows. However, the teacher table is not in third normal form because there is a dependency between office_no and section_no. The office_no functionally determines the section_no (but only for those teachers who have an office). The problem in this case is that there is a transitive functional dependency between teacher number and section number, which becomes problematical when the teacher office link is optional. However, that fact that some teachers do not have an office does not affect the functional dependencies and we would still arrive at the set of tables as produced from figure 1 which would mean that in some cases we could not find out which section teachers belonged to. Therefore the topdown produces a table that is in second normal form but it is preferable to the third normal form table as it ensures that we have a path from teacher to their section essential for teachers who do not have an office. In the previous paragraph it was stated that normalisation does not deal with optionality among dependencies. The fact that some teachers may not have an office is not a consideration when we ask ourselves if the teacher number functionally determines the office number. The answer is yes. The teacher number functionally determines the office number (for those teachers that have an office). This becomes a problem if the office number goes on to determine something else - in this case the office number functionally determines the section number. There is a transitive functional dependency between teacher number and section number. 2.2 Subtypes The top-down approach can also deal with the above by using subtypes. The teachers without offices problem could be dealt with as a subtype on an ER model. If it is a question of part-time teachers not having an office (rather than some other arbitrary decision as to who has an office and who has not) then we have a natural subtype within our teacher entity. An enhanced entity-relationship diagram can be used to illustrate subtypes. Figure 3 illustrates the subtypes on an enhanced entityrelationship diagram. In figure 3 the diagram shows clearly that it is only the full-time teachers who have a relationship with the entity office. Interestingly, when mapped to tables using option A for the mapping of subtypes, we arrive at a set of tables that are in third normal form. The theory of normalization does not deal with null values. This is also supported by Halpin [13] and Codd in [14] states that nulls should be ignored when applying rules about Functional Dependencies. consequences. Part-Time Teacher Full Time However, this can have dire Office Teacher (Emp_no, name, section_no*) Fulltime (Emp_no, office_no*) Part-time (Emp_no, no_of_hours) Section (Section_no, section_name Figure 3: Subtypes and Resulting Tables Section 3. FOURTH NORMAL FORM Fourth Normal Form is concerned with multivalued dependencies or separate independent repeating groups. If we take the following table (Subject, Book, Lecturer) which has been arrived at by flattening out information on a subject guide where a subject has many different recommended texts and also has many different lecturers. Every occurrence of Lecturer has to be combined with every book for the subject even though the lecturers and books are separate independent repeating groups for the subject the lecturers have no link with the books recommended and vice versa. The theory of fourth normal form was put forward [15] to get over this problem which can occur if you rigidly follow First Normal Form and carry out a fill in the blanks exercise. (Some normalization by decomposition processes recommend separating out independent repeating groups at First Normal Form which would eliminate the problem anyway.) If you were to take a top-down approach to this problem anyone but a novice designer would recognize that we have three entities, Subject, Lecturer, Book and that there is a many to many relationship between Subject and Lecturer and a many to many relationship between Module and Book. Therefore for most designers fourth normal form will not be an issue with a top-down approach. Normalisation provides a good theoretical basis for database design but it does have some limitations as well as being difficult to use in practice. A topdown approach can deal with the null value problem 15

4 by using subtypes, and the top down approach all but eliminates the fourth normal form problem. 4. CASE TOOLS IN DATABASE DESIGN Model Driven Development CASE Tools are now widely available for drawing ER diagrams which can then be automatically mapped to target databases. The Select SSADM CASE tool allows you to draw an ER diagram (including subtypes) which can be mapped to data definition language (create table statements). The Oracle Designer 2000 tool will also map an ER diagram drawn with the tool to target databases and create the tables. The rules used to map to tables will be the same rules outlined in appendix one. However, the problem with tools of this nature is that the model needs to be correct before mapping to tables, otherwise unsuitable tables are produced. It would be useful if tools could offer some checking of the model before mapping to tables. Work has taken place by Bowers [16] to check transitive relationships on ER diagrams drawn with a model driven development tool. The use of these tools may be the way forward for database design. 5. OBJECT RELATIONAL (OR) DATABASES Object Relational Databases appear to be maturing. Additions have been made to the SQL standard to accommodate some new OR features and the Oracle DBMS has also added some facilities which are object/relational. If the popularity of OR databases increases it may mean that normalization is no longer a suitable tool for database design (at least for object relational databases). The use of Enhanced ER diagrams with the ability to show supertypes and subtypes mean that the models can be easily mapped to object relational databases which can support subtype structures and the mapping algorithm already allows for this. 6. CONCLUSION It has been suggested that good top down methodologies for database design will tend to produce fully normalised designs [17p 336]. From an educational point of view the teaching of normalisation theory in centres of higher education is becoming less valid as the current database management systems are moving on from the limited record based systems of relational models to include more object-relational and advanced features. Also, model-driven development tools, for example Oracle Designer 2000 and Microsoft Visiomodeler, will map conceptual models to target databases. ER diagrams are at a higher level of abstraction and deal with things and their properties. They are a good communication aide between the user and the designer and when complete can be easily mapped to tables for use in a relational database, and, the mapping algorithm can be easily altered to map to an object/relational database. With the continued rise in end-user computing and the rise in model-driven development tools it will be useful to develop tools which help the inexperienced designer to produce the best possible model which could then be automatically or manually mapped to a relational or object-relational representation. 7. REFERENCES [1] Chen P The Entity Model towards a unified view of data. ACM transactions on Databases Systems, vol 1, no March 1976 [2] Teorey T, Yang D and Fry J A Logical Design Methodology for Relational Databases using the Extended Entity- Model. Computing Surveys, Vol 16 No 2, June 1996 [3] Elmasri R, Navathe S, Fundamentals of Database Systems Third Edition Addison- Wesley [4] Batra D, Hoffer J, Bostrom R, Comparing Representations with Relational and EER Models. In Communications of the ACM Feb 1990 vol 33 Number 2 [5] Batra D, Davis J Conceptual data modeling in database design. Int. J. Man-Machine Studies (1992) 37, Academic Press Limited. [6] Moody D, Shanks G. What makes a Good Data Model? Evaluating the Quality of Entity Models. Proceedings 13 th International Conference on ER Approach 1994 Manchester Springer-Verlag. [7] Kesh S Evaluating the quality of entity relationship models. Information and Software Technology (12) [8] Saiedian, H. An evaluation of extended entityrelationship model. Information and Software Technology 39 (1997) [9] Jones T, Song I Y Analysis of binary/ternary cardinality combinations in ER modeling. Data and Knowledge Engineering 19 (1996) [10] Siau K, Wand Y, Benbasat I. The Relative Importance of Structural Constraints and Surface Semantics in Information Modeling. Information Systems Vol. 22 No. 2/3 pp Elsevier Science Ltd. [11] Byrne B, Garvey M, Jackson M. Experiences of Using Object Role Modelling to Teach Database Design. LTSN Workshop on Teaching, Learning and Assessment in Databases. July 2003 Coventry University. 16

5 [12] Byrne B. A set of Heuristics for locating connection traps and transitive relationships on Entity Models. In proceedings of Information Systems Modelling (ISM) Czech Republic April 2002 [13] Terry Halpin Information Modelling and Relational Databases - From Conceptual Analysis to Logical Design Page 633 [14] Codd, E F The Relational Model for Database Management Version 2, Addison-Wesley 1990 [15] Fagin R. Multivalued Dependencies and a New Normal Form for Relational Databases. ACM TODS 2, No 3 September 1977 [16] Bowers D. Detection of Redundant Arcs in Entity Conceptual Models. In proceedings of the International Workshop on Conceptual Modeling Quality. pp ER 2002 Finland [17] Date C J An Introduction to Database Systems Addison-Wesley Sixth Edition page

6 Step 1 Entity Step 2 Entity Step 3 - Step 4 Step 5 Step 6 Multivalued Attribute Step 7 Appendix A Entity to Relational Algorithm Each normal entity type on the diagram is mapped to a table. The table will include all the simple attributes of the entity marked on the diagram. For a composite attribute the simple components are used as attributes. One key of the entity type is chosen as the primary key. If the key is composite, then the set of simple attributes that form it will together become the primary key. Each weak entity type is mapped to a table which includes all the simple attributes of the weak entity. The primary key is a partial key from the weak entity combined with the primary key of the owner. For each binary 1:1 relationship identify the two tables taking part in the relationship and choose one of the tables, say A and include as a foreign key in A the primary key from the other table, say B. It is better to choose the table with total participation to play the A role. Any attributes of the 1:1 are included as attributes of A. For each normal (non-weak) binary 1:m relationship between two relations X and Y, identify the many side of the relationship, e.g., Y and include as a foreign key in Y the primary key of X, which refers to the relation at the one side of the relationship. Include any simple attributes of the 1:N relationship as attributes of Y. For each binary M:N relationship create a new relation to represent the relationship. The primary key is a combination of the keys of the participating relations. Any attributes of the relationship are included in the new relation. For each multi-valued attribute create a new table R which includes the key of the owner relation. The primary key of R will be the combination of the owner primary key plus the attribute. If the multivalued attribute is composite include its simple components. For each N-ary relationship where N>2, create a new relation S. Included in S as foreign keys are the primary keys of the relations taking part in the relationship. Also include any simple attributes of the N- ary relationship. Option A Specialisation and Generalisation Create a relation for the superclass and its attributes. Create relations for each of the subclasses. The subclass relations will contain the specific attributes of the subclass plus the primary key of the superclass. A join between the superclass and subclass tables over the primary key will produce all the specific and inherited attributes of the entity. Option B Create one relation with all the attributes of the superclass and subclasses. An entity that does not belong to some of the subcla sses will have null values for the specific attributes of these subclasses. (Summarised from Elmasri [3]) 18