Base de Donnees Et Le Modele Entite-Association - Levraicoursdocx

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 1
I DE L’ARTISANAT A LA METHODE
Une démarche de conception de base de données doit conduire à la définition des données permanentes
nécessaires aux besoins d’un ensemble d’utilisateurs. Cette BD est relative à un domaine d’activité, à sa gestion
et à son contrôle ou même parfois à son automatisation. Un tel domaine dit d’application pourrait être une
bibliothèque, un service hospitalier, le département de marketing d’une entreprise ou son service du personnel,
etc.
Dans ces conditions la BD doit contenir toutes les données nécessaires à la représentation du domaine
d’application et rien que ces données. Ces dernières sont regroupées en tables de manière à permettre une
description aisément utilisable du domaine, et en particulier, de manière à permettre leur gestion par un
ordinateur. Lorsque le problème est simple, un utilisateur un tant soit peu habile pourra exprimer directement
ses besoins en terme de tables colonnes et contraintes. Cependant quand le domaine d’application présente une
certaine complexité, il devient difficile de raisonner pour la définition des tables.
C’et pourquoi l’on fera appel à un mode de description du domaine d’application le modèle entité-
association.
Ce modèle qui est le plus populaire de nos jours, il permet de décrire plus naturellement les concepts du
domaine et leurs informations seront représentées en tables et colonnes. Ce modèle offre une
représentation graphique du concept qu’il décrit, ce qui en fait un outil de raisonnement et de
spécifications particulièrement attrayant. La description du domaine d’application se traduira sous la forme
d’un schéma conceptuel.
II UNE DEMARCHE SIMPLIFIEE
Le schéma conceptuel est un modèle mental, abstrait des concepts du domaine d’application et des
informations. Il n’est donc pas directement implémentable dans un ordinateur. Par conséquent, il faut le
traduire en schéma de base de données (modèle logique) sous la forme de tables, colonnes et contraintes
d’intégrité. Ici encore, nous limiterons le processus de traduction en des règles simples et systématiques. La
démarche de conception des BD proposée consiste en deux phases :
• L’analyse conceptuelle au terme de la quelle les besoins en information des utilisateurs sont traduits en
un schéma conceptuel ;
• La production de la base de données par laquelle le schéma conceptuel est traduit en schéma de la base
de données.
Cette démarche se traduit par la figure ci-dessous :
Relever les types

ANALYSE d’entités et types
ENONCE
CONCEPTUELLE d’associations
SCHEMA
Sortir des
CONCEPTUEL
propositions
élémentaires

III PRINCIPE DU MODELE DE DONNEES
III.1 INTRODUCTION
L'ensemble de toutes les données de l'entreprise ou toute autre organisation peut être regroupé. Sous
l'appellation de base de données, ce regroupement représente l'information de l’organisation. Elle existe
indépendamment de l'usage qu'en font les programmes d'application ou les utilisateurs finaux. L'information
doit donc pouvoir être décrite indépendamment de l'usage qui en est fait. Cette description nécessite un modèle
de données, c'est à dire un ensemble de concepts et de règles assez généraux et riches de sémantique pour
pouvoir donner de façon formelle un schéma de la structure permanente de cette information.
Le système logiciel qui met en œuvre le modèle de données, qui stocke les données, gère les accès, les droits
des utilisateurs, et plus généralement qui traite au mieux l'ensemble des problèmes que nous venons d'évoquer,
est appelé système de gestion de base de données (SGBD).
Dès 1965 apparaît l'idée de distinguer les données de leurs traitements. Cela exige une description préalable des
données qui doit être fournie par les utilisateurs.
Pour bien comprendre cela, observons le travail que devait réaliser le programmeur et que le système doit
maintenant prendre en charge : le programmeur devait transformer en structures informatiques une certaine
vision de la réalité (par exemple une personne est stockée sous la forme d'un enregistrement composé : d'un
champ "numéro de sécurité sociale", d'un champ "nom", d'un champ "prénom" et d'un champ "date de
naissance").
C'est à présent le SGBD qui va effectuer ce travail, il recevra en entrée une description abstraite des données et
disposant de règles déclarées par l'administrateur, il choisira la façon de les stocker et de gérer les accès.
Les outils offerts par le SGBD pour décrire les données qu'il aura à stocker reposent sur un ensemble de règles
et de concepts permettant de décrire le monde réel. Ces règles et concepts constituent un modèle de données. Le
modèle entité-association peut ici être donné à titre d'exemple.
En informatique, un modèle de données est un modèle qui décrit de façon abstraite comment sont représentées
les données dans une organisation métier, un système d'information ou une base de données.
III.3 NIVEAUX DE PREOCCUPATION OU D’ABSTRACTION DU MODELE DE

DONNEES
Une théorie de modèle de données définit généralement des niveaux de préoccupation. Par exemple, dans la
méthode MERISE ou dans les modèles entité-relation , on définit des niveaux de préoccupation tels que :
• Le niveau conceptuel,
• Le niveau organisationnel,
• Le niveau physique ou opérationnel.

Ces niveaux sont décrits dans les paragraphes suivants :
• Le niveau conceptuel : que peut-on faire et avec quelles données (quoi ? avec quelles données ?)
• Le niveau organisationnel : on intègre à l'analyse conceptuelle les aspects liés aux organisations, à
savoir le lieu, les acteurs, le positionnement dans le temps, le type de traitement : automatique,
interactif, manuel (qui ? où ? quand ?)
• Le niveau physique ou opérationnel : abordé dans la phase de réalisation, elle consiste à faire les choix
techniques d'implémentation (choix de logiciels, découpage en programme). Il s'agit donc de répondre à
la question : comment?
Dans le cadre de ce cours, nous présentons uniquement le niveau conceptuel.
IV LE MODELE CONCEPTUEL DE DONNEES
De manière générale, un schéma conceptuel est une représentation d'un ensemble de concepts reliés
sémantiquement entre eux. Les concepts sont connectés par des lignes fléchées auxquelles sont accolés des
mots.
La relation entre les concepts s'appuie sur des termes exprimant cette relation: « appartiens à », « passe par »,
« mène à », « prévient que », « favorise »…
Le schéma conceptuel poursuit plusieurs buts :
• représenter le modèle mental d'une situation, que cette représentation soit personnelle, celle d'un groupe
ou d'une organisation ;
• résumer la structure de la connaissance extraite d'ouvrages écrits (état de l’art technique).
En informatique, un schéma conceptuel est une représentation graphique qui sert à décrire le fonctionnement
d'une base de données. Il représente ainsi les objets principaux contenus dans cette dernière, leurs
caractéristiques et les relations qui s'établissent entre ces différents objets. Cette représentation est normée
suivant une modélisation bien définie. Plusieurs types de schémas conceptuels existent, correspondants aux
différents types de base de données que l'on peut rencontrer :
• le modèle hiérarchique ;
• le modèle réseaux sémantiques ;
• le modèle entité / association ;
• le modèle objet ;

 Le modèle hiérarchique
L'information est organisée de manière arborescente (selon une hiérarchie), accessible uniquement à partir de la
racine de cette arborescence. Il permet de facilement ajouter des éléments et d'en modifier la structure.
Le défaut principal de cette représentation provient du fait que le point d'accès à l'information est bien unique
(c'est la racine de l'arbre hiérarchique). Cela entraîne que toute recherche de donnée demande le parcours de
toute, ou au moins partie, de la hiérarchie, en passant par la racine. L'exemple le plus courant est celui de
l'arborescence utilisé pour les systèmes de fichiers (bien qu'il ne s'agit pas de SGBD à proprement parler,
comme nous le verront plus loin), où l'on navigue depuis la racine du système vers des sous répertoires et des
fichiers contenant les données.
 Le modèle réseaux sémantiques
Ce modèle décrit le fonctionnement d'une base de données réseau. Ce type de base de données fonctionne sur le
principe du regroupement des différents éléments de la base de données par leur sens. Toutes les informations
peuvent y être associées les unes aux autres et servir de point d'accès. Cela en fait un modèle complexe dont
l'extraction de données est difficile.
L'exemple le plus concret d'un tel modèle est le web sémantique.
 Le modèle objet
Dans le cadre de ce modèle, comme dans la programmation orientée objet, les données sont décrites comme des
classes et représentées sous forme d'objet possédant des attributs et des méthodes. Chaque objet peut servir de
point d'entrée pour d'autres objets, permettant une navigation à la fois souple et aisée dans la base.
L'inconvénient principal est l'importante quantité de ressources (mémoire et temps de calcul) que nécessite cette
approche.
 Le modèle entité/association
Le modèle entité-association est un type de schéma conceptuel qui est notamment utilisé par les bases de
données relationnelles. Les points d'entrées y sont indépendant de la structure de la base de données,
l'utilisateur saisi simplement une requête, sans avoir à naviguer dans la base, et la machine se charge de
l'exécuter pour atteindre les données escomptés. Le principal inconvénient est la rigidité de la structure du
modèle définie et les difficultés que cela entraîne pour faire évoluer un schéma existant lorsqu'un besoin
nouveau apparaît ou qu'une erreur de conception est découverte. Cela inclus notamment tous les systèmes se
basant sur le langage SQL. Le modèle entité-association est le plus utilise de nos jours. C’est lui qui sera
l’objet de notre étude.

IV.1 ROLE DU MODELE ENTITE-ASSOCIATION (MEA)
Le Modèle entité-association permet de représenter la structure du système d'information, du point de vue des
données, et définit également les dépendances ou relations entre ces différentes données.
Ce modèle de données correspond à une modélisation assez naturelle du monde réel. Il se compose de trois
concepts élémentaires : l'entité, l'association et les contraintes portant aussi bien sur les entités que sur les
associations.
Une base de données se détermine à travers un domaine d’application ou d’activité par des concepts ou
données (tables contenant des lignes et des colonnes), et sur lesquelles sont appliquées des contraintes
d’intégrités, représentant les besoins en informations d’une communauté d’utilisateurs. L’on propose de
travailler en deux étapes :
1-L’élaboration du schéma conceptuel de données, qui décrit sans référence à la technologie informatique,
les concepts ou données du domaine d’application ;
2- La traduction de ce schéma en structures de bases de données, y compris éventuellement leur expression

en SQL.
IV.2 LES CONCEPTS DU MODELE ENTITES-ASSOCIATIONS
IV.2.1 Introduction et question de vocabulaire
Le modèle entités-associations est né dans les années 60 de la nécessité de décrire les besoins en informations
des utilisateurs d’une base de données d’une manière complètement indépendante des technologies de mise en
œuvre de celle-ci.
Partant de l’idée qu’une base de données doit être une description fidèle du domaine d’application, on envisage
de relever dans celui-ci les concepts principaux et leurs propriétés. L’identification et la description de ces
concepts utilise un modèle, c’est à dire une manière de voir les choses, auquel on associe une notation
graphique. Un même modèle peut faire l’objet de plusieurs notations. C’est ainsi qu’on utilise aujourd’hui plus
d’une dizaine de représentations graphiques, plus ou moins équivalentes, des objets du modèle entité-
association.
La manière de voir les choses, ou vision du monde, du modèle entités-associations est très simple. Elle consiste
à structurer le monde en classes d’entités dotées de propriétés, en associations les unes des autres. Cette
simplicité offre deux avantages majeurs : elle met ce modèle à la portée des utilisateurs peu expérimentés et elle
se traduit aisément en un schéma de base de données. Néanmoins il existe des modèles plus riches que des
utilisateurs expérimentés pourront utiliser.
Cependant, une question de vocabulaire est à relever :
Certains auteurs appelleront entité client ce que nous appelons ici type d’entité CLIENTS. Dans ce cas ce que
nous appelons entité client se dénommera instance ou occurrence du type d’entité CLIENTS. Ces deux
systèmes d’appellation sont légitimes pour autant qu’on s’en tienne exclusivement à l’un d’eux. Il est important
d’être précis dans l’utilisation des termes relatifs au modèle et aux schémas entités-associations, et en
particulier de ne pas confondre les types et leurs instances. Dans notre étude on parlera de type d’entités
CLIENTS et de l’entité c400 qui est une de ses instances. L’expression entité client est donc incorrecte. Le
tableau suivant résume les expressions admises.

TYPE INSTANCE
Type d’entité Entité
Type d’associations Associations
attribut Valeur d’attribut
IV.2.2 Les types d’entités
Le domaine d’application est perçu comme étant constitué d’objets concrets ou abstraits. Ainsi par exemple
dans le contexte du domaine d’application assurance automobile, on peut cerner les objets clients, véhicules,
contrats ou accidents. Chaque élément de ces objets, est considéré comme une entité du domaine et que chaque
entité appartient à une classe ou type d’entité. Dans le modèle entités-associations un type d’entités est donc
considéré comme une population de concepts du monde réels (ou faits) homogènes, souvent variable dans le
temps. Par exemple :
Ici l’on définira 04 types d’entités, CLIENTS VEHICULES, CONTRATS, ACCIDENTS qui sont représentés
comme suit :
CLIENTS CONTRATS ACCIDENTS

VEHICULES
Le type d’entités CLIENTS regroupe l’ensemble des clients qui ont signé un contrat d’assurance, le type
d’entités VEHICULES regroupe l’ensemble des véhicules qui ont été assurés, etc.
Un type d’entités peut correspondre à des objets concrets inanimés (véhicules), des objets concrets animés
(clients), des conventions abstraites (contrats), ou des événements (accidents).
La figure suivante représente de manière imagée une population de chaque type ou une entité est représentée
par une pastille.
CLIENTS CONTRATS VEHICULES VEHICULES
Entités Types d’entité
Figure x : types d’entités et entités
Pour compléter la représentation graphique, on définira 03 entités pour le type d’entité CLIENTS, comme
présenté sur la figure x ci-dessous.
NumClient=C400
Nom = FERRARD
Adresse= 65, r du Tertre

NumClient=B332
Nom = MONTI
Adresse= 112, r Neuve
NumClient=F010
Nom = TOUSSAINT
Adresse= 5, r Gogefroid
IV.2.3 Type d’associations
IV.2.3.1 Définition
Un type d’associations est une liaison qui existe entre des types d’entités, et qui a une signification précise.
Dans notre exemple le type d’association « signer » est une liaison évidente entre les types d’entités CLIENTS
et CONTRATS.
De même on définira des types d’associations entres les types d’entités CLIENTS et VEHICULES, indiquant
qu’un véhicule appartient à un client, CONTRATS et VEHICULES indiquent qu’un contrat couvre les risques
d’un véhicule, etc. les types d’associations sont des verbes généralement conjuguer à l’infinitif. Mais le
présent simple est aussi accepté. Le type d’association signer est représenté à la figure suivante :
CLIENT
Signer
CONTRACT
Figure x : type d’entités et type d’associations
IV.2.3.2 Propriétés d’un type d’association
La définition des propriétés d’un type d’associations entre deux types d’entités A et B indique pour chacun des
types d’entités, à combien d’associations R chaque entité doit elle participer ? Plus précisément ces propriétés
se mesureront pour chaque type d’entité participant, par le nombre minimum et le nombre maximum
d’associations auxquelles toute entité participe. Ces propriétés seront représentées en deux catégories ; la classe
fonctionnelle et le caractère obligatoire/facultatif des types d’associations. Ces propriétés seront ensuite
synthétisées sous la forme d’une propriété de cardinalité.

IV.2.3.2.1 Rôle d’un type d’association
Lorsqu’un type d’association intervient dans une relation avec des types d’entités, on dit qu’il joue un rôle. Ce
terme sera donc utilisé pour designer une des extrémités d’un type d’associations. On peut assigner un nom à
un rôle. En l’absence de nom explicite c’est celui du type d’entités qui en tiendra lieu. Généralement leur nom
est composé du nom du type d’association suivi du nom du type d’entités.
Exemple :
CLIENTS 0 ,N 1,1 CONTRATS

Signer
Signer. CLIENTS Signer. CONTRATS
IV.2.3.2.2 Cardinalités d’un type d’association
La cardinalité est défini comme un couple de valeurs traduisant le nombre minimum et maximum de fois un
type d’entités participe à un type d’associations. La cardinalité peut également être définie comme suit :
Chaque type d’entités apparaissant dans un type d’associations joue un rôle qui y est caractérisé par un couple
de valeurs min-max appelé cardinalité. On dira qu’un type d’associations (occupe par exemple) est de
cardinalité (x , y) de type d’entité source vers le type d’entité cible ou destination. Dans le cas précédent on dira
que occupe est de cardinalité (o, n) de département vers employé et de cardinalité (1,1) de employé vers
département.
DEPARTEMENT 0, N 1, 1 EMPLOYE
Occuper
Cette figure sera interprétée de la manière suivante :
Toute entité département est associée, via, occuper, à un nombre de (0,N) d’entité d’employé et toute entité
employé est associée, via occuper à (1,1) entité département. Les cardinalités possibles sont : (0,1) ; (0,n );
(1,1) ; (1 ,n) ; (n,m).
IV.2.3.2.3 Classes fonctionnelles ou type d’un type d’association
Cette propriété décrit le nombre maximum de fois une entité participe à une association. Trois classes
fonctionnelles de type d’association sont courantes : un à plusieurs, un à un , plusieurs à plusieurs. Nous allons
les définir plus amplement dans les paragraphes suivants :
a) Type d’association un à plusieurs (1 : n)
Dans le premier sens (gauche à droite) : le type d’entité DEPARTEMENT participe au maximum plusieurs fois
au type d’entité EMPLOYE; Dans l’autre sens (droite gauche) : le type d’entité EMPLOYE participe au
maximum, 1 fois au type d’entité DEPARTEMENT.

Exemple
DEPARTEMEN EMPLOYE
D D
E E
E
D E
E
D3 E E
DEPARTEMENT
N 1 EMPLOYE
OCCUPE
R
Un département est occupe par au maximum plusieurs employés : N, un employé occupe au maximum un seul
département : 1
b) Type d’association un à un (1 :1)
Chaque entité participe au maximum une seule fois à l’association.
DEPARTEMEN EMPLOYE
E3
D1 E3
D2 E3 E4
D3
DEPARTEMENT 1 1 EMPLOYE
Diriger
Un département donne est dirigé au maximum par un employé : card max 1. Un employé donne dirige au
maximum un département : card max 1

C) Types d’association plusieurs à plusieurs (N : M)
Chaque type d’entité participe au maximum plusieurs fois à l’autre.
PRODUIT
USINE
P1 P2
U1 U2
P3
U3 P4 P5
U4 P6
N M
USINE PRODUIT
Fabriquer
Une usine fabrique au maxi plusieurs produits N ; un produit donné est fabriqué au maxi par plusieurs usines.
Important : Il est essentiel de noter que les cardinalités se mettent en place après avoir répondu à deux
questions :
- une entité type donnée A VERBE participe au mini et au maxi combien d’entité B ?
- une entité type donnée B VERBE participe au mini et au maxi combien d’entité A ?
Le verbe est généralement conjugué à l’infinitif, mais il peut se mettre au présent simple ou au participe passé
selon l’emplacement du type d’entités.
IV.2.3.2.4 Type d’association obligatoire ou facultatif
On peut imposer qu’un type d’associations soit obligatoire pour un type d’entités qui y participe. C’est ainsi que
occupe sera déclaré obligatoire pour EMPLOYE, imposant que toute entité EMPLOYE (instance) participe à
une association occupe, ou encore qu’elle soit associée à une entité DEPARTEMENT (instance).
1,1
DEPARTEMENT 0, N
EMPLOYE
Occuper
Le type d’association occupe est obligatoire (Card min 1) pour EMPLOYE et facultatif (Card min 0) pour
DEPARTEMENT.

IV.2.3.2.5 Cas particuliers
• Gestion du temps et entités temporelles
La gestion du temps peut présenter plusieurs formes :
o en tant que propriété élémentaire si elle est simplement cible d'une dépendance fonctionnelle
directe (pour un véhicule, date de la prochaine révision)
o en tant qu'entité si elle est source d'une dépendance fonctionnelle directe (date ->
heureLeverSoleil, heureCoucherSoleil
o en tant qu'entité si elle participe en tant que source à une dépendance fonctionnelle (association
non fonctionnelle : numCde, refProd, dateLivr -> quantite ); on a à faire à une association
ternaire à vérifier.
• Type d’association cyclique ou récursif ou réflexif
Il est tout à fait possible d’établir un type d’associations entre un type d’entités et lui-même. Par exemple
une personne peut superviser un certain nombre de personnes, qui sont ses subordonnés.
Ce fait est illustré à travers la figure suivante :
PERSONNE
Subordonné - Une personne est responsable de 0 ou plusieurs

Responsable
• personnes
0, N 0, N - Une personne est subordonne à 0 ou plusieurs
Occuper
• Association ternaire et n-aires
Une association ternaire relie 3 entités (au delà, on parle de 'n-aires') : il est indispensable de s'assurer de
sa validité en vérifiant qu'aucune dépendance fonctionnelle entre les entités (identifiant) n'existe, c'est à
dire que idEnt1,idEnt2 -X-> idEnt3, que idEnt1,idEnt3 -X-> idEnt2, et que idEnt2,idEnt3 -X-> idEnt1
(avec '-X->' signiant 'ne détermine pas')
Pour un professeur et une matière, on peut avoir plusieurs classes, Pour une classe et une matière, on
peut avoir plusieurs professeurs (c'est le cas ici, d'enseignant pour CM, TD ou TP), Pour une classe et un
professeur, on peut avoir plusieurs matières (c'est le cas ici, où un enseignant intervient en
mathématiques et en physique)
classe
professeur 1,n
1,n
1,n
Matiere

Pour un medecin et un type d'acte, on peut avoir plusieurs patients, Pour un medecin et un patient, on
peut avcoir plusieurs type d'actes, Pour un patient et un type d'acte, on peut avoir plusieurs
médecin...mais...on vient d'appendre qu'en fait, un type d'acte n'est réalisé que par un et un seul médecin
!
1,n
acte
médecin
1,n
pratiquer
1,n
devient ci
patient f
1,n
1,1
• Entité faible dans un type d’association
Une entité faible, ou dépendante, possède un identifiant qui n'est pas suffisant pour identifier de manière
unique chacune des occurrences, mais nécessite l'identifiant d'une autre entité avec laquelle elle est
associee. L'identifiant est dit 'relatif',
DISPOSER 1,1
1,n
CHAMBRES
HOTELS
Entité forte Entité faible
• CIF et CIM
CIF : Contrainte d'Intégrité Fonctionnelle (association hiérarchique, association fonctionnelle) : permet de

définir une contrainte d'unicité dans une association, entre une ou plusieurs occurrence d'entités et une
occurrence d'une autre entité participant à cette association. Les associations hiérarchiques de cardinalités 1,1-
1,N portent par défaut une CIF.
N CIF 1
CIM : Contrainte d'Intégrité Multiple (association non fonctionnelle) : définit une association avec des
cardinalités maximales à N sur chacune de ses branches.

• Héritage et spécialisation
Si toutes les occurrences d'une entité-type ne possèdent pas toujours les mêmes propriétés ou ne sont
pas liées aux mêmes associations, l'analyse peut montrer qu'on a affaire à
o d'une part, une entité générique qui regroupe les propriétés communes à toutes les occurrences,
et qui est reliée aux associations communes,
o et d'autre part à des entités spécialisées qui comporteront leurs propres propriétés et seront
reliées à leurs propres associations. Elles héritent également des propriétés de l'entité générique :
on est en effet dans une forme de relation hiérarchique (sans association)
Pour qualifier la contrainte associée à cette spécialisation :
o X : pour eXclusion, une occurrence de l'entité générique ne peut être spécialisée que d'une seule
forme ou n'être pas spécialisée
o T : pour Totalité, une occurrence de l'entité générique est spécialisée d'une au moins des formes
proposées
o XT (ou +) : pour eXclusion et Totalité, une occurrence de l'entité générique est spécialisée d'une
seule des formes proposées
o sinon pas de contrainte: des occurrences peuvent être spécialisées d'une seule ou plusieurs
formes ou n'être pas spécialisées ( voir doc)
EMPLOYE
Id_emp
nom
prenom generalisation
specialisation
XT EMPL-VAC
EMPL-MENS
Datedebutvacation
Dateentree tauxhoraire
salairemensuel dureevacation
Quand le concepteur s’aperçoit que plusieurs entités, proches mais distinctes, partagent un ensemble de
caractéristiques, il doit mettre en œuvre un processus de création d’entités génériques (ou entités sur-types) et
d’entités spécialisées (ou entités sous-types) appelé «héritage ». Ce concept qui permet de représenter le lien «
est-un » ou « IS-A » entre deux entités A et B (une occurrence de A est une occurrence de B) est représenté
graphiquement par une flèche double allant de A vers B.
Entité générique B
Liste propriétés communes
Entité spécialisée A
Liste propriétés spécifiques

On dit qu’il y a héritage simple quand un sous-type n’a qu’un seul sur-type. Dans ce cas, toutes les
occurrences du sous-type sont en même temps des occurrences de son sur-type.
Cela n’implique pas que toutes les occurrences du sur-type soient des occurrences de l’un des sous-types. Le
schéma suivant illustre l’inclusion des ensembles d’occurrences des sous-types dans l’ensemble des
occurrences du sur-type.
Occurrences du
sur type
Occurrences du
sous type
• Agrégats ou pseudo-entité
Un agrégat est un regroupement d'entités et d'associations qui peut être associé à une autre entité (exemple de
réservations de chambre - ou de tout autre objet - pour une période donnée). Voir figure
Les agrégations sont des associations ou liens particuliers ayant la sémantique "composé-composant".
La suppression d'un "composé" peut ou non entraîner celle des "composants" ("pièces détachées"
irrécupérables ou récupérables!). Réciproquement la suppression d'un "composant" peut ou non
entraîner la suppression du "composé" (une voiture sans roue ne change pas d'identité, une voiture
avec un nouveau châssis est une autre voiture...). La notation ER classique était insuffisante pour
rendre compte de ces surcharges sémantiques. La notation UML en rend compte assez précisément
comme illustré ci-dessous : voiture
chassis roue moteur

IV.3 ATTRIBUTS ET IDENTIFIANTS
IV.3.1 Les attributs
IV.3.1.1 Généralités
Un attribut est une propriété caractéristique d’un type d’entités ou d’un type d’associations. Ici on dira que
chaque élément (ou instance) de la population de clients est caractérisé par un numéro, un nom, et une adresse.
On modélisera ces faits en dotant le type d’entités CLIENTS par les attributs numclient, nomclient,
adresseclient. De même on dotera les autres types d’entités d’attributs. Par ailleurs, il est tout à fait possible de
doter un type d’associations d’attributs. Dans notre cas, le type d’associations « Signer » dispose d’un attribut
« Datesign ». Tout cela est illustré sur la figure x ci-dessous.
CLIENT CONTRAT VEHICULE ACCIDENT

Signer
NumClient NumCtr NumVeh NumAcc
datesign
Nom Type Marque DateAcc
Adresse Datesign Modèle Montant

Année
Cylindrée
Figure x : Type d’entités, type d’associations et leurs attributs.
Une instance de l’entité type CLIENTS a pour valeurs d’attributs C400 comme Numéroclient, LAGO comme
Nom, YAMOUSSOUKRO comme Adresse.
L’on spécifiera dans le formalisme des attributs, le type de chaque attribut ; numérique caractère, date, etc.,
ainsi que sa longueur comme indiqué sur la figure ci-dessous :
VEHICULEE
Figure x : A chaque attribut correspond NumVeh : char(16)
un type de valeur Marque :char(30)
Modèle : char(30)
Annee : num(14)
cylindrée: num(06)
couleur[0-1]
Id : Numveh

Il se peut que la valeur d’un attribut ne soit pas connue au moment ou on décrit l’objet. On admet que cet
attribut puisse ne pas avoir de valeur pour certaines instances, on le déclarera facultatif par le symbole [0-1]
comme indiqué sur la figure précédente pour l’attribut couleur.
Un type d’entités et ses attributs ne doivent traiter d’un seul sujet afin d’assurer une certaine cohérence au
modèle. Dans notre exemple Les types d’entités CLIENT ET VEHICULE ne peuvent donc pas être regroupés,
leurs informations ne sont pas homogènes (un client n’a pas de marque et un véhicule n’a pas d’adresse
électronique). Il faut donc préférable de créer deux types d’entités séparés, CLIENT et VEHICULE.
IV.3.1.2 Les identifiants
IV.3.1.2.1 Généralité
En général un type d’entités est doté d’un attribut particulier qui identifie ou distingue les uns des autres,
chaque instance de ce type. Le type d’entités CLIENTS, par exemple possède un attribut NumClient tel qu’à
tout instant les instances de type d’entités CLIENTS ont des valeurs de Numclient distinctes (sans doublon), et
doivent être identifiables de manière unique. Il s’agit de l’identifiant qui est souligné par exemple sur le
schéma Access par convention.
En outre, il peut arriver qu’un type d’entités possède plus d’un identifiant. Dans ce cas, l’un d’eux peut être
déclaré primaire tandis que tous les autres sont secondaires.
IV.3.1.2.1.1 Importance du concept d’identifiant
Les identifiants d’un type d’entités sont bien plus que de simples ornements de celui-ci. Ils contribuent à en
définir la sémantique. Déterminer un identifiant de E revient à définir précisément ce qu’est une entité E,
puisqu’il s’agit de trouver en quoi une instance se distingue des autres du même type.
IV.3.1.2.1.2 Identifiants minimaux et identifiants implicites
Lorsqu’un identifiant comprend plus d’un composant, il faut s’assurer que ceux-ci sont tous indispensables
pour garantir l’unicité. On observe en effet que tout groupe de composants qui inclut un identifiant est lui-
même, un identifiant. Ainsi les attributs (numacc, date) forment un identifiant d’accident. On qualifiera de
minima un identifiant tel qu’aucun de ses composants ne puissent lui être retiré sans qu’il perde son statut
d’identifiant. On veillera à ce qu’un schéma conceptuel ne contienne que des identifiants minimaux.
IV.3.1.2.3 Les contraintes d’intégrité sur les données
Les contraintes d’intégrité formalisent certaines propriétés importantes du domaine d'application, que les
données doivent respecter. On distinguera les contraintes de base, intrinsèques au modèle entités-associations,
et les contraintes additionnelles.

IV.3.1.2.3.1 Les contraintes de base
Il s’agit des contraintes explicitement définies dans le modèle. Etant donné leur importance, on leur a attribué
un nom et une représentation graphique. Il s’agit des trois contraintes de base suivantes :
1- les identifiants (primaires et secondaires) ;

2- les attributs obligatoires ;
3- les contraintes de cardinalité des rôles.
IV.3.1.2.3.2 Les contraintes additionnelles
Elles sont désignées par toutes les propriétés qu’on voudrait voir définies dans le schéma mais que le modèle ne
permet pas d’exprimer de manière explicite. On indiquera ces contraintes sous la forme d’annotations associées
aux objets du schéma comme illustré sur la figue suivante :
Date livraison >=Date commande

ACHAT
CodeAchat
Date paiement>date livraison
Date Commande
(Date paiement non vide)si date livraison non vide
Date Livraison [0-1]
Modalité paiement={A,Q,ST} Modalité de Paiement [0-1]
Montant
Montant>0
Id : Code Achat
Figure x : Description des contraintes additionnelles au moyen d’annotations
Certaines questions sont à ce point, élémentaires, qu’il suffit d’une simple inspection du schéma pour être
convaincu que celui-ci contient l’information recherchée. Par exemple retrouver les accidents dans lesquelles
un véhicule est impliqué, ou le propriétaire d’un véhicule sont des questions auxquelles on peut de toute
évidence répondre. En ce qui concerne des demandes complexes, on fera appel à un graphe de populations. Soit
la recherche suivante : Trouver les signataires des contrats couvrant les véhicules impliqués dans un accident
déterminé. Pour répondre à cette demande, on procède comme suit :

CLIENTS
Les clients
signataires
VEHICULES
CONTRATS
ACCIDENTS
L’accident
Figure x : interrogation d’un ensemble de populations
1- On repère l’accident en question, qu’on marque de manière visible ;

2- En suivant les arcs du type d’associations impliqué, on sélectionne les véhicules impliques qui sont
également marques ;
3- A partir des véhicules marqués, on sélectionne, via les associations couvrir , les contrats qui couvent les
véhicules impliques et on les marque ;
4- A partir de ces contrats et en suivant les associations « signer », on obtient finalement les deux
signataires.
Cette manière de conduire une recherche se généralise aisément à des conditions plus élaborées portant par
exemple sur les valeurs des attributs des entités (instances, on ne retient que les véhicules de modèle X), ou sur
le nombre d’arcs (véhicules n’ayant qu’un seul accident). A ce titre d’exemple plus complexe, on imaginera un
procédé similaire permettant de vérifier qu’on peut retrouver les véhicules dont le propriétaire n’est pas le client
qui a signé le contrat qui les couvre, ou encore, en représentant cette fois les valeurs d’attributs, les accidents
qui impliquent des véhicules de la même marque.

V MODELES D'ACCES AUX DONNEES
Définit la structure des données et comment y avoir accès. On distingue :
 Le modèle navigationnel
Dans le modèle navigationnel, la structure des données est parcourue en empruntant des chemins prédéfinis
constitués par des réseaux de pointeurs. Au modèle navigationnel sont associées les notions suivantes:
Articles ; Enregistrement (RECORD) ; Ensemble (SET).
 Le modèle relationnel
Dans le modèle relationnel, les données désirées sont obtenues par la formulation de requête. Il n'est plus
nécessaire de parcourir la structure des données est en empruntant des chemins prédéfinis. C'est ce modèle
que nous étudierons dans la suite de notre cours.
V.1 LE MODELE RELATIONNEL
V.1.1 Brève description

Le modèle relationnel est une manière de modéliser les informations contenues dans une base de données qui
repose sur des principes mathématiques mis en avant par E.F. Codd.
On appelle relation un ensemble d'attributs qui définissent un fait - par exemple un employé a un matricule
donné, son nom est un tel, il travaille dans tel service et a été embauché à telle date. Chaque instance est
appelée un tuple. Les relations sont d'ordinaire représentées sous la forme de tables, et on confond les deux
concepts. On confond de même ligne dans la table et tuple dans la relation. Par définition, chaque tuple d'une
relation est unique, et est identifié par un attribut ou une combinaison de plusieurs attributs qui forme la clef.
L'ordre des tuples n'est pas significatif.
Codd a défini une algèbre relationnelle et des opérateurs qui permettent de construire d'autres relations à partir
de relations. Les idées de Codd ont été implémentées -- plus ou moins fidèlement -- dans les systèmes de
gestion des bases de données relationnelles ou SGBDR telles que le projet expérimental IBM System R, puis
des produits commerciaux tels qu'Oracle, DB2 ou MySQL, et dans le langage de manipulation des données
SQL.
Le modèle relationnel est aujourd’hui l'un des modèles les plus utilisés. « Les premiers systèmes de gestion de
base de données (SGBD ou DBMS en anglais) bâtis sur ce modèle ont été SQL/DS et DB2 de IBM, d'où est né
le langage de manipulation de bases relationnelles, SQL (Structured Query Language). »] Le modèle relationnel
est basé sur deux instruments puissants : l’algèbre relationnelle (c'est-à-dire le concept mathématique de
relation en théorie des ensembles) et la notion de produit cartésien.

Ce modèle définit une façon de représenter les données, les opérations qui peuvent être effectuées et aussi les
mécanismes pour préserver la consistance des données. E.F Codd a décrit les principes et la conception de
modèle relationnel dans son livre « A relational model of data for large shared data banks ». par exemple une
bonne utilisation du code nécessite la redéfinition d'une entité qui va être exploitable dans la présentation de
données.
VI PROCESSUS DE CONCEPTION D'UNE BASE DE DONNEES
Le travail de conception commence par une analyse du domaine à modéliser, on établie une cartographie des
notions qu'il comprend et des détails de leurs relations, c'est le schéma conceptuel.
On traduit ensuite cette cartographie uniquement en termes d'ensemble d'éléments, les relations devenant des
éléments à part entière, c'est le modèle logique.
Enfin on implémente le résultat dans un ensemble logiciel, c'est le schéma physique (même si les logiciels
sont virtuels, il s'agit de la structure concrètement utilisé).Cela est illustré à la figure suivante :
Représentation MODELE
CONCEPTUEL
Entite- association-
DOMAINE
cardinalité
D’ACTIVITES
Traduction
Implémentation MODELE
MICRO- LOGIQUE
ORDINATEUR
Les relations ou
VI.1 LABORATION D’UN SCHEMA CONCEPTUEL
Le processus d’élaboration d’un schéma conceptuel d’une base de données est crucial, car il conditionne la
qualité de celle-ci, et complexe car il représente une activité de modélisation de situations issues de la réalité.
Modéliser consiste à construire une représentation abstraite formelle, généralement de nature mathématique,
des aspects des situations sur lesquels porte notre intérêt. Un modèle d’un domaine d’application nous permet
de mieux comprendre celui-ci, de raisonner à son sujet et de construire des systèmes techniques, tels qu’une
base de données ou une application informatique qui représente, contrôle ou pilote ce domaine d’application.
Le formalisme de représentation utilisé ici est le modèle entités-associations.
Conformément à l’approche simplifiée que nous avons utilisée pour la conception des BD, nous nous limiterons
à une démarche simple et intuitive.

Les sources d’informations utilisées lors de l’élaboration d’un schéma conceptuel peuvent être extrêmement
diverses. En accord avec l’objectif de parcours rapide, nous nous limiterons à un seul type d’informations
constitué d’un énoncé en langage courant. Généralement l’on se servira d’interviews, de textes légaux, de
formulaires ou d’écrans s’il en existe ou encore de l’observation du fonctionnement de l’organisation.
Le processus peut s’exprimer comme suit : à partir d’un énoncé, construire un schéma entités-
associations représentant les concepts ou faits exprimés d’un domaine d’activité.
Les principaux problèmes rencontrés surgissent lorsque les propositions contenus dans l’énoncé sont
incomplètes, redondantes, contradictoires ou même erronées. Il existe plusieurs façons de présenter un concept
d’un énoncé. Tout en supposant que le processus est en cours et disposant déjà d’un embryon de schéma
traduisant les concepts de l’énoncé jusqu’au point courant (schéma courant), on propose de procéder à
l’élaboration du schéma conceptuel comme suit :
- On décompose l’énoncé en phrases, ou en propositions élémentaires ;

- Chaque proposition si elle est pertinente pour le domaine d’application est comparées aux types
de faits déjà incorporés dans le schéma courant, si le type de fait qu’elle exprime est absent et est
non contradictoire, il est traduit en termes du modèle entités-associations et incorporé dans le
schéma courant.
- On documente le schéma ;
- On vérifie que le schéma est complet ;
- On vérifie que le schéma ne contient pas d’erreurs ;
- A la fin du processus le schéma courant est le schéma final.
VI.2 UN PREMIER EXEMPLE
Nous illustrons le processus de construction d’un schéma conceptuel par un premier exemple élémentaire.
Supposons qu’on dispose du texte ci-après, décrivant la manière dont un employé de bibliothèque voit son
environnement de travail :
un employé peut emprunter des livres ou en réserver ; l’employé a un nom et une adresse ; il possède un
numéro unique et travaille dans un service de l’entreprise, l’entreprise est identifié par son nom ; l’on
connait la localisation d’un service ; un ouvrage porte un numéro ISBN et possède un titre, un prix et une
date d’achat. La figure suivante montre un schéma conceptuel qui pourrait être tiré de cet énoncé.

Le service possède un nom
SERVICES
Le service a une location

Nom
Localisation
Le service est identifie par son nom
Id : Nom
Un employé travaille dans un service
0-N Un employé peut emprunter des ouvrages
Travailler
Emprunter 0-1 OUVRAGES un ouvrage un numéro ISBN
0-N
ISBN
1-1 un ouvrage porte un titre
EMPLOYES Titre
Numéro un ouvrage porte une date d’achat
Date achat
Nom 0-N Réserver 0-1
Id :ISBN Le numéro ISBN est unique
Adresse Un employé peut réserver un ouvrage
Id : Numéro Le numéro de l’employé est unique

Un employé a un nom
Un employé a une adresse
Un employé possède un numéro
Un premier coup d’œil nous montre que chaque élément du schéma traduit un fragment de texte, cependant en
regardant de plus prés on remarque :
• Certains fragments ont été reformulés (le numéro de l’employé est unique) ;
• Certains fragments n’ont pas été utilisés (le prix) ;
• On perçoit bien comment les attributs et les types d’associations ont été détectés, mais la détection des
types d’entités est moins évidente ;
• Certains fragments fournissent la même information et sont donc redondants (livres et ouvrages
apparaissent comme des synonymes) ;
Il semble que le concept d’ouvrage ne soit pas compris et que son expression soit erronée : confusion entre
ouvrages et exemplaires, le texte contient donc des formulations incorrectes :
• Enfin un schéma ainsi annoté est plus lisible et compréhensible que si les fragments étaient retirés :
ceci contribue donc à la documentation du schéma.
C’est donc par une analyse critique des informations que l’on peut tirer de l’énoncé que les éléments pertinents
du schéma pourront être identifies. Nous allons le montrer dans les paragraphes suivants :
VI.3 DECOMPOSITION DE L’ENONCE
L’énonce est décomposé en propositions élémentaires décrivant chacune un concept ou un type de faits qui
pourra être traduit en composants du schéma conceptuel.

VI.3.1 Notion de propositions élémentaires
La forme standard qui et privilégiée correspond à la composition suivante : Sujet Verbe Objet
Quelques exemples :
• Tout client a un nom ;

• Une commande est passée par un client ;
• Un voyage est effectue par un train ;
• Un service traite des dossiers
Les propositions de ce type, sont qualifiées de binaires, puisqu’elles comportent deux termes, affirment
l’existence de deux concepts, représentés respectivement par le sujet et l’objet, et d’un lien représenté par le
verbe entre deux concepts.
La première phrase exprime l’existence de trois types de faits :
• L’existence du concept client ;

• L’existence du concept nom ;
• L’existence d’un lien (a verbe avoir) entre client et nom.
certaines formes plus simples peuvent être envisagées :

• Il existe des fournisseurs :
• On s’intéresse aux accidents.
D’autres propositions plus complexes peuvent être reformuler :
• Un employé est identifié par un numéro matricule et caractérisé par un nom et une adresse.
Elle pourra être décomposée en trois propositions élémentaires :
• Un employé est identifié par un numéro matricule ;
• Un employé est caractérisé par un nom ;
• Un employé est caractérisé par une adresse.
Ou encore, la phrase :
• Le cout du produit devra…
Recèle en fait deux propositions :
• Le produit a un cout,
• Le cout du produit devra…
On veillera aussi à expliciter les raccourcis du langage que constituent les pronoms personnels ou possessifs :
• Il peut contracter une assurance (le client)

• Son département (l’employé…)

VI.4 CARDINALITE
Pour les propositions du type « A verbe B » ou A et B désignent deux concepts pertinents ou verbe indique
l’ existence d un lien entre ces concepts ; on cherchera à obtenir la réponse aux questions suivantes :
1 pour un exemplaire de A ; combien trouve- t- on d’exemplaires de B, au minimum et au maximum ?
2 pour un exemplaire de B, combien trouve-t- on d’exemplaires de A, au minimum et au maximum ?
Ainsi, la proposition « une commande est passée par un client » sera-t- elle affinée par la réponse aux
questions :
1 par combien de client une commande est- elle passée ? (réponse de1 à1)
2 combien de commandes un client peut – il passer ? (réponse de 0 à plusieurs)
De même, la proposition « un client a une adresse » doit-elle être analysée de manière plus approfondie par
les questions :
1 combien un client a –t- il d adresses ?
2 combien de client peut-on trouver a une adresse déterminée ?
On sera attentif à la différence d’interprétation des pronoms un ou une dans les deux dernières phrases. Ainsi,
dans la proposition « une commande est passée par un client » une commande signifie toute commande,
tandis qu’un client est interprété comme un seul client.
La réponse à de telles questions se trouve parfois dans la formulation même de la proposition. Des locutions
telles que : tout, certains , chaque ; les formes verbales utilisant pouvoir ou devoir ; les expressions au moins
un , un seul , au plus un , des ou les , permettent de déterminer l’ information recherchée. Dans d autres
cas nous ferons appel, soit à des informations complémentaires (interview dirigée) , soit à notre connaissance
du domaine d application , soit encore au simple bon sens.
VI.5 PROPOSITIONS GENERALES ET PROPOSITIONS PARTICULIERES
Les propositions énoncées jusqu’ici sont générales, en ce sens qu’elles sont vraies pour tous les faits de même
nature, présents et futurs. Elles s’expriment au niveau des concepts généraux et non au niveau des exemples et
cas spécifiques. Une proposition telle que :
• Toute voiture a un numéro minéralogique : Spécifie un type de faits général dans le domaine
d’application choisi, tandis que la :
• Ma voiture a le numéro minéralogique HB G -82910 : est particulière, elle constitue un fait
élémentaire qui n’est qu’un exemple de la première.
Le terme «Toute voiture » de la première proposition désigne un concept alors que le terme « Ma
voiture » désigne un objet concret de ce concept c'est-à-dire une occurrence, un exemplaire ou une
instance. Le numéro minéralogique désigne un concept de HBG910-82 qui en est une occurrence.

VI.5.1 Propositions complexes irréductibles
Certaines propositions non binaires ne peuvent, sans qu’on perde de l’information être réduites aussi
simplement en propositions binaires. Considérons la proposition suivante ternaire :
Les clients achètent des produits chez des fournisseurs, elle peut être décomposée en plusieurs propositions
binaires :
• Les clients achètent des produits
• Les fournisseurs vendent des produits
• Les clients s’approvisionnent chez des fournisseurs
VI.5.2 Propositions non binaires réductibles
Certaines propositions en apparence irréductibles doivent impérativement être décomposées en propositions

binaires sans passer par un concept intermédiaire. Exemple ;
Un trajet est organisé entre une ville de départ et une ville d’arrivée, Peut se décomposer en :
- Un trajet a une ville de départ ; Un trajet a une ville d’arrivée.
On réduira de même manière, les énoncés complexes suivants :
• Un médecin dirige un service dans son hôpital ;

• Les entreprises inscrivent certaines de leurs employés à des sessions de formation.
La première proposition concerne trois concepts : médecins, service et hôpital. A un médecin correspond un
seul service et à un service correspond un seul hôpital. ->deux propositions (médecins services), (services,
hôpital).
De même la seconde proposition suppose qu’un employé travaille dans une seule entreprise, ce qui permet d’y
repérer les deux propositions binaires (employé-entreprise) et (employé-hôpital).
Par contre la proposition « les clients achètent des produits chez des fournisseurs » n’est pas
décomposable parce qu’aucune des affirmations suivantes n’est correcte : Un client n’achète qu’un seul
produit ; Un client n’achète que chez un seul fournisseur ; Un produit n’est achète que par un seul
client ; Un produit n’est acheté que chez un seul fournisseur ; Un fournisseur ne vend qu’à un seul
client ; Un fournisseur ne vend qu’un seul produit.

VI 5.3 Pertinence d’une proposition
Certaines propositions apportent de toute évidence une contribution au schéma conceptuel. D’autres en
revanche doivent être considérées comme du bruit dans ce processus et sont ignorées. Certaines cependant
peuvent cacher des structures qu’il faut mettre en lumière par une analyse plus approfondie. Considérons les
fragments d’énoncés suivants, dans un domaine d’application relatif à une compagnie d’assurance automobile.
Exemple1 : Un véhicule est couvert par une police : proposition pertinente à retenir
Exemple2 : On enregistre le véhicule dès que la prime est payée : Cette proposition décrit une contrainte
d’exécution d’activités de gestion. Elle sera certainement utile lors de la conception de programmes
informatiques, mais semble moins directement exploitable ici. Cependant une analyse plus approfondie plus
approfondie pourrait conduire à retenir les propositions dérivées : Un véhicule a une date d’enregistrement ;
Une prime a une date de paiement.
Il serait alors aisé de vérifier dans un programme la règle d’antériorité exprimée par la proposition d’origine.
Exemple3 : Les véhicules que la compagnie assure….
Etant donne qu’on s’intéresse qu’aux véhicules assurés par la compagnie et que cette unique compagnie
constitue ou contient le domaine d’application cette proposition n’apporte aucune information, sinon l’existence
probablement déjà connue de la notion de véhicule. Il serait sans utilité d’en conclure que : La compagnie
assure des véhicules.
VI.6 REPRESENTATION D’UNE PROPOSITION
Il faut rappeler que la plupart des propositions mettent en évidence des concepts et des liens entre ces concepts.
On cherchera donc à représenter chaque concept s’il n’est pas déjà exprimé dans le schéma courant, ainsi que
les liens qui l’unissent aux autres concepts. On doit admettre cependant que le processus ne peut être
entièrement formalisé, et que le bon sens est souvent le meilleur guide en cette matière.
Nous donnerons ci-dessous quelques règles simples et générales couvrant les situations les plus fréquentes.
VI.6.1 Nouveau type d’entités et son attribut
Un concept nouveau se présentera par un type d’entités s’il apparait comme important, ou par un attribut s’il
apparait comme une simple propriété du concept. Exemple : la proposition tout dossier possède un titre est
formalisé par :
DOSSIERS
Titre
Fig x : Traduction d’une proposition en type d’entités

VI.6.2 Type d’associations entre type d’entités existants
Une proposition qui établit un lien entre deux concepts déjà représentés par des types d’entités se traduira par
un type d’associations entre ces derniers. Ainsi la proposition les clients peuvent acheter des produits pourra
être intégrée au schéma courant par le formalisme suivant :
CLIENTS
Numcli CLIENTS PRODUIT
Numprod
Nom
+ Libelle Numcli Numprod
Adresse Quantité Nom Libelle
Adresse Quantité
Les clients peuvent acheter des
produits
Acheter
Fig x : Proposition traduisant un type d’associations
0,n 0,n
VI.6.3 Attribut d’un type d’entités existant
Une proposition qui établit un lien entre un concept déjà représenté par un type d’entité et une propriété
nouvelle de ce concept se traduira en un nouvel attribut attaché à ce type d’entités.
La proposition suivante : chaque voiture est d’un modèle déterminé, est illustré par le formalisme suivant :
VOITURES VOITURES
Numveh
marque Numveh Chaque voiture est d’un modèle déterminé
marque
modèle
VI.6.4 Nouveau type d’entité et ses deux attributs
Une proposition peut exprimer un lien entre deux concepts qui se traduisent naturellement par deux attributs.
Mais elle peut aussi représenter un nouveau type d’entités auquel on affecte des attributs. La proposition
suivante : Le montant est dépensé à une date déterminée, peut être élucidée via par le formalisme suivant :
DEPENSES
Date
Montant

VI.6.5 Restructuration pour intégration
L’intégration d’un nouveau type de faits peut poser des problèmes qui ne peuvent être résolus que par la
restructuration d’une partie de ce schéma. Par exemple certaines situations semblent réclamer des
modifications non licites du schéma courant, telles que :
1 - l’affectation d’un attribut AA à un attribut A (un attribut ne peut avoir d’attributs) ;
2- l’établissement d’un lien entre un type d’entité E1 existant et un attribut A existant qui appartient déjà à un
autre type d’entitéE2 (un attribut ne peut être associe qu’à un seul type d’entité) ;
3 l’affectation d’un attribut A à un type d’associations R existant (un type d’associations ne peut avoir
d’attributs) ;
4 Ajouter un troisième type d’associations existant (un type d’associations ne peut relier que deux types
d’entités).
Les problèmes 1 et 2 pourraient se résoudre Si l’attribut A était au préalable transformé en un type d’entités.
Les problèmes 3 et 4 pourraient se résoudre Si le type d’associations R était au préalable transforme en type
d’entités.
Nous suggérons donc deux transformations qui permettent de résoudre les problèmes évoqués précédemment :
 Transformation d’un type d’association en type d’entités (type d’associations n à n).
CLIENTS PRODUITS
Numcli Numprod
Nom libelle
Adresse Quantité
Acheter
0,n 0,n
 Transformation d’un attribut en type d’entités
Il est tout à fait possible d’extraire un attribut (ou même plusieurs) d’un même type d’entités pour former un
nouveau type d’entités. Ici Numfourn n’est pas une propriété de produits, il est extrait pour former un type
d’entités fournisseurs. FOURNISSEURS
PRODUITS PRODUITS
PRODUITS Numfourn Numprod
libelle
Numprod
libelle
Quantité
Numfourn
Id : Numprod
VI.6.6 Recommandations pratiques
• Si un concept n’est décrit que par une de ses caractéristiques, on envisagera de ne pas le
représenter par un type d’entités. Si la seule mention du concept de fournisseur est celle de son
nom attaché à la description des produits qu’il livre, il peut être suffisant de le représenter par le
simple attribut NomFournisseur de produit. En cas d’hésitation définir un type d’entités
fournisseur doté de l’attribut nom et en association avec produit.
• En revanche si on cite au moins deux caractéristiques d’un concept, il faut le représenter par un
type d’entités doté d’attributs correspondant à ces caractéristiques.
• Si une même caractéristique d’un concept est citée à plusieurs endroits, il est préférable de
représenter ce concept par un type d’entités doté de l’attribut correspondant à cette
caractéristique.
• Quand on hésite sur le type d’entité auquel il faut associer un attribut, on choisira une solution
qui n’entraine pas de redondance (présence de la même information plusieurs fois).
• Si parmi les attributs d’un type d’entité, on repère un groupe homogène en relation étroite, il
convient probablement de l’extraire pour en constituer un type d’entité.
VI.6.7 Non-redondance des propositions
Une proposition élémentaire exprime des types de faits sous la forme de l’existence de concepts parfois déjà
présents dans le schéma courant.
On appelle redondance structurelle le phénomène selon lequel une construction du schéma courant et une
proposition nouvelle expriment le même type de faits.
VI.6.7.1 Redondance explicite
Schéma courant et proposition expriment le même type de faits.
CLIENTS
Tout client possède un nom
Numcli
=
Nom
Adresse

VI.6.7.1.1 Variante d’expression
Une proposition peut exprimer un type de faits déjà représenté dans le schéma courant sous une forme
différente.
CLIENTS VEHICULES
Un véhicule appartient à un
client
=
posséder
VI.6.7.1.2 Redondance indirecte
Souvent difficile à détecter car elle exprime les types de faits qui ne sont pas explicitement exprimés dans le
schéma courant mais qui peuvent s’en déduire.
DEPARTEMENTS
Appartenir = Un département à des employés
SERVICES
EMPLOYES
Occuper
VI.7 CONTRAINTES D’INTEGRITES
Le plus souvent c’est l’énoncé lui-même qui spécifiera les contraintes de manière explicite. Il sera parfois
nécessaire de recourir à des sources d’informations complémentaires telles qu’une conversation avec des
utilisateurs, la connaissance que nous pourrons avoir du domaine d’activités ou encore le simple bon sens.
Pratiquement il faudra examiner avec soins chaque type d’entités, chaque type d’associations et chaque
attribut afin d’y relever les contraintes de base et additionnelles à retenir.

VI.8 NORMALISATION DU SCHEMA CONCEPTUEL
A ce stade le schéma obtenu est présumé correct. On peut souvent effectuer un nettoyage de celui-ci, soit dans
un but de simplification, soit pour éliminer certaines anomalies qui pourraient subsister.
VI.8.1 Simplification du schéma conceptuel
Il s’agit de s’assurer que l’information a été présentée de manière adéquate, conforme à la philosophie du
modèle entité-association. Soit le schéma suivant :
CLIENTS
LOCALITES
0,n 1,1 NumCli
Nomlocalite
Nom
Adresse
Id : Nomlocalite Id :Numcli
L’on constate que le type d’entités LOCALITES n’a d’autres intérêts que d’associer un nom de localité à
chaque entité client. On pourrait donc le remplacer par un simple attribut de client.
CLIENTS
NumCli
Nom
Adresse
Nomlocalite
Id :Numcli
VI.8.2 Autres règles de normalisation
Un bon schéma entité-association dispose de 9 règles de normalisation que le concepteur doit connaitre par
cœur.
VI.8.2.1 Les 6 bonnes manières dans un schéma entités-associations
1-Normalisation des types d’entités (importante): tout type d’entité remplaçable par une association
doit être remplacée. Exemple : le type d’entité projections dispose de cardinalité 1,1 de part et d’autres,
elle peut être remplacée par un type d’association projeter.
Crenaux
horaires
Créneaux
horaires Numcren
Date
Numcren Heuredebut
date
heuredebut
0,n
Avoir lieu pendant
0,n
0,n 0,n
Projections
Films
1,1 Projeter Films
Concerner
Numproj
Tarif
Numfilm soi Tarif
Numfilm
Titre
Durée Titre
1,1 Durée
0,n
Avoir lieu dans
Salles
0,n
+ unicité de la
Salles
projection de tel film, Numsalle
Capacité
Numsalle dans telle salle, à tel
Capacité créneau
Fig x : Entité remplaçable par une association ternaire
2-Normalisation des noms : le nom d’une entité, association ou d’un attribut doit être unique :
- pour les entités, utiliser un nom commun au pluriel en majuscule (par exemple : CLIENTS)
- pour les associations, utiliser un verbe à l’infinitif (effectuer, concerner) éventuellement à la forme
passive (être commandé) et accompagné d’un adverbe (avoir lieu dans, pendant ,à) ;
- pour les attributs, utiliser un nom commun singulier (par exemple : Nom, Prénom) éventuellement
accompagne du nom de l’entité ou de l’association auxquelles ils appartiennent (nometudiant).
Nb : Si les noms sont composés de plus d’un mot, séparer les mots par un tiret bas(nom_etudiant)..
Lorsqu’il existe le même nom plusieurs fois cela est sujet à une redondance. Exemple :
ETUDIANTS ENSEIGNANTS
PERSONNES
Numet Numens Numpers

Nom Nom Nom
Prénom Fusion
Prénom Prénom
Adresse Adresse Adresse
Figure x : Deux entités qui semblent homogènes peuvent être fusionnées

CLIENTS COMMANDES
1,n 1,1
Numcl passer Numcom
Nomcl Datecom
Adresselivr Adresselivr
Fig x : Contre exemple de la normalisation des noms
Si deux attributs contiennent les mêmes informations, alors la redondance induit non seulement un
gaspillage d’espace mais un grand risque d’incohérence (ici les Adresselivr ne sont pas les mêmes).
3-Normalisation des identifiants : Chaque entité doit posséder un identifiant :
- éviter les identifiants composés de plusieurs attributs (par exemple un identifiant formé par les attributs
nom, prénoms)
- préférer un identifiant court (minimal) pour rendre la recherche la plus rapide possible (éviter les
chaines de caractères comme numéro de plaque d’immatriculation, le numéro de sécurité sociale
ou code postal).
- éviter les identifiants susceptibles de changer dans le temps (comme la plaque d’immatriculation et
numéro sécu provisoire).
- L’identifiant sur un schéma entité association est souligné, c’est la future clé primaire dans le
schéma relationnel, il doit être un entier de préférence incrémenté automatiquement.
4 Normalisation des attributs (importante)
- Remplacer les attributs en plusieurs exemplaires qui posent des problèmes d’évolutivité du modèle, par
une association supplémentaire de cardinalités max n, et ne pas ajouter d’attributs calculables à partir
d’autres attributs. Voir figure courante
EMPLOYES
EMPLOYES
Numempl
Numempl Nom ADRESSES
Nom 1,n
Adresseprincipale Normalisation Numadresses
Adressesecondaire Adresseprincipale
occuper
Teldomicile Adressesecondair
Telportable e
1,n type
1,n
Posséder
TELEPHONES
Numtelephone
Teldomicile
1,n Telportable
Figure x : Attributs en plusieurs exemplaires remplacés par une association

COMMANDE ARTICLES
1,n Figurer
0,n
Numcom Numart
Datecom Quantité Désignation
Montant total Pu vente
Calculable à partir de
Fig x : attribut calculable qu’il faut retirer du schéma
- Les attributs d’une association de type plusieurs à plusieurs dépendent directement des identifiants des
entités en associations. Voir exemple Fig x : normalisation des attributs des associations
CLIENTS Concerner1 ARTICLES FOURNISSEURS

Concerner2
Numcli Quantitéco Numcom Numfourn
Nomcli Datecom Quantitélivree nomfourn
Adressecli Montant total telephonecontact
1,n
1,n 1,n 1,n 1,n

1,n
LIVRAISON LIVRER
COMMANDES
passer
Numlivr
Numcom
nomlivreur
Datecom
Datelivr 1,n
1,n
L’inconvénient de cette règle de normalisation est qu’elle est difficile à appliquer pour les associations qui ne
possèdent pas d’attributs. Pour vérifier cette règle aux associations sans attributs, on peut donner à l’association
un attribut imaginaire
5-Normalisation des associations (importante):il faut éliminer les associations fantômes, redondante
ou en plusieurs exemplaires voir figure ci-dessous :
FOURNISSEURS
1,1
Numfourn
Nomforn
Adressefourn FOURNISSEURS
Travailler chez
fusion Numfourn
CONTACTS nomfourn
adresse
Numcontact telcontact
nomcontact 1,1
telephonecontac

Fig x : toutes les cardinalités sont 1,1 c’est donc une association fantôme
6-Normalisation des cardinalités : une cardinalité mini vaut 0 ou 1 et une cardinalité max vaut 1 ou n
et non 2,3…Cela signifie que les que cardinalités max 2,3…pourraient évoluer vers n. par contre les
cardinalités, max valant 0 n’ont pas de sens.
XI.2 LES FORMES NORMALES

Aux règles précédentes il faut ajouter les 03 premières formes normales traditionnelles concernant les schémas
entités-associations :
- Première forme normale : à un instant donné dans un type d’entité, pour une entité donnée un attribut
ne peut prendre qu’une seule valeur et non un ensemble de valeurs. Si un attribut prend plusieurs valeurs
alors ces attributs feront l’objet d’une entité supplémentaire en association avec la première. voir
Figire ci-dessous : Application de la première forme normale il peut y avoir plusieurs auteurs pour un
livre donné.
LIVRES LIVRES AUTEURS

1,n 1,n
Numlivre Numlivre Numaut
Titre
Ecrire Nom
Auteur Titre
Editeur
Editeur
Nbre pages
Nbre pages
Année
Année
- Deuxième forme normale : l’identifiant peut être compose de plusieurs attributs, mais les autres
attributs de l’entité doivent dépendre de l’identifiant en entier et non pas une partie. Cette deuxième
forme normale peut être oubliée si on suit les conseils de n’utiliser que des identifiants non composes et
de type entier incrémenté.
Considérons le contre exemple suivant : dan une entité-type CLIENTS dont l’identifiant est composée
des attributs nom et prénom, la date de fête d’un client ne dépend pas de son identifiant en entier mais
d’une partie, le prénom. L’attribut date fête ne doit pas figurer dans l’entité clients elle doit appartenir à
une autre entité à part calendrier en association avec clients.
- Troisième forme normale ou Boyce-Codd (importante) : tous les attributs d’une entité doivent
dépendre directement de son identifiant et d’aucun autre attribut. Si ce n’est pas le cas, il faut placer
l’attribut pathologique dans une entité séparée, mais en association avec la première. Voir figure
suivante :
Numéro avion Constructeur Modèle Capacité Propriétaire

1 Airbus A380 180 Air France
2 Boeing B747 314 British Airways
3 Airbus A380 180 KLM

Fig x : il y a redondance dans les colonnes « constructeur et capacité ».
Par exemple l’entité avion à gauche n’est pas en forme normale de Boyce Cood, car la capacité et le
constructeur ne dépendent pas du numéro d’avion mais de son modèle. La solution normalisée est formalisée
sur la figure suivante :
AVIONS AVIONS
MODELES
Numavion Numavion 1,n 1,n
Nummodele
D’AVIONS
3eme forme
Modèle Propriétaire codemodele
normale Etre du
Constructeur
LibelleModèle
Capacité Constructeur
Propriétaire Capacité
Fig x : troisième forme normale de Boyce Codd
 QUE RETENIR ?
- Le modèle entités-associations permet de structurer les concepts d’un domaine d’application en type
d’entités, type d’associations et éventuellement leurs attributs;
- Un type d’entités contient une classe ou population d’objets (instances ou entités), remarquable du
domaine d’application, dont chaque attribut représente une propriété commune aux entités de ce
type.
- Les entités peuvent être mises en relation deux à deux par des associations binaires classées en type
d’associations ;
- Un attribut tire ses valeurs d’un type de valeurs de base (entier, caractère, booléen, etc.) ;
- Un attribut est obligatoire si chaque entité doit posséder une valeur pour cet attribut, sinon il est
déclaré facultatif ;
- Un type d’associations comprend deux rôles joués chacun par un type d’entités, si les rôles sont joués
par le même type d’entité, le type d’associations est dite cyclique ;
- Un rôle est caractérisé par une contrainte de cardinalités formée par un couple de valeurs indiquant
le minimum, et maximum de fois une entité participe à une association. Il existe trois classes
fonctionnelles principales ou type d’associations: un à un, un à plusieurs, plusieurs à plusieurs ;
- Un type d’entités peut posséder un ou plusieurs identifiants. Le plus important est le primaire, les
autres sont des secondaires. (voir page 308).

VI.9 COMPLETUDE DU SCHEMA CONCEPTUEL
Certaines parties du schéma ne sont peut être encore qu’a l’état d’ébauche. On les complétera par des
vérifications systématiques telles que les suivantes :
Types d’entités
• Son nom est il suffisamment significatif ?

• A-t-il des attributs ?si ce n’est le cas est ce normal ?
• A-t-il au moins un identifiant ? L’identifiant primaire est -il constitué de composants
obligatoires ?
• Ses identifiants sont ils minimaux ? Ne comportent-ils pas de rôles de cardinalités [0-1] ou
[1-1] ?
• Lui a-t-on affecté une description précise et complète ?
Attributs
• Son nom est –il significatif ?

• Son domaine de valeurs est -il précisé ?
• Est-il monovalué ?
• A-t-on précisé s’il est obligatoire ou facultatif ?
• Lui a-t-on affecté une description précise ?
Type d’associations
• Son nom est-il suffisamment significatif ?

• Pour chaque rôle :
- Son nom implicite ou explicite est-il unique ?
- Sa cardinalité mini 0 1 est elle correcte ?
- Sa cardinalité maxi 1 n est elle correcte ?
- La cardinalité est elle d’un des trois types admissibles, 0 1-11, 0 n-1 n?
- Lui a t-on affecté une description précise ?

VI.10 QUE RETENIR ?
 Une base de données est construite à partir du schéma conceptuel qui décrit les concepts du domaine
d’application. Il est important que ce schéma représente naturellement, complètement et sans
redondance ce domaine d’application ;
 La connaissance du domaine d’application s’appuie généralement sur un ensemble de textes décrivant
les concepts du domaine, et décomposés en propositions élémentaires, obéissant à la forme binaire sujet
verbe objet ou concept lien concept ;
 Les propositions non binaires sont décomposées en propositions binaires ;
 Les types d’entités siège de redondance seront également décomposés ;
 La normalisation du schéma consiste à simplifier certaines structures (types d’entités, attributs et types
d’associations.
VII METHODOLOGIE DE BASE
Face à une situation bien définie (soit à travers un énoncé précis ou une collection de formulaires ou d’états )
que le système d’information est censé remplacer, l’on pourra procéder ainsi :
1- identifier les entités en présence ;

2- lister leurs attributs ;
3- Ajouter les identifiants (arbitraires ou incrémentés) ;
4- Etablir les associations binaires entre les entités ;
5- Lister leurs attributs ;
6- Calculer les cardinalités ;
7- Vérifier les règles de normalisation et en particulier, la normalisation des entités (c’est à ce stade
qu’apparaissent les associations binaires), des associations et de leurs attributs ainsi la troisième forme
normale de Boyce Codd ;
8- Effectuer les corrections nécessaires ;
9- Attribuer un identifiant à chaque entité ;
10- Ajouter l’ensemble des attributs avec leurs dépendance fonctionnelles ;
11- Ajuster les cardinalités ;
12- En somme vérifier toutes les règles de normalisation (pas de redondance, pas de synonymes…).

VII.1 REGLES DE PASSAGE DU MCD AU MLD
La phase finale de production d’une base de données consiste à traduire le schéma conceptuel dans le langage
de définition de données d’un SGBD. Pratiquement, on traduira chaque composant du schéma entité-
association en structures de tables, colonnes, identifiants, clés primaires et clés étrangères. Ces structures sont
généralement exprimées dans le langage SQL.
Le schéma conceptuel exprime clairement les structures d’information à représenter, mais il n’est pas accepté
tel que par l’ordinateur. Il est donc nécessaire de traduire ce schéma en structures techniques de tables et de
colonnes, c'est-à-dire en concepts compréhensibles et gérables par des outils disponibles : les SGBD
relationnels.
Des règles de traduction de chaque type de composants entités-associations sont proposées :
- Regle1 : Représentation des types d’entités
a) Un type d’entités non influencé du MCD, devient une relation, c’est à dire une table dans le schéma de la
base. La table garde les mêmes attributs que dans le MCD.
Dans un SGBD de type relationnel, une table est une structure tabulaire dont chaque ligne correspond aux
données d'un objet enregistré (d'où le terme enregistrement ) et où chaque colonne correspond à une propriété
de cet objet. Une table contiendra donc un ensemble d’enregistrements. Une ligne correspond à un
enregistrement. Une colonne correspond à un champ. La valeur prise par un champ pour un enregistrement
donné est située à l’intersection ligne-colonne correspondant à enregistrement-champ.
Il n’y a pas de limite théorique au nombre d’enregistrements que peut contenir une table. Par contre, la limite
est lié à l’espace de stockage.
b) l’identifiant du type d’entités devient la clé primaire de la table.
La clé primaire permet d’identifier de façon unique un enregistrement dans la table. Les valeurs de la clé
primaire sont donc uniques. Les valeurs de la clé primaire sont obligatoirement non nulles.
Dans la plupart des SGBDR, le fait de définir une clé primaire donne lieu automatiquement à la création d’un
index.
- c) Les autres propriétés deviennent les attributs de la relation.
Exemple le type d’entités CLIENTS du MCD

CLIENTS
Numcli
Nom
Adresse
Devient dans le MLD la table CLIENTS (Numcli, Nom, Adresse)

Règle 2 : Types d’associations un à plusieurs (1 :N)
Dans un type d’association binaire un à plusieurs entre deux types d’entités A et B (plusieurs entités B pour
chaque entité B, une seule entité A pour chaque entité B)

0 ,1 0, n
1,1 1,n
A R B
L’entité A est appelé fils (carda max 1 : un fils n’a qu’un seul père)
L’entité B est appelé père (carda max n : un père peut avoir plusieurs fils)
Le type d’association ne devient pas une table, La table fils A retient ses propriétés, la table père B reçoit une
copie de l’identifiant de la table fils ainsi que les attributs du type d’associations. Ainsi le schéma conceptuel
suivant :
CLIENTS 1,1 COMMANDES
Numcli 0,n Numcom

Nom Passer Qtecom
Adresse
Id : Numcli
Id : Numcom
Devient les tables suivantes dans la base de données :
CLIENTS (Numcli, Nom, Adresse)
COMMANDES (Numcom, Qtecom, #Numcli)
L’identifiant migrant est une clé étrangère (Numcli) dans la table COMMANDES. Cette clé ne peut pas avoir
la valeur nulle si la cardinalité est 1,1. Obtenant ainsi le schéma relationnel de la base de données comme
suivant :
CLIENTS COMMANDES
Numcli Id : Numcom
Nom
Adresse ref : Numcli
Numcom
Id : Numcli Qtecom
Numcli

Règle 3 : Types d’associations un à un (N:M)
Une association de type N :N (c’est à dire qui a les cardinalités maximales positionnées à « N » des 2 côtés de
l’association) se traduit par une table dont la clé primaire est composée des clés étrangères référençant les
relations correspondant aux entités liées par l’association.
Les éventuelles propriétés de l’association deviennent des attributs de la relation.
Exemple, Du MCD suivant :
COMMANDES Ref
PRODUITS
1,n 1,n
Concerner
Numcom Refprod
Datecom Quantite Libelleprod
Id :Numcom Id : Refprod
L’on tire les tables suivantes :

COMMANDES (numCom ,dateCom)
PRODUITS (refProduit, libelleProduit)
CONCERNER (#numCom , #refProd , quantité)
Si le nom dans le MCD n’est pas significatif, on peut renommer le nom de la table. Dans notre exemple, plutôt
que la table « CONCERNER », on la nommera « LIGNE_DE_COMMANDE ».
LIGNE_DE_COMMANDE (#numCom , #refProd , quantité)
 Associations ternaires : Les règles définies ci-dessus s’appliquent aux associations ternaires.
 Associations réflexives : Les règles définies ci-dessus s’appliquent aux associations réflexives.
Règle 4 : Cas particuliers : type d’association 1,1
On entend par type d’ association 1,1 une association dont les cardinalités maximales sont à 1 de chaque côté.
- Type d’association de cardinalité 1,1 de part et d’autre : Le type d’association ne devient pas une
table dans la base.
Exemple 1 : Dans le cadre d’une course à la voile en solitaire, l’on peut représenter le schéma relationnel après
avoir fait le schéma Entités-Relations pour les informations suivantes : numéro du marin, nom du marin,
numéro du voilier, nom du voilier.
MARINS 1,1 1,1 VOILIERS

Piloter
Nummarin Numvoilier
Nommarin Nomvoilier
Id : Nummarin Id : Numvoilier

Dans ce type d’associations, le type d’entités fonctionnement important reçoit une copie des propriétés de
l’autre. Ici
Si fonctionnellement, le marin est le plus important…
MARIN (numMarin , nomMarin , #numVoilier , nomVoilier)
Clé primaire : numMarin
OU
Si fonctionnellement, le voilier est le plus important…
VOILIER(numVoilier , nomVoilier , #numMarin , nomMarin)
Clé primaire : numVoilier
OU
Si le modèle peut évoluer ou si on a une distinction fonctionnelle forte entre marin et voilier…
VOILIER(numVoilier , nomVoilier , #numMarin)
Clé primaire : numVoilier
Clé étrangère : numMarin qui référence numMarin de la table MARIN
MARIN(numMarin , nomMarin , numVoilier)
Clé primaire : numMarin
Clé étrangère : numVoilier qui référence numVoilier de la table VOILIER
- Type d’associations de cardinalités 0,1 et 1,1 de part et d’autre

Le type d’association ne devient pas une table dans la base. Le type d’entités de cardinalités 11, reçoit une
copie de l’identifiant du type d’entites de cardinalites 01. Soit dans un immeuble, un appartement peut
bénéficier d’une place de parking ou pas mais jamais de plusieurs. Travail à faire : Représenter le schéma
relationnel après avoir fait le schéma Entités-Relations.
APPARTEMENT 0,1 1,1 PLACE-PARKING

beneficier
Numappart Numplace
superficie etage
Id : Numappart Id : Numplace
APPARTEMENT (numAppartement, superficie)

Clé primaire : numAppartement
PLACE_PARKING (numPlace , Etage , #numAppartement)
Clé primaire : numPlace
Clé étrangère : numAppartement qui référence numAppartement de la table APPARTEMENT

- Type d’associations de cardinalités 0,1 de part et d’autre.
Le type d’association devient une table dans la base Ses propriétés sont la concaténation des identifiants des
types d’entités qu’ils lient.
Soit Une activité culturelle, elle peut disposer d’un animateur ou pas mais jamais de plusieurs. Un animateur
peut s’occuper au maximum d’une activité culturelle.
Travail à faire : Représenter le schéma relationnel après avoir fait le schéma Entité-Relations
ANIMATEURS
ACTIVITES-CULTURELES
Numanim 0,1 0,1
Animer Idactivités
Nom
Nomactivites
Id : Numanim
Id : Idactivités
ANIMATEUR (numAnimateur , nom)
Clé primaire : numAnimateur
ACTIVITE_CULTURELLE (idActivite, nomActivite)
Clé primaire : idActivite
ANIMER (, #numAnimateur , , # idActivite)
Clé primaire : numAnimateur + idActivite
Clé étrangère : numAnimateur qui référence numAnimateur de la table ANIMATEUR
Clé étrangère : id Activité qui référence id Activité de la table ACTIVITE_CULTURELLE
VIII REGLES POUR LE SYSTEME RELATIONNEL DE BASE DES DONNEES
1. La règle informationnelle : Toutes les informations dans la base des données sont explicites et portent
la même structure logique et sont représentées par valeurs dans les tableaux.
2. La règle de certitude : Toutes les données dans le modèle relationnel sont accessibles par la
combinaison de nom de tableau, la valeur de clé principale et le nom de la colonne.
3. Le traitement des valeurs nulles systématique : Les valeurs nulles sont bien adoptées par le modèle
relationnel et pour représentation de l’information qui n’est pas définie et ne sont pas dépendantes du
type de données.
4. Le catalogue en ligne basé sur le modèle relationnel : La description de la base des données est
exprimée sur le même niveau logique et de même manière que les dates de client. Alors un utilisateur
autorisé peut appliquer la même langue relationnelle pour appliquer sa demande comme utilisateur qui
travaille avec les données.
5. La langue de définition des données : Le système relationnel peut soutenir plusieurs langues et modes
pendant l’utilisation de terminal. Mais il faut qu’il y ait au moins une langue vaste qui puisse définir la

structure des données, la manipulation interactive, restrictions intégrales, autorisation pour accéder à la
base des données, les commandes transactionnelles etc. (SQL).
6. La règle de création de vue : Toutes les vues sont théoriquement possibles et sont aussi créées par
système.
7. Le pouvoir de créer, insérer et effacer : Il est possible de préserver les règles relationnelles sur les
relations de base et aussi relations dérivées non seulement en regardant les données, mais aussi pendant
les opérations d’intersection, l’union et effacement des données.
8. L’indépendance physique des données : Les programmes d’application sont indépendants de la
structure physique des données.
9. L’indépendance de la logique des données : Les programmes d’application sont indépendants de la
structure logique de base des données.
10. L’indépendance intégrale : Les restrictions intégrales doivent être définies par les moyens de la base
des données relationnelle ou son langage et doivent être situées dans le catalogue et non dans le
programme d’application.
11. L’indépendance de la distribution : Il est nécessaire que le système de gestion de base des données
relationnel soit capable d’être implémenté sur les autres architectures informatiques.
12. La règle d'accès sur la base des données : Si le système relationnel a la langue de niveau bas, on ne
peut pas utiliser ce niveau pour exprimer les restrictions intégrales et il est nécessaire de les exprimer en
langue relationnelle de niveau supérieur.
Le modèle relationnel est basé sur la notion d’ensemble. Chaque ensemble possède un nom et aussi des attributs
nommés qui appartiennent dans cet ensemble et il existe des restrictions intégrales qui limitent cet ensemble.
On peut présenter cet ensemble sous forme d’une table relationnelle qui porte son nom et les attributs sont
représentés par les colonnes. Dans les cellules de la table peuvent être seulement inscrits les éléments
atomiques. L’aménagement des dates dans la base des données est pour un utilisateur non essentiel et les dates
peuvent exister indépendamment sur le dépôt physique. Un grand avantage de ce modèle est que l’utilisateur
n’a pas à savoir où sont déposées physiquement les données et il peut les utiliser sans problème. C’est un grand
avantage par rapport au modèle hiérarchique ou au modèle réseau.
La modélisation relationnelle permet de présenter les relations sous forme des tables de deux dimensions.
Chaque colonne possède un identificateur qui représente un domaine. On appelle tuple ou n-uplet un set des
valeurs des attributs incoordonnés, c'est-à-dire la ligne de table. La relation peut donc être définie par le set de
n-tuples. « Chaque opération relationnelle sur une table génère une nouvelle relation et les opérateurs
relationnels – ceux de la langue SQL, permettent de décrire le résultat que l’on veut obtenir sans avoir à décrire
la procédure nécessaire pour arriver au résultat : on dit que la langue relationnel est « non procédural » »
Pour lier les relations ensemble il existe la clé primaire et la clé étrangère. La clé principale d’une relation est
un attribut ou un ensemble des attributs qui permet de désigner d’une façon unique un tuple. La seule

connaissance de la clé principale peut identifier toute ligne dans une table. De l’autre côté, la clé étrangère est
un identificateur qui fait référence à une clé unique dans une autre table.
Dans le sens mathématique est la relation un sous-ensemble du produit cartésien des certaines domaines. Un
domaine est représenté comme un ensemble des valeurs : R = (A1 X A2 X A3).
Cette relation R est représentée par une table de 3 colonnes (trois attributs) A1, A2, A3 dont chaque ligne est
caractérisée par différente valeurs dans les domaines A1, A2, A3.Pour modéliser l’entité du monde réel
« voiture » on prendra comme constituants la marque, la couleur, la plaque d’immatriculation et la date de
création : voiture (marque, couleur, plaque-immatriculation, date-création). Les domaines correspondant aux
identificateurs de colonnes peuvent être déterminés par les ensembles de valeurs suivants :
marque : chaine de 1 à 50 caractères alphabétiques.
couleur : chaine de 1 à 30 caractères alphabétiques.
plaque-immatriculation : chaine de 1 à 10 caractères alphabétiques.
date-création : dates depuis le 1er janvier 1800 jusqu’au présent.
Dans le modèle relationnel, les entités du schéma conceptuel sont transformées en tableaux à deux dimensions.
Le modèle relationnel s’appui sur trois concepts fondamentaux : le domaine, l’attribut et la relation ou table.
1. Domaine : ensemble de valeurs défini en extension ou en intension. Un domaine peut être simple ou
composé.
Domaine simple : si tous les éléments sont atomiques ou décomposables.
Ex : l’ensemble des grades du salarié peut être définit en extension par employé, agent de maîtrise, ou cadre.
Domaine composé : si les éléments peuvent être décomposés.
Ex : les dates sont décomposées d’un jour, un mois et une année.
2. Attribut : chaque colonne est appelée attribut et contient un ensemble des valeurs d’un domaine.
Chaque ligne représente un tuple.
3. Relation ou table : une relation est un tableau à deux dimensions. Le degré de la relation est le nombre
de colonnes ou des domaines considérés.
IX BIEN CONCEVOIR UNE BASE DE DONNEES (SCHEMA DE LA BD)

IX.1 INTRODUCTION
Nous étudions dans ce chapitre comment bien concevoir une BD. Pour ce faire, à partir d'un même ensemble de
connaissances ayant trait aux plages, nous proposons deux choix d'organisation des informations sous forme
relationnelle. Nous étudions les qualités et les défauts de ces différents choix avant de présenter les règles de
"bonne" conception d'une BD relationnelle.
- Premier choix :
BAINS (NN, NOM, PRENOM, QUALITE, DATE, DUREE, NP, NOMP, TYPE, REGION, POLLUTION)
- Deuxième choix :
NAGEUR (NN, NOM, PRENOM, QUALITE)
PLAGE (NP, NOMP, TYPE, REGION, POLLUTION)
BAIGNADE (NN, NP, DATE, DUREE)
NN et NP sont des numéros permettant de distinguer respectivement les nageurs et les plages. NN est
l'équivalent du numéro de sécurité sociale.
Nous constatons sur cet exemple l'existence de plusieurs façons de structurer un même ensemble
d'informations. Si nous privilégions instinctivement l'une des deux solutions proposées, c'est qu'elle correspond
davantage à notre perception du monde réel, dans laquelle nous distinguons naturellement certaines entités : les
personnes, les plages, etc.
L'étape de conception est primordiale pour le bon fonctionnement d'un SGBD. Elle fait partie des
quelques facteurs qui peuvent entraîner des incohérences dans les réponses et une diminution
inacceptable des performances du système ; c'est pourquoi il est indispensable d'y attacher une attention
toute particulière.
Une solution "instinctive" n'est pas suffisante pour concevoir le schéma d'une base importante.
Il est donc nécessaire d'isoler les critères de décision et de formaliser des méthodes de conception des bases de
données. Tel est l'objet de ce chapitre Les problèmes les plus courants rencontrés dans des bases de données
mal conçues peuvent être regroupés selon les critères suivants :
- Redondance des données
Certains choix de conception entraînent une répétition des données lors de leur insertion dans la base. Cette
redondance est souvent la cause d'anomalies provenant de la complexité des insertions.
C'est, par exemple, le cas de la première organisation proposée : dès qu'une personne prend un nouveau bain, on
doit non seulement répéter son numéro qui, par hypothèse, suffit à le déterminer, mais aussi toutes les
informations liées à ce numéro (son nom, son prénom, sa qualité). Au contraire, dans le deuxième choix, seul le
numéro indispensable à la distinction d'un nageur est répété. La situation est identique pour les plages.
- Incohérence en modification

La redondance de l'information entraîne également des risques en cas de modification d'une donnée répétée en
différents endroits : on oublie fréquemment de modifier toutes ses occurrences (en général par simple ignorance
des différentes places où figure l'information).
Par exemple, dans la première organisation proposée, si une personne change de nom (cas fréquent lors de
mariages), il faut changer ce nom dans tous les tuples où apparaissent ses coordonnées. Dans la deuxième
organisation, un seul tuple est modifié.
- Anomalie d'insertion
Une mauvaise conception peut parfois empêcher l'insertion d'un tuple, faute de connaître la valeur de tous les
attributs de la relation. Pour remédier à ce problème, certains SGBD implantent une valeur non typée qui
signifie que la valeur d'un attribut d'un tuple est inconnue ou indéterminée. Cette valeur (appelée usuellement
NULL) indique réellement une valeur inconnue et non une chaîne de caractères vide ou un entier égal à zéro
(analogie avec un pointeur égal à NIL en Pascal).
Dans le premier schéma proposé, insérer une nouvelle plage où personne ne s'est jamais baigné est aussi
impossible.
- Anomalie de suppression
Enfin, une mauvaise conception peut entraîner, lors de la suppression d'une information, la suppression d'autres
informations, sémantiquement distinctes, mais regroupées au sein d'un même schéma.
C'est ce qui se produit dans notre premier exemple, la suppression d'une plage entraîne automatiquement la
suppression de tous les nageurs ne s'étant baignés que sur cette plage.
De nombreux travaux ont permis de mettre au point une théorie de conception d'une base de données
relationnelle : la théorie de la normalisation, que nous allons développer dans les prochains paragraphes.
IX.2 EXEMPLES DE REDONDANCES INTERNES
Table répertoriant les livres d'une bibliothèque :
Observation
Les données TITRE et AUTEUR sont répétées autant de fois
qu'il existe de livres identiques.

Cette table viole le principe premier des bases de données :
tout fait du domaine d'application est enregistré une et
une seule fois.
Problèmes
• gaspillage d'espace
• si on modifie la valeur d'un titre, il faut répercuter cette
modification dans toutes les lignes similaires
• si on supprime l'unique exemplaire d'un livre, on perd les
informations sur son auteur et son titre
• est-on certain que le titre et l'auteur ont été orthographiés
exactement de la même manière pour tous les exemplaires
d'un livre ?
Suggestion
Rassembler les données communes (ISBN, TITRE, AUTEUR)
dans une table spécifique

Deux questions
1. Comment détecter les situations de redondance ?
2. Comment les corriger ?
La réponse à ces questions repose sur une nouvelle forme
de contrainte d'intégrité : la dépendance fonctionnelle.
ISBN → TITRE, AUTEUR

si deux lignes ont la même valeur de ISBN,
alors elles ont aussi les mêmes valeurs de TITRE et d’AUTEUR
On dit que :
• il existe une dépendance fonctionnelle de ISBN vers TITRE et
AUTEUR
• ISBN détermine ou est un déterminant de TITRE et AUTEUR
• TITRE et AUTEUR dépendent de ou sont déterminés par ISBN
Deux observations
1. par définition, un identifiant détermine toutes les colonnes de
la table
2. si un groupe de colonnes détermine chaque colonne de la
table, il constitue par définition un identifiant de la table
NUMERO → TITRE, AUTEUR, ISBN, DATE_ACHAT, EMPL

Comment détecter les situations de redondance ?
Réponse
Il y a redondance interne dès qu'il existe un
déterminant qui n'est pas un identifiant de la table
Une dépendance fonctionnelle dont le déterminant n'est
pas un identifiant est dite anormale
ISBN est un déterminant dans LIVRE mais il n'en est pas
un identifiant. Il entraîne donc des redondances internes.
Comment corriger les situations de redondance ?
Réponse
En décomposant la table T en deux fragments T1 et T2 :
T1(déterminant, déterminé)
T2(déterminant, résidu)
T2.déterminant est une clé étrangère vers T1
Dernières remarques
1. Une table qui est le siège d'une dépendance fonctionnelle anormale est dite non normalisée
2. Une table sans dépendance fonctionnelle anormale est dite normalisée

3. Décomposer une table de manière à éliminer ses dépendances anormales consiste à normaliser
cette table
4. Il est essentiel que toutes les tables d'une base de données soient normalisées
5. Il est possible qu'une table qui est le siège de dépendances fonctionnelles anormales ne comporte
pas de redondance à certains moments. Il ne s'agirait que d'un accident statistique ! Inutile de
tenter le diable !
6. La question de la normalisation d'une table sera étudiée de manière plus détaillée dans le chapitre
3 de cette série de leçons.

IX.2 THEORIE DE LA NORMALISATION DES RELATIONS
Cette théorie est basée sur les "dépendances fonctionnelles" (DF). Les dépendances fonctionnelles traduisent
des contraintes sur les données (par exemple, on décide que deux individus différents peuvent avoir même nom
et prénom mais jamais le même numéro NN).
Ces contraintes sont représentatives d'une perception de la réalité et imposent des limites à la base.
Les dépendances fonctionnelles sont des propriétés particulières qui définissent une suite de formes normales
(FN). Elles permettent de décomposer l'ensemble des informations en diverses relations.
Chaque nouvelle forme normale marque une étape supplémentaire de progression vers des relations présentant
de moins en moins de redondance. Ces étapes traduisent une compréhension de plus en plus fine de la réalité.
Chacune de ces formes normales peut être obtenue au moyen d'algorithmes de décomposition. Le point de
départ de ces algorithmes est la relation universelle, c'est-à-dire la relation qui regroupe toutes les
informations à stocker (dans notre exemple, le premier schéma représente cette relation universelle) ; le but
est d'obtenir, en sortie, une représentation canonique des données présentant un minimum de redondance à
l'intérieur de chaque relation et un maximum d'indépendance entre les différentes relations .
nom Dependances
fonctionnelles
Region type
NN NOMP
Normalisation
Relation universelle
IX 2.1 Les dépendances fonctionnelles

Définition : dépendance fonctionnelle
On dit qu'un attribut B dépend fonctionnellement d'un attribut A si, étant donné une valeur de A, il lui
correspond une unique valeur de B (quel que soit l'instant t considéré).
Notation : A → B
Exemple :
La dépendance fonctionnelle NN → NOM signifie qu'à un numéro est associé un nom unique (c'est, par
exemple, le cas du numéro de sécurité sociale). Remarquons qu'une dépendance fonctionnelle n'est
généralement pas symétrique, c'est-à-dire que NN → NOM n'interdit pas que deux personnes distinctes
(correspondant à deux NN différents) portent le même nom.
Une dépendance fonctionnelle est une propriété définie sur tous les tuples d'une relation et pas seulement sur un
tuple particulier. Elle traduit une certaine perception de la réalité (par exemple, deux personnes distinctes
peuvent porter le même nom). Elle correspond à une contrainte qui doit être vérifiée en permanence.

Les dépendances fonctionnelles sont parties intégrantes du schéma d'une BD. Elles doivent donc théoriquement
être déclarées par l'administrateur et contrôlées par le SGBD.
Exemple :
Nous définissons les propriétés vérifiées par notre base de baignades. Deux personnes distinctes peuvent, par
exemple, porter le même nom, le même prénom, et avoir la même qualité de nage. Deux numéros de nageur
différent les distinguent l'une de l'autre. Les dépendances fonctionnelles que nous venons de décrire sont donc
NN → NOM, NN → PRENOM, NN → QUALITE
Nous pouvons supposer également que deux plages distinctes ont toujours deux numéros différent ; ce qui
implique :
NP → NOMP
NP → REGION
que la pollution et le type sont propres à une plage :
NP → POLLUTION
NP → TYPE
et que deux plages d'une même région ne peuvent porter le même nom :
(NOMP, REGION) → NP
Propriétés des dépendances fonctionnelles
Les dépendances fonctionnelles obéissent à certaines propriétés connues sous le nom d'axiomes d'Armstrong.
Réflexivité :
Y ⊂ X ⇒X → Y
Augmentation :
X → Y ⇒X Z → Y Z
Transitivité :
X → Y et Y → Z ⇒ X → Z
D'autres propriétés se déduisent de ces axiomes :
Union :
X → Y et X → Z ⇒X → Y Z
Pseudo-transitivité :
X → Y et Y W → Z ⇒X W → Z
Décomposition :
X → Y et Z ⊂ Y ⇒ X → Z
L'intérêt de ces axiomes et des propriétés déduites est de pouvoir construire, à partir d'un premier ensemble de
dépendances fonctionnelles, l'ensemble de toutes les dépendances fonctionnelles qu'elles génèrent. On parle
alors de dépendances fonctionnelles élémentaires.

IX.2.1.1 Dépendance fonctionnelle élémentaire
Définition : dépendance fonctionnelle élémentaire
Une dépendance fonctionnelle X → A est élémentaire si - A n'est pas inclus dans X ;
- il n'existe pas X' inclus dans X tel que X’ → A.
Cette notion de dépendance fonctionnelle élémentaire est primordiale car elle permet de construire une sorte de
famille génératrice minimale (appelée couverture minimale) des dépendances fonctionnelles utiles pour
structurer la base.
Exemple :
Deux plages d'une même région ne peuvent pas porter le même nom (contrairement à deux plages de régions
différentes) ; le degré de pollution d'une plage dépend exclusivement de la plage et non de la région. On a alors
(NOMP, REGION) → POLLUTION
mais on n'a aucunement
NOMP → POLLUTION
ni
REGION → POLLUTION
donc (NOMP, REGION) → POLLUTION est une dépendance fonctionnelle élémentaire.
IX.2.1.2. Graphe des dépendances fonctionnelles
C'est une représentation graphique permettant de visualiser aisément toutes les dépendances fonctionnelles et
d'isoler les principales (i.e. les DF élémentaires).
Exemple :
Toutes les dépendances fonctionnelles citées précédemment peuvent être représentées de la façon suivante.
Voir document BON BON PDF
IX.2.1.3. Fermeture transitive

Définition : fermeture transitive
La fermeture transitive d'un ensemble de dépendances fonctionnelles est ce même ensemble enrichi de toutes
les dépendances fonctionnelles déduites par transitivité.
Exemple :
De l'exemple précédent , on déduit par transitivité deux nouvelles dépendances fonctionnelles :
(NOMP, REGION) → TYPE
(NOMP, REGION) → POLLUTION
qui enrichit le graphe de la façon suivante : voir document

IX.2.1.4 Couverture minimale
Définition : couverture minimale
La couverture minimale d'un ensemble de dépendances fonctionnelles est un sous ensemble minimum de
dépendances fonctionnelles élémentaires permettant de générer toutes les autres.
Exemple :
L'ensemble des dépendances fonctionnelles suivant :
(NN → NOM, NN → PRENOM, NN → QUALITE, NP → NOMP, NP → REGION, (NOMP, REGION) →
POLLUTION, (NOMP, REGION) → NP)
est une couverture minimale de l'ensemble des dépendances fonctionnelles.
Théorème :
Tout ensemble de dépendances fonctionnelles admet une couverture minimale, en général non unique.
Exemple :
L'ensemble des dépendances fonctionnelles suivant :
(NN → NOM, NN → PRENOM, NN → QUALITE, NP → NOMP, NP → REGION, NP → POLLUTION,
(NOMP, REGION) → NP)
est une autre couverture minimale de l'ensemble des dépendances fonctionnelles.
La recherche de la couverture minimale d'un ensemble de dépendances fonctionnelles est un élément essentiel
du processus de normalisation, dont le but est de décomposer une relation en plusieurs relations plus petites.
IX.2.1.5 Clé d'une relation

Définition : clé d'une relation
Soit R(A1, A2, ..., AN) un schéma de relation, soit F+ l'ensemble des dépendances fonctionnelles associées à R,
soit X un sous-ensemble de A1, A2, ..., AN, on dit que X est une clé de R si et seulement si - X →A1, A2, ...,
AN ;
- il n'existe pas de sous ensemble Y inclus dans X tel que Y → A1, A2, ..., AN.
Une clé d'une relation est un ensemble minimum d'attributs qui détermine tous les autres.
Exemple :
NN est clé de la relation PERSONNE (NN, NOM, PRENOM, QUALITE) ;
(NOMP, REGION) est clé de la relation (NP, NOMP, REGION, POLLUTION, TYPE).
Plusieurs clés peuvent être candidates pour une même relation.
Exemple :
NP et (NOMP, REGION) sont deux clés candidates à la relation (NP, NOMP, REGION, POLLUTION,
TYPE).
Dans l'écriture des schémas de relations, on indique les clés en soulignant les attributs constitutifs.

Exemple :
PLAGE (NP, NOMP, REGION, POLLUTION, TYPE)
IX.2.1.6 Décomposition des relations

La théorie de la normalisation repose sur un principe de décomposition des relations.
Définition : décomposition d'une relation
La décomposition d'un schéma de relation R(A1, A2, ..., AN) est son remplacement par une collection de
schémas de relations (R1, R2, ..., Ri) telle que :
SCHEMA(R) = SCHEMA(R1) ∪ SCHEM A(R2)
A (Ri).∪ ...
Définition : décomposition sans perte
Une décomposition d'une relation R en N relations R1, R2, ..., RN est sans perte si et seulement si, pour toute
extension de R, on a :
R = R1 |x| R2 |x| ... |x| RN
Théorème : décomposition sans perte
Une décomposition en deux relations est sans perte si l'attribut de jointure de la recomposition est clé d'une au
moins des deux relations.
Définition : décomposition préservant les dépendances fonctionnelles

Une décomposition (R1, R2, ..., RN) de R préserve les dépendances fonctionnelles si la fermeture des
dépendances fonctionnelles de R est la même que celle de l'union des dépendances fonctionnelles des relations
R1, R2, ..., RN.
IX.3. LES TROIS PREMIERES FORMES NORMALES

Nous définissons ici des règles de décomposition la relation universelle sans perdre d'information en utilisant
les dépendances fonctionnelles. Le but est d'obtenir une représentation du monde réel qui minimise la
redondance et les risques d'anomalies lors des mises à jour.
IX.3.1 La première forme normale 1FN

Définition : première forme normale
Une relation est en première forme normale si tout attribut est atomique.
Conséquences :
- un attribut représente une donnée élémentaire du monde réel ;
- un attribut ne peut désigner, ni une donnée composée d'entités de nature quelconque, ni une liste de données
de même nature.

La première forme normale correspond à un souci de simplicité au niveau du langage de manipulation. Elle a
pour particularité d'éviter toute hiérarchie dans une relation en interdisant les domaines composés de plusieurs
valeurs.
Exemple :
Nous pourrions imaginer une relation BAINS de schéma BAINS (NN, NP, DATE, DUREES) où DUREES
serait la liste des durées des bains pris par le nageur NN sur la plage NP à la date DATE. A lieu de cela, la
première forme normale nous oblige à décomposer cette relation en BAINS (NN, NP, DATE, DUREE) ce qui
induira autant de tuples qu'il y a de baignade d'un même baigneur, sur la même plage, le même jour ; avec (nn,
np, date, duréei) pour le ième bain de la journée.
IX.3.2 La deuxième forme normale 2FN

Définition : deuxième forme normale
Une relation est en deuxième forme normale si et seulement si :
- elle est en première forme normale ;
- tout attribut n'appartenant pas à une clé ne dépend pas que d'une partie de cette clé.
Exemple :
Considérons la relation PLAGE de schéma suivant :
PLAGE (NOMP, REGION, TYPE, POLLUTION)
où la clé est (NOMP, REGION). Supposons que la pollution est bien dépendante de la plage mais que le type
est, quant à lui, dépendant de la région. La deuxième forme normale nous impose de distinguer deux relations
R1 et R2 de schémas respectifs : R1 (NOMP, REGION, POLLUTION) ; R2 (REGION, TYPE).
IX.3.3. La troisième forme normale 3FN

L'objectif de cette troisième forme normale est l'élimination des redondances dues aux dépendances
fonctionnelles déduites par transitivité.
Définition : troisième forme normale
Une relation est en troisième forme normale si :
- elle est en deuxième forme normale ;
- tout attribut n'appartenant pas à une clé ne dépend pas d'un attribut non clé.
Théorème :
Toute relation R admet au moins une décomposition (R1, R2, ..., RN) en troisième forme normale telle que :
- la décomposition conserve les dépendances fonctionnelles ;
- la décomposition est sans perte.

Exemple :
Considérons maintenant la relation PLAGE de schéma PLAGE (NP, REGION, TYPE, POLLUTION) où la clé
est NP. Supposons maintenant comme dans l'exemple précédent que le type est dépendant de la région. La
troisième forme normale nous impose de distinguer deux relations R1 et R2 de schémas respectifs :
- R1 (NP, REGION, POLLUTION) ;
- R2 (REGION, TYPE).
IX.3.4 Algorithme de décomposition en troisième forme normale

Cet algorithme accepte en entrée la relation universelle à décomposer et les dépendances fonctionnelles de la
relation.
Principe de l'algorithme :
1- à partir du graphe G des dépendances fonctionnelles, CALCULER une couverture minimale C ;
2- EDITER l'ensemble des attributs isolés dans une même relation (tous les attributs sont
clés) ;
3- RECHERCHER le plus grand ensemble X d'attributs qui détermine d'autres attributs ;
4- EDITER la relation R(X, A1, ..., AN) qui est en troisième forme normale ;
5- SUPPRIMER toutes les dépendances fonctionnelles figurant dans R du graphe de
couverture minimale C ;
6- SUPPRIMER les attributs isolés de C (c'est-à-dire les attributs non sources ou cibles de
dépendances fonctionnelles) ;
7- REPETER l'opération de réduction du graphe C à partir de l'étape 3 jusqu'à ce que C soit
vide.
Remarque : Cet algorithme fournit bien une décomposition en 3FN qui préserve les DF mais qui n'est pas
nécessairement sans perte. Pour avoir une décomposition sans perte, il suffit d'ajouter à la décomposition finale
une relation composée des attributs formant la clé de la relation universelle (ou ajouter ces attributs à la
relation créée à l'étape 2, si elle existe).
IX.3.5 Insuffisance de la troisième forme normale
Il s'agit ici de détecter les boucles pouvant exister dans le graphe des dépendances fonctionnelles. Supposons,
par exemple une relation PLAGE indiquant le nom, la région et le canton où se situent les plages. Supposons en
outre que deux plages d'une même région ne puissent pas porter le même nom et qu'il n'existe pas deux cantons
de même nom. La relation se note : PLAGE (NOMP, REGION, CANTON) et possède les dépendances
fonctionnelles suivantes : (NOMP, REGION) → CANTON et CANTON → REGION

Bien que la relation soit en 3ème forme normale, il existe encore des redondances dues au fait qu'un attribut
non clé détermine une partie de la clé. Afin d'éliminer ce type de redondance, BOYCE et CODD ont introduit
une nouvelle forme normale :
Définition : Forme Normale de BOYCE-CODD (BCNF) :
Une relation est en BCNF si et seulement si les seules dépendances fonctionnelles élémentaires sont celles dans
lesquelles une clé détermine un attribut. Pour l'exemple précédent une décomposition en BCNF serait :
PLAGE (NOMP,CANTON) et GEO (CANTON,REGION)
Théorème de décomposition en BCNF :
Toute relation admet au moins une décomposition en BCNF qui est sans perte ; cependant, une telle
décomposition ne préserve généralement pas les dépendances fonctionnelles. Dans l'exemple précédent on ne
préserve pas la première DF.
IX.4. LA QUATRIEME FORME NORMALE

La notion de dépendance fonctionnelle nous a conduit à décomposer les relations en troisième forme normale et
en forme normale de BOYCE CODD. Ceci est pourtant insuffisant pour éliminer les redondances et les
anomalies de mises à jour. Considérons, par exemple, une relation PREFERENCES où nous indiquons, pour
chaque nageur, ses différents domiciles et les plages qu'il a l'habitude de fréquenter :
PREFERENCES (NN, VILLE, NP)
Il n'existe aucune dépendance fonctionnelle entre les différents attributs, ce qui conduit à des situations du type
:
Dans cette relation, tout est clé : elle est en 3ème forme normale. Pourtant, il subsiste de nombreuses
redondances. La relation n'est pas décomposable selon les critères que nous venons d'évoquer, ce qui nous
conduit à introduire la notion de dépendance fonctionnelle multivaluée.
IX.4.1 Les dépendances multivaluées
Définition : Dépendance Multivaluée
Soit R(A1, A2, …,An) un schéma de relation. Soient X et Y des sous-ensembles de A1, A2, …,An. On dit que
X ->-> Y (X multi-détermine Y, ou il y a une dépendance multivaluée de Y sur X) si, étant données des valeurs
de X, il y a un ensemble de valeurs de Y associées et cet ensemble est indépendant des autres attributs Z = R-X-
Y de la relation R.
( X ->-> Y) ⇔ ( (xyz) et (xy'z') ∈R ⇒(xy'z) et (xyz') ∈ R)
Propriété :
Les dépendances fonctionnelles sont des cas particuliers de dépendances multivaluées :
(X →Y ) ⇔( (xyz) et (xy'z') ∈R ⇒y = y')
De même que pour les dépendances fonctionnelles, il existe des axiomes d'inférence de dépendances
multivaluées. Ce sont les suivants :

- Complémentation : (X ->-> Y) ⇒ (XR - X - Y)
->->
- Augmentation : (X ->-> Y) et (V ⊂ W YV)
->-> ) ⇒(X W
- Transitivité : (X ->-> Y) et (Y ->-> Z) ⇒ (XZ-Y)
->->
Dont on peut déduire d'autres règles telles l'union :
- Union : (X ->-> Y) et (Y ->-> Z) ⇒ (XYZ)
->->
A partir de ces axiomes, on introduit la notion de Dépendance Multivaluée Elémentaire :
Définition : Dépendance Multivaluée Elémentaire
Une dépendance multivaluée élémentaire X ->-> Y d'une relation R est une dépendance est une dépendance
multivaluée telle que :
- Y n'est pas vide et est disjoint de X ;
- R ne contient pas une autre Dépendance Multivaluée du type X' ->-> Y' telle que X' ⊂X et Y '⊂Y .
Ainsi, dans l'exemple précédent nous isolons les Dépendances Multivaluées Elémentaires suivantes :
NN ->-> VILLE et NN ->-> NP
IX.4.2 Quatrième forme normale

Définition : quatrième forme normale
Une relation est en quatrième forme normale si et seulement si, lorsqu'il existe une dépendance multivaluée
élémentaire, celle-ci est unique.
Propriété :
Toute relation a une décomposition en quatrième forme normale qui est sans perte. Cette décomposition n'est
pas forcément unique.
Du fait qu'une dépendance fonctionnelle est un cas particulier de dépendance multivaluée, nous pouvons
déduire qu'une relation en quatrième forme normale est en forme normale de BOYCE-CODD et donc en
troisième forme normale.
Sur l'exemple que nous venons de voir (PREFERENCES), la clé est l'ensemble des trois attributs et il existe
deux dépendances multivaluées : la relation n'est donc pas en quatrième forme normale. Une décomposition de
cette relation en quatrième forme normale donne deux relations PREF1 (NN, VILLE) et PREF2 (NN, NP)
IX.5. LA CINQUIEME FORME NORMALE

La quatrième forme normale n'est pas encore suffisamment poussée pour éliminer tous les risques de
redondances et d'anomalies.
Exemple :
Nos précédents nageurs sont amateurs de fruits de mer et en consomment couramment quand ils vont sur leurs
plages préférées. Voyons une extension de la relation CONSOMMATION (NAGEUR, CRUSTACES, VILLE)
:

Nous constatons aisément que cette relation présente de la redondance. Cette redondance provient d'une
contrainte d'intégrité implicite dans la conception du monde réel :
"Tout nageur ayant consommé un type de crustacés et ayant séjourné dans une ville les cultivant a consommé
de ce type de crustacés dans cette ville."
Ainsi, le fait que Plouf ait mangé du tourteau est répété à plusieurs reprises, etc.
Toutefois, cette relation est en quatrième forme normale car il n'y a pas de dépendance multivaluée. Pour nous
en assurer, nous pouvons considérer les projections B1, B2, B3 de la relation CONSOMMATION sur les
différents couples d'attributs C1(NAGEUR, CRUSTACES), C2(NAGEUR, VILLE) et C3(CRUSTACES,
VILLE), et constater que la jointure de deux de ces relations ne redonne jamais la relation CONSOMMATION.
La relation n'est donc pas décomposable en deux autres relations.
IX.5.1 Les dépendances de jointure

Le problème provient du fait que nous avons jusqu'alors toujours essayé de décomposer une relation en deux
relations. Comme nous allons le montrer ci-dessous, certaines relations sont décomposables, non pas en deux,
mais en trois relations. C'est le cas dans notre exemple en raison de la contrainte d'intégrité que nous rappelons
ci-dessous :
"Tout nageur ayant consommé un type de crustacés et ayant séjourné dans une ville les cultivant a consommé
de ce type de crustacés dans cette ville." qui se note de façon plus formelle :
(nageur, crustacés) ∈ C1 et (nageur, ville) ∈C2 et (crustacés, v
⇒(nageur, crustacés, ville) ∈ CONSOM M ATION
Définition : dépendance de jointure

Soit R(A1, A2, …, An) un schéma de relation et X1, X2, …, Xm des sous-ensembles de (A1, A2, …, An). On
dit qu'il existe une dépendance de jointure *(X1, X2, …,Xm) si R est la jointure de ses projections sur X1, X2,
…, Xm, c'est-à-dire si :
R = π X1(R) |x| π X2(R) |x| … |x| π Xm(R).
Par exemple, la relation CONSOMMATION obéit à la dépendance de jointure suivante :
* (NAGEUR CRUSTACES, NAGEUR VILLE, CRUSTACES VILLE)
Propriété :
Les dépendances multivaluées sont des cas particuliers de dépendances de jointure :
(X →Y ) ⇒( (xyz) et (xy'z') ∈R ⇒y = y')
IX.5.2 Cinquième forme normale

La cinquième forme normale est une généralisation de la quatrième forme normale qui nécessite de prendre en
compte les dépendances de jointure induites par la connaissance des clés d'une relation.
Définition : Cinquième Forme Normale
Une relation R est en cinquième forme normale si et seulement si toute dépendance de jointure est impliquée
par des clés candidates de R.
IX.6 CONCLUSIONS
Dans ce chapitre, nous avons présenté la théorie de la normalisation des schémas relationnels. Cette
normalisation est très importante dans la pratique si l'on veut éviter de stocker des informations redondantes.
On considère, en général, que la troisième forme normale est suffisante dans les cas courants.
Dépendant de la sémantique des données, le processus de normalisation reste à la charge de l'utilisateur du
SGBD. Cette phase, délicate, est aujourd'hui largement facilitée par des outils d'aide à la conception que
proposent différents constructeurs.
X LES OUTILS
Les activités d’analyse et de production peuvent rapidement s’avérer fastidieuse et sujettes à des erreurs. C’est
pourquoi les informations se fon t aider par des outils spécialistes, les ateliers de génie logiciel ou AGL, de la
même manière que les architectes, les graphistes les ingénieurs disposent d’outils informatiques spécifiques à
leur domaine.
X.1 SYSTEMES DE GESTION DES BASES DE DONNEES(SGBD)
X.1.1 Introduction
On conçoit aisément que la gestion d’une BD, sa consultation et d’une manière générale la manipulation des
données qu’elle contient constituent des opérations complexes. C’est la raison pour laquelle on fera appel à des
logiciels spécialisés appelés systèmes de gestion de bases de données (SGBD). L’on distingue plusieurs SGBD
sur le marche, Access, oracle, db2, SQL server ou MySQL, qui sont parmi les SGBD les plus représentatifs. Ils
offrent un ensemble de fonctions permettant la définition, l’exploitation et la gestion de tables et de leurs
contenus. Les fonctions offertes généralement par les SGBD relationnelles sont :
- Organisation des données : les données sont organisées sous forme de tables et de colonnes. le SGBD
vérifie les propriétés d’unicité (deux lignes n’ont pas la même valeur de NPROD dans la table des
produits) et de référence (à toute valeur de NPROD dans la table détails doit correspondre une ligne
dans la table des produits) de certaines colonnes).
- Gestion des données : il est possible d’ajouter et de retirer des lignes dans une table. Il est également
possible de modifier les valeurs d’une colonne dans certaines lignes d’une table. Le SGBD garantit le
respect des contraintes d’unicité et de référence qui ont été déclarées.
- Accès aux données : l’accès aux données et leur manipulation s’effectuent à l’aide du langage SQL.
Celui-ci permet de décrire des ensembles des données en en définissant les propriétés, c'est-à-dire sans
faire référence aux techniques d’accès qui seront utilisées pour atteindre ces données dans la base. cette
désignation d’ensemble de données prend la forme de requêtes SQL.

- Accès par programme : les commandes SQL peuvent être exécutées soit à partir d’un terminal ou d’un
programme d’application.
- Autres fonctions : les SGBD offrent d’autres fonctions telles que la protection contre les incidents, la
gestion des accès et le contrôle des accès.
X.1.2 Les defis des sgbd d’aujourd’hui
Les données sont au cœur de grandes applications informatiques, mais elles sont aussi essentielles dans la
plupart de nos activités professionnelles ou simples citoyennes. Les défis des SGBD de nos jours sont diverses :
- Multiplicité des types de données : les données prennent aujourd’hui des formes très variées , souvent
bien éloignées de simples formats que nous observons chaque jour : donnees multimédias, (images,
vidéo, musique) , donnees semi-structurées(texte, formulaire), donnees géographiques(GPS)…
- Information incomplète : l’on est souvent submergé d’informations de piètres qualités. Cela est vrai
pour les bases de donnees contenant de nombreuses donnees erronées. Comment produire l’information
correcte à partir des donnees imprécises ?
- Volumes et performances : en 1969 la plus grande BD comportait 500 000 enregistrements(Bachmann).
Elles en contiennent aujourd’hui plusieurs milliards. Comment mémoriser , gérer et exploiter ces
donnees en toute sécurité en offrant aux utilisateurs des temps de réponse acceptables ?
- Accès aise par des non informaticiens :l’explosion des demandes exige que l’utilisateur puisse lui-même
accéder aux donnes sans passer par l’intermédiaire de l’informaticien. Quelles technologies qu’elles
interfaces et quelles compétences vont amener ces utilisateurs à l’autonomie nécessaire ?
- Maintenance et évolution : comme tous les composants des systèmes d’information, les bases de
donnees évoluent au gré de l’évolution des besoins des utilisateurs . ce processus est complexe. En
effet une BD est utilisée par plusieurs milliers de programmes, de sortes que toute modification des
structures de donnees risque d’exiger la modification des milliers de programme set d’écrans
d’interfaces avec les utilisateurs. Le manque de documentation décrivant les formats et la signification
des structures de donnees constitue ici un défi majeur.
- Données distribuées et nomades : le modèle d’une BD sous la forme d’une machine unique n’est plus
appropriée aux exigences actuelles. Les donnes sont aujourd’hui distribuée sur plusieurs machines
communicantes, qui vont de gros serveurs aux Smartphones. Les techniques de gestion et d’exploitation
centralisée ne sont plus suffisantes d’autant plus que certaines parties de la base sont nomades
intermittentes et partiellement autonomes.
- Les BD et le web : le web constitue une BD extraordinaire. Mais loin des concepts classiques : mode de
stockage, formats de données, SGBD, délocalisation, consultation et gestion, intégrité, sécurité,
résistance aux pannes, tout est différent. Mais comment unifier web et bases de données ?comment
interfacer web avec les BD ?
- Données décisionnelles : aux BD traditionnelles, celles que nous allons étudier dans cet ouvrage
s’ajoutent les BD d’aide à la décision souvent dénommées entrepôts de donnees. Ces BD spécialement
conçues pour l’analyse des données sont souvent de très grande taille et alimentées par à partir de
sources diverses dont les bases de données classiques et font l’objet de traitements statistiques
extrêmement lourds.
- Les ORM : l’émergence des outils de développement de programmes dits Object relational mapping(tels
que EJB et Hibernate), incitent à ,modéliser les besoins des utilisateurs sous la forme de classes java.
De celles-ci les outils sont capables de dériver de manière automatique les structures d’une base de
donnees permettant de stocker les données persistantes des objets de ces classes. Cette pratique entraine
souvent de multiples problèmes de qualité et d’évolutivité de la base de données.

Base de Donnees Et Le Modele Entite-Association - Levraicoursdocx

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Base de Donnees Et Le Modele Entite-Association - Levraicoursdocx

Transféré par

Droits d'auteur :

Formats disponibles

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 1

II UNE DEMARCHE SIMPLIFIEE

Relever les types

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 2

III.3 NIVEAUX DE PREOCCUPATION OU D’ABSTRACTION DU MODELE DE

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 3

Dans le cadre de ce cours, nous présentons uniquement le niveau conceptuel.

IV LE MODELE CONCEPTUEL DE DONNEES

Le schéma conceptuel poursuit plusieurs buts :

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 4

 Le modèle réseaux sémantiques

L'exemple le plus concret d'un tel modèle est le web sémantique.

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 5

2- La traduction de ce schéma en structures de bases de données, y compris éventuellement leur expression

IV.2 LES CONCEPTS DU MODELE ENTITES-ASSOCIATIONS

IV.2.1 Introduction et question de vocabulaire

Cependant, une question de vocabulaire est à relever :

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 6

IV.2.2 Les types d’entités

CLIENTS CONTRATS ACCIDENTS

CLIENTS CONTRATS VEHICULES VEHICULES

Entités Types d’entité

Figure x : types d’entités et entités

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 7

IV.2.3 Type d’associations

Figure x : type d’entités et type d’associations

IV.2.3.2 Propriétés d’un type d’association

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 8

CLIENTS 0 ,N 1,1 CONTRATS

Signer. CLIENTS Signer. CONTRATS

IV.2.3.2.2 Cardinalités d’un type d’association

Cette figure sera interprétée de la manière suivante :

IV.2.3.2.3 Classes fonctionnelles ou type d’un type d’association

a) Type d’association un à plusieurs (1 : n)

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 9

b) Type d’association un à un (1 :1)

Chaque entité participe au maximum une seule fois à l’association.

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 10

Chaque type d’entité participe au maximum plusieurs fois à l’autre.

IV.2.3.2.4 Type d’association obligatoire ou facultatif

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 11

• Gestion du temps et entités temporelles

La gestion du temps peut présenter plusieurs formes :

Ce fait est illustré à travers la figure suivante :

Subordonné - Une personne est responsable de 0 ou plusieurs

• Association ternaire et n-aires

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 12

• Entité faible dans un type d’association

Entité forte Entité faible

CIF : Contrainte d'Intégrité Fonctionnelle (association hiérarchique, association fonctionnelle) : permet de

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 13

Pour qualifier la contrainte associée à cette spécialisation :

Liste propriétés communes

Liste propriétés spécifiques

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 14

comme illustré ci-dessous : voiture

chassis roue moteur

Francis Mathieu LAGO Ziza -Enseignant INP-HB de Yamoussoukro- DMI Page 15

IV.3.1 Les attributs

CLIENT CONTRAT VEHICULE ACCIDENT

Adresse Datesign Modèle Montant

Figure x : Type d’entités, type d’associations et leurs attributs.

Figure x : A chaque attribut correspond NumVeh : char(16)