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

Association

Bases de données avancées 2004-2005 1

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

Bases de données avancées 2004-2005 2

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.

Sup
Employé Chef Fournisseur
Inf
nom salaire nomF adresse

Emploi Livraison

quantité

Rayon Vente Article

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

Bases de données avancées 2004-2005 3

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.

Pour l'exemple de l'hypermarché, le diagramme suivant affine la représentation des articles:

Article

Article Article Article

alimentaire habillement Hi-Fi

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 (mais partiel) pour la base de données exemple Hypermarché est donc:

Bases de données avancées 2004-2005 4

 Livraison

marque
nomA
Vente Article type
n°code
quantité en
stock

Article Article Article

alimentaire habillement Hi-Fi

date limite de tailles couleurs puissance

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

Bases de données avancées 2004-2005 5

 no matricule
Personne nom
prénom

Etudiant section Employé classe de

traitement

sujet Doctorant Enseignant Technicien Administratif

Assistant Professeur

laboratoire dirigé
Assistant-doctorant

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 2004-2005 6

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

0:n 2:2
Parent 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 2004-2005 7

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:
est composé de
Produit Composition
est composant de
nomP 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 p5 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.

Bases de données avancées 2004-2005 8

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: 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).
Exemple: salaire, téléphones

Le diagramme suivant:

Bases de données avancées 2004-2005 9

 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.

4.1. Identifiant d'un TA

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

époux
Personne Mariage
épouse
AVS nom sexe état-civil date

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:

Bases de données avancées 2004-2005 10

 ( é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 2004-2005 11

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é, 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, é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 2004-2005 12

 - 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 2004-2005 13

 - 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 Article 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 sous-
types ne permettent aucun changement de classification. 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
alimentaire, etc. De tels groupes de sous-types sont dits statiques. C'est une contrainte d'intégrité.

Article

disjoint statique

Article Article Article

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 2004-2005 14