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
