|
La construction des applications informatiques a été grandement facilitée par la
mise au point de deux techniques : les systèmes de gestion de bases de données
(SGBD),
qui ont mis de l’ordre dans le stockage et la recherche des données, et les
moniteurs transactionnels, qui pilotent la communication entre le système et ses
utilisateurs.
Les bases de données sont ainsi aujourd’hui l’un des piliers de l’informatique.
Si la réalisation d’un SGBD est une affaire hautement technique, les principes
selon lesquels il est construit devraient, eux, pouvoir être aisément compris.
Or le vocabulaire qu'utilise la profession gêne leur compréhension. On peut même
juger dangereuse la façon dont les bases de données sont présentées. Certes,
quelqu'un de rigoureux et d'intelligent pourra toujours s'en sortir sans
dommage, de même qu'un funambule bien exercé marche naturellement sur un fil.
Mais les autres risquent de se casser la figure. Voici les points que je crois
périlleux.
Choix des populations à observer
Lorsque l'on considère le monde de la nature, et que l'on veut en bâtir une
représentation, il faut choisir les populations que l'on veut y voir figurer («
les clients», « les produits », « les salariés » etc.), et le monde comporte
bien d'autres populations dont on fera abstraction.
Or dans le langage des bases de données on ne voit pas apparaître de terme qui
désignerait ces « populations » et leur théorie n’évoque pas la façon dont il
convient de choisir les populations que l'on observera. Elle suppose que ce
choix a été fait avant que l'on n'entreprenne de construire la base de données.
Pourtant il ne va pas de soi, et il peut être erroné. L'étude des systèmes
d'information montre que nombre d'entreprises ont longtemps été réticentes à
considérer la population que forment leurs clients, et cela se révèle si l'on
examine les identifiants : souvent les clients ne sont pas identifiés.
En fait la méthode la plus courante de conception d'une base de données
considère essentiellement les contraintes formelles auxquelles toute base doit
obéir, et elle omet « implicitement » les questions sémantiques.
Une telle omission n’a en principe rien de critiquable, puisque cette méthode ne
prétend pas plus s’intéresser à la sémantique qu'un langage de programmation ne
s’intéresse à l’adéquation des applications aux besoins des utilisateurs. Le
problème, c’est qu’ici l’omission est implicite. La théorie en matière de
conception de base de donnée doit donc être complétée par des études sur la
qualité des données, l'architecture des processus, la culture d'entreprise etc.
Choix des données
Elmasri et Navathe définissent ainsi les données (p. 4) : « known facts that can
be recorded and that have implicit meaning ». Certes, il ne faut pas se battre
sur la définition d'un terme aussi général et d'ailleurs, comme l’a dit Aristote
lui-même, « il ne faut pas chercher à tout définir».
Cependant quand une définition est énoncée on peut tenter de voir l'orientation
qu'elle indique.
Ici, la définition ignore que (1) la liste des attributs résulte d'un choix qui
ne va pas plus de soi que celui des populations que l'on observera, et qui peut
lui aussi être erroné (on observe des attributs inutiles, et on n'observe pas
ceux dont on aurait besoin) ; (2) la façon dont on code les attributs que l'on a
sélectionnés résulte d'un autre choix (pour un attribut qualitatif comme
l'activité économique d'une entreprise, ou la catégorie sociale d'une personne
il faut définir une classification, et les critères formels ne suffisent pas à
définir ce qu'est une « bonne » classification) ; là encore le choix peut être
erroné (la classification, ou nomenclature, peut ne pas permettre le
discernement que le raisonnement, ou l'action, réclament) ; (3) la donnée
elle-même, telle qu'elle est notée dans la base de données, résulte d'une
observation dont elle enregistre le résultat (et qui peut être exacte ou
erronée).
Il faut enfin distinguer parmi les données : (1) les identifiants, (2) les
données observées, entrées du système d'information, (3) les données que le SI
produit en appliquant des calculs aux données observées. Chacune de ces
catégories de données relève d'une gestion spécifique. Certes la théorie des
bases de données reconnaît cette distinction,
mais souvent les informaticiens ont, en pratique, tendance à considérer
les données comme une matière pondéreuse indifférenciée analogue à du charbon et
que l’on traite au volume, ce qui les empêche de bien distinguer les catégories de données
pour les traiter différemment selon leur importance et leur éventuelle
fragilité.
Derrière la définition de la « donnée » par Elmasri et Navathe se devine une
priorité : il s'agit de construire et gérer une base de données en supposant
déjà réalisé le choix des populations, des attributs, des classifications,
ainsi que des méthodes qui garantissent la qualité des observations. On ne se
pose donc plus de questions sur la pertinence sémantique, sur le sens ou
l'utilité pratique des données ; on ne considère que les questions de physique,
de cohérence formelle que suppose la maîtrise des traitements et des
performances ainsi que celle des « couches basses » de la plate-forme technique.
Ce sont là des questions importantes et
intéressantes, mais une base de données, aussi bien gérée et formellement
correcte qu'elle soit, sera de peu d'utilité si les populations et les attributs
ont été mal choisis. Or cela se produit souvent : comme on croit que ces choix
vont de soi, on les fait à la va-vite.
Homonymies
Le langage des bases de données comporte des termes pour désigner la façon dont
on décrit l'individu type d'une population ; mais ces termes varient selon le
modèle considéré. Ce sera « type d'entité » dans le modèle entité-association,
« classe » dans le modèle objet, « relation » dans la base de donnée
relationnelle ; dans ces trois modèles, l'individu lui-même sera représenté
respectivement par une « entité », un « objet » et un « tuple ».
Il vaut mieux dire « modèle entité-association » plutôt que « modèle
entité-relation ». Lorsque les auteurs de la méthode Merise ont traduit
« entity-relationship model » par « modèle entité-relation », ils ont pris le
risque d’une confusion avec la « relation » du SGBD relationnel qui est tout
autre chose.
Dans un modèle entité-association en effet, l'association est comme dans
le langage courant ce qui relie deux individus [par exemple : « Jean-Pierre
Martin » (individu) « possède » (association) « le piano Pleyel n° 134878-80 »
(individu)].
Par contre dans la base de données relationnelle le mot relation est pris
dans le sens qu'il a paraît-il en théorie des ensembles : il désigne un
tableau contenant, pour une liste d'individus appartenant à une même
population, les valeurs des attributs que l'on a choisi d'observer sur cette
population. Il peut aussi désigner un tableau contenant la description d'un
ensemble d’associations : par exemple, un tableau intitulé « possession » dans
lequel on trouverait les attributs « possédant », « possédé », « date de début »
et éventuellement « date de fin », pour décrire l’association entre les
propriétaires et les biens qu'ils possèdent.
Tout cela se classe à peu près bien dans la tête une fois que l'on a compris,
mais le fait que le mot « relation » joue deux rôles différents selon le modèle
que l'on utilise ne facilite pas la communication avec les personnes inexpertes.
L'individu passe après l'attribut
L'algèbre relationnelle, utilisée pour mettre en forme les calculs que l'on
réalise sur une base de données relationnelle, comporte beaucoup plus
d'instructions applicables aux attributs que d'instructions applicables aux
individus. Il en est de même des « formes normales » qui condensent les
contraintes formelles auxquelles une base de données doit obéir. On ne mentionne
qu'en passant le fait que les données rassemblées dans un « tuple » (i. e. dans
une ligne de la relation) sont relatives au même individu.
Si l'on avait suivi la démarche qui part de la population pour aller vers
l'individu, puis ensuite seulement vers les attributs, on aurait abordé la
relation non pas par colonne (par attribut) mais par ligne (par individu).
La qualité du codage se vérifie d'abord, il est vrai, attribut par attribut (un
codage doit être conforme au type requis pour l'attribut). Mais il faut aussi
vérifier la cohérence de certaines données individu par individu (exemple :
exactitude des additions), et pour calculer les intervalles de vraisemblance
nécessaires au repérage des anomalies il faut évaluer des corrélations, ce qui
nécessite de considérer la co-occurrence des valeurs prises par les divers
attributs dans chaque individu.
Faiblesse de l'identification
Le fait que l'on accorde plus d'importance aux attributs qu'aux individus se
manifeste clairement lorsque l'on parle des identifiants, ou « clés ». On dit
que dans chaque relation il doit exister un attribut, ou une combinaison
d'attributs, qui permette d'identifier chaque tuple de façon univoque.
Cela peut marcher, et cela marche si c'est bien fait, mais une telle formulation
invite à l'erreur. Certes l'identifiant n'est, formellement, qu'un attribut
parmi les autres ; mais il joue en pratique un rôle tellement important que l'on
ferait mieux de l'isoler pour le traiter d'une façon particulière. Par ailleurs,
il est périlleux de prendre pour identifiant un attribut existant ou une
combinaison d'attributs, même s'ils permettent d'identifier chaque tuple de
façon univoque : qui sait si, la population évoluant, le caractère univoque de
l'identification pourra être conservé avec ces attributs-là ?
On peut tolérer que des attributs soient pris comme identifiants lors de la
discussion entre les informaticiens et les utilisateurs, car c'est plus
intuitif. Mais lorsque l'on passera au modèle logique puis au modèle physique,
il sera impératif de prendre un identifiant dépourvu de signification et
construit de façon aléatoire.
Ambiguïté du « null »
On note « null » un attribut quand (1) l'attribut n'aurait pas de sens pour
l'individu considéré (une personne qui n'a pas d'emploi ne peut pas avoir de
téléphone professionnel) ; (2) il aurait un sens mais on ne sait pas s'il existe
(cette personne a un emploi mais on ignore si elle a un téléphone professionnel)
; (3) il aurait un sens mais il n'existe pas (elle a un emploi mais elle n'a pas de téléphone
professionnel) ; (4) il existe, mais on ignore sa valeur (elle a un téléphone
professionnel, mais on ne connaît pas le numéro). Je ne suis pas sûr d'avoir
fini la liste des significations possibles du code « null ».
Elmasri et Navathe disent (p. 343) que l'on a tenté de construire des SGBD
qui distingueraient les diverses acceptions de « null », mais comme c'était
compliqué on y a finalement renoncé. C'est une faiblesse des SGBD relationnels,
car à chacune de ces acceptions correspondent des contraintes de gestion
différentes. Certaines bases de données sont aussi désertes qu'une plage
anglaise en plein hiver, remplies (si l'on peut dire) de champs vides que l'on
ne sait comment interpréter. Il s'agit là d'un point technique, moins
important que les précédents – et rien n'est d'ailleurs sorti des nombreuses
thèses de doctorat consacrées à ce sujet, modèles probabilistes à l'appui.
|
