Le changement de paradigme en action

Le stockage des données d’une base de données s’effectue au sein de tables de ha-chage, ou « maps » permettant une association entre une clé et une valeur sous forme d’objets Java™ ( ™). Cette structure de données ne permet pas de définir de schéma de manière ana-logue aux SGBDRs. Afin de conserver la structuration générique de l’information définie par le modèle de données décrit dans précédement, un Plain Old Java Object (POJO)3 a été définie pour chaque table du MLD (Figure 5.2). La liste de ces tables est donnée Table 5.2. Ces dernières permettent de stocker, au niveau applicatif, le contenu des tables auxquelles ils se rapportent. Chaque tuple d’une table pouvant être, intégralement et identiquement structuré, stocké dans une instance de la classe ™associée à cette table (i.e. chaque classe ™ possède un attribut pour chaque colonne de la table à laquelle cette classe se rapporte). Dans leur ensemble, ces ob-jets permettent donc de reproduire l’intégralité de l’information du modèle logique de données en préservant ainsi la modélisation conceptuelle de cette dernière.

Tables POJO

TB_OBJECT DBObject.java

TB_DATATYPE_PROPERTY DatatypeProperty.java TB_OBJECT_PROPERTY ObjectProperty.java

TB_INDEXING Indexing.java

TB_HIERARCHY Hierarchy.java

TB_MODEL Model.java

TB_MODEL_DATATYPE_PROPERTY ModelDatatypeProperty.java TB_MODEL_OBJECT_PROPERTY ModelObjectProperty.java TB_MODEL_INHERITANCE ModelInheritance.java

Table 5.2 – Correspondance entre les tables du modèle physique de données générique et les Classes

™qui en permettent leurs représentations au niveau applicatif.

1. : « Grille de Données en Mémoire » 2. : « code Source Ouvert »

Ces POJOs sont construits à partir des données présentes dans le SGBDR de l’EDS. Ils sont ensuite insérés et maintenus au sein de la base de données à l’aide d’un SGBD spécifique appelé NINJAC Is Not Just A Cache (NINJAC) qui organise les accès à au sein du SI du . Les POJOs de type DBObject et Model possèdent la parti-cularité de pouvoir stocker (i.e. d’imbriquer) la liste des POJOs qui les concernent. Ainsi, un

DBObject représentant conceptuellement un objet quelconque, permet éventuellement, si celui-ci a été préalablement complété, d’accéder directement à liste des attributs (i.e. la liste des

DatatypeProperty) et des relations dans lesquelles cet objet conceptuel est impliqué (i.e. la liste de ObjectPropertyet/ouIndexing et/ouHierarchy). Il est néanmoins possible d’accéder aux PO-JOs DatatypeProperty,ObjectPropertyet Hierarchysans nécessairement passer par le DBObject auquel il se rapporte. En revanche, le POJO Model est lui systématiquement complété avec les POJOs ModelDatatypeProperty,ModelObjectPropertyetModelInheritancequi le concerne. Ainsi, du coté applicatif, la partie modèle du MLD est intégralement maintenue par l’ensemble des POJOs Model.

, tout comme les solutions NoSQL de type clé-valeur d’une manière générale, ne fournit pas de mécanisme permettant de définir de modèle de données à proprement parler. Par conséquent, le modèle de données peut être vu comme résultant de la conjonction entre l’ensemble des maps constituant la base d’une part et la structure des POJOs servant comme clés et valeurs dans ces dernières d’autre part. La Table 5.3 donne la liste des maps utilisées par le SI. Quant à la structure des objets utilisés comme clé et valeur, elle est héritée de la structure des tables du MLD.

Le système de gestion NINJAC permet principalement d’alimenter les maps de ce modèle et de mettre à disposition des méthodes permettant d’en extraire les POJOs de manière basique à partir des clés ou de manière un peu plus évoluée en complétant par exemple les DBObject avec les DatatypeProperty, ObjectProperty, Indexing et Hierarchy qui les concernent. Ce modèle est notamment composé de cinq « caches d’entité » donnant accès aux cinq POJOs destinés à la représentation de la partie donnée du MLD et d’un cache destiné à la partie modèle : le cache d’objets donnant accès auxDBObject, le cache d’attributs donnant accès auxDatatypeProperty, les caches de relations, d’indexations et de subsomptions donnant respectivement accès aux

ObjectProperty,Indexing etHierarchyet enfin le cache de modèle en charge de la représentation de la partie modèle du MLD. Les autres caches de la Table 5.4 sont des « caches système » qui servent davantage au fonctionnement interne de NINJAC et sont plus rarement exploités par des applications tierces requérant de l’information.

Cache d’objets

Retrouver un objet à partir de son identifiant

"RDF_RESOURCE" −→ DBObject

identifiant d’un objet. Instance ™ deDBObject représentant l’objet ayant

pour identifiant "RDF_RESOURCE".

Cache d’attributs

Retrouver les attributs d’un objet à partir de l’identifiant de ce dernier. "RDF_RESOURCE" −→ ^h DatatypePropertyⁱ

identifiant d’un objet. Liste des instances ™ de DatatypeProperty

représentant les attributs de l’objet

d’identi-fiant "RDF_RESOURCE" définit dans la table TB_DATATYPE_PROPERTY.

Cache de relations

Retrouver une relation à partir de l’identifiant de son objet source. "RDF_RESOURCE_SOURCE" −→ ^h ObjectPropertyⁱ

identifiant d’un objet source d’une relation.

Liste des instances ™ de ObjectProperty représen-tant les relations de la table TB_OBJECT_PROPERTY

dont l’objet source a pour identifiant

"RDF_RESOURCE_SOURCE".

Cache d’indexations

Retrouver une relation d’indexation à partir de l’identifiant de l’objet indexé. "RDF_RESOURCE_INDEXED" −→ ^h Indexingⁱ

identifiant d’un objet source d’une relation d’indexation.

Liste des instances ™ de Indexing représentant les relations de la table TB_INDEXING dont l’objet indexé a pour identifiant "RDF_RESOURCE_INDEXED".

Cache de subsomptions

Retrouver une relation hiérarchique à partir de l’identifiant de l’objet père. "RDF_RESOURCE_BROADER" −→ ^h Hierarchyⁱ

identifiant d’objet source d’une relation hiérarchique.

Liste des instances ™ de Hierarchy

représen-tant les relations de subsomption de la table

TB_HIERARCHY dont l’objet père a pour identifiant "RDF_RESOURCE_BROADER".

Cache de modèles

Retrouver un type à partir de son libellé.

"TYPE_ID" −→ Model

identifiant d’objet source d’une relation hiérarchique.

instance ™ de Model représentant ce type d’objet, d’attribut, de relation ou ce type abstrait (et ayant donc "TYPE_ID"pour libellé).

Légende :

“xxx” Chaîne de caractère contenant le texte xxx. Class instance de la classe Class.java

[X] Collection ordonnée d’éléments de type X.

{X} Collection non ordonnée et sans doublons d’éléments de type X.

Table 5.3 – Liste des caches de données du SI NoSQL du . Pour chaque Map : Cl´e →

Cache d’identifiants

Retrouver les identifiants des objets d’un type donné. "TYPE_ID" −→ {"RDF_RESOURCE"}

Libellé d’un type

d’ob-jet contenu dans la table TB_OBJECT.

Ensemble des identifiants des objets de ce type "TYPE_ID".

Cache de types

Retrouver le libellé du type d’un objet.

"RDF_RESOURCE" −→ "OBJECT_TYPE_ID" identifiant d’objet contenu

dans la table TB_OBJECT.

type de l’objet ayant cet identifiant "RDF_RESOURCE".

Table 5.4 –Liste des saches système du SI NoSQL du .