VMDS


VMDS abbreviates the relational database technology called Version Managed Data Store provided by GE Energy as part of its Smallworld technology platform and was designed from the outset to store and analyse the highly complex spatial and topological networks typically used by enterprise utilities such as power distribution and telecommunications.
VMDS was originally introduced in 1990 as has been improved and updated over the years. Its current version is 6.0.
VMDS has been designed as a spatial database. This gives VMDS a number of distinctive characteristics when compared to conventional attribute only relational databases.

Distributed server processing

VMDS is composed of two parts: a simple, highly scalable data block server called SWMFS 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. This approach makes VMDS well suited to enterprise deployment that might involve hundreds or even thousands of concurrent clients.

Support for long transactions

Relational databases support short transactions in which changes to data are relatively small and are brief in terms in duration.
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. 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. 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.

Spatial and topological capabilities

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

Data abstraction

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. Magik get and set methods for the Magik exemplar can be automatically generated that expose a table's field. Each VMDS row manifests itself to the application as an instance of a Magik object and is known as an RWO. Tables are known as collections in Smallworld parlance.
# all_rwos hold all the rows in the database and is heterogeneous
all_rwos << my_application.rwo_set
# valve_collection holds the valve collection
valves << all_rwos.select
number_of_valves << valves.size
Queries are built up using predicate objects:
# find 'open' valves.
open_valves << valves.select
number_of_open_valves << open_valves.size
_for valve _over open_valves.elements
_loop
write
_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
# find a manager called 'Steve' and get the first matching element
steve << employees.select.and.an_element
# display the names of his direct reports. name is a field
# on the employee collection
_for employee _over steve.direct_reports.elements
_loop
write
_endloop
Performing a transaction:
# each key in the hash table corresponds to the name of the field in
# the collection
valve_data << hash_table.new_with
# get the valve collection directly
valve_collection << my_application.database.collection
# 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
transaction.run