360 likes | 730 Views
Conceptual Modeling of Geographic Databases - Emphasis on Relationships among Geographic Databases. Anders Friis-Christensen National Survey and Cadastre. Outline. Geographic data Conceptual foundation Conceptual modeling What and why Modeling geographic data
E N D
Conceptual Modeling of Geographic Databases - Emphasis on Relationships among Geographic Databases Anders Friis-Christensen National Survey and Cadastre
Outline • Geographic data • Conceptual foundation • Conceptual modeling • What and why • Modeling geographic data • Modeling multiple representations • Summary
Geographic data (1) • Data where spatial and temporal aspects are important for the intended applications • Applications: • The spatial aspects appear as regions, lines, and points, and changes occur discretely across time • Topographic, cadastral, and network applications • The continuously changing spatial aspects • Environmental applications and location-based services
Geographic data (2) • A geographic object has: • A spatial attribute value, which specifies the location in space • Its data type can be, e.g., a polygon or a point • Thematic attribute values, which specify thematic properties • Any data type (non-spatial data types) • Temporal attribute values, which specify temporal properties: • Valid time, vt, which specifies when something is valid. E.g., the color of a building was white from 1991-2000 • Existence time, et, which specifies when something exists. E.g., a building has existed from 1900-present • Transaction time, tt, which specifies when something is being recorded as current in a database. E.g., in Aug. 2000 we record that John Doe was the owner of a building from Mar. 2000 to present. tt is (Aug, 2000, today), vt (Mar, 2000, today)
Geographic data (3) • Associations among geographic objects: • Topological, e.g., that an address point is inside a building • Metric, e.g., that a building is less than 10 meters from a road • Part-whole associations, e.g., that a county consist of several municipalities • Constraints on geographic objects: • Constraints on objects. E.g., the size of an building may not be smaller than 25 sqm • Constraints on associations. Eg., one object should be inside another • Most model elements imply constraints, e.g., the data type of attributes
Conceptual Data Models (1) • The idealization of the world to be described • A way to organize and structure data • Common conceptual data models can: • Support an Infrastructure for Geographic data, e.g., based on the work by ISO TC211 • Support reuse of solutions and designs (design patterns) • Solve the problem of interoperability (exchange and querying of data) • Give a clear overview and understanding of a given application (non-technical) • Be used as a language between users, domain experts and developers • Be modified and maintained easily • Be used as a documenting tool
Conceptual Data Models (2) • Conceptual data models describe: • Object classes and their properties • Associations among object classes • Possible constraints on objects and attribute values • Conceptual data models are: • Independent of later implementation • Conceptual modeling notations: • Entity Relationship Model (E/R) • The Unified Modeling Language (UML)
System’s Development Context Universe of Discourse Requirements Conceptual Data Modeling Conceptual Schema DBMS- independent Data Model Mapping DBMS- specific Logical Schema Physical Design Internal Schema
Example • An example in UML:
Modeling Approaches (1) • It is instructive to distinguish between two different approaches to providing better support for conceptual modeling of geographic data • One approach is to extend the base notation • Spatio-temporal concepts are given special syntax • This makes for more compact diagrams • The modeling notation becomes more complex • Another approach is to not extend base notation • With this approach, a library of generic diagrams is offered • “Patterns” can be identified • Diagrams remain complex • Existing design and transformation tools are applicable
Stereotypes: • Are used to define new semantics to existing model elements • Notation: <<stereotype>> or as an icon • Example: Modeling Approaches (2) • One sub-approach of the extension approach is to introduce spatio-temporal annotations into the base notation: • In UML, which is extensible, stereotypes may be defined • A two-step design process can been advocated for the annotation approach: • First, a diagram is designed that models the universe of discourse without taking into account the spatial and temporal aspects of the universe of discourse • Second, the diagram resulting from the first step is annotated with spatio-temporal annotations
Stereotypes <<tempDependSpatial>> = Temporal dependent spatial object Modeling Geographic Data • Example using extensions:
Modeling Geographic Data (2) • Underlying Spatial Model: Open GIS Consortium geometry model:
Modeling Geographic Data (3) • DBMSs (e.g., MySQL and Oracle) have adopted and implemented the OGC geometry model • This means that we can map the spatial extension of the conceptual model directly to a logical and physical model • No standardized model has been adopted for temporal aspects (several different implementations exist)
Outline • Geographic data • Conceptual modeling • Modeling geographic data • Modeling multiple representations • What it is and requirements • Conceptual modeling approach to integrate data • Multiple representation schema language • Summary
Multiple Representation of Geographic Entities • Multiple representation is when several databases describe the same entity • The reasons for multiple representation vary • Different approaches in data collection • Different application purposes / definitions • Varying levels of detail (multi-scale)
Topographic Road Applications 3 DB3 Real-world entity Road Universe of discourse DB1 DB2 Applications2 Applications 1 Networked Road Motivation • Integration of data: • May support new potential use of data for various analysis purposes (e.g., integration of register and map data) • Can be used to rationalize the production of data • Integration depends on: • Definitions/semantics • Data models/structures • Varying levels quality
Example (Multi-Scale) Topographic Map 1:50,000
Example (Multi-Scale) Topographic Map 1:10,000
Multiple Representation of Geographic Entities • Problems today • Inconsistencies may occur among these multiple representations • Less concern is given to the fact that data change • Maintaining spatial data is costly • Benefits of a solution to handle MR • Reduce the cost of maintaining multiple representations of an entity • Ensure that users are working with updated representations • Possible integration of data comming from different sources
Requirements • An effective approach to the management of MR among legacy systems is needed • Several requirements exist. We need to be able to: • Specify consistency, matching, and restoration rules • Evaluate consistency rules with respect to a multiply represented entity • Match r-objects located in different representation databases • Monitor the representation databases for changes • Restore consistency if inconsistency occurs • Translate the specification into a database schema • Keep the various legacy GISs autonomous
Object correspondences (OCs) Value correspondences (VCs) Matching rules Restoration rules Existing classes in different databases, which we want to keep mutually consistent OC VC Multiple Representation Schema Language • The MRSL is based on an ”Integration Class” (i-class), which abstracts the entity represented • Introducing an i-class has several advantages • No changein representation databases • A simple approach to describe complex correspondence scenarios • A logical abstraction of an entity • Consistency, matching, and restoration requirements can be expressed in a single class
Integration Class in MRSL • The i-class is the main element in the MRSL and contains: • Attributes which are common for the r-classes • Consistency, matching, and restoration rules • Operations to restore consistency and match objects • A new stereotype is defined <<i-class>>, which specifies that a class: • Is defined within an integration database schema • Is associated to at least two representation classes • Should be identified uniquely • Has extra specification compartments for VCs, matching rules, restoration rules
Consistency Rules • The consistency rules consist of: • Object correspondences (OCs), which specify existence dependencies between the i-object and its r-objects • Value correspondences (VCs), which specify value (attribute) dependencies between the i-object and its r-objects
Consistency Rules (OC) • A new stereotype <<mr-association>> is defined for the OC: • It is always binary (either connects and i-class with a r-class or connects two i-classes) • Its navigation is always from the i-class to the r-class • It can be a master, i.e., the associated r-class controls the instances • It is represented as a dash-dotted line
Consistency Rules (VC) In UML the VCsare specified in a specification compartment and as initial values of i- attributes
Matching Rules • The matching rules specify how to find corresponding objects from different representation databases • The following matching criteria can be used: • Attribute comparison, e.g., spatial • Global object identifier • Manual inspection
Modify r-object / Establish correspondence r-object id Lookup Use lookup or matching function Find i-object i-object id No i-object i-object id / r-objects id Find r-object Example: Matching Rules: mr1: br.location inside tm.shape Matching Process Create i-object
Restoration Rules • The restoration rules specify the restoration actions that need to be applied when an OC or VC is not satisfied • The restoration rules follow the principle of event-condition-action (ECA) rules
Event Check OC r-object id true false true Object matching Check VC false i-object id / r-objects id Restoration Insert, update, delete, or notification Restoration Process
Restoration Rules Example: Restoration Rules: rr1: on insert tm then insert br {immediate}, rr2: on update tm.shape if not v1 then placeInside(br.location){immediate} v1: br.location inside shape
Summary • An overview of geographic data • Different conceptual modeling approaches • Standardized conceptual models support • Standardized logical models and implementations • Integration and exchange of data • Extensions can be used to satisfy those requirements posed by: • Geographic data in general • Multiple representations of geographic entities • Extensions are solutions to capture special semantics
Thank you for your attention! ???Questions???