Du modèle sémantique à la base de données orientée graphes

Je vous soumets quelques réflexions à propos des nouvelles tendances dans les bases de données. N’étant pas un spécialiste du sujet, j’ai pu commettre des erreurs ou des naïvetés. N’hésitez pas à me corriger.

Ce qui caractérise le “NoSQL”

Les SGBD orientés graphes se rangent dans la catégorie des SGBD NoSQL. À bien y regarder, cette appellation « NoSQL » n’est pas ce qui caractérise le mieux les nouvelles solutions de persistance (orientées graphes comme Neo4j ou orientées documents comme MongoDB). En effet, ces solutions proposent forcément un langage de requête qui joue le rôle de SQL (Cypher pour Neo4j). Le vrai discriminant n’est pas là mais dans l’absence de schéma a priori (autant dire : l’absence de DDL, Data Definition Language). Il est possible, à tout moment, c’est-à-dire après la création de la base et sa mise en service, d’ajouter de nouveaux types d’objets – sous forme de « labels » associés aux nœuds – ainsi que de nouvelles propriétés, associées ou pas aux labels. Une propriété pourrait même n’exister que sur un seul nœud. De même, il est possible de créer de nouvelles relations entre les nœuds, au fil de l’exploitation. On peut associer impérativement des propriétés à des labels ou à des relations, par le truchement de « contraintes ». Tout ceci s’obtient en l’absence de modèle ou de schéma de la base de données, et ne nécessite aucune opération d’administration.

Ce que cela entraîne

De prime abord, cette liberté semble un avantage fabuleux. Elle s’accorde parfaitement avec certaines applications manipulant les données de façon assez lâche, typiquement pour l’analyse. Dans les cas où on recourt à ces solutions pour des applications plus classiques, cette liberté confine à l’anarchie, porteuse de risques (mes excuses auprès des libertariens qui pourraient lire ceci). Il est toujours nécessaire de vérifier la pertinence des propriétés relatives aux types d’objets, d’une part, et l’applicabilité des relations selon le type des objets qu’elles relient. Également, on aimerait retrouver un mécanisme similaire à l’héritage dans l’orientation objets afin d’assurer qu’un objet appartenant à un sous-type (exemple : Individu) dispose des propriétés définies sur le type plus général (exemple : Entité). D’autres contrôles encore sont nécessaires, comme le contrôle des cardinalités : à combien d’objets, un certain objet peut être relié via une relation donnée. On sait que, dans un modèle sémantique, changer la cardinalité d’une association affecte la définition même de l’objet relié. Il s’agit donc d’un élément de la plus haute importance pour la compréhension des informations.

Ces réflexions nous ramènent toujours au même point : comment traduire, en termes logiciels, la connaissance humaine ? Exprimé dans le contexte de la méthode Praxeme : comment dériver le modèle sémantique vers une base de données, sans perdre ni substance ni structure ?

Le tableau suivant met en regard les termes de la modélisation sémantique et ceux des solutions dans le style relationnel et dans l’orientation graphes.

Catégorie sémantique	Interprétation naturelle	Terminologie du style relationnel	Terminologie du style orienté graphes
Classe (en tant que représentation d’un concept ou d’un ensemble d’objets)	Type d’objet, concept	Table	Label (éventuellement)
Propriété informative (le plus souvent : attribut)	Type d’information propre au type d’objet	Colonne (d’une table)	Propriété (définie sur les nœuds)
Association entre classes	Type de relation qu’entretiennent des objets selon leurs types	Clef étrangère (colonne particulière d’une table)	Relation (en tant que nom de relation, défini au niveau des instances)
Instance de classe	Objet (concret, précis, particulier)	Ligne dans une table	Nœud
Lien, instance d’une association	Relation établie entre des objets	Valeur d’une clef étrangère, sur une ligne	Relation entre deux nœuds
Valeur d’une propriété (d’un attribut)	Information, valeur attribuée à une propriété d’un objet	Valeur d’une cellule (une colonne dans une ligne)	Valeur d’une propriété

Ce tableau ne s’intéresse qu’à la partie informative de la sémantique, la partie correspondant aux données. Il laisse de côté d’autres propriétés essentielles de la sémantique : propriétés actives (opérations) et transformatives (automates à états, événements, règles). La raison de cette exclusion réside tout simplement dans le fait que les SGBD examinés ici ne couvrent pas ces dimensions, exception faite de la notion de procédure cataloguée^[1].

Les trois premières lignes de ce tableau révèlent le décalage apporté par l’orientation graphes.

Même la notion de « label » (ou étiquette) mise en correspondance avec la classe ne se crée pas pour elle-même, mais toujours à travers la documentation d’un nœud particulier, donc au niveau de l’instance et non du type. De plus, on ne peut pas assortir les étiquettes avec des propriétés, alors que la notion de propriété est fortement impliquée dans celle de classe (la propriété est ce qui est propre – caractéristique – à une classe ; celle-ci devrait en être la seule propriétaire, en tout cas si le modèle est bien formé). Ce décalage vaut aussi pour les relations : elles peuvent être dotées de propriétés, quand elles équivalent à des classes associatives, mais ces propriétés apparaissent au niveau des instances et non à celui des types. Ces différences se résument à un seul trait : l’absence de modèle de données.

Les besoins de compensation

Ce vide peut se combler partiellement à l’aide des « contraintes ». Les contraintes d’unicité et d’existence permettent d’imposer certaines règles lors de la création des nœuds et des relations. Elles sont loin de suffire pour approcher le niveau de contrôle obtenu par un bête modèle logique de données.

Lors du passage d’une culture SQL à l’orientation graphes, cette différence radicale a de quoi déstabiliser. L’imprécision du vocabulaire augmente le malaise. Le terme « relation » nomme indifféremment l’association – entre classes – et le lien – entre instances. Une telle imprécision s’explique par la disparition du niveau « modèle »^[2].

Les SGBD orientés graphes autorisent les relations réflexives, mais restreignent la notion de relation aux relations binaires. Là encore, quand on connaît l’importance des associations n-aires pour arriver à la bonne expression des concepts, on se sent un peu démuni.

Le bilan rapide est que ces solutions ne restituent facilement que des phrases simples, sur la structure « sujet-verbe-complément d’objet ». Illustration : « X réside à Adresse » où « X » et « Adresse » sont des nœuds, et « réside à » est une relation. Dès que l’on souhaite s’approcher un peu plus de la réalité pour parler, par exemple, de l’adresse de résidence, l’adresse de livraison, l’adresse de facturation, l’adresse fiscale… on introduit un troisième terme, l’usage de l’adresse, et les choses se compliquent. Bien sûr, il y a toujours moyen de s’en sortir. Dans l’exemple, on peut ajouter une propriété sur la relation « réside » ou même faire de la résidence un nœud… Je n’entrerai pas dans plus de détails, ici.

Mon but, dans ce rapide papier, est de montrer ce qui oppose l’organisation tabulaire des informations telle que l’on s’y est habitué avec les SGBD relationnels, et l’organisation réticulaire présentée par les SGBD orientés graphes. Le point le plus remarquable est l’absence de schéma, au sens de modèle de données, établi a priori.

Le tableau suivant distribue les notions sur l’axe M0-M3 défini par l’OMG.

Niveau	Sémantique	Relationnel (SQL)	Orienté graphes
M0	Objets, instances : Mme XX, M. XY	Lignes	Nœuds et relations
M1	Classes : Individu, Adresse	Tables	Labels sur les nœuds (éventuellement ; pas obligatoire)
M2	Méta-classe « Classe » et sa structure (catégories d’expression)	Le modèle interne du SGBD	Idem. Les notions de nœud, relation, etc.
M3	Meta Object Facility pour établir les correspondances entre langages

Comment rétablir le contrôle malgré l’absence de schéma de base de données

Malgré cette limite, de nombreux bénéfices militent en faveur de l’adoption de ces solutions, en tout cas pour les usages dans lesquels la notion de relation revêt une importance cruciale. Même dans ces cas, le besoin de contrôler la pertinence reste entier. Puisqu’il n’est pas pris en charge par le SGBD, trop ouvert, il revient au programme. À cette fin, l’idée est d’inclure dans la base, mélangé avec les informations courantes, un graphe isolé qui fait office de schéma de la base et qui reprend le modèle logique de données. C’est ce que propose le graphe ci-dessous, extrait d’une base Neo4j. Il s’agit d’une illustration partielle, montrant des nœuds étiquetés « Meta_TypeObjet » et « Meta_TypeRelation » pour définir l’équivalent des classes Individu, Entité, Action… Ces nœuds se relient à des nœuds « Meta_Propriété » pour connaître les propriétés de ces classes et relations. Le tout sera exploité algorithmiquement pour contrôler le contenu des objets (nœuds) produits par l’application ainsi que les relations.

On peut trouver ce mécanisme un peu lourd et même juger qu’il s’agit d’une régression par rapport à ce que l’on attendait des SGBD traditionnels. C’est le prix à payer pour bénéficier de cet avantage inouï : l’évolutivité de la base. Elle repose sur la capacité, laissée à l’utilisateur, de définir ou d’étendre le modèle, avec ses propres types d’objets et de relations et de nouvelles propriétés. Cette solution est détaillée ailleurs (cf. modèle logique de données orienté graphes pour la méta-application Sloog).

Récapitulatif :

Plan de représentation	Catégorie	Commentaire
M2	Les étiquettes préfixées « Meta_ »	Nécessaires pour constituer le modèle M1
M1	Les nœuds portant ces étiquettes + étiquettes pour chaque type d’objet + contraintes	Graphe séparé exprimant le modèle des données avec les types d’objets reconnus et les relations admises
M0	Nœuds étiquetés avec les types d’objets (M1) + relations	À l’exécution, lors de la création ou de la modification d’un nœud, le programme exploite les informations du M1 pour contrôler la validité de l’information : les propriétés nécessaires, les relations admises.

Les nœuds utilisés pour reproduire le schéma de la base (niveau M1) portent les étiquettes « Meta_ » du niveau M2. Ces nœuds se relient pour reproduire le modèle de données. Les nœuds étiquetés « Meta_TypeObjet » se doublent par des étiquettes qui reprennent le nom des concepts ou types d’objets. Elles servent à marquer les nœuds du niveau M0.

---

^[1] Sans vouloir nous faire du mal, rappelons qu’un SGBD orienté objets est capable de couvrir tout cela, donc de reprendre presque intégralement le contenu exprimé par un modèle sémantique. On se souvient de l’excellent SGBD O_2, issu d’un projet de l’INRIA et qui, malgré ses qualités, n’a pas trouvé son marché.

^[2] On connaît les difficultés, sur les projets, quand on se confronte à ce type de problème. Dans de nombreux domaines, les systèmes doivent gérer des notions qui s’échelonnent sur plusieurs niveaux. L’esprit doit donc distinguer, avec agilité, ces niveaux. Une illustration est : la voiture particulière, physique, avec sa plaque d’immatriculation ; le modèle de voiture ; le produit « voiture ».