Étiquette : sémantique

Un Commentaire

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

  de

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émantiqueInterprétation naturelleTerminologie du style relationnelTerminologie du style orienté graphes
Classe (en tant que représentation d’un concept ou d’un ensemble d’objets)Type d’objet, conceptTableLabel (éventuellement)
Propriété informative (le plus souvent : attribut)Type d’information propre au type d’objetColonne (d’une table)Propriété (définie sur les nœuds)
Association entre classesType de relation qu’entretiennent des objets selon leurs typesClef étrangère (colonne particulière d’une table)Relation (en tant que nom de relation, défini au niveau des instances)
Instance de classeObjet (concret, précis, particulier)Ligne dans une tableNœud
Lien, instance d’une associationRelation établie entre des objetsValeur d’une clef étrangère, sur une ligneRelation entre deux nœuds
Valeur d’une propriété (d’un attribut)Information, valeur attribuée à une propriété d’un objetValeur d’une cellule (une colonne dans une ligne)Valeur d’une propriété
La traduction des éléments sémantiques selon le style de SGBD

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.

NiveauSémantiqueRelationnel (SQL)Orienté graphes
M0Objets, instances : Mme XX, M. XYLignesNœuds et relations
M1Classes : Individu, AdresseTablesLabels sur les nœuds (éventuellement ; pas obligatoire)
M2Méta-classe « Classe » et sa structure (catégories d’expression)Le modèle interne du SGBDIdem. Les notions de nœud, relation, etc.
M3Meta Object Facility pour établir les correspondances entre langages  
Les réponses des SGBD sur les plans de représentation

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.

Extrait de la base Sloog développée avec Neo4j : graphe partiel traduisant une partie du modèle logique de données

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ésentationCatégorieCommentaire
M2 Les étiquettes préfixées « Meta_ »Nécessaires pour constituer le modèle M1
M1Les nœuds portant ces étiquettes + étiquettes pour chaque type d’objet + contraintesGraphe séparé exprimant le modèle des données avec les types d’objets reconnus et les relations admises
M0Nœ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.
Le principe de la solution pour assurer le contrôle sémantique

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 O2, 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 ».

La French Tech tacle l’Empire

  de

Ou : « EBX fait le buzz »

Le cabinet Gartner vient de publier son Magic Quadrant pour les solutions de Master Data Management. L’étude place la solution EBX, d’Orchestra Networks, dans la catégorie des « Leaders » (elles ne sont que deux solutions dans cette catégorie).

On s’étonnera que des noms plus prestigieux soient confinés dans la zone des acteurs de niche. Une raison probable est la spécialisation des solutions par domaine. Pour le vendeur, une telle spécialisation s’est longtemps montrée rentable :

  1. tout d’abord, elle facilite la démarche commerciale, notamment auprès des directions métier ;
  2. ensuite, elle permet de tirer davantage de profits, en proposant une solution distincte pour chaque domaine à couvrir, ce qui gonfle la facture ;
  3. enfin, elle évite au vendeur de déployer trop d’efforts pour intégrer des solutions, presque toujours issues d’acquisitions successives.

Permettez-moi de vous raconter une anecdote. Il s’agit d’un gros projet de MDM, dans une compagnie d’assurance japonaise. Tout de suite, le projet est scindé en deux sous-projets, chacun sur un domaine précis : l’un sur les données des clients, l’autre sur celles des fournisseurs. Un seul prestataire est retenu, qui propose une solution pour chacun des domaines.

En revue d’architecture, quelqu’un pose la question naïve : au fait, quand on y pense, est-ce qu’un client – individu ou organisation – ne présente pas des points communs avec un fournisseur ?

Il va de soi que, dans une approche de modélisation sémantique, « client » et « fournisseur » sont considérés comme des rôles, et que le modèle place, en son centre, le véritable objet : l’entité. C’est uniquement dans sa relation à un contrat ou à un engagement que l’entité revêt tel ou tel rôle. D’ailleurs, une même entité peut être, pour une entreprise, à la fois un client et un fournisseur, ou un client et un collaborateur, etc.

De là, l’idée toute simple qu’un seul référentiel pourrait couvrir toutes les entités, quels que soient leurs rôles, réduisant ainsi la redondance du système (donc les coûts d’investissement et de fonctionnement, la lourdeur, les risques, etc.).

Pendant cette revue d’architecture, tout le monde tombe d’accord sur cette évidence. Mais trop tard…

Faute d’avoir aperçu cette idée toute simple, on en arrive à ce paradoxe : alors que la démarche MDM a pour but d’augmenter la maîtrise du système, ce qui passe par une réduction de la redondance, le projet n’a fait que l’accroître. Passe encore que nos systèmes aient accumulé une redondance effarante au cours de leur histoire : on en connaît les raisons. Mais que, au moment de reconstruire, les mêmes erreurs se reproduisent… il n’y a pas d’excuse. Cela ressemble fort aux logiques perverses que Jacques Généreux dénonce dans « La déconnomie » à propos des politiques économiques.

Orchestra Networks, en tant que « pure player » depuis son origine, a évité cet écueil. N’étant pas inféodée à d’autres intérêts, la solution a toujours et forcément été multi-domaine. Ce n’est pas un hasard, d’ailleurs, si Orchestra Networks compte parmi les fondateurs du Praxeme Institute. D’aucuns y verront le signe d’une communauté culturelle profonde.

Une entreprise qui voudrait améliorer radicalement son système informatique, comme le prône Praxeme, trouverait dans EBX la solution parfaite. Elle lui permettrait de restaurer l’unité de ses données, et de se rapprocher de la pureté sémantique. Cette étape est nécessaire pour simplifier le système et recouvrer une créativité qui a bien déserté le domaine de l’informatique.

Dans un sens, on peut voir, dans la destinée d’Orchestra Networks, une belle illustration de la « French Tech ». Dans l’esprit : plutôt que concevoir des solutions tactiques qui traitent partiellement le sujet, penser une solution globale et pragmatique… et s’y tenir

Lien vers l’étude de Gartner : http://www.orchestranetworks.com/gartner-mdm-magic-quadrant/.

Formaliser la connaissance du métier

  de

Terminologie, ontologie, sémantique

Quoi que l’on fasse – transformation, innovation, automatisation… -, le point de départ est toujours le même : la connaissance du métier. Non seulement nous devons posséder cette connaissance, mais aussi elle doit se présenter sous une forme telle qu’elle satisfasse à plusieurs critères. Elle doit être :

  • complète, pour éviter les surprises en cours de route,
  • sans ambiguïté, pour empêcher les conflits d’interprétation,
  • précise, pour appuyer une conception pertinente,
  • fidèle, conforme à la réalité,
  • économique, c’est-à-dire exprimée sans redondance, avec le minimum de termes pour dire le maximum de choses,
  • ouverte, affranchie des présupposés qui pourraient réduire sa portée.

Cette qualité d’expression ne se donne pas d’emblée. On ne l’obtient que par de grands efforts et une volonté constante. Elle ne se trouve ni du côté du “métier”, ni du côté de l’informatique. En effet, force est de constater qu’elle n’est pas immédiatement disponible dans l’entreprise. Il suffit de réunir deux experts du métier et de les faire travailler sur des définitions, pour s’apercevoir que les pratiques reposent sur beaucoup de non-dit et que la verbalisation fait voler en éclat l’apparent consensus.

Pour obtenir une bonne expression de la connaissance, nous disposons de plusieurs techniques : la terminologie, les ontologies, la modélisation sémantique. Chacune présente des avantages et des limites. Comment les utiliser ? Peut-on les articuler ? Quel niveau d’exigence viser, selon l’objectif que l’on se donne ?

Voilà quelques-unes des questions abordées dans l’article “Formuler la connaissance“, publié sur le wiki du Praxeme Institute.

Version anglaise : “Formulating Knowledge“.

 

 

Big data : la nécessaire sémantisation des données

  de

En exploitant les nouvelles sources de données, à un moment ou à un autre, se pose la question de la signification de ces données. Également, pour tirer un plus grand profit de la connaissance acquise, la donnée doit être rapportée à un concept, c’est-à-dire à l’objet (physique ou abstrait) qui la porte. Elle doit s’articuler aux autres facettes de cet objet.
C’est le rôle de la modélisation sémantique de dégager la signification des données, de les formaliser en tant que propriétés du concept et de les inscrire dans une structure manipulable.

La modélisation sémantique apparaît donc comme un outil incontournable pour bénéficier des techniques X-data. En retour, les X-data influent sur la modélisation sémantique – sinon sur ses procédés, du moins sur son contenu. Notamment :

  • assimilation de nouvelles propriétés dans le modèle sémantique (complétant les classes sémantiques, déjà identifiées, avec des “détails” issus des big data), particulièrement des propriétés de portée classe (valeurs agrégées, indicateurs issus des open data),
  • extension du modèle à des notions nouvelles (par exemple, meilleure description des objets appartenant à l’environnement de l’entreprise, les personnes, leurs relations, leurs comportements, les événements externes…),
  • évolution vers un “style” de modèle qui ménage leur place aux comportements, aux corrélations et aux anticipations (des catégories de propriétés que l’on peut considérer comme nouvelles ou, en tout cas, d’usage rare dans la modélisation classique), avec un enrichissement conséquent des automates à états et de la propagation des changements d’états.

Praxeme exhorte le modélisateur à ne pas réduire la connaissance du métier à celle des données. Le choix du terme “sémantique” en lieu et place de “conceptuel” découle de cette position, ce dernier terme évoquant fortement le modèle conceptuel des données alors que le modèle sémantique prend en charge le concept, tout le concept, sous ses trois facettes réconciliées dans l’unité de la classe : information, action, transformation.

Un modèle de données n’est pas un modèle sémantique

  de

On change plus facilement les appellations que les pratiques. Aujourd’hui, il est de bon ton d’insister sur les objets métier. C’est une très bonne chose… à condition d’en faire des modèles qui ne soient pas que des modèles de données “à l’ancienne”. Je réponds ci-dessous à une question qui m’a été posée sur ce que change l’utilisation d’UML par rapport à Merise.

Qu’est-ce qui fait, fondamentalement, que les entités de Merise sont distinctes de ce que l’on nomme “objets métier” ? En dehors de la notion d’héritage (et donc de spécialisation dans UML), qu’est-ce qui fait, dans le formalisme et dans les principes, qu’UML est plus adapté que Merise pour représenter les objets métier ? Est-ce-qu’en pratique, ce sont les notions d’agrégation et de composition qui changent tout ?

 

Tout d’abord, Merise – méthode de conception informatique – ne nous enseigne pas à représenter la connaissance métier mais impose, dès l’abord, la séparation données-traitements. Le MCD est un modèle de données : c’est dire qu’il ne peut pas représenter toute la connaissance des fondamentaux du métier. Conséquence pratique : certaines informations ne peuvent pas être inscrites sur le modèle, sous prétexte qu’elles sont calculées (ex. l’âge de la personne alors que l’on a la date de naissance). C’est tout à fait justifié pour un modèle de données, ça ne l’est pas pour un modèle sémantique. Du point de vue de l’acteur métier, ces distinctions entre données brutes et données calculées n’ont pas cours : il voit des informations qui font partie du concept.

Plus important encore : la sémantique d’un concept ou d’un objet métier ne s’arrête pas aux propriétés informatives : elle comporte également des propriétés actives (ce que l’objet peut “faire”) et des propriétés transformatives (comment il se comporte ?). Si nous voulons exprimer toute la sémantique, nous devons associer à l’objet métier : les opérations et leurs conditions d’emploi, les contraintes (règles métier), les états (cycles de vie)… bref tout ce qui complique dangereusement nos solutions informatiques faute d’une approche appropriée.

Si la notation UML est bien utilisée, elle peut outiller la modélisation sémantique. Les classes portent les trois types de propriétés : informatives (sous la forme d’attributs, y compris attributs calculés et attributs de portée classe) ; actives (les opérations) ; transformatives (les contraintes et les automates à états).

Évidemment UML est connotée “logiciel” (et est, d’ailleurs, largement sous-exploitée par les informaticiens dont les pratiques de modélisation ont considérablement régressé au cours de ces dernières décennies). Mais il ne faut pas oublier que les notions et axiomes qui forment la logique objet proviennent de la philosophie de la connaissance (de là le terme “classe”) : ce n’est donc pas un hasard si cette logique et les notations qui l’expriment se prêtent aussi facilement à la représentation des connaissances. A noter aussi que l’élargissement des possibilités de modélisation (dans un modèle sémantique par rapport à un MCD) n’aboutit pas à un simple ajout de propriétés sur le modèle : il en change la structure. Ce que je veux dire par là, ce n’est pas seulement les éléments visibles qu’apporte UML par exemple (héritage, agrégation…) : ces éléments pouvaient être, en partie, restitués dans l’approche classique. C’est qu’en prenant en compte toutes les propriétés des objets métier et en suivant les exigences de généricité et de factorisation, le modélisateur est conduit à arranger différemment l’ensemble des propriétés. Les conséquences de ces changements de structure sont énormes : si on les suit sur toute la chaîne de transformation (conception des processus, automatisation…) l’enjeu se chiffre en millions d’euros. L’exemple d’école est la notion de Personne (ou client, employé, etc.). En appliquant rigoureusement cette approche, on peut diviser le volume des SI par 2, facilement ! Tout en augmentant le confort d’utilisation parce que l’on aura construit des solutions plus proches des représentations naturelles.

En conclusion, un modèle sémantique est bien plus qu’un modèle conceptuel des données (il le contient et on peut, à tout moment, extraire le modèle des données d’un modèle sémantique. Praxeme propose plusieurs filières de dérivation à partir du modèle sémantique, dont celle qui produit le modèle logique des données).
L’appellation “Business Object Model” a servi un peu trop à désigner des MCD (et parfois, même pas bons : on en a de lamentables exemples sur le marché). Ce qu’on appelle un BOM (par exemple celui d’IBM) ou l’Information Model d’ACORD ne sont que des modèles de données (même pas normalisés). Les conséquences sont dramatiques. Mais c’est une autre histoire…

Ce commentaire ne remet pas en cause l’héritage de Merise. UML est une notation, pas une méthode. Merise est une méthode et beaucoup de ses recommandations non seulement restent d’d’actualité mais encore sont nettement supérieures à ce que l’on trouve dans les méthodes orientées objet et dans les pratiques courantes. Donc, nous avons tout intérêt à faire fructifier notre héritage. Praxeme reconnaît bien volontiers sa filiation avec Merise.

Formaliser la connaissance

  de

En réponse à la demande d’un client, Dominique VAUQUIER tire au clair les différents moyens d’exprimer la connaissance. C’est l’occasion pour formuler des réflexions qui traînaient au sein du Praxeme Institute, surtout depuis les ateliers des professeurs Loïc DEPECKER sur la terminologie et Christophe ROCHE sur les ontologies.

L’article repose sur l’idée que les techniques à notre disposition pour exprimer les connaissances s’échelonnent selon le niveau de formalisation. Plus l’effort consenti est important, plus grandes sont les possibilités d’automatisation.

En pratique, les entreprises que le sujet préoccupe pourront arrêter une démarche progressive, mettant à profit différentes techniques : le classement de documents à l’aide de taxinomies, l’élaboration de la terminologie d’entreprise, le développement d”ontologies, la modélisation – particulièrement la modélisation sémantique.

Télécharger l’article