logo-header

 
 

Introduction

To structure data, different data models are used. As the GeoDMS works with geographic data, geographic data models are relevant to structure this type of data, see chapter Geography.

Another relevant and well-known data model, used in many databases is the relational model. Much data is structured according to this model and many data modellers and database designers are familiar with this model. The focus of this chapter will be on assisting these modellers how the relational model relates to the GeoDMS datamodel and how relational operations can be configured in the GeoDMS.

All examples in this chapters are also visible in a complete configuration example, which can be downloaded here.

Example

In the examples of this chapter we will use the following relational model, derived from the Dutch BAG model. 

relation example small    

Each apartment has a unique identifier (Id, primary key) and an administrative address (Street, Number, Zipcode and Town). A boolean attribute (IsResidential) indicates if the apartment has a residential function. The last attribute is the Surface (in square meters) of the apartment.

Each building has also a unique identifier (Id, primary key), a construction year and a footprint of the building in square meters. The footprint can also be calculated with the area function in the GeoDMS.

Apartments can be related to multiple buildings and buildings can consist of multiple apartments, the relation is therefore a n-n relation, implemented in a third relational table called ApartmentBuildingRelation. In this table ApartmentId and BuildingId are foreign keys.

Relation Model versus Semantic Arrays

A relation in the relational model is defined as a subset of the Cartesian product of n domains. These relations are represented as tables/views. In a relation a primary key uniquely specifies a tuple. Foreign keys are used to represent 1-n or n-n relations between relations. Structured Query Languages (like SQL) are used to define/modify or delete database objects (DDL) or to query/modify/delete data from tables/views (DML).

The GeoDMS uses a data model with semantic arrays. Semantics means each array is associated with meta information, used to derive calculation characteristics and check calculation logic. Semantic arrays are mappings between sets, in GeoDMS terms typed by domain and values units.

Relevant differences between the attributes of relations in the relational model and semantic arrays:

- domain units need to be configured explicitly. As a semantic array is defined by its domain and values unit, these units need to be configured explicitly before the arrays can be defined. In the relation model a SQL statement results in a new view/relation with a subset of the source table(s)/views. In the GeoDMS such an operation is peformed in two steps

1. use a relation function to define the new domain unit
2. define the relevant attributes for the new domain unit.

See for example the Select From Where example.

- index numbers (mappings) are used to relate domains. Aggregational and Relational functies always work with these index numbers. Foreign keys in relations are therefore first translated to the index number of the relating domain (with the rlookup function). Such an attribute with domain unit A and as values unit the index numbers of domain B is called a partitioning.

- As the GeoDMS uses arrays, the sequence of elements matter. In the relation model there is no meaning in the ordering of the rows of a relation. A domain unit in the GeoDMS can be defined, in terms of the relational model, as an ordered relation. The sequence of the elements is relevant and if the sequence of elements would be different, they also need to have a different domain unit. This ordering can for instance be used in cumulate functions. 

This difference between relations and semantic arrays has implications on how SQL statements can be translated into GeoDMS operations. These differences are the topic of this chapter. The examples are available as a seperate configuration file, which can be downloaded here (soon).


OBJECT VISION BV
Vrije Universiteit
De Boelelaan 1085
1081 HV Amsterdam
The Netherlands

tel: +31 (0)20 598 9083
fax:+31 (0)20 598 9904