Cas "Bûcherons du Bois-Bernin"  Cas "Back on Tracks Intl" 

LE MODELE ENTITE-ASSOCIATION (4)

4 Validation du modèle

Les quelques règles qui suivent ont pour but d'aider à la validation du modèle. Elles doivent permettre, en étudiant le modèle auquel on est arrivé, de s'interroger pour voir si certaines anomalies plus ou moins graves surgissent et amènent à éventuellement remettre en cause certaines parties du modèle.

4.1. Un même attribut ne peut apparaître à plusieurs endroits dans le modèle

On ne peut trouver à deux endroits différents dans le modèle un même attribut. En effet, ceci voudrait dire qu'une même donnée de base de la réalité est attachée à des objets différents.

Bien souvent, cette règle a comme effet de repérer des attributs effectivement différents mais auxquels on a donné le même nom. C'est facilement le cas pour des attributs tels que "Nom" qu'il faudra préciser en "Nom_Employé", "Nom_Entreprise" et "Nom_Conseiller" comme dans le cas BTI. Le terme de "Date" devra lui aussi être explicité vis-à-vis de ce à quoi il s'applique.

Parfois, au contraire, cette règle permet de mettre en évidence une véritable erreur de modélisation, du type de celle qui apparaît dans la figure 3.5. On y voit que l'entité CONCURRENT contient l'attribut Nom_Equipe qui figure aussi dans l'entité EQUIPE. Or le fait qu'un concurrent appartienne à une équipe est déjà exprimé par l'association Appartenir : cet attribut Nom_Equipe n'a rien à faire dans l'entité CONCURRENT.

4.2. Il ne doit pas y avoir de dépendances fonctionnelles entre parties de l'identifiant

Si l'identifiant d'une entité est constitué de plusieurs attributs, et qu'un sous-ensemble de ces attributs est en dépendance fonctionnelle avec le reste de l'identifiant, alors l'identifiant est incorrect car surdimensionné. L'identifiant doit donc être minimal.

Ainsi, déclarer que l'ensemble "Dossard+Nom+Prénom" est identifiant de l'entité CONCURRENT est correct dans le sens où tous les autres attributs sont bien en dépendance fonctionnelle avec l'ensemble. Mais comme Nom et Prénom dépendent fonctionnellement de Dossard, seul Dossard doit être considéré comme l'identifiant de l'entité, tandis que Nom et Prénom deviennent de simples attributs.

Cette situation peut aussi se produire dans le cas d'associations mal construites soit parce qu'elles ne sont pas en réalité des associations, soit parce que les attributs qu'on leur affecte n'y ont pas leur place.

On évoquera par exemple l'hypothèse, faite au début du cas BTI, que le business account pourrait en réalité constituer une association entre une entreprise, un employé et un conseiller, donc expression de la conclusion d'une affaire pour BTI. La figure 7 exprime cette version envisageable du modèle entité-association.

Figure 7. Business account comme association

La nouvelle association Bus_Account a donc implicitement comme identifiant la somme des identifiants des entités reliées, soit "Num_Employé+ID+Code_Conseiller". Si l'on y regarde de plus près, on constate que dans cet identifiant, ID, c'est-à-dire l'entreprise passant contrat, est en dépendance fonctionnelle du numéro de l'employé : en effet, le fait de connaître un employé permet de dire immédiatement l'entreprise d'où il vient. Donc cet identifiant est mal formé, et en fait la raison en est que l'association Bus_Account est mal formée car le business account a vocation d'être en réalité une entité.

4.3. Exclusion des attributs répétitifs

Comme il a été dit plus haut, on doit se méfier des attributs d'une entité qui répètent la même information pour plusieurs des valeurs qu'elle peut prendre. Un exemple de ce cas a été présenté dans la figure 2 où l'on envisageait, à tort, de créer trois attributs répertoriant les inscriptions aux trois épreuves du concours des bûcherons.

Dans l'exemple BTI, un tel cas aurait pu se produire si l'on avait prévu dans l'entité EMPLOYE deux ou trois groupes d'attributs qui auraient répertorié les diverses entreprises (ID_Emb) ayant éventuellement réembauché l'employé, ainsi que les dates d'embauche correspondantes :

Il faut bien voir qu'outre le fait que les liens naturels entre entités auraient mal été exprimés, on encourt dans de tels cas d'autres inconvénients très gênants. Si par exemple on se place du point de vue de la base de données qui va être implantée sur la base d'un tel modèle, il faudra réserver de la place dans le fichier des employés pour six champs supplémentaires qui prendront au total un minimum de 30 caractères pour ces informations. Or si l'on fait l'hypothèse que 90% des employés sont casés à la première embauche, 9% le sont à la seconde et le reste à la troisième, on se rend compte qu'en moyenne un peu plus de 11 caractères seront réellement utilisés, les autres restant vides. Sur un fichier de 100 employés seulement, on mobilise ainsi 3000 caractères pour 1130 utiles. Si par contre on se fonde sur le modèle construit, l'information sur les embauches sera contenue dans un fichier "embaucher" répertoriant les identifiants Num_Employé et ID plus l'attribut Date_Embauche. On aura en moyenne 1,13 occurrence par employé pour une place requise de 12 caractères, soit un total, 1356 caractères : cela représente 55% d'économie de place. Il faut noter par ailleurs qu'un fichier avec des attributs répétitifs deviendrait difficile à exploiter. C'est ainsi que la recherche des employés ayant été embauchés par une entreprise particulière obligerait à chercher sa valeur dans chacun des trois attributs susceptibles de l'héberger.

4.4. Un attribut ne peut dépendre fonctionnellement d'une partie seulement de l'identifiant

Ce genre de situation apparaît plutôt dans le cas d'associations mal construites. Quand un identifiant comporte plusieurs attributs, on ne peut avoir un attribut non identifiant qui ne dépende fonctionnellement que d'un sous-ensemble de l'identifiant. Soit l'identifiant est incorrect, soit l'attribut n'est pas à sa place.

Supposons que dans le cas BTI nous ayons mis dans l'association Correspondre entre les entités BUS_ACCOUNT et ENTREPRISE les attributs Budget et Date_BA. Le raisonnement, fallacieux, aurait été de dire que cette correspondance, exprimée par l'association, sanctionne une affaire traitée sur la base d'un certain budget et conclue à une certaine date avec une entreprise. Implicitement, l'identifiant de cette association Correspondre est "ID+Num_BA" . Que peut-on dire des dépendances fonctionnelles entre les attributs ajoutés et cet identifiant implicite ? Que Date_BA et Budget dépendent bien fonctionnellement du numéro de business account, mais pas du numéro (ID) de l'entreprise. En effet, le fait de connaître une entrepise par son numéro ne détermine pas de manière unique une telle date ou un tel budget, tout simplement parce qu'une entreprise peut conclure plusieurs affaires avec BTI.

D'une manière générale, et en remarquant qu'il existe une cardinalité "1,1"  — l'autre étant "1,n"  — dans les liens de l'association Correspondre, on dira que dans un tel cas, l'association ne doit pas comporter d'attributs spécifiques.

4.5. Un attribut non identifiant ne doit en principe pas dépendre fonctionnellement d'un autre attribut non identifiant

Il arrive que dans la liste des attributs d'une entité, il soit possible de détecter des liens entre attributs qui ne font pas partie de l'identifiant. Autrement dit, il n'y a pas indépendance entre ces attributs, et le fait de connaître la valeur d'un attribut non identifiant permet de déterminer de manière unique la valeur d'un autre attribut. Il y a donc dépendance fonctionnelle entre attributs n'appartenant pas à l'identifiant de l'entité. Dans ce cas, il y a lieu de se méfier et de se demander si on n'a pas oublié de prévoir une entité spécifique : bien souvent, l'attribut qui est à l'origine de la dépendance fonctionnelle a vocation à devenir une entité.

Il n'y a pas de cas de ce genre dans les exemples BBB et BTI que nous avons étudiés. Mais il est facile d'imaginer des cas où une telle erreur pourrait se produire.

Imaginons le cas d'un étudiant qui suit un programme d'études comportant des cours de base et des cours, par exemple trois, spécifiques à une filière à option. Supposons que l'on ait créé l'entité ETUDIANT suivante :

On voit que l'attribut Filière, qui ne participe pas à l'identifiant (ici le matricule) de l'entité, permet de connaître les trois cours répertoriés dans les attributs Cours_1, Cours_2 et Cours_3. Outre le fait que ces attributs sont répétitifs et suspects au titre de la règle énoncée en 3.2.5.3., on voit de plus qu'ils dépendent fonctionnellement de l'attribut Filière. Cette situation doit nous mettre sur la voie de l'éventuelle adjonction d'une entité FILIERE reliée à l'entité ETUDIANT via une association que l'on nommerait Choisir. Cette entité FILIERE devrait alors permettre de retrouver ses cours spécifiques, probablement à travers une association avec une entité COURS.

Il existe toutefois des cas où l'on hésitera avant de corriger une entité dont les attributs non identifiants sont en dépendance fonctionnelle. Il est évident par exemple qu'une adresse contient une forme de redondance dans la mesure où la connaissance de la ville implique automatiquement celle du canton ou du pays où elle se trouve. Cela n'empêchera pas de faire figurer dans une entité PERSONNE son adresse complète avec les attributs Ville et Pays.

Un autre cas où l'on pourra déroger à la règle concerne les attributs calculés. La Valeur en stock d'un article dépend fonctionnellement de la Quantité et du Prix (car Valeur=Quantité*Prix), deux attributs non identifiants d'une entité STOCK. On a le choix de supprimer cet attribut car on peut toujours le calculer après coup, ou de le maintenir pour éviter ce calcul à chaque accès aux informations stockées. Le choix de maintenir ou non une telle redondance se fera sur des bases techniques, à savoir l'intérêt relatif d'économiser de la place sur disque au prix d'un ralentissement pour calcul à chaque accès, ou réciproquement.

4.6. Eliminer les entités équivalentes à des associations, et les associations redondantes avec une autre association

En général, on a souvent tendance à compliquer un modèle en multipliant entités et associations qui se révèlent à l'usage inutiles. Il y a donc lieu de bien analyser le modèle pour l'épurer au maximum.

On en a un exemple dans le cas BTI à propos de l'association Licencier qui relie un employé à l'entreprise qui le confie à BTI pour préparer sa reconversion. On avait d'ailleurs vu qu'une contrainte d'intégrité devait être respectée, à savoir le fait que l'entreprise qui licencie un employé doit être la même que celle qui correspond au business account regroupant notamment cet employé (voir à la fin du paragraphe 3.2.4.2). En observant le modèle de la figure 3.10, on se rend compte que l'association Licencier fait double emploi avec le couple d'associations Correspondre et Regrouper à travers l'entité BUS_ACCOUNT. On peut donc supprimer cette association sans risque de perdre quoi que ce soit dans la qualité de la représentation. Ce faisant, on évite de devoir adjoindre au modèle une contrainte d'intégrité supplémentaire, cette dernière disparaissant grâce à cette simplication.