La lecture de ce texte n'a d'intérêt que si préalablement on a lu le cas "Bûcherons du Bois-Bernin" avec attention...

Cas "Bûcherons du Bois-Bernin"

LE MODELE ENTITE-ASSOCIATION (1)

 

1. Les concepts de la modélisation entité-association

1.1. Entité

RESUME

Une entité est un objet concret ou abstrait de la réalité, sur lequel nous souhaitons connaître et enregistrer des informations qui lui sont spécifiques. Une entité est donc un objet bien précis, identifiable parmi d'autres objets du même type ou de types différents.

C'est ainsi que Monsieur Jean-Marie Gerber nous intéresse dans la modélisation car nous devons gérer des concurrents, et cette personne s'est inscrite au concours. On désire savoir qu'il appartient à l'équipe BBB, qu'il s'est inscrit à certaines épreuves et qu'il obtiendra par la suite certains résultats. Cette personne est une entité différenciable des autres entités de même type, les autres concurrents.

 

Remarque : dans tout ce document, les paragraphes en retrait et colorés  font référence au cas "Bûcherons..." comme illustration des concepts énoncés...

En fait, en termes de modélisation, on ne s'intéresse pas directement à une entité, mais à un "type d'entité". Un type d'entité est le sous-ensemble des objets de la réalité qui regroupe des objets de même nature et jouant le même rôle. A un type d'entité correspond une définition précise, reflet de la réalité qui nous intéresse.

Toutefois, pour simplifier la terminologie, on désignera désormais simplement un "type d'entité" par le terme d'"entité", et on parlera d'"occurrence d'entité" dans le cas d'un individu particulier faisant partie de l'entité. Autrement dit, l'entité sera une sorte de "moule" général décrivant les caractéristiques que possède chaque occurrence particulière. On représentera une entité par un rectangle identifié par le nom de cette entité et comportant les noms des caractéristiques — on parlera par la suite en 1.3. d'"attributs" — auxquelles on s'intéresse. A cette entité correspondront plusieurs occurrences qui auront chacune des valeurs particulières pour chaque caractéristique : chaque occurrence est différente des autres.

RESUME

En définitive, une entité a pour but de regrouper des objets semblables de telle sorte que l'on puisse sans ambiguïté dire si un objet de la réalité appartient ou non à cette catégorie.

L'entité CONCURRENT est représentée ci-dessous. On y a fait figurer certaines caractéristiques qui définissent chaque occurrence telles que Nom_Concurrent, Prénom et Dossard. On y a montré deux occurrences.

L'identification d'une entité est un choix du modélisateur en fonction de ses objectifs vis-à-vis du système d'information auquel il s'intéresse. Plus précisément, on décidera de créer une entité dans le modèle en construction chaque fois qu'il existera des objets distincts mais similaires sur lesquels on désire mémoriser des informations, sachant que ces objets ont des relations avec des occurrences d'autres entités.

La gestion du concours implique que nous organisions des épreuves, entité possédant trois occurrences : rondelle, tirefort et hache. Ces épreuves seront disputées lors de séries qui constituent une autre entité car une part importante de la gestion du concours passe par leur constitution : quels concurrents regroupent-elles, à quelle épreuve correspondent-elles, quand ont-elles lieu ? Par ailleurs, l'existence d'inscriptions aux épreuves par équipes oblige à créer une entité équipe susceptible par la suite d'obtenir un résultat dans chaque épreuve et donc un classement. Ces diverses entités sont représentées ci-après.

Une des difficultés rencontrées dans l'identification des entités utiles dans une modélisation est le fait que l'on peut facilement être tenté de considérer comme objet de base du système d'information quelque chose qui n'est en fait que le regroupement d'informations contenues dans d'autres — véritables — entités. Cela apparaît chaque fois que certains objets identifiables ne sont, en fait, que la synthèse de plusieurs informations existant par ailleurs, ou bien qu'ils sont le résultat de traitements plus ou moins complexes.

On peut par exemple être tenté, au vu des documents de travail utiles pour la gestion du concours, de considérer qu'une entité CLASSEMENT devrait être créée. En effet, il y a plusieurs classements : dans chacune des trois épreuves ainsi qu'en individuel ou par équipes, ce qui pourrait faire penser à six occurrences d'une entité CLASSEMENT. En réalité, un classement n'est qu'un produit de l'ensemble du modèle final qui exploitera l'information sur les concurrents, leurs scores dans les épreuves et qui fabriquera une liste triée sur les scores croissants. Il n'y a rien de spécifique dans "classement" qui n'existerait pas dans le modèle construit; ce n'est pas une entité, c'est le produit d'un traitement particulier.

Parfois aussi, on sera tenté d'attribuer un statut d'entité à un objet bien identifiable du réel perçu, mais que l'on devra éliminer dès que l'on se rendra compte qu'une telle entité ne comporte qu'une seule occurrence. En effet, quel est l'intérêt de créer un objet générique spécial s'il n'a qu'une seule occurrence ?

Un exemple de cette situation se trouve dans l'idée de faire de la notion de "Concours" une entité. Il est certes évident que l'on s'intéresse au concours (des bûcherons du Bois-Bernin), mais en réalité à quoi sert de créer une entité CONCOURS ? A rien, car elle ne serait reliée à rien d'autre dans notre modélisation, qui plus est elle n'aurait qu'une occurrence, notre propre concours. Par contre, une entité CONCOURS deviendrait légitime si, du point de vue du système d'information de la Fédération Helvétique des Bûcherons, il y avait lieu de gérer les divers concours organisés ici et là, et si des informations de type date et lieu du concours, prix offerts, etc. étaient utiles pour cette fédération.

1.2. Association

Une association est une correspondance entre deux (ou plusieurs) occurrences d'entités exprimant une relation entre les deux types d'objets.

De la même façon que pour une entité, on parle d'une manière plus générale d'un "type d'association" pour exprimer la classe de toutes les associations possibles entre deux (ou plusieurs) occurrences d'entités qui vérifient la définition de ce type. Mais pour simplifier la terminologie là aussi, on utilisera le terme d'association pour cette notion de type d'association, et on parlera par la suite d'"occurrence d'une association" pour la relation qui existe entre deux (ou plusieurs) occurrences d'entités.

On représentera une association par un ovale (ou un hexagone) reliant les entités impliquées. Chaque liaison entre une entité et l'association comporte la signification de la relation entre l'entité et l'association.

RESUME

Un concurrent fait souvent partie d'une équipe. Il convient donc d'exprimer ce lien entre concurrents et équipes, deux entités qui ont été identifiées précédemment. C'est ce qu'exprime le concept d'association : nous pouvons donc construire une association, que nous appelerons "Appartenir", reliant CONCURRENT et EQUIPE :

La signification de cette association est simple. Du point de vue de l'entité CONCURRENT, elle dit qu'un concurrent appartient à une équipe. Du point de vue de l'EQUIPE, elle s'interprète comme le fait qu'une équipe est formée de concurrents. Le fait qu'un concurrent ne peut appartenir qu'à une seule équipe, ou à aucune (concurrent isolé), et qu'une équipe est formée de plusieurs concurrents, n'est pas encore exprimé dans cette représentation de l'association. C'est au point 1.6 sur les "cardinalités" que cette spécificité de l'association sera exprimée. Pour compléter cette notion d'association, on énumérera quelques occurrences de cette association Appartenir en se basant sur le document "Liste des concurrents" qui figure à la fin de la présentation du cas :

Gerber Jean-Marie   <===>   BBB

Ruefli Thomas      <===>    BBB

.........                 < ===>   BBB (autres membres BBB)

Longhi Rinaldo          <===>   Boscaioli Ticinese

..........         <===>  Boscaioli Ticinese

..........          <===>    .....

Les autres associations que l'on peut identifier et qui expriment des liens logiques entre les entités sont les suivantes :

Un concurrent est inscrit à une ou plusieurs épreuves. Et réciproquement, une épreuve est disputée par plusieurs concurrents.

Chaque série, qui regroupe des concurrents et a lieu dans une certaine tranche horaire, correspond à une et une seule épreuve parmi les trois. En effet, on ne peut organiser au même endroit et au même moment la compétition sur plusieurs épreuves. Et réciproquement, chaque épreuve donne lieu à plusieurs séries regroupant une douzaine de concurrents.

Il y a une relation entre une série et les concurrents que l'on a regroupés pour concourir dans une épreuve. L'association résultante exprime le fait qu'un concurrent fera partie d'une série, ou de plusieurs s'il est inscrit dans plus d'une épreuve, et que réciproquement, une série regroupe plusieurs concurrents.

De la même façon que pour les concurrents, il est prévu une inscription par équipes débouchant sur un classement par équipes. En conséquence, l'association Inscr_Equipe relie les équipes, qui se sont inscrites, aux épreuves, celles auxquelles chaque équipe s'est inscrite.

Tout ceci nous amène à une toute première version du modèle dans la figure 1 qui répertorie les entités et leurs associations telles que l'on vient de les mettre en évidence. Elle est le résultat d'un arrangement spatial qui parfois n'est pas facile à déterminer.

Figure 1. Les entités et les associations du modèle

Parfois, mais pas souvent, l'association identifiée peut être caractérisée par une ou plusieurs valeurs qui la décrivent. Ou, si l'on préfère, à une occurrence de l'association correspond une ou plusieurs informations attachées à cette occurrence et que l'on doit soigneusement répertorier et représenter dans la modélisation. On verra dans le paragraphe qui suit qu'il s'agit d'un "attribut" de cette association.

Reprenons l'association INSCRIRE, et regardons une occurrence particulière :

Ce qui caractérise le fait que ce concurrent particulier est inscrit à cette épreuve est le fait qu'il va passer cette épreuve et donc obtenir un score sur la base duquel il aura un classement dans cette épreuve. L'information "Score" est évidemment indispensable dans notre modélisation, et sa seule place est justement au sein de cette association INSCRIRE. Ce score de Wild au tirefort n'est pas spécifique de Wild puisqu'il peut avoir plusieurs scores (à chacune des épreuves auxquelles il s'est inscrit). Ce score n'est pas non plus une caractéristique de l'épreuve de tirefort puisque beaucoup de concurrents obtiendront des scores dans cette même épreuve. L'information "Score" n'est en fait spécifique que du couplage — de l'association — d'un concurrent à une épreuve.

1.3. Attribut

Un attribut est une caractéristique d'une entité ou d'une association que le concepteur juge utile ou nécessaire de répertorier dans la réalité perçue et qui prendra une valeur bien précise pour chaque occurrence d'une entité ou d'une association. Dans le schéma du modèle entité-association, chaque attribut aura un nom qui le décrira et figurera au sein des autres attributs dans la partie basse du rectangle pour une entité ou de l'ovale/hexagone pour une association.

Toutefois, on ne répertoriera dans une entité que les seules caractéristiques qui la décrivent spécifiquement et qui ne sont pas déjà explicitement exprimées dans d'autres entités à travers les associations auxquelles elle est reliée. Un exemple illustrera ce point important.

RESUME

Prenons l'entité CONCURRENT. Parmi les informations qui sont à l'évidence caractéristiques de chaque occurrence figurent le nom du concurrent, son prénom et le numéro de dossard qui lui a été attribué au moment de son inscription. On pourrait aussi dire que le nom de l'équipe dont il fait partie le définit également, de même que le fait qu'il est, ou non, inscrit à chacune des épreuves. On pourrait donc envisager la liste des attributs suivants : Nom_Concurrent, Prénom, Dossard, Nom_Equipe, Inscript_Hache, Inscript_Tirefort, Inscript_Rondelle. La figure 3.5 montre l'entité CONCURRENT ainsi que les deux associations Inscrire et Appartenir qui la relient aux entités EPREUVE et EQUIPE.

On voit bien que l'association Appartenir exprime déjà le fait qu'un concurrent fait partie d'une équipe (ou non), donc un attribut "Nom_Equipe" dans l'entité CONCURRENT est inutile et superflu : il ne doit pas figurer dans CONCURRENT.

De la même façon, les trois attributs qui sanctionnent, par un "oui" ou un "non", le fait que chaque concurrent est inscrit à une ou plusieurs épreuves, est déjà exprimé dans l'association Inscrire. Ces trois attributs n'ont donc rien à faire au sein de la description d'un concurrent.

Figure 2. Attributs inutiles (en italiques) dans l'entité CONCURRENT

L'application de cette règle, et l'interprétation des informations données dans le texte de l'étude de cas, amènent à identifier un certain nombre d'attributs utiles et nécessaires qui figurent dans la première version de notre modèle entité-association. Cette version est présentée dans la figure 3.

Figure 3. Version 1 du modèle entité-association : entités, associations et attributs

Un attribut, pour chaque occurrence, prend des valeurs sur un domaine qui précise et limite les valeurs acceptables. On dira alors que l'attribut prend ses valeurs dans un "domaine". On peut citer quelques exemples :

Attribut 

Domaine
nom d'une personne lettres, apostrophe, tiret, espace, longueur 20 caractères au maximum
quantité d'un stock  nombre entier positif
prix d'un article nombre avec deux décimales, positif mais inférieur à 10.000,00
sexe d'un individu  lettre M ou F exclusivement
date d'une commande  jour/mois/année sous la forme jj/mm/aa avec des contraintes sur les valeurs possibles (par exemple "mm" allant de 01 à 12 exclusivement)

La connaissance du domaine d'un attribut est utile et nécessaire d'une part pour décider de la correction d'une donnée, d'autre part pour prévoir la place que prendront les données au moment de l'implantation physique du modèle dans la future base de données. Un attribut peut être :

  • obligatoire : c'est le cas habituel où l'entité possède une caractéristique qui a toujours une valeur connue et impérative. Pour un individu, le sexe est une donnée intangible et préexistante, le nom et le prénom dans l'entité CONCURRENT sont impératifs dès que l'on parle d'une quelconque occurrence de cette entité.

  • facultatif : certaines caractéristiques d'une entité peuvent se révéler indéterminées sans qu'il y ait à redire. Le numéro de téléphone personnel pourra être utile et sera de ce fait un attribut à prévoir, mais il se pourra que pour une occurrence particulière, une personne qui n'a pas de téléphone personnel, cette valeur soit indéterminée.

  • indéfini provisoirement : c'est un attribut dont la valeur n'apparaîtra qu'à un certain moment, dans l'attente duquel sa valeur restera indéfinie. Par exemple, le "Score" obtenu par un concurrent à une épreuve ne sera connu qu'à l'issue de son passage dans une série.

  • indéfini conditionnellement : dans ce cas, un attribut n'aura une valeur que pour autant qu'un autre attribut ait une valeur particulière. Un cas évident serait celui de l'attribut "nom de jeune fille" forcément indéfini conditionnellement car n'apparaissant pas pour un individu de sexe masculin.

  • élémentaire quand on ne peut pas le décomposer en d'autres attributs.

  • décomposable si on peut lui faire correspondre un ensemble équivalent d'attributs élémentaires. Par souci de simplicité et d'économie à ce niveau initial de modélisation, on pourra se contenter de créer un attribut "Adresse" dont on sait qu'il serait décomposable en des attributs élémentaires tels que numéro et rue, ville, code postal et pays.

  • simple s'il fait référence à une caractéristique unique de l'entité.

  • répétitif s'il peut prendre plusieurs valeurs incitant à le démultiplier en plusieurs attributs de même nature.

Il est bon de s'attarder sur cette question des attributs répétitifs en prenant un exemple général. Si l'on s'intéresse aux sports pratiqués par un individu, un attribut tel que "Sports_Pratiqués" pourrait prendre plusieurs valeurs. Une solution consiste à ne prévoir qu'un seul attribut qui serait de type alphanumérique : on ménagerait suffisamment de place pour énumérer les divers sports envisageables qui figureraient dans cet attribut. L'autre solution consiste à prévoir plusieurs attributs qui prendraient alors les noms "Sport1", "Sport2", ... Sachant qu'une personne peut pratiquer un, plusieurs sports ou encore aucun, le problème devient celui de définir le nombre de sports auquel on s'intéresse. Ces deux options de structuration des données de base sont envisageables mais avec beaucoup de précautions. En effet, si on a besoin par la suite de faire des exploitations du système d'information orientées sur ces sports pratiqués par les individus, alors on rencontrera des difficultés. Où retrouver la valeur "Tennis" dans le texte de l'attribut "Sports_Pratiqués", ou bien parmi les multiples attributs "Sport1", "Sport2" et "Sports"" que l'on aura ménagés ? Comme on le verra par la suite, l'existence d'attributs répétitifs doit toujours être mise en cause pour voir si en fait il ne manque pas dans la modélisation une entité à créer. Dans le cas précédent, n'est-il pas judicieux de créer une entité SPORT qui serait reliée à l'entité INDIVIDU par l'association Pratiquer ?

Dans l'entité CONCURRENT, ce problème d'attributs répétitifs peut se poser initialement. Pourquoi ne pas créer trois attributs dans l'entité CONCURRENT qui seraient "Score_Tirefort", "Score_Rondelle" et "Score_Hache" ? Ces trois attributs sont bien des caractéristiques de chaque concurrent... Ce serait acceptable si en fait l'entité EPREUVE n'était pas un objet nécessaire du réel perçu : tout le problème du concours étant justement d'organiser et de gérer des épreuves, on ne peut se passer d'une telle entité. Comme l'indique la figure 3.6, cette information sur les scores est caractéristique de l'association Inscrire, et l'attribut "Score" lui appartient donc.

RESUME

1.4. Identifiant

A partir du moment où l'on a mis en évidence une entité, on a en fait défini une manière de trier les objets de la réalité pour les classer, ou non, comme faisant partie de l'entité. Et donc, chaque occurrence doit pouvoir être repérée de manière unique et sans ambiguïté et distinguée de toutes les autres. En effet, chaque occurrence d'une entité est un objet concret et unique —Monsieur Jean Dupont ou la commande 1234 — que l'on désire répertorier individuellement. C'est le rôle de l'identifiant d'une entité.

RESUME

L'identifiant d'une entité est un attribut, ou un ensemble d'attributs, qui permet de repérer une occurrence d'une manière unique. Autrement dit, parmi toutes les occurrences d'une entité, on ne peut pas en trouver deux qui aient la même valeur de l'identifiant : il ne peut y avoir deux "Monsieur Jean Dupont, celui qui habite à tel endroit et qui est né tel jour". On parle aussi de clé, terme synonyme d'identifiant.

On représente l'identifiant d'une entité en soulignant l'attribut, ou l'ensemble des attributs, qui le constitue(nt), et en général, on le fait figurer en tête de la liste des attributs d'une entité.

En ce qui concerne un concurrent, on pourrait se dire que l'ensemble du nom et du prénom peut constituer l'identifiant de l'entité CONCURRENT car il y a peu de chances que deux concurrents aient le même nom et le même prénom. Toutefois, cette coïncidence n'est pas impossible. Par ailleurs, on nous dit que chaque concurrent se voit attribuer un "dossard" : il s'agit probablement d'un numéro unique pour chaque concurrent. Le dossard, étant une caractéristique de chaque concurrent, est donc un attribut; compte tenu de son unicité, cet attribut a la vocation évidente pour devenir l'identifiant de l'entité CONCURRENT. Toutefois, cette constatation serait moins évidente si l'Association des Bûcherons du Bois-Bernin désirait utiliser le système d'information à mettre en place pour les différents concours annuels qui vont se dérouler dans le futur, et souhaitait gérer des concurrents participant chaque année au concours : dans ce cas, il n'y a que peu de chances pour que le numéro de dossard reste le même d'une année sur l'autre. Mais rien ne suggère dans le texte que tel est le cas.

Souvent, on sera amené à créer de toutes pièces un identifiant pour une entité. En effet, même si on ne disposait pas du dossard pour identifier un concurrent, le fait de faire de "nom+prénom" l'identifiant présente des difficultés : il devient nécessaire pour sélectionner un concurrent particulier dans la future base de données d'indiquer le nom complet ainsi que le prénom, ce qui est long et présente le risque d'une erreur d'orthographe. On a donc intérêt à créer un attribut particulier comme "Numéro_Personne" qui constituera l'identifiant de l'entité. On peut alors se poser la question de la nature de cet identifiant.

D'une manière générale, on aura souvent intérêt à créer un simple "Numéro" (de commande, d'article, de fournisseur, ...) sans signification particulière, on dira sans "sémantique" dans la mesure où ce numéro n'aura pas d'interprétation possible vis-à-vis de l'occurrence qu'il identifie. Parfois, on souhaitera au contraire que cet identifiant permette, à sa lecture, de dire quelque chose sur l'occurrence qu'il représente. Ce faisant on pourra profiter de ce qui existe déjà et qui n'a pas besoin d'être inutilement compliqué. Si l'on parle d'une entité ROUTE, pourquoi se passer du nom habituellement adopté tel que A7 ou N90 pour l'autoroute en question ou la route nationale 90 : de telles dénominations sont familières et sans ambiguïté. Mais si un tel identifiant est à créer, alors il ne faudra déroger qu'avec précaution à la règle d'un simple numéro sans signification. Un identifiant d'article en stock qui ferait référence à la place où il est stocké dans l'entrepôt serait pratique pour retrouver facilement cet article. Mais un tel identifiant est dangereux car il y a de bonnes chances pour que dans la vie de cet article, il change de place...

RESUME

En ce qui concerne une association, elle a aussi un identifiant qui permet de reconnaître de façon unique une occurrence de cette association. Mais cet identifiant est implicite. C'est en fait l'ensemble des identifiants de chaque entité reliée par cette association.

Ainsi, l'identifiant de l'association Inscrire est le regroupement de l'identifiant "Dossard" de l'entité CONCURRENT et de l'identifiant "Num_Epreuve" de l'entité EPREUVE, donc "Dossard+Num_Epreuve". Ainsi, on identifie dans l'association Inscrire les épreuves d'un concurrent aussi bien que les concurrents inscrits à une épreuve :

Mais bien évidemment, dans cette association, on ne doit pas trouver deux occurrences de même identifiant : cela voudrait dire qu'on trouve le même concurrent inscrit deux fois dans la même épreuve, ce qui est inacceptable.

1.5. Dépendances fonctionnelles

On dira qu'un attribut B d'une entité (ou d'une association) dépend fonctionnellement d'un autre attribut (ou groupe d'attributs) A de cette entité (ou association) si pour toute occurrence et à tout instant, la connaissance de A détermine une valeur unique de B. On exprime cette dépendance de la façon suivante :

A ===> B

Dit d'une autre manière, la connaissance de la valeur de l'attribut A détermine automatiquement la valeur de B, et ceci est valable pour n'importe quelle occurrence.

Ainsi, la connaissance d'un numéro de dossard détermine le nom et le prénom du concurrent qui le porte, ce que l'on écrira de la façon suivante :

Dossard ===> Nom_Concurrent

Dossard  ===>Prénom

De la même façon, on pourra dire que :

Dossard, Num_Série ===> Ordre_Passage

car si l'on connaît le numéro de dossard d'un concurrent et la série dans laquelle il passe une épreuve, on en déduit automatiquement son ordre de passage dans cette série. Ceci est exprimé dans l'association Faire_Partie.

L'analyse des dépendances fonctionnelles entre attributs est un moyen d'analyser une modélisation et de faire en sorte qu'elle soit correcte, comme on le verra plus loin en 3.2.5 à propos de la validation d'un modèle. D'ores et déjà, on peut dire que cette analyse des dépendances fonctionnelles est un moyen de déterminer d'une part à quelle entité-association appartient un attribut, et d'autre part si un attribut est identifiant d'une entité.

1.6. Cardinalités

Un aspect particulièrement important de la modélisation, expression d'une réalité, consiste à valoriser les liaisons entre entités et associations en termes de nombre d'occurrences minimum et maximum qui peuvent ou doivent exister. C'est ce que l'on entend par cardinalités, et cet élément de la modélisation consiste à inscrire sous chaque trait reliant une entité et une association les deux nombres minimum et maximum d'occurrences de l'association pouvant être générées par chaque occurrence de l'entité.

Plus pragmatiquement, les questions que l'on se pose sont les suivantes. Si l'on prend une occurrence d'une entité et que l'on regarde dans combien d'occurrences d'une association avec une autre entité elle peut figurer, on doit déterminer les nombres suivants :

  • au minimum, peut-elle apparaître dans 0 ou 1 occurrence de l'association ? Ce qui veut dire qu'elle peut ne pas apparaître (0) ou bien qu'elle apparaît au moins une fois (1).

  • au maximum, peut-elle n'apparaître qu'une seule fois (1) ou bien plusieurs fois (n) ?

Autrement dit, les cardinalités que l'on pourra trouver entre une entité et une association pourront prendre les valeurs "0,1" ou "1,1" ou "0,n" ou "1,n" dans lesquelles les deux nombres séparés par une virgule sont les cardinalités minimum et maximum respectivement. Il est important de comprendre que dans une association entre deux entités figureront des cardinalités de part et d'autre de l'association : chaque couple de cardinalités exprime le point de vue d'une occurrence d'une entité susceptible d'être associée à des occurrences de l'entité se situant de l'autre côté de l'association. Des exemples préciseront cette détermination.

RESUME

Prenons l'association Appartenir qui relie un concurrent à une équipe. On l'a représentée avec les cardinalités découlant de l'analyse du cas. Les cardinalités "1,n" entre une équipe et un concurrent signifient qu'à une équipe correspond au moins un concurrent, et donc qu'il n'existe pas d'équipe que l'on ne pourrait associer à aucun concurrent. C'est logique, car pourquoi s'intéresser à une équipe sans membres ?... Donc au minimum, une équipe a un concurrent. Et au maximum ? Le terme même d'équipe exprime bien le fait que l'on s'attend qu'à une équipe on puisse associer plusieurs concurrents, d'où la cardinalité maximum "n".

Si maintenant on se place du point de vue d'un concurrent particulier, peut-il n'appartenir à aucune équipe ou bien doit-il appartenir à au moins une équipe ? La lecture du cas est claire à cet égard : il y a des concurrents en individuel et qui donc n'appartiennent à aucune équipe. Donc la cardinalité minimum est de 0. Et pour la cardinalité maximum, on se pose la question de savoir si un concurrent peut appartenir à une seule équipe au maximum ou bien s'il peut être associé à plusieurs équipes. Là aussi, la réponse va de soi : un concurrent ne peut appartenir au plus qu'à une seule équipe, donc 1. Et les cardinalités entre Appartenir et CONCURRENT sont donc "0,1".

La figure 4 donne la version finale de notre modèle entité-association enrichi de toutes les cardinalités dont on résume ici les significations.

Figure 1.4. Le modèle entité-association complet

  • Un concurrent s'inscrit à au moins une épreuve (sinon, ce n'est pas un concurrent) et éventuellement à plusieurs (1,n).

  • Une épreuve fait l'objet d'une inscription d'un concurrent au moins (sinon elle n'a pas lieu d'exister), et en général elle a plusieurs concurrents inscrits (1,n).

  • Une épreuve donne lieu à plusieurs séries (association Correspondre) et à au moins une (1,n), tandis qu'une série correspond à une et une seule épreuve car on ne peut mélanger plusieurs épreuves différentes dans la même série (1,1).

  • Un concurrent fait partie (dans l'association Regrouper) d'une série au moins, voire plusieurs selon le nombre d'épreuves auxquelles il s'est inscrit (1,n), et réciproquement une série regroupe au moins un concurrent (sinon elle n'a pas lieu d'être) et habituellement plusieurs (1,n).

  • Une équipe (dans l'association Inscr_Equipe) peut n'être inscrite à aucune épreuve (on peut imaginer que ceci est envisageable bien que ce point ait besoin d'être précisé), ou bien à plusieurs (0,n), tandis qu'une épreuve doit être disputée par au moins une équipe, et en fait plusieurs sinon il n'y a plus de classement possible (1,n).

Outre le fait que les cardinalités sont un des éléments importants pour représenter la signification et la structure de l'information, leur connaissance se révélera utile ultérieurement pour déduire au niveau de l'implantation physique de la base de données le volume des données à stocker.

1.7. Contraintes d'intégrité

Les éléments de modélisation introduits jusqu'à présent ne peuvent prendre en compte un certain nombre de faits spécifiques de la réalité à appréhender. Certaines relations entre les données ne peuvent s'exprimer qu'à travers des contraintes d'intégrité qui viennent se juxtaposer au modèle entité-association tel que construit jusqu'à présent. Une contrainte d'intégrité est donc une propriété particulière que doivent satisfaire les données; elle s'énonce sous la forme d'une règle logique textuelle.

La notion de "domaine" d'un attribut déjà exposée est en elle-même une forme de contrainte d'intégrité, par exemple le fait qu'un prix doit être positif, ou que le numéro d'un mois doit rester inférieur ou égal à 12. Mais bien d'autres contraintes d'intégrité doivent être répertoriées pour bien exprimer les particularités du système d'information.

RESUME

Une contrainte d'intégrité peut être statique si on doit la satisfaire à tout moment. Une date de début, par exemple, doit toujours être antérieure à une date de fin. On parlera de contrainte dynamique chaque fois que cette contrainte devra être validée au moment d'une mise à jour d'une information. Si par exemple les règles régissant le prêt de livres dans une bibliothèque interdisent le prêt de plus de trois livres, le système d'information devra empêcher qu'un utilisateur emprunte un nouveau livre s'il en a déjà trois en prêt. De même, si une personne est employée pendant une journée complète à une tâche, on ne pourra lui affecter une autre tâche le même jour. On parlera enfin d'intégrité référentielle pour exprimer le fait que dans une association, on ne peut trouver une occurrence qui fasse référence à un identifiant inexistant d'une entité associée. Par exemple, on ne peut associer un article acheté à un fournisseur si ce fournisseur n'existe pas.

On peut repérer dans la situation de gestion du concours un certain nombre d'informations qui ne peuvent trouver leur place dans le modèle entité-association auquel on est arrivé. En voici quelques-unes :

  • Pour pouvoir concourir dans une épreuve, une équipe doit avoir au moins trois concurrents qui ont disputé l'épreuve.

  • Tout concurrent inscrit à une épreuve (association Inscrire) doit être affecté à une série (association Regrouper) correspondant à cette épreuve.

  • De la même façon, une série ne doit regrouper que des concurrents qui se sont inscrits à l'épreuve correspondante (dans l'association Correspondre).

  • Une série ne doit pas regrouper plus de 12 concurrents.

  • Un concurrent ne peut pas faire partie de deux séries ayant lieu au même moment car il ne peut se trouver à deux endroits à la fois puisque les épreuves se déroulent sur des lieux différents.

1.8. Intérêt du modèle conceptuel des données

Il est bon de s'interroger maintenant sur la démarche qui a été suivie pour voir ce qu'elle apporte à la construction du système d'information. Construire un tel modèle n'est pas un simple exercice de style, c'est un véritable outil garantissant la qualité de ce qui sera concrètement construit sur sa base. En effet, un tel modèle est tout d'abord un moyen de communiquer, de dialoguer, d'argumenter et d'approfondir la compréhension de la réalité. C'est une abstraction condensée, organisée et rigoureuse de ce qui au départ n'était qu'un discours vague et confus — le texte de l'étude de cas ou bien l'enquête que l'on aurait préalablement effectuée.

Bien que rien en ce monde ne soit intangible, ce modèle a essayé de capturer une certaine permanence dans la signification de l'information manipulée. Il a donc une certaine robustesse et il aura une pérennité quels que soient les traitements nouveaux qui seront effectués par la suite. Illustrons ce point.

Que se passe-t-il si les organisateurs du concours décident de créer une quatrième épreuve ? Beaucoup de choses pour l'organisation, mais rien pour notre modèle : il ne bougera pas, seule une quatrième occurrence de l'entité EPREUVE viendra sanctionner cette nouveauté. Et si le succès du concours est explosif et que le nombre de concurrents augmente considérablement ? Un calcul simple montre qu'actuellement on ne peut dépasser le cap des 84 concurrents (dans l'hypothèse de leur inscription à toutes les épreuves) à 252 concurrents (à raison d'une seule épreuve par concurrent). En effet, il y a 7 tranches horaires dans lesquelles on peut monter 3 séries de 12 concurrents. En termes d'organisation, le dépassement de ce nombre maximum se traduirait par la mise sur pied en parallèle de séries d'une même épreuve sur des sites doublés. Mais le modèle quant à lui ne sera pas affecté, si ce n'est l'obligation d'ajouter à l'entité SERIE un nouvel attribut "Site" décrivant l'endroit où la série aura lieu.

Dans l'élaboration du modèle conceptuel de données, on fait autant que possible abstraction des traitements à effectuer sur ces données : c'est l'idée de départ qui vise à travers cette modélisation à assurer une indépendance entre les données et les traitements.

Dans le cas du concours, on a très vite écarté les notions de classements, en individuel et par équipes, bien qu'à la lecture on sente bien qu'il s'agit là d'une préoccupation majeure des organisateurs : comment faire en sorte que les classements soient correctement et rapidement effectués ? On avait justifié la mise à l'écart de ces notions par le fait que l'information permettant l'élaboration des classements était en principe contenue dans la structure des données. Vérifions cela.

L'établissement du classement individuel va consister à parcourir toutes les occurrences de l'association Inscrire pour une épreuve particulière, puis à les trier par ordre croissant de score (attribut de cette association) et enfin à récupérer par l'intermédiaire du numéro de dossard dans l'entité CONCURRENT les noms et prénoms des concurrents. Tout y est pour faire ce classement. Il en va de même pour le classement par équipe, un petit peu plus compliqué à établir à cause de la moyenne sur les trois meilleurs concurrents d'une équipe.

Ce cas montre aussi d'autres documents utiles pour le concours, tels que la liste des concurrents avec leur équipe et les épreuves auxquelles ils sont inscrits. Là aussi, toute l'information est disponible et aisément accessible.

Quel que soit le soin mis à séparer données et traitements, il arrive un moment où la sémantique de l'information n'arrive plus à être exprimée dans ce modèle. Ceci est déjà apparent avec les règles d'intégrité que l'on a été amené à énumérer. Il est bon toutefois, dans cette conclusion sur l'approche suivie, de dire que le modèle entité-association que l'on a présenté ici n'est qu'une version simplifiée et minimale. En effet, le modèle entité-association possède des extensions importantes qui lui permettent de prendre en compte des situations plus complexes. Il n'est pas dans les intentions de cet ouvrage d'aller au-delà de cette version de base, sachant que le lecteur intéressé trouvera des éléments supplémentaires dans d'autres ouvrages.