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.

Les données spatiales vectorielles, telles que les points, les polylignes et les polygones, peuvent être dotées d'attributs topologiques permettant de modéliser des réseaux complexes. Des moteurs d'analyse de réseaux sont disponibles pour répondre à des questions comme la recherche du chemin le plus court entre deux nœuds ou l'optimisation d'un itinéraire de livraison ( problème du voyageur de commerce ). Un moteur de topologie peut être configuré avec un ensemble de règles définissant les interactions entre les entités topologiques lors de l'ajout ou de la modification de données.

Dans VMDS, toutes les données sont présentées à l'application sous forme d'objets. Cela diffère de nombreuses bases de données relationnelles qui présentent les données sous forme de lignes issues d'une table ou de résultats de requêtes utilisant par exemple JDBC . VMDS fournit un outil de modélisation des données et une infrastructure sous-jacente au sein de la plateforme technologique Smallworld . Ces outils permettent aux administrateurs d'associer une table de la base de données à un exemple (ou classe) Magik. Les méthodes d'accès (get et set) Magik pour cet exemple peuvent être générées automatiquement, exposant ainsi les champs (ou colonnes) de la table. Chaque ligne VMDS se manifeste dans l'application comme une instance d'un objet Magik et est appelée RWO (ou objet du monde réel). Dans le jargon Smallworld, les tables sont appelées collections.

# all_rwos contient tous les rwos de la base de données et est hétérogène all_rwos << mon_application.rwo_set() # valve_collection contient la collection de vannes vannes << all_rwos.select(:collection, {:valve}) nombre_de_vannes << taille_des_vannes

Les requêtes sont construites à l'aide d'objets prédicats :

# Trouver les vannes « ouvertes ». vannes_ouvertes << vannes.select(predicate.eq(:operating_status, "ouvert")) nombre_de_vannes_ouvertes << taille_vannes_ouvertes

_pour la vanne _sur les éléments_vannes_ouvertes() _boucle écrire(valve.id) _endloop

Les jointures sont implémentées sous forme de méthodes sur l'objet RWO parent. Par exemple, un responsable peut avoir plusieurs employés qui lui sont rattachés :

# Récupérer la collection des employés. employés << my_application.database.collection(:gis, :employees)

# Trouver un responsable appelé 'Steve' et récupérer le premier élément correspondant steve << employees.select(predicate.eq(:name, "Steve").and(predicate.eq(:role, "manager")).an_element()

# Afficher les noms de ses subordonnés directs. « Nom » est un champ (ou une colonne). # sur la collection (ou le tableau) des employés _pour l'employé _sur steve.direct_reports.elements() _boucle écrire(employé.nom) _endloop

Effectuer une transaction :

# Chaque clé de la table de hachage correspond au nom du champ (ou de la colonne) dans # la collection (ou le tableau) données_valve << table_de_hachage.nouveau_avec( :asset_id, 57648576, :matériau, "Fer")

# Obtenez directement la collection de vannes collection_valve << my_application.database.collection(:gis, :valve)

# Créer une transaction d'insertion pour insérer un nouvel enregistrement de vanne dans la 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()