• No results found

Spatio-temporal multigranularity in an object data model

N/A
N/A
Protected

Academic year: 2021

Share "Spatio-temporal multigranularity in an object data model"

Copied!
164
0
0

Loading.... (view fulltext now)

Full text

(1)

Universit`

a degli Studi di Milano

Facolt`

a di SS.MM.FF.NN.

Dottorato di Ricerca in Informatica

Spatio-temporal multigranularity

in an object data model

Elena Camossi

XVII ciclo, a.a. 2004-2005

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`a di Pisa - Italy Coordinatore

Prof. Giovanni Degli Antoni Universit`a di Crema

DICO, Universit`a degli Studi di Milano

(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`a degli Studi di Milano

via Comelico 39/41

I-20135 Milano - Italycamossi@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`a di Pisa - Italy guerrini@di.unipi.it

Supervisor:

Prof. Giovanni Degli Antoni

Dipartimento di Informatica e Scienze dell’Informazione, Universit`a di Crema

gda@dsi.unimi.it Ext. Reviewers: Prof. Christophe Claramunt

Institut de Recherche de l’´Ecole Navale Lanvoc-Poulmic, France claramunt@ecole-navale.fr

Dott. Nectaria Tryfona

Computer Technology Institute, Athens, Hellas tryfona@cti.gr

Prof. Carlo Combi

Universit`a 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 defini-tion 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 spatio-temporal 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 spatio-temporal objects. Specifically, we first design a multigranular spatio-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 7

1.1 ODMG Object Model . . . 7

1.1.1 Type System . . . 8

1.1.2 Interfaces and Classes . . . 9

1.1.3 Objects . . . 10

1.1.4 Inheritance . . . 11

1.1.5 OQL, the ODMG Query Language . . . 13

1.2 Modelling Time and Space and Spatio-temporal Multigranularity . . . 15

1.2.1 Representation of Temporal Dimension . . . 15

1.2.2 Temporal Database Models . . . 16

1.2.3 Temporal Granularities . . . 16

1.2.4 Space Representation and Spatial Models . . . 18

1.2.5 Spatial Granularites and Multiresolution Models . . . 19

1.2.6 Spatio-temporal Models . . . 21

1.3 Temporal Expirations . . . 22

1.3.1 Data Deletion . . . 22

1.3.2 Evolution . . . 23

1.4 Active Paradigms . . . 24

I. Modelling Spatio-Temporal Data at Multiple Levels of Detail 27 2 Spatial and Temporal Granularities 28 2.1 Issues on Spatial Granularity Design . . . 28

2.1.1 Connected Set of Spatial Granularities . . . 29

2.1.2 Different Types of Spatial Granularities . . . 30

2.2 A Uniform Framework for Supporting Temporal and Spatial Granularities . . . 32

2.3 Relationship among Granularities . . . 34

2.4 Issues in Implementation of Granularities . . . 36

2.5 Concluding Remarks . . . 38

3 ST ODMG: A Multigranular Spatio-Temporal Extension of ODMG Model 39 3.1 Handling Spatio-Temporal Multigranularity . . . 40

3.2 Preliminaries: Temporal and Spatial Granularities and Elements . . . 41

3.3 Spatio-temporal Multigranular Types . . . 42

3.3.1 Basic Types . . . 43

3.3.2 Multigranular Spatial Types . . . 43

3.3.3 Multigranular Temporal and Spatio-temporal Types . . . 44

3.3.4 ST ODMG Classes and Objects . . . 45

3.4 Spatio-temporal Granularity Conversions . . . 48

3.4.1 Conversion of Spatial Geometrical Attributes . . . 49

3.4.2 Conversion of Spatial Statistical and Temporal Attributes Values . . . 50

3.4.3 Specification of Granularity Conversions . . . 52

3.5 Issues and Properties of Granularity Conversions . . . 53

3.5.1 Issues in Granularity Conversions . . . 53

3.5.2 Properties of Granularity Conversions . . . 54

3.6 Querying Spatio-temporal Data at Different Granularities . . . 56

(5)

3.6.2 Spatio-temporal Access and Path Expressions . . . 60

3.6.3 Spatio-temporal Query Specification . . . 66

3.7 Safe Refinement of Multigranular Attributes . . . 68

3.7.1 Spatio-temporal Subtyping . . . 68

3.7.2 Safe Refinement of Attributes . . . 69

3.7.3 Access and Update for Refined Attributes . . . 73

3.7.4 Analysis of Safe Refinements of Temporal Attributes . . . 76

3.8 Implementation Issues . . . 77

3.8.1 Representation of Multigranular Spatio-temporal Attributes . . . 78

3.8.2 Granularity Conversions . . . 79

3.8.3 Multigranular Navigational Access . . . 80

3.8.4 Implementation of Attribute Refinement . . . 81

3.9 Concluding Remarks . . . 83

II. Expiration of Multigranular Temporal and Spatio-Temporal Objects 85 4 T ODMGe: A Data Model Supporting Dynamic Attributes 86 4.1 Handling Expiration of Multigranular Temporal Objects . . . 86

4.2 T ODMGe The reference model . . . 88

4.2.1 T ODMGe Classes and Objects . . . 89

4.2.2 T ODMGe Object Consistency . . . 90

4.3 Specification of Expiration for Dynamic Attributes . . . 92

4.3.1 Specification of Granularity Evolutions . . . 92

4.3.2 Specification of Deletions of Values . . . 93

4.3.3 Consistency Constraints for Dynamic Attribute Specifications . . . 93

4.4 Expiration Execution: Preliminaries . . . 97

4.4.1 Valid Time as Temporal Dimension . . . 97

4.4.2 Semantics of Temporal Periods . . . 97

4.4.3 Verification of the Expiration Condition: Lazy vs Quantum Approaches . . . 98

4.5 Expiration Execution . . . 98

4.5.1 Expiration Process . . . 99

4.5.2 Non-monotonic Updates of Dynamic Attributes . . . 100

4.5.3 Semantics of Dynamic Attribute Updates . . . 103

4.5.4 Value Deletion and Object Consistency . . . 104

4.6 Access to Multigranular Temporal Objects . . . 105

4.6.1 Access Preliminaries . . . 105

4.6.2 Unqualified Object Accesses . . . 106

4.6.3 Qualified Object Accesses . . . 108

4.6.4 Properties of Object Accesses . . . 108

4.7 T ODMGe Implementation . . . 110

4.8 Concluding remarks . . . 112

5 ST2 ODMGe: A Spatio-Temporal Model for the Dynamic Expiration of Multigranular Object Attributes 114 5.1 Spatio-Temporal Expirations . . . 114

5.2 Preliminaries: the Reference Model . . . 116

5.2.1 Time, Space, and Granularities . . . 117

5.2.2 ST2 ODMGe Classes and Objects . . . 117

5.3 Specification of Dynamic Expirations . . . 121

5.3.1 Specification of Expiration Events . . . 122

5.3.2 Specification of Expiration Conditions . . . 123

5.3.3 Specification of Expiration Actions . . . 125

5.3.4 Consistency of Expiration Specifications . . . 127

5.4 Semantics of Dynamic Expirations: Preliminaries . . . 132

5.4.1 Time Semantics in Dynamic Expirations . . . 133

5.4.2 Semantics of Spatio-Temporal Bounds of Dynamic Expiration Elements . . . 133

5.5 Execution of Dynamic Expirations . . . 136

(6)

5.5.2 Non-periodical Expirations . . . 138

5.5.3 Execution of Periodical Expiration . . . 139

5.5.4 Modifying the Behaviour of ST2 ODMGe Expirations . . . 142

5.5.5 Management of Attribute Updates . . . 142

5.6 On the Access toST2 ODMGe Objects . . . 143

(7)

List of Figures

1.1 Example of inheritance relationships . . . 12

2.1 Example structure of a granularity set defined respect to generalization process . . . 29

2.2 Example of a granularity set defined respect to generalization process . . . 31

2.3 Generalization preserving topological consistency . . . 32

2.4 (a) Example of temporal granularity. (b) Violations of conditiont1 of Definition 2.1. (c) Violation of conditiont2 of Definition 2.1. . . 33

2.5 (a) Example of spatial granularity. (b) Violation of conditionsof Definition 2.2. . . 33

2.6 groups-intorelationship . . . 34

2.7 (a)groups-periodically-into relationship (b)groups-uniformly-intorelationship . . . 35

2.8 finer-thanrelationship . . . 35

2.9 partitionsrelationship . . . 36

2.10 Design of classes implementing granularities and granules . . . 37

3.1 (a) finer-than relationship (b) groups-into relationship. . . 42

3.2 Example of legal value for typespatialcountries(sethPolygoni) . . . 44

3.3 Example of legal value for spatio-temporal attributeboundariesof classMap. . . 45

3.4 Spatio-temporal extension of ODMG class declaration syntax . . . 46

3.5 Spatial geometric conversion operators, where−−−−−→ op∈Opg , op∈Opr ←−−−−−. . . 49

3.6 Example of spatial conversion of a geometric value . . . 50

3.7 Granularity conversions syntax. . . 52

3.8 BNF syntax forSTODMG query elements. . . 67

3.9 Semantics of accesses to multigranular attributes with cast up . . . 75

3.10 Data structure for multigranular spatial values . . . 78

3.11 Data structure for a multigranular temporal values . . . 79

3.12 Data structure for a multigranular spatio-temporal values . . . 79

3.13 Granularity conversions . . . 80

3.14 Implementation of spatial and temporal element (a) ClassElement(b) ClassTElement(c) ClassSElement . . . 81

3.15 Spatio-temporal values (a) ClassTValue(b) ClassSValue(c) ClassSTValue . . . 82

3.16 ClassRedefinition . . . 83

4.1 Example of object state . . . 90

4.2 Example of application of coercion functions at different levels of detail . . . 91

4.3 BNF of attribute declaration . . . 92

4.4 Generic attribute declaration with evolutions and deletions . . . 94

4.5 Constraints forevolveclauses . . . 95

4.6 Constraints fordeleteclauses . . . 97

4.7 (a) Class declaration and (b) evolution and deletion process . . . 100

4.8 tax paymentattribute value . . . 102

4.9 Relationships between starting time and update border of a dynamic attribute . . . 103

4.10 (a)Operational semantics of dynamic attribute updates (b) Procedure signatures . . . 104

4.11 Example of object state . . . 105

4.12 Solving the object accesso.a↓li G . . . 107

4.13 Solving the qualified object access o.a↓f li G . . . 109

(8)

4.15 Temporal value . . . 111

4.16 Dynamic attribute value . . . 112

4.17 ClassSTemporal . . . 112

5.1 Example of object state . . . 118

5.2 BNF Syntax of dynamic expirations. . . 122

5.3 BNF Syntax of expiration events. . . 123

5.4 BNF Syntax of expiration conditions. . . 124

5.5 BNF Syntax of expiration actions. . . 126

5.6 Granularity graph for spatio-temporal attributea. . . 130

5.7 Semantics of temporal occurrence ofST2 ODMGe expirations. . . 133

5.8 ST2 ODMGe execution model. . . 137

5.9 Example ofST2 ODMGe spatial attribute value . . . 138

5.10 Example of ST2 ODMGe spatial attribute value with evolutions . . . 139

5.11 Deletions of value of attribute a . . . 139

5.12 Granularity acquisition. (a) Example of value of attribute a (b-c) Consistent granularity level graphs fora(a) . . . 140

(9)

List of Tables

3.1 Implementation of Operation among Temporal and Spatial Element . . . 80 3.2 Implementation of spatio-temporal operators . . . 83 4.1 Propagation of non-monotonic update effects to evolution levels . . . 101

(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 sophis-ticated 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. Tem-poral and spatial granularities correspond to different partitions of the temTem-poral 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. admin-istrative 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

(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 STODMG, a multigranular temporal object model, that extends ODMG type system to support spatial, temporal and spatio-temporal data at multiple levels of detail. The model has been defined as extension of the spatio-temporal model proposed in [BFGM03].

InST ODMG model,T IME andSPACE 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 toR2. Spatial granularities examples compliant to the proposed definition aremeters,kilometers,f eet,yards,

provincesandcountries. 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 granular-ities. 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 granularityG, usually a granule of a coarser granularity exists that properly includes it. For example, granularitydaysis finer thanmonths, and granularitymonthsis finer thanyears. Moreover,municipalitiesis finer thancountries.

The ODMG type system has been extended with specific types for representing spatial data ac-cording 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 of-ten 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 con-versions are specified separately. Spatio-temporal concon-versions 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 at-tributes, 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 val-ues) to different spatial granularities is performed according to model-oriented generalization principles

(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 conver-sions 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 topo-logical 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 ap-plyingcoercion[BFGM03] andrefinement 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 user-defined 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 theSTODMG model, we investigate the issues of the covariant attribute refinement along an inheritance hierarchy ofST ODMG classes. In particular, we devise the conditions that allow for safe refinements of multigranular spatio-temporal attributes. In theSTODMG 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 theSTODMG model, the expressive power provided by multigranular mod-els is grater than that provided by conventional data modmod-els, in particular when multigranular capabilities are combined with heterogeneous characteristics. Indeed, since the semantics required for managing at-tribute 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 mod-elling 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 expi-rations 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 sup-portsdynamic 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, ex-piration conditions can be specified. An exex-piration condition is given specifying an exex-piration 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

(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 op-erations) 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. TheT 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, theT 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 theinvarianceof 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 designST2 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 forT ODMGe model, but also to their values and to the occurrence of other attributes, as well as to the execution of object methods. Moreover, theST2 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 theST2 ODMGe model has been obtained by relaxing the conditions on spatio-temporal consistency we defined forSTODMG 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.

(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 STODMG, the T ODMGe and the ST2 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 STODMG model. Finally, chapters 4 and 5 discusses the expiration of temporal and spatio-temporal multigranular objects. Specifically, Chapter 4 presents theT ODMGe model, whereas Chapter 5 discusses the design of theST2 ODMGe model.

(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 spatio-temporal 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 theT 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 ofT ODMGe. The resulting model,ST2 ODMGe, performs dynamic expirations of multigranular spatio-temporal data, specified at run-time according to anEvent - Condition - Actionparadigm.

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

(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 con-sortium, 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 oth-erwise 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 1989. The main achievement of OMG has been the CORBA (Common Object Request Bro-ker 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 def-inition 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] ob-ject model. Specifically we present the ODMG type system, obob-ject and classes, and the inheritance relationships supported. Furthermore, we briefly describe the object query language (OQL).

1.1.1

Type System

The basic modelling concepts in the ODMG object model are the notions ofobject andliteral. Objects have a unique identifier (oid), whereas literals have no identifiers. Literals are identified by their values. Literal values are described as being constant orimmutable, i.e., their values cannot change. The concept

(17)

of literal in ODMG 3.0 is similar to the one ofvalue 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 aredate,interval,time,timestamp. In addition, the user can define its own structured literal type using the type constructorstruct. 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 ob-jects 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 typedefdeclaration, 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. Then Object,

Person, Set<Person>andBag<short>are examples of ODMG object types.

By contrast, long, boolean, bag<Object>1are examples of ODMG literal types. 2

1.1.2

Interfaces and Classes

An object type is defined by an externalspecificationand by one or moreimplementations. 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: aninterface 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 stateand abehavior. 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 ofoperations that can be executed on or by the objects of that type.

The object type behavior is specified as a set ofoperation 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.

Extentsandkeyscan 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τ0, 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 ofexceptions(error conditions) the operation can raise. In this context we do not consider exceptions.

(18)

extent ofτ is a subset of the extent ofτ0. 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 classes3 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 implemen-tation defines the internal aspectsof the instances of the object type. The distinction between external specification and implementation is important, since the separation between them is the approach accord-ing to which ODMG supports encapsulation. Implementation details are not relevant from a modellaccord-ing 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. The following is an example of an object type external specification of a class describing persons.

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);

}; 2

1.1.3

Objects

An object in ODMG is characterized by astateand abehavior. The state of an object is defined by the values of itsproperties. Properties can be eitherattributesof the object itself orrelationshipsamong 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 ofoperationsthat 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.

3ODMG 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.

(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 in-stances 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,marriageis an example of one-to-one relationship between two instances of type Person. A woman can have a one-to-many mother ofrelationship with many children. Teachers and students typically participate in many-to-many relationships. A relationship is implicitly defined by declaringtraversal pathsthat 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 traver-sal paths, since a professor teaches one or more courses, and a course is taught by a professor. The

teachestraversal path is defined in the interface declaration of the Professortype. The is taught by

traversal path is defined in the interface declaration of the Course type. The fact that theteaches 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 teachesandis taught bytraversal paths is a one-to-many relation-ship betweenProfessorandCourseobjects. This cardinality is shown in the traversal path declarations. A Professorinstance is associated with a set of Course instances via the teaches traversal path. A

Courseinstance is associated with a single Professorinstance via theis taught bytraversal path. 2 The OODBMS is responsible for maintaining referential integrity of relationships. If an object par-ticipating 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 non-existing 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.

1.1.4

Inheritance

ODMG object model includes inheritance-based type-subtype relationships. More precisely, ODMG supports two inheritance relationships: theISA relationship and theEXTENDSrelationship.

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

(20)

Professor Employee Person EmployeePerson Object EXTENDS ISA ISA ISA ISA

Figure 1.1: Example of inheritance relationships

In ODMG 3.0 each user-defined object type, declared both through a class and an interface specifi-cation, inherits through the ISA relationship from the system interfaceObjectwhich is thus the root of the ISA relationship. Such relationship, betweenObjectand 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, whileextendsdenotes 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 interfaceEmployee. Moreover, class EmployeePersoninherits the state and behavior from class Person, whereas it inherits the behavior from interfaceEmployee. 2 According to the notation used in the ODMG object model, given an interface i and a class c, if an edgei ← c (or i ←i0 where i0 is an interface) exists in the ISA relationship, theni is called direct

superinterfaceofc(i0). In addition, given two classesc andc0, if an edgecc0 exists in the EXTENDS

relationship, thencis calleddirect superclassofc0.

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

Departmentbe a class modelling university departments. Then the definitions of the classes Salaryand

Employee, and of the interface Studentand of the class Teaching Assistant, which inherits from the interface Studentand from the class Employee, are the following.

(21)

attribute float base; attribute float overtime; attribute float bonus; }

class Employee:Object (extent employees, key id){ attribute string name;

attribute short id;

attribute Salary annual salary; void hire();

void fire(); };

interface Student{

struct Address{string college, string room number}; attribute string stud name;

attribute string student id; attribute short year;

attribute Address dorm address;

relationship set<Section> takes

inverse Section::is taken by;

boolean reg for course(in Course c,in Section s); void drop course(in Course c);

void assign major(in Department d);

short transfer(in Section old s,in Section new s); };

class Teaching Assistant extends Employee:Student (extent Teaching Assistants){ relationship Section assists

inverse Section::has TA; attribute string stud name; attribute string student id; attribute short year;

attribute Address dorm address;

relationship set<Section> takes

inverse Section::is taken by;

}; 2

1.1.5

OQL, the ODMG Query Language

ODMG provides a declarative language for querying objects, OQL, that is simple, not computationally complete, and provides high level primitives to deal with objects. OQL is an SQL-like language, thus, it is based on theSelect - From - Whereclause.

Example 1.6 Consider the database schema presented in Example 1.2. The following OQL query re-trieves the names of the persons that live in Rome.

select p.name from Person p

where p.address.city = "Rome" 2

Even though OQL is very close to SQL, it differs from SQL in many respects. First, the result of a query in SQL is always a relation, whereas in OQL the type of the result of a query depends on the query itself, as shown in the following example.

Example 1.7 Consider the database schema presented in Example 1.5. The following OQL query re-trieves the names of the teaching assistants living in room 511.

select t.stud name

(22)

where t.dorm address.room number = "511"

In such a query the type of the result is bag<string>since the type of the attribute stud name of classTeaching Assistantis string and no distinct clause has been specied. In case of distinct clause the type of the result would beset<string>.

Suppose that attribute yearof class Teaching Assistant stores the university year a student attends. The following OQL query retrieves theTeaching Assistant objects corresponding to students attending at least the third university year.

select t

from Teaching Assistants t

where t.year >= 3

By contrast, the following OQL query retrieves the set of structs composed by the name and the identifier of the teaching assistants attending at least the third university year.

select struct(t name: t.stud name, t id: t.student id)

from Teaching Assistants t,

where t.year >= 3 2

The second feature of OQL which differentiates it from SQL is the use of path expressions. OQL path expressions allow one to navigate through objects via object identifers. Path expressions appear in SQL:1999 to support navigation through reference types and through the ADT components. However, in SQL:1999 they are an alternative to the usual join mechanism, whereas in OQL they are the standard mechanism to navigate through references. In OQL, indeed, object oids cannot be explicitly referenced in queries. OQL uses the dot notation to follow both references contained in attributes and traversal paths corresponding to relationships. In addition, in OQL method invocations can appear in path expressions. The notation for calling a method is exactly the same as for accessing an attribute or traversing a relationship, in the case the method has no parameters. If it has parameters, these are given between parentheses. In OQL path navigation across multivalued properties is not allowed. The following example presents some OQL queries involving path expressions.

Example 1.8 Consider the database schema presented in Example 1.5. Suppose that class Section is equipped with an attributecourse, that stores the course to which the section refers. In addition, suppose that class Course is equipped with an attributenamewhich stores the course name. The following OQL query retrieves the names of the teaching assistants of database courses.

select t.stud name

from Teaching Assistants t

where t.assists.of course.name = ‘‘Database"

The following OQL query retrieves the set of structs composed by the names and the identifiers of the teaching assistants which take sections of database courses.

select struct(t name: t.stud name, t id: t.student id)

from Teaching Assistants t, t.takes s where s.of course.name = "Database"

Suppose that the method boolean reg for course which class Teaching Assistant inherits from interfaceStudentreturns true if the teaching assistant attends that course in that section, false otherwise. The following OQL query retrieves the set of objects of class Teaching Assistantrepresenting students of a database course.

select t

from Teaching Assistants t, Course c, Sections s

where t.reg for course(c,s) and c.name = "Database" 2

An important feature of OQL is the support of the late binding mechanism. Thus, for each method invocation the most specific implementation with respect to the type of the object is associated with the method for execution.

(23)

Example 1.9 Suppose that methodreg for courseis overridden inSenior Teaching Assistant, which is subclass ofTeaching Assistant. Then for theTeaching Assistantobjects whose most specific class isSenior Teaching Assistantthe method implementation given in this class is invoked. 2

The use of methods in queries opens many relevant issues that are not fully addressed in OQL. For instance, though it is not explicitly stated in the OQL specification, it seems reasonable to allow only side-effect free methods in queries, that is, they should not modify the database state [Clu98]. Such a restriction is reasonable in order to keep queries side-effect free.

1.2

Modelling Time and Space and Spatio-temporal

Multigran-ularity

In this section we describe how time and space dimensions are represented in the literature.

1.2.1

Representation of Temporal Dimension

Temporal logic represent time as an arbitrary set of instants with an imposed partial order. Linear time can be specified by adding an axiom imposing a total order on this set. In the linear model, time advances from the past to the future in a step-by-step fashion. Another possible model is thebranchingmodel. In the branching model time is linear from the past to now, where it then divides into several time lines, each representing a potential sequence of events.

Axioms may also be added to temporal logics to characterize thedensityof the time line. Combined with the linear model, discrete models of time are isomorphic to natural numbers, implying that each point in time has a single succesor. Densemodels of time are isomorphic to either rationals or the reals: between any two moments of time another moment exists. Continuous models of time are isomorphic to the reals, that is, they are both dense and, unlike the rationals, contain no “gaps”.

A time point on the time line is referred to as an instant [JDB+98]. The time between two time instants is calledtime interval5, also referred to as time period. Linear time is partitioned into smaller segments. A non-decomposable one-dimensional unit of time is calledchronon [Ari86, CR87, JDB+98]. Thus, a chronon is the smallest duration of time the can be represented in a model.

The time domain is used to represent time. Specifically, the time domaingives the set of primitive temporal entities used to define and interpret time-related concepts. The structure of the time domain defines whether it is linear or branching, and if it is dense or discrete. Time domain is usually represented as a pair (T,), whereT is a set, represented either asR,Q,Z, orN, andis the order onT.

Facts are related to the time domain, either as eventsor states. Events are related to instants. By contrast, states have a duration. Moreover, facts interacts with time according to dimensionality of the time domain, In the context of databases, two time dimensions are of general interest: valid time and transaction time. Valid time concerns the time a fact was true in reality [JDB+98]. The valid time of an event is the time at which the event occurred in the real word, independent of the recording of that event in some database. Valid time can refer also to the future, if it is expected the some fact will be true at a specified time after now. Transaction time concerns the time the fact was stored in the database [JDB+98]. The transaction time of a fact identifies the transaction that inserted the fact into the database and the transaction that removed this fact from the database. These two dimensions are orthogonal. A data model supporting neither is termedsnapshot, as it captures only a single snapshot in time of both the database and enterprise that the database models. A data model which supports only valid time is termedvalid-time, one that supports only only transaction time is termedtransaction-time, and one that supports both valid and transaction time is termedbitemporal. Temporalis a generic term implying some kind of time support. There is a third kind of time that may be included: user-defined time [JDB+98]. This term refers to the fact that the semantics of these values are known only to the user, and are not interpreted by the DBMS as differentiated from valid and transaction time, whose semantics are supported by the DBMS.

5Literature related to SQL refer to unanchored segment of the time line, e.g., one day, as time interval. By contrast, time periods represent absolute portion of the time line. However, usually, in the literature, the two terms are widely accepted as synonimus. In the following, we prefer the termtime intervalto represent absolute and contiguous portions of time.

(24)

1.2.2

Temporal Database Models

Temporal database systems efficiently manage not only the current value of data, but also the entire history of data over time. By contrast, in conventional database systems the content of a database represents a snapshot of the reality in that only the current data are recorded. If such a need arises, data histories must be managed at application program level, thus, making the management of data very difficult, if at all possible. Thus, temporal database systems overcomes this lack. Issues related to temporal data models and query languages have been extensively investigated from the theoretical point of view [JS99, WJW98].

Most of the research and development efforts in the area of temporal databases have been carried out in the context of the relational model. In 1995, TSQL2 [Sno95], the temporal extension of the SQL-92 relational database standard has been proposed. In the new standard SQL:1999 [GP99, MSG01] temporal features have not yet been introduced. A recent book by Snodgrass [Sno99] presents effective techniques for designing and building relational database applications that must integrate past and current data.

Several temporal object-oriented data models have been proposed as well in the literature [BFGM03, BFGM98, EdOP93, WH92, ¨OPS+95, RS91, SN97, WD93]. Most models support a linear discretetime structure, whereas only few of them model a user-defined hierarchy of time types. Several practical arguments justify this choice. First, measures of time are inherently imprecise. Second, most natural language references to time are compatible with the discrete time model. Third, the concepts of chronon and period allows to naturally model events that are not instantaneous but have a duration. Finally, any implementation of a data model with a temporal dimension requires some discrete encoding for time.

An important feature which distinguishes the approaches proposed is the modelling entity to which time is associated. Usually, in temporal object-oriented databases objects or attributes can have an associated time. Some approaches associate a timestamp, that is, a time value, with the whole object state; others associate a timestamp with each object attribute often regarding the value of a temporal attribute as a function from a temporal domain to the set of legal values for the attribute. This is also the approach taken in the temporal model presented in the thesis. In all these approaches, except than [BFGM03, BFGM98], one can notice the lack of a common basis and the complete neglecting of standardization issues. One of the main reasons is that the ODMG standard is recent if compared to the SQL standard, and not yet well-established. The definition of the standard has represented for the object-oriented database community a common basis to define extensions of object-oriented databases, compliant with the standard, in many research directions, such as with temporal features. [BFGM98] has been the first attempt to produce an extension of the ODMG object model to manage the time dimension.

Once stored, temporal data must be retrieved, according to a temporal query languages. [Sno95] and [Feg99] give an exaustive review about temporal query languages. The models proposed in [BFGM03, BFGM98, EdOP93, WH92, ¨OPS+95, RS91, SN97, WD93] provide, in particular, temporal object-oriented query languages. However, most of them are extensions of relational query languages rather than of exist-ing non-temporal object-oriented query languages. As we mentioned when describexist-ing OQL in Section 1.1, object-oriented database systems provide, in addition to traditional query languages, anavigational ap-proach to data access. The navigational apap-proach is based on object identifiers and aggregation rela-tionships: given an oid, the system directly accesses the corresponding object and navigates through objects referred to by its components. This access modality can be combined with the query-based (e.g., SQL-like) access. Thus, conditions in a query can be imposed on the nested attributes of the queried ob-jects; such nested attributes are in most cases denoted bypath expressions, or similar syntactic notations. Among the few proposals addressing issues concerning object navigation in a temporal object-oriented data model let us mention [BFG98].

1.2.3

Temporal Granularities

An important requirement, when dealing with temporal aspects, concerns the support formultiple tem-poral granularities [BJW00]. Temporal granularities are the unit of measure for temporal data. For instance, birth dates are typically referred to the granularity of days and train schedules to that of min-utes. The choice of the correct temporal granularity allows the system to store the minimal amount of data, according to the needed level of detail. Since many different granularities exist and no granularity is inherently “better” than another, a temporal database system should support a wide range of temporal granularities and should allow the user to define his/her own application-spec

References

Related documents

With cloud and managed security services, integrated technologies and a team of security experts, ethical hackers and researchers, Trustwave enables businesses to transform the

July 2014, Canadian Statistical Society Annual Conference, Toronto, May 2014, World Social Science Forum, Montréal, October 2013, R/Rmetrics Meielisalp Workshop &amp; Summer School

Besides, some component technologies (e.g. Sun's EJB) introduce new roles in the development process. These roles are not accounted by traditional development

The significant contemporaneous correlation between expenditure changes and income changes reported in Panel B of Table 5 implies that expenditure changes are not dominanted

Air Baltic (delayed flight), Air China (delayed flight), Air Mediterranée (delayed flight), British Airways (cancelled flight, rebooked on a flight departing 23 hours later),

Service Design Service Loose Coupling minimizes dependencies Service Abstraction minimizes the availability of meta information Service Compos ability maximizes

by autistic children in case of learning English in speaking skill, kind of teaching difficulties faced by teacher in case of teaching English speaking skill for autistic children,

consider three models: probabilistic automata, stochastic weighted automata, and PSRs under control from a finite- state policy.. The first two results extend existing results in