Anders Friis-Christensen National Survey and Cadastre

National Survey and Cadastre – Denmark

Conceptual Modeling of Geographic Databases

- Emphasis on Relationships among Geographic Databases

Anders Friis-Christensen

National Survey and Cadastre

National Survey and Cadastre – Denmark Nordic Forum for Geo-statistics — March 25-26, 2004 2

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 ofDiscourse

DBMS-specific

DBMS-independent

Requirements

ConceptualSchema

ConceptualData Modeling

Data ModelMapping

PhysicalDesign

LogicalSchema

InternalSchema


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


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:- Are used to define new semantics to existing model

elements- Notation: <<stereotype>> or as an icon- Example:


Modeling Geographic Data

• Example using extensions:

Stereotypes<<tempDependSpatial>> = Temporal dependent spatial object


Modeling Geographic Data (2)

• Underlying Spatial Model:

Open GIS Consortiumgeometry 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 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)

Multiple Representation of Geographic Entities


Real-world entity

Motivation

Universe of discourse

DB1

DB3

DB2

• 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

Applications 1 Applications 2

Applications 3

Road

Topographic Road

Networked Road


Example (Multi-Scale)

Topographic Map 1:50,000


Example (Multi-Scale)

Topographic Map 1:10,000


Example (Different Definitions)

TM Building id34225433342253423422534134225340

T10 Building id usage buildingType1798705 non-residential low houses

BR Building id usage numOfFloors timeCon31371004 apartment house 2 4731371003 store 2 4631371002 apartment house 2 4631371001 apartment house 2 46


• 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

Multiple Representation of Geographic Entities


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


• Introducing an i-class has several advantages– No change in 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

• The MRSL is based on an ”Integration Class” (i-class), which abstracts the entity represented

Object correspondences (OCs)Value correspondences (VCs)

Multiple Representation Schema Language

Matching rulesRestoration rules

Existing classes in different databases, which we want to keep mutually consistent

attributes

i-class

attributes

r-class1

VC

OC


• 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

Integration Class in MRSL


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 VCs are specified in a specification compartment and as initial values of i- attributes


• 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

Matching Rules


Matching Process

Create i-object

No i-objecti-object id

Find r-object

Use lookup ormatching function Find i-object

Lookup

i-object id /r-objects id

Modify r-object /Establish correspondence

r-object id

Example:

Matching Rules: mr1: br.location inside tm.shape


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


Restoration Process

Object matching

r-object id

Check OC

i-object id /r-objects id

Restoration

false

Check VC

true

true

Event

false

Insert, update, delete, or notification


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


Complete Schema


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???

Anders Friis-Christensen National Survey and Cadastre

Documents

Transcript of Anders Friis-Christensen National Survey and Cadastre