A Class Normalization Approach to the Design of Object-Oriented Databases

Transcription

1 A Class Normalization Approach to the Design of Object-Oriented Databases Shuguang Hong Dept. of Computer Information Systems Georgia State University Atlanta, GA ABSTRACT In a poorly designed conceptual database schema based on an object-oriented model, redundant information can be found in class definitions. This redundant information is very harmful to the data sharing, data consistency, and data integrity. By examining the relationships among the attributes of a class, we have defined an existence dependency relationship which is similar to the functional dependency relationship in relational database theory. Based on the relationship, we introduce the class normalization concept and three desired class normal forms for the design of object-oriented databases. In this paper, we report our initial finding and show by examples that this concept can help a database designer to identify redundant information in a conceptual database schema and to remove update anomalies caused by this redundancy. 1. INTRODUCTION Methodologies for the design of object-oriented databases ( OODBs ) have been studied since the emergence of this new technology. However, most of these research efforts have been focused on the conceptual aspects of modeling, i.e., how to model an enterprise in terms of its objects, classes, and relationships. Accordingly, tools have been built to help the novice users design a conceptual database schema. But, after the classes are defined, there is no guide to the user to check if the definition of a class is "correct" with respect to the issues of data sharing, data consistency, and data integrity. Inspired by the normalization concept in the design theory of relational databases, we propose a class normalization concept for the design of OODBs in this paper. We believe that the problems addressed by the relation normalization theory such as redundant information and update anomalies [Date 90, Ullman 88, Kent 83] do exist in the design of OODBs as shown later in this paper. In order to study these problems in the design of OODBs, we have extended and generalized the relation normalization concept and suggested a methodology for normalizing classes. Instead of inventing a new theory from scratch, our research can benefit from the previous research results of design theory for relational databases. Our main objective is to provide a practical procedure which can help the novice users detect design problems in class definitions and supply sound suggestions to resolve the problems. After classes in a conceptual schema are defined, the user can follow the proposed rules to check whether the definition of a class contains redundant information which may result in update anomalies. If any problem is found in a class definition, that class can be normalized into desired normal forms. In the rest of the paper, Section 2 briefly reviews the design methodologies and tools for the design of OODBs, and Section 3 suggests two concepts, key identifier and existence dependency. Based on the concepts in Section 3, class normalization theory is proposed in Section 4. Finally, in Section 5 the applications and limitations of our approach are discussed and further research is suggested. 2. RELATED RESEARCH Various design methodologies for information system analysis and design based on an objectoriented approach have been proposed. Wirfs-Brock and Johnson provided a survey of the current research in object-oriented design [Wirfs-Brock 90]. Booch - 1 -

2 [Booch 91] and Rumbaugh and his colleagues [Rumbaugh 91] discussed detailed methodologies for software system analysis and design. They also addressed issues related to database design. However, those methodologies mainly deal with how to identify and construct objects, classes, and relationships which satisfied the application requirements. The issues specific to the database design, such as data sharing, data consistency, and data integrity, have not been addressed. Computer aided tools for the design of OODBs have also been developed. Representative research efforts are OdeView [Agrawal 90], RIDL [Troger 89], SeaWeed [Hong 88, Maryanski 85], SNAP[Byrce 86], SIG [Maier 86], Gambit [Bragger 85], ISIS [Gold 85], LID [Fogg 84], SKI [King 84], and DDEW [Reiner 84]. These systems adopted graphical user interfaces and provided facilities which aid the user in the design of a conceptual database schema. But these tools emphasized the user interface and data modeling issues. They did not provide any guide in determining whether the definition of a class satisfies the database issues mentioned earlier. In contrast, the formal theory for the design of relational databases has been studied intensively since Codd introduced the normal form concept in 1970 [Codd 70, Chamberlin 76]. More than two decades later, many design methodologies have been developed based on the relation normalization theory [Maier 83, Ullman 88, Elmasri 89, Hawryszkiezycz 91]. Numerous applications have shown the effectiveness of the design theory in reducing the redundant information and update anomalies. The class normalization concept proposed in this paper has been strongly influenced by this design theory. 3. NORMALIZATION FOUNDATION 3.1 Classes and Key Identifiers Classes in a conceptual schema of an OODB are the bases from which objects are instantiated. Thus, defining classes correctly is a very critical factor in ensuring data consistency, data sharing, and data integrity. The proposed class normalization concept attempts to help the user to improve the database design quality. A class consists of two components, attributes and methods. Attributes describe the static properties of objects of a class, and methods implement the dynamic properties of objects of that class. Formally, a class C is defined as C = ( A, M ) where A is a set of attribute name and attribute type pairs A = A i A i = < n : t > and i = 1, 2,..., m, and M is a set of methods. More simply, attributes are the facts about objects of a class, and methods are the common behavior of objects of that class. A key identifier K of a class C is a subset of attributes of the class, K(C) C.A Two properties distinguish a key identifier from other attributes of a class: 1. Semantics Sufficiency. It provides enough information about an object of the class such that it can be used to distinguish the object from other objects without the presence of other attributes. 2. Minimality. No proper subset of it can satisfy the property (1) above. In other words, a key identifier is equivalent to the identity of an object with respect to identifying objects, which is similar to the key concept in the relational data model. But, the relational key concept has been introduced basically as tuple identifier. In general, a key attribute alone does not indicate much information about a tuple ( entity ). However, the key identifier concept states that, not only can an object be uniquely identified, but can also its semantics be characterized by its key identifier. Thus, the key identifier concept is the extension of the key concept in relational data model. Figure 1 below defines a class PERSON. The key identifier of the class is composed of the four underlined attributes: SSN, Name, Sex, and birthdate. These four attributes together can uniquely identify a person as well as provide sufficient information about that person. If PERSON was defined as a relation, the primary key of PERSON would be SSN. But SSN alone specifies a little - 2 -

3 meaning about a person. Note that in Figure 1 we have omitted the definition of methods and adopted a C++ like syntax for illustration. We also assumed that the classes, NAME, DATE, ADDRESS and COLOR, have been defined somewhere else. Class PERSON private: char NAME char DATE ADDRESS COLOR COLOR... SSN[11]; Name; Sex; birthdate; Live-at; Hair-color; Eye-color; FIGURE 1: PERSON CLASS DEFINITION How to select a key identifier of a class is dependent on the database designer's knowledge of the enterprise to be modeled. This decision is based on how critical a piece of information this object is. Figure 2 gives another example. The class INSTRUCTOR is a subclass of PERSON. The key identifier of INSTRUCTOR is the combination of the key identifier of PERSON and the underlined attribute of INSTRUCTOR, that is K ( INSTRUCTOR ) = SSN, Name, Sex, birthdate, Dept. Class INSTRUCTOR : PERSON Private: DEPARTMENT Dept; ROOM assignedoffice; Set of PERSON officemates;... FIGURE 2. INSTRUCTOR CLASS In this paper, we assumed single class inheritance. Class COLLOQUIUM Private: PERSON TOPIC Set of PERSON DATE ROOM TIME Integer Integer Update Anomalies Speaker; Subject; Attendants; thedate; theroom; thetime; roomcapacity; numberofattendants; FIGURE 3. COLLOQUIUM CLASS During the design of a conceptual schema of an OODB, we want to check whether the definition of a class contains redundant information. Figure 3 shows the definition of COLLOQUIUM class in which other classes are assumed to be defined somewhere else. The key identifier of the class consists of the underlined attributes. By analyzing the class definition, we find that the attributes, roomcapacity and numberof-attendants, should not be included in the class. We can see several problems existing in this class definition. 1. Redundancy. The room capacity information is repeated in all COLLOQUIUM objects which are scheduled in a same room. Also, the number of attendants should be obtained from the cardinality of the set of attendants. 2. Potential inconsistency. As a consequence of the redundancy in (1) above, the database would contain inconsistent data if the change of the capacity of a room is not propagated to all COLLOQUIUM objects referring to that room. 3. Deletion anomalies. If the room capacity in COLLOQUIUM is the only place in the - 3 -

4 database where this information is recorded, the cancellation of all COLLOQUIUM objects scheduled in a same room unintentionally loses the room capacity information. Following the terminology of relational databases, we call the above problems 2 and 3 as update anomalies. Note that the problems above are the same problems addressed by the relation normalization in the design of an relational database. It has motivated us to study the class normalization concept to reduce redundant information and to remove update anomalies in the design of an OODB. One may argue that the above mentioned problems could be resolved by implementing specific methods to ensure data consistent and to avoid update anomalies. However, this solution may not work unless the redundant information can be identified in the schema design phase. It is the proposed class normalization concept that can help the designer to uncover any redundant information. 3.3 Existence Dependency Existence dependency is a kind of relationship between attributes of a class. Let the class C contains a set of attributes, C.A C.A = A 1, A 2,..., A n and X and Y be subsets of C.A. Y is said to be existentially dependent on X (1) If Y supplies additional fact about X, and (2) If X is removed from C, then Y should also be deleted from C. This existence dependency is denoted as X <== Y. Intuitively, the above definition says that Y adds an additional fact about nothing but X. From the example in Figure 3, we can identify the following existence dependencies. Speaker, Subject, Attendants <== thedate, thetime, theroom Attendants <== numberofattendants theroom <== roomcapacity We can also find the following existence dependency in PERSON class in Figure 1. SSN, Name, Sex, birthdate <== Liveat, Haircolor, Eyecolor In this example, X happens to be the key identifier of PERSON. Note that, existence dependency looks similar to functional dependency of relational database theory [Codd 70, Kent 83, Ullman 88, Date 90]. But existence dependency is a generalized form of functional dependency; functional dependency is a specialized form of existence dependency. For example, the functional dependency SSN, Name, Sex --> ( Haircolor, Eyecolor ) can be mapped to the existence dependency SSN, Name, Sex <== Haircolor, Eyecolor. But, an existence dependency is not necessarily a functional dependency. For instance, the existence dependency Attendants <== numberofattendants has no corresponding functional dependency. It is because functional dependency is based on atomic values, while existence dependency is based on objects. 4. CLASS NORMALIZATION Based on the existence dependency, we propose three desired normal forms for class definitions in a conceptual database schema, following the relation normalization concept of relational database design theory. 4.1 First Normal Form Class normalization should be employed as the last design step after the conceptual modeling process of an enterprise is completed. Thus, a conceptual database schema which is defined based on a qualified object-oriented model should be as the starting point for class normalization. According to the threshold - 4 -

5 model discussed by Zdonik and Maier in [Zdonik 90], we define the first normal form of a class as follows. DEFINITION I. A class is in first normal form ( 1NF ) if it is defined based on an object-oriented model which supports Object identity, Encapsulation, and objects with complex state. We have assumed that the examples given in Figures 1, 2, and 3 above are defined based on such a qualified object-oriented model. Thus the classes, PERSON, INSTRUCTOR, and COLLOQUIUM, are all in first normal form according to this definition. 4.2 Second Normal Form The class COLLOQUIUM in Figure 3 is in 1NF but has update anomalies. The analysis in Section 3 has revealed that the redundant information is caused by that the attributes, numberofattendants and roomcapacity, are not facts about a COLLOQUIUM object, but are the facts about individual components of the object, i.e., Attendants and theroom, respectively. These two attributes are existentially dependent on a partial key identifier of the COLLOQUIUM class, i.e., K(COLLOQUIUM) = Speaker, Subject, Attendants, thedate, thetime, theroom and Attendants <== numberofattendants theroom <== roomcapacity. DEFINITION II. A class is in second normal form ( 2NF ) if every non-key identifier attribute is existentially dependent on the key identifier and not on any proper subset of the key identifier. Intuitively, this definition says that a non-key identifier attribute must be a fact about the key identifier and not a fact about a component of the key identifier. According to this definition, COLLOQUIUM class is not in second normal form. To normalize the class, the attribute numberofattendants should be deleted because this information can be obtained from the set Attendants. Two of possible ways to remove the attribute roomcapacity are as follows. (1) If there is no attribute in the class ROOM to record the room capacity, add the attribute roomcapacity to ROOM class, and then delete the attribute from COLLOQUIUM. (2) If there already exists a similar attribute in the class ROOM, simply eliminate the attribute roomcapacity from COLLOQUIUM. After the above normalization process, COLLOQUIUM is now in 2NF according this definition. Note that the definition of 2NF has included extreme cases in which a class definition includes irrelevant attributes. For example, a novice user may include as attributes of a class some temporary variables required only by the implementation of some methods. Such a mistake may not be a serious problem if it occurs in a program. But such a mistake should not be permitted in the design of a conceptual database schema. 4.3 Third Normal Form Update anomalies can still be found in classes which are in 2NF. Let us analyze the class INSTRUCTOR in Figure 2. The key identifier of INSTRUCTOR is K(INSTRUCTOR) = SSN, Name, Sex, birthdate, Dept The existential dependencies in INSTRUCTOR are SSN, Name, Sex, birthdate, Dept <== assignedoffice assignedoffice <== officemates, SSN, Name, Sex, birthdate, Dept <== officemates. INSTRUCTOR is in 2NF according to Definition II. However, there is a transitive dependency from the key identifier to officemates through assignedoffice. It causes several problems

6 1. Redundant information. The officemates appears in all INSTRUCTOR objects who share a same office. 2. Potential inconsistent. As a consequence of the redundancy in (1) above, update the objects on officemates may cause data inconsistencies. 3. Deletion anomalies. Deletion of instructor objets may unintentionally lose office sharing data if this information is a valuable piece of historical information. After a close examination on the definition of the class INSTRUCTOR, we find that the attribute officemates should actually belong to a relationship among a set of INSTRUCTOR objects. Figure 4 shows a solution to remove the update anomalies by creating a new class OFFICE to model the office sharing relationship and modifying the definition of INSTRUCTOR. This example shows a process by which a class is normalized into classes that are in third normal form. Class OFFICE Private: ROOM Set of PERSON... Class Instructor : Person Private: DEPARTMENT OFFICE... theoffice; officemates; Dept; assignedoffice; FIGURE 4. OFFICE AND INSTRUCTOR CLASSES DEFINITION III. A class is in third normal form ( 3NF ) if it is in 2NF and all non-key identifier attributes are non-transitively dependent on the key identifier. Intuitively, the above definition says that a class should not contain a piece of information which is a fact about a relationship in which that class is one of the participants. 5. CONCLUSION We have introduced the class normalization concept and three class normal forms in this paper. This concept can be applied to the design of an OODB and to determine whether the definition of a class contains any redundant information that may results in update anomalies. The normalization concept is based on the key identifier and existence dependency concepts. Existency dependency is a generalized form of functional dependency of relational data model. We believe that normalized classes can reduce redundant information and remove some update anomalies. Because of lack of a formal and widely accepted theory about object-oriented data modeling and methodology for the design of OODBs, the proposed class normalization procedure could add greatly to database design practice based on object-oriented approach. This normalization procedure is rather straightforward and should be easily accepted by those users who are familiar with the normalization concept of relational database theory. However, this paper represents our initial effort in seeking for a formal design theory for OODBs. A number of theoretical issues have not been addressed. Some of these issues are: A formal theory about existence dependency and its properties, A formal theory about class normal forms, A way of formalizing the class "decomposition" procedure, and A formal proof of the correctness and soundness of the class normalization concept. In addition, answers are needed for the following questions: - 6 -

7 How does class inheritance, in general, affect class normalization? Applications," The Benjamin /Cummings Publishing Company, Inc., How do relationships, in general, affect class normalization? What is the role played by methods of a class in the normalization process? Can class normalization be extended to detect redundant information and update anomalies among classes? What is the relationship between class normalization and relation normalization? These issues suggest fruitful areas of future research. ACKNOWLEDGMENTS The author would like to thank Dr. Ephraim McLean for his review, correction, and commentis of this paper. REFERENCES [Agrawal 90] Agrawal, R., Gehani, N.H., and Srinivasan, J, "OdeView: The Graphical Interface to Ode", Proc. of ACM SIGMOD, May, 1990, pp [Byrce 86] Byrce, D. and Hull, R., "SNAP: A Graphics- Based Schema Manager", Proc. of IEEE Int'l Conf. on Data Engineering, Feb. 1986, pp [Bragger 85] Bragger, R.P., et al. "Gambit: An Interactive Database Design Tool for Data Structures, Integrity Constraints, and Transactions", IEEE Trans. on Software Engineering, Vol. SE-11, No. 7, July 1985, pp [Bancilhon 90] Bancilhon, F. and Kim, W., "Object-Oriented Database Systems: In Transition," SIGMOD Record, Vol. 19, No. 4, Dec [Booch 91] Booch, G., "Object-Oriented Design with [Chamberlin 76] Chamberlin, D.D., "Relational Data-Base Management Systems," ACM Computing Surveys, Vol. 8, No. 1, March 1976, pp [Codd 70] Codd, E.F., "A Relational Model of Data for Large Shared Data Banks,"Communication of ACM, Vol. 13, No. 6, June, 1970, pp [Date 90] Date, C.J., "An Introduction to Database Systems", Volume 1, 5th Edition, Addison- Wesley Publishing Company, [Elmasri 89] Elmasri, R. and Navathe, S.B., "Foundamentals of Database Systems," The Benjamin/Cummings Publishing Company, Inc., [Fogg 84] Fogg, D., "Lessons from `Living in a Database' Graphical Query Interface," Proc. of ACM SIGMOD, June, 1984, pp [Goldman 85] Goldman, K.J. et al., "ISIS: Interface for a Semantic Information System", Proc. of ACM- SIGMOD, May 1985, pp [Hawryszkiewycz 91] Hawryszkiewycz, I.T., "Database Analysis and Design," 2nd Edition, Science Research Associates, Inc., [Hong 88] Hong, S., and Maryanski, F., "Database Design Tool Generation vis Software Reusability," Proc. of IEEE Int. Computer Software & Applications Conf., Oct. 1988, pp [Kent 83] Kent, W., "A Simple Guide to Five Normal Forms in Relational Database Theory," Communications of ACM, Vol. 26, No. 2, Feb. 1983, pp [King 84] King, R. and Melville, "Ski: A Semantics- Knowledgeable Interface," Proc. of VLDB, Aug. 1984, pp

8 [Maryanski 85] Maryanski, F., and Hong, S., "A Tool For Generating Semantic Database Applications," in Proc. of IEEE Int'l Computer Software & Application Conf., Oct. 1985, pp [Maier 83] Maier, D., The Theory of Relational Databases, Computer Science Press, [Maier 86] Maier, D., Nordquist, P. and Grossman, M., "Displaying Database Objects", Proc. of 1st Int'l Conf. on Expert Database Systems, April 1986, pp [Reiner 84] Reiner, D. S., et al, "The Database Design and Evaluation Workbench ( DDEW ) Project at CCA," IEEE Database Engineering, Vol. 7, No. 4, Dec. 1984, pp [Rumbaugh 91] Rumbaugh, J., et al., "Object-Oriented Modeling and Design," Prentice Hall, [Troger 89] Troger, O.D., "RIDL: A Tool for the COmputer Aided Engineering of Large Databases in the Presence of Integrity Constraints," in Proc. of ACM SIGMOD, June, 1989, pp [Ullman 88] Ullman, J.D., "Principles of Database and Knowledge-Base Systems,", Volumes 1 & 2, Computer Science Press, [Wirfs-Brock 90] Wirfs-Brock, R.J. and Johnson, R.E., "Surveying Current Research in Object-Oriented Design," Communication of ACM, Vol. 33, No. 9, Sept. 1990, pp [Zdonik 90] Zdonik, S.B. and Maier, D., "Fundamentals of Object-Oriented Databases", Readings in Object- Oriented Database Systems, edited by S. Zdonik and D. Maier, Morgan Kaufmann Publishers, Inc.,