Conception de Bases de Données

Modèle entité/association

Le modèle E/A est un modèle conceptuel de haut niveau. Il est
souvent utilisé comme modèle de données pivot de
méthodes de conception (Merise par exemple). Il a été
élaboré par Chen [Chen 1976]. Il s'agit d'une des
premières tentatives pour intégrer au modèle de
données plus de sémantique, afin de se rapprocher de la
réalité considérée.

De nombreuses variations et extensions ont été faites sur ce
modèle. Aucun SGBD commercialisé ne l'implante (il s'agit d'un
modèle dit de conception). Un handicap fort est qu'il n'y a pas de
langage de manipulation associé (ou plutôt il y en a plusieurs,
aucun ne s'étant imposé).

Les concepts du modèle entité/association

Entité

Une entité est un objet du monde réel avec une existence
indépendante. Chaque entité a des propriétés particulières
("attributs") qui la décrivent. Une entité donnée a des valeurs pour chacun de ses attributs. Un attribut peut être composé hiérarchiquement de
plusieurs autres attributs (attribut composite par opposition à
attribut simple ou atomique).

Exemple : attribut composite "adresse". Une adresse peut être décomposée de la façon suivante :
  • libellé
    • numéro
    • rue
    • no-appt
  • ville
  • pays
  • codepostal
Un attribut peut être monovalué ou multivalué. Is se peut que la valeur d'un attribut peut être dérivée d'une ou plusieurs autres valeurs d'attributs. Par exemple, l'age d'une personne peut être dérivé de la
date du jour et de celle de sa naissance l'attribut "age" est appelé "attribut dérivé" et "est dérivable de" l'attribut "date de naissance"

Une valeur d'attribut peut également être dérivée
à partir d'entités reliées (par exemple, l'attribut
"nombre d'employés" d'une entité "département" peut
être calculé en comptant le nombre d'entités
"employé" reliées à ce département).

Ensemble d'entités ou type d'entité

Les entités ayant même propriétés sont
regroupées dans des ensembles d'entité (ou type
d'entité). Un ensemble d'entité est défini par un nom et
une liste d'attributs. Parmi les attributs d'un ensemble d'entité on distingue les attributs
clés c'est à dire ceux dont la valeur discrimine chaque
entité. Les attributs clés identifient donc une entité et
garantissent l'unicité des entités ayant même valeur de
clé. Un domaine de valeur est associé à chaque attribut simple (et
par conséquent, on peut construire le domaine des attributs composites
à partir du produit cartésien du domaine de ses attributs
simples).

Ensemble d'associations

Un ensemble d'associations A (par abus de langage ou dit très
souvent association) défini sur n ensembles d'entité E1,
..., En est un ensemble d'associations entre des entités de ces
ensembles.

A inclus dans E1 X ... X En

Une association représente un lien quelconque entre différents
objets du monde réel. Le degré d'une association est le nombre d'ensembles d'entité
y participant. Chaque ensemble d'entités participant à un ensemble
d'associations y joue un rôle particulier. Le "nom du rôle"
décrit le rôle joué. Ce nom de rôle est
intéressant lorsque le même ensemble d'entité participe
plusieurs fois dans un même ensemble d'associations (l'ensemble
d'associations est alors dit "récursif"). Par exemple, l'ensemble d'association "chef de" défini sur "employé"
X "employé" doit distinguer entre le chef et son subalterne.

Contraintes sur les ensembles d'associations : "contraintes
structurelles"

De manière à décire plus précisément la
sémantique des associations, leur définition est
précisée par des propriétés qui sont les
cardinalités minimale et maximale.

Pour les ensembles d'associations binaires la cardinalité minimale
(maximale) d'une association est le nombre minimum (maximum) d'entités
de l'ensemble d'entités d'arrivée associées à une
entité de l'ensemble de départ. Les valeurs les plus
fréquentes pour la cardinalité minimale sont 0 (association
partielle), 1 (association totale), N (association multivaluée). Pour la
cardinalité maximale on rencontre 1 ou N. Ces cardinalités sont
importantes lorsque l'on réalise la transformation d'une
modélisation E/A en modélisation relationnelle.

On peut également définir des attributs sur des ensembles
d'associations. Ceux ci reprennent les mêmes caractéristiques de
construction que les attributs sur les ensembles d'entités.

Ensemble d'entité non identifié ou faible :
"weak entity type"

Certains ensembles d'entités dits faibles n'existent qu'en
référence à d'autres ensembles d'entités dits
identifiants. L'ensemble identifiant est appelé "identifiant
étranger" et l'association qui les unit "association identifiante". Un
ensemble d'entité non identifié a une contrainte de
cardinalité 1:1 sur son association d'identification (sinon il pourrait
y avoir des éléments non identifiés).

Un ensemble d'entité non identifié a une clé locale qui
permet d'identifier une entité dans l'ensemble des entités
associées à une entité identifiante. La clé
complète d'un ensemble d'entités faible est la
concaténation de la clé de l'ensemble d'entités
identifiante et de sa clé locale. Il existe implicitement une contrainte
existentielle entre une entité identifiante et ses entités
identifiées (en cas de suppression de l'entité identifiante, il
faut également supprimer les entités identifiées).

Cette notion correspond à un besoin d'abstraction supplémentaire.
En effet, il est difficile de décrire tous les ensembles d'entité
dans une application "au même niveau", il est intéressant de
pouvoir les hiérarchiser. Cette construction représente en
quelque sorte la composition d'objets composites que l'on retrouve dans les
modèles orienté-objet ou l'approche relationnel étendu.

D'ailleurs, un ensemble d'entité non identifié peut être
quelque fois représenté comme un attribut composite ou
multivalué. C'est la même sémantique d'identification, mais
on ne peut définir des associations sur les composants alors que l'on
peut le faire sur les ensembles d'entité non identifiés.

En général, on peut définir des ensemble d'entité
non identifiés à autant de niveaux que l'on veut.

Comparaison modèle entité/association et modèle relationnel 

MODELE E/A
 
MODELE RELATIONNEL

ensemble d'entité

  relation
entité n-uplet
attribut simple attribut atomique
attribut composite simulé par un ensemble d'attributs
attribut dérivé simulé par une vue
ensemble d'entité faible simulé par une relation
ensemble d'assocation nouvelle relation ou clé étrangère dans relation existante
association n-uplet

Règles de traduction d'un modèleentité/association vers un modèle relationnel

  • Règles portant sur la transformation des ensembles d'entités :

    (R1) pour chaque ensemble d'entité identifié E, on crée
    une relation R dont le schéma est celui de l'ensemble d'entité
    (les attributs composites sont aplatis, c'est à dire on concatène
    leur définition). La clé de R est une des clés de E.

    (R2) pour chaque ensemble d'entité non identifié I ayant un
    identifiant étranger E, on crée une relation R qui comprend tous
    les attributs de I. De plus on définit comme clé
    étrangère dans R, les attributs clés de la relation
    correspondant à E. La clé de R est la concaténation de la
    clé partielle de I et de la clé de l'identifiant
    étranger.

  • Règles portant sur la transformation des ensembles d'associations
    :

    (R3) Chaque ensemble d'associations est transformé en une
    relation dont le schéma est constitué d'une part de la clé
    de chacun des ensemble des entités participants à l'association
    et d'autre part (le cas échéant) des attributs propres à
    l'ensemble d'association). La clé de la relation obtenue se
    déduit de l'analyse des cardinalités de l'ensemble d'association
    (c'est au plus la concaténation des clés des ensembles
    d'entités participants).

    Cette règle conduit à produire un grand nombre de relations et ne
    dérive donc pas la solution la plus compacte (en terme de nombre de
    relations). Si l'on veut obtenir le nombre minimum de relations (au
    détriment de la lisibilité certes), il faut appliquer à la
    place de la règle (R3), les règles (R3') et (R4') :

    (R3') pour chaque ensemble d'association binaire R de type 1:1 entre les
    ensembles d'entités S et T (représentés par les relations
    RS et RT respectivement) on inclut dans la définition de RS comme
    clé étrangère la clé de RT. Tous les attributs
    simples de R sont ajoutés à la définition de S.

    (R4') pour chaque ensemble d'association binaire A de type M:N ou pour chaque
    ensemble de relation A de degré supérieur à 2, on
    crée une nouvelle relation RA pour représenter A. On met dans RA
    comme clé étrangère, les clés de toutes les
    relations correspondant aux ensembles d'entité participant à A.
    On ajoute également à RA tous les attributs définis sur A.
    La clé de RA est la concaténation des clés
    étrangères.

  • Règle portant sur la transformation des attributs multivalués
    :

    (R5) pour chaque attribut multivalué M d'un ensemble d'entités E
    (idem pour un ensemble d'associations), on crée une nouvelle relation RM
    qui comprend un attribut monovalué correspondant à A plus la
    clé de RE (relation représentant E). La clé de RM est la
    concaténation des deux attributs.

  • Règle portant sur la transformation des attributs
    dérivés :

    (R6) chaque attribut dérivé est représenté par une
    vue dont la définition correspond à la traduction en SQL de la
    règle de dérivation.

 Exemples de traduction

 Nous illustrons le processus de traduction d'un modèle entité/association vers un modèle relationnel au travers de deux exemples : la base des vins élargie et la base de gestion du personnel.

Traduction de la base des vins élargie

Le schéma entité association à traduire est le suivant. 

Application de (R1)

VINS(nv, cru, mil, degré)

VITICULTEURS(nvt, nomv, prénomv, villev)

BUVEURS(nb, nomb, prénomb, villeb)

COMMANDES(nc, datec)

Application de (R2)

EXPEDITIONS(nc, datee, qte) où nc est la clé de la relation correspondant à l'ensemble
d'entités identifiant COMMANDES

Application de (R3')

(R3') COMMANDES(nc, datec, nb, nv, qte) où nb représente un numéro de buveurs et nv représente numéro de vin avec
qte comme attribut supplémentaire.

Les associations sont mono-valuées dans le sens COMMANDES vers VINS et COMMANDES vers BUVEURS

Application de  (R4')

PRODUCTIONS(nv+nvt)

L'association est multivaluée dans les deux sens, donc la clé est
la concaténation des clés des entités participantes

Le schéma relationnel obtenu est donc Traduction de la base de gestion du personnel

Le schéma entité association à traduire est le suivant.  Vous trouverez aussi une description de cette BD ici.

Application de (R1)

EMPLOYE(noss, nomf, prenom, salaire)

DEPARTEMENT(numérod, nomd)

PROJET(numérop, nomp, local)

Application de (R2)

PERSONNESACHARGE(noss+nom, datenais, parenté)

noss est la clé de la relation correspondant à l'ensemble
d'entités identifiant EMPLOYE

Application de (R3')

EMPLOYE(noss, nomf, prenom, salaire, numérod,
nossup) où numérod permet de représenter TRAVAILLEPOUR et
nossup représente SUPERVISION

DEPARTEMENT(numérod, nomd, nosschef,
datedébut) où nosschef représente DIRIGE avec l'attribut datedébut en
plus

PROJET(numérop, nomp, local,
numérod) où numérod représente CONTROLE

Application de (R4')

TRAVAILLEDANS(noss+numérop, heures)

Application de (R5)

LOCALISATION(local+numérod)

Attention, l'attribut local représente ici une localisation et
non pas un ensemble de localisations. L'ensemble des localisations d'un
DEPARTEMENT s'obtient par sélection sur LOCALISATION de l'ensemble des
localisation correspondant à un DEPARTEMENT.

Application de (R6)

La vue exprimant l'attribut calculé nb-emp s'exprime en SQL de la
manière suivante :

CREATE VIEW EFFECTIFS(numérod, nb-emp) AS

SELECT numérod, count(*)

FROM EMPLOYE

GROUP BY numérod

Le schéma relationnel obtenu est donc Critique du modèle entité/association

Avantages

  • relativement naturel (pas trop éloigné de notre mode de
    pensée),
  • offre une représentation graphique souvent assez claire,
  • indépendant du niveau physique,
  • incorpore une sémantique relativement riche (cardinalité,
    identification),
  • supporte bien l'agrégation.

Inconvénients

  • pas de langage de manipulation associé,
  • ne supporte pas d'abstraction comme la généralisation -
    spécialisation.

Bibliographie

Navathe-Elmasri 1989, "Fundamentals of databases systems", 1989. The
Benjamin Cummings Publishing Company Inc. Series on database systems and
applications.

Chen 1976, "The Entity Relationship Model - Toward a unified view of data" ,
TODS, march 1976.

Posté le 1 septembre 2009