conception d'un schéma entité-association

C H A P I T R E 3

C o n c e p t i o n d ' u n S c h é m a E n t i t é - A s s o c i a t i o n Dans ce chapitre, nous proposons quelques règles pour guider le concepteur lors de la définition du schéma conceptuel entité association d'une (nouvelle) base de données. Les concepts proposés (dépendances, règles) sont volontairement définis de façon non exhaustive. Un traitement complet de ces concepts dépasse le cadre du cours.

1. Aperçu général de la méthode Nous proposons de construire dans un premier temps le diagramme représentant le schéma en cours d'élaboration (étapes 1 et 2), puis de transcrire ce diagramme en schéma (étape 3) en apportant les précisions supplémentaires sur les éléments qui ne sont pas représentés graphiquement (définitions libres de la sémantique des TE, TA et attributs, définition des domaines des attributs simples, contraintes d'intégrité, ...). 1.1. Construction progressive du diagramme entité association Le concepteur étudie l'existant et les besoins de l'entreprise en recensant les fiches, formulaires, bordereaux,..., utilisés jusqu'à présent dans l'entreprise et en interviewant les personnes de l'entreprise sur les informations qu'elles utilisent et dont elles aimeraient disposer. Le concepteur établit ainsi progressivement la liste des types d'entités, sous-types, types d'association, attributs, règles d'intégrité et de gestion (règles décrivant les traitements dans cette entreprise). Le diagramme entité association est ainsi construit progressivement, en précisant pour chaque type sa définition. Exemple: dans une bibliothèque, la bibliothécaire explique:

"Nous gérons des livres, évidemment, mais faisons également un suivi des lecteurs. Les lecteurs reçoivent une carte numérotée à leur inscription à la bibliothèque. Ils peuvent alors emprunter jusqu'à trois livres, sauf s'ils sont en retard (s'ils ont emprunté un livre depuis plus de trois semaines sans le rendre). Les trois livres ne sont pas nécessairement empruntés au même moment."

De cet exposé on peut extraire les informations suivantes pour le schéma de la base de données: - les objets Lecteur et Livre ayant des existences indépendantes, il y a (au moins) deux TE, Lecteur

et Livre. - il y a un TA Emprunte entre Livre et Lecteur; cette association a une cardinalité (0 : 3) pour le

Lecteur (un lecteur peut emprunter zéro, un, deux, ou trois livres). - il faut mémoriser la date d'emprunt (pour savoir s'il y a retard); c'est un attribut qui dépend de Livre

et de Lecteur, donc c'est un attribut du TA Emprunte. - la contrainte de ne pas pouvoir avoir plus de trois emprunts en cours simultanément, sera assurée

automatiquement par le SGBD à cause de la cardinalité maximale 3 de Lecteur pour le TA Emprunte.

Etablir la liste des types d'entités, ... n'est pas une tâche aisée. Il faut être bien conscient que les choix de représentation dépendent du point de vue du concepteur. La même réalité peut donner lieu à des

23

Chapitre 3 : Conception d’un schéma entité-association

modélisations différentes. Par exemple, un mariage peut être représenté comme une association entre des entités personnes, ou comme un entité en soi dont certains attributs décriront l'époux et l'épouse. Ce deuxième point de vue pourrait être celui d'une administration chargée de gérer l'information sur les mariages. Pour cette administration, les époux sont des attributs, non des entités. En fait, en adoptant un point de vue purement statique (i.e., en ne considérant que les données de l'application) il est impossible de déterminer avec certitude si tel composant de l'application doit être représenté comme une entité, une association, ou un attribut. De même, il est impossible de déterminer la classification des objets: faut-il représenter toutes les entités personnes par un type Personne, ou vaut-il mieux les représenter selon les deux types Homme et Femme, éventuellement sous-types du sur-type Personne ? Sur le plan statique, ces diverses représentations peuvent être équivalentes. C'est donc seulement en examinant l'utilisation des données, à savoir l'ensemble des traitements qui seront appliqués aux données dans le cadre de l'application étudiée, qu'il est possible de déterminer la représentation adéquate. Cette connaissance des traitements, complétée par la connaissance des liens de dépendance entre informations (définis ci-après), nous permet d'appliquer les règles de modélisation suivantes: Règle de représentation par un type d'entité: est représenté par un TE tout ensemble d'objets similaires qui a un intérêt en soi pour au moins un traitement de l'application. En d'autres termes, il existe un traitement (ou un ensemble de traitements) qui utilise les entités de ce type indépendamment de leurs liens éventuels d'association avec d'autres types d'entité. Cette règle s'applique également au choix des sous-types et des sur-types. On ne définira un sous-type (sur-type) que si la matérialisation qu'il offre de l'ensemble des entités correspondantes offre un intérêt pour au moins un traitement. Règle de représentation par un type d'association: est représenté par un TA tout ensemble de liens similaires et de même sémantique, d'intérêt pour l'application, entre deux ou plusieurs objets représentés par des entités. Règle de représentation par un attribut: est représenté par un attribut toute information intéressante qui participe à la description d'un objet ou d'un lien et qui ne fait l'objet de traitement qu'en tant que partie de cet objet ou lien. Un attribut ne dépend que de l'entité (ou de l'association, i.e. des entités liées) à laquelle il est attaché. Remarque importante: par rapport à la réalité, un schéma est une représentation - incomplète: il ne représente que les informations qui sont intéressantes pour l'application - partiale: il représente le point de vue du concepteur - infidèle: il ne représente pas la réalité telle qu'elle est, mais telle qu'elle intéresse le concepteur. 1.2. Vérification du diagramme entité association Une fois le diagramme entité association établi, plusieurs types de vérification sont effectuées:

- vérification "syntaxique": il s'agit de vérifier que les règles du modèle entité association sont respectées (voir le chapitre précédent sur la définition du modèle et la suite de chapitre sur les règles de vérification d'un diagramme entité association);

- par jeu d'essai: le concepteur vérifie grâce à une mini base de données que le diagramme permet effectivement de stocker les informations nécessaires à l'entreprise;

- complétude par rapport aux traitements: le concepteur vérifie que le diagramme contient tous les types d'information nécessaires à l'exécution des traitements prévus;

- par les utilisateurs: le concepteur présente le diagramme accompagné des définitions aux personnes qui utiliseront la base de données et vérifie que les informations contenues correspondent bien aux besoins.

Chaque oubli, erreur, modification, ...., détecté lors des vérifications entraîne une mise à jour du diagramme et relance les différentes phases de vérification.

24


1.3. Définition du schéma entité association Une fois le diagramme entité association établi et vérifié, le schéma textuel détaillé est défini et validé (voir l'exemple du schéma FormaPerm en fin de ce chapitre). 2. Notion de dépendance Avant de voir comment vérifier la cohérence syntaxique d'un diagramme entité association, nous introduisons le concept de dépendance entre données ou entre types d'entité, qui est utile pour certaines règles de vérification. Le concept de dépendance n'est pas propre au modèle entité-association; c'est un concept générique qui est utilisé aussi bien en entité-association qu'en relationnel pour exprimer les propriétés intrinsèques des données. Définition: étant donné un attribut, ou un ensemble d'attributs, A, d'un TE (ou TA), et B un attribut du même TE (ou TA), il y a dépendance A vers B, notée A→B , si dans la population du TE (ou TA) toutes les occurrences qui ont même valeur pour A ont toujours même valeur pour B. Plus formellement, on a A → B si et seulement si, quelles que soient deux occurrences du TE (TA) de valeurs (a,b) et (a',b') pour les attributs A et B, on a toujours: a=a' ⇒ b=b'.

Si A (ou B) est multivalué, par valeur de A (ou de B) on entend l'ensemble des valeurs prises par l'attribut pour une occurrence du TE (ou du TA). On dit aussi que B dépend de A, ou que A détermine B. A est dit la source de la dépendance, dont B est la cible. Pratiquement toute dépendance A→B, traduit un fait du monde réel ou bien une règle de l'application qui lie de manière univoque la valeur de B à la valeur prise par A, quelque soit le contexte dans lequel A et B sont considérés. Par exemple, la valeur de l'attribut date-de-naissance dépend indissociablement de la personne dont on parle et d'aucun autre facteur: c'est un fait du monde réel. Dans l'exemple ci-dessous, le nom d'un étudiant est une fonction univoque du numéro de carte considéré, sur la base de l'hypothèse que l'institution n'attribue un numéro de carte qu'à un seul étudiant: c'est une règle de l'application. Par définition, l'identifiant d'un TE (ou TA) détermine tous les autres attributs du TE (TA). Exemple:

N°carte nom prénoms datenais

n° rue ville NPA

adresse

jour mois année

Etudiant

liste

Dans cet exemple, les dépendances suivantes sont supposées vraies: N°carte → nom N°carte → prénoms N°carte → adresse N°carte → datenais. Ceci peut s'écrire également: N°carte → nom , prénoms, adresse, datenais. Si (nom + prénoms) était un autre identifiant de Etudiant, on aurait en plus les dépendances suivantes: (nom , prénoms) → N°carte (nom , prénoms) → adresse (nom , prénoms) → datenais La notion de dépendance peut être étendue aux dépendances entre TEs liés par un TA.

25


Définition: soient E1, E2 deux TE liés par un TA. Il existe une dépendance E1 vers E2, notée E1→E2, si et seulement si pour chaque occurrence de E1, le TA lui associe toujours la même occurrence de E2. On notera que dans un TA correctement défini, le fait qu'un rôle ait une cardinalité maximum égale à 1 implique qu'il y a une dépendance du TE jouant ce rôle vers les autres TE du TA:

E2 0:1

E3

E1 → E2 E1 → E3

RE1 i:j

m:n

Attention: ne pas confondre, sur un diagramme EA, les flèches représentant des liens de généralisation (qui font partie du modèle EA), et les flèches représentant des dépendances. Ces dernières ne font pas partie du modèle EA et servent pendant la validation du schéma et, le cas échéant, à exprimer des contraintes d'intégrité.

3. Règles de vérification d'un diagramme entité association La connaissance des dépendances permet de vérifier si le schéma élaboré traduit correctement la réalité de l'entreprise à décrire. Par ailleurs, d'autres règles permettent de corriger ou de valider un schéma. 3.1. Validation des attributs d'un TE ou TA Règle 1 pour les attributs directs (ou attributs de niveau 1): Dans un TE (ou TA) valide, tout attribut direct (simple ou complexe) dépend uniquement de chaque identifiant entier du TE (TA). Sinon le TE (TA) n'est pas correct. En effet, si un attribut d'un TE ne dépend pas de l'identifiant du TE, cela signifie que cet attribut ne décrit pas directement les objets réels représentés par le TE. De même, si un attribut A d'un TE à identifiant composé (I+J) dépend uniquement de I (et donc d'une partie de l'identifiant du TE), cela signifie que cet attribut ne décrit pas les objets réels représentés par le TE, mais leur propriété I. Exemple:

nom adresses

rue ville

n°étudiant

n°

Etudiant

n°étudiant, nom et adresses sont les attributs directs du TE Etudiant, dont n°étudiant est identifiant. Si les seules dépendances existantes sont celles illustrées sur le diagramme, le TE est correctement défini. La règle est contredite si un attribut dépend d'une partie de l'identifiant, et non de l'identifiant entier. Soit, par exemple:

directeur_départementdépartementn°étudiant nom_étudiant

Etudiant

26


L'identifiant de ce TE Etudiant est n°étudiant+département (on suppose ici que les numéros sont donnés par les départements suivant une numérotation qui leur est propre, telle que deux étudiants différents de départements différents peuvent recevoir le même numéro). Les dépendances sont: (n°étudiant, département) → nom_étudiant et département → directeur_département. La deuxième dépendance (qui exprime qu'un département n'a qu'un directeur) contredit la règle. Il convient donc de modifier la définition du TE afin de regrouper dans un même attribut complexe les attributs en dépendance:

départementn°étudiant nom_étudiant

directeurintitulé

Etudiant

Autre exemple de TE mal défini:

départementn°étudiant directeur_département

Etudiant

Ce TE Etudiant n'est pas correct. En effet, la dépendance département → directeur_département n'a pas pour source l'identifiant du TE. Elle contredit la règle 1. L'existence de cette dépendance signifie que les deux attributs sont liés sémantiquement. Comme dans l'exemple précédent, ce lien peut être traduit dans le schéma EA par le regroupement des deux attributs en un attribut complexe. On obtient ainsi le nouveau TE Etudiant:

départementn°étudiant

Etudiant

directeurintitulé

qui est correctement défini. Règle 2 pour les attributs indirects (ou de niveau i>1): Dans un TE (ou TA) valide E, tout attribut E•…•X•Y•Z•A de niveau i (i>1) dépend uniquement:

1/ soit d'un (ou plusieurs) de ses frères E•…•X•Y•Z•B 2/ soit d'un (ou plusieurs) de ses frères, E•…•X•Y•Z•B, et d'un (ou plusieurs) de ses oncles E•…•X•Y•U,

plus éventuellement d'un (ou plusieurs) de ses grand-oncles E•…•X•V, … et ainsi de suite en remontant jusqu'à l'identifiant du TE (TA) sans sauter de niveau.

27


Cette règle signifie qu'un attribut du ième niveau peut dépendre d'une combinaison d'attributs du même niveau et de niveaux supérieurs contigus (i, i-1, i-2…), issus du même père. Cette règle s'explique par le fait qu'il existe deux types d'attributs complexes:

- ceux qui décrivent une propriété locale des entités, comme par exemple les enfants d'une personne ou ci-dessus le département de l'étudiant (cas 1/ de la règle);

- et ceux qui décrivent une propriété locale plus le lien entre l'entité et cette propriété (cas 2/ de la règle). Ce dernier cas est représenté dans l'exemple ci-dessous par l'attribut chercheurs qui décrit les chercheurs (nomC, adresse) et le lien entre chaque chercheur et le labo (dateentrée du chercheur dans le labo et %temps passé chaque semaine par le chercheur dans le labo).

Exemple: Les attributs du TE Laboratoire ci-dessous respectent les règles 1 et 2:

- les attributs directs, directeur et chercheurs, dépendent de l'identifiant, nomLab;

- l'attribut du 2ème niveau, adresse, dépend de nomC; ce qui signifie que l'adresse du chercheur ne dépend que du chercheur et pas du laboratoire; si le même chercheur (nomC) apparait dans deux occurrences de Laboratoire, il y apparaitra avec la même adresse;

- les attributs du 2ème niveau, date-entrée, %temps et projets, dépendent de (nomC, nomLab); ce qui signifie que si un chercheur travaille dans deux laboratoires (par exemple à mi-temps), il peut y être entré à des dates différentes, travailler sur des projets différents ... ;

- l'attribut du 4ème niveau, montant, dépend de (nomP, ligne), ce qui signifie que le montant alloué à chaque ligne (matériels, fonctionnement, ...) dépend du projet et de la ligne.

Exemple:

nomLab directeur chercheurs

nomC adresse dateentrée %temps projets

nomP budget description

ligne montant

Laboratoire

3.2. Validation des attributs d'un TA Les règles de validation des attributs d'un TE s'appliquent de la même façon aux attributs d'un TA. On peut en déduire les règles suivantes: Règle 3 pour les attributs des TA: Les attributs du premier niveau d'un TA dépendent d'au moins tous les TEs qui font partie d’au moins un identifiant du TA. Dans un TA sans dépendance entre les TEs liés, les attributs du premier niveau dépendent d'au moins tous les TEs liés par ce TA.

28


Exemple:

N°Carte notes moyenne coef NumMat

ContrôleEtudiant Matière

Les dépendances existantes sont: (N°Carte, NumMat) → notes (N°Carte, NumMat) → moyenne NumMat → coef . Par contre: N°Carte moyenne, NumMat moyenne N°Carte notes, NumMat notes Ce diagramme est correctement défini en ce sens que les attributs notes et moyenne dépendent à la fois de l'étudiant et de la matière: un étudiant a des notes et une moyenne par matière, et pour une matière il y a des notes et une moyenne par étudiant. On notera que l'attribut coef est bien placé, car il ne dépend que de la matière et pas de l'étudiant. Autre exemple:

notes coef Nom

Etudiant Enseignant

Nom Cours

Cours

Contrôle

N°Carte

Un enseignant peut enseigner plusieurs cours. Un cours peut être enseigné par plusieurs enseignants; dans ce cas les notes mises par chaque enseignant ont un poids différent (coef) qui est fonction du nombre d'heures assurées par l'enseignant dans ce cours. En vérifiant les attributs du TA Contrôle, on s'aperçoit que l'attribut notes dépend des trois TE liés, mais que l'attribut coef ne dépend que des TE Enseignant et Cours. Le bon diagramme est alors:

notes

Etudiant

Nom

Nom Cours

Contrôle

coef

Cours Assure

N°Carte

Enseignant

3.3. Validation d'un TA (arité) Règle 4: Soit un TA bien construit, liant les TE E1, E2, ..., En; s'il existe une dépendance:

29


(E1, ..., Ei) → Ei+1, alors il existe la dépendance: (E1, ..., Ei) → (Ei+1, ..., En). Donc, si dans un diagramme EA, un TA comporte l'une de ces dépendances sans les autres, il faut décomposer le TA, afin de matérialiser cette dépendance par un nouveau TA de cardinalité maximale 1 pour le rôle source de la dépendance. Exemple:

Chercheur LaboTravaille

Projet

0:1 0:n

1:n

Dépendance La dépendance (Projet → Labo) traduit la règle d'entreprise suivante: chaque projet est réalisé dans un et un seul laboratoire. Ce schéma n'est pas correct et génère des redondances. La dépendance doit être décrite par un TA binaire reliant Projet et Labo. Le TE restant, Chercheur, sera lié par un TA binaire au TE source de la dépendance (Projet):

Chercheur Travaille0:1 1:n

1:1

0:n

Labo

Affecté

Projet

Si on décomposait le TA Travaille en associant Chercheur à la cible de la dépendance, cela conduirait à une perte d'information: on ne saurait plus sur quel projet travaille un chercheur. Bien que les deux TA respectent la règle 3, cette décomposition est donc incorrecte:

Chercheur Travaille0:1 0:n

0:n

1:1

Projet

Affecté

Labo

3.4. Elimination des TA redondants Un TA est redondant si les associations correspondantes peuvent être établies sans ambiguïté par composition des associations d'autres TA.

30


Exemple:

InscritEtudiant Cours Assure Enseignant

Est élève de

Si "Est élève de" établit une association entre un étudiant et l'enseignant dont il suit un cours, cette association est la même que celle résultant de la composition des associations correspondantes Inscrit et Assure: Dupont est élève de Durand si Dupont est inscrit à un cours assuré par Durand. Le TA "Est élève de" n'apporte aucune information supplémentaire et doit donc être supprimé. Si pour l’application on veut cependant conserver ce TA, il faut alors déclarer par une contrainte d’intégrité le fait que le TA est dérivé des deux autres. 3.5. Transformation des attributs référence Si l'on trouve dans un TE E1 un attribut dont la valeur est égale à celle de l'identifiant d'un TE E2, cet attribut exprime en réalité un lien entre les TEs E1 et E2. La règle de représentation par un type d'association n'a pas été respectée. Il convient donc de corriger le schéma: le lien doit être explicitement décrit comme un TA entre les deux TEs et l'attribut doit être supprimé du TE E1. Le nouveau schéma ainsi obtenu est préférable car le TA assure une meilleure intégrité des données que l'attribut référençant un TE. Dans le cas de l'attribut, les utilisateurs peuvent y entrer une valeur qui n'existe pas en tant qu'identifiant de E2; ce qui est manifestement une erreur. Par contre ce serait impossible de faire une erreur équivalente avec le TA, puisqu'une association ne lie que des entités existantes. Exemple: si un schéma contient les deux TEs suivants:

• • • n°servicen°emp

Employé

étage nomn°

Service

avec en plus la contrainte d'intégrité: "les valeurs de l'attribut n°service de Employé doivent toujours être égales à une valeur de l'attribut n° du TE Service". Alors il convient de supprimer l'attribut n°service de Employé et d'établir le lien correspondant entre les deux TEs par un TA. La contrainte d'intégrité est alors inutile. On obtient donc le schéma suivant:

• • •n°emp

Employé

étage nomn°

ServiceTravaille

3.6. TE ou attribut complexe ? Il est tout à fait possible que, lors d'une première esquisse du diagramme EA, le concepteur ait inclus des types d'entité qui lui paraissaient utiles a priori, mais qui se révèlent inutiles une fois la conception du schéma terminée. Il convient donc de supprimer ces types inutiles. Conformément à la règle de représentation par un type d'entité, un TE est inutile s'il ne présente d'intérêt, en tant que TE, pour aucun traitement de l'application. S'il faut néanmoins conserver l'information correspondante, celle-ci sera rattachée, sous forme d’un attribut, au TE (ou TA) où elle est pertinente (c.à-d., dont elle dépend). Par exemple, dans le dernier schéma ci-dessus, si les informations sur les services ne sont utilisées que comme une information supplémentaire sur les employés, sans qu'il y ait de traitements portant directement

31


sur les services (pas de requêtes du type "à quel étage est le service comptabilité?”), Service est alors un TE inutile. Les informations sur les services seront rattachées au TE Employé et décriront, pour chaque employé, le service dans lequel cet employé travaille:

• • •n°emp

Employé

étage nomn°

service

Le fait que les mêmes informations sur les services apparaîtront dans tous les employés d'un service donné n'est pas un inconvénient dans une modélisation conceptuelle. Rappelons que le schéma conceptuel représente la structure des données telle qu'elle est vue par l'application. Cette structure conceptuelle n'est pas nécessairement implantée telle quelle aux niveaux logique et/ou physique. Autre exemple: un TE qui n’a pas de sur-type et qui n'a qu'un seul attribut, doit probablement être transformé en attribut des TEs auxquels il est lié.

Alieu dans

• • • • • n° • • • • n°salle

Cours Salle Cours

Par contre, conformément à la règle de représentation par un type d'entité, il convient, lorsqu'un TE possède un attribut complexe, de vérifier que cet attribut ne fait pas l'objet de traitements (création de nouvelles valeurs, interrogations, mises à jour, suppressions) indépendamment du TE en question. Si de tels traitements existent, il faut remplacer cet attribut par un TE, plus un TA qui conserve le lien avec le TE d'origine.

Etudiant Cours

intitulé salle cours horaire • • • • •

intitulé salle horaire

Etudiant

• • • • • • •

? Inscrit

Enfin, il convient de supprimer tout TE qui n'aurait qu'une seule occurrence (il s'agit ici aussi d'une erreur d'analyse, fréquente chez les concepteurs débutants). Cette occurrence unique n'a probablement aucun intérêt pour l'application.

32


4. Exemple: la base de données "FormaPerm" Nous donnons ici un exemple de diagramme et de schéma entité-association pour une base de données établie pour les besoins d'un hypothétique institut de formation permanente. Soit un institut de formation permanente qui veut gérer avec une base de données ses cours, ses enseignants et ses étudiants, avec leurs inscriptions et leurs résultats. Les cours, identifiés par leur nom, sont répartis sur trois cycles (1, 2 et 3). Chaque cours peut avoir zéro, un ou plusieurs autres cours du même cycle ou des cycles précédents en prérequis. Un enseignant, identifié par son nom, peut assurer un ou plusieurs cours; mais un cours est assuré par un seul enseignant. L'institut mémorise, pour chaque enseignant, ses nom, prénom, adresse, numéro de téléphone, statut (universitaire, professionnel...), et renseignements bancaires. Les étudiants s'inscrivent à un ou plusieurs cours et paient un droit d'inscription pour chaque cours (qui est le même pour tous les cours). Lors de sa première inscription à l'institut, l'étudiant reçoit un numéro qu'il conserve tout au long de sa formation. Chaque étudiant est décrit par ses nom, prénoms, numéro, adresse, études antérieures (diplômes et année) et date de naissance. L'institut conserve, pour chaque étudiant, la liste des cours qu'il a obtenus, avec la note et l'année. On suppose que l'offre de cours est la même d'une année à l'autre. 4.1. Diagramme entité association de FormaPerm

a-pour est-un

notes année

n°E dateN études

année diplôme

tél.statut rens.banc.

banque agence compte

cycle nomC

nom prénoms adr.

Prérequis

Assure

Etudiant Enseignant

Cours

Personne

jourmois année liste

liste

couverture

liste

multi-ensemble

Obtenu Inscrit

4.2. Définitions des types d'entité et d'association Etudiant: tout individu qui est actuellement inscrit à l'institut, ou qui a déjà passé avec succès l'un des cours de l'institut.

Enseignant: tout individu assurant actuellement un ou plusieurs cours à l'institut.

Personne: tout étudiant et tout enseignant de l'institut.

Cours: tout cours offert par l'institut.

Obtenu: tel étudiant a réussi tel cours telle année et a obtenu telle note.

Inscrit: actuellement, tel étudiant est inscrit à tel cours.

Assure: actuellement, tel enseignant assure tel cours.

Prérequis: tel cours est un pré-requis pour tel cours.

33


4.3. Contraintes d'intégrité a) Un cours c1 ne peut pas être pré-requis d'un cours c2 s'il appartient à un cycle postérieur à celui de c2. Ce qui s'exprime par la contrainte d'intégrité suivante (en français et en logique) : Pour toute occurrence c1 de Cours, si c2 est une autre occurrence de Cours liée à c1 par Prérequis (dans le sens c1(a pour)–Prérequis–c2(est un)), alors on doit avoir : c2•cycle ≥ c1•cycle. ∀ c1 ∈ Cours, ∀ c2 ∈ Cours, ( Prérequis (c1/est-un, c2/a-pour) ⇒ c2•cycle ≥ c1•cycle ) b) Un inscrit à un cours doit avoir obtenu tous les pré-requis de ce cours. Ce qui s'exprime par la contrainte d'intégrité suivante (en français et en logique) : Pour toute occurrence e de Etudiant, pour chacun des Cours c auxquels il est lié par Inscrit, et pour chacun des Cours r auxquels c est lié par Prérequis (dans le sens c(a pour)–Prérequis–r(est un)), e doit être lié à r par Obtenu. ∀ e ∈ Etudiant , ∀ c ∈ Cours , ∀ r ∈ Cours, ( Inscrit (e, c) ∧ Prérequis (r/est-un, c/a-pour) ⇒ Obtenu (e, r) ) c) Un étudiant doit avoir au moins 18 ans. Ce qui s'exprime par la contrainte d'intégrité suivante (en français et en logique) : Pour toute occurrence e de Etudiant, on doit avoir: (Date - e•dateN) ≥ 18 ans. ∀ e ∈ Etudiant (Date - e•dateN) ≥ 18 ans d) Les dates sont cohérentes. Ce qui s'exprime par les deux contraintes d'intégrité suivantes (en français et en logique) : Pour toute occurrence e de Etudiant, pour toute valeur v de e•études, on doit avoir :

v•année > e•dateN•année. Pour toute occurrence e de Etudiant, pour toute occurrence o de Obtenu liant e, on doit avoir :

o•année > (e•dateN•année + 18). ∀ e ∈ Etudiant, ∀ v ∈ e•études v•année > e•dateN•année ∀ e ∈ Etudiant, ∀ c ∈ Cours ( Obtenu (e, c) ⇒ e•dateN•année < (Obtenu•année + 18) ) e) Le groupe de sous-types de Personne forme une couverture. Ce qui s'exprime par la contrainte d'intégrité suivante (en français et en logique) : Pour toute occurrence p de Personne, p doit aussi être occurrence de Etudiant et/ou de Enseignant. ∀ p ∈ Personne ( ∃ e ∈ Etudiant ( e ISA p ) ∨ ∃ e ∈ Enseignant ( e ISA p ) ) 4.4. Schéma entité association de FormaPerm Domaine Dnom : chaînes de caractères de longueur inférieure à 30 Domaine Dch100 : chaînes de caractères de longueur inférieure à 100 Domaine Djour: [1 : 31] Domaine Dmois : [1 : 12] Domaine Dannée : [1970 : 1993] Domaine Dnote : [0.0 : 20.0] Type d'entité: Personne Attributs: nom: 1:1, simple: Dnom prénoms: 1:n liste, simple: Dnom adr: 1:1 , simple: Dch100 Identifiant: (nom + prénoms)

34


Type d'entité: Etudiant sous-type de Personne Attributs: n°E: 1:1, simple: entier dateN: 1:1, complexe: (jour: 1:1, simple: Djour mois: 1:1, simple: Dmois) année: 1:1, simple: Dannée) études: 0:n liste, complexe: (année: 1:1, simple: Dannée diplôme: 1:1, simple: Dnom ) Identifiant: (n°E) Type d'entité: Enseignant sous-type de Personne Attributs: tél: 1:1, simple: entier statut: 1:1, simple: Dnom rens.banc.: 1:1, complexe: (banque: 1:1, simple: Dnom agence: 1:1, simple: Dnom compte: 1:1, simple: entier) Identifiant: / Type d'entité: Cours Attributs: nomC: 1:1, simple: Dnom cycle: 1:1, simple: entier Identifiant: (nomC) Type d'association: Obtenu Rôles: Etudiant (0:n) liste, Cours (0:n) Attributs: notes: 1:n multi-ensemble, simple: Dnote année: 1:1, simple: Dannée Identifiant: (Etudiant + Cours) Type d'association: Assure Rôles: Enseignant (0:n), Cours (1:1) Attributs: / Identifiant: (Cours) Type d'association: Inscrit Rôles: Etudiant (0:n), Cours (0:n) Attributs: / Identifiant: (Etudiant + Cours) Type d'association: Prérequis Rôles: Cours: est-un (0:n), Cours: a-pour (0:n) Attributs: / Identifiant: (Cours: est-un + Cours: a-pour)

35

E x e r c i c e s - S é r i e 2

Proposer des diagrammes entité-association qui modélisent les cas ci-dessous. Précisez en français les contraintes d'intégrité.

Exercice 1. Bibliothèque La Bibliothèque d'un syndicat intercommunal consiste en 5 centres de prêt. Ces centres disposent d'ordinateurs personnels interconnectés qui doivent permettre de gérer les emprunts. L'interview des bibliothécaires permet de déterminer les faits suivants:

- une personne qui s'inscrit à la bibliothèque verse une caution. Suivant le montant de cette caution elle aura le droit d'effectuer en même temps de 1 à 10 emprunts;

- les emprunts durent au maximum 15 jours; - un livre est caractérisé par son numéro dans la bibliothèque (identifiant), son titre, son éditeur et son (ses)

auteur(s); - on veut pouvoir obtenir, pour chaque abonné les emprunts qu'il a effectué (nombre, numéro et titre du

livre, date de l'emprunt) au cours des trois derniers mois; - toutes les semaines, on édite la liste des emprunteurs en retard : nom et adresse de l’abonné, date de

l'emprunt, numéro(s) et titre du (des) livre(s) concerné(s); - on veut enfin pouvoir connaître pour chaque livre sa date d'achat, son état et s'il est disponible dans quel

centre.

Exercice 2. Editeur Un éditeur souhaite installer une base de données pour mémoriser les informations suivantes:

- les livres sont identifiés par leur numéro ISBN. Un livre possède un titre et un prix de vente. Il est écrit par un ou plusieurs auteurs.

Chaque livre est tiré en une ou plusieurs éditions, datées et identifiées par leur ordre (première édition, seconde édition, etc.). Chaque édition comporte un certain nombre d'exemplaires. Le prix de vente peut changer d'une édition à l'autre.

Un livre peut être primé (Goncourt, Fémina etc.). - les auteurs sont identifiés par leur nom et prénoms et peuvent avoir un pseudonyme. Pour chaque livre, un

auteur perçoit des droits d'auteur annuels, calculés comme un pourcentage des ventes (il est aussi fonction du nombre d'auteurs).

- les libraires (identifiés par leur nom et adresse complète) commandent des livres en précisant l’édition et le nombre d’exemplaires désiré.

Exercice 3. Les courses de chevaux Un parieur assidu des champs de courses et des bases de données, voudrait mémoriser dans une base de données les courses de chevaux, les paris qu'il a faits et les résultats. Plus précisément, il veut enregistrer les informations suivantes pour chaque course:

- le nom et la date (exemple: Prix d'Amérique, 21-07-92) - le numéro, le nom et la cote des chevaux partants (exemple: <1, Salicorne, 20/1>, <2, Solstice, 8/1>, <3,

Samovar, 17/1> ...)

37

Chapitre 3 : Conception d’un schéma Entité-Association

- ses paris, avec pour chacun: le type de pari (couplé, tiercé, quarté, quinté ...) la somme jouée et les numéros de chevaux dans l'ordre du pari (exemple: <tiercé, 20 Frs, 13-2-8>)

Une fois la course jouée, on enregistre aussi : - le résultat : l'ordre d'arrivée des chevaux (exemple: <1er, 13>, <2ème, 8>, <3ème, 14>, ...) et les rapports

pour chacun des types de pari (exemple: <tiercé dans l'ordre, 900 Frs>, <tiercé dans le désordre: 112 Frs>, <quarté dans l'ordre: 5430 Frs>, <quarté dans le désordre: 750 Frs>, <2 sur 4 : 21 Frs> ...)

- le gain total du parieur pour la course. Les noms de chevaux sont uniques, et les noms de courses sont uniques (à un instant donné). Proposer deux diagrammes entité-association, l'un contenant un seul type d'entité (Course), l'autre en contenant plusieurs (Course, Cheval...) ainsi que des types d'association. Préciser les contraintes d'intégrité.

Exercice 4. Club Vidéo Dix magasins de location de cassettes vidéo se sont regroupés pour mettre en commun les cassettes dont ils disposent et ont fondé un club de location. A la suite d'une rencontre avec les représentants de ce club, il ressort que chaque point de vente disposera d'un ordinateur personnel relié à un site central et qu'il faudra pouvoir prendre en compte les éléments suivants:

- un client qui s'inscrit au club verse une caution. Suivant le montant de cette caution il aura le droit d'emprunter en même temps de 1 à 6 cassettes;

- les cassettes empruntées doivent être retournées dans un délai de 3 jours dans n'importe quelle boutique du club;

- plusieurs cassettes peuvent contenir le même film; - un film est rattaché à un genre cinématographique (défini par un nom et le type de public auquel il est

destiné). Il est caractérisé par sa durée, son réalisateur et la liste des acteurs principaux; - une location n'est permise que si le client est en règle (pas de dépassement du nombre d'emprunts

maximum, pas de cassette en retard); - la consultation d'un client permettra d'obtenir son nom, son adresse, son nombre d'emprunts en cours, la

liste des numéros de cassettes et des titres qu'il a actuellement empruntés; - la consultation d'un genre permettra d'obtenir la liste des films de ce genre disponibles dans un magasin

donné; - périodiquement, on veut obtenir la liste des retardataires; on veut pour chaque cassette non retournée à

temps les informations suivantes : nom et adresse du client, date de l'emprunt, numéro(s) de cassette et titre du (des) film(s) concerné(s);

- on veut pouvoir connaître pour chaque cassette (identifiée par une numérotation commune aux dix magasins) où elle est, quand elle a été mise en service, quel film y est enregistré, combien de fois elle a déjà été louée, et quel est son état (de très bon à mauvais).

38



Exercice 1. Aéroport Pour les besoins de la gestion d'un aéroport on souhaite mémoriser dans une base de données les informations nécessaires à la description des faits suivants:

- chaque avion géré est identifié par un numéro d'immatriculation. Il est la propriété soit d'une société, soit d'un particulier: dans les deux cas on doit connaître le nom, l'adresse et le numéro de téléphone du propriétaire, ainsi que la date d'achat de l'avion;

- chaque avion est d'un certain type, celui-ci étant caractérisé par son nom, le nom du constructeur, la puissance du moteur, le nombre de places;

- la maintenance des avions est assurée par les mécaniciens de l'aéroport. Par sécurité, les interventions sont toujours effectuées par deux mécaniciens (l'un répare, l'autre vérifie). Un même mécanicien peut, selon les interventions, effectuer la réparation ou la vérification. Pour toute intervention effectuée, on conserve l'objet de l'intervention, la date et la durée;

- pour chaque mécanicien on connaît son nom, son adresse, son numéro de téléphone et les types d'avion sur lesquels il est habilité à intervenir;

- un certain nombre de pilotes sont enregistrés auprès de l'aéroport. Pour chaque pilote on connaît son nom, son adresse, son numéro de téléphone, son numéro de brevet de pilote et les types d'avion qu'il est habilité à piloter avec le nombre total de vols qu'il a effectué sur chacun de ces types.

Des questions types auxquelles l'application doit pouvoir répondre sont les suivantes:

- liste des avions de la société "Voltige"; - liste des avions qui sont la propriété de particuliers; - durée totale des interventions faites par le mécanicien Rochat au mois de janvier; - liste des types d'avion de plus de 4 places; - liste des pilotes habilités pour tel type d'avion; - liste des interventions (objet, date) faites sur l'avion numéro 3242XZY78K3.

Exercice 2. Club sportif Le club sportif d’une école veut enregistrer les informations sur ses adhérents. Il lui importe de connaître, pour chaque adhérent, le nom et prénom, la date de naissance, la commune et canton de naissance, la section et année d'études (pour les étudiants), le département (pour les enseignants), le service (pour les administratifs). On veut aussi connaître les années d'adhésion précédentes, les sports pratiqués pour l'année en cours ainsi que le niveau de l'adhérent dans chacun de ces sports. Proposer deux diagrammes entité-association, l’un sans lien de généralisation/spécialisation, l’autre avec.

39


Exercice 3. Personnel On veut représenter le personnel d'une entreprise et son affectation. L'entreprise est organisée en services auxquels est affecté le personnel. Chaque service est décrit par son nom, son chef (qui est nécessairement un cadre de l'entreprise) et la liste de ses locaux. Le personnel est réparti en trois catégories, les administratifs, les techniciens et les cadres. Tous possèdent un numéro d'employé, un nom, un prénom, une adresse, une identification bancaire (nom banque, nom agence, numéro de compte), un salaire et sont rattachés à un service. Chaque catégorie possède en outre des renseignements qui lui sont propres:

- pour un administratif ou un technicien, le prix de l'heure supplémentaire; - pour un technicien, les machines dont il est responsable; - pour un administratif, le(s) cadre(s) pour le(s)quel(s) il travaille; - pour un cadre, son bureau, son numéro de poste téléphonique et l'(les) administratif(s) (s'il en existe) qui

lui est (sont) attaché(s).

Exercice 4. Généalogie Proposer deux diagrammes entité-association (l’un sans lien de généralisation/spécialisation, l’autre avec) pour une base de données décrivant un arbre généalogique. Pour chaque individu on désire: son nom, ses prénoms, son sexe, sa date et son lieu de naissance (et éventuellement de décès), ses parents (la mère et le père), ses enfants et l'historique de ses mariages: date, lieu, nom et prénoms du conjoint (avec éventuellement la date de décès), et s’il y a lieu le divorce (date, lieu).

40



Exercice 1. Musée Définir un diagramme entité-association représentant les faits suivants, relatifs à un musée: - toute œuvre du musée a un titre, un ou plusieurs auteurs, une date d'acquisition et un numéro de catalogue (identifiant); - une œuvre est exposée dans l'une des salles du musée (qui est caractérisée par un numéro, son nom, le nombre d'œuvres exposables, sol, éclairage), ou est en prêt dans un autre musée (nom et adresse de ce musée, début et durée du prêt); - certaines œuvres exposées dans le musée peuvent avoir été empruntées par le musée, soit à un autre musée, soit à un particulier (nom et adresse). Dans ce cas, on connaît son titre, son (ou ses) auteur(s), la date de début et la durée de l'emprunt. De plus, l'œuvre doit alors être assurée. On veut savoir le montant de la prime d'assurance, la valeur pour laquelle l'œuvre est assurée, le nom et l'adresse de la compagnie qui l'assure; - le conservateur garde le fichier des musées et des particuliers qui ont prêté ou qui sont susceptibles de prêter des œuvres. Pour chacun (musée ou particulier), il garde le nom et l'adresse et la liste des collections qui l'intéressent (art déco, art contemporain, antiquités, ...). Préciser les contraintes d'intégrité.

Exercice 2. Les créneaux et l'ordinateur (extrait du journal "Le Monde" du 18.10.94) Si le club X occupe pendant deux heures le stade Y, combien de temps restera-t-il à l'association Z pour plonger dans la piscine ? Absurde dans son énoncé, ce problème est pourtant celui que doivent résoudre quotidiennement les responsables de la gestion des équipements sportifs. Pour les aider à régler ce casse-tête, ils ont fait appel à l'informatique. Ces dernières années, quelques sociétés informatiques ont mis au point des logiciels qui permettent de planifier l'utilisation des équipements et de savoir en temps réel ce qui est libre ou occupé. La société Dinafield, basée à Poitiers, a installé son programme Hercule dans une soixantaine de villes de plus de quarante mille habitants. Il permet, par exemple, aux habitants de réserver leurs courts de tennis par Minitel. Avec ses trois mille aires (terrains de jeux, lignes d'eau, pistes, etc.), ses deux cent quatre-vingt mille créneaux horaires par semaine, ses quarante-cinq mille contrats par an pour mille huit cents associations, la Ville de Paris était confrontée à des combinaisons beaucoup plus complexes. Son système Planning, qui fonctionne depuis la rentrée sur les douze secteurs de la capitale, permet aux responsables de la direction de la jeunesse et des sports de connaître exactement le taux de fréquentation des équipements. Pour chaque créneau horaire, le gardien inscrit le nombre de sportifs présents en face du nom de l'association. Les éventuelles intempéries sont mentionnées. C'est une façon de s'assurer que ceux qui n'occupent pas les créneaux horaires qu'ils ont réservés ont de bonnes excuses. Autrement, leur contrat risque de ne pas être renouvelé, et leur place offerte à ceux qui sont sur les listes d'attente.

41


Exercice 3. Organisation d’un colloque Les organisateurs d’un colloque annuel d’informatique veulent monter une base de données pour gérer les inscriptions des participants, la préparation des actes qui contiennent le texte des articles qui sont présentés au colloque, le choix de ces articles, et l’organisation des différentes sessions. Le colloque dure quatre jours et chaque demi-journée est consacrée à une session qui regroupe des articles portant sur le même thème (systèmes temps réel, multi-média, bases de données, ...). Les articles présentés au colloque et imprimés dans les actes sont choisis de la façon suivante: ce sont des articles de 15 à 20 pages, présentant des résultats de recherche, proposés par une (ou plusieurs) personne, appelée ici auteur, qui travaille dans un laboratoire de recherche d’une université ou entreprise. Un comité de lecture regroupant une trentaine d’experts fait la sélection. Chaque article est évalué par trois experts qui mettent chacun une note. Les experts ne doivent pas proposer eux-mêmes d’article ni être de la même université ou entreprise que les auteurs des articles qu’ils évaluent. A partir des notes, le comité classe les articles, choisit les meilleurs et les affecte aux différentes sessions. Les organisateurs veulent conserver les informations suivantes pour la préparation du prochain colloque: - pour chaque article proposé: titre, nombre de pages, mots clés, auteur(s) avec mention de l’auteur principal à qui envoyer la réponse (acceptation ou refus), les trois experts avec les notes qu’ils ont mises à l’article. Si l’article est accepté, la session et l’heure à laquelle il sera présenté. S’il y a plusieurs auteurs, celui qui le présentera (appelé l’orateur). - pour chaque auteur: nom, titre, université ou entreprise, adresse, le(s) article(s) qu’il propose. S’il est auteur principal, on enregistre en plus ses numéros de téléphone et de télécopie, et son adresse électronique. S’il est orateur, on enregistre en plus son CV résumé sur cinq lignes pour que le président de la session puisse le présenter. - pour chaque expert: nom, titre, université ou entreprise, adresse, numéro de téléphone, numéro de télécopie, adresse électronique, les articles qu’il évalue avec la note qu’il leur met. - pour chaque session: thème, jour, heure de début, heure de fin, le président (celui qui anime la session, présente les orateurs, lance la discussion,....; c’est un expert, un participant ou un auteur d’un autre article), liste des articles de la session, avec leur heure de passage, coût de l’inscription à la session (toutes les sessions n’ont pas le même prix). - pour chaque participant: nom, affiliation (nom de l’entreprise, université, ...), adresse, s’il a déjà participé à ce colloque une (des) année précédente: quelles années et s’il y était simple participant ou auteur ou expert. On enregistre aussi les sessions auxquelles il s’inscrit et s’il a réglé son inscription. Exemple de requêtes auxquelles le SGBD devra pouvoir répondre:

- liste des orateurs de telle session - liste des auteurs principaux dont un article au moins a été accepté - liste des participants à telle session - liste des experts qui n’ont pas encore fait leur évaluation - liste des articles acceptés - liste des articles de note moyenne supérieure à 8 - .......

42



Exercice 1. Gestion d'un Zoo

Le directeur d'un zoo, qui désire informatiser la gestion de son établissement, charge un informaticien de concevoir une base de données. Celui ci décide d'interroger les différents services du zoo pour analyser les informations à modéliser dans la future base de données. Par le chef du personnel, il apprend les fait suivants : Pour chacun des 61 employés du zoo, le service administratif conserve son nom, son prénom, ses date et lieu de naissance, ses douze derniers salaires (caractérisés par le mois et le montant), son nom marital si l'employé est une femme mariée, son numéro d'AVS, son adresse et son numéro de téléphone. Chaque employé appartient à un service (administratif, surveillance ou médical). Les 18 employés du service médical sont soit des vétérinaires soit des infirmières. Le service de surveillance est composé de 30 gardiens et de 8 chefs de secteur. Pour les gardiens du zoo on conserve leur taux d'occupation (ce sont les seuls employés qui peuvent travailler à temps partiel) et leur grade. Le service administratif est composé de deux secrétaires, d'un comptable, du chef du personnel et du directeur. Tous les employés sont référencés par un code mnémotechnique de 3 caractères et le chef du personnel ne tient pas à ce que l'informatisation du zoo bouleverse ses habitudes. L'informaticien interroge ensuite les gardiens. Il apprend que le zoo est divisé en huit secteurs qui ont chacun une fonction bien précise (oiseaux, reptiles, aquarium, singes,...) et sont placés sous la responsabilité d'un chef de secteur. Chaque secteur est divisé en un certain nombre de parcelles, qui sont surveillées par des gardiens pendant les heures d'ouverture au public. L'emploi du temps des gardiens est très précis et est toujours défini pour une semaine à l'avance. Chaque gardien ne surveille qu'un seul secteur par jour mais change de parcelle toutes les heures. Chaque chef de secteur doit surveiller son secteur entier et vérifier que les gardiens sont bien à leur place. L'emploi du temps des gardiens est actuellement écrit manuellement sur un tableau blanc, mais après l'informatisation il sera édité automatiquement avec deux types d'états (listings) différents : un exemplaire commun avec l'emploi du temps complet pour l'affichage (état 1), et des exemplaires individuels avec l'emploi du temps personnel pour chaque gardien (état 2). Chaque gardien peut choisir jusqu'à trois secteurs favoris (pour lesquels il se porte volontaire) et trois secteurs non appréciés. Ses affinités seront prises en compte dans la mesure du possible lors de la définition de l'emploi du temps. ......... Secteur Singes : Parcelle 1 Parcelle 2 Parcelle 3 Parcelle 4 Parcelle 5 Lundi 09H-10H JEA DUV YVE LUC VIT 10H-11H VIT JEA DUV YVE LUC 11H-12H YVE LUC VIT JEA DUV 12H-13H LUC DUV JEA YVE VIT

43


... ...

Etat 1 : Emploi du temps par secteur, par parcelle, par jour et par heure. Emploi du temps de : Jean-Marc Dupuis Semaine du 28-02 au 5-03 Lundi : secteur Singes, parcelles 1 - 2 - 4 - 3 - 5 - 2 - 1 - 3 Mardi : secteur Reptiles, parcelles 3 - 1 - 2 - 3 - 1 - 2 - 3 - 1 Mercredi : secteur Reptiles, parcelles 1 - 2 - 3 - 1 - 2 - 3 - 1 - 2 .....

Etat 2 : Emploi du temps d'un gardien, par jour, par secteur, par parcelle et par heure. L'informaticien se renseigne enfin auprès du service vétérinaire qui s'occupe des pensionnaires (animaux) du zoo. Les pensionnaires sont classés en deux catégories : les individus et les groupes. Les individus sont les animaux qui possèdent un nom et pour lesquels on conserve une fiche signalétique précise : l'espèce, la date de naissance, ses mesures (poids et taille) prises à dates périodiques (pour vérifier sa croissance) et enfin son groupe sanguin. De plus, si l'individu est né en captivité (dans le zoo) on conserve sa parenté (sa mère et son père supposé s'il est connu). Le service conserve donc les fiches de tous les individus du zoo, même ceux décédés (dans ce cas on conserve la date de décès). Les groupes sont des ensembles d'individus qui appartiennent à la même espèce et qui ne peuvent être appréhendés isolément (termites, souris blanches, poissons clown, ...). Pour chaque groupe on conserve le nombre approximatif d'animaux qui le compose. Chaque espèce est donc représentée soit sous la forme d'un groupe soit sous la forme d'un ou de plusieurs individus. Chaque espèce n'est présente que dans une seule parcelle, mais, dans certains secteurs, une même parcelle peut accueillir plusieurs espèces différentes. Des demandes typiques auxquelles la base de données devra pouvoir répondre sont :

- Afficher l'emploi du temps hebdomadaire global des gardiens (par secteur, par parcelle, par jour et par heure).

- Afficher l'emploi du temps personnel du gardien Michelot selon le format jour, heure, secteur, parcelle. - Quels sont les noms de secteurs et les noms et prénoms des gardiens qui apprécient ce secteur et dans

lequel le nombre de volontaires est inférieur ou égal au nombre de parcelles à surveiller ? (Dans le but d'affecter les gardiens aux secteurs qu'ils apprécient lorsque leurs demandes peuvent être satisfaites)

44

Chapitre 5: Normalisation d’une relation

E x e r c i c e s S u p p l é m e n t a i r e s


Exercice 1. Inventaire des œuvres d'art Les musées d'art veulent constituer une base de données commune des œuvres d'art qu'ils possèdent. Actuellement le conservateur de chaque musée garde, pour chaque œuvre, les informations suivantes: type (peinture, collage, sculpture, lithographie, etc.), titre, année, nom de(s) artiste(s), matière(s), dimensions, le courant artistique (impressionnisme, cubisme, etc.) auquel elle appartient s'il est défini (certaines œuvres sont inclassables) et éventuellement le numéro de l'exemplaire possédé par le musée (certains types d'œuvres comme les lithographies et les sculptures en bronze sont tirées en plusieurs exemplaires, le musée peut alors posséder l'œuvre ou/et l'un, voire plusieurs, des exemplaires de l'œuvre). En plus, certains conservateurs se sont constitué des fiches techniques décrivant:

- les principaux courants artistiques: nom du courant, période (année de début, année de fin), texte descriptif;

- les artistes: nom, prénom, nationalité, date de naissance, éventuellement date de décès, les courants auxquels il/elle a participé par ses œuvres, texte descriptif.

Ils veulent aussi mettre ces fiches en commun dans la base de données. Cette base de données devra permettre de répondre à des questions du type:

- Où est (nom et ville du musée) telle œuvre de tel(s) artiste(s)? Dans le cas d'une œuvre à exemplaires, liste des (nom, ville) des musées conservant un exemplaire de l'œuvre.

- Liste (titre, année) des œuvres créées par tel artiste. - A quels courants a participé tel artiste? - Où sont (nom et ville du musée) les œuvres de tel courant artistique? - Liste des titres et des noms de(s) artiste(s) des œuvres d'un musée. - Renseignements sur tel artiste (information sur l'artiste et liste de ses œuvres). - Renseignements sur tel courant artistique. - Liste des musées de telle ville.

Exercice 2. Annuaire téléphonique On veut gérer un annuaire téléphonique, ainsi que la facturation des appels. L'annuaire répertorie les personnes, les sociétés et leurs numéros de téléphone. Un même numéro peut être partagé par plusieurs personnes ou sociétés situées à la même adresse. Une même personne ou société peut posséder plusieurs numéros. Les personnes et sociétés sont répertoriées avec leurs noms, adresses, éventuellement une ligne de commentaire et leur(s) numéro(s) de téléphone. Les personnes et sociétés possèdent en plus un numéro d'abonné unique permettant à l'organisme de les identifier, même après résiliation ou changement de numéro de téléphone (il n'y a pas deux abonnés avec le même numéro d'abonné). Dans le cas d'une personne, on mémorise aussi ses prénoms, et, dans celui d'une entreprise, sa rubrique professionnelle. Pour la gestion de la facturation, qui est fonction de l'heure, de la durée et de la distance, on mémorise pour chaque appel le numéro appelé, la date, l'heure et la durée. On mémorise aussi, afin de pouvoir calculer la distance, pour chaque numéro de téléphone l'indicatif de la région correspondant à ce numéro. Dans le cas d'un numéro affecté à plusieurs personnes ou sociétés, une de ces personnes/sociétés est l'abonné principal: c'est à elle que sont envoyées les factures.

45


Exercice 3. Immatriculation de véhicules L'administration d'Enregistrement des Véhicules désire connaître les informations relatives aux propriétaires et aux transactions (achat/vente) effectuées sur les véhicules. À chaque véhicule, elle assigne un numéro d'enregistrement. Il n'existe pas deux véhicules ayant le même numéro d'enregistrement. À tout moment, un véhicule n'appartient qu'à un seul propriétaire, qui est soit un constructeur, soit un garage, ou encore une personne privée. Il peut avoir été possédé par plusieurs propriétaires (à des moments distincts). Un constructeur, un garage ou une personne privée est connu de l'administration d'Enregistrement des Véhicules, c'est à dire considéré comme faisant partie de l'ensemble des propriétaires s'il possède ou a possédé un véhicule. Qu'il soit constructeur, garage ou personne privée, un propriétaire est caractérisé par un numéro l'identifiant. Pour un constructeur, on connaît son nom, son adresse ainsi que les garages avec lesquels il travaille (garages concessionnaires). Un garage est caractérisé par un nom, une adresse et un numéro de registre de commerce. On connaît le nom, le prénom et l'adresse d'une personne privée. Pour toute transaction effectuée sur un véhicule, on connaît le vendeur (ancien propriétaire), l'acheteur (nouveau propriétaire), la date de transaction et le prix d'achat/vente. Un véhicule peut faire l'objet de plusieurs transactions (à des dates différentes). Il n'est pas exclu que deux transactions réalisées à des dates différentes puissent porter sur un même véhicule, un même vendeur et un même acheteur. Un constructeur ne peut vendre ses véhicules à d'autres constructeurs, ni directement à des personnes privées. Il ne les vend qu'à ses garages concessionnaires. Il n'achète aucun véhicule. Un garage peut vendre ou acheter des véhicules à des personnes privées ou à des garages. Il peut, bien sûr, acheter également des véhicules aux constructeurs pour lesquels il est concessionnaire. Une personne privée ne peut vendre ou acheter des véhicules qu'à des personnes privées ou à des garages. Ceci signifie donc que seuls, les véhicules dont le propriétaire "du moment" est un constructeur, n'ont été l'objet d'aucune transaction.

46

conception d'un schéma entité-association

Documents