La méthode Merise pas à pas

C

H A P I T R E

2

U n M o d è l e C o n c e p t u e l : L e M o d è l e E n t i t é

-A s s o c i a t i o n

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), Article, Atelier de fabrication, Service, ...

Association

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 Article, 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).

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; - Article, 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, Article et Rayon; - Vente, d'attribut quantité, liant Rayon et Article;

- 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.

Employé

Fournisseur

Sup

Inf

Article

Rayon

nom

salaire

adresse

nomR

étage

quantité

nomA

type

nomF

quantité

Chef

Livraison

Emploi

Vente

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 Article 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 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 Article, 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 "Article alimentaire", un TE "Article d'habillement" et un TE "Article 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.

Article Article Hi-Fi Article habillement Article alimentaire

Les liens de généralisation/spécialisation sont souvent appelés liens "est-un" (IS A); on dit que "Article alimentaire est-un Article". 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 "Article Hi-Fi", comme les autres TE spécifiques, est implicitement lié par les TA Vente et Livraison, hérités du TE Article. 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 Article Hi-Fi.

Un diagramme plus précis pour l'exemple hypermarché est donc:

Article Article Hi-Fi Article habillement Article alimentaire Service après-vente marque nomA type n°code quantité en stock puissance couleurs tailles date limite de vente Réparation Vente Livraison

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 Article. 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.

Personne Etudiant Technicien Administratif Doctorant Enseignant Assistant Professeur no matricule nom prénom classe de traitement laboratoire dirigé section sujet Assistant-doctorant Employé

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);

- identifiants: 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;

- 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•nomR1 ₎

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 0 1 1 1 0 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:

Enfant

0:n

2:2

est parent de

Parent

1 _{la notation pointée Employé}

_•

_•

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.

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

est composé de

est composant de

nomP

quantité

Composition

Si l'on représente dans la base de données la composition d'une voiture, on pourra obtenir les occurrences suivantes: TE Produit : voiture carrosserie roue moteur ...

TA Composition: est composé de est composant de quantité

voiture carrosserie 1

voiture roue 5

voiture moteur 1

carrosserie porte 4

...

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. Exemple: description d'un attribut "date de naissance" d'un TE Personne

- nom: date de naissance

- définition: "date de naissance de la personne"

- 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: 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

attribut complexe: 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

attribut monovalué: un attribut qui ne peut prendre qu'une seule valeur par occurrence (cardinalité max=1).

Exemple: nom, date de naissance

attribut multivalué: un attribut qui peut prendre plusieurs valeurs par occurrence (cardinalité max>1). Exemple: prénoms, téléphones

attribut obligatoire: un attribut qui doit prendre une valeur au moins par occurrence (cardinalité min=1).

Exemple: nom, prénoms

attribut facultatif: un attribut qui peut ne pas prendre de valeur dans une occurrence (cardinalité min=0).

Le diagramme suivant:

n°E

nom

prénoms

_CV

diplôme année

postes

intitulé

salaires

date-début date-fin

montant

date

mois

année

Employé

liste liste liste

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.

4.1. Identifiant d'un TA

Exemple: soit le TA Mariage suivant, représentant les mariages actuels:

époux

épouse

nom sexe

état-civil

date

Mariage Personne

AVS

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:

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.

N°Carte

notes moyenne

coef NumMat

Contrôle

Etudiant

Matière

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:

Personne nomP nomA Voiture numV Assure Cie Assurance

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.

N°Produit

date

quantité

N°Client

Commande

N°Commande

Produit

Client

Le TA Commande a ici deux identifiants:

( N˚Produit + N˚Client + date ) et N˚Commande

4.2.

Identifiant d'un TE faible

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.

ISBN

titre

N°ex

état

Correspond

Livre

Exemplaire

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é, Article alimentaire, Article habillement et Article Hi-Fi ont tous les trois pour identifiant celui de Article (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,y> ∈ Mariage ⇒ x•sexe = "M"

- seules les femmes peuvent participer à l'association mariage dans le rôle "épouse"

∀x,y ∈ Personne, <x,épouse:y> ∈ Mariage ⇒ x•sexe = "F"

- 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é

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;

- 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 Articles sont disjoints: un article alimentaire n'est jamais un article Hi-Fi 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 représentation. Par exemple un étudiant de première année devient étudiant de seconde année, un étudiant devient assistant… Une contrainte possible est de définir un groupe de sous-types comme statique. Par exemple pour l'hypermarché, le groupe de sous-types d'Article est statique: un article d'habillement ne peut pas se transformer en article Hi-Fi, etc.

Article

Article

Hi-Fi

Article

habillement

Article

alimentaire

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é (CI) associées:

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

Faire le tutorial distribué durant la séance.

Cette série d’exercices doit vous permettre de prendre en main DBMAIN que vous utiliserez pour la conception du schéma Entité-Association de votre projet. DBMAIN est un outil CASE (Computer-Aided Software Engineering) ayant pour objectif d'apporter une aide dans les principaux processus de développement et de maintenance de bases de données.

La version éducative de DBMAIN peut être téléchargée sur Internet à la page suivante :

http://www.info.fundp.ac.be/~dbm/demotool65.shtml

La documentation de DBMAIN est aussi en ligne à l’adresse :