216
Chapitre 9 • Le modèle Entité-association
ne pourrait apparaître que dans une seule commande, ce qui serait absurde. Le type
d’entités PRODUIT ne représente donc pas les produits, mais un autre concept qui
reste à découvrir.
Il est aussi important de noter qu’il existe plusieurs natures d’identifiants.
Certains identifiants n’ont pas de signification particulière, et servent essentiellement à distinguer les entités d’un type. Tel est le cas de NCli, NCom et NPro dans le
schéma 9.17. On dira de ces identifiants qu’ils servent de désignateur. Ils sont en
général constitué d’un attribut technique (numéro, code, etc.). L’identifiant de
DETAIL est d’une autre nature. Bien qu’il puisse aussi servir à désigner une entité
DETAIL, il exprime surtout une contrainte d’intégrité qui correspond à une loi du
domaine d’application : une commande enregistrée ne peut citer un même produit
plus d’une fois.
La question se pose souvent du choix de l’identifiant primaire d’un type d’entités.
Il conviendrait que sa valeur soit stable durant la durée de vie d’une entité. Or, s’il
est formé d’attributs qui représentent des propriétés évolutives au cours du temps,
ses valeurs seront naturellement instables. Une règle est souvent appliquée par les
concepteurs de bases de données : l’identifiant primaire est formé d’un identifiant
non significatif, et donc stable. Cette règle favorise les identifiants primaires de désignation.
Citons un exemple (réel) qui clarifie le propos. Une base de données comportait
un répertoire des établissements scolaires. On avait défini pour ces derniers l’identifiant primaire comme suit : code postal de la commune de l’établissement + initiales
du nom de l’établissement. On obtenait ainsi un code compact qui offrait en outre
deux avantages : il était facile à reconstituer pour un établissement connu et il était
possible d’en extraire une information utile sans consulter des données, à savoir la
commune d’implantation. Ce choix qui semblait raisonnable au départ s’est avéré
catastrophique à l’usage. En effet, d’une part, il n’est pas rare qu’un établissement
change de nom et donc d’initiales, et d’autre part, des regroupements de communes
entraînent une modification du code postal de certains établissements. Après quelques années, le logiciel de gestion d’écoles utilisant cette base de données a dû être
transformé suite à cette décision maladroite et en apparence anodine.
9.5 AUTRES CONTRAINTES D’INTÉGRITÉ
Identifiants, cardinalités et attributs obligatoires ne constituent qu’un échantillon
réduit des contraintes dont on voudrait disposer pour modéliser avec précision les
propriétés des entités du domaine d’application. Pour exprimer les autres
contraintes, celles qui n’ont reçu ni nom ni graphisme spécifiques, il faudra faire
appel à un mode descriptif général, informel (en français) ou formel (rédigés sous
forme de prédicats). Nous en donnerons quelques exemples sur lesquels nous
reviendrons plus tard.
Précisons d’abord ce qu’on entend par contrainte d’intégrité : il s’agit d’une
propriété que les objets décrits par un schéma (les entités, les associations et les
valeurs d’attributs) doivent respecter de manière à représenter les situations et le
Chapitre 9 • Le modèle Entité-association
ne pourrait apparaître que dans une seule commande, ce qui serait absurde. Le type
d’entités PRODUIT ne représente donc pas les produits, mais un autre concept qui
reste à découvrir.
Il est aussi important de noter qu’il existe plusieurs natures d’identifiants.
Certains identifiants n’ont pas de signification particulière, et servent essentiellement à distinguer les entités d’un type. Tel est le cas de NCli, NCom et NPro dans le
schéma 9.17. On dira de ces identifiants qu’ils servent de désignateur. Ils sont en
général constitué d’un attribut technique (numéro, code, etc.). L’identifiant de
DETAIL est d’une autre nature. Bien qu’il puisse aussi servir à désigner une entité
DETAIL, il exprime surtout une contrainte d’intégrité qui correspond à une loi du
domaine d’application : une commande enregistrée ne peut citer un même produit
plus d’une fois.
La question se pose souvent du choix de l’identifiant primaire d’un type d’entités.
Il conviendrait que sa valeur soit stable durant la durée de vie d’une entité. Or, s’il
est formé d’attributs qui représentent des propriétés évolutives au cours du temps,
ses valeurs seront naturellement instables. Une règle est souvent appliquée par les
concepteurs de bases de données : l’identifiant primaire est formé d’un identifiant
non significatif, et donc stable. Cette règle favorise les identifiants primaires de désignation.
Citons un exemple (réel) qui clarifie le propos. Une base de données comportait
un répertoire des établissements scolaires. On avait défini pour ces derniers l’identifiant primaire comme suit : code postal de la commune de l’établissement + initiales
du nom de l’établissement. On obtenait ainsi un code compact qui offrait en outre
deux avantages : il était facile à reconstituer pour un établissement connu et il était
possible d’en extraire une information utile sans consulter des données, à savoir la
commune d’implantation. Ce choix qui semblait raisonnable au départ s’est avéré
catastrophique à l’usage. En effet, d’une part, il n’est pas rare qu’un établissement
change de nom et donc d’initiales, et d’autre part, des regroupements de communes
entraînent une modification du code postal de certains établissements. Après quelques années, le logiciel de gestion d’écoles utilisant cette base de données a dû être
transformé suite à cette décision maladroite et en apparence anodine.
9.5 AUTRES CONTRAINTES D’INTÉGRITÉ
Identifiants, cardinalités et attributs obligatoires ne constituent qu’un échantillon
réduit des contraintes dont on voudrait disposer pour modéliser avec précision les
propriétés des entités du domaine d’application. Pour exprimer les autres
contraintes, celles qui n’ont reçu ni nom ni graphisme spécifiques, il faudra faire
appel à un mode descriptif général, informel (en français) ou formel (rédigés sous
forme de prédicats). Nous en donnerons quelques exemples sur lesquels nous
reviendrons plus tard.
Précisons d’abord ce qu’on entend par contrainte d’intégrité : il s’agit d’une
propriété que les objets décrits par un schéma (les entités, les associations et les
valeurs d’attributs) doivent respecter de manière à représenter les situations et le