Chapitre 2 CONCEPTION D'UN SCHEMA ENTITE- ASSOCIATION

Transcription

1 Chapitre 2 CONCEPTION D'UN SCHEMA ENTITE- ASSOCIATION 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 décrites dans les paragraphes 1.1 et 1.2 ci-dessous), puis de transcrire ce diagramme en schéma (étape décrite dans le paragraphe 1.3 ci-dessous) en apportant les précisions supplémentaires sur les éléments qui ne sont pas représentés graphiquement : définitions de la sémantique des types d'entité (TE), des types d'association (TA) et des attributs, contraintes d'intégrité Construction progressive du diagramme entité association Le concepteur étudie l'existant et les besoins de l'entreprise en recensant les fiches, formulaires, bordereaux, fichiers, ancienne base de données, etc 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, soustypes, 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. Bases de données avancées

2 - 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 modélisations différentes. Par exemple, un mariage peut être représenté comme une association entre des entités personnes, ou comme une 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 soustype (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 c'est-à-dire 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 Vérification du diagramme entité association Une fois le diagramme entité association établi, plusieurs types de vérification sont effectuées : Bases de données avancées

3 - 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 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 ou en orienté-objets 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 : Bases de données avancées

4 liste N carte nom prénoms datenais adresse jour mois année n rue ville NPA 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, 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 TE liés par un TA. 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 : E1 0:1 R m:n E3 i:j E2 E1 E2 E1 E3 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 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). Bases de données avancées

5 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 : n étudiant nom adresses n rue ville n étudiant, nom et adresses sont les attributs directs du TE, 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 : n??tudiant d?partement directeur_d?partement nom_?tudiant L'identifiant de ce TE 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 : n étudiant département nom_étudiant intitulé directeur Bases de données avancées

6 Autre exemple de TE mal défini : n??tudiant d?partement directeur_d?partement Ce TE 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 : n??tudiant d?partement nomdep directeur 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. 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 Bases de données avancées

7 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. Laboratoire nomlab directeur chercheurs nomc adresse dateentrée %temps projets nomp budget description ligne montant 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. Exemple : Contrôle Matière N Carte notes moyenne coef NumMat 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 Bases de données avancées

8 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 : Contrôle Enseignant N Carte notes coef Nom Cours Nom Cours 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 : Contrôle Enseignant N Carte Cours notes Assure Nom Nom Cours coef 3.3. Validation d'un TA (arité) Règle 4 : Soit un TA bien construit, liant les TE E 1, E 2,..., En; s'il existe une dépendance : (E 1,..., Ei) Ei+1, alors il existe la dépendance : (E 1,..., 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 0:n 0:n Travaille Labo 1:n Projet d?pendance Bases de données avancées

9 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 0:n Travaille Labo 0:n Affect? 1:n 1:1 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 0:n 0:n Travaille Labo 0:n Affect? 1:1 Projet 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. Exemple : Inscrit 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. Bases de données avancées

10 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 : Employé Service n emp n service n étage nom 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 : Employé Travaille Service n emp n étage nom 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 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 : Bases de données avancées

11 Employé n emp service n étage nom 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é. Cours Alieu dans Salle Cours n n salle 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.? Inscrit Cours cours intitulé salle horaire intitulé salle horaire 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. 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. Bases de données avancées

12 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. Bases de données avancées

13 4.1. Diagramme entité association de FormaPerm nom pr?noms liste Personne adr. jour mois ann?e n? E daten?tudes dipl meann?e liste liste couverture Enseignant t?l. statut rens.banc. banque compte agence Obtenu Inscrit Assure multi-ensemble notes ann?e Cours nomc est-un a-pour cycle Pr?requis 4.2. Définitions des types d'entité et d'association : 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 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, 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. Bases de données avancées

14 e, 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, on doit avoir : (Date - e daten) = 18 ans. e (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, pour toute valeur v de e études, on doit avoir : v année > e daten année. Pour toute occurrence e de, pour toute occurrence o de Obtenu liant e, on doit avoir : o année > (e daten année + 18). e, v e études v année > e daten année e, 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 et/ou de Enseignant. p Personne ( e ( 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) Type d'entité: 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 Bases de données avancées

15 Identifiant: (n E) diplôme: 1:1, simple: Dnom ) 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: Identifiant: (nomc) nomc: 1:1, simple: Dnom cycle: 1:1, simple: entier Type d'association: Obtenu Rôles: (0:n) liste, Cours (0:n) Attributs: notes: 1:n multi-ensemble, simple: Dnote année: 1:1, simple: Dannée Identifiant: ( + Cours) Type d'association: Assure Rôles: Enseignant (0:n), Cours (1:1) Attributs: / Identifiant: (Cours) Type d'association: Inscrit Rôles: (0:n), Cours (0:n) Attributs: / Identifiant: ( + 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) Bases de données avancées