- Email: [email protected]
Modelling concepts for the representation of evolution constraints
Computers, Environment and Urban Systems 27 (2003) 225–241 www.elsevier.com/locate/compenvurbsys
Modelling concepts for the representation of evolution constraints Christophe Claramunta,*, Christine Parentb a Naval Academy Research Institute, BP 600, Brest Naval, France University of Lausanne, HEC Inforge, Lausanne, CH 1015, Switzerland
b
Abstract During the past years several methods have been successfully applied for the design of databases in many application areas. However, the database modelling of the behaviour of dynamic systems is still a challenging open issue, particularly for applications with an important temporal component. The recent integration of the temporal dimension within database modelling methods provides a first step towards the representation of the dynamics of evolving systems. This paper proposes a set of modelling concepts oriented towards the description and representation of constraints that restrict the evolution of entities. We make a distinction amongst evolutions that are characterised by either a migration of an entity towards another entity type, generation or deletion of an entity, or change of value of an entity attribute. These modelling concepts are illustrated in the context of an urban database. # 2002 Elsevier Science Ltd. All rights reserved. Keywords: Database modelling; Evolution; Constraints
1. Introduction Conceptual database models favour a high-level communication support between database designers and the application level. Database schemas are often represented by graphic diagrams, for example, an Entity-Relationship schema that provides a user-oriented visual representation of the application semantics. The development of conceptual database models has been recently re-visited due to recent progress in the integration of the temporal and spatial dimensions within databases (Tryfona & Jensen, 1999). Among the proposed models that include the temporal dimension, most come with temporal constraints that are automatically * Corresponding author. Fax: +33-2-98-23-38-57. E-mail addresses: [email protected] (C. Parent).
(C.
Claramunt),
[email protected]
0198-9715/02/$ - see front matter # 2002 Elsevier Science Ltd. All rights reserved. PII: S0198-9715(02)00022-4
226
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
associated to the modelling concepts: the constraints are inherent to the data model. For instance, the life span of a temporal relationship must be included in the life spans of the linked entities. However, some applications may not obey such a predefined constraint that would contradict the application semantics (Spaccapietra, Parent, & Zimanyi, 1998). Proposals that do not include inherent constraints let database designers define their constraints according to their application requirements. More flexibility is then achieved. Tracking the evolution of entities is another fundamental requirement of dynamic databases and especially of geographic databases. Most geographical applications are dynamic: they need to store the history of real world objects in order to analyse their evolution and the future states of the represented system. Among other requirements, these applications often require the storage within the database of the processes that cause geographical changes (Claramunt & The´riault, 1995), and the ability to explicitly define the constraints that restrict these processes. For example, the migration of a parcel of type Park, protected by an environmental decree, towards a parcel Industrial is generally not allowed within legal databases. Similarly, the rapid natural reforestation of a parcel characterised as dry is not considered as plausible in many environmental studies. Unfortunately, there is still a lack of concepts for an explicit description of changes that occur in the real world. The research described in this paper is oriented to the representation of evolution constraints considered as a user-defined task, part of the modelling process. An evolution refers to any change that can affect an entity. It can be either (or the combination of): Migration: the classification of an entity is modified. An entity is specialised into a sub-class, or on the contrary it looses its membership to a sub-class, or it moves from one sub-class to a sister sub-class. Such an entity modifies its own structure while maintaining its identity (Dong & Li, 1994; El-Sharkawi & Kambayashi, 1990; Radeke & Scholl, 1994). Generation: a new entity is created. Attribute value modification: the value of a thematic, spatial, and/or temporal attribute(s) of an entity is modified. Deletion: an entity is deleted. In order to provide a flexible modelling approach, our model relies on an extended Entity Relationship data model with entity types, relationship types and generalisation/specialisation links (or ISA links). A real world object can be represented by several instances belonging to different classes linked by ISA links (unlike most current object-oriented DBMS, our data model supports multi-instanciation). For instance, a specific parcel can be represented by three instances with the same identity: an instance of the class Parcel, an instance of the sub-class Commercial and an instance of the sub-class Industrial (Commercial and Industrial are sub-classes of Parcel). Moreover, the generalisation/specialisation hierarchy is dynamic: a real world object can at any time gain a new (or lose an existing) instance in another class.
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
227
The proposed evolution model is based on the description of a database schema represented as a graph. An evolution is represented as a directed relationship between entities. An evolution pattern is then defined as a sequence of evolutions authorised by the application semantics (i.e. a path within the graph). Evolutions can be completed by user-defined constraints represented as thematic, spatial and temporal database constraints. We make a difference between constraints that apply before, during or after an evolution, and authorised versus unauthorised evolutions. The remainder of this paper is organised as follows. Section 2 presents a summary of related work in the representation of temporal constraints within database models. Section 3 introduces the temporal properties and the principles used for the development of our model. Section 4 develops the semantics of evolutions and evolution patterns, and a classification of constraints that restrict these evolutions. Section 5 defines a database model for evolutions and their constraints. Section 6 illustrates the model of evolutions with a simplified case study. Finally Section 7 draws the conclusions.
2. Related work Modelling user-defined evolutions implies the description of permissible and prohibited evolutions and the representation of their thematic, temporal and spatial constraints. Thematic constraints are well defined in the database world, they include semantic constraints on data types, key uniqueness, and referential integrity to mention some well-known examples. The explicit representation of temporal constraints has been widely studied by the database research community (Bertino, Ferrari, & Guerrini, 1996; Clifford & Croker, 1988; Su, 1997). Some of the constraints identified include temporal precedence rules between the successive values of an entity1 or temporal constraints for entities involved in generalisation and aggregation relationships. Temporal constraints have been also studied between entities and relationships. For aggregation relationships, an entity component of an aggregation relationship does necessarily hold over the time interval of the aggregated entity (Clifford & Croker, 1988). The temporal existence of an entity is constrained by the temporal existence of its entity type (i.e. the life span of an entity is included in the life span of its entity type) (Bertino, Ferrari, Guerrini, & Merlo, 1998). The temporal existence of a relationship is constrained by the temporal existence of the entities involved in the relationship (Elmasri & Navathe, 1994). Overlapping temporal constraints are also useful for the representation of the notion of referential integrity (i.e. the valid time of two entities related by a referential integrity constraint must intersect in time; Bergamaschi & Sartori, 1998). Classic cardinality constraints have been also extended to snapshot and lifetime constraints that restrict the cardinalities of the roles for either a single instant of time or the life span of this relationship, respectively (Tauzovich, 1991). 1
We use the term entity to describe a real-world concept or phenomena, independently of the database model.
228
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Last but not least normal forms have been extended to the time dimensions (Jensen, Soo, & Snodgrass, 1996). A formal model for the description of evolutions and evolution patterns that restrict the range of possible entity changes has been studied in (Su, 1997). These latter constraints form a set of generic constraints independent of the application. The evolution of objects has been also widely studied within object-oriented models (Bertino et al., 1998; Dong & Li, 1994; El-Sharkawi & Kambayashi, 1990; Maiocchi & Pernici, 1991; Radeke & Scholl, 1994). A specialised case of evolution, the migration, is considered within object-oriented models as either an object that changes to a different class, the addition of a new class membership to an object or the specialisation of an object while maintaining the identity of the object. Integrity constraints restrict certain migrations within object-oriented models. For example, a class defined as essential means that an object member of that class cannot at a subsequent point in time migrate to another class, an exclusive class restricts the membership of an object to this class (Zdonik, 1987). In conclusion, constraints supported by most temporal data models are system constraints that apply explicitly to every type (or class) of the database schema. Therefore, they do not provide full flexibility during the development of a database schema. Very few models allow to describe and to memorise the evolutions. Su’s model provides a landmark theoretical investigation on object migrations (Su, 1997). However this model does not provide a set of modelling concepts oriented and adapted to the user-level. It is also restricted to migrations while our model provides a more general approach that makes a modelling distinction between migrations and events that affect the life and the properties of an entity [i.e. generation, deletion and attribute(s) modification]. In a related work we have proposed a model for the description of spatio-temporal processes that generate some evolutions (Claramunt, Parent, Spaccapietra, & The´riault, 1999), however this proposal does not support so far any modelling concepts for the definition of constraints associated to these processes. The modelling of spatial constraints is still a domain not completely covered at the database conceptual level. In fact the representation of these constraints is often deferred until the database implementation—particularly true in the GIS domain— with all the common drawbacks of incomplete conceptual designs. The inability to enforce spatial constraints at the conceptual level poses a serious treat to the quality of spatial databases (Cockfroft, 1997). Typically, spatial constraints can be defined by expressions containing spatial relationships. These include metric (e.g. minimum distance between two buildings), topological (e.g. a building in a parcel), and orientation constraints (e.g. minimum distance between a building and a factory with dangerous emissions, defined as a function of the locations of the building and factory and the orientation of the main winds). However, few database models integrate these constraints as part of the conceptual model. Current proposals are mainly defined at the logical level as predicate expressions (Egenhofer, 1994; Hadzilacos & Tryfona, 1992). From this brief overview of the different categories of constraints, we believe that the modelling and integration of user-defined evolutions and their associated thematic, temporal, and spatial constraints are still an area that might be explored at
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
229
the database conceptual level. Accordingly, we intend to develop a flexible modelling approach that allows designers to define evolutions and their constraints that reflect the semantics of their applications.
3. Model principles In order to describe the temporal properties of our model, we introduce some basic temporal hypotheses. We assume time to be continuous, T is the set of measured times isomorphic to the set of real numbers and I is the set of time intervals. Let i be a time interval of I, i=[t1, t2] where t1, t22T and t14t2. This notation allows the representation of a time instant as [t1, t1]. Let now be a temporal constant that denotes the present valid time. Relationships between these temporal intervals are defined using Allen’s well known temporal operators {equals, before, meets, overlaps, during, starts, finishes} and their inverse (does not apply for equal which is a symmetric operator; Allen, 1984). As our model aim is the representation of application constraints, we consider the valid-time dimension. We define an a-temporal entity as an entity that represents a real-world object whose existence is supposed permanent (or infinite), a temporal entity as an entity that represents a real-world object with a specific life span that denotes its existence. The life span of a temporal Entity is represented by a finite set of disjoint time intervals as in (Clifford & Croker, 1988). A relationship describes spatial, thematic and/or temporal associations between entities. As for entities, we define an atemporal relationship as a relationship with a supposed permanent existence, a temporal relationship as a relationship with a specific life span that denotes its existence. The life span of a temporal relationship is represented by a finite set of disjoint time intervals. A lot of real-world events have a duration that requires a domain defined by a time interval. Accordingly, the temporality of an evolution is represented by a time interval that can be an instant according to our definition of a time interval. An evolution represents an indivisible temporal property, i.e. an evolution that occurs for an interval of time does not occur for any sub-interval of time of this interval of time, as in (Allen, 1984). The effect of an evolution is represented as a binary function EntEvol as EntEvol : 2Entity Evolution ! 2Entity where 2Entity denotes the power set of Entity; Entity denotes the set of Entity instances, and Evolution the set of evolutions. The development of our model is based on the description of a database schema represented as a directed graph (Hull & King, 1987). A database schema represents entity types, relationship types, and the generalisation/specialisation hierarchy. Nodes are composed of entity types and relationship types. An entity type models a population of entities that share some common properties. Similarly, a relationship type models a population of relationships that share some common properties.
230
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Edges represent entity type to relationship type role links and entity type to entity type IS-A links. IS-A edges that stem from the same entity node and that describe the specialisation of the entities according to a common criteria, can be grouped into a cluster. We model an evolution as a temporal relationship. The life span of an evolution is represented by one time interval (which can be an instant) as we consider an evolution as a continuous (or instantaneous) function in time. Predefined constraints on the migration of entities between the sub-classes of a cluster can be defined: a dynamic (versus static) cluster models entities which can (versus cannot) be involved in a migration from one sub-class to another during their existence. Note that a dynamic cluster may contain a-temporal entity types. Constraints can also restrict the classification defined by the cluster. In a total cluster, every entity instance of the super-class of the cluster must belong at least to one sub-class of the cluster. In a disjoint cluster, every entity instance of the super-class can belong at most to one sub-class. A partition cluster is a total and disjoint cluster. More formally, let us assume the following pairwise disjoint and countable infinite sets: E the set of entity types, R the set of relationship types. A database schema D is a tuple < G, constraints> where: G=(N, A) is a directed graph, N=E [ R is the set of nodes, A E R [ E E is the set of labelled edges (roles of relationships and IS-A links), constraints is a set of constraints that include temporal, thematic and/or spatial constraints.
4. Evolutions and constraints An elementary evolution can be either a migration, a generation or deletion of an entity, or a change of value(s) of an entity attribute(s). Composite evolutions mix several elementary evolutions (e.g. conjunction of two evolutions, sequence of evolutions). For instance, the split of a parcel into two new parcels, is the conjunction of a deletion and a generation. Composite evolutions are not described in the current version of this model; they will be investigated in further work. We model an elementary evolution as a specific kind of temporal relationship, characterised by its specific semantics, and its peculiar roles: source (i.e. entities which are affected by the evolution), target (i.e. entities which are the result of the evolution) and causal (i.e. entities that initiate the evolution). Evolutions are characterised as follows (note that a semantic modelling constraint implies that a relationship is at least a binary link): A migration type models a set of migrations that share some common properties. It is represented as a directed relationship type from m to n entity types which belong to the same generalisation hierarchy, the m entity types being the predecessor entity types to which the entity belongs before the migration and the n entity types being the successor entity types to which
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
231
the entity belongs after the migration. The direction of the migration relationship type represents the orientation of the time line. Predecessor and successor entities represent the same real world object, and therefore have the same identity. Additional Entity types, that cause the migration, may be linked to the migration relationship type (Fig. 1). A generation represents a real-world event that leads to the creation of a (or several) new entity(ies). The entity type(s) that leads to the generation is linked by a generation relationship type to the generated entity type(s) in which an (several) entity(ies) is (are) created, thus modelling the cause of the generation (Fig. 2). A deletion represents a real-world event that leads to the destruction of a (or several) entity(ies). The entity type(s) that leads to the deletion is linked by a deletion relationship type to the entity type(s) from which an (several) entity(ies) is (are) deleted, thus modelling the cause of the deletion (Fig. 2). An attribute modification describes a real-world event that causes a change of value(s) of a (several) thematic, spatial and/or temporal attribute(s) of an entity. The entity type(s) that leads to the modification is linked by a modification relationship type to the entity type(s) whose entity(ies) is (are) updated, thus modelling the cause of the modification (Fig. 2). We identify several forms of evolution types that characterise migrations depending on the configuration of predecessor and successor entity types involved in the evolution. These configurations are defined as follows (note that the following configurations denote distinct roles of a same entity): 1. A single to single role migration type is a relationship type between one and only one predecessor entity type e1 and one and only one another successor entity type e2, e16¼e2 (e.g. a rural parcel becomes a commercial parcel); 2. A single to multiple roles migration type is a relationship between one and only one predecessor entity type e1 and a set of successor entity types {e2, . . ., en} with n > 2 (e.g. a rural parcel becomes both a commercial and industrial parcel);
Fig. 1. Migration.
232
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Fig. 2. Generation versus deletion versus attribute modification.
3. A multiple to single roles migration type is a relationship between a set of predecessor entity types {e1, . . ., en 1} and one successor entity type en with n > 2 (e.g. a parcel which is both rural and commercial becomes an industrial parcel only); 4. A multiple to multiple roles migration type is a relationship between a set of predecessor entity types {e1, . . ., en} and a set of successor entity types {en+1, . . ., en+m}, with {e1, . . ., en}6¼{en+1, . . ., en+m}, n > 1 and m > 1 (e.g. a parcel which is both rural and commercial becomes both an industrial and commercial parcel).
We propose a classification of the constraints that restrict the execution of an evolution as follows: 1. a pre-condition constraint models a constraint that applies before the execution of an evolution, 2. an exe-condition constraint represents a constraint that applies during the execution of an evolution, and 3. a post-condition constraint models a constraint that applies after the execution of an evolution. We define an evolution inventory, denoted evolution_inventory, as the set of evolution types whose semantics has an interest from the application point of view. On the other hand, the database designer can define constraints that restrict the set of possible evolution paths in the database graph. For instance, a legal constraint may restrict any further migration during a period of 10 years for parcels that have migrated from an entity type Rural into either entity types Commercial and/or Industrial. Moreover, in order to complete the explicit description of authorised versus unauthorised evolutions, we introduce an additional modelling concept. A set of unauthorised evolutions, denoted n_evolution, represents the set of evolution types that are unauthorised by the application semantics. This latter constraint is quite useful in legal or scientific applications for which the definition of unauthorised evolutions is often as important as permissible ones (note that we make a distinction between evolutions which are unauthorised from those which are not of interest from the application point of view).
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
233
Therefore, the complete set of evolution patterns is defined by the pair (evolution_inventory, n_evolution) and the constraints that limit the set of allowed sequences of evolutions. Any other evolution, that is neither listed in the evolution_inventory or n_evolution, is implicitly authorised (these evolutions do not present a modelling interest from an application point of view).
5. Database representation The following schema introduces a homogeneous structure for the representation of entity types, clusters, relationship types and evolution types. First, an entity type is defined as a n-tuple (name, supertypes, attributes, constraints): name represents the name of the entity type; supertypes describes the (possibly empty) set of entity types that are direct superclasses of the entity type; attributes represents the attributes of the entity type. attributes is defined as a set of pairs (att_name, att_type) where att_name is the name of the attribute and att_type its domain (i.e. primitive values, complex values using set, list and record constructors, or list of couples < value, valid time interval > for temporal attributes). For temporal entities, a specific attribute lifespan represents their life span (with a domain defined by a finite set of disjoint time intervals). For spatial entities, a specific attribute geometry represents their spatial extent (with a spatial domain chosen among the following ones: Point, Line, Area, PointSet, LineSet, . . .). constraints represents the set of constraints applicable to the entity type. A constraint is defined as a named Boolean expression whose variables are attributes of the entity type. To ensure the consistency of these constraints we define constraints as satisfiable, that is, there exists a non empty database for which all the constraints hold. Secondly, a cluster is defined as a n-tuple (name, supertype, subtypes, status, behaviour): name represents the name of the cluster; supertype describes an entity type which is the super-class of the cluster; subtypes describes a set of entity types that are direct sub-classes of the supertype; status describes the classification of entities in the sub-classes (i.e. an entity instance of the super-class must (can) belong at least (at most) to one sub-class. It is defined on a domain with four values total, exclusive, partition, and null when the cluster is neither total nor exclusive; behaviour describes the static versus dynamic quality of the cluster (i.e. authorisation to migrate between the sub-classes or not, respectively), defined on a domain with two values static and dynamic.
234
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Thirdly, a relationship type is defined as a n-tuple (name, role_entities, attributes, constraints): name represents the name of the relationship type; role_entities represents the set of edges linking the relationship type to the connected entity types. Each edge, called role, is defined by the linked entity type, the role name, and its cardinality. A role is mandatory if any occurrence of the entity type of the role must be linked by at least one occurrence of the relationship type, optional in the opposite case. A role is mono-valued if any occurrence of the entity type of the role may be linked by at most one occurrence of the relationship type, multi-valued in the opposite case. attributes represent the attributes of the relationship type in the same way as for entity types. attributes is defined as a set of pairs (att_name, att_type) where att_name is the name of the attribute and att_type its domain (i.e. primitive values, complex values using set, list and record constructors, or temporal values). An attribute lifespan represents the life span of a temporal relationship (with a domain defined by a finite set of disjoint time intervals); constraints represents the set of constraints applicable to the relationship type. A constraint is defined as a predicate whose variables are attributes of the linked entity types and relationship type. As for the entity type we define constraint as satisfiable. Finally, an evolution type is a peculiar type of relationship which can be either a migration, a deletion, a generation, a modification, or any combination of these. It is characterised as follows: role_entities groups three different sets of roles (or linked entity types): source roles that describe the entity types predecessor of the evolution, target roles that describe the entity types successor of the evolution, causal roles that describe the entity types that caused the evolution; attributes must contain an attribute lifespan that represents the life span of the evolution, defined by an atomic time interval domain; constraints represents the set of named constraints applicable to the evolution type. This set is divided into three subsets, pre, exe and post, that represent the set of pre-condition constraints, exe-condition constraints and post-condition constraints of the evolution type, respectively. The definition of these types supports the modelling of entities, clusters, relationships, and evolutions. The identity of an entity is managed at a system level and not represented explicitly within the entity type specification.
6. Application In order to illustrate the properties of our model, let us consider, as in Section 4, an illustrative case study in the context of a land-use database whose entities are
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
235
thematic, spatial and temporal (the semantics presented in the following examples has an illustration objective, not a search for realism). This application example includes the entity types Rural, Commercial, Industrial and Park. Due to environmental rules, a parcel Park cannot become any other kind of parcel; it is and will always stay as and only as a parcel Park. On the other hand a parcel which is not a park can freely change its type or gain a new type. For instance, a parcel Rural can become a parcel Commercial, then become a parcel Industrial. . .. There is only one exception to these free migrations: the application semantics prohibits a parcel Rural to become a parcel Industrial. The entity types Rural, Commercial, Industrial and Park are generalised into an entity type Parcel. The entity types Rural, Commercial and Industrial define a dynamic cluster, the entity type Park does not belong to this cluster as it has been previously constrained as static. Evolution types describe the dynamics of the application including constraints that restrict the range of these evolutions. For instance, an isolated deletion (resp. an appearance) of a parcel denotes a parcel that is transferred to (resp. taken from) the public domain as proposed in (Spery, Claramunt, & Libourel, 2001). A contraction (resp. an expansion) of a parcel denotes a part of a parcel that is transferred to (resp. taken from) the public domain. This reflects the fact that the public domain is not referenced in many cadastral systems (e.g. the French cadastral system). The set of non-evolutions defines the prohibited migrations (from Park to any other entity type, and from Rural to Industrial). Fig. 3 illustrates the schema of this application. Additional and self-explanatory constraints are presented within entity type specifications. The first specification of entity type concerns the entity type Parcel. ENTITY Parcel ATTRIBUTES:
CONSTRAINTS:
(LifeSpan: INTERVAL UNIT DAY, Geometry: POLYGON, Pnumber: INTEGER, Owner: STRING), (ParcelC1: CountHistory(self, 365) < 3, ParcelC2: area(self.Geometry) > 10)
END Parcel Aggregated constraints restrict evolution patterns that may affect some entities from the time they belong to an entity type. They are an example of pre-condition constraints. The earlier constraint example ParcelC1 restricts the number of migrations of an entity for a duration of time. This constraint is propagated backward in the lifecycle of the entities of this entity type. It is based on the identity of the entity. It is defined using a function CountHistory that returns the number of current and previous entity types of an entity for a specific duration of time (i.e. starting from now backward). The constraint ParcelC1 limits the number of migrations for any entity of entity type Parcel to a maximum of 2 during any duration of time of 365 days. A second constraint example ParcelC2 models the fact that an entity of type Parcel must have a minimal area. This constraint does apply for the generation of a new parcel and for a change of value of the spatial attribute Geometry. It is defined using a
236
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Fig. 3. Application schema.
function Area that returns the area of a parcel entity. As previously mentioned, the notion of cluster allows us to define in which groups of sub-classes migrations are allowed or prohibited. For instance, the cluster CDyn groups the classes which are dynamic (Rural, Commercial and Industrial ). We can remark that the cluster Cdyn is not a total cluster as entities Park do not belong to this cluster. CLUSTER CDyn dynamic SUPER_ENTITY: SUB_ENTITIES: END CDyn
Parcel Rural, Commercial, Industrial
A second example of entity type, Rural, specialisation of the entity type Parcel, illustrates an entity type that includes a thematic constraint RuralC1 that restricts the domain of the attribute Culture. ENTITY Rural IS A Parcel ATTRIBUTES: (Culture: STRING), CONSTRAINTS: (RuralC1: self.Culture=‘‘Wheat’’ OR self.Culture= ‘‘Corn’’ OR self.Culture=‘‘Oat’’ OR self.Culture=‘‘Rice’’ OR self.Culture=‘‘Vineyard’’) END Rural A third example of entity type, Industrial, includes a spatial constraint IndustrialC1 that prohibits an industrial parcel from being adjacent to a rural parcel (defined with a Boolean function Adjacent that returns true if two spatial extents are topologically adjacent, false in the opposite case).
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
237
ENTITY Industrial IS A Parcel ATTRIBUTES: (Activity: STRING, RiskLevel: INTEGER), CONSTRAINTS: (IndustrialC1: Not Exist (Select r From r In Rural Where adjacent(self.Geometry, r.Geometry)) END Industrial The following example of entity type Commercial illustrates an entity type that includes a thematic and spatial constraint CommercialC1 that does not allow important commercial buildings to be adjacent to rural parcels. The constraint is specified by a conjunction of predicates that return true if there is at least one entity of entity type Commercial and of level of Activity 3, adjacent to an entity of entity type Rural, false on the contrary. ENTITY Commercial IS A Parcel ATTRIBUTES: (ActivityLevel: INTEGER), CONSTRAINTS: (CommercialC1: NotExist (Select r From r In Rural Where adjacent(self.Geometry, r.Geometry AND self.ActivityLevel=3)) END Commercial Finally the following examples illustrate the entity types Park and Surveyor (the entity type Surveyor is of interest for applications whose objective is to keep the references of the surveyor that materialised the parcel change). ENTITY Park IS A Parcel END Park ENTITY Surveyor ATTRIBUTES:
(Name: STRING, Address: STRING ),
END Surveyor The second category of examples concerns evolution types. We introduce two examples that illustrate the specification of predecessor and successor entity types and pre-, exe- and post-execution constraints. A first example describes a single role migration. The evolution type RuralToCommercial models a migration between the Entity type Rural and the entity type Commercial (a one to one relationship). A precondition constraint RtoCPre limits the domain of a predecessor entity of entity type Rural to entities with a maximal surface, and an exe-condition RtoCExe to migrations whose duration take less than 365 days. EVOLUTION RuralToCommercial CATEGORY MIGRATION, ROLE: (SOURCE: Rural [0,1] TARGET: Commercial [0,1]),
238
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
ATTRIBUTES:
CONSTRAINTS:
(LifeSpan: INTERVAL UNIT DAY, BuildingSociety: STRING, Architecture: STRING), (PRE: RtoCPre: area(self.SOURCE. Rural.Geometry) < 5000, EXE: RtoCExe: duration(self.Lifespan) < 365)
END RuralToCommercial A third example describes the evolution type RuralToCommercialAndIndustrial that models a single to multiple roles migration (we can remark that this migration does not correspond to a spatial process that splits the parcel into two new parcels, but to a functional migration that brings two new activities to an existing parcel whose spatial extent and idEntity are not changed). This evolution type models a relationship between the Entity type Rural and the Entity types Commercial and Industrial (ternary relationship). Self-explanatory constraints are also defined. EVOLUTION RuralToCommercialAndIndustrial CATEGORY MIGRATION, ROLE: (SOURCE: Rural [0,1], TARGET: Commercial [0,1], TARGET: Industrial [0,1]), ATTRIBUTES: (LifeSpan: INTERVAL UNIT DAY, BuildingSociety: STRING, Architecture: STRING, ToxicLevel: INTEGER), CONSTRAINTS: (PRE: RtoC&IPre: area(self.SOURCE.Rural. Geometry) < 10000, EXE: RtoC&IExe: duration(self.Lifespan)< 365, POST: RtoC&Ipost: self.TARGET.Commercial. ActivityLevel)6¼3) END RuralToCommercialAndIndustrial An evolution that models the expansion of the geometry of a Parcel is modelled as follows: EVOLUTION ParcelExpansion CATEGORY MODIFICATION, ROLE: (TARGET: Parcel [0,1], CAUSE: Surveyor [0,N]) ATTRIBUTES: (LifeSpan: INTERVAL UNIT DAY, Deed: STRING), CONSTRAINTS: (POST: PEPost: area(self.TARGET.NEW.Geometry) > area(self.TARGET.OLD.Geometry)) END ParcelExpansion
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
239
An evolution that describes the deletion of a Parcel is modelled as follows: EVOLUTION ParcelDeletion CATEGORY MODIFICATION, ROLE: CONSTRAINTS: END ParcelDeletion
(TARGET: Parcel [0,1], CAUSE: Surveyor [0,N] ), (PRE: PDPre: self.TARGET.Owner=NUL)
An evolution type that specialises an entity of type Parcel into an entity of type Rural is modelled as follows (single role migration). Similar evolution types can be defined for the entity types Commercial, Industrial and Park. EVOLUTION ParcelToRural CATEGORY MIGRATION, ROLE:
(SOURCE: Parcel [0,1], TARGET: Rural [0,1])
END ParcelToRural The evolution inventory describes the above set of authorised evolutions that present an interest from the application point of view: evolution_inventory=
(RuralToCommercial, RuralToCommercialAndIndustrial ParcelToRural, ParcelToCommercial, ParcelToIndustrial, ParcelToPark )
Finally, unauthorised evolutions that describe the prohibited migrations of the application can be defined as follows: n_evolution=
(MIGRATION Rural TO Industrial, MIGRATION Park TO Parcel, MIGRATION Park TO Rural, MIGRATION Park TO Industrial, MIGRATION Park TO Commercial)
7. Conclusion The representation of user-defined evolutions and constraints is an important requirement for the improvement of the semantics represented within databases. If some important progress have been recently made in the integration of the time
240
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
dimension within database models and on the representation of temporal constraints, the modelling and integration of user-defined evolutions and constraints are still an area that might be explored for the benefits of both legal and scientific applications. This paper proposes a description of evolution types and their constraints within a database schema. We make a distinction between several forms of evolutions: the migration of an entity between sub-classes, the generation (and deletion) of an entity, and the change of value(s) of an entity attribute(s). They allow the definition and management of evolution constraints at the database design level. We integrate these constraints as a component of a database schema in order to guarantee a monitoring of these constraints within the life cycle of a database application. Evolutions are modelled as a specific subset of relationship types. Evolution constraints are represented as pre-conditions, exe-conditions and post-conditions that restrict the execution of evolutions. An evolution inventory defines the set of authorised evolutions. Similarly, unauthorised evolutions can also be explicitly declared.
References Allen, J. F. (1984). Towards a general theory of actions and time. Artificial Intelligence, 23, 123–154. Bergamaschi, S., & Sartori, C. (1998). Chrono: a conceptual design framework for temporal entities. In T. W. Ling, S. Ram, & M. Lee (Eds.), Proceedings of the XVII International Conference on Conceptual Modelling (ER’98), LNCS 1507 (pp. 35–50). Singapore: Springer-Verlag. Bertino, E., Ferrari, E., & Guerrini, G. (1996). A formal temporal object-oriented data model. In P. M. G. Apers, M. Bouzeghoub, & G. Gardarin (Eds.), Proceedings of the Extended Database Technology Conference (EDBT’96), LNCS 1057 (pp. 342–356). Avignon: Springer-Verlag. Bertino, E., Ferrari, E., Guerrini, G., & Merlo, I. (1998). Extending the ODMG model with time. In E. Jul (Ed.), Proceedings of the 12th European Object-Oriented Programming Conference (ECOOP 98), LNCS 1445 (pp. 41–66). Brussels: Springer-Verlag. Claramunt, C., Parent, C., Spaccapietra, S., & The´riault, M. (1999). Database modelling for environmental and land use changes. In S. Geertman, S. Openshaw, & J. Stillwell (Eds.), Geographical information and planning: European perspectives (pp. 173–194). Berlin: Springer-Verlag. Claramunt, C., & The´riault, M. (1995). Managing time in GIS: an event-oriented approach. In J. Clifford, & A. Tuzhilin (Eds.), Recent advances on temporal databases (pp. 23–42). Zurich: Springer-Verlag. Clifford, J., & Croker, A. (1988). Objects in time. Data Engineering Bulletin, 11(4), 11–18. Cockfroft, S. A. (1997). Taxonomy of spatial data integrity constraints. Geoinformatica, 1(4), 327–343. Dong, G., & Li, Q. (1994). A framework for object migration in object-oriented databases. Data and Knowledge Engineering, 13(3), 221–242. Egenhofer, M. (1994). Pre-processing queries with spatial constraints. Photogrammetry Engineering and Remote Sensing, 60(6), 783–790. Elmasri, R., & Navathe, S. B. (1994). Fundamentals of database systems. Benjamin/Cummings. El-Sharkawi, M. E., & Kambayashi, Y. (1990). Object migration mechanisms to support updates in object-oriented databases. In N. Rishe, S. Navathe, & D. Tal (Eds.), Proceedings of the Parbase’90 International Conference on Databases, Parallel Architectures and their Applications (pp. 378–387). Miami Beach: IEEE-CS Press. Hadzilacos, T., & Tryfona, N. (1992). A model for expressing topological integrity constraints in geographic database. In A. U. Frank, I. Campari, & U. Formentini (Eds.), Theories and methods of spatiotemporal reasoning in geographic space (pp. 252–268). Berlin: Springer-Verlag. Hull, R., & King, R. (1987). Semantic data modelling: survey, applications and research issues. ACM Computing Surveys, 19(3), 201–260.
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
241
Jensen, C. J., Soo, M. D., & Snodgrass, R. T. (1996). Unifying temporal models via a conceptual model. Information Systems, 19(7), 513–547. Maiocchi, R., & Pernici, B. (1991). Temporal data management systems: a comparative view. IEEE Transactions on Knowledge and Data Engineering, 3(4), 504–524. Radeke, E., & Scholl, M. H. (1994). Framework for object migration in federated database systems. In Proceedings of the 3rd Conference on Parallel and Distributed Information Systems (PDIS 94), Austin, Texas, September 28-30 (pp. 187–194). Austin: IEEE Computer Society. Spaccapietra, S., Parent, C., & Zimanyi, E. (1998). Modelling time from a conceptual perspective. In G. Gardarin, J. C. French, N. Pissinou, K. Makki, & L. Bouganin (Eds.), Proceedings of the International Conference on Information and Knowledge Management, CIKM’98 (pp. 332–340). Washington DC: ACM Press. Spery, L., Claramunt, C., & Libourel, T. (2001). A spatio-temporal model for lineage metadata. Geoinformatica, 5(1), 51–70. Su, J. (1997). Dynamic constraints and object migration. Theoretical Computer Sciences, 184(1–2), 195–236. Tauzovich, B. (1991). Toward temporal extensions to the entity-relationship model. In T. J. Teorey (Ed.), Proceedings of the 10th International Conference on the Entity-Relationship Approach (pp. 163–179). San Mateo: ER Institute. Tryfona, N., & Jensen, C. (1999). Conceptual data modelling for spatiotemporal applications. Geoinformatica, 3(3), 241–264. Zdonik, S. (1987). Object-oriented type evolution. In F. Bancilhon, & P. Buneman (Eds.), Advances in database programming languages (pp. 277–288). Roscoff: ACM Press/Addison Wesley.
Modelling concepts for the representation of evolution constraints Christophe Claramunta,*, Christine Parentb a Naval Academy Research Institute, BP 600, Brest Naval, France University of Lausanne, HEC Inforge, Lausanne, CH 1015, Switzerland
b
Abstract During the past years several methods have been successfully applied for the design of databases in many application areas. However, the database modelling of the behaviour of dynamic systems is still a challenging open issue, particularly for applications with an important temporal component. The recent integration of the temporal dimension within database modelling methods provides a first step towards the representation of the dynamics of evolving systems. This paper proposes a set of modelling concepts oriented towards the description and representation of constraints that restrict the evolution of entities. We make a distinction amongst evolutions that are characterised by either a migration of an entity towards another entity type, generation or deletion of an entity, or change of value of an entity attribute. These modelling concepts are illustrated in the context of an urban database. # 2002 Elsevier Science Ltd. All rights reserved. Keywords: Database modelling; Evolution; Constraints
1. Introduction Conceptual database models favour a high-level communication support between database designers and the application level. Database schemas are often represented by graphic diagrams, for example, an Entity-Relationship schema that provides a user-oriented visual representation of the application semantics. The development of conceptual database models has been recently re-visited due to recent progress in the integration of the temporal and spatial dimensions within databases (Tryfona & Jensen, 1999). Among the proposed models that include the temporal dimension, most come with temporal constraints that are automatically * Corresponding author. Fax: +33-2-98-23-38-57. E-mail addresses: [email protected] (C. Parent).
(C.
Claramunt),
[email protected]
0198-9715/02/$ - see front matter # 2002 Elsevier Science Ltd. All rights reserved. PII: S0198-9715(02)00022-4
226
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
associated to the modelling concepts: the constraints are inherent to the data model. For instance, the life span of a temporal relationship must be included in the life spans of the linked entities. However, some applications may not obey such a predefined constraint that would contradict the application semantics (Spaccapietra, Parent, & Zimanyi, 1998). Proposals that do not include inherent constraints let database designers define their constraints according to their application requirements. More flexibility is then achieved. Tracking the evolution of entities is another fundamental requirement of dynamic databases and especially of geographic databases. Most geographical applications are dynamic: they need to store the history of real world objects in order to analyse their evolution and the future states of the represented system. Among other requirements, these applications often require the storage within the database of the processes that cause geographical changes (Claramunt & The´riault, 1995), and the ability to explicitly define the constraints that restrict these processes. For example, the migration of a parcel of type Park, protected by an environmental decree, towards a parcel Industrial is generally not allowed within legal databases. Similarly, the rapid natural reforestation of a parcel characterised as dry is not considered as plausible in many environmental studies. Unfortunately, there is still a lack of concepts for an explicit description of changes that occur in the real world. The research described in this paper is oriented to the representation of evolution constraints considered as a user-defined task, part of the modelling process. An evolution refers to any change that can affect an entity. It can be either (or the combination of): Migration: the classification of an entity is modified. An entity is specialised into a sub-class, or on the contrary it looses its membership to a sub-class, or it moves from one sub-class to a sister sub-class. Such an entity modifies its own structure while maintaining its identity (Dong & Li, 1994; El-Sharkawi & Kambayashi, 1990; Radeke & Scholl, 1994). Generation: a new entity is created. Attribute value modification: the value of a thematic, spatial, and/or temporal attribute(s) of an entity is modified. Deletion: an entity is deleted. In order to provide a flexible modelling approach, our model relies on an extended Entity Relationship data model with entity types, relationship types and generalisation/specialisation links (or ISA links). A real world object can be represented by several instances belonging to different classes linked by ISA links (unlike most current object-oriented DBMS, our data model supports multi-instanciation). For instance, a specific parcel can be represented by three instances with the same identity: an instance of the class Parcel, an instance of the sub-class Commercial and an instance of the sub-class Industrial (Commercial and Industrial are sub-classes of Parcel). Moreover, the generalisation/specialisation hierarchy is dynamic: a real world object can at any time gain a new (or lose an existing) instance in another class.
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
227
The proposed evolution model is based on the description of a database schema represented as a graph. An evolution is represented as a directed relationship between entities. An evolution pattern is then defined as a sequence of evolutions authorised by the application semantics (i.e. a path within the graph). Evolutions can be completed by user-defined constraints represented as thematic, spatial and temporal database constraints. We make a difference between constraints that apply before, during or after an evolution, and authorised versus unauthorised evolutions. The remainder of this paper is organised as follows. Section 2 presents a summary of related work in the representation of temporal constraints within database models. Section 3 introduces the temporal properties and the principles used for the development of our model. Section 4 develops the semantics of evolutions and evolution patterns, and a classification of constraints that restrict these evolutions. Section 5 defines a database model for evolutions and their constraints. Section 6 illustrates the model of evolutions with a simplified case study. Finally Section 7 draws the conclusions.
2. Related work Modelling user-defined evolutions implies the description of permissible and prohibited evolutions and the representation of their thematic, temporal and spatial constraints. Thematic constraints are well defined in the database world, they include semantic constraints on data types, key uniqueness, and referential integrity to mention some well-known examples. The explicit representation of temporal constraints has been widely studied by the database research community (Bertino, Ferrari, & Guerrini, 1996; Clifford & Croker, 1988; Su, 1997). Some of the constraints identified include temporal precedence rules between the successive values of an entity1 or temporal constraints for entities involved in generalisation and aggregation relationships. Temporal constraints have been also studied between entities and relationships. For aggregation relationships, an entity component of an aggregation relationship does necessarily hold over the time interval of the aggregated entity (Clifford & Croker, 1988). The temporal existence of an entity is constrained by the temporal existence of its entity type (i.e. the life span of an entity is included in the life span of its entity type) (Bertino, Ferrari, Guerrini, & Merlo, 1998). The temporal existence of a relationship is constrained by the temporal existence of the entities involved in the relationship (Elmasri & Navathe, 1994). Overlapping temporal constraints are also useful for the representation of the notion of referential integrity (i.e. the valid time of two entities related by a referential integrity constraint must intersect in time; Bergamaschi & Sartori, 1998). Classic cardinality constraints have been also extended to snapshot and lifetime constraints that restrict the cardinalities of the roles for either a single instant of time or the life span of this relationship, respectively (Tauzovich, 1991). 1
We use the term entity to describe a real-world concept or phenomena, independently of the database model.
228
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Last but not least normal forms have been extended to the time dimensions (Jensen, Soo, & Snodgrass, 1996). A formal model for the description of evolutions and evolution patterns that restrict the range of possible entity changes has been studied in (Su, 1997). These latter constraints form a set of generic constraints independent of the application. The evolution of objects has been also widely studied within object-oriented models (Bertino et al., 1998; Dong & Li, 1994; El-Sharkawi & Kambayashi, 1990; Maiocchi & Pernici, 1991; Radeke & Scholl, 1994). A specialised case of evolution, the migration, is considered within object-oriented models as either an object that changes to a different class, the addition of a new class membership to an object or the specialisation of an object while maintaining the identity of the object. Integrity constraints restrict certain migrations within object-oriented models. For example, a class defined as essential means that an object member of that class cannot at a subsequent point in time migrate to another class, an exclusive class restricts the membership of an object to this class (Zdonik, 1987). In conclusion, constraints supported by most temporal data models are system constraints that apply explicitly to every type (or class) of the database schema. Therefore, they do not provide full flexibility during the development of a database schema. Very few models allow to describe and to memorise the evolutions. Su’s model provides a landmark theoretical investigation on object migrations (Su, 1997). However this model does not provide a set of modelling concepts oriented and adapted to the user-level. It is also restricted to migrations while our model provides a more general approach that makes a modelling distinction between migrations and events that affect the life and the properties of an entity [i.e. generation, deletion and attribute(s) modification]. In a related work we have proposed a model for the description of spatio-temporal processes that generate some evolutions (Claramunt, Parent, Spaccapietra, & The´riault, 1999), however this proposal does not support so far any modelling concepts for the definition of constraints associated to these processes. The modelling of spatial constraints is still a domain not completely covered at the database conceptual level. In fact the representation of these constraints is often deferred until the database implementation—particularly true in the GIS domain— with all the common drawbacks of incomplete conceptual designs. The inability to enforce spatial constraints at the conceptual level poses a serious treat to the quality of spatial databases (Cockfroft, 1997). Typically, spatial constraints can be defined by expressions containing spatial relationships. These include metric (e.g. minimum distance between two buildings), topological (e.g. a building in a parcel), and orientation constraints (e.g. minimum distance between a building and a factory with dangerous emissions, defined as a function of the locations of the building and factory and the orientation of the main winds). However, few database models integrate these constraints as part of the conceptual model. Current proposals are mainly defined at the logical level as predicate expressions (Egenhofer, 1994; Hadzilacos & Tryfona, 1992). From this brief overview of the different categories of constraints, we believe that the modelling and integration of user-defined evolutions and their associated thematic, temporal, and spatial constraints are still an area that might be explored at
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
229
the database conceptual level. Accordingly, we intend to develop a flexible modelling approach that allows designers to define evolutions and their constraints that reflect the semantics of their applications.
3. Model principles In order to describe the temporal properties of our model, we introduce some basic temporal hypotheses. We assume time to be continuous, T is the set of measured times isomorphic to the set of real numbers and I is the set of time intervals. Let i be a time interval of I, i=[t1, t2] where t1, t22T and t14t2. This notation allows the representation of a time instant as [t1, t1]. Let now be a temporal constant that denotes the present valid time. Relationships between these temporal intervals are defined using Allen’s well known temporal operators {equals, before, meets, overlaps, during, starts, finishes} and their inverse (does not apply for equal which is a symmetric operator; Allen, 1984). As our model aim is the representation of application constraints, we consider the valid-time dimension. We define an a-temporal entity as an entity that represents a real-world object whose existence is supposed permanent (or infinite), a temporal entity as an entity that represents a real-world object with a specific life span that denotes its existence. The life span of a temporal Entity is represented by a finite set of disjoint time intervals as in (Clifford & Croker, 1988). A relationship describes spatial, thematic and/or temporal associations between entities. As for entities, we define an atemporal relationship as a relationship with a supposed permanent existence, a temporal relationship as a relationship with a specific life span that denotes its existence. The life span of a temporal relationship is represented by a finite set of disjoint time intervals. A lot of real-world events have a duration that requires a domain defined by a time interval. Accordingly, the temporality of an evolution is represented by a time interval that can be an instant according to our definition of a time interval. An evolution represents an indivisible temporal property, i.e. an evolution that occurs for an interval of time does not occur for any sub-interval of time of this interval of time, as in (Allen, 1984). The effect of an evolution is represented as a binary function EntEvol as EntEvol : 2Entity Evolution ! 2Entity where 2Entity denotes the power set of Entity; Entity denotes the set of Entity instances, and Evolution the set of evolutions. The development of our model is based on the description of a database schema represented as a directed graph (Hull & King, 1987). A database schema represents entity types, relationship types, and the generalisation/specialisation hierarchy. Nodes are composed of entity types and relationship types. An entity type models a population of entities that share some common properties. Similarly, a relationship type models a population of relationships that share some common properties.
230
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Edges represent entity type to relationship type role links and entity type to entity type IS-A links. IS-A edges that stem from the same entity node and that describe the specialisation of the entities according to a common criteria, can be grouped into a cluster. We model an evolution as a temporal relationship. The life span of an evolution is represented by one time interval (which can be an instant) as we consider an evolution as a continuous (or instantaneous) function in time. Predefined constraints on the migration of entities between the sub-classes of a cluster can be defined: a dynamic (versus static) cluster models entities which can (versus cannot) be involved in a migration from one sub-class to another during their existence. Note that a dynamic cluster may contain a-temporal entity types. Constraints can also restrict the classification defined by the cluster. In a total cluster, every entity instance of the super-class of the cluster must belong at least to one sub-class of the cluster. In a disjoint cluster, every entity instance of the super-class can belong at most to one sub-class. A partition cluster is a total and disjoint cluster. More formally, let us assume the following pairwise disjoint and countable infinite sets: E the set of entity types, R the set of relationship types. A database schema D is a tuple < G, constraints> where: G=(N, A) is a directed graph, N=E [ R is the set of nodes, A E R [ E E is the set of labelled edges (roles of relationships and IS-A links), constraints is a set of constraints that include temporal, thematic and/or spatial constraints.
4. Evolutions and constraints An elementary evolution can be either a migration, a generation or deletion of an entity, or a change of value(s) of an entity attribute(s). Composite evolutions mix several elementary evolutions (e.g. conjunction of two evolutions, sequence of evolutions). For instance, the split of a parcel into two new parcels, is the conjunction of a deletion and a generation. Composite evolutions are not described in the current version of this model; they will be investigated in further work. We model an elementary evolution as a specific kind of temporal relationship, characterised by its specific semantics, and its peculiar roles: source (i.e. entities which are affected by the evolution), target (i.e. entities which are the result of the evolution) and causal (i.e. entities that initiate the evolution). Evolutions are characterised as follows (note that a semantic modelling constraint implies that a relationship is at least a binary link): A migration type models a set of migrations that share some common properties. It is represented as a directed relationship type from m to n entity types which belong to the same generalisation hierarchy, the m entity types being the predecessor entity types to which the entity belongs before the migration and the n entity types being the successor entity types to which
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
231
the entity belongs after the migration. The direction of the migration relationship type represents the orientation of the time line. Predecessor and successor entities represent the same real world object, and therefore have the same identity. Additional Entity types, that cause the migration, may be linked to the migration relationship type (Fig. 1). A generation represents a real-world event that leads to the creation of a (or several) new entity(ies). The entity type(s) that leads to the generation is linked by a generation relationship type to the generated entity type(s) in which an (several) entity(ies) is (are) created, thus modelling the cause of the generation (Fig. 2). A deletion represents a real-world event that leads to the destruction of a (or several) entity(ies). The entity type(s) that leads to the deletion is linked by a deletion relationship type to the entity type(s) from which an (several) entity(ies) is (are) deleted, thus modelling the cause of the deletion (Fig. 2). An attribute modification describes a real-world event that causes a change of value(s) of a (several) thematic, spatial and/or temporal attribute(s) of an entity. The entity type(s) that leads to the modification is linked by a modification relationship type to the entity type(s) whose entity(ies) is (are) updated, thus modelling the cause of the modification (Fig. 2). We identify several forms of evolution types that characterise migrations depending on the configuration of predecessor and successor entity types involved in the evolution. These configurations are defined as follows (note that the following configurations denote distinct roles of a same entity): 1. A single to single role migration type is a relationship type between one and only one predecessor entity type e1 and one and only one another successor entity type e2, e16¼e2 (e.g. a rural parcel becomes a commercial parcel); 2. A single to multiple roles migration type is a relationship between one and only one predecessor entity type e1 and a set of successor entity types {e2, . . ., en} with n > 2 (e.g. a rural parcel becomes both a commercial and industrial parcel);
Fig. 1. Migration.
232
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Fig. 2. Generation versus deletion versus attribute modification.
3. A multiple to single roles migration type is a relationship between a set of predecessor entity types {e1, . . ., en 1} and one successor entity type en with n > 2 (e.g. a parcel which is both rural and commercial becomes an industrial parcel only); 4. A multiple to multiple roles migration type is a relationship between a set of predecessor entity types {e1, . . ., en} and a set of successor entity types {en+1, . . ., en+m}, with {e1, . . ., en}6¼{en+1, . . ., en+m}, n > 1 and m > 1 (e.g. a parcel which is both rural and commercial becomes both an industrial and commercial parcel).
We propose a classification of the constraints that restrict the execution of an evolution as follows: 1. a pre-condition constraint models a constraint that applies before the execution of an evolution, 2. an exe-condition constraint represents a constraint that applies during the execution of an evolution, and 3. a post-condition constraint models a constraint that applies after the execution of an evolution. We define an evolution inventory, denoted evolution_inventory, as the set of evolution types whose semantics has an interest from the application point of view. On the other hand, the database designer can define constraints that restrict the set of possible evolution paths in the database graph. For instance, a legal constraint may restrict any further migration during a period of 10 years for parcels that have migrated from an entity type Rural into either entity types Commercial and/or Industrial. Moreover, in order to complete the explicit description of authorised versus unauthorised evolutions, we introduce an additional modelling concept. A set of unauthorised evolutions, denoted n_evolution, represents the set of evolution types that are unauthorised by the application semantics. This latter constraint is quite useful in legal or scientific applications for which the definition of unauthorised evolutions is often as important as permissible ones (note that we make a distinction between evolutions which are unauthorised from those which are not of interest from the application point of view).
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
233
Therefore, the complete set of evolution patterns is defined by the pair (evolution_inventory, n_evolution) and the constraints that limit the set of allowed sequences of evolutions. Any other evolution, that is neither listed in the evolution_inventory or n_evolution, is implicitly authorised (these evolutions do not present a modelling interest from an application point of view).
5. Database representation The following schema introduces a homogeneous structure for the representation of entity types, clusters, relationship types and evolution types. First, an entity type is defined as a n-tuple (name, supertypes, attributes, constraints): name represents the name of the entity type; supertypes describes the (possibly empty) set of entity types that are direct superclasses of the entity type; attributes represents the attributes of the entity type. attributes is defined as a set of pairs (att_name, att_type) where att_name is the name of the attribute and att_type its domain (i.e. primitive values, complex values using set, list and record constructors, or list of couples < value, valid time interval > for temporal attributes). For temporal entities, a specific attribute lifespan represents their life span (with a domain defined by a finite set of disjoint time intervals). For spatial entities, a specific attribute geometry represents their spatial extent (with a spatial domain chosen among the following ones: Point, Line, Area, PointSet, LineSet, . . .). constraints represents the set of constraints applicable to the entity type. A constraint is defined as a named Boolean expression whose variables are attributes of the entity type. To ensure the consistency of these constraints we define constraints as satisfiable, that is, there exists a non empty database for which all the constraints hold. Secondly, a cluster is defined as a n-tuple (name, supertype, subtypes, status, behaviour): name represents the name of the cluster; supertype describes an entity type which is the super-class of the cluster; subtypes describes a set of entity types that are direct sub-classes of the supertype; status describes the classification of entities in the sub-classes (i.e. an entity instance of the super-class must (can) belong at least (at most) to one sub-class. It is defined on a domain with four values total, exclusive, partition, and null when the cluster is neither total nor exclusive; behaviour describes the static versus dynamic quality of the cluster (i.e. authorisation to migrate between the sub-classes or not, respectively), defined on a domain with two values static and dynamic.
234
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Thirdly, a relationship type is defined as a n-tuple (name, role_entities, attributes, constraints): name represents the name of the relationship type; role_entities represents the set of edges linking the relationship type to the connected entity types. Each edge, called role, is defined by the linked entity type, the role name, and its cardinality. A role is mandatory if any occurrence of the entity type of the role must be linked by at least one occurrence of the relationship type, optional in the opposite case. A role is mono-valued if any occurrence of the entity type of the role may be linked by at most one occurrence of the relationship type, multi-valued in the opposite case. attributes represent the attributes of the relationship type in the same way as for entity types. attributes is defined as a set of pairs (att_name, att_type) where att_name is the name of the attribute and att_type its domain (i.e. primitive values, complex values using set, list and record constructors, or temporal values). An attribute lifespan represents the life span of a temporal relationship (with a domain defined by a finite set of disjoint time intervals); constraints represents the set of constraints applicable to the relationship type. A constraint is defined as a predicate whose variables are attributes of the linked entity types and relationship type. As for the entity type we define constraint as satisfiable. Finally, an evolution type is a peculiar type of relationship which can be either a migration, a deletion, a generation, a modification, or any combination of these. It is characterised as follows: role_entities groups three different sets of roles (or linked entity types): source roles that describe the entity types predecessor of the evolution, target roles that describe the entity types successor of the evolution, causal roles that describe the entity types that caused the evolution; attributes must contain an attribute lifespan that represents the life span of the evolution, defined by an atomic time interval domain; constraints represents the set of named constraints applicable to the evolution type. This set is divided into three subsets, pre, exe and post, that represent the set of pre-condition constraints, exe-condition constraints and post-condition constraints of the evolution type, respectively. The definition of these types supports the modelling of entities, clusters, relationships, and evolutions. The identity of an entity is managed at a system level and not represented explicitly within the entity type specification.
6. Application In order to illustrate the properties of our model, let us consider, as in Section 4, an illustrative case study in the context of a land-use database whose entities are
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
235
thematic, spatial and temporal (the semantics presented in the following examples has an illustration objective, not a search for realism). This application example includes the entity types Rural, Commercial, Industrial and Park. Due to environmental rules, a parcel Park cannot become any other kind of parcel; it is and will always stay as and only as a parcel Park. On the other hand a parcel which is not a park can freely change its type or gain a new type. For instance, a parcel Rural can become a parcel Commercial, then become a parcel Industrial. . .. There is only one exception to these free migrations: the application semantics prohibits a parcel Rural to become a parcel Industrial. The entity types Rural, Commercial, Industrial and Park are generalised into an entity type Parcel. The entity types Rural, Commercial and Industrial define a dynamic cluster, the entity type Park does not belong to this cluster as it has been previously constrained as static. Evolution types describe the dynamics of the application including constraints that restrict the range of these evolutions. For instance, an isolated deletion (resp. an appearance) of a parcel denotes a parcel that is transferred to (resp. taken from) the public domain as proposed in (Spery, Claramunt, & Libourel, 2001). A contraction (resp. an expansion) of a parcel denotes a part of a parcel that is transferred to (resp. taken from) the public domain. This reflects the fact that the public domain is not referenced in many cadastral systems (e.g. the French cadastral system). The set of non-evolutions defines the prohibited migrations (from Park to any other entity type, and from Rural to Industrial). Fig. 3 illustrates the schema of this application. Additional and self-explanatory constraints are presented within entity type specifications. The first specification of entity type concerns the entity type Parcel. ENTITY Parcel ATTRIBUTES:
CONSTRAINTS:
(LifeSpan: INTERVAL UNIT DAY, Geometry: POLYGON, Pnumber: INTEGER, Owner: STRING), (ParcelC1: CountHistory(self, 365) < 3, ParcelC2: area(self.Geometry) > 10)
END Parcel Aggregated constraints restrict evolution patterns that may affect some entities from the time they belong to an entity type. They are an example of pre-condition constraints. The earlier constraint example ParcelC1 restricts the number of migrations of an entity for a duration of time. This constraint is propagated backward in the lifecycle of the entities of this entity type. It is based on the identity of the entity. It is defined using a function CountHistory that returns the number of current and previous entity types of an entity for a specific duration of time (i.e. starting from now backward). The constraint ParcelC1 limits the number of migrations for any entity of entity type Parcel to a maximum of 2 during any duration of time of 365 days. A second constraint example ParcelC2 models the fact that an entity of type Parcel must have a minimal area. This constraint does apply for the generation of a new parcel and for a change of value of the spatial attribute Geometry. It is defined using a
236
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
Fig. 3. Application schema.
function Area that returns the area of a parcel entity. As previously mentioned, the notion of cluster allows us to define in which groups of sub-classes migrations are allowed or prohibited. For instance, the cluster CDyn groups the classes which are dynamic (Rural, Commercial and Industrial ). We can remark that the cluster Cdyn is not a total cluster as entities Park do not belong to this cluster. CLUSTER CDyn dynamic SUPER_ENTITY: SUB_ENTITIES: END CDyn
Parcel Rural, Commercial, Industrial
A second example of entity type, Rural, specialisation of the entity type Parcel, illustrates an entity type that includes a thematic constraint RuralC1 that restricts the domain of the attribute Culture. ENTITY Rural IS A Parcel ATTRIBUTES: (Culture: STRING), CONSTRAINTS: (RuralC1: self.Culture=‘‘Wheat’’ OR self.Culture= ‘‘Corn’’ OR self.Culture=‘‘Oat’’ OR self.Culture=‘‘Rice’’ OR self.Culture=‘‘Vineyard’’) END Rural A third example of entity type, Industrial, includes a spatial constraint IndustrialC1 that prohibits an industrial parcel from being adjacent to a rural parcel (defined with a Boolean function Adjacent that returns true if two spatial extents are topologically adjacent, false in the opposite case).
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
237
ENTITY Industrial IS A Parcel ATTRIBUTES: (Activity: STRING, RiskLevel: INTEGER), CONSTRAINTS: (IndustrialC1: Not Exist (Select r From r In Rural Where adjacent(self.Geometry, r.Geometry)) END Industrial The following example of entity type Commercial illustrates an entity type that includes a thematic and spatial constraint CommercialC1 that does not allow important commercial buildings to be adjacent to rural parcels. The constraint is specified by a conjunction of predicates that return true if there is at least one entity of entity type Commercial and of level of Activity 3, adjacent to an entity of entity type Rural, false on the contrary. ENTITY Commercial IS A Parcel ATTRIBUTES: (ActivityLevel: INTEGER), CONSTRAINTS: (CommercialC1: NotExist (Select r From r In Rural Where adjacent(self.Geometry, r.Geometry AND self.ActivityLevel=3)) END Commercial Finally the following examples illustrate the entity types Park and Surveyor (the entity type Surveyor is of interest for applications whose objective is to keep the references of the surveyor that materialised the parcel change). ENTITY Park IS A Parcel END Park ENTITY Surveyor ATTRIBUTES:
(Name: STRING, Address: STRING ),
END Surveyor The second category of examples concerns evolution types. We introduce two examples that illustrate the specification of predecessor and successor entity types and pre-, exe- and post-execution constraints. A first example describes a single role migration. The evolution type RuralToCommercial models a migration between the Entity type Rural and the entity type Commercial (a one to one relationship). A precondition constraint RtoCPre limits the domain of a predecessor entity of entity type Rural to entities with a maximal surface, and an exe-condition RtoCExe to migrations whose duration take less than 365 days. EVOLUTION RuralToCommercial CATEGORY MIGRATION, ROLE: (SOURCE: Rural [0,1] TARGET: Commercial [0,1]),
238
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
ATTRIBUTES:
CONSTRAINTS:
(LifeSpan: INTERVAL UNIT DAY, BuildingSociety: STRING, Architecture: STRING), (PRE: RtoCPre: area(self.SOURCE. Rural.Geometry) < 5000, EXE: RtoCExe: duration(self.Lifespan) < 365)
END RuralToCommercial A third example describes the evolution type RuralToCommercialAndIndustrial that models a single to multiple roles migration (we can remark that this migration does not correspond to a spatial process that splits the parcel into two new parcels, but to a functional migration that brings two new activities to an existing parcel whose spatial extent and idEntity are not changed). This evolution type models a relationship between the Entity type Rural and the Entity types Commercial and Industrial (ternary relationship). Self-explanatory constraints are also defined. EVOLUTION RuralToCommercialAndIndustrial CATEGORY MIGRATION, ROLE: (SOURCE: Rural [0,1], TARGET: Commercial [0,1], TARGET: Industrial [0,1]), ATTRIBUTES: (LifeSpan: INTERVAL UNIT DAY, BuildingSociety: STRING, Architecture: STRING, ToxicLevel: INTEGER), CONSTRAINTS: (PRE: RtoC&IPre: area(self.SOURCE.Rural. Geometry) < 10000, EXE: RtoC&IExe: duration(self.Lifespan)< 365, POST: RtoC&Ipost: self.TARGET.Commercial. ActivityLevel)6¼3) END RuralToCommercialAndIndustrial An evolution that models the expansion of the geometry of a Parcel is modelled as follows: EVOLUTION ParcelExpansion CATEGORY MODIFICATION, ROLE: (TARGET: Parcel [0,1], CAUSE: Surveyor [0,N]) ATTRIBUTES: (LifeSpan: INTERVAL UNIT DAY, Deed: STRING), CONSTRAINTS: (POST: PEPost: area(self.TARGET.NEW.Geometry) > area(self.TARGET.OLD.Geometry)) END ParcelExpansion
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
239
An evolution that describes the deletion of a Parcel is modelled as follows: EVOLUTION ParcelDeletion CATEGORY MODIFICATION, ROLE: CONSTRAINTS: END ParcelDeletion
(TARGET: Parcel [0,1], CAUSE: Surveyor [0,N] ), (PRE: PDPre: self.TARGET.Owner=NUL)
An evolution type that specialises an entity of type Parcel into an entity of type Rural is modelled as follows (single role migration). Similar evolution types can be defined for the entity types Commercial, Industrial and Park. EVOLUTION ParcelToRural CATEGORY MIGRATION, ROLE:
(SOURCE: Parcel [0,1], TARGET: Rural [0,1])
END ParcelToRural The evolution inventory describes the above set of authorised evolutions that present an interest from the application point of view: evolution_inventory=
(RuralToCommercial, RuralToCommercialAndIndustrial ParcelToRural, ParcelToCommercial, ParcelToIndustrial, ParcelToPark )
Finally, unauthorised evolutions that describe the prohibited migrations of the application can be defined as follows: n_evolution=
(MIGRATION Rural TO Industrial, MIGRATION Park TO Parcel, MIGRATION Park TO Rural, MIGRATION Park TO Industrial, MIGRATION Park TO Commercial)
7. Conclusion The representation of user-defined evolutions and constraints is an important requirement for the improvement of the semantics represented within databases. If some important progress have been recently made in the integration of the time
240
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
dimension within database models and on the representation of temporal constraints, the modelling and integration of user-defined evolutions and constraints are still an area that might be explored for the benefits of both legal and scientific applications. This paper proposes a description of evolution types and their constraints within a database schema. We make a distinction between several forms of evolutions: the migration of an entity between sub-classes, the generation (and deletion) of an entity, and the change of value(s) of an entity attribute(s). They allow the definition and management of evolution constraints at the database design level. We integrate these constraints as a component of a database schema in order to guarantee a monitoring of these constraints within the life cycle of a database application. Evolutions are modelled as a specific subset of relationship types. Evolution constraints are represented as pre-conditions, exe-conditions and post-conditions that restrict the execution of evolutions. An evolution inventory defines the set of authorised evolutions. Similarly, unauthorised evolutions can also be explicitly declared.
References Allen, J. F. (1984). Towards a general theory of actions and time. Artificial Intelligence, 23, 123–154. Bergamaschi, S., & Sartori, C. (1998). Chrono: a conceptual design framework for temporal entities. In T. W. Ling, S. Ram, & M. Lee (Eds.), Proceedings of the XVII International Conference on Conceptual Modelling (ER’98), LNCS 1507 (pp. 35–50). Singapore: Springer-Verlag. Bertino, E., Ferrari, E., & Guerrini, G. (1996). A formal temporal object-oriented data model. In P. M. G. Apers, M. Bouzeghoub, & G. Gardarin (Eds.), Proceedings of the Extended Database Technology Conference (EDBT’96), LNCS 1057 (pp. 342–356). Avignon: Springer-Verlag. Bertino, E., Ferrari, E., Guerrini, G., & Merlo, I. (1998). Extending the ODMG model with time. In E. Jul (Ed.), Proceedings of the 12th European Object-Oriented Programming Conference (ECOOP 98), LNCS 1445 (pp. 41–66). Brussels: Springer-Verlag. Claramunt, C., Parent, C., Spaccapietra, S., & The´riault, M. (1999). Database modelling for environmental and land use changes. In S. Geertman, S. Openshaw, & J. Stillwell (Eds.), Geographical information and planning: European perspectives (pp. 173–194). Berlin: Springer-Verlag. Claramunt, C., & The´riault, M. (1995). Managing time in GIS: an event-oriented approach. In J. Clifford, & A. Tuzhilin (Eds.), Recent advances on temporal databases (pp. 23–42). Zurich: Springer-Verlag. Clifford, J., & Croker, A. (1988). Objects in time. Data Engineering Bulletin, 11(4), 11–18. Cockfroft, S. A. (1997). Taxonomy of spatial data integrity constraints. Geoinformatica, 1(4), 327–343. Dong, G., & Li, Q. (1994). A framework for object migration in object-oriented databases. Data and Knowledge Engineering, 13(3), 221–242. Egenhofer, M. (1994). Pre-processing queries with spatial constraints. Photogrammetry Engineering and Remote Sensing, 60(6), 783–790. Elmasri, R., & Navathe, S. B. (1994). Fundamentals of database systems. Benjamin/Cummings. El-Sharkawi, M. E., & Kambayashi, Y. (1990). Object migration mechanisms to support updates in object-oriented databases. In N. Rishe, S. Navathe, & D. Tal (Eds.), Proceedings of the Parbase’90 International Conference on Databases, Parallel Architectures and their Applications (pp. 378–387). Miami Beach: IEEE-CS Press. Hadzilacos, T., & Tryfona, N. (1992). A model for expressing topological integrity constraints in geographic database. In A. U. Frank, I. Campari, & U. Formentini (Eds.), Theories and methods of spatiotemporal reasoning in geographic space (pp. 252–268). Berlin: Springer-Verlag. Hull, R., & King, R. (1987). Semantic data modelling: survey, applications and research issues. ACM Computing Surveys, 19(3), 201–260.
C. Claramunt, C. Parent / Comput., Environ. and Urban Systems 27 (2003) 225–241
241
Jensen, C. J., Soo, M. D., & Snodgrass, R. T. (1996). Unifying temporal models via a conceptual model. Information Systems, 19(7), 513–547. Maiocchi, R., & Pernici, B. (1991). Temporal data management systems: a comparative view. IEEE Transactions on Knowledge and Data Engineering, 3(4), 504–524. Radeke, E., & Scholl, M. H. (1994). Framework for object migration in federated database systems. In Proceedings of the 3rd Conference on Parallel and Distributed Information Systems (PDIS 94), Austin, Texas, September 28-30 (pp. 187–194). Austin: IEEE Computer Society. Spaccapietra, S., Parent, C., & Zimanyi, E. (1998). Modelling time from a conceptual perspective. In G. Gardarin, J. C. French, N. Pissinou, K. Makki, & L. Bouganin (Eds.), Proceedings of the International Conference on Information and Knowledge Management, CIKM’98 (pp. 332–340). Washington DC: ACM Press. Spery, L., Claramunt, C., & Libourel, T. (2001). A spatio-temporal model for lineage metadata. Geoinformatica, 5(1), 51–70. Su, J. (1997). Dynamic constraints and object migration. Theoretical Computer Sciences, 184(1–2), 195–236. Tauzovich, B. (1991). Toward temporal extensions to the entity-relationship model. In T. J. Teorey (Ed.), Proceedings of the 10th International Conference on the Entity-Relationship Approach (pp. 163–179). San Mateo: ER Institute. Tryfona, N., & Jensen, C. (1999). Conceptual data modelling for spatiotemporal applications. Geoinformatica, 3(3), 241–264. Zdonik, S. (1987). Object-oriented type evolution. In F. Bancilhon, & P. Buneman (Eds.), Advances in database programming languages (pp. 277–288). Roscoff: ACM Press/Addison Wesley.