Spatio-temporal multigranularity in an object data model

Transcription

1 Università degli Studi di Milano Facoltà di SS.MM.FF.NN. Dottorato di Ricerca in Informatica Spatio-temporal multigranularity in an object data model Elena Camossi XVII ciclo, a.a Tutor Prof.ssa Elisa Bertino Computer Science Department, Purdue University - Indiana, USA Relatori Dott.ssa Michela Bertolotto University College Dublin - Ireland Prof.ssa Giovanna Guerrini Università di Pisa - Italy Coordinatore Prof. Giovanni Degli Antoni Università di Crema DICO, Università degli Studi di Milano via Comelico 39/41, I Milano, Italy

2 Ph.D. Thesis in Computer Science Faculty: SS.MM.FF.NN. Title: Spatio-temporal multigranularity in an object data model Submitted by Elena Camossi Dipartimento di Informatica e Comunicazione, Università degli Studi di Milano via Comelico 39/41 I Milano - Italy camossi@dico.unimi.it Date of submission: November 2004 a.a. 2004/2005 Advisors: Prof. Elisa Bertino Computer Science Department, Purdue University - Indiana, USA bertino@cs.purdue.edu Dott. Michela Bertolotto Computer Science Department, University College Dublin - Ireland bertolotto@ucd.ie Prof. Giovanna Guerrini Dipartimento di Informatica, Università di Pisa - Italy guerrini@di.unipi.it Supervisor: Prof. Giovanni Degli Antoni Dipartimento di Informatica e Scienze dell Informazione, Università di Crema gda@dsi.unimi.it Ext. Reviewers: Prof. Christophe Claramunt Institut de Recherche de l École Navale Lanvoc-Poulmic, France claramunt@ecole-navale.fr Dott. Nectaria Tryfona Computer Technology Institute, Athens, Hellas tryfona@cti.gr Prof. Carlo Combi Università di Verona Ca Vignal 2, Verona, Italy combi@sci.univr.it.

3 Abstract Several application domains require to handle spatial and temporal aspects of data, but traditional GIS models do not support a convenient representation of temporal aspects of spatial data. Moreover, a crucial issue in handling spatio-temporal data is the choice of the appropriate granularity: the support for multiple granularities is essential since different levels of detail are usually required for spatio-temporal data in several applications, to enhance modelling flexibility. Unfortunately, while a consolidated definition of temporal granularity exists, no comparable results have been achieved for spatial granularities. This thesis addresses such open problems. A formal definition of spatial granularity is proposed and integrated in a multigranular spatio-temporal object model, defined as extension of ODMG data model. A query language, extending OQL declarative and navigational mechanisms with multigranular spatiotemporal capabilities, integrates the model design. In the context of such model, we investigate the conditions that allow for a safe refinement of object attributes along the inheritance hierarchy. Furthermore, we discuss the application of multigranularity to the expiration of temporal and spatiotemporal objects. Specifically, we first design a multigranular temporal model handling the expiration of historical objects, that is performed according to static conditions specified with respect to the age of data. Then, we extend such a design by proposing a multigranular spatio-temporal model supporting both valid and transaction temporal dimensions, that allows for the dynamic expiration of object attribute.

4 Contents 1 Background and Related Work ODMG Object Model Type System Interfaces and Classes Objects Inheritance OQL, the ODMG Query Language Modelling Time and Space and Spatio-temporal Multigranularity Representation of Temporal Dimension Temporal Database Models Temporal Granularities Space Representation and Spatial Models Spatial Granularites and Multiresolution Models Spatio-temporal Models Temporal Expirations Data Deletion Evolution Active Paradigms I. Modelling Spatio-Temporal Data at Multiple Levels of Detail 27 2 Spatial and Temporal Granularities Issues on Spatial Granularity Design Connected Set of Spatial Granularities Different Types of Spatial Granularities A Uniform Framework for Supporting Temporal and Spatial Granularities Relationship among Granularities Issues in Implementation of Granularities Concluding Remarks ST ODMG: A Multigranular Spatio-Temporal Extension of ODMG Model Handling Spatio-Temporal Multigranularity Preliminaries: Temporal and Spatial Granularities and Elements Spatio-temporal Multigranular Types Basic Types Multigranular Spatial Types Multigranular Temporal and Spatio-temporal Types ST ODMG Classes and Objects Spatio-temporal Granularity Conversions Conversion of Spatial Geometrical Attributes Conversion of Spatial Statistical and Temporal Attributes Values Specification of Granularity Conversions Issues and Properties of Granularity Conversions Issues in Granularity Conversions Properties of Granularity Conversions Querying Spatio-temporal Data at Different Granularities Spatial and Temporal Expressions i

5 3.6.2 Spatio-temporal Access and Path Expressions Spatio-temporal Query Specification Safe Refinement of Multigranular Attributes Spatio-temporal Subtyping Safe Refinement of Attributes Access and Update for Refined Attributes Analysis of Safe Refinements of Temporal Attributes Implementation Issues Representation of Multigranular Spatio-temporal Attributes Granularity Conversions Multigranular Navigational Access Implementation of Attribute Refinement Concluding Remarks II. Expiration of Multigranular Temporal and Spatio-Temporal Objects 85 4 T ODMGe: A Data Model Supporting Dynamic Attributes Handling Expiration of Multigranular Temporal Objects T ODMGe The reference model T ODMGe Classes and Objects T ODMGe Object Consistency Specification of Expiration for Dynamic Attributes Specification of Granularity Evolutions Specification of Deletions of Values Consistency Constraints for Dynamic Attribute Specifications Expiration Execution: Preliminaries Valid Time as Temporal Dimension Semantics of Temporal Periods Verification of the Expiration Condition: Lazy vs Quantum Approaches Expiration Execution Expiration Process Non-monotonic Updates of Dynamic Attributes Semantics of Dynamic Attribute Updates Value Deletion and Object Consistency Access to Multigranular Temporal Objects Access Preliminaries Unqualified Object Accesses Qualified Object Accesses Properties of Object Accesses T ODMGe Implementation Concluding remarks ST 2 ODMGe: A Spatio-Temporal Model for the Dynamic Expiration of Multigranular Object Attributes Spatio-Temporal Expirations Preliminaries: the Reference Model Time, Space, and Granularities ST 2 ODMGe Classes and Objects Specification of Dynamic Expirations Specification of Expiration Events Specification of Expiration Conditions Specification of Expiration Actions Consistency of Expiration Specifications Semantics of Dynamic Expirations: Preliminaries Time Semantics in Dynamic Expirations Semantics of Spatio-Temporal Bounds of Dynamic Expiration Elements Execution of Dynamic Expirations Execution Architecture ii

6 5.5.2 Non-periodical Expirations Execution of Periodical Expiration Modifying the Behaviour of ST 2 ODMGe Expirations Management of Attribute Updates On the Access to ST 2 ODMGe Objects Concluding Remarks iii

7 List of Figures 1.1 Example of inheritance relationships Example structure of a granularity set defined respect to generalization process Example of a granularity set defined respect to generalization process Generalization preserving topological consistency (a) Example of temporal granularity. (b) Violations of condition t1 of Definition 2.1. (c) Violation of condition t2 of Definition (a) Example of spatial granularity. (b) Violation of condition s of Definition groups-into relationship (a) groups-periodically-into relationship (b) groups-uniformly-into relationship finer-than relationship partitions relationship Design of classes implementing granularities and granules (a) finer-than relationship (b) groups-into relationship Example of legal value for type spatial countries (set Polygon ) Example of legal value for spatio-temporal attribute boundaries of class Map Spatio-temporal extension of ODMG class declaration syntax Spatial geometric conversion operators, where op Op r op Op g, 3.6 Example of spatial conversion of a geometric value Granularity conversions syntax BNF syntax for ST ODMG query elements Semantics of accesses to multigranular attributes with cast up Data structure for multigranular spatial values Data structure for a multigranular temporal values Data structure for a multigranular spatio-temporal values Granularity conversions Implementation of spatial and temporal element (a) Class Element (b) Class TElement (c) Class SElement Spatio-temporal values (a) Class TValue (b) Class SValue (c) Class STValue Class Redefinition Example of object state Example of application of coercion functions at different levels of detail BNF of attribute declaration Generic attribute declaration with evolutions and deletions Constraints for evolve clauses Constraints for delete clauses (a) Class declaration and (b) evolution and deletion process tax payment attribute value Relationships between starting time and update border of a dynamic attribute (a)operational semantics of dynamic attribute updates (b) Procedure signatures Example of object state Solving the object access o.a lg i Solving the qualified object access o.a f lg i System architecture iv

8 4.15 Temporal value Dynamic attribute value Class STemporal Example of object state BNF Syntax of dynamic expirations BNF Syntax of expiration events BNF Syntax of expiration conditions BNF Syntax of expiration actions Granularity graph for spatio-temporal attribute a Semantics of temporal occurrence of ST 2 ODMGe expirations ST 2 ODMGe execution model Example of ST 2 ODMGe spatial attribute value Example of ST 2 ODMGe spatial attribute value with evolutions Deletions of value of attribute a Granularity acquisition. (a) Example of value of attribute a (b-c) Consistent granularity level graphs for a (a) v

9 List of Tables 3.1 Implementation of Operation among Temporal and Spatial Element Implementation of spatio-temporal operators Propagation of non-monotonic update effects to evolution levels

10 Introduction A large percentage of data managed in a variety of different application domains has spatio-temporal characteristics. Such characteristics are however quite articulated and diversified and thus require sophisticated data modeling and management tools. In particular, at least three relevant types of application have been reported by the scientific literature which differ with respect to the modeling and management of spatial aspects, that is, position and shape, of the objects involved [TJ99, Jen03]: cadastral applications, in which the spatial aspects are modeled primarily as regions and points, and changes occur discretely across time; transportation applications, in which the spatial aspects are modeled primarily as linear features, graphs, and polylines, and changes of position occur continuously or discretely along time, whereas the shape of objects does not change; environmental applications, that are characterized by continuously changing spatial aspects. Both spatial and temporal characteristics of data can be expressed at different levels of detail. Temporal and spatial granularities correspond to different partitions of the temporal and spatial domains, respectively. In the temporal context, for instance, birth dates are typically referred to the granularity of days and train schedules to that of minutes. In the spatial context, spatial entities can be represented at different granularities by considering hierarchical representations that can be devised, for example, from subdivisions of the reference space into grids, or from some of their semantic characteristics, e.g. administrative boundaries, road categories, land use classifications. Multiple granularities allow one to store spatio-temporal data according to different units, depending on the needs of the application domain, and represent a crucial functionality when analyzing huge amounts of data, possibly collected from different sources. The notion of granularity has been deeply investigated in the temporal context by temporal database and reasoning communities, that finally reached an agreement in 1998 by proposing and then adopting a common definition [BDES98, BJW00]. By contrast, a similar reference definition does not exist yet for the spatial context, mainly due to the inherent complexity of the spatial domain. Recent work on spatial granularity has mainly dealt with issues related to the concepts of vagueness, imperfection and imprecision of spatial information, mainly for qualitative reasoning (see [BS01a, Bit02, DMSW01]) A fundamental work for a definition of spatial granularity in a database context is [SW98], where Stell and Worboys present a theoretical framework for the specification of a spatial granularity lattice that can be integrated in a spatial database model. Commercial systems, both GIS and database products, do not provide a satisfactory support for multi-representation of spatial data. Furthermore, such systems are not able to manage adequately applications that require to handle situations in which temporal aspects have to be taken into account. Although temporal extensions of GIS systems exist [Lan92], commercial packages still do not properly support temporal aspects of spatial data, and database products do not provide data structures for their efficient management as well. Moreover, traditional GIS are not always adequate to manage situations that require to add spatial functionality to existing non-spatial data, since GIS store separately spatial and non-spatial attribute data: usually spatial objects properties are stored in files managed by a file management system, while attribute data are stored in a commercial database. Such an approach, somewhere referred to as loosely coupled approach [RSV02], is in contrast with the approach used by emerging database products (e.g., Oracle [Oracle], Postgres [Postgres], MySQL [MySQL]), that follow an integrated approach for managing spatial and non-spatial information. These products typically provide an information infrastructure 2

11 based on a single database system for managing both types of data. Such an integrated approach is very effective when one needs to add spatial functionality to legacy data already managed by a traditional DBMS because the spatial component can be integrated in a homogeneous way. Moreover, the loosely coupled approach does not allow for maintaining data integrity between spatial and non-spatial attribute data, since they are not managed by the same engine. By contrast, the integrated approach can provide a more effective support for integrity constraints involving both spatial and non-spatial data. The thesis addresses such open research problems, by defining ST ODMG, a multigranular spatiotemporal object model, that extends ODMG type system to support spatial, temporal and spatiotemporal data at multiple levels of detail. The model has been defined as extension of the temporal model proposed in [BFGM03]. In ST ODMG model, T IME and SPACE dimensions are orthogonal. Intuitively, granularities give the units of measure of a set of data, with respect to the dimensions of the domain they represent. Each dimension requires a specific and connected set of granularities, and each set is orthogonal to the sets applied to other dimensions. Then, spatio-temporal information is represented at different levels of detail according to a set of spatial and a set of temporal granularities. The standard notion of temporal granularity [BDES98, BJW00] is supported. Then, a temporal granularity is defined as a mapping from an ordered index set to the set of possible subsets of the time domain, that preserves the order given by the index set. Intuitively, a granularity defines a partition, possibly non-total, of the time domain, such as those represented by subdivisions used by Gregorian calendar (e.g., days, weeks, years, etc.). A proposal of a formalization of spatial granularity has been provided, and is supported by the model. According to such definition, a spatial granularity is defined as a mapping from an index set to possible subset of the spatial domain, that is homeomorphic to R 2. Spatial granularities examples compliant to the proposed definition are meters, kilometers, f eet, yards, provinces and countries. No order is required among granules of the same granularity, but two granules of the same granularity cannot overlap. Spatial and temporal granularities are related to form a connected structure, that, in the general case, is a lattice, as specified in [BDES98] for temporal granularities and in [SW98] for spatial granularities. Each lattice is defined according to the finer-than relationship (defined for temporal granularities in [BDES98]). Such a relationship reflects the intuition that different granularities result in different partitions of the considered domain, but that, given a granule of a granularity G, usually a granule of a coarser granularity exists that properly includes it. For example, granularity days is finer than months, and granularity months is finer than years. Moreover, municipalities is finer than countries. The ODMG type system has been extended with specific types for representing spatial data according to vector format, and with type constructors for representing spatio-temporal data at multiple granularities. In particular, such type set allows to define database schemas with spatio-temporal object types specified having spatial, temporal and spatio-temporal attributes at different spatial and temporal granularities (i.e., it is a non-homogeneous model). Thus, relying on such type system, spatio-temporal object database schemas can be defined to handle uniformly and efficiently all kinds of spatio-temporal information: entities with a spatial extension that move in a (potentially evolving) geographical area, e.g. cars, planes, etc.; the modifications of geographical and thematic maps over time; environmental and social phenomena referred to a geographical area, such as meteorological monitoring systems and cadastral applications; etc. Moreover, the model supports the explicit conversion of spatio-temporal data stored in a database to different spatial and temporal granularities. Granularity conversions are mainly required to represent data at a level of detail suitable for a given task. For instance, a coarser representation of data is often sufficient for visualization purposes, whereas a detailed view is required by spatio-temporal analysis. Granularity conversions are applied according to specifications given by the database designer in the schema. Each conversion specification refers to a single class attribute. Then, the attribute value is converted from a given granularity to a different one with a specific semantics. Spatial and temporal conversions are specified separately. Spatio-temporal conversions are obtained by combining temporal and spatial conversions specified. The granularity conversions specified for an attribute define an instance of the spatio-temporal granularity lattice specific for that attribute. Given two different spatio-temporal attributes, their granularity lattices (potentially) differ with respect to the granularity conversions specified for them. Two categories of operators are supported for performing granularity conversions. The conversion of spatial geometrical attribute values (and of geometrical component of spatio-temporal attribute values) to different spatial granularities is performed according to model-oriented generalization principles 3

12 [MLR95]. Model-oriented generalization applies cartographic techniques for representing spatial data at different levels of abstraction, by taking into account also semantic aspects of data and some notion of consistency, as, for example, the preservation of topological relationships. Specifically, geometric conversions are obtained by applying compositions of the set of model-oriented generalization operators defined in [Ber98, Saa99], and compositions of operators that perform the inverse functions. Such operators are continuous mappings from a vector representation of spatial data to a generalized one. Moreover, they preserve topological consistency, an essential property for data usability. As a consequence of topological consistency property, these operators have the limitation of not being able to represent some of the traditional generalization operations, (e.g. aggregation). Each composition of such operators is a macro-operator with the same characteristics. By contrast, the conversion of spatial statistical attribute values (and of spatial statistical component of spatio-temporal attribute values) to different spatial and temporal granularities is performed by applying coercion [BFGM03] and refinement functions [BCG04], opportunely modified when applied to the spatial context. Coercion functions have been defined in [BFGM03] to allow safe refinement of temporal attributes at coarser granularities, and rely on semantic assumption defined by Bettini et al. [BWJ98]. Moreover, coercion functions have been used in [CBBG03] to convert temporal values and spatio-temporal values to coarser granularities in a meaningful way. Refinement functions have been defined in [BCG04] as inverse of coercion functions, to (re)obtain information at finer granularities from aggregate information stored at coarser granularities. Conversion functions supported by the model perform a wide set of different granularity conversions. However, the database designer is allowed to use his/her own conversion functions if needed. Such userdefined conversion should be specified as class methods in the database schema, then they extend the reference set of conversions for all the instances of that schema, and can be specified as granularity conversion in multigranular attribute specifications. The conversion functions supported by the model are also embedded in a spatio-temporal query language, defined as extension of OQL, the ODMG query language. Specifically, we extend the two mechanisms OQL supports for querying data, namely comparison of values and navigations through objects, with multigranular spatio-temporal capabilities. In particular, the formalization proposed for the extension of conventional path expressions of traditional object oriented model has been inspired by temporal path expressions proposed in [BFGM03]. Spatial and temporal elements, expressions and access have been formalized as well. Such a query language allows the database user to represent and compare information stored at different temporal and spatial granularities. In the context of the ST ODMG model, we investigate the issues of the covariant attribute refinement along an inheritance hierarchy of ST ODMG classes. In particular, we devise the conditions that allow for safe refinements of multigranular spatio-temporal attributes. In the ST ODMG model, the refinement of an attribute in a subclass is allowed in order to modify the granularities at which the attribute values are stored. Substitutability is ensured by the application of granularity conversions on attribute values. As demonstrated also by the ST ODMG model, the expressive power provided by multigranular models is grater than that provided by conventional data models, in particular when multigranular capabilities are combined with heterogeneous characteristics. Indeed, since the semantics required for managing attribute values is often domain dependent, such characteristics allow to target data management to single attribute specifications, enhancing the modelling flexibility. However, several situations exist for which such capabilities are not yet sufficient to satisfy the modelling user requirements. Whenever the significance of data vary, the level of detail used to represent them should be modified. Such a capability is required, for example, to represent phenomena with a periodical occurrence, or when modelling monitoring systems, in which the significance of data varies according to the execution of operations and to the values of a given set of parameters. For spatio-temporal data, in particular, the significance of information stored could change according to locations and/or over time. A static specification of the level of detail of data is not suitable to model such situations. In the second part of the thesis we address such problem, investigating the issues related to the expirations of multigranular temporal and spatio-temporal objects. We first analyse the specific requirements of temporal data, by designing the T ODMGe model, a multigranular temporal data model that supports dynamic attributes. Dynamic attributes are historical attributes whose values are tuple of temporal values, maintained at different levels of detail according to the age of data. On dynamic attributes, expiration conditions can be specified. An expiration condition is given specifying an expiration frequency for the attribute value at a certain granularity, and the action to take when data expire: either evolution at a coarser granularity, or deletion of values, or both. If the action specified is a deletion, the expiration 4

13 condition must also specify the amount of data to expire, expressed through a temporal period. Thus, in the model, at schema level, it is possible to specify that an attribute granularity can be evolved to a coarser granularity after a period of time, through the application of a coercion function. Such an approach allows one to obtain summary information (through aggregation, selection, or user defined operations) from historical data. The model supports as well the possibility of specifying the deletion of values corresponding to a set of granules, namely the oldest ones, from the database. The expiration of historical attribute value is specified, in both cases, according to the age of data. The functionalities provided by T ODMGe model are particularly useful in the context of temporal databases, since they provide an effective solution to the problem, well-known also in the datawarehouse research area [SJ02, SJM03, YW01, DZS03] of the indiscriminate increase of the amount of data. In historical database, indeed, the amount of data stored grows faster than in traditional databases, thus analysis performances decrease. however, temporal (and spatio-temporal) applications usually require that a fine level of detail is used for representing data recently acquired, while older data are of interest to applications and users only as aggregate. For example, details on the kernel temperature in a nuclear power station are relevant at granularity of seconds when they are acquired, but after a month only the daily average can be of interest. The T ODMGe model suites all such requirements, because it provides the support for temporal granularities, that allows to represent historical data at different levels of detail, and allow to manage the level of detail required by temporal applications not only according to the attribute semantics, but also according to how recent data are. Moreover, the T ODMGe model provides the capability for computing and materializing aggregates of temporal values at different levels of detail, for efficiently answering queries that require aggregated temporal values, and it allows to delete/move out of the online database past values at a given level of detail, in order to minimize the disk storage space. To develop such the expiration mechanism of the T ODMGe model, we first revise the notion of multigranular temporal object model, so that different portions of the value of a temporal attribute can be stored at different granularities. Attribute values at different granularities are related by means of coercion functions. The coercion functions applied depend on attribute semantics. A language to specify attribute granularity evolution and value deletion is proposed, assuming that the user specifies such information at schema definition level because expiration conditions depend on the attribute semantics and on specific policies of the application domain. For instance, according to current Italian laws, tax records have to be kept for 5 years, whereas details on bank transactions of an account have to be kept for 60 days. In the last example, moreover, after 60 days, only the account balance has to be maintained for the next 60 days. Finally, we investigate the access to dynamic attribute values, by proposing two different strategies, that are applied according to the available data and to the preferences specified by the user. Specifically, the accuracy and the efficiency on query execution are the strategies we propose. Moreover, we discuss the invariance of the queries results with respect to expiration operations, and the static detection of unsolvable queries. In the last chapter of the thesis, we extend the support of expirations to the spatio-temporal context, and we investigate the issues entailed by a dynamical support for expirations of spatio-temporal objects. Specifically, we design ST 2 ODMGe, a multigranular spatio-temporal model that handles the dynamic specification and execution of expirations on spatio-temporal data. Value deletion, that allows to remove attribute values from the database, and granularity evolution and acquisition, that allow the run-time modification of attribute granularities, are the type of expiration supported. Expirations can be specified interactively, instead to appear in the database schema, by means of declarative specifications with the form Event - Condition - Action, according to the general paradigm of active database models. The conditions specified for expirations can refer to the age of data, as for T ODMGe model, but also to their values and to the occurrence of other attributes, as well as to the execution of object methods. Moreover, the ST 2 ODMGe model is bi-temporal, because it supports two temporal dimensions, specifically valid and transaction time, and expiration specifications can refer to both temporal dimensions. Both periodical and non-periodical expirations are supported by the model. In particular, different semantics for the execution of periodical expirations are proposed. The evaluation of expiration events and conditions, and the effects of expiration actions, can be bounded with respect to geographical areas and to given periods of time (both transactional or valid bounds can be specified). The design of dynamical expirations proposed in the ST 2 ODMGe model has been obtained by relaxing the conditions on spatio-temporal consistency we defined for ST ODMG objects. However, the resulting model provides a very flexible approach to support dynamical expirations. Data usability is guaranteed by consistency rules on the specification of expirations. 5

14 The thesis is organized as follows. Chapter 1 revises the literature and the notions related with the topics of the thesis. In particular, we describe the ODMG model, that is extended by the ST ODMG, the T ODMGe and the ST 2 ODMGe models we design in the thesis. Chapter 2 formally defines the notions of temporal and spatial granularity we use in the thesis, and it analyses the issues related to the formalisation of spatial granularities. Chapter 3 describes the design and the formalisation of the ST ODMG model. Finally, chapters 4 and 5 discusses the expiration of temporal and spatio-temporal multigranular objects. Specifically, Chapter 4 presents the T ODMGe model, whereas Chapter 5 discusses the design of the ST 2 ODMGe model. 6

15 Chapter 1 Background and Related Work In this chapter we present the existing literature related to the main topics of the thesis. The first part of the chapter is dedicated to the ODMG model, because the temporal and spatiotemporal models we define in Chapter 3, 4 and 5 are extensions of ODMG. We describe in particular, providing also some technical detail, the aspects of the ODMG model mainly involved by the topics we deal with in the thesis: the ODMG type system, objects and classes, the inheritance management, and OQL, the ODMG query language. The remaining of the chapter is dedicated to the review of the literature related with the thesis topics. First, we review the literature on spatio-temporal formalisations. Since most of the literature is related to either temporal or spatial aspects of data, we present temporal and spatial modelling separately. Then, we discuss models that support both spatial and temporal dimensions. We focus in particular on work related with database modelling, and we discuss how spatial and temporal granularities are supported by data models in the literature. Among the formalisations presented, we describe in particular a previous multigranulair temporal extension of ODMG model [BFGM03], on which the models formalised in the thesis rely too. The details related to temporal and spatial granularity formalisations we assume in the thesis are discussed in Chapter 2. Finally, we review the work on expirations and active models, concerned with the second part of the thesis. We first discuss the work related with temporal expirations. Temporal expirations are the basis of the T ODMGe formalisation we propose in Chapter 4, that combines temporal granularity evolutions and value deletions approaches in order to reduce the storage occupancy of multigranular historical data. Then, we briefly describe the literature related with active database models. In Chapter 5 we apply an active approach to the spatio-temporal extension of T ODMGe. The resulting model, ST 2 ODMGe, performs dynamic expirations of multigranular spatio-temporal data, specified at run-time according to an Event - Condition - Action paradigm. This chapter is organized as follows. In Section 1.1 we present the main characteristics of the ODMG model, reporting also a review of the literature dealing with the ODMG standard. In Section 1.2 we describe concepts related to modelling of temporal and spatial dimensions. Moreover, we review the literature in spatio-temporal models, focus on spatial and temporal multigranularity and multigranular models. In Section 1.3 we review the work related to temporal expirations. Finally, in Section 1.4 we describe the work on active object-oriented databases and SQL triggers, that represent an instrument currently available in most commercial database systems in order to define active constraints. 1.1 ODMG Object Model Object-oriented database management systems (OODBMSs) [BM92, CZ00a] result from the integration of database technology with the object-oriented paradigm developed in the programming language and software engineering areas. The object-oriented approach improves the modelling flexibility of traditional database models, because the data types and query languages are not limited to those available in traditional database systems. One of the most important features of OODBMSs is the ability to specify both the structure of complex application objects and the operations to manipulate those structures. The late 1980s saw the birth of OODBMSs and, since then, this type of system has undergone intense industrial development. Commercial OODBMS products appeared more than a decade ago. Since then 7

16 OODBMSs were being significantly improved from their earliest releases. The beginning of OODBMSs was characterized by the development of a large number of systems, most of which were produced by small vendors, that were revolutionary with respect to previous DBMSs in that they were built from scratch with a different code base and a different data model. In this initial period, the research community felt the need of at least defining what an OODBMS was. Thus, in 1989, the Object-Oriented Database System Manifesto [ABD + 89] was published. This document describes the main features and characteristics that a system must have to qualify as an OODBMS. Such document can be considered as the ancestor of ODMG. The OODBMS panorama at the beginning of the 1990s was characterized by a quite large number of systems, lacking a common data model and whose use in applications was still at the experimental stage. One of the reasons for the slow growth in OODBMSs was the resistance by customers and companies in migrating to new technologies. However, a common feeling within the OODBMS community was that the lack of a standard for object databases was the major limitation for their widespread use. Indeed, the success of relational database systems did not simply result from a higher level of data independence and a simpler data model than previous systems. Much of their success has been due to the standardization they offer. The acceptance of the SQL standard resulted in a high degree of portability and interoperability among systems, simplified learning new relational DBMSs, and represented a wide endorsement of the relational approach. The lack of any common standard led the major OODBMS companies to establish in 1991 a consortium, ODMG (Object Database Management Group), with the goal of developing suitable standards for OODBMSs. The goal of ODMG was to develop a standard specification for the object model that could allow one to write portable schemas and applications for object-oriented databases. The intense ODMG effort has given the object database industry a jump start towards standards that would otherwise have taken many years. ODMG enables many vendors to support and endorse a common object database interface with respect to which customers can write their applications. As far as possible, ODMG tried to benefit from the work of the OMG (Object Management Group), established in The main achievement of OMG has been the CORBA (Common Object Request Broker Architecture) specification [OPR96] which provides common object-oriented interfaces for distributed systems. ODMG 3.0 [CBB + 99] is the recent release of the object database standard. It follows ODMG-93 [Cat93] and its subsequent releases: ODMG 1.1 [Cat94], ODMG 1.2 [Cat96], and ODMG 2.0 [CBB + 97]. The ODMG standard includes a reference object model (ODMG object model), an object definition language (ODL) and an object query language (OQL). Moreover, the C++, Smalltalk, and Java programming language bindings for ODL and for object manipulation have been specified [CBB + 99]. The task undertaken by ODMG was obviously difficult. The systems manufactured by the member companies were significantly different in many respects. Though most commercial OODMSs still do not exhibit a full level of compliance to the ODMG standard, some of the ODMG caracteristics have been adopted by different categories of products. Java Data Object [JDO], that are a library for the development of persitent Java applications, rely (even not officially) on the ODMG Java binding. Then, a model that is ODMG compliant can also be easily applied to persistent Java applications. Object-relational database management systems (ORDBMSs), which can be regarded as the last generation of DBMSs, support most of the object-oriented concepts. The last release of the SQL standard, SQL:1999 [GP99, MSG01], is based on an object-relational data model. In SQL:1999 relations are still the fundamental data structuring concepts, but objects and classes are introduced in the relational model, extended by supporting reference types and complex types for the tuples of relations and for the domains of relation attributes. For this reasons, we think that relating this thesis work to the ODMG standard makes it more understandable and easily adoptable by commercial systems. In the remaining of the section we summarize the main features of the ODMG 3.0 [CBB + 99] object model. Specifically we present the ODMG type system, object and classes, and the inheritance relationships supported. Furthermore, we briefly describe the object query language (OQL) Type System The basic modelling concepts in the ODMG object model are the notions of object and literal. Objects have a unique identifier (oid), whereas literals have no identifiers. Literals are identified by their values. Literal values are described as being constant or immutable, i.e., their values cannot change. The concept 8

17 of literal in ODMG 3.0 is similar to the one of value in common object-oriented languages. Objects are described as being mutable. Changing the values of the attributes of an object, or the relationships in which the object is involved, does not change the identity of the object. Literal types can be partitioned into three groups: atomic literal types, collection literal types, and structured literal types. Atomic literal types are numbers, characters and so on. Collection literal types represent set, bag, list, array, and dictionary literals. Structured literal types have a fixed number of elements, each of which has a name and can contain either a literal value or an object identifier. They represent structures implementing records. Pre-defined structured literal types supported by the ODMG object model are date, interval, time, timestamp. In addition, the user can define its own structured literal type using the type constructor struct. The extent of a literal type is the classical set of values of the corresponding type. Objects and literals are categorized according to their types. Object types can be defined through interface or class declarations. Object types can be partitioned into three main groups: atomic object types, collection object types, and structured objects types. Atomic object types are user-defined types (e.g., Person, Employee) and they can be defined through interface and class declarations. Collection object types are pre-defined and represent set, bag, list, array and dictionary objects. Structured objects types are pre-defined types, namely Date, Interval, Time, Timestamp. Note that they are the corresponding object version of structured literal types. The model provides constructs for assigning names to types (i.e., through the typedef declaration, declaring a user-defined structure, or declaring an enumeration type). Example 1.1 Let Object be an interface identifier and Person be a class identifier. Person, Set<Person> and Bag<short> are examples of ODMG object types. By contrast, long, boolean, bag<object> 1 are examples of ODMG literal types. Then Object, Interfaces and Classes An object type is defined by an external specification and by one or more implementations. The external specification of an object type consists of an abstract, implementation-independent description of the properties, operations, and exceptions that are visible to users. The ODMG object model includes two different constructs to define the external specification of an object type: an interface definition, which is a specification only defining the abstract behavior of an object type; a class definition, which is a specification defining the abstract state and abstract behavior of an object type. Object type external specifications are characterized by a state and a behavior. The state is defined by the names and the types of its properties. Properties can be either attributes or relationships. The behavior of an object type is defined by the set of operations that can be executed on or by the objects of that type. The object type behavior is specified as a set of operation signatures (method signatures). The ODMG object model does not include formal specification of the semantics of operations. The semantics is highly implementation dependent. Each signature defines the name of an operation, the name and type of each of its arguments, the types of the value returned. 2 Each operation is associated with a single type and its name must be unique within the corresponding type definition. ODMG supports operation overloading, i.e., operations with the same name can be defined for different types. As usual in the object-oriented paradigm, the choice of a specific operation with an overloaded name is referred to as operation dispatching. At run time the most specific implementation (along the inheritance hierarchy) for the invoked method and the receiver object is selected. An operation may have side effects. Some operations may return no value. Extents and keys can be optionally associated with an object type defined through a class declaration. The extent of an object type is the set of all instances of the type within a particular database. In the ODMG object model, if an object type has an extent, then it is unique. If an object is an instance of an object type τ, then it necessarily belongs to the extent of τ. If type τ is a subtype of type τ, then the 1 Note that the ODMG notation [CBB + 99] uses strings with upper case first letter (e.g. Bag<τ>) to denote collection object types (for bags) and strings with lower case first letter (e.g. bag<τ>) to denote the corresponding collection literal type. 2 Moreover each signature defines the names of exceptions (error conditions) the operation can raise. In this context we do not consider exceptions. 9

18 extent of τ is a subset of the extent of τ. In some cases, instances of an object type, defined through a class declaration, can be uniquely identified by the values they have for some property or set of properties. These identifying properties are called keys. The scope of uniqueness for keys is the extent of the type, thus a type must have an extent in order to have a key. Both class and interface types are object types. The main difference between a class and an interface type is that a class is a type which is directly instantiable, that is, instances of this type may be created, whereas an interface is a type that cannot be directly instantiated. Thus, according to the set-inclusion relationship holding between the set of instances of types related by inheritance, we can state that the set of objects instances of an interface type τ is the union of the set of instances belonging to the classes inheriting from τ. Interfaces represent the abstract behavior of an object type, whereas classes represent the abstract state and behavior of an object type. However, it is important to remark that, even though interfaces represent the abstract behavior of an object type, attributes and relationships can be defined within an interface declaration. Attribute and relationship declarations can be specified, exactly with the same notation, both in interfaces and classes. When declared within interfaces, however, properties specify abstract behavior, since they are merely shorthand for the get and set operations. The semantics of such property definitions is the same defined for the OMG [OPR96] accessor and mutator methods. By contrast, when declared within classes, properties are abstract state, thus, they represent data structures rather than operations. The same construct for property declaration has, thus, different semantics when used within classes or when used within interfaces. Many object-oriented programming languages, including C++, Java, and Smalltalk, have language constructs called classes. These correspond to implementation classes and are not to be confused with abstract classes 3 defined in the ODMG object model. Each language binding defines a mapping between ODMG abstract classes and its language classes. We do not introduce throughout the thesis any language binding, rather we refer the reader to [CBB + 99]. Besides the external specification, an object type has one or more implementations. An implementation defines the internal aspects of the instances of the object type. The distinction between external specification and implementation is important, since the separation between them is the approach according to which ODMG supports encapsulation. Implementation details are not relevant from a modelling point of view. Thus, the ODMG object model focuses on the external specification, that is, interface and class definitions, disregarding the implementation specification of an object type. Example 1.2 Let Object be an interface identifier. external specification of a class describing persons. The following is an example of an object type Objects class Person... { attribute short age; attribute string name; attribute enum gender male, female; attribute Address home address; attribute set<phone no> phones; relationship Person is married to inverse Person::is married to; void get married(in Person p); }; An object in ODMG is characterized by a state and a behavior. The state of an object is defined by the values of its properties. Properties can be either attributes of the object itself or relationships among the object and one or more other objects. Typically the value of an object property can change over time. The behavior of an object is defined by the set of operations that can be executed on or by the object. All objects of a given type have the same set of properties and the same set of defined operations. 3 ODMG classes are referred to as abstract in that they specify no method implementation. They should not be confused, however, with abstract classes as supported, for instance, in Java, since ODMG classes can be instantiated. 10

19 In addition to the object identifier, an object can be characterized by one or more names that are meaningful to the programmer or end user. 4 An attribute value is either a literal or an object identifier, whereas relationships are defined between object types. The ODMG object model supports only binary relationships, i.e., relationships between two types, each of which must have instances that can be referenced by object identifiers. Therefore literal types cannot participate in relationships because they do not have object identifiers. Relationships in the ODMG object model are similar to relationships in the entity-relationship data model [Che76]. A binary relationship may be one-to-one, one-to-many, or many-to-many, depending on how many instances of each type participate in the relationship. One-to-many and many-to-many relationships can be represented using collection literal types, such as set, list, and bag. For instance, marriage is an example of one-to-one relationship between two instances of type Person. A woman can have a one-to-many mother of relationship with many children. Teachers and students typically participate in many-to-many relationships. A relationship is implicitly defined by declaring traversal paths that enable applications to use the logical connections between the objects participating in the relationship. For each relationship two traversal paths are declared, one for each direction of traversal of the binary relationship. The following example illustrates traversal path declarations. Example 1.3 The relationship between a professor and the courses he/she teaches generates two traversal paths, since a professor teaches one or more courses, and a course is taught by a professor. The teaches traversal path is defined in the interface declaration of the Professor type. The is taught by traversal path is defined in the interface declaration of the Course type. The fact that the teaches and is taught by traversal paths refer to the same relationship is specified by an inverse clause in both traversal path declarations, as shown in what follows: interface Professor {... relationship set<course> teaches inverse Course::is taught by; }; interface Course {... }; relationship Professor is taught by inverse Professor::teaches; The relationship defined by the teaches and is taught by traversal paths is a one-to-many relationship between Professor and Course objects. This cardinality is shown in the traversal path declarations. A Professor instance is associated with a set of Course instances via the teaches traversal path. A Course instance is associated with a single Professor instance via the is taught by traversal path. The OODBMS is responsible for maintaining referential integrity of relationships. If an object participating in a relationship is deleted, any traversal path leading to that object must also be deleted. Maintaining referential integrity prevents applications from accessing traversal paths that lead to nonexisting objects. Object-valued attributes or, in other words, composite objects, offer an alternative to relationships. Object-valued attributes just enable one object to reference another, without expectation of an inverse traversal path or referential integrity Inheritance ODMG object model includes inheritance-based type-subtype relationships. More precisely, ODMG supports two inheritance relationships: the ISA relationship and the EXTENDS relationship. Subtyping through the ISA relationship pertains to the inheritance of behavior only. Thus interfaces may inherit from other interfaces and classes may also inherit from interfaces. By contrast interfaces may not inherit from classes, nor may classes inherit from other classes through the ISA relationship. Because the ODMG object model supports multiple inheritance of object behavior, it could happen that a type inherits operations with the same name from two different interfaces. The model precludes such a possibility by disallowing name overloading along the ISA hierarchy. 4 Object names are used especially to refer to root objects, which provide entry points into the database. 11

20 ISA Employee ISA Object ISA ISA Person EXTENDS Professor EmployeePerson Figure 1.1: Example of inheritance relationships In ODMG 3.0 each user-defined object type, declared both through a class and an interface specification, inherits through the ISA relationship from the system interface Object which is thus the root of the ISA relationship. Such relationship, between Object and the user-defined object types, can be either explicitly declared, as in Example 1.4, or can be implicitly deduced. In addition to the ISA relationship, that defines the inheritance of behavior between object types, the ODMG object model provides the EXTENDS relationship for the inheritance of state and behavior. The EXTENDS relationship is a single inheritance relationship between two classes, whereby the subordinate class inherits all properties and operations of the class that it extends. The following example illustrates the differences between the two inheritance relationships. Example 1.4 In the following, according to the ODL syntax, the colon (:)denotes the ISA relationship, while extends denotes the EXTENDS relationship. interface Object{...}; interface Employee:Object {... }; interface Professor:Employee {... }; class Person:Object {...}; class EmployeePerson extends Person:Employee{...}; The inheritance relationships induced by the previous declarations are illustrated in Figure 1.1. In Figure 1.1, interface object type names are placed in simple rectangles, whereas class object type names are placed in rectangles with round corners, the ISA and EXTENDS hierarchies are explicitly distinguished by labels on the edges. According to the previous declarations, interfaces Employee and Person inherit the behavior from interface Object through the ISA relationship, whereas interface Professor inherits the behavior from interface Employee. Moreover, class EmployeePerson inherits the state and behavior from class Person, whereas it inherits the behavior from interface Employee. According to the notation used in the ODMG object model, given an interface i and a class c, if an edge i c (or i i where i is an interface) exists in the ISA relationship, then i is called direct superinterface of c (i ). In addition, given two classes c and c, if an edge c c exists in the EXTENDS relationship, then c is called direct superclass of c. If a class type has a direct superinterface, according to the ISA relationship the attributes defined in the interface type are not inherited, since only the behavior is inherited through the ISA relationship. Attributes must thus be redeclared in the class definition. This is in accordance with the fact that interface attributes are intended as accessor method signatures, whereas class attributes are intended as data storage structures. The same remarks apply to relationships. The following example reports an ODMG database schema, where most of the aspects we discussed so far are involved. Example 1.5 Let Course and Section be two classes modelling courses and their sections, and let Department be a class modelling university departments. Then the definitions of the classes Salary and Employee, and of the interface Student and of the class Teaching Assistant, which inherits from the interface Student and from the class Employee, are the following. class Salary:Object { 12