Mapping an Extended Entity-Relationship Schema into a Schema of Complex Objects

Transcription

1 Mapping an Extended Entity-Relationship Schema into a Schema of Complex Objects Rokia Missaoui 1 Jean-Marc Gagnon and Robert Godin Departement d'informatique, Universite du Quebec a Montreal C.P. 8888, Succursale \Centre-Ville", Montreal, Canada, H3C 3P8 Abstract. With the advent of object-oriented database systems, there is an urgent need to dene a methodology for mapping a conceptual schema into an object-oriented one, and migrating from a conventional database to an object-oriented database containing complex objects. This paper deals with an important step of the migration process by describing a technique for complex entity formation which involves recursively grouping entities and relationships from an extended entityrelationship schema, using semantic abstractions such as aggregation, generalization and association. The abstract schema produced by the clustering technique at a given level of grouping can then be converted into a structurally object-oriented schema allowing the explicit expression of complex entity types, relationships and integrity constraints. The overall methodology is implemented within the environment of INTER- SEM, a prototype for semantic object-oriented modelling. 1 Introduction Most of present database (DB) applications are based on traditional (conventional) database management systems (DBMS). With the advent of objectoriented (OO) systems in the market and the increasing popularity and utilization of the entity-relationship model [5], the following related questions need to be addressed: (i) how to map an extended entity-relationship (EER) schema into a corresponding object-oriented schema? (ii) how to re-engineer the old conventional applications to produce object-oriented databases instead of designing them from scratch? The second question (which includes the rst one) can be answered by dealing with the three consecutive steps [2]: (i) backward step: map the existing logical (i.e., relational, hierarchical, or network) schema of the database into a semantic (conceptual) one, (ii) forward step: map the resulting semantic schema into an OO schema, (iii) loading step: migrate the existing data to the new schema. Since the entity-relationship model is a very commonly used and continuously improved semantic model, the rst step of this process can be undertaken by mapping a conventional logical schema to a corresponding EER diagram. Such a mapping has been extensively studied and handled by many researchers [11, 13]. Our main concern in this paper is to deal with a part of the issue of reengineering database applications. More specically, our objective is to deal with

2 the second step of the whole process of re-engineering by providing a methodology for converting an extended entity-relationship into a structurally OO schema. This methodology is mainly based on the observation that (i) in many database modelling applications, several types of entities are related to each other, and (ii) such a set of related components should be perceived and described as a unit. An important step of this methodology is inspired by the clustering technique proposed by Teorey et al. [17]. The article is organized as follows. First, we show how the clustering technique described in [17] can be adapted to convert an EER schema into a schema of complex objects. Rules for mapping complex object types into a semantic object-oriented schema are also described. We provide a practical example to illustrate the application of the clustering technique. We assume the reader is familiar with the key notions of object-oriented models and semantic modelling [1, 2, 4, 6, 9]. 2 Complex Entity Type Formation In many real-world applications, designers tend to constitute classes of objects such as concepts, chunks and clusters according to some similarity criteria. The clustering technique proposed by [17] is basically suggested to be an aid in user communication and documentation. It consists in recursively grouping entities and relationships from an extended entity-relationship schema, using semantic abstractions such as aggregation, generalization and association. In this paper, we shall show that some variations of this clustering technique can be useful not only to improve the understanding of the DB conceptual schema and master its complexity, but also to contribute to the formation of complex entities, and therefore could be used as an important step in the mapping process of an initial EER diagram into an object-oriented schema. 2.1 The clustering Technique The procedure [17] is performed iteratively in a bottom-up manner by starting from atomic entities in an EER and building more complex entities (entity clusters) out of them until the desired level of abstraction n is reached or until no more clustering operation can be applied. The level n of clustering represents the desirable depth of aggregation hierarchies in the resulting complex object schema. It can be set based on the peculiarities of the application under consideration. To ensure a high semantic cohesion within complex entities, the grouping operations are done in a precedence (priority) order. This order is dened in terms of the concept of cohesion, to represent the strength of the relationship among entities in an entity cluster. The weakest cohesion appears in the last grouping (see below) since there is no dominant entity in ternary and higherdegree relationships.

3 2.2 Grouping operations and Priority Order The four grouping operations and their priority order are slightly dierent from the ones proposed in [17]. The priority order applies as follows: when a given entity E is both involved in a relationship of priority order k and a relationship of priority order k + 1, then the grouping of order k is chosen. When a given entity E is candidate to two groupings of a same priority (except for weak entity absorption), then we decide which one to use based on additional rules dened later. 1. Weak entity absorption A strong entity E is collapsed with all its direct dependent entities to form a single complex entity whose label corresponds to the name of the strong entity. The weak relationships as well as any one-to-many relationship and its corresponding related (member) entity associated with E are also absorbed in the complex entity. In the presence of a sequence of weak entities and relationships, the grouping starts with the most dependent entity and assembles entities in cascade (see below) as illustrated by the example in Section Dominance Grouping We dene a dominant entity as the one which is in a binary association with at least two entities by a one-to-many relationship. Dominance grouping consists in assembling a dominant entity with its related entities and relationships. The name of the clustered entity is identical to the name of the dominant entity. 3. Generalization and Categorization Grouping The generalization/categorization grouping consists in creating a complex entity whose name is identical to the name of the supertype/category 1 and whose components are the immediate subtypes/supertypes of the generalized entity or category. A category is dened as a subset of the union of some classes [6]. 4. Relationship Grouping The n-ary relationships of any degree can be grouped into an entity cluster, reecting the semantics of the relationship as a whole. As opposed to [17], the name of the entity cluster is not necessarily identical to the name of the relationship. It corresponds to the name of the relationship especially when the association is either a many-to-many binary relationship or n-ary relationship. In the mapping process (see Section 4 for more details), the translation of an entity cluster obtained by relationship clustering takes into account the nature of the entities in relationship: key entities, mandatory/optional participation, and the number of other associations in which an entity is involved in. 1 when there exists only one specialization/categorization of the generalized/category entity

4 2.3 Additional Rules In order to preserve the logical and natural sequence of viewing a database at dierent levels of abstraction, to maintain the whole semantics of data, and handle some conicting situations, we use the following four rules which will be illustrated with an example in Section 2.4. The rst two rules are borrowed from [17]. Step-by-step grouping { Whenever a new grouping is to be done on a schema C i (schema with a clustering level i), the output is a schema C i+1 as long as at least one grouping operation is achieved on C i. The initial schema is assigned level 0. { If the n-th clustering operation within level i is achieved around the entity E, then it leads to an entity cluster with a label, and a level expressed by < i:n >. The label of the complex entity depends on the kind of clustering: it is the name of the dominant (or strong, or generalized or category, or owner) entity, or the name of the relationship if it is a many-to-many binary relationship or a ternary relationship. { A grouping operation cannot be achieved at level i if it involves a complex entity recently formed at that same level, and therefore has to be postponed to the next level. Consistency To avoid the possibility of losing the semantics associated with data, and in order to preserve the initial relationships between entities inside and outside a complex entity, we do the following. Whenever a component (or subcomponent) E i of a complex entity E j is in a relationship (IS-A, or association) with another entity, the appropriate side of this relationship will be labeled by E j?1:... :E i representing the path needed to reach the component E i inside E j (see Figure 2). Cascading If an entity E i is both a candidate to a clustering operation of any kind (weak entity absorption, dominance, generalization/categorization, or relationship grouping) as a slave entity (i.e. a component of a potential complex entity E), and a candidate to another clustering operation as a master entity (i.e. an entity whose name is identical to the name of a potential cluster such as dominant/strong entities, generalized entities, and one-side entities in a one-to-many relationship), then the inner clustering operation (i.e. the one involving E i as a master) is applied before the outer grouping (i.e the one involving E i as a slave). As a special case, in the presence of a sequence of weak entities with their corresponding relationships, the absorption grouping starts from the most dependent entity and relationship, and then iteratively forms a complex entity until the strong entity is encountered. Visibility/Unvisibility of Entities In any information system, there are some entities that are relevant to many

5 procedures and needs of users. We think that these key entities have to be quite visible at any level of abstraction of the initial schema, and not hidden inside a complex entity. Therefore, any grouping that encapsulates a key entity has to be prohibited. 2.4 An Illustrative Example Let the EER schema of the database be the one illustrated by Figure 1 indicating that an employee has dependents who are either adult or non-adult, he/she works for a department, and is involved in one or many projects. Each department controls projects. Dependents benet from social services, may have a driver's license (if they are adult) and toys (when they are non-adult). Assume also that Employee and Department are key entities. Therefore, any grouping in which these entities have to be components of a complex entity is prohibited. Figure 1 shows a chain of weaks entities Dependent and Soc service. At the clustering level 1, the weak entities Soc service, Toy and Project are absorbed by Dependent, Non adult and Department respectively. For the entity Driver which is a union/category of Employee and Adult dependent, there are two candidate groupings: one by categorization, and the other as by 1 : 1 binary relationship grouping. Even though the former has priority over the latter, it is in conict with the visibility principle. Then, Driver is assembled with License. At the next level, the new complex entity Dependent is candidate to three kinds of grouping: weak entity absorption by Employee, generalization grouping where Dependent acts as a slave entity, and generalization grouping where Dependent is a master entity. Then, using the cascade rule, the clustering by generalization in which Dependent is a master entity is performed at the level 2 to hide the specialized entities Adult and Non adult. We cannot undertake an additional grouping operation at level 2 because each potential grouping involves either the complex entity Dependent recently clustered at that level, or a key entity. At level 3, Employee absorbs its weak entity Dependent. To maintain the semantic consistency of the schema, relationships (association, ISA, and union) that involve a component of a complex entity must exhibit the path needed to reach that component. For example, Figure 2 indicates that the relationship involved in connects the entity Employee to the entity Project which is a component of the complex entity Department. Our clustering approach is based on [17]. However, it diverges from Teorey's paper in the following way: { It aims mainly at complex object formation even though it can be a useful technique for documentation and abstraction. { Additional rules and renements are proposed to handle multiple choices, and preserve the logical sequence of DB schema abstract views. { Once the appropriate grouping is retained by the user, there is an additional step aimed at converting the clustered EER into an object-oriented schema.

6 Fig. 1. A two-level clustering Fig. 2. Complex entities for a three-level clustering

7 3 Mapping a Clustered EER Schema into an Object-oriented Schema Up to now, we are able to derive a schema of complex entities out of an EER schema. An interesting issue is to map the clustered EER schema obtained from the grouping procedure into an object-oriented schema. Elmasri and Navathe [6] mention that one of the drawbacks and limitations of the OO approach is that the relationships commonly expressed in semantic models are not directly supported. Instead of being visible, the relationships are expressed indirectly by means of interobject references. In our approach, the stage of mapping the clustered EER schema into an object-oriented not only handles complex object description but also takes into account the relationships and semantic constraints. For space limitation, we do not elaborate on integrity contraints and external relationships attachments. The interested reader is referred to [8, 12]. Denition 1. We dene a structurally object-oriented database scheme to be a couple (S; ) consisting of a collection of entity types E 1 ;... ; E m closed under references and supertypes, and a set of inter-entity integrity constraints. An entity type E i can be described by the following properties: { Supertypes: set of supertypes of E i, { Structure: aggregation of (atomic or complex) attributes A j belonging to either built-in or user-dened types, { Relationships: set of associations in which E i participates, { Specializations: set of specializations < Sub; CD; Inherit > where E i is the generalized entity, { Category: description of the supertypes that participate to the union (if applicable), and { Constraints: set of intra-entity constraints. Generalized entities are dened by the triplet < Sub; CD; Inherit >, where:? Sub represents the entities that specialize the supertype,? CD is a couple of two boolean values indicating whether the generalization is complete or not, and whether the instances of the subtypes overlap or not (see [2, 6]).? Inherit indicates how the subtypes are formed [1] (e.g. user-dened or predicatebased specialization). Since a same entity can be a generalization for more than one specialization criterion, there are as many triplets as there are kinds of specialization for that entity. The extension of E i is the set of objects O i1 ;... ; O ip whose type is E i. A database extension D of a schema S is a set of all the instances of the entities in S which verify the whole set of intra and inter-entity integrity constraints.

8 3.1 Transformation Rules Once the diagram for complex objects is produced, the OO schema description can then be produced. There are at least two kinds of mapping of an ER diagram into an OO schema [16]: the rst type, called stable translation, consists in converting each entity and each relationship into an object as in [14] while the second one, called mapped translation, consists in integrating a relationship into an object class using references, and creating an object class for each ternary relationship [10]. We dene an entity E j in the initial (i.e, non clustered) schema as a potential candidate to absorption by another entity E i when one of the following cases occurs: { E j is in only one 1:1 or one 1:N relationship or only one ternary relationship involving E i, and E j has no other associations in the schema under consideration. { E j is a weak entity with respect to E i and participates only to weak relationships (if any) as a strong entity. { Each specialized entity E j of E i does not have specic properties by its own and does not participate to any relationship. The translation process we adopt is a little bit similar to the mapping of an ER schema into a relational one [2]: { Each entity of the clustered EER diagram is mapped into an object type. The structure of the complex object type depends upon the grouping operation used for complex entity formation. Except for entities that are candidates to absorption, each component of the complex object is recursively mapped into an object type. Multivalued attributes are expressed using the set or list constructors. Aggregate attributes are expressed using the tuple constructor. { Depending on the arity of the relationship and the (minimal and maximal) cardinalities of the associations, each relationship is mapped onto either new attributes (either references to object types or actual attributes) added to the appropriate entities, or new entities making reference to the concerned entities. It is important to note that during the translation process and independently of the way the complex entity E i has been formed, the reference to an entity E j inside E i can take one of the following forms: { the actual structure (attributes) of E j when E j is a candidate to absorption by E i, { a reference attribute (pointer) otherwise. Weak entity absorption and dominance grouping. For this type of grouping, a complex type is created as an aggregation of the strong/dominant entity and the weak/related entities. Each relationship inside the grouping is mapped

9 to a reference attribute whose name is the label of the relationship, and whose type conforms to the weak/related entity type. Curly braces fg are used whenever there are many occurrences of the weak/related entities for one occurrence of the strong entity. Relationship grouping. There are two approaches for relationship translations in the literature [3]: one which explicitly describes the relationship as a class structure [14, 15]. The second approach maps the relationship into a pair of direct and inverse references as described in [4, 10]. In the last case, reference attributes are used to express the relationships between objects and ensure the navigation in one or both directions. To describe the inverse relationships, inverse reference attributes are used. Translation of One-to-one Relationships The translation of one-to-one relationships depends on the kind of the two entities (key or non-key) and their minimal cardinalities in the relationship (optional versus mandatory participation), and on the number of other associations in which each of the two entities is involved in (see [12] for more details). As an illustration, let Oce be (i) a non-key entity, (ii) in an optional participation to the one-to-one relationship occupies with the entity Employee, and (iii) with no other associations in the schema under consideration. In such a situation, it may be wise to make the actual attributes of Oce be components of the entity Employee and destroy the entity Of- ce, especially if no new relationships are expected between Oce and other entities of the schema. Translation of One-to-many Relationships For one-to-many binary relationships grouping, we have to aggregate the entity on the \one side" part together with the entity on the \many side" part placed inside curly brackets, followed by the attributes attached to the relationship, if any. Translation of Many-to-many and Ternary Relationships For many-to-many relationships and ternary relationships, a new structure is created by aggregating the references to the participating entities as well as the attributes associated with the relationships. Generalization/Categorization. The denition of a generalized entity includes the specication of the generalization relationship described by the triplet < Sub; CD; Inherit > as well as its structure. The mapping of a generalized entity and its related specialized entities can be perceived as a translation of a 1 : 1 relationship between the generalized entity and each of its subtypes. A category is described in an OO schema mainly by means of two properties: its structure and its superclasses. The structure is the aggregation of the name of the appropriate superclass together with a reference attribute to the instance of that superclass. The second property enumerates the participating superclasses. The choice of a given mapping depends also upon:

10 { The expected usage patterns. For example, if there are queries that ask for employees of a given department as well as requests for departments having some kinds of employees, then it is required to have both direct and inverse reference attributes connecting departments to their employees. { The expected evolution of the DB schema. For example, if we expect that the entity Oce can very likely participate to a new relationship with another entity, say Floor, then it may be wise to keep Oce as an independent object type instead of pushing it inside Employee. { The peculiarities of the OODBMS under consideration. For example, the database designer is allowed in ObjectStore c to declare two attributes as inverse of one another. This feature is interesting since it oers a way to maintain the consistency of relationships, as opposed to a need for an explicit declaration of directional relationships as in some other OO systems. 3.2 An Example The OO schema corresponding to the clustered EER in Figure 2 can be expressed partly by the following denitions. For the description of class structures and constraints, we make use of the object-oriented language T QL [7]. Class Person Superclasses N il Structure [name : string; age : integer ] Relationships N il Specializations < femployee; Dependentg; (F; T ); User > Category N il Constraints IC 1 : this:age < 110 end Person Class Employee Superclasses Person Structure [ssn : integer; works in : Department; has : fdependentg 0;4 ; involved in : fp rojectg 1;2 ; personal data : P erson ] Relationships works in : Department inverse has worker, involved in : Department:P roject inverse involves Specializations N il Category N il Constraints IC 2 : this:ssn 6= Employee:ssn IC 3 : this:involved in this:works in:controls end Employee

11 Class Department Superclasses N il Structure [name : string; floor : (1... 9); head : Employee; staff : femployeeg +, controls : fp rojectg 0;5 ] Relationships controls : P roject inverse controlled by Specializations N il Category N il Constraints IC 4 : this:name = this:head:works in:name end Department The denition of Person species that this entity is a generalized class for Employee and Dependent with a partial coverage (e.g. a consultant is a person who is neither an employee nor an employee's dependent), and without overlapping between instances of the two classes (i.e., the dependent of an employee is not allowed to be an employee). The specialization is user-dened. In the description of Employee, the cardinality constraint stating that an employee has at most four dependents is expressed by fdependentg 0;4. The keyword \this" in the syntax of T QL denotes the current object, while a type name indicates the class of objects (minus the current object if the key-word \this" also appears). IC 2 is then a uniqueness constraint. IC 3 means that an employee works on a project only when the latter is under the control of the department in which this employee works. The comparison symbol stands for inclusion when applied to sets. IC 4 expresses the idea that if an employee is a head of a department, he/she also works in that department. 4 Conclusion and Further Research In this paper, we have presented an adaptation of the clustering technique proposed in [17] to complex entity formation which is an important step in the mapping process of an EER schema into an object-oriented schema. The overall methodology is implemented within the environment of the prototype called INTERSEM (Interface semantique) [12]. INTERSEM is intended to reduce the semantic gap between the conceptual modelling of OODBs and the modelling tools by providing a framework and an environment for semantic data modelling, OODB design and interfacing, reverse engineering, generic model extraction, and DB schema querying. We are currently studying the validity of the mapping procedure for a real-life application within an industrial project called IGLOO. We are also investigating its potential as a physical object clustering technique when the database usage patterns are closely related to the semantic relationships between object types.

12 Acknowledgements. This work was supported in part by the Natural Sciences and Engineering Research Council of Canada, and by the Ministry of Industry, Commerce, Science and Technology, Quebec, under the IGLOO project organized by the Centre de Recherche Informatique de Montreal. References 1. Atkinson, M. et al.: The Object-oriented Database System Manifesto. Technical Report #30-89, GIP ALTAIR, LeChesnay, France, Batini, C., Ceri, S., and Navathe, S.B.: Conceptual Database Design. An Entityrelationship Approach. The Benjamin/Cummings, New York, Bertino, E., Martino, L.: Object-Oriented Database Systems. Concepts and Architectures. Addison-Wesley Cattell, R.G.G.: The ODMG-93 Standard. Morgan Kaufmann, San Mateo, Chen, P.: The Entity-Relationship Model: Toward a Unied View of Data. ACM Transactions on Database Systems. 1(1), 1976, 9{ Elmasri, R., Navathe, S.B.: Fundamentals of Database Systems, Second edition, Benjamin/Cummings, Redwood City, Formica, A., Missiko, M.: Adding Integrity Constraints to Object-Oriented Databases, Proceedings International Conference on Information and Knowledge Management. Baltimore, MD, 1992, 593{ Gagnon, J-M, Representation et exploitation de la semantique dans un mod`ele oriente objets., Master's thesis, Universite du Quebec a Montreal, August Gray, P.M.D., Kulkarni, K.G., Paton, N.W.: Object-Oriented Databases: Semantic Data Model Approach, C.A.R. Hoare Series Editor. New York/London, Prentice Hall, Hughes, J.G.: Object-Oriented Databases. Computer Science. Prentice Hall Johannesson, P.: A Method for Transforming Relational Schemas into Conceptual Schemas, Proceedings Tenth International Conference on Data Engineering, IEEE Computer Society Press, Los Alamitos, CA, 1994, Missaoui, R., Gagnon, J.M.: Mapping an Extended Entity-Relationship Schema into a Schema of Complex Objects. Technical Report, IGLOO Program, Centre de Recherche Informatique de Montreal, 40 pages, Navathe, S.B., Awong, A.M.: Abstracting Relational and Hierarchical Data with a Semantic Data Model. In Proceedings of Sixth International Conference on Entity- Relational Approach, Navathe, S.B., Pillallamarri, M.K.: OOER: Toward Making the ER Approach Object Oriented. Proceedings of the 8th International Conference on Entity- Relationship Approach, 1989, 55{ Rumbaugh, J.E.: Relations as Semantic Constraints in an Object-Oriented Language, Proceedings of the International Conference on Object-Oriented Programming Systems, Languages, and Applications (OOPSLA). Orlando, Florida, 1987, 466{ Song, I.Y.: A Survey of Object Oriented Database Design Methodologies, Proceedings of the International Conference on Information and Knowledge Management. Baltimore, MD, 52{59, Teorey, T.J. et al.: ER Model Clustering as an Aid for User Communication and Documentation in Database Design. CACM. 32(8), 1989, 975{987. This article was processed using the LaT E X macro package with LLNCS style