Modélisation des données

Objectif

La décision que le modèle soutient est celle de la structure des données persistantes. Le BABOK le pose comme une force de la technique: la revue d'un modèle de données logique permet de vérifier que la conception des données persistantes représente correctement le besoin métier. Un choix de structure devient coûteux à défaire une fois implémenté, et le modèle le rend discutable avant.

Le modèle répond à trois questions dans cet ordre: de quelles choses l'organisation garde-t-elle trace, que retient-elle sur chacune et comment ces choses se tiennent-elles ensemble. Les réponses portent les noms d'entité, d'attribut et de relation, et une relation ne se tient pour posée qu'une fois dénombrée: chaque client est rattaché à exactement un secteur de vente, un secteur de vente compte zéro, un ou plusieurs clients.

Usage

Quand l'utiliser

• Conception d'une base de données relationnelle: la structure persistante se pose avant l'implémentation.
• Conception d'un logiciel orienté objet: les classes et leurs associations cadrent le code à écrire.
• Revue d'une conception de données: vérifier que le modèle logique répond au besoin métier.
• Système existant sans documentation: reconstruire la structure réelle avant toute décision de reprise ou de migration.
• Domaine soupçonné incohérent: la modélisation formelle fait apparaître des contradictions et des exigences que la prose masquait.

Quand ne pas l'utiliser

• Public strictement métier, sans culture informatique: le formalisme rebute, tenir le modèle de concepts ou le glossaire pour ce public.
• Besoin limité aux définitions d'éléments: format, longueur et valeurs admises relèvent du dictionnaire de données (10.12) seul.

Les éléments du modèle

Le BABOK décompose le modèle en cinq éléments: l'entité ou classe, l'attribut, la relation ou association, le diagramme qui les porte et les métadonnées, que le modèle contient facultativement.

Entité, attribut, relation

Une entité est ce dont le métier garde trace: quelque chose de physique (un entrepôt), d'organisationnel (un secteur de vente), d'abstrait (une gamme de produits) ou un événement (un rendez-vous). Chaque occurrence porte un identifiant unique. Sur un diagramme de classes, la même chose s'appelle une classe et porte un compartiment de plus, celui des opérations: émettre une facture, ouvrir un compte.

Un attribut est une information retenue sur l'entité, avec le type de donnée qu'il porte. Son nom unique, ses alias, ses valeurs admises et sa définition dans le contexte de la solution sont le contenu d'une entrée de dictionnaire de données. Les valeurs admises sont souvent fixées par une règle métier tenue ailleurs, que couvre l'analyse des règles métier.

Une relation dit comment deux entités se tiennent ensemble. Le BABOK en donne la formule de lecture, qui se prononce telle quelle devant un expert du domaine: chaque occurrence de cette entité est liée à un minimum et un maximum d'occurrences de cette autre entité. Une relation se lit dans les deux sens et les deux lectures sont deux règles métier distinctes, à valider séparément. Sur un modèle de classes, les mots changent pour la même idée: association et multiplicité.

Cardinalité et optionnalité

Derrière le mot cardinalité se tiennent deux questions indépendantes, et les traiter comme une seule est l'erreur la plus fréquente sur un modèle logique. La première porte sur le maximum: une occurrence peut-elle en toucher plusieurs de l'autre côté ou une seule? La seconde porte sur le minimum: doit-elle en toucher au moins une, ou peut-elle n'en toucher aucune? Le BABOK range les deux bornes sous le seul terme de cardinalité. La tradition issue de la méthode de Barker nomme la seconde l'optionnalité: une relation est obligatoire quand son minimum vaut un, facultative quand il vaut zéro.

Les deux bornes se posent aux deux extrémités, ce qui fait quatre valeurs à valider pour une seule ligne de diagramme. Sur la relation entre Assuré et Police: un assuré détient zéro, une ou plusieurs polices; une police est détenue par exactement un assuré. Le minimum se discute rarement et porte pourtant une décision d'implémentation: écrire zéro autorise la base à contenir un assuré sans aucune police, écrire un le lui interdit et oblige l'application à créer l'assuré et sa première police dans la même transaction.

Répondre au minimum par la règle métier donne une borne fausse. L'assurance de base est obligatoire pour toute personne domiciliée en Suisse, ce qui invite à écrire un du côté de la police. Or le dossier d'un assuré existe dans le système entre la demande d'affiliation et l'émission du contrat, et il existe encore après la résiliation de la dernière police. La borne minimale décrit les états que la base doit accepter à tout instant, y compris les états transitoires que la règle métier ignore.

Une borne posée par défaut est une règle métier inventée. Le « plusieurs » mis d'office parce qu'il coûte moins cher à défaire accorde une permission que personne n'a donnée, et il se découvre le jour où l'application accepte un cas que le métier refuse. Chaque borne se valide auprès de l'expert du domaine, dans les termes de son activité: combien de polices un assuré peut-il détenir en même temps, une police peut-elle couvrir plusieurs personnes. En assurance-maladie suisse, la seconde réponse est non, chaque personne étant assurée pour elle-même, y compris lorsque le ménage reçoit une facture unique. Un modèle qui répond oui écrase la distinction entre le contrat et sa facturation.

Identifiant, clé primaire, clé étrangère

L'identifiant apparaît dès le niveau conceptuel, où il désigne l'attribut qui distingue une occurrence des autres. Au niveau logique, il devient la clé primaire et prend trois obligations: être unique, être renseigné en toute circonstance et rester stable dans le temps.

La clé naturelle est un attribut que le métier possède déjà: le numéro AVS d'un assuré, le numéro d'une police. La clé technique, dite aussi de substitution, est un nombre sans signification que le système attribue au seul usage de l'identification. La clé naturelle se lit, se contrôle à l'œil sur un extrait de table et économise une colonne. Deux défauts pèsent souvent contre elle. Elle change le jour où le métier change sa manière de numéroter, comme le numéro AVS passé en 2008 de onze à treize chiffres, et le changement se propage dans toutes les entités qui la recopient. Chaque table qui recopie un identifiant de personne devient par ailleurs une table de données personnelles, et le périmètre à protéger s'élargit d'autant.

La clé étrangère est l'attribut par lequel une entité porte l'identifiant d'une autre; elle tient la relation au niveau logique et sa place est dictée par le maximum de la cardinalité: dans une relation un-à-plusieurs, elle se pose du côté « plusieurs », la police portant le numéro AVS de son assuré. Une relation plusieurs-à-plusieurs n'offre aucun côté où la poser. C'est le signe qu'une entité manque au modèle. On la nomme, on lui donne son identifiant et ses attributs propres. Les deux relations qui en partent redeviennent des un-à-plusieurs: entre Police et Prestation, l'entité intermédiaire est la Couverture, qui porte la date d'effet et le taux de participation.

Les métadonnées

Le cinquième élément, facultatif, décrit le modèle lui-même: l'origine et l'usage des entités ainsi que les contraintes de sécurité, de confidentialité et d'audit qui pèsent sur une entité ou sur un groupe entier. Sur un domaine où les entités portent des données de santé, la contrainte de confidentialité portée en métadonnée commande les droits d'accès et les durées de conservation, et elle se recueille auprès du métier au même titre qu'une cardinalité.

Les trois niveaux

Deux modèles du même domaine peuvent différer sensiblement d'un niveau à l'autre, parce que les trois niveaux sont développés dans des buts différents. C'est la distinction que les praticiens confondent le plus souvent, et c'est elle qui décide de qui tient le crayon.

Le modèle de données conceptuel est indépendant de toute solution et de toute technologie. Il montre la façon dont le métier perçoit son information et sert à établir un vocabulaire cohérent pour la décrire. On y trouve les entités du domaine et les relations qui comptent, nommées dans les mots du métier. Ces entités visent déjà une structure implémentable, et c'est ce qui sépare ce niveau du modèle de concepts. Le BABOK note qu'à ce niveau les notations produisent des résultats largement semblables, au point que l'on peut les traiter comme une technique unique.

Le modèle de données logique est une abstraction du précédent qui incorpore les règles de normalisation, afin de gérer formellement l'intégrité des données et des relations. Il demeure indépendant de la plateforme, et il est associé à la conception d'une solution: identifiants, clés étrangères, cardinalités posées. Le type, la longueur et l'index attendent le niveau suivant, parce qu'ils supposent un système de gestion de base de données.

Le modèle de données physique décrit l'organisation physique d'une base sur un système de gestion de base de données donné: tables, colonnes, types, longueurs, index. Ses préoccupations sont la performance, la concurrence et la sécurité, et elles n'ont de réponse qu'en présence de la technologie retenue.

Le niveau conceptuel appartient au business analyst: il ne suppose aucune technologie et les experts du domaine peuvent le confirmer ou l'infirmer. Le niveau logique se partage: le business analyst le lit, le questionne et le valide contre le besoin, l'architecte ou le concepteur de la solution le construit. Le niveau physique appartient à l'administrateur de base de données et à l'ingénieur. Le BABOK le dit dans ses propres termes: les modèles logiques et physiques comportent des éléments propres à la solution qu'ils soutiennent et sont généralement développés par des parties prenantes compétentes dans l'implémentation de solutions techniques particulières.

Normaliser: les trois premières formes

Normaliser, c'est retirer du modèle les redondances qui permettent à la base de se contredire. Si l'adresse de l'assuré est recopiée sur chacune de ses polices, deux polices du même assuré peuvent porter deux adresses différentes, et rien dans la structure ne dit laquelle fait foi. L'opération range chaque attribut auprès de l'identifiant dont il dépend, et une clé étrangère porte la relation entre les entités qui en résultent.

Les règles qui gouvernent l'opération sont les formes normales, énoncées par Edgar F. Codd: la première dans l'article de 1970 qui fonde le modèle relationnel, les deuxième et troisième dans le rapport de recherche de 1971 qui pousse la normalisation plus loin. Chacune ajoute une exigence à la précédente, et les trois premières couvrent ce qu'un business analyst a besoin de vérifier sur le modèle logique d'une application de gestion.

La première forme normale exige que chaque attribut porte une valeur unique et qu'aucun groupe d'attributs ne se répète. Une entité Sinistre qui porterait Prestation 1, Prestation 2 et Prestation 3 la viole. La même information rangée en une seule colonne de codes séparés par des virgules la viole également. Le remède ne varie pas: ce qui se répète devient une entité, reliée à la première.

La deuxième forme normale ajoute que chaque attribut non identifiant dépende de la totalité de l'identifiant, et elle ne mord que sur les entités à identifiant composé. Une entité Couverture identifiée par le couple numéro de police et code de prestation, portant le libellé de la prestation, la viole: le libellé dépend du seul code et se recopie sur chaque police qui inclut cette prestation. Le libellé appartient à l'entité Prestation.

La troisième forme normale ajoute qu'aucun attribut non identifiant ne dépende d'un autre attribut non identifiant. Une entité Police portant à la fois le code de l'assureur et son nom la viole: le nom se déduit du code, et deux polices du même assureur peuvent porter deux noms différents dès que l'un est saisi à la main. Le nom appartient à une entité Assureur identifiée par son code.

Un modèle en troisième forme normale écrit chaque fait à un seul endroit, tient ses relations par des clés et ne fait dépendre chaque attribut que de l'identifiant de son entité. Les formes suivantes, à commencer par la forme normale de Boyce-Codd, traitent des cas de clés candidates multiples: une entité en troisième forme normale qui ne porte qu'une clé candidate satisfait déjà à Boyce-Codd, ce qui est le cas courant dans une application de gestion.

Dénormaliser sciemment

Le niveau physique revient parfois sur la normalisation. Un modèle normalisé répartit l'information entre de nombreuses tables, et toute lecture qui la rassemble paie autant de jointures. Sur une charge dominée par la lecture, tableau de bord, entrepôt de données, rapport réglementaire, la conception physique recopie une valeur pour éviter la jointure, et le schéma en étoile d'un entrepôt est la forme organisée de cette recopie. La contrepartie se paie en cohérence: chaque copie doit être tenue à jour et la conception nomme le mécanisme qui s'en charge, faute de quoi la base retrouve la contradiction que la normalisation lui avait retirée.

Une valeur figée à une date ressemble à une redondance et se supprime à tort. Le montant de la franchise appliquée à un sinistre, inscrit sur le sinistre, a l'air d'une copie de la franchise portée par la police. Ce sont deux faits: la police porte la franchise en vigueur aujourd'hui, le sinistre porte celle qui valait à sa date. Supprimer l'attribut du sinistre fait dépendre l'historique des valeurs courantes, et le premier changement de franchise réécrit le passé.

Modèle de données et modèle de concepts

Un modèle de concepts (BABOK 10.11) capture le sens et le vocabulaire: les termes que le métier emploie, les faits qui les relient et les définitions sur lesquelles l'organisation s'accorde. Un modèle de données capture la structure destinée au stockage et à l'implémentation: les entités, leurs attributs, les clés et les cardinalités. Ronald G. Ross énonce la frontière en une ligne: les modèles de concepts sont centrés sur le concept, les modèles de données sur la chose, l'entité ou la classe. Il ajoute qu'un modèle de données se dérive assez aisément d'un modèle de concepts, alors que le chemin inverse est nettement plus difficile, ce qui est l'argument pratique pour commencer par le vocabulaire quand les termes du domaine sont disputés.

Trois objets voisins portent des noms presque identiques. Le modèle de concepts est la technique 10.11, celle du vocabulaire. Le modèle de données conceptuel est le niveau le plus abstrait, et il demeure un modèle de données: il a des entités et des relations, et il vise à terme une structure implémentable. Le modèle conceptuel de données de Merise, le MCD, désigne pour un lecteur de Suisse romande ce même niveau, dans le vocabulaire propre d'une autre école de modélisation. Le modèle de concepts établit ce que le mot « sinistre » signifie et que la police couvre un sinistre. Le modèle de données conceptuel établit que Sinistre est une entité reliée à l'entité Police, et il ouvre la question du nombre de sinistres qu'une police peut couvrir.

Choisir la bonne notation

Le diagramme d'un modèle de données s'appelle un diagramme entités-relations (ERD), celui d'un modèle de classes un diagramme de classes. Le BABOK tranche en une phrase: on emploie des ERD logiques et physiques pour implémenter une base de données relationnelle, un diagramme de classes logique ou physique pour soutenir un développement orienté objet.

Le critère qui départage est l'artefact que l'on conçoit. Le schéma persistant se conçoit en ERD, la structure du code se conçoit en classes et une application orientée objet posée sur une base relationnelle, qui est le cas ordinaire dans une entreprise suisse, produit les deux modèles: l'ERD pour sa base, le diagramme de classes pour son code. La plateforme du projet laisse la question ouverte, l'artefact la referme.

Deux critères secondaires précisent le choix. Le comportement d'abord: la classe porte des opérations en plus de ses attributs et elle est la seule des deux à les porter, si bien qu'un domaine où le comportement compte autant que la structure se modélise en classes. Le lecteur en aval ensuite, quand le modèle circule entre plusieurs mains: l'administrateur de base de données lit couramment un ERD, le développeur un diagramme de classes et un relecteur venu du métier mais familier des systèmes d'information, responsable de domaine ou analyste de gestion, suit plus volontiers un ERD, dont le vocabulaire reste celui des entités et des relations.

La même relation, deux notations

Le diagramme entités-relations et le diagramme de classes UML écrivent la même information de deux manières. La cardinalité se note le plus souvent en pattes-de-corbeau (crow's foot), notation due à Everest (1976) puis popularisée par la méthode de Barker et les ateliers Oracle, celle que retient la figure du BABOK et celle que l'on trace au tableau blanc.

Les pattes-de-corbeau mettent le dénombrement dans un symbole en deux parties, l'une pour le maximum et l'autre pour le minimum, quand UML l'écrit en clair à l'extrémité de l'association, sous forme d'intervalle. Les deux notations placent la marque du côté de l'entité que l'on compte, si bien qu'une relation se lit dans l'une comme dans l'autre en parcourant le trait vers cette entité.

Sur la relation entre Assuré et Police, l'ERD porte un cercle puis une fourche du côté de la police et deux barres du côté de l'assuré; le diagramme de classes écrit 0..* du côté de la police et 1 du côté de l'assuré. Le fait dessiné est le même, le vocabulaire change: l'ERD parle d'entité, de relation et de cardinalité, le diagramme de classes de classe, d'association et de multiplicité.

Sans transformation explicite de l'un vers l'autre, la cohérence des deux modèles se vérifie à la main: une cardinalité corrigée sur l'ERD ne se propage pas au diagramme de classes.

Une troisième école se rencontre dans les organisations francophones. Merise écrit le même domaine sous la forme d'un modèle conceptuel de données, le MCD, puis le transforme en tables par des règles fixes. Sa cardinalité s'écrit à l'extrémité opposée de celle où les pattes-de-corbeau et UML posent la leur: un modèle transposé d'une école à l'autre sans le savoir affirme l'inverse du domaine.

Le lien avec le dictionnaire de données

Le dictionnaire de données (BABOK 10.12) définit les éléments: le nom unique d'un attribut, ses alias, ses valeurs admises, son format et sa longueur, sa définition dans le contexte de la solution. Le modèle de données donne la structure: quelles entités existent, quels attributs leur appartiennent, comment elles se relient. Les deux artefacts se tiennent par les attributs, et le BABOK note que le dictionnaire est souvent tenu conjointement avec un diagramme entités-relations, dont il peut être extrait. Un modèle sans dictionnaire montre des cases dont personne ne sait ce qu'elles acceptent, un dictionnaire sans modèle donne des champs dont personne ne sait comment ils s'assemblent.

Considérations IA

Un modèle de langage rend deux services sur cette technique. Le premier est la dérivation d'un modèle candidat: il lit le schéma d'une base existante, colonnes, types, contraintes et clés étrangères, ou un corpus de documents d'exigences et de comptes rendus d'entretiens, et il en propose des entités, des attributs et des relations. Sur un système hérité sans documentation, le brouillon obtenu se corrige plus vite qu'une page blanche ne se remplit. Le second est la vérification de la normalisation: signaler un groupe répétitif, une dépendance partielle ou une dépendance transitive est un travail réglé qui se prête bien à la machine. La limite est de nature métier. Ce qu'une entité signifie pour l'organisation et le fait qu'une relation existe réellement dans son activité sont des faits que le métier détient et que le modèle doit refléter. Une machine qui lit un schéma déduit ce que la base contient, y compris les erreurs de structure qu'elle a accumulées; elle ne peut pas confirmer qu'une police couvre bien un seul assuré, parce que la réponse tient à la manière dont l'organisation assure. Toute proposition de l'IA est un brouillon soumis aux experts du domaine.

Coût

Outils

Les outils se séparent sur ce qu'ils gardent, un dessin ou un modèle. L'outil de schéma généraliste donne un diagramme propre et ne contrôle rien, si bien que deux entités peuvent y porter le même attribut sous deux noms sans que rien ne le signale. Il suffit au niveau conceptuel, que le business analyst tient avec le métier et corrige en séance. L'atelier de modélisation de données garde un dépôt où les trois niveaux sont trois vues du même modèle: il génère le script de création de la base, rétro-conçoit le modèle depuis une base existante et le compare au schéma déployé, ce qui fait apparaître l'écart entre les deux. Le catalogue de données prend le relais sur les métadonnées: origine d'une entité, classification des données personnelles ou de santé, durée de conservation. Le niveau physique échappe parfois à ces trois familles, là où la base est tenue par des scripts de migration versionnés à côté du code: la suite des scripts fait foi et le modèle n'est exact que le jour où on le rétro-conçoit.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.15 Data Modelling.
• OMG, Unified Modeling Language (UML) Specification: la spécification qui définit le diagramme de classes et sa notation de multiplicité.
• Peter Chen, « The Entity-Relationship Model: Toward a Unified View of Data », ACM Transactions on Database Systems, vol. 1, n° 1 (1976), pp. 9-36: l'article fondateur du modèle entités-relations.
• Gordon C. Everest, « Basic Data Structure Models Explained with a Common Example », Proc. Fifth Texas Conference on Computing Systems (1976): l'origine de la notation de cardinalité en pattes-de-corbeau.
• Richard Barker, CASE*Method: Entity Relationship Modelling, Addison-Wesley (1990), ISBN 978-0201416961: la variante Barker/Oracle des pattes-de-corbeau et la tradition qui nomme l'optionnalité comme question distincte du maximum de la cardinalité.
• E. F. Codd, « A Relational Model of Data for Large Shared Data Banks », Communications of the ACM, vol. 13, n° 6 (1970), pp. 377-387: le modèle relationnel et la première forme normale.
• E. F. Codd, « Further Normalization of the Data Base Relational Model », IBM Research Report RJ909 (1971), republié dans Data Base Systems, dir. Randall Rustin, Prentice-Hall (1972): les deuxième et troisième formes normales.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge: la référence de la gestion des données, qui emploie les mêmes trois niveaux, conceptuel, logique et physique.
• Ronald G. Ross, « What Is a Concept Model? », Business Rules Journal, vol. 15, n° 10 (2014): l'énoncé de référence de la frontière entre modèle de concepts et modèle de données.