Object-Relational Database Design: Can Your Application Benefit ...

Object-Relational Database Design: Can Your Application Benefit from SQL:2003?

George Feuerlicht1 and Jaroslav Pokorný2 and Karel Richta3 1 2 3

University of Technology, Sydney, Australia, [email protected] Charles University of Prague, Prague, Czech Republic, [email protected] Czech Technical University of Prague, Czech Republic, [email protected]

Abstract. Traditional database design methods based on information engineering principles and data normalization do not fully apply to SQL:2003 object-relational databases. New design methodologies and tools are needed to support complex data constructs used in today’s software engineering practice. There are application domains such as spatial, geographical information systems and multimedia applications where the use of object-relational features is mandatory. There are also many other application types that are good candidates for objectrelational features, but are frequently implemented using purely relational design as designers hesitate to face the challenges of object-relational design. It can be argued that the use of object-relational features is limited in practice by the lack of design methodologies that can guide database designers in making informed decisions about design choices that involve comparisons of relational and object-relational solutions. In this paper we discuss objectrelational design guidelines and illustrate using an example that the object-relational implementation can provide significant benefits simplifying the resulting data structures and the implementation of database queries.

1. Introduction The early research and development of object-oriented databases at the beginning of 90s was followed by the emergence of object-relational database approach that builds on the relational database model extending it with object-oriented features. An extensive effort by the database industry and researchers over a period of more than six years resulted in the specification of the SQL:1999 language standard (ISO/IEC 1999) that became the blueprint for the implementation of Object-Relational Database Management Systems (ORDBMS). SQL:1999 and the more recent SQL:2003 (ISO/IEC 2003) provide support for a comprehensive range of features that enable the implementation of complex data types and relationships that characterize modern database applications. However, the availability of such features does not automatically result in an improved design and a more efficient database implementation. Traditional database design methods based on data engineering principles that in-

2

George Feuerlicht and Jaroslav Pokorný and Karel Richta

volve data normalization do not fully apply to object-relational databases. New design methodologies and tools are needed to support complex data constructs used in today’s software engineering practice. ORDBMS must also address the problem of efficient storage and management of complex objects (Zhu et al. 2006) and XML data (Mlýnková and Pokorný 2005). The first attempts to propose methodologies for object-relational databases followed soon after the standardization of objectrelational extensions in SQL:1999, e.g., (Marcos et al. 2001; Rahayu and Taniar 2002; Marcos et al. 2004; Pardede et al. 2004). Notwithstanding such efforts, there are still no widely accepted methodologies for ORDB (Object-Relational Database) design. In some cases the design guidelines rely on proprietary extensions to the SQL standard available in specific ORDBMS products. Furthermore, enhancements included in SQL:2003 have not been systematically incorporated in such approaches. Currently available modelling and design tools vary in notation and constructs they support, but generally use entity types and their hierarchies and various forms of relationships, and have only limited support for SQL:2003. This holds true not only for entity-relational modelling tools, but also for UML-based tools that support object-oriented modelling. The richness of the object-relational data model (when compared to the relational model), and the repertoire of various constructs makes logical database design highly challenging as the number of design options for a given conceptual model dramatically increases. This makes it difficult to develop a methodology that designers can follow in order to map a conceptual schema (either object-oriented or entity-relationship) to an objectrelational database, and at the same time maximizing the effectiveness and efficiency of the design. Design of relational databases follows a structured methodology applying a set of well-defined transformations of the conceptual schema into normalized relations (3NF tables). Using the object-relational design, additional properties of the conceptual schema, such as its graph structure need to be considered. Furthermore, objectrelational design must take into account application requirements, as they impact on the choice of the most appropriate database structures. Consequently, the designer must understand how the data is going to be used by applications including the details of principal queries. In most standard business applications that use simple data structures (e.g. purchase order processing, customer relationship management, etc.) the use of object-relational features introduces unnecessary complexities into the design. In such cases purely relational design may represent the best solution. There are other application domains such as spatial, GIS (Geographical Information Systems) and multimedia applications where the use of object-relational extensions to represent application objects is mandatory. But, importantly, there are many other types of database applications that are good candidates for object-relational features, but are frequently implemented as relational databases because of the lack of suitable design methodologies that can assist with the evaluation of different design strategies. It can be argued that the use of object-relational features in SQL:2003 is limited in practice by the lack of design methodologies that can guide database designers in making informed decisions about design choices that involve comparisons of relational and object-relational solutions. In this paper we show that object-relational features can provide significant benefits simplifying the resulting data structures and

Object-Relational Database Design: Can Your Application Benefit from SQL:2003?

3

the implementation of database queries. In section 2 we discuss the available literature dealing with the topic of object-relational database design. In section 3 we overview the main conceptual constructs used in object-relational models and design tools, and in section 4 we describe the corresponding SQL:2003 object-relational features. In section 5 we introduce the transformation rules for mapping conceptual models to object-relational schemas and discuss their application using an illustrative example. In the concluding section (section 6) we briefly summarize the main contributions of this paper and identify the need for further research in this area.

2. Related work Approaches to object-relational design can be classified into two main categories: 1) General approaches based on the constructs of conceptual models 2) Domainspecific approaches based on data types used in specific domain applications, e.g. spatial data, XML data, scientific data, etc.

2.1 General approaches Marcos et al. (2001) and (2004) consider a methodological approach for ORDB design using UML extensions. In the latter paper Marcos et al. present guidelines for object-relational database design assuming that the conceptual schema is represented in UML and that the target language is SQL:1999. Paper by (Urban et al. 2003) illustrates how UML diagrams can be used to study mappings to different types of database systems, including ORDBSs based on the SQL:1999 standard. Some methodologies are specific to commercial products (e.g. Oracle), and incorporate vendor specific features that are inconsistent with the SQL standards, see, for example (de Haan 2005). Another important area of research concerns the representation of complex objects. For example, (Pardede et al. 2004) consider aggregation constructs and its representation in Oracle 9i. They propose two methods based on proprietary constructs, so called index clustering and nested tables.

2.2 Domain-specific Approaches Mapping spatial data models into object-relational database schemas has been the subject of extensive research interest. For example, the book by (Parent et al. 2006) is devoted to conceptual modelling of spatial and spatio-temporal databases based of the MADS (Modelling of Application Data with Spatio-temporal features) conceptual model. Authors discuss a structural dimension of MADS in the context of object-relational databases, and SQL:2003. They developed a prototype that translates MADS conceptual models into corresponding database schemas for the Oracle and GIS-oriented systems ArcView, and MapInfo systems. The combination of XML and spatial features can be encoded in the Geography Markup Language (GML). Zhu et al. (2006) propose an approach to map GML schema to object-relational database schema based on SQL:1999 and store non-spatial and spatial data from GML documents in object-relational spatial database. The mapping rules from GML schema to

4

George Feuerlicht and Jaroslav Pokorný and Karel Richta

object-relational schema are established so that the structure and semantic constraints of the source GML schema can be preserved in the target object-relational schema. Cohen et al. (2006) consider object-relational representation of the Weather Research and Forecasting (WRF) Model. The main problem the authors attempt to address is how to represent multidimensional variables. ORDB approach offers a more effective solution than the Star or Snowflake schemas transformed into 1NF relations used in data warehousing applications. Authors use mainly ORACLE’s built-in array types (collections) Variable Arrays (Varrays) and Nested Tables.

3. Conceptual Model Constructs In this section we review the conceptual constructs used in database modelling and comment on their limitations in the context of ORDB design. Based on the traditional entity-relationship-attribute approaches, the constructs of conceptual models include: entity types (E), relationship types (R), attributes (A), weak entity types, and ISA hierarchies. The original Chen’s approach to ERA (Entity-RelationshipAttribute) modelling includes n-ary relationships with arbitrary cardinalities, but the cardinality is typically restricted in commercial tools, e.g. (Oracle Designer 2000) to binary relationships with cardinalities 1:N. ISA hierarchies are analogous to class hierarchies in UML. Perhaps, the most significant restriction in conceptual modelling concerns attribute structures. Although there is a natural use for multivalued and composite attributes, most theoretical ERA approaches and practical tools support only simple (atomic) attributes, leading to direct transformation of conceptual structures to 1NF relations. Neglecting rather exotic conceptual constructs such as exclusive relationship types (Oracle 2000), we further consider aggregation and composition. Aggregation and composition are not usually supported in ERA modelling tools, but in UML they are treated as first-class constructs. An aggregation is a partof relationship, in which a composite object (a whole) consists of other component objects (parts). Shareable and existence-independent parts can be represented. We can differentiate between simple aggregations (Marcos et al. 2001), and aggregation hierarchies with several levels of aggregation. A composition is special kind of aggregation in which parts are existentially-dependent on the whole. Consequently, deletions result in removal of all dependent parts. More recently, conceptual models were extended to support XML data, e.g. (Nečaský 2007). The notion of hierarchy is essential to modelling XML data. XML hierarchy can be based on general relationships between entities of two different entity types or modelled specifically using aggregation and composition. The root of the hierarchy can be identified using a graph analysis of the conceptual schema and the hierarchy and then transformed into XML Schema or directly into types and tables of the object-relational data model. Complex data types that can be represented using the object-relational model include geometric complex types, (e.g. line, circle, polygon etc.) used in spatial databases (Zhu et al. 2006).

Object-Relational Database Design: Can Your Application Benefit from SQL:2003?

5

3.1 Illustrative Example To illustrate some of the key features of the object-relational model, consider, for example an Online Movie Database (OMDB) that maintains information about movies, actors, directors, and other movie related information. Users can browse this information on the OMDB website and purchase products (i.e. movie videos, DVDs, books, CDs, and other movie related merchandise). The movie information includes the movie title, director, the official movie website, genre, studio, short synopsis, and the cast (i.e. actors and the roles they play in the movie). Each movie has up to 5 external editorial reviews, and unlimited number of user reviews entered by users online. OMDB website offers products for sale including movie videos and DVDs. Information about videos and DVDs includes title, rating, list price, release date, and other relevant information. This situation can be modelled using a UML Class Diagram shown in Fig. 1. We return to the OMDB model in section 5 where we discuss the design options for transforming the conceptual model into SQL:2003 objectrelational database implementation. class OMDB «metaclass» Person_type

«container» people -

id: OID {ordered}

-

country: string(20) dob: date name: string(100) sex: char(1)

actor_type actor_ref cast_type

playwriter_type playwriter_ref

-

«container» castings

casting_order: integer(2) role: string(50)

{ordered} -

id: OID

director_type movie_ref

movie_type director -

«container» movies -

id: OID

genre: string(20) studio: string(20) synopsis: string(500) title: string(100) website: string(40)

0..5

1

1 {ordered}

external_review_type

ext_review -

user_review_type

review_source: string(50) review_url: string(50)

user_review

-

review_date: date review_text: string(4000) reviewer: string(30) score: integer(1)

*

movie_ref video_type «metaclass» product_type

«container» products -

id: OID {ordered}

-

availability: string(50) list_price: money our_price: money production_company: string(30) rating: string(10) release_date: date runtime: integer(3)

-

format: string(10)

-

acpect_ratio: string(10) dvd_encoding: string(10) number_of_disos: integer(1)

dvd_type

Fig. 1: Conceptual Model of OMDB database

4. SQL:2003 Object-Relational Model In this paper we focus on object-relational databases whose type system is consistent with the SQL standard (i.e. SQL:2003 and its predecessor SQL:1999). The SQL:2003 model is a superset of the original relational model and a relation (table) remains the main data structure, potentially with a sub-structure that may involve complex objects. Objects in the SQL:2003 object-relational model are implemented using user defined types (UDTs). UDTs are either row types or structured types that can include methods specifications and are analogous to Abstract Data Types

6

George Feuerlicht and Jaroslav Pokorný and Karel Richta

(ADTs) in object-oriented databases. With a row type in a table column we can model composite attributes. Structured types can be used to type tables and columns. An object in SQL:2003 is a row of a typed table that includes an OID (Object Identifier). SQL:2003 includes constructors for two special user-defined collection types: ARRAY and MULTISET that are used to implement multivalued attributes. Collection types and row types allow the representation of multivalued and composite attributes, respectively, providing a mechanism for implementing de-normalized tables. The SQL:2003 standard further extends the data structures introduced in the standard SQL:1999 to provide more flexibility for implementation of multivalued attributes, changing array and multiset semantics in a number of significant ways. Arrays can be declared without specifying the cardinality, in which case the (maximum) cardinality is vendor-defined (potentially unbounded), and in SQL:2003 array nesting is unrestricted. Similarly, MULTISETs do not require specification of the maximum cardinality. The MULTISET construct in SQL:2003 allows differentiation between a NULL value and an empty set. Deleting the last element of a multivalued attribute in a table results in an empty set, as opposed to a NULL value. SQL:2003 defines advanced multiset support that includes comparison and set operators. There are three new aggregate functions: to create a multiset from the value of the argument in each row of a group (COLLECT), to create a multiset union of a multiset value in all rows of a group (FUSION), and to create the multiset intersection of a multiset value in all rows of a group (INTERSECTION).

5. Object-Relational Database Design Following the description of the object-relational modelling constructs (in section 3) and the SQL:2003 object-relational model in section 4, we now consider objectrelational database design describing the design choices available when transforming a conceptual model into a set of target SQL:2003 objects. SQL:2003 provides a rich environment for the implementation of database applications and presents the designer with a number of important decisions that include the choice between relational features and object-relational extensions. As the SQL:2003 model subsumes the relational model (i.e. SQL:1999 and SQL:2003 are supersets of SQL:1992), the designer can choose to implement the database as a purely relational database with untyped tables. Alternatively, the designer may decide to define all tables as typed tables and follow the object-relational approach. It is also possible to mix relational and object-relational features typing only selected tables. The designer needs to make decisions about using primary and foreign keys to implement relationships, or using OIDs and REFs (references) for typed tables. Implementation of relationship also present a number of choices; for example, aggregation and composition can be implemented using separate tables, or alternatively using SQL:2003 multisets. Such design decisions are of key importance and must be based on clear design principles and guidelines, as once implemented the database cannot not be readily re-structured to accommodate alternative design strategies. In the following section (5.1) we review the transformation rules for mapping conceptual constructs into SQL:2003 database structures. In section 5.2 we then

Object-Relational Database Design: Can Your Application Benefit from SQL:2003?

7

discuss (using the OMDB example introduced in section 3) the various design choices and the basis for making decisions about using object-relational features available in SQL:2003.

5.1 Transformation Rules for Mapping into SQL:2003 The transformation of a conceptual model into relational and object-relational database structures (i.e. typed or untyped tables) has been extensively investigated. Table 1 shows a typical set of mapping rules giving the correspondence between conceptual constructs and SQL:2003 database structures for both entity types and relationships. Conceptual construct Entity type Attribute Multivalued Composed Calculated Relationship 1:1 1:N

SQL:2003 Type level Structured type Column type ARRAY/MULTISET ROW/Structured type in column

Instance level typed table

Trigger/Method

REF/[ARRAYMULTISET]

2 typed tables 2 typed tables

N:M

ARRAY /[ARRAYMULTISET]

2 typed tables

Aggregation

REF/[ARRAYMULTISET]

2 typed tables

Composition

REF/[ARRAYMULTISET] type hierarchy Based on composition

2 typed tables

Generalization Hierarchy

REF/REF

table hierarchy

Table 1. SQL:2003 Transformation Mapping Rules

A number of options exist for implementing aggregation and composition using SQL:2003 structures and these have been described in the literature. For example, the authors of (Rahayu and Taniar 2002) present a classical relational solution with tables for the whole and the parts, and an additional, aggregate table. The rows of the aggregate table are of the form (whole_id, part_id, part_type). Using this approach referential integrity between aggregate and parts tables is not expressible using the declarative SQL statements. The cardinality of the relationship between the whole and the aggregate is 1:N, and between the part and the aggregate tables 1:1 or 1:N. The cardinality of the relationship between a part and the aggregate tables for a composition is 1:1. In addition to decisions about aggregate structures discussed above, the implementation of SQL:2003 style databases involves decisions about identifiers. Here we differentiate between two basic approaches: object-oriented, and valuebased. The former uses identifiers implied by structured types with relationships represented via references (REF types), or via SQL:2003 multisets. Attributes of

8

George Feuerlicht and Jaroslav Pokorný and Karel Richta

relationships can be added to multiset elements, so that for example arrays of rows, possibly with additional structures can be used into an arbitrary depth. A further design decision involves implementing relationships as bi-directional or unidirectional (the expressivity of both options is the same). Further options include representing relationships by a multiset of primary key values added to a row representing an entity. Ordering of arrays can be relevant for storing XML hierarchies where ordering of child elements is of importance. We have applied the transformation rules in Table 1 to the OMDB conceptual model shown in Fig. 1 and produced the following type definition: create type external_review_type as object (...); create type external_review_array as varray(5) of external_review_type; create type user_review_type as object (...); create type user_review_table as table of user_review_type; create type person_type as object(...)not final; create type director_type under person_type (...); create type actor_type under person_type (...); create type playwriter_type under person_type (...); create type movie_type as object (...); create type product_type as object(...)not final; create type dvd_type under product_type (...); create type video_type under product_type (...); create type cast_type as object (...);

We show abbreviated versions of the type definitions and do not show the corresponding typed tables. In the following sections we discuss the design guidelines used in transforming the OMDB conceptual model.

5.2 Design Guidelines As noted earlier, implementation of the SQL:2003 style databases using the transformation rules in Table 1 involves design decisions about which object-relational feature to use and how it should be deployed. Similar to design of relational databases such design decisions must be based on solid guidelines and universal principles that include the minimization of redundancy, maximizing reuse, and at the same time ensuring good query performance. Also importantly, the complexity of the design must be minimized as complex data structures lead to complexity of database applications and corresponding increase in the development and maintenance effort.

5.2.1 Data Normalization The question of minimizing data redundancy when using composite and nested database structures deserves attention. Normal forms provide a set of guiding principles for relational database design that lead to the minimization of data redundancy. It can be argued that normalization is relevant to object-relational database design, although with some important caveats. For example the use of non-atomic attributes, e.g. address type column that includes STREET, SUBURB, and POSTCODE, vio-

Object-Relational Database Design: Can Your Application Benefit from SQL:2003?

9

lates 1NF, but in general does not lead to redundant data, but using a collection (e.g. VARRAY) to implement a repeated attribute such as phone numbers (e.g. HOME PHONE, WORK PHONE, MOBILE PHONE, etc.) leads to complex retrieval logic, and should be avoided altogether. The use of SQL:2003 collections should be reserved for the implementation of composition and aggregation; in such cases collections represent a separate data structure (although embedded in the parent table) and do not result in redundant data. Similarly, using OIDs avoids partial dependencies between key and non-key attributes (i.e. violation of 2NF), but attribute interdependencies between non-key attributes can still exist and lead to data redundancy, violating 3NF and causing update anomalies.

5.2.2 OIDs vs Keys OIDs and REFs are generally used to implement complex relationships, and they are particularly useful for implementing multiple-level relationships, used for example in integrated circuit design, or component assemblies in manufacturing applications. The main advantage of using OIDs and REFs is the ability to navigate complex relationships without the need for relational joins, thus significantly reducing the number of database reads required to retrieve a composite object. OIDs and REFs typically incur additional storage and processing requirements that can be reduced by scoping references to a particular table. OIDs are also useful in situations where natural (attribute-based) identifiers are not available. We use OIDs throughout the OMDB database, for example for the person, movie and product object types. This leads to simplification and improved clarity of queries. For example, the following query requirement: List the cast for the movie “The Godfather” (in order of importance) showing actors and the roles they play. results in a relatively simple query: SELECT C.ACTOR_REF.NAME, C.CAST_ROLE FROM CASTINGS C WHERE C.MOVIE_REF.TITLE = 'THE GODFATHER' ORDER BY C.CASTING_ORDER;

5.2.3 Column vs Row Types The SQL:2003 model allows the implementation of database objects as column or row types. Only row types have OIDs and should be used if referencing via REFs is required. Column objects (types) cannot be referenced directly and must be accessed via dot notation, e.g. employee.address.postcode (i.e. the corresponding row must be located first and then the column object accessed). Row types provide a comprehensive support for object features, including inheritance and method overriding. In the OMDB example we use typed tables throughout, and take advantage of subtyping and inheritance available for typed tables. The implementation of the PERSON type and all its subtypes (i.e. ACTOR_TYPE, DIRECTOR_TYPE, and PLAYWRITER_TYPE) is a single typed table PEOPLE OF PERSON_TYPE. This design results in a simple solution for query requirements such as:

10

George Feuerlicht and Jaroslav Pokorný and Karel Richta

Are there any movies in which the director is also one of the actors/actresses? The following query takes advantage of referencing and of the fact that both actors and directors have the same supertypes (i.e. PERSON_TYPE). SELECT C.MOVIE_REF.TITLE, C.MOVIE_REF.DIRECTOR_REF.NAME, C.ROLE FROM CASTINGS C WHERE C.ACTOR_REF = C.MOVIE_REF.DIRECTOR_REF;

5.2.4 Implementing Composition and Aggregation As discussed above a number of distinct options exist for the implementation of composition and aggregation in SQL:2003. The general rule for using collections to implement compositions and aggregation is that each detail object must belong to a single master object, and that the detail objects have no meaning out of the context of the master object (e.g. book and book chapters). Additional decisions involve choosing the type of collection most suitable for a specific design scenario, e.g. a choice between VARRAYs and NESTED TABLEs using the Oracle implementation. VARRAYs are more efficient if the collection is manipulated as a single unit using special array functions. NESTED TABLES, on the other hand provide more options for access to individual records using SQL queries that take advantage of the database optimizer, but have increased storage requirements (nested tables include a 16bytes system generated NESTED_TABLE_ID that points to the parent row). OMDB uses VARRAYs to implement the external reviews and NESTED TABLEs to implement the user reviews. Both review types are a form of aggregation, as the individual review records have no meaning outside of the particular movie record. The decision to use VARRAYs for external reviews and NESTED TABLEs for user reviews is based on the consideration of the likely large number of user review records, and the benefits of using SQL queries rather than array processing methods. We have avoided using collections for the implementation of CASTINGS type as a separate table give more flexibility and allows the use of the full power of SQL (including subqueries). The following example illustrates the point: For all movies list the leading actress, i.e. the first billed actress (in the order of credits). SELECT C.MOVIE_REF.TITLE, C.MOVIE_REF.GENRE, C.MOVIE_REF.DIRECTOR_REF.NAME, C.ACTOR_REF.NAME FROM CASTINGS C WHERE C.CASTING_ORDER = ( SELECT MIN(CASTING_ORDER) FROM CASTINGS WHERE ACTOR_REF.SEX = 'F' AND MOVIE_REF = C.MOVIE_REF);

5.2.5 Generalization, Inheritance and Reuse SQL:2003 supports the notion of sub-types and super-types using user-defined types, including single inheritance and method overriding. This gives a number of design options for implementing super-type/sub-type combinations. The standard relational transformation leads to separate (un-typed) tables with each subtype transformed into

Object-Relational Database Design: Can Your Application Benefit from SQL:2003?

11

a corresponding table; alternatively the entire super-type/sub-type combination is transformed into a single relational supertype table. Object-relational transformation follows the same pattern, but supports inheritance and method overriding. For example, the following function AGE is defined for the supertype PERSON and inherited by all its subtypes: CREATE TYPE BODY PERSON_TYPE IS MEMBER FUNCTION AGE(DOB DATE) RETURN INTEGER IS ... END;

The function can then be used to give the age of the director of the movie “SUNSHINE”. SELECT M.TITLE,M.DIRECTOR_REF.NAME,AGE(M.DIRECTOR_REF.DOB) FROM MOVIES M WHERE M.TITLE = 'SUNSHINE';

Method overriding can be used to set discount levels for different types of products: CREATE TYPE BODY dvd_type AS OVERRIDING MEMBER FUNCTION SPECIAL_PRICE ... END; CREATE TYPE BODY video_type AS OVERRIDING MEMBER FUNCTION SPECIAL_PRICE ... END;

6. Conclusions The effective use of SQL:2003 object-relational features requires understanding of the design tradeoffs associated with alternative design strategies. In the absence of guidelines for object-relational database design practitioners tend to avoid using object-relational features altogether, missing out on the potential benefits that this approach provides. The main contribution of this paper is to show that objectrelational design can provide an elegant and an effective solution even for application types that are not normally regarded as candidates for object-relational implementation. We have illustrated using examples how object-relational features can be deployed in such database applications, discussing the design tradeoffs involved in adopting specific object-relational features such as collections, OIDs and REFs. Further work is needed to provide a fully comprehensive design methodology for object-relational databases that can serve as the basis for object-relational design tools. The inclusion of XML support in SQL:2003 creates another area of research interest and demand for design methodologies and tools. The availability of MULTISETs and ARRAY constructs in SQL:2003 makes ORDBMS systems suited for the management of hierarchically structured XML data, but numerous design options exist that need to be evaluated in the context of specific application requirements. Detailed discussion of XML design issues is out of the scope of this paper and will the subject of further publications.

12

George Feuerlicht and Jaroslav Pokorný and Karel Richta

7. Acknowledgments This research has been partially supported by the National Program of Research, Information Society Project No. 1ET100300419, and also by Ministry of Education of Czech Republic under research program MSM 6840770014 and also by the grant of GACR No. GA201/06/0756.

References Cohen, S., Hurley, P., Schulz, K.W., Barth, W.L. & Benton, B. (2006) ACM SIGMOD Record, Vol. 35, No 2 pp. 10–15. de Haan, L. (2005): Mastering Oracle SQL and SQL*Plus. APress. Geography Markup Language (GML) Implementation Specification Version 3.0. (2004) Available at http://www.opengis.net/gml. ISO/IEC 9075:1999 (1999): Information Technology, Database Languages, SQL. Part 2: Foundations. ISO/IEC 9075:2003 (2003): Information Technology, Database Languages, SQL. Part 2: Foundations. Marcos, E., Vela, B., Cavero, M. (2004): A methodological approach for object-relational database design using UML. Informatik - Forschung und Entwicklung, Vol. 18, Num. 3-4 / April, 2004, Springer Berlin / Heidelberg, pp. 152-164. Marcos, E., Vela, B., Cavero, M., Cáceras (2001): Aggregation and Composition in ObjectRelational Database Design. In: Proc. of ADBIS 2001, Res. Communications, A. Caplinskas, J. Eder (Eds.): pp. 195-209. Melton, J., Simon, A.R. (2001): SQL: 1999 - Understanding Relational Language Components. Morgan Kaufmann, 2nd edition. Mlýnková, I., Pokorný, J. (2005): XML in the World of (Object-)Relational Database Systems. In: Information Systems Development Advances in Theory, Practice, and Education 2004. Vasilecas, O.; Caplinskas, A.; Wojtkowski, G.; Wojtkowski, W.; Zupancic, J.; Wrycza, S. (Eds.), Springer Science+Business Media, Inc., 2005, pp. 63-76. Nečaský M. (2007): XSEM - A Conceptual Model for XML. In Proc. Fourth Asia-Pacific Conference on Conceptual Modelling (APCCM2007), Ballarat, Australia. CRPIT, 67. Roddick, J. F. and Annika, H., Eds., ACS. 37-48. ORACLE (2000): Oracle Designer 6i: Systems Modeling. Volume 1 - Instructor Guide. Pardede, E., Rahayu, W., Taniar, D. (2004): Mapping Methods and Query for Aggregation and Association in Object-Relational Database using Collection. In: Proc. of the International Conference on Information Technology: Coding and Computing (ITCC’04), IEEE, 2004, pp. 539-543. Parent, Ch., Spaccapietra, S. & Zimányi, E. (2006) Conceptual Modeling for Traditional and Spatio-Temporal Applications The MADS Approach, Springer Berlin Heidelberg. Rahayu, W., Taniar, D. (2002): Preserving Aggregation in Object-Relational DBMS. In: Proc. of ADVIS 2002, T. Yakho (Ed.), LNCS 2457, pp. 1-10. Urban S.D. & Dietrich, S.W. (2003) Using UML Class Diagrams for a Comparative Analysis of Relational, Object-Oriented, and Object-Relational Database Mappings. In: Proc. of SIGCSE’03, February 19-23, 2003, Reno, Nevada, USA, pp. 21-25. Zhu, F., Zhou, J., Guan, J. and Zhou, S. (2006) Storing and Querying GML in ObjectRelational Databases. In: Proc. of ACM-GIS’06, November 10–11, 2006, Arlington, Virginia, USA, ACM, pp. 107-114.