Chapitre 1 UN MODELE CONCEPTUEL: LE MODELE ENTITE- ASSOCIATION

Transcription

1 Chapitre 1 UN MODELE CONCEPTUEL: LE MODELE ENTITE- ASSOCIATION 1. Concepts de base et diagrammes EA Le modèle entité-association (EA, appelé aussi entité-relation ou ER) est un modèle de données de type conceptuel. Comme tel, il est actuellement utilisé par plusieurs méthodes et outils d'aide à la conception des bases de données (MERISE, IDA, Yourdon,...). Ce modèle est actuellement limité à la description statique: son but est de permettre la description conceptuelle des structures de données d'une application. L'idée fondamentale du modèle EA est de retenir comme concepts de base pour la représentation les mêmes concepts génériques que ceux qui guident le processus d'abstraction conduisant de l'observation d'une réalité à sa description. On suppose que la perception d'une situation observée se fait naturellement sur la base d'une identification des objets présents (qu'ils soient réels, une personne, ou abstraits, une foule), de liens entre ces objets (une personne conduit une voiture) et de propriétés observables (la taille d'une personne, la couleur d'une voiture,...). Le modèle EA propose une description sur la base de ces mêmes trois concepts, renommés de façon à distinguer facilement le discours sur la réalité (fait en termes d'objets, liens et propriétés) du discours sur la représentation de la réalité (fait en utilisant les termes du modèle). La correspondance entre les trois concepts génériques et la terminologie du modèle EA est la suivante: objet entité lien association propriété attribut Entité représentation d'un objet du monde réel (concret ou abstrait), perçu par le concepteur comme ayant une existence propre, et à propos duquel on veut enregistrer des informations. Une entité existe indépendamment du fait qu'elle puisse être liée à d'autres entités de la base de données. Exemples: Mme Dupont, Mr. Durand, la cafetière X32, l'atelier de fabrication A22, le service Comptabilité, sont des objets susceptibles d'être représentés par des entités. Type d'entité (TE) représentation d'un ensemble d'entités perçues comme similaires et ayant les mêmes caractéristiques. Exemples: Employé (représentation de l'ensemble des employés),, Atelier de fabrication, Service,... Association Bases de données avancées

2 représentation d'un lien entre plusieurs entités, lien où chaque entité liée joue un rôle déterminé. Si l'association lie deux (ou plus) entités du même type, elle est dite "cyclique" et, dans ce cas, la spécification du rôle de chaque entité est indispensable pour supprimer les ambiguïtés possibles. Exemples: le lien de fabrication entre l'atelier A22 (rôle: producteur) et la cafetière X32 (rôle: objet produit); le lien de travail entre l'employé Durand et le service Comptabilité; le lien de mariage entre Mr. Durand (rôle: époux) et Mme Dupont (rôle: épouse),... peuvent être représentés par des associations entre les entités correspondantes. Type d'association (TA) représentation d'un ensemble d'associations ayant la même sémantique et décrites par les mêmes caractéristiques (liant des entités de même type avec les mêmes rôles, et possédant les mêmes propriétés). Exemples: le TA fabrique lie le TE Atelier de fabrication au TE, chaque association de ce TA exprimant le fait qu'un atelier de fabrication donné fabrique un article donné; travaille lie le TE Employé au TE Service pour exprimer que tel employé travaille dans tel service; est marié avec lie le TE Personne avec lui-même pour exprimer que telle personne, l'époux, est mariée à telle autre personne, l'épouse. Attribut représentation d'une propriété associée à un TE, ou à un TA, ou participant à la composition d'un autre attribut. L'ensemble des attributs d'un TE (TA) représente l'ensemble des informations inhérentes que l'on souhaite conserver sur les entités (associations) du TE (TA). Exemples: nom, prénoms, salaire sont des attributs du TE Employé; quantité-en-fabrication est un attribut du TA fabrique; date-de-mariage est un attribut du TA est-marié-avec; jour, mois, année sont des attributs composant un attribut date,... On appelle occurrence d'un TE (TA) toute entité (association) appartenant à l'ensemble décrit par le TE (TA). On appelle population d'un TE (TA) l'ensemble des occurrences du TE (TA). La base de données décrite par un schéma EA est donc l'ensemble des populations des TE et TA apparaissant dans le schéma. Une occurrence de TE est vue par l'utilisateur comme un ensemble de valeurs: une valeur pour chaque attribut du TE (NB: il est possible que la valeur d'un attribut soit en fait une absence de valeur ou un ensemble de valeurs). Une occurrence de TA est vue par l'utilisateur comme un ensemble de valeurs (éventuellement vide) et un ensemble d'occurrences de TE : une valeur pour chaque attribut du TA (s'il en existe), et, pour chaque rôle associé au TA, une occurrence du TE qui joue ce rôle. Il faut remarquer que les termes type, population, occurrence sont génériques (ne sont pas propres au modèle EA, ni aux modèles conceptuels). Le modèle EA permet une représentation graphique assez lisible du schéma d'une base de données. Dans cette représentation, appelée diagramme EA, les types d'entités sont représentés par des rectangles; les types d'associations sont représentés par des hexagones ou autre symbole similaire (ovale, losange...). Les attributs sont soit rattachés au TE (TA) par des traits (convention utilisée ici), soit listés à l'intérieur du rectangle TE (hexagone TA), au dessous du nom du TE (TA) et séparés de celui-ci par une barre (voir les diagrammes MERISE, par exemple). Bases de données avancées

3 Par exemple, le diagramme EA suivant illustre le schéma d'une base de données pour la gestion d'un hypermarché. Dans ce diagramme, sont représentés quatre types d'entité: - Employé, d'attributs nom et salaire; - Rayon, d'attributs nomr et étage; -, d'attributs noma et type; - Fournisseur, d'attributs nomf et adresse. Ces types d'entité sont reliés par les types d'association suivants: - Livraison, d'attribut quantité, liant Fournisseur, et Rayon; - Vente, d'attribut quantité, liant Rayon et ; - Emploi, liant Employé et Rayon; - Chef, cyclique, liant Employé (avec le rôle Inf) et Employé (avec le rôle Sup). La signification des différents types de traits (pleins, pointillés,...) est précisée dans le paragraphe 3. Sup Employé Chef Fournisseur Inf nom salaire nomf adresse Emploi Livraison quantité Rayon Vente nomr étage quantité noma type Un premier diagramme pour la base de données Hypermarché 2. Représentations multiples: la généralisation/spécialisation Un type d entité représente une classe d'objets du monde réel perçus comme similaires et ayant les mêmes caractéristiques. Or, il arrive parfois qu'un même ensemble d'objets soit perçu d'un certain point de vue comme une seule classe, mais en même temps perçu d'un autre point de vue comme plusieurs classes, différentes malgré l'existence de caractéristiques communes. Exemple: dans le diagramme EA décrivant un hypermarché, le TE regroupe tous les articles vendus, quels qu'ils soient; certains traitements doivent pouvoir accéder de façon uniforme à tous les articles: inventaire, recherche des caractéristiques d'un article dont on ne connaît que le code,... Pour d'autres usages, on peut néanmoins vouloir séparer les articles en plusieurs classes (alimentation, habillement, Hi-Fi, hygiène,...). Par exemple, la gestion des ventes promotionnelles n'aura pas les mêmes critères suivant la catégorie, les articles d'alimentation doivent être retirés des Bases de données avancées

4 rayons lorsque la date limite de vente est dépassée. Chaque classe peut avoir des caractéristiques qui lui sont propres, par exemple: date limite de vente (alimentation), taille et couleur (habillement),... On sera donc amené à décrire, en plus du TE générique, des TE plus spécialisés, représentant les sous-classes "intéressantes" (celles sur lesquelles on a effectivement quelque chose de particulier à faire). Par exemple, un TE " alimentaire", un TE " d'habillement" et un TE " Hi-Fi". Ceci, toutefois, introduit une situation atypique: celle où les mêmes objets sont représentés par deux TE (le TE générique et l'un des TE spécialisés), alors que normalement les populations de deux TE représentent des classes d'objets disjointes. Pour décrire une telle situation atypique, les modèles de données récents incluent le concept de généralisation/spécialisation: un lien, orienté, d'un TE spécialisé (ou spécifique) vers un TE générique. La sémantique de ce lien est qu'à toute occurrence du TE spécifique correspond une occurrence du TE générique qui décrit le même objet du monde réel. Inversement, à toute occurrence du TE générique correspond zéro ou une occurrence par TE spécifique. Graphiquement, ce lien est représenté par une flèche orientée du TE spécifique vers le TE générique. Pour l'exemple de l'hypermarché, le diagramme suivant affine la représentation des articles: alimentaire habillement Hi-Fi Les liens de généralisation/spécialisation sont souvent appelés liens "est-un" (IS A); on dit que " alimentaire est-un ". On dit également que le TE spécifique est un sous-type du TE générique qui, lui, est sur-type du TE spécifique. En effet, par convention, les attributs communs au TE générique et aux TE spécifiques ne sont décrits, dans le schéma, que comme attributs du TE générique. Néanmoins, ils sont implicitement inclus dans les attributs des TE spécifiques: on dit que ces derniers "héritent" des attributs du TE générique. En plus des attributs hérités, les TE spécifiques peuvent avoir des attributs propres. Ce qui a été dit pour la description et l'héritage des attributs s'applique également à l'héritage des rôles d'association. Par exemple, le TE " Hi-Fi", comme les autres TE spécifiques, est implicitement lié par les TA Vente et Livraison, hérités du TE. Il pourrait, en plus, être lié par un TA Réparation à un TE Service après-vente (tel type d'articles de Hi-Fi est réparé par tel Service après-vente). Ce dernier TA n'est défini alors que pour les articles du TE Hi-Fi. Un diagramme plus précis (mais partiel) pour la base de données exemple Hypermarché est donc: Bases de données avancées

5 Vente alimentaire Livraison habillement marque noma type n code quantité en stock Hi-Fi date limite de vente tailles couleurs puissance Réparation Service après-vente Il n'est pas nécessaire que les TE spécifiques représentent, dans leur ensemble, tous les objets représentés par le TE générique. Ainsi, dans l'exemple, les articles d'hygiène, de bricolage,... ne constituent pas d'autres classes spécifiques et sont donc uniquement représentés par le TE. De même, les TE spécifiques d'un même TE générique ne représentent pas nécessairement des populations disjointes, comme le montre le diagramme qui suit, décrivant des personnes travaillant ou étudiant dans un campus universitaire. Cet exemple illustre également le fait qu'un TE générique peut à son tour être sous-type d'un autre TE: on dit alors que l'on a une hiérarchie de généralisations. On parle de généralisation multiple lorsqu'un TE est sous-type de plusieurs autres TE. C'est le cas dans l'exemple du campus universitaire pour le TE Assistant-doctorant, qui regroupe la population des personnes qui sont à la fois Assistant et Doctorant. La généralisation multiple pose des problèmes liés à l'héritage: éviter d'hériter deux fois d'un ancêtre commun (dans l'exemple, Assistant-doctorant doit hériter une seule fois de Personne, soit via Doctorant-Etudiant, soit via Assistant-Enseignant-Employé), éviter d'avoir des conflits d'héritage (par exemple, lorsque deux attributs portant le même nom se trouvent dans deux TE génériques différents dont on hérite). Pour résoudre ces conflits d'héritage, soit le concepteur spécifie explicitement une préférence d'héritage, soit le système applique une règle implicite déterministe. Bases de données avancées

6 Personne no matricule nom prénom Etudiant section Employé classe de traitement sujet Doctorant Enseignant Technicien Administratif Assistant Professeur Assistant-doctorant laboratoire dirigé 3. Description d'un schéma EA Un TE est décrit par les spécifications suivantes: - le nom du type d'entité; - le nom du (ou des) type(s) d'entité sur-type de ce type d'entité, s'il en existe; - une définition libre (commentaire) précisant la population exacte du type d'entité; - la description des attributs du TE; - la composition des identifiants du TE, s'il en existe (voir 4). Exemple: description du TE "Employé" de la base de données hypermarché: - nom : Employé; - sur-types: / ; - définition: "toute personne salariée par l'entreprise en ce moment"; - attributs: nom, salaire (avec leur description); - identifiant: nom. Remarques: - deux TE différents ne peuvent avoir le même nom; - la définition libre est une partie très importante de la description d'un TE. C'est elle qui permet de définir exactement, de façon non ambiguë, la population du TE. Elle inclut notamment la spécification temporelle (soulignée dans l'exemple), qui permet de savoir si le contexte modélisé couvre uniquement la situation actuelle ou aussi l'historique (les situations antérieures) et/ou la prospective (situations à venir). Un TA est décrit par les spécifications suivantes: - le nom du type d'association; - une définition libre (commentaire) précisant la population exacte du type d'association; Bases de données avancées

7 - les noms des TE participant au TA, avec le nom du rôle les associant au TA. En pratique, le nom de rôle n'est obligatoire que pour les associations cycliques; - pour chaque rôle, ses cardinalités: c'est une information supplémentaire exprimant la règle de participation des entités dans les associations (au niveau des occurrences). Les cardinalités consistent en deux nombres, min et max, spécifiant le nombre minimal et le nombre maximal d'occurrences du TA qui peuvent, à un instant donné, lier par ce rôle une occurrence quelconque du TE en question; min et max sont deux entiers tels que max=min, min=0, max=1. Dans le cas d'une cardinalité maximale supérieure à 1, on précise si les rôles liant une entité constituent une liste ou un ensemble (valeur par défaut). - la description des attributs du TA, s'il en existe; - la composition des identifiants du TA, s'il en existe (voir 4). Exemple: description du TA "Emploi" de la base de données hypermarché: - nom: Emploi - définition: "lie un employé au rayon dans lequel cet employé travaille aujourd'hui" - TE participants: Employé, Rayon - cardinalités: Employé: min=0, max=1 Rayon: min=0, max=n - attributs: / - identifiant: ( Employé nom + Rayon nomr 1 ) Les cardinalités possibles pour un rôle (ici, Employé de Emploi) et leur signification sont les suivantes: min=0 : un employé peut ne travailler dans aucun rayon min=1 : un employé doit travailler dans au moins un rayon max=1 : un employé ne peut travailler dans plus d'un rayon max=n : un employé peut travailler dans plusieurs rayons La représentation graphique des rôles et des attributs varie en fonction des cardinalités associées au rôle ou à l'attribut, selon le tableau ci-dessous: minimum maximum n 1 n m n Certains auteurs utilisent une convention graphique différente, consistant à indiquer explicitement les cardinalités par deux chiffres (min,max ou min:max) au voisinage du trait continu représentant le rôle correspondant: Parent 0:n 2:2 est parent de Enfant La signification des cardinalités dans ce diagramme est: un parent peut avoir de 0 à n enfants; un enfant a toujours (dans cette base de données) deux parents. 1 la notation pointée Employé nom désigne l'attribut nom du TE Employé. Plus généralement, X a désigne le composant a de l'objet X. Bases de données avancées

8 Les TA cycliques suivent les mêmes conventions. Rappelons qu'un TA est dit cyclique s'il lie plusieurs fois, avec des rôles différents, le même type d'entité. Dans ce cas, les noms de rôle sont essentiels pour éviter des ambiguïtés. Ils sont donc explicitement notés sur le diagramme. Par exemple, un TA cyclique modélisant le lien de composition associant à un produit composé les produits le composant sera illustré comme suit: Produit nomp est composé de est composant de Composition quantité Si l'on représente dans la base de données d'un constructeur automobile la composition d'une voiture, on pourra obtenir les occurrences suivantes: TE Produit : occurrence nomp p1 voiture p2 carrosserie p3 roue p4 moteur p5 porte... TA Composition : occurrence est composé de est composant de quantité c1 p1 p2 1 c2 p1 p3 5 c3 p1 p4 1 c4 p2 p Un attribut est décrit par les spécifications suivantes: - nom de l'attribut; - définition libre (libellé en clair); - cardinalités: min et max, spécifiant combien de valeurs de cet attribut sont autorisées (au minimum, au maximum) dans: une occurrence du TE (TA), si l'attribut est directement rattaché au TE (TA), une valeur de l'attribut dont il est composant, sinon (voir ci-dessous). Dans le cas d'une cardinalité maximale supérieure à 1, on précise si les valeurs de l'attribut constituent une liste, un ensemble ou un multi-ensemble (valeur par défaut); - si l'attribut n'est pas composé d'autres attributs: domaine de valeurs associé, spécifiant quel est l'ensemble des valeurs autorisées pour l'attribut; - si l'attribut est composé d'autres attributs: description des attributs composants. Exemple: description de l'attribut "nom" du TE Employé de la base de données hypermarché: - nom: nom - définition: "nom de l'employé, nom de jeune fille pour une femme" - cardinalités: min=1, max=1 (tout employé a un nom et un seul) - domaine de valeurs: l'ensemble des chaînes de caractères de longueur inférieure à 15. Bases de données avancées

9 Exemple: description d'un attribut "date de naissance" d'un TE Personne - nom: date de naissance - définition: "date de naissance de la personne" - cardinalités: min=1, max=1 (tout personne a une date de naissance connue) - composition: - nom: jour - définition: "jour de naissance de la personne" - cardinalités: min=1, max=1 - domaine de valeurs: les entiers dans l'intervalle [1,31] - nom: mois - définition: "mois de naissance de la personne" - cardinalités: min=1, max=1 - domaine de valeurs: les entiers dans l'intervalle [1,12] - nom: année - définition: "année de naissance de la personne" - cardinalités: min=1, max=1 - domaine de valeurs: les entiers dans l'intervalle [1870,1993] Terminologie: on appelle: attribut simple: attribut complexe: attribut monovalué: attribut multivalué: attribut obligatoire: attribut facultatif: Le diagramme suivant: un attribut qui n'est pas décomposé en d'autres attributs: ses valeurs sont atomiques. Un domaine lui est associé. Exemple: salaire, téléphones un attribut qui est décomposé en d'autres attributs: ses valeurs sont des valeurs composées. Exemple: adresse, composé de: rue, ville, code postal un attribut qui ne peut prendre qu'une seule valeur par occurrence (cardinalité max=1). Exemple: nom, date de naissance un attribut qui peut prendre plusieurs valeurs par occurrence (cardinalité max>1). Exemple: prénoms, téléphones un attribut qui doit prendre une valeur au moins par occurrence (cardinalité min=1). Exemple: nom, prénoms un attribut qui peut ne pas prendre de valeur dans une occurrence (cardinalité min=0). Exemple: salaire, téléphones Bases de données avancées

10 Employé liste liste liste n E nom prénoms CV postes diplôme année intitulé salaires date-début date-fin montant date année mois illustre un TE Employé, qui a deux attributs simples, monovalués et obligatoires (n E et nom), un attribut simple, multivalué et obligatoire (prénoms) et deux attributs complexes et multivalués (CV et postes), dont le premier est facultatif et le deuxième est obligatoire. Il convient de souligner que la définition d'un attribut (ou d'un rôle) comme étant obligatoire induit une contrainte sur la création des occurrences correspondantes. En effet, la création d'une occurrence ne peut être acceptée que si tous les attributs (rôles) obligatoires reçoivent une valeur dès sa création. 4. Identifiants des TE et TA Définition: un identifiant d'un TE (ou TA) est un ensemble minimum d'attributs tel qu'il n'existe pas deux occurrences du TE (ou TA) qui ont la même valeur pour ces attributs. Un TE, comme un TA, peut avoir plusieurs identifiants; il peut n'en avoir aucun. Dans ce cas, des occurrences de même valeur sont autorisées. Exemple: n employé et (nom+prénoms) sont deux identifiants du TE Employé, si dans cette entreprise il n'y a jamais deux employés ayant les mêmes nom et prénoms, ou le même numéro. Les identifiants des TE peuvent être représentés sur le diagramme en les soulignant (attention à distinguer l'existence de deux identifiants de celle d'un identifiant composé de deux attributs). Par contre, pour ne pas surcharger le diagramme, les identifiants des TA sont en général précisés textuellement en commentaire du diagramme Identifiant d'un TA Exemple: soit le TA Mariage suivant, représentant les mariages actuels: AVS Personne nom sexe état-civil époux épouse Mariage Une occurrence du TA Mariage est un triplet: < <un époux>, <une épouse>, date > Comme l'attribut AVS est l'identifiant de Personne, Mariage possède deux identifiants: époux AVS et épouse AVS Cette définition n'est valable que si la population du TA Mariage ne contient que les mariages en cours (on ne garde pas l'historique). Si le TA Mariage conservait l'historique (les mariages passés), les cardinalités des deux rôles seraient 0,n et les identifiants du TA seraient: date Bases de données avancées

11 ( époux AVS + date ) et ( épouse AVS + date ) Un TA dont tous les rôles ont une cardinalité maximum supérieure à 1, a souvent (mais pas toujours) un identifiant qui est constitué de l'ensemble des identifiants des TE liés. Exemple: soit un TA Contrôle, avec une occurrence (donc une moyenne, et un ensemble de notes) par étudiant par matière suivie. Ce TA représente les résultats acquis, à ce jour, par un étudiant dans une matière. Etudiant Contrôle Matière N Carte notes moyenne coef NumMat En supposant que les identifiants des TE soient ceux indiqués sur le diagramme, l'identifiant du TA Contrôle est: ( Etudiant N Carte + Matière NumMat ) Néanmoins, il n'est pas toujours vrai que l'identifiant d'un TA est constitué de l'ensemble des identifiants des TE liés. Si l'un des rôles du TA a une cardinalité maximum égale à 1, l'identifiant du TE associé à ce rôle est un identifiant du TA (ce qui était le cas de Mariage, dans la première version). Par exemple, soit le TA suivant: noma Cie Assurance nomp Personne Assure Voiture numv L'identifiant du TA Assure n'est pas ( Personne nomp + Cie Assurance noma + Voiture numv ) car ce triplet ne constitue pas un ensemble minimal. En effet, l'attribut numv de Voiture suffit, à lui seul, pour identifier une occurrence d'assure. Ceci est dû à la cardinalité 1,1 du rôle de Voiture dans le TA, qui garantit que pour une valeur de numv il n'y aura qu'une seule occurrence d'assure avec cette valeur de numv. D'où la règle suivante. Règle: si le TA a une cardinalité maximum égale à 1 pour un des TE liés, alors tout identifiant de ce TE est identifiant du TA. Une autre règle peut être établie pour les cas où plusieurs occurrences du TA lient les mêmes occurrences des TE. Dans l'exemple ci-dessous, plusieurs commandes peuvent être passées par un même client pour un même produit à des dates différentes. Dans ce cas l'identifiant du TA contient au moins un attribut du TA. Produit Commande Client N Produit N Commande date quantité N Client Le TA Commande a ici deux identifiants: ( N Produit + N Client + date ) et N Commande 4.2. Identifiant d'un TE faible Bases de données avancées

12 Un TE est dit faible si aucun sous-ensemble de ses attributs ne constitue un identifiant (il n'a pas d'identifiant qui lui soit interne), et qu'un identifiant peut être défini en intégrant un identifiant d'un autre TE' qui lui est lié par un TA binaire de cardinalité (1,1) pour TE. On dit dans ce cas que TE dépend de TE'. Dans l'exemple ci-dessous, Exemplaire (qui représente un exemplaire d'un livre) est un TE faible (N ex n'est pas un identifiant) dépendant du TE Livre. On dit que Exemplaire dépend de Livre car, du fait des cardinalités, il n'est pas possible de créer une occurrence de Exemplaire sans la rattacher à une occurrence existante de Livre. Ce type de dépendance est appelé dépendance d'existence. Livre Correspond Exemplaire ISBN titre N ex état L'identifiant d'un TE faible (qui est le même que celui du TA) est constitué de l'identifiant du TE dont il dépend et d'un (ou plusieurs) attribut du TE faible. L'identifiant de Exemplaire (et du TA "Correspond") est: ( Livre ISBN + N ex 2 ) 4.3. Identifiant d'un TE sous-type Soit E un TE sous-type du TE E', alors tout identifiant de E' est aussi identifiant de E. E n'a pas nécessairement d'identifiant qui lui soit propre. Dans l'exemple de l'hypermarché, alimentaire, habillement et Hi-Fi ont tous les trois pour identifiant celui de (n code). 5. Contraintes d'intégrité Les concepts d'entité, d'association, d'attribut et de sous-type ne suffisent pas à décrire tout ce qui caractérise les données d'un schéma EA. Par exemple, pour le TA Mariage du 4.1, une règle connue mais non exprimée par ce diagramme est: si une occurrence de Personne participe à l'association Mariage, alors la valeur de son attribut état civil doit être "marié". Un formalisme possible, inspiré de la logique du premier ordre, pour cette règle est: x,y Personne, <x,y> Mariage x état-civil = "marié" y état-civil = "marié" (soient x et y deux occurrences quelconques de Personne, alors, le fait que la paire <x,y> forme une occurrence de mariage implique que l'attribut état-civil dans les occurrences x et y a la valeur "marié") D'autres règles possibles s'appliquant à cet exemple sont: - seuls les hommes peuvent participer à l'association mariage dans le rôle "époux" x,y Personne, <époux:x, épouse:y> Mariage x sexe = "M" - seules les femmes peuvent participer à l'association mariage dans le rôle "épouse" x,y Personne, <époux:x, épouse:y> Mariage y sexe = "F" 2 ISBN signifie "international standard book number". C'est un numéro qui identifie tout nouveau livre édité. Bases de données avancées

13 - si l'état-civil d'une personne est "marié", celui-ci ne peut être changé en "célibataire" x Personne, t1,t2 Temps, t2>t1 x(t1) état-civil="marié" x(t2) état-civil? "célibataire" De telles règles, définissant les états (ou transitions d'état) possibles de la base de données et qui ne peuvent pas être décrites avec les concepts du modèle, sont appelées contraintes d'intégrité. Si les valeurs de la base de données ne satisfont pas ces contraintes, il y a une "erreur" dans la base de données; on dit que la base de données est incohérente. Lors du passage au schéma logique (celui implanté sur le SGBD), les contraintes d'intégrité peuvent être implémentées par des prédicats de contraintes (par exemple les CHECK de SQL), par des procédures déclenchées automatiquement (par exemple les TRIGGERS de SQL) ou par des procédures associées au schéma (par exemple les "stored procedures" de SQL). Contraintes d'intégrité sur les attributs Les contraintes d'intégrité les plus fréquentes limitent les valeurs possibles d'un attribut à certaines valeurs du domaine sous-jacent. Dans le cas le plus simple, elles sont du type: age [0,130]. Il s'agit ici d'une limitation définissant de façon fixe une même fourchette pour toutes les valeurs de l'attribut. Ces contraintes simples disparaissent si le modèle permet une définition précise des domaines de valeurs, au lieu des définitions ne faisant appel qu'à des domaines généraux prédéfinis (entier, réel, chaîne de caractères, booléen,...). Les limites peuvent être définies en fonction du contexte (valeur d'un autre attribut, participation à une association,...). Exemples: - si mois {4, 6, 9, 11} alors jour [1:30], sinon si mois=2 alors jour [1:29] sinon jour [1:31] ; - si une Personne participe à l'association Mariage, alors son état civil doit être "marié"; - une française mariée avant 1986 a pour premier nom, le nom de son mari; une française mariée après 1986 a pour premier nom son nom de jeune fille. Contraintes d'intégrité sur les cardinalités D'autres types de contraintes d'intégrité limitent les cardinalités des TE, des TA, ou des valeurs des attributs. Exemple: On suppose, dans le diagramme Parent-Enfant du paragraphe 3, que les attributs du type d'entité Parent sont les suivants: nom, prénoms, adresse, nombre-enfants. Il existe alors la contrainte d'intégrité: nombre-enfants = nombre d'occurrences du TA "est parent de" qui lient ce Parent. Contraintes d'intégrité sur les généralisations/spécialisations Dans une hiérarchie de généralisation/spécialisation, il est fréquent de trouver des contraintes d'intégrité décrivant le partage de population entre les sous-types d'un même sur-type: - contrainte de couverture, pour spécifier que l'union des populations de certains TE spécifiques d'un même TE générique est égale à la population du TE générique; - contrainte de disjonction, pour spécifier que les populations de certains TE spécifiques d'un même TE générique n'ont aucune occurrence en commun; Bases de données avancées

14 - contrainte de partition, pour spécifier que la population d'un TE générique se distribue complètement et sans intersection entre certains de ses TE spécifiques (partition = couverture + disjonction sur les mêmes TE spécifiques). Par exemple, dans la base de l'hypermarché, les trois sous-types de sont disjoints: un article alimentaire n'est jamais un article d'habillement et vice-versa. Un autre type de contrainte peut être défini sur les groupes de sous-types issus d'un même sur-type s'ils sont statiques. A priori un objet du monde réel peut se transformer et changer de classification. Par exemple, dans la base de données du campus universitaire vue à la fin du paragraphe 2, un étudiant ayant fini sa licence peut devenir assistant doctorant, puis ayant fini sa thèse il peut devenir assistant, puis plus tard devenir professeur. La même occurrence change donc de sous-type au cours de sa vie. Le groupe de sous-types est alors dit "dynamique". Au contraire certains groupes de soustypes ne permettent aucun changement de classification. Par exemple pour l'hypermarché, le groupe de sous-types d' est statique: un article d'habillement ne peut pas se transformer en article alimentaire, etc. De tels groupes de sous-types sont dits statiques. C'est une contrainte d'intégrité. disjoint statique alimentaire habillement Hi-Fi En conclusion: Un schéma conceptuel entité association est un ensemble de descriptions de types d'entité et de types d'association (avec leurs attributs et les liens de généralisation entre types d'entité), et des contraintes d'intégrité associées. Bases de données avancées