Mapping an extended ER model to a spatial relational model. Areti Dilo

Transcription

1 Mapping an extended ER model to a spatial relational model Areti Dilo June 22, 2000

2 Abstract Observing that many spatial applications, quite often, need more complex spatial objects types than the basic ones points, lines, and areas this research is dedicated to identifying what are the most important and mostly needed spatial object types. A set of spatial elements is chosen to cover these needs and formalisation of them is given using topology and graph concepts. The formal specifications of spatial elements are refined into specifications of spatial data types, which can be used in conceptual modelling of spatial applications not only as data types for the spatial attributes of spatial objects, but also to set constraints in the objects class extension. Considering an extended (with specialisation, grouping, etc.) Entity-Relationship model and a nested relational data model, a set of rules is defined for the translation of a conceptual schema to a relational schema. 2

3 Acknowledgment I would like to express gratitude to The Netherlands Fellowship Programme for providing the fellowship for this study. Special thanks to my main supervisor, Dr. Rolf de By, for being patient with all my delays in the time schedule, and for clarifying the ideas every time I was feeling lost in all kinds of technical details. Thanks to all the ITC teachers who helped us to increase our knowledge. A lot of thanks to Angela, Tal, Nirvana, Füsun, Vahit, Romina and all our classmates for making nice the time we spent together. Special thanks to Milton, for his willingness to help with comments and answers to all my questions (small and important ones). My gratitude to Mohamed, for always being disposed to help with everything. Arta 3

4 Contents 1 Introduction General Problem Definition Research Questions Objectives Approach Structure of the Thesis Literature Review Formal methods The Z Notation Conceptual models for GIS Data Modelling Spatial Elements Graph notions Spatial Elements Zero-dimensional elements One-dimensional elements Two-dimensional elements Summary Logical Model Graph Design Schemas Spatial Data Types Mapping Rules Conclusions 64 A 66 A.1 Topology Concepts A.2 Z at work

5 List of Figures 2.1 Sort and Kind hierarchy of a spatial DB Graph hierarchy Extended Spatial ER Diagram Examples of line Examples of line collections Examples of planar line collections One-dimensional elements hierarchy The relation between one-dimensional elements and graphs Examples of region Examples of region collections Two-dimensional elements hierarchy A (partial) hierarchy of spatial data types

6 Chapter 1 Introduction 1.1 General Conceptual modelling offers important advantages compared to direct logical design modelling approaches. This is because users may express their knowledge about the application using concepts that are independent of computer terms (concepts). Another important reason is that the model is independent of the software tool with which the application will be implemented. It can also facilitate the understanding of the application model, being a model that is closer to a general way of thinking, not specific for the particular field of computer science. But, this brings the necessity of translating the conceptual schema to a logical schema, which is the basis for a real implementation in the computer software. The relational model is a firmly established data model, which is implemented in many commercial relational DBMS packages. The relational model is one of the three major data models that are currently used in commercially available DBMSs, the others two being the hierarchical model and the network model. The Entity-Relationship (ER) model is probably the most used conceptual model in the field of database design. The ER model accommodates a number of well-chosen primitives to define the information contents of the future database, in a format that is intuitively appealing to both specialists and non-specialists, and which also allows the downwards translation in the conceptual / logical / physical database schemas to obtain a representative relational database schema [8]. 1.2 Problem Definition What is missing in the spatial domain, is a conceptual model for spatial applications, that is accepted as a (kind of) standard. Previous work has been done in building conceptual models for spatial applications [11], [18], [14], and in formalising the models [13], [12], [7]. There is still place for a complete formalisation and separation of implementation issues from the conceptual ones ([7]), or for a more complete list of spatial elements needed in many spatial applications. Furthermore, (it seems) there is no work done in a formal 6

7 translation from a conceptual model to a logical representation of spatial data. Accepting the ER model as a good solution for the conceptual modelling phase of spatial database design, and an extensible DBMS based on the relational model, as the spatial database system, the aim of this research is to find a set of rules for mapping an extended ER diagram to the logical schema. A spatial database system deals with different kinds (approaches) of spatial data: the fieldbased approach, the object-based approach, fuzzy objects, etc. What will be considered in this research work is the object-based approach to spatial data. 1.3 Research Questions To help solving the raised problem, the following questions should be answered: What are the spatial elements that cover the spatial applications (considered here)? How can they be described formally? How can they be included (fitted) in the standard ER model? What is a proper implementation of spatial elements? What rules can be formulated for translating from the conceptual model to the logical model? 1.4 Objectives To reach the aim of the research, first a set of spatial elements will be defined, which cover the needs of (most of the) spatial applications. Then, the formal specification of these spatial elements will be given, and the role they play in the ER model will be defined. Accepting a non-first normal form as the data model of the target system (where the spatial data will be implemented), a concrete specification of spatial elements will be given, which is the basis of their implementation as (complex) data types in a relational database system. Considering the (data) structure of these spatial elements and some common (basic) relationships between them, a set of rules will be defined for translating from an ER diagram to a (database) relational schema. 1.5 Approach What will be done in this thesis work, in an ordered fashion, is the following: Defining the spatial elements that can be used to build a conceptual schema for spatial applications. 7

8 Looking at some commercial spatial database systems what spatial elements do they offer? Are these elements covering them? Finding a proper formalization of the spatial elements and defining their role in the ER model. Refining the formal specifications of the spatial elements into more concrete representations, which are closer to (computer) implementation. Defining rules for mapping from the extended ER model to the logical model. 1.6 Structure of the Thesis The thesis consists of five chapters. This chapter gave an introduction to the aim of this research, the objectives of the research and the approach followed. Chapter 2 will give a short introduction to Z, the formal language that will be used for the specifications in the coming chapters. Later in chapter 2 are resumed some of the papers dealing with spatial data modelling and data modelling in general. Chapter 3 is dedicated to the formalisation of spatial elements, and chapter 4 is refining the specifications given in chapter 3 in implementation schemas. It gives clues on how they can be used in modelling of spatial applications. Chapter 5 closes the thesis with some conclusions. 8

9 Chapter 2 Literature Review This chapter consists of three parts: Section 2.1 discusses the importance of formal methods in software engineering, section describes the Z Notation, which is a formal language used for formal specifications; Section 2.2 gives some ideas on what should be done for the application of formal methods in GIS, and describes work done in conceptual modelling of spatial applications; Section 2.3 resumes the ideas given in some papers written about data modelling. 2.1 Formal methods For many years, the software industry has been producing software, employing much effort in programming. But still, the vast majority of computer code is handcrafted from raw programming languages by artisans using techniques they neither measure nor are able to repeat consistently [9]. That brings the danger of having errors in the written code, for which there is no way of controlling except for testing the final software, and it also brings the risk of overwork of producing (probably different) code for the solution of similar problems. The first of them, testing the software, tells us only that there are bugs in the program (if testing is good enough to find some of them), but it can never prove that there are no bugs in the software. Putting the program design in algebraic forms, makes it possible to avoid serious mistakes, giving the possibility of controlling (proving) the correctness of program design. The second problem, duplication of written code, can be solved by first structuring the problem in small parts, writing code for each part, and then using the technology that supports interchangeability of software parts, to put together existing and (just) written code. Formal methods help in solving or decreasing those problems. They help in writing robust computer programs, because they provide for techniques of structuring the problem (the program is supposed to solve), and 9

10 an output that is concise, precise and unambiguous. They consist of: Formal specifications that tell what the system (solution of the problem) should do. Verified design that tells how the system is going to do the job. The methodology underlying formal methods is that one first specifies the behaviour of a piece of software, then that software is written and one proves whether or not that actual implementation meets its (formal) specification. This final aspect of formal methods is known as verified design. This term applies to the relation between a formal specification and the software component that is written to meet that specification. Clearly, we want the software component to satisfy its specification; proof techniques have been developed to enable someone to prove that a software component meets its specification [10]. To write formal specifications we use formal languages. The branches of mathematics mostly used in formal languages, are set theory and first-order logic. The formal language that will be used here is the Z notation, the ingredients of which are: some basic mathematical types (e.g., set, relation, etc.) and some operators defined on them. Other types can be defined using the basic types. The language provides tools for this. some more complex structures that are capable of carrying semantics (e.g., schemas) or defining rules or properties (e.g., axioms, general definitions). some mathematical laws, rules and proof methods (e.g., mathematical induction) that makes it possible to reason effectively about the way a specified system will behave. What is the output of formal methods in describing a system, using the Z notation? These methods define: States in which the system can be, and operations on states. Both can be described by Z schemas. The description of the system is given at an abstract level by abstract schemas and at a concrete level by concrete schemas, which are closer to computer concepts. Refinement is needed to show the correspondence between the two levels, abstract schemas and concrete ones. This is an orthogonal process to the system description levels (abstract, concrete and other that can be needed as intermediate) that has two parts: data refinement and operation refinement. Formal specifications are at a middle stage in the software life cycle. They come after writing the requirements document in a natural language (like English or Spanish), and before proceeding with the system implementation in a programming language. They are 10

11 not a replacement of the natural language description of the system, only a complement to it. For being concise and unambiguous they can serve as a reliable reference point for the persons who write the customer requirements, those who will implement the program, others that will test the results and also for writing the reference manuals of the system [9]. The next section will first describe a standard collection of mathematical symbols, then the features of the Z language, and, at the end, we will talk about data and function refinement. An example of the implementation of a Birthday Book will be presented to illustrate the use of Z. Some definitions needed for it will be in given in this section, and a more complete solution is given in Appendix A.2. 1 This example shows how schema calculus can be used to modularise a specification and how data refinement is used to relate specifications and designs The Z Notation One of the key ideas of Z is that the specification and implementation should be kept separate. The specification should precisely state what the eventual piece of software should do and not how it is to go about achieving its task. Separating specifications and implementations results in a separation of the often conflicting task of correctly solving the problem in hand and that of building an efficient piece of software. Something that is important to realise is that writing a formal specification is quite different from writing a computer program [10]. A Z specification is a combination of mathematical language statements that strictly define or prove system properties, and natural language statements that describe what is said or done by the mathematics used. Basic Notions Some of the mathematical concepts used in the Z language are sets (special sets offered by Z are naturals denoted by, integers denoted by ), bags, sequences, relations, functions, etc. Built upon those are other concepts like Cartesian product (X Y of X and Y ); the power set (denoted by X, which is the set of all subsets of X ); finiteness applicable to sets (denoted by X, which is the set of finite subsets of X ), and the # operator for the number of elements in a finite set; the nonemptiness concept that is applicable to sets, bags, sequences (e.g seq 1 X is the set of nonempty finite sequences on X ), functions, etc. Definition, properties and operations on some of these will be given below (taken from [9]). Relations A relation R from (the set) X to (the set) Y is a set of pairs (x, y) where x X and y Y, thus R X Y. The element (x, y) R can also be written as x y R. X Y denotes the set of all relations between X and Y. 1 The example and its solution is taken from [22]. 11

12 The domain of a relation R is that subset of X, for which each element is related (by R) to at least one element of Y. Its definition in Z is dom R = {x X ; y Y x y R x} The range of a relation R is that subset of Y, for which each element is related to at least one element of X. Its definition in Z is ran R = {x X ; y Y x y R y} Domain restriction (over A X ) is again a relation: all the pairs of R, which first members are elements of A. Its definition in Z is A R = {x X ; y Y x y R x A x y} Range restriction (over B Y ) is a relation that has all the pairs of R, which second members are elements of B. The definition in Z is R B = {x X ; y Y x y R y B x y} Domain co-restriction (over A) is a relation that has all the pairs of R, which first members are not elements of A. (Range co-restriction is defined in an analogous way.) A R = {x X ; y Y x y R x / A x y} The inverse of R is a relation R : Y X that is defined from R R = {x X ; y Y x y R y x} The identity relation is id X = {x : X x x} The relational composition of R : X Y and S : Y Z is R S = {x X ; y Y ; z Z x y R y z S x z} The backward composition With the above definitions of R and S: S R = R S Overriding If R, S : X #Y then R S is a relation that agrees with R everywhere outside the domain of S, but agrees with S where S is defined: R S = (dom S R) S Relational image If R : X # Y and A X, then RA = ran(a R) is the relational image of A through R. Functions A partial function from X, called source, to Y, the target, is a relation that maps elements of X to at most one element of Y. The set of all partial functions from X to Y is 2 X Y == {f : X # Y x X ; y1, y2 Y 2 see Abbreviations in next subsection x y 1 f x y 2 f y 1 = y 2 } 12

13 A total function is a partial function in which each element of the source is mapped to exactly one element of the target. The set of all total functions from X to Y is X " Y == {f : X Y dom f = X } If x y f then y is denoted as f (x). All operations defined on relations are also valid on functions (as they are relations with some specific properties). Some properties of functions are: Injections If each element of the domain is mapped to a different element of the target, then the function is said to be injective. There are partial injective functions, which symbol is, and total injective functions, which symbol is. Surjections If the range of the function is the whole target, the function is said to be surjective. Partial surjections have the symbol, total surjections have the symbol. Bijections A function that is both surjective and injective is called bijective. The symbol for bijection is. Finite functions are defined as X Y == {f : X Y dom f X } Sequences A sequence is an ordered collection of objects (it can be empty), e.g., a, c, f, d, c is a sequence. If X is a set, then the set of all finite sequences of objects from X is defined by seq X == {s : X n dom s = 1.. n} where 1.. n = {i 1 i n}. Some operations on sequences are: Concatenation If s, t seq X, then s t seq X denotes the concatenation of s and t, i.e., adds t at the end of s. Head and Tail if s seq 1 X, then head s is the first element of s, and tail s is the remaining part. Length If s seq X, then #s denotes the length of s, that is the largest integer for which the associated partial function is defined. Bags A bag is an unordered collection of objects in which the multiplicities are important, e.g., a, c, f, d, c is a bag, which is the same as a, c, c, d, f. If X is a set, then the set of all bags with elements from X is defined as bag X == X 1 ( 1 = \ {0}) The number of times an element x : X appears in a bag B : bag X is count B x (B x is another notation). The fact that an element x : X is in the bag B is denoted by x B, and the following equivalences are true: x : X ; B : bag X x B x dom B and x B B x > 0 13

14 Definitions To illustrate definitions, for which syntax will be given here, we will use examples from the Birthday Book. (The Birthday Book is a system that records people s birthdays, allowing us to add new people and their birthdays, and ask for birthdays of people that are already in the book.) A definition can be one of the following: A declaration that introduces a new type or new variable of an existing or previously declared type. We will need a type NAME for names of persons, and a type DATE for their birthdays in our Birthday Book. To declare them we write: [NAME, DATE] To declare a variable that holds the names of persons with birthdays recorded (thus known is a set of names), we state known : NAME An abbreviation introduces a new name for some expression. It is of the form symbol == expression e.g., Month == {Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec} or of a generic form, which introduces a family of symbols: symbol parameter == expression e.g., the empty set is a subset of every set. In a set X it is defined as [X ] == {x : X false} Because the predicate part on the right side is always false, there is no element x : X that can satisfy it. An axiom gives an everlasting property (truth). It is of the form: x : X P(x) or of a generic form, based on a type (or some types), e.g., the definition of projection functions for ordered pairs: [X, Y ] first : X Y " X second : X Y " X x : X ; y : Y first(x, y) = x second(x, y) = y 14

15 A free type In our example of Birthday Book, we will look for the birthday of a person, and it can be that the person is not yet in our book. For this special case (and probably others) it is good to have a variable result that tells us what is the situation. The type of this variable can be a free type, REPORT, for which the declaration is: REPORT ::= ok already known not known If we declare then the variable result : REPORT, that variable can assume just three values: ok, already known, not known The notation for free type definitions adds nothing to the power of Z language, but it makes it easier to describe recursive structures such as lists and trees [22]. Schemas, of which the definition has a name, a declaration part, and a predicate part. A schema is used to describe state information, operations on states, and initialisation. To describe the state space of our system, Birthday Book, we write the schema: BirthdayBook known : NAME birthday : NAME DATE known = dom birthday Here birthday is a function which, when applied to a certain name (that is an element of the set known), gives the birthday associated with that name. The declaration of a schema can also look like (called a horizontal schema): Schema Name = [declaration predicate] A schema can also be defined in terms of its signature and its property. The signature introduces the schema variables together with their types. A declaration is a signature together with implicit predicates. The property constrains the variables and describes the relationship between them. The property includes the explicit predicate below the line, and any implicit predicates concealed within the types used in the declaration. The schema property is also called the schema invariant. The relationship known = dom birthday in the BirthdayBook schema is an invariant of the system. A schema may be used wherever a declaration is expected. It may be used as a predicate, and also it may be used as a type, in the same way as mathematical types. A schema S represents a set, the set of all its bindings. A binding is an assignment of values to a schema s components such that they obey its predicate. If a variable is declared with a schema type s : S, then the variable s value is one of these bindings. This is exactly the same as saying if a variable is declared x :, then x has the value of one of the members of. A schema binding is denoted by θs, S being the schema name [3]. 15

16 Schemas may be composed, using schema calculus (schema operators), to form specification of new states and operations. This has two benefits: the operations can be broken into small parts that are more easily understood, extensive reuse of schemas becomes possible. Schema Operators are decoration (which symbol is ), conjunction ( ), disjunction ( ), negation ( ), quantification ( - for all, - exists, 1 - exists only one), hiding (\), composition (), and precondition (the symbol is pre ). We use decoration to indicate the after variables of an operation, where the before variables are undecorated [3] e.g., known is the state of known after adding another person in the Birthday Book (that results in adding another name to the set known). Using decoration we can define some common schemas, the Delta ( ) schema and Xi (Ξ) schema that we will use in our example later. BirthdayBook = BirthdayBook BirthdayBook The is part of the name of the schema and is used to indicate change of state [3]. ΞBirthdayBook BirthdayBook θbirthdaybook = θbirthdaybook The Ξ is part of the schema name and is used to indicate no change of state [3], i.e., the values of BirthdayBook s components are the same before and after the operation. Examples of conjunction, disjunction, and quantification will be given later. To show how hiding works, let us take the schema S S = [x : X ; y : Y P] S \ (x) (read S hiding x) is the schema: S \ (x) = [y : Y x : X P] The operation pre is applied to operation schemas. The precondition of an operation is a schema that characterises the collection of before states for which some after states can be shown to exist [9]. The precondition of an operation can be calculated. The purpose of the precondition calculation is to check that the operation is valid. There must be at least one before state in which the operation is applicable. If there is an inconsistency in the definition, the precondition is false, and hence there are no appropriate before states. So, in a precondition calculation the aim is to determine what must be true of the before state and the operation inputs to achieve a satisfactory outcome. This is done by hiding the outputs and after variables [3]. pre Operation = State Operation \ outputs 16

17 Refinement The meaning of refinement is to make more concrete. Refinement is the process of turning a more abstract specification into a more concrete one [3]. Typically refinement is performed in a number of steps, in which we move gradually towards the concrete design of the system, proving in each step that the lower level (the more concrete one) is a correct representation of the higher level (the more abstract one), from which it is derived. What we get at the end of the refinement process is a system design that is closer to the level of the programming language. Efficiency issues, the space/time trade-off, should be taken into consideration in the system design. Refinement has two parts, data refinement and function (operation) refinement. Data Refinement [3] In data refinement, the abstract data type in the abstract specification is related to the concrete data type in the concrete specification (design). This is done by means of a retrieve schema that shows the relationship between the abstract and the concrete state items in logical terms. This relationship allows us to retrieve the abstract state from the concrete one. Function Refinement [3] In moving toward a more concrete description of the system, the operations change from describing the what of the operation to the how. To be able to demonstrate the refinement, we have to show the following: Correct initial concrete state. Each possible initial concrete state (subscript c) must represent a possible initial abstract state (subscript a). The concrete version should not allow starting points that the abstract specification forbids. State c Init c State a Init a Retrieve Correct operation refinement. Whenever the abstract operation terminates, so should the concrete operation. In other words, if we are in a state in which the abstract operation is guaranteed to terminate and we apply the retrieve relation, we will be in a state in which the concrete operation is guaranteed to terminate. State a ; State c pre Op a Retrieve pre Op c Correct concrete operation. If the abstract operation terminates, then so should the concrete one and the state in which the concrete operation terminates should represent a possible abstract state in which the abstract operation could terminate. In other words, we can either start in the precondition of the abstract operation, perform the retrieve operation to reach the concrete state and then perform the concrete operation, or we can first perform the abstract operation and then apply the retrieve relation. State a ; State c ; State c preop a Retrieve Op c State a Op a Retrieve 17

18 2.2 Conceptual models for GIS What should be done for the application of formal methods to GIS are: Choice of an ontology, Choice of paradigm of formalisation, and Choice of formal languages and reasoning techniques [4]. Finite and discrete representations of infinite and continuous domains are achieved by means of abstraction and discretisation. One way of representing infinite and continuous domains of individuals is to represent classes of individuals rather than individuals. Individuals in the same class are considered to be equivalent. Equivalence classes of individuals partition the domain of individuals. The difficult problem is to define the classes of equivalence in such a way that the structural properties of the original domain of individuals are preserved. This can be achieved if structures that govern the domain of individuals are used to define the classes of equivalent individuals [4]. Such kind of structures can be achieved by : The geometric paradigm of formalisation which define the equivalence based on properties and relations that remain invariant under particular classes of transformations; The analytic paradigm of formalisation defines the equivalence based on relation of order with respect to a frame of reference; The qualitative paradigm of formalisation is based on landmark values (individuals which represent significant changes) and order relations between them which qualitatively structure the domain. Often more than one paradigm of formalisation is used depending on the structural properties of the class of intended model [4]. Until the beginning of the last century, Euclidean geometry was the only form of geometry. Then hyperbolic, or Lobachevskian geometry, and elliptic, or Riemannian geometry were constructed. As more than one geometric theory was designed, the problem became the determination of what made a theory of space a geometry. What is the essence of geometry? Geometry abstracts from particular location and considers properties of geometric figures that are independent of particular location, i.e., invariant under a certain group of transformations. Geometric figures are equivalence classes of geometric individuals or configurations of geometric individuals that can be made to coincide by transformations belonging to such a group (e.g., triangles, configurations of triangles, polygons, configurations of polygons). Transformations are operations on geometric individuals that change certain properties and leave others invariant [5]. For example, Euclidean geometry deals with properties such as the length of a line, the sizes of angles, etc., all of which remain unchanged under the transformations of rotations and translations. This definition of geometry also includes areas of mathematics such as graph theory and topology, which have a geometric component. Typically each group of transformations defines a set of properties that remain invariant and thus creates a geometry that can be formally defined and studied [16]. Location is a relation between spatial individuals and a frame of reference. Location within a frame of reference allows abstracting from individuals using equivalence classes with respect to identity of location. Individuals that have the same location in a particular frame of reference, form an equivalence class. An important issue is to evaluate which 18

19 geometric properties of the domain of individuals are preserved in the domain of equivalence classes of individuals with respect to location [5]. Geometry can be represented in terms of locations in R n. Analytical geometry is a mathematical theory of geometric properties of sets of points based on finite representations of their locations in a frame of reference given by a system of n axes of directed real lines and the corresponding coordinate space R n [5]. In [15], spatial objects are represented by inequalities, and the paper argues about advantages and disadvantages of linear constraints representation compared to a pointer-based vector representation in terms of storage and processing time of operations. In [14], [20], [21], [23], [24] space is modelled as a subset of R 2 and the objects defined on that space are zero-, one- and two-dimensional. They consider different levels of granularity (different scales) for the objects in a single conceptual schema element, i.e., a land parcel can be seen as a point or a region, dependent on the current scale of the application. So, a land parcel object can be a point or region, zero or two dimensional object. Spatial objects have a position in space that is made up of four components: Shape is one of the four components, which fully and non redundantly define position: the others are size, orientation and centroid [20]. Spatial objects have descriptive attributes and spatial attributes. Spatial attributes are properties of the embedding space that indirectly become properties of the spatial objects via their position in space, i.e., the spatial objects inherit them from space. The spatial attributes of objects may be captured independently of the objects using so-called fields (called also layers). Layers are one of two types: those that are continuous functions, e.g., temperature, or erosion, and those that are discrete functions, e.g., county division represented as regions [24]. It is frequently necessary to capture the position of spatial objects in the database. The first step to support this is to provide means for representing the space in which the objects are embedded. The next is to provide means for indicating that the objects position in this space is to be captured. For this purpose the following special entity and relationship sets are introduced. The special entity sets SPACE, GEOMETRY, POINT, LINE, REGION. Entity set GEOMETRY captures the geometrical position of the entity set and can be POINT, LINE, REGION, or any other geometric type (or geometry). The special relationship set is located at that associates a spatial entity set with its geometry. The cardinality of this set is 1:M because a spatial entity may have more than one geometry when multiple granularities are employed. The relationship set belongs to between GEOMETRY and SPACE with cardinality M:1 is also included. The spatial attributes of entities are calculated via the relationship belongs to [24]. MADS, as described in [18] and [19], is a conceptual model for spatial data. MADS offers a set of spatial abstract types, organised in a generalisation hierarchy. This hierarchy can be changed according to the needs of the application, by creating new subtypes, or grouping 19

20 some existing types into a new supertype. With every spatial type are associated some methods that permit to define and manipulate instances of that type. The most general type is Geo; its subtypes are Simple Geo and Complex Geo. Subtypes of Simple Geo are Point, Line, Simple Area. The type Line is a subtype of Oriented Line type. Subtypes of Complex Geo are Point Set, Line Set, and Complex Area. Line Set is a subtype of Oriented Line Set. If an object type has type Geo, the precise type of every instance will be defined at the moment of its creation. The spatiality of an object is described by a predefined attribute, geometry that is a grouping of shape (e.g., Point, Line, Area, or Simple Geo) and location that can be given in absolute coordinates or relative to other known locations. The domain of values of geometry is one of the spatial abstract types given above. An element can be described as a spatial object or a spatial attribute, depending on the application. A spatial attribute is a simple attribute, single-valued or multivalued, derived or not, whose domain is a spatial abstract type. Spatial integrity constraints may be associated with spatial entities or spatial attributes. A spatial relationship may be of different types, e.g., topological, orientation, metrical, or spatial aggregation. Spatial relationships can be deduced from the spatiality of objects, thus, these relationships implicitly exist and are accessible through GIS functions. But, in MADS it is possible to define them explicitly, giving the possibility to attach to them attributes or methods, or to give them a special semantics, complementing the semantics they have from GIS functions. MADS provides topological relationships and spatial aggregation. Any other spatial relationship type may be explicitly declared with the methods attached to the spatial abstract types. The predefined relationship types in MADS are: disjunction, adjacency, crossing, overlapping, inclusion, and equality. Aggregation can be spatial or thematic. It is a binary link directed from the composite to the component object. An object type composed of several object types is represented using several aggregation links, one for each component type. It is common that some attributes of the composite and component objects are related. These dependencies are represented either by derived attributes, or by integrity constraints. Generalisation links may relate to spatial or non-spatial object types. Inheritance can be adjusted by using either refinement or redefinition. Refinement is useful each time a property of an object (thematic attribute or geometry) has a smaller domain in a subtype than in a supertype. Redefining an inherited attribute aims at a different objective. Redefinition creates a new attribute in the subtype, with the same name. Thus, redefinition of geometry makes it possible to associate different geometries to the same object. This can be used for multiple representations. Multiple inheritance is another kind of generalisation link that solves the problem of sharing the same object by several object types [18]. Spatial partitions are discussed in [12]. Partitions are a central spatial concept to organise our perception of understanding the space. They enable us to consider the attributes of single points (space-based view), they also provide access to collections of points having equal attributes (object-based view). Thus, the model closes the gap between these two views of the space. In set theory, a partition is a complete decomposition of a set S into non-empty, disjoint 20

21 subsets {S i i I }, called blocks. A partition can be seen as a total surjective function π : S I. A spatial partition can be defined as a set-theoretic partition of the plane, or as a function π : R 2 I. From an application point of view, different blocks of a spatial partition are marked (labelled). Thus, a partition model should consider point sets together with the associated values. The set of values that are used for labelling in a specific partition, define in a way the type of partition. The spatial partition of a type A are functions of type π : R 2 A, where A in contrast to I has some semantics. To ensure that π is a total function, an assumption is that every label type A contains an element A (called undefined or unknown), and the outside area of a partition is labelled by A. Blocks of a spatial partition are called regions. Regions that actually appear in application are regular, without cuts or punctures, and without isolated points or lines. So, the interior of regions of a partition is required to be a regular open set. Since points in the boundary cannot be assigned uniquely to either adjacent regions, they are mapped to the set of values given by the labels of all their adjacent regions. The definition of spatial partitions is given in two steps. First, a spatial mapping of type A is defined as a total mapping π : R 2 " A A. The range of a spatial mapping π is the set of labels actually used by π and is denoted by range(π). The blocks of a spatial mapping π are maximal point sets that are mapped to the same value. (If f : X " A then a A f 1 (a) = {x X f (x) = a}. When f 1 is applied to a set it yields a set of sets.) The common label of a block b of π is denoted by π[b], that is π(b) = {l} π[b] = l. The cardinality of block labels identifies different parts of a partition: the interior and the boundary. A region of π is any block of π that is mapped to a single element of A, and a border of π is given by a block that is mapped to a set of A-values. The interior of π is the union of all its regions, and the boundary of π is the union of all its border blocks. Let π be a spatial mapping of type A, then ρ(π) := π 1 (range(π) A) are the regions of the partition, and β(π) := π 1 (range(π) A) are the borders. Then a spatial partition is defined by topologically constraining regions to regular point sets and by semantically constraining boundary labels to those of adjacent regions. Thus, a spatial partition of type A is a spatial mapping π of type A, such that r ρ(π) : r is a regular point set, and b β(π) : π[b] = {π[r] r ρ(π) b r} The set of all spatial partitions of type A is denoted by [A], and it is [A] R 2 " A A. The partition boundary can be seen as an undirected planar graph. From this point of view, using the cardinality of border labels, they can be discriminated further: an edge block is mapped to a two element subset of A and defines a border curve between two regions. A vertex block is mapped to a subset of A with three or more elements; a vertex block is a singleton point set and describes location where more than two regions of a partition meet [12]. Three basic operators on partitions: Intersection, Relabel, Refine, are formally defined in [12] and it is shown that operations that arise generally in spatial analysis, cartography, 21

22 etc. such as overlay, reclassify, merge, cover, clipping, can be realised by these three basic operators. Spatial types, together with some Base, Time, Temporal and Range types are introduced in [13]. The spatial types, used in the design of wider spatio-temporal types, are point, points as finite sets of points, line as finite sets of curves that intersect each other only at their ends, region as regular point sets. A curve is given as the range of a continuous function from a closed interval in R to R 2, it is not self-intersecting, but can be looped, and a condition for the uniqueness of representation of the curve by the function is given. In the geometry object model of [7] a GeometryCollection is an object type that is a collection of one or more geometric types. Subtypes of it are Point, MultiPoint as the type of finite collections of points; Curve is given as the homeomorphic image of a closed real interval, and it can be simple the line is not self-intersecting and looped the begin and end of line are the same point (but the homeomorphism excludes the looped curve); LineString is a curve obtained by linear interpolation between its representing points, Line as line strings with exactly two points, LineRing as simple looped curves; a MultiCurve is a collection of curves and a subtype of it is MultiLineString; a Surface can be threedimensional as well as planar surface; A Polygon is a planar surface that is a regular closed set, its interior is a connected set, its frontier consists of a set of linear rings; MultiSurface is a collection of surfaces, and Multipolygon is a collection of polygons that can intersect each other only in a finite set of points from their frontiers. 2.3 Data Modelling The IFO model described in [1] is a formal semantic database model, which primary focus is on the structural component of the data model (the other components being data manipulation and the integrity specification component). Four fundamental principles of semantic database modelling are identified. The most basic is that data about objects and relationships between them should be modelled in a direct manner. As first introduced by the Entity-Relationship model, such object-based modelling allows database designers and users to think in terms of objects without the indirection resulting from the symbolic identifiers necessitated by records and pointers. As highlighted in the Functional Data Model (FDM), a second basic perception of semantic modelling is that many (if not most) of the relationships recorded in a database are functional in nature. A third basic perception is the significance of the so-called ISA relationships, which specify the fact that one set of objects must be a subset of another set of objects. The final perception of semantic data modelling is to provide a hierarchical mechanism for building object types out of other object types, like aggregation and grouping. The IFO model is a mathematically defined database model that incorporates the four principles within a coherent, graph-based representational framework. The presentation of the model is done in four steps. First types are introduced that model the structure of objects arising in database applications. Second, fragments are built from types, and are 22

23 used to represent functional relationships in the IFO model. Third, it is described how ISA relationships between various objects of the schema are incorporated. Finally, all the pieces are put together to form IFO schemas. Types can be atomic or nonatomic and they are defined as tree structures. There are three kind of atomic types: printable types are predefined types like STRING, INTEGER, BOOLEAN, PICTURE, etc.; abstract types correspond to objects in the world that have no underlying structure, relative to the point of view of the application, e.g., the type PERSON is a typical one; free types correspond intuitively to entities obtained via an ISA relationship, e.g., STUDENTs are a subclass of PERSONs, and STUDENT is a free type. Nonatomic types are built from the previous ones using two mechanisms: collection or grouping that are finite set of objects, which are represented by star-vertices ( -vertex) in the IFO schema. If m 0 and O 1,..., O m are objects, then {O 1,..., O m } is a set object; aggregation or composition is a Cartesian product and is represented by cross-vertices ( -vertex). If n > 0 and O 1,..., O n are objects, then [O 1,..., O n ] is a tuple object. The two constructs corresponding to star and cross vertices can be applied recursively in any order. Fragments are used to represent functional relationships, but differently from the FDM in the IFO model a distinction is made between vertices serving the role of domain and those serving the role of range. Another difference is that nested functions can be modelled in the IFO model (but not in FDM). An ISA Relationship from a type SUB to a type SUPER indicates that each object associated with SUB is associated with the type SUPER, and functions of SUPER are inherited by SUB. Two types of ISA relationships are distinguished in an IFO model: specialisation and generalisation. Specialisation can be used to define possible roles from members of a given type, e.g., subtypes EMPLOYEE and STUDENT are specialisations of PERSON. An object may change such roles without changing its underlying or fundamental identity. A generalisation represents situations where distinct, pre-existing types are combined to form new virtual types, e.g., types CAR and MOTOR-BOAT can be combined to form VEHICLE. In such situations it is not allowed for an object of one subtype to migrate into another subtype. Also, it is common to require that a generalised supertype be covered by its subtypes. Two simple constraints on ISA relationships can be incorporated into IFO schemas: subtypes forming a generalised type can be forced to be disjoint, and specialisations of a supertype can be asked to cover the supertype. IFO Schemas can be built in a top-down design fashion, beginning with the specification of the major object types arising in the application environment, then specifying subsidiary object types, either constructed or defined as sub- or supertypes, and finally specifying the functions of all object types of the schema. Five rules are put on ISA relationships of an IFO schema. To characterise very precisely the types occurring locally in a schema instance the concept of derived type is introduced. The derived types are a family of tree structures that start with basic types (printable and abstract), and permit the application of three constructs, and, which represent aggregation, grouping, and generalisation. The type T formed 23

24 from of two types T 1 and T 2 will have a domain equal to the union of domains of T 1 and T 2. An order relation and an equivalence relation are defined on the derived types. The paper also focuses on the semantics of updates in the IFO model. In particular, it allows to carefully examine the different ways that a modification of the data associated with one part of a database schema can affect data associated with other parts of the schema. A fundamental observation was that local update semantics can be specified separately for each construct of the model, and then combined in a natural manner to form a well-defined global semantics [1]. The spatial data model described in [11] is an integration of functional data modelling concepts with order-sorted algebras. The novelties of this model are the modelling and querying of networks and heterogeneous collections of spatial objects. Graphs are used for modelling networks, but they are also presented as a modelling tool to describe relationships between objects, thus making available all the efficient graph algorithms in data queries. They use a multilevel order-sorted algebra to put all the concepts they introduce and describe in a common formalism. The classical relational algebra is a one-sorted algebra, its domain being a set of relations, having a collection of operations (functions like join, project) defined on this domain. A many-sorted algebra provides for a well-structured type system and integration of arithmetic or aggregate functions, and generally ADT functions. Order-sorted algebra allows for subtype hierarchies and inheritance, by means of a partial order on algebra sets (sort carriers), which implies that functions defined on one set can be applied to elements of a subset. The model describes complex object types that are built from simpler ones by means of type constructors that can not be described by means of a one-level algebra. The model supports polymorphic functions, and this polymorphism can not be modelled by only one level of algebra. To have the parametric polymorphism it is needed to have sets of types in which to define the (polymorphic) function, and this is realised by kinds that are simply sets of types (sorts of the first level). The first level algebra describes basic types that are the sorts of this algebra, and operations on sorts. The second level algebra describes kinds, which carriers are sets of sorts of the first level algebra. Operations of the second-level algebra are the type constructors, their associated functions are mappings between kinds, i.e., they map one or more sorts of one kind to a sort of another kind. This second level is called kind algebra. The types gained from applying type constructors of the second level, are then used at the first level. A third-level algebra is mentioned (called class algebra) to introduce some operations on complex (structured) types. The data model is developed in three steps, by introducing first the data types, then the object types, and finally the structures. Data types are a collection of standard data types BOOL, STR, INT, REAL as well as the geometric types POINT, LINE, REG and some other types shown in figure 2.1.a that gives the sort hierarchy. Standard and geometric types are the basic data types (sorts), and are the leaves of the tree in the sort hierarchy. The notation is used to refer to the domain of a type (carrier set of the sort), e.g., INT denotes the carrier set of sort INT. The carrier of the internal nodes is defined to be the union of the carriers of children, e.g., NUM = INT REAL. 24