VMDS

VMDS is composed of two parts: a simple, highly scalable data block server called SWMFS (Smallworld Master File Server) and an intelligent client API written in C and Magik. Spatial and attribute data are stored in data blocks that reside in special files called data store files on the server. When the client application requests data it has sufficient intelligence to work out the optimum set of data blocks that are required. This request is then made to SWMFS which returns the data to the client via the network for processing.

This approach is particularly efficient and scalable when dealing with spatial and topological data which tends to flow in larger volumes and require more processing then plain attribute data (for example during a map redraw operation). This approach makes VMDS well suited to enterprise deployment that might involve hundreds or even thousands of concurrent clients.

Relational databases support short transactions in which changes to data are relatively small and are brief in terms in duration (the maximum period between the start and the end of a transaction is typically a few seconds or less).

VMDS supports long transactions in which the volume of data involved in the transaction can be substantial and the duration of the transaction can be significant (days, weeks or even months). These types of transaction are common in advanced network applications used by, for example, power distribution utilities.

Due to the time span of a long transaction in this context the amount of change can be significant (not only within the scope of the transaction, but also within the context of the database as a whole). Accordingly, it is likely that the same record might be changed more than once. To cope with this scenario VMDS has inbuilt support for automatically managing such conflicts and allows applications to review changes and accept only those edits that are correct.

As well as conventional relational database features such as attribute querying, join fields, triggers and calculated fields, VMDS has numerous spatial and topological capabilities. This allows spatial data such as points, texts, polylines, polygons and raster data to be stored and analysed.

Spatial functions include: find all features within a polygon, calculate the Voronoi polygons of a set of sites and perform a cluster analysis on a set of points.

Vector spatial data such as points, polylines and polygons can be given topological attributes that allow complex networks to be modelled. Network analysis engines are provided to answer questions such as find the shortest path between two nodes or how to optimize a delivery route (the travelling salesman problem). A topology engine can be configured with a set of rules that define how topological entities interact with each other when new data is added or existing data edited.

In VMDS all data is presented to the application as objects. This is different from many relational databases that present the data as rows from a table or query result using say JDBC. VMDS provides a data modelling tool and underlying infrastructure as part of the Smallworld technology platform that allows administrators to associate a table in the database with a Magik exemplar (or class). Magik get and set methods for the Magik exemplar can be automatically generated that expose a table's field (or column). Each VMDS row manifests itself to the application as an instance of a Magik object and is known as an RWO (or real world object). Tables are known as collections in Smallworld parlance.

 # all_rwos hold all the rwos in the database and is heterogeneous
 all_rwos << my_application.rwo_set()

 # valve_collection holds the valve collection
 valves << all_rwos.select(:collection, {:valve})
 number_of_valves << valves.size

Queries are built up using predicate objects:

 # find 'open' valves.
 open_valves << valves.select(predicate.eq(:operating_status, "open"))
 number_of_open_valves << open_valves.size

 _for valve _over open_valves.elements()
 _loop
   write(valve.id)
 _endloop

Joins are implemented as methods on the parent RWO. For example, a manager might have several employees who report to him:

 # get the employee collection.
 employees << my_application.database.collection(:gis, :employees)

 # find a manager called 'Steve' and get the first matching element
 steve << employees.select(predicate.eq(:name, "Steve").and(predicate.eq(:role, "manager")).an_element()

 # display the names of his direct reports. name is a field (or column)
 # on the employee collection (or table)
 _for employee _over steve.direct_reports.elements()
 _loop
    write(employee.name)
 _endloop

Performing a transaction:

 # each key in the hash table corresponds to the name of the field (or column) in
 # the collection (or table)
 valve_data << hash_table.new_with(
   :asset_id, 57648576,
   :material, "Iron")

 # get the valve collection directly
 valve_collection << my_application.database.collection(:gis, :valve)

 # create an insert transaction to insert a new valve record into the collection a
 # comment can be provide that describes the transaction
 transaction << record_transaction.new_insert(valve_collection, valve_data, "Inserted a new valve")
 transaction.run()

• Smallworld Technical Paper No. 8 - GIS Databases Are Different
• List of relational database management systems
• List of object-relational database management systems
• Spatial database
• Multiversion concurrency control