École Nationale des Sciences Informatiques

Conception de Bases de Données

R. KHCHERIF
Raoudha.khcherif@ensi-uma.tn
(Bureau 208)
 I. Introduction
• Volume important de données (Banques, bibliothèques, … etc.)
– Problème : comment stocker et manipuler les données?
– Données → Bases de données (BD)
– Logiciel → Système de Gestion de bases de Données (SGBD)
• I.1. Bref Historique des SGBD?
– Années 1960s:
• Organisation classique en fichiers.
• 1ère génération de SGBD (hiérarchiques puis réseaux).
– Années 1970s:
• 2ème génération de SGBD – SGBD relationnels (commercialisés en 1980).
– Années 1980s:
• 3ème génération de SGBD – SGBD orientés objet
– Années 1990s:
• 4ème génération supportant le web et le multimédia

Conception de BD
RK 2
 I. Introduction
• I.2. Pourquoi les BD?
– Pour pallier aux problèmes des systèmes traditionnels (systèmes de
fichiers):
• Redondance des données:
– Particularisation des fichiers en fonction des traitements.
• Insécurité des données:
– Accès non autorisés
– Abandon d’un ensemble d’opérations
• Incohérence des données:
– MAJ d’une partie des données redondantes
– Non respect des contraintes d’intégrités

Conception de BD
RK 3
 Limites des systèmes de fichiers

Fichiers Applications

BP 2536
Facturation

BP 2536 Commercial

BP 2536
Prospects
Délais de mise à jour

Conception de BD
RK 4
 Avec base de données

Base de données Filtre (vues) Applications

BP 2536 Facturation

Commercial

Prospects

Conception de BD
RK 5
 Propriétés d’une BD

– Une BD permet de :
• Combiner toutes les données
• Centraliser les données
• Partager les données entre plusieurs traitements
– Limitation de la redondance des données
• Appliquer les MAJ qu’une seule fois
• respecter les contraintes d’intégrités (age d’une personne doit être
un nombre positif)
• Sécuriser les accès
• Abandonner facilement les opérations erronées non validées
• Résister aux pannes éventuelles

Conception de BD
RK 6
 I.3. Qu’est ce qu’une BD?

• Une Base de données (BD) est :

– Collection de données structurées, sures, cohérentes, et partageables.
• Correspond à une représentation fidèle des données et de leur structure avec
le minimum de contraintes imposées par le matériel
• Susceptible d’être utilisée par toutes les applications sans duplication

• Un SGBD est un logiciel permettant de:

– Décrire - la confidentialité
– Manipuler en assurant - l’intégrité
– Consulter les données - la sécurité
– Définir des CI - le partage des données

Conception de BD
RK 7
 I.4. Avantages des BDs

• Usage multiple des données.

• Uniformisation de la saisie (et standardisation des traitements).
• Une grande flexibilité des modifications.
• Facilité d’accès aux données: meilleure disponibilité.
• Protection contre les données erronées et les pannes système.
• Réduction du volume des données stockées: une information n’est stockée
qu’une seule fois, pas de redondance.
• Chaque application ne voit que ce qu’elle doit voir

Conception de BD
RK 8
 Vision simplifiée d’un SGBD

SGBD externe
SGBD interne

Terminaux

Programmes Gestionnaire de fichiers

Conception de BD
RK 9
 I.5. Architecture fonctionnelle type d’un SGBD

• Architecture Ansi/Sparc – 3 niveaux:

– Niveau externe: le niveau d’expression des besoins des users. Il formalise la
manière dont les utilisateurs voient les données.
• Environnement de programmation / interfaces graphiques / deboggueurs / …
– Niveau conceptuel: décrit la structure de la base de données globalement à
tous les utilisateurs (limite la redondance) .
• Compilation / optimisation des requêtes / maintien de l’intégrité / gestion de la
confidentialité.
– Niveau interne: relatif à la mémoire physique
• Gestion de la mémoire secondaire (fichiers), schéma, index
• Gestion de la concurrence
• Reprise après panne

Conception de BD
RK 10
 Architecture à niveaux Ansi/Sparc

Niveau Externe Schéma A Schéma B Schéma C

(vue d’un user)

Correspondance
externe/conceptuelle

Description
Niveau Conceptuel
Unique

Correspondance
Conceptuelle/physique

Niveau Interne Schéma interne

(vue physique)

Conception de BD
RK 11
 Avantage de la séparation en 3 niveaux

• Indépendance physique: on peut modifier l’organisation des données sans

toucher les programmes de traitement.
– Limiter les modifications liées aux changements de matériel, de système
d’exploitation ou des logiciels utilisés.

• Indépendance logique: une modification de l’organisation logique des

fichiers (e.g. une nouvelle rubrique) n’entraîne pas de modification dans les
programmes d’application non concernés.
– la vision de chaque utilisateur est indépendante des visions des autres
utilisateurs et n ’est pas modifiée par les modifications du schéma
conceptuel qui ne le concernent pas.
Conception de BD
RK 12
 I.6. Fonctions des SGBD

• Description des données : Langage de définition de données (LDD)

• Recherche des données Langage de
• Mise à jour des données Manipulation de
Données (LMD)
• Transformation des données

• Contrôle de l’intégrité des données – respect des contraintes d’intégrité:

– Schéma = structure + contraintes
– Formule logique (E.g. Nom character 20, non NULL; age integer between 0 and
120; debit <= credit).
– But: protéger les données
• Gestion de transactions (atomicité des transactions) et sécurité (mots de passe,
etc.)

Conception de BD
RK 13
 Types de SGBD
• SGBD Hiérarchique:
– Les données sont représentées dans la base sous forme de structure
arborescente.
• Manipulation des données (balayage ascendant/descendant).
– E. g. IMS-IBM
• SGBD réseau:
– Les données sont représentées dans la base sous forme d ’un graphe
quelconque.
– Les programmes:
• ne sont pas indépendants de la structure logique de la base
• doivent indiquer le chemin d’accès aux données
• utilisent un langage complexe pour travailler avec lers données.

Conception de BD
RK 14
 Types de SGBD

• SGBD relationnel:
– fondé sur la théorie mathématique des relations;
– représentation très simple des données (tables);
– langage non procédural (déclaratif), puissant et simple d’emploi
– SQL est un standard parmi ces langages
– dominent le marché:
• Exemples : Oracle, DB2, SQLServer, Access, DBase, Paradox, … etc.
• SGBD Objet:
– enregistre les données sous forme d’objets
– E. g. O2
•

Conception de BD
RK 15
 Big Data

• Chaque jour, nous générons 2,5 trillions d’octets de données

• 90% des données dans le monde ont été créées au cours de ces
dernières années
• 90% des données générées sont non structurées
• Source:
– Capteurs utilisés pour collecter les informations climatiques
– Messages sur les médias sociaux Images numériques et vidéos publiées en
ligne
– Enregistrements transactionnels d’achat en ligne
– Signaux GPS de téléphones mobiles
• Données appelées Big Data ou Données Massives

Conception de BD
RK 16
 III.1 Introduction aux modèles de données

• La vue conceptuelle:
– la représentation de l’ensemble des informations contenues dans la base de
données.
– Vue globale de la BD
– Définie par un schéma conceptuel:
• le résultat de la modélisation de l’entreprise.
• écrit au moyen de LDD conceptuel
– Elle se fait indépendamment de toute référence aux représentations des champs
en mémoire, à l’indexage, aux pointeurs, … bref à l’implémentation en
machine.
 Modélisation sémantique au problème de la conception de la base de données.

Conception de BD
RK 17
 III.4. Le Modèle Entité/Association
• Encore appelé entité/relation (« entity/relationship »).
– A ne pas confondre avec modèle relationnel!
• Le modèle entité/association a été introduit par Chen en 1976.
– Un outil informel pour analyser les situations du monde réel (institutions,
entreprises, … etc.).
– L’information est représentée par 3 concepts primitifs :
• Entité: un être ou un objet (concret ou abstrait), qui existe et peut être
distingué d’un autre objet.
– Exemple : employé, personne, étudiant, voiture, …
• Attribut: la propriété décrivant une entité.
– Exemple: Numéro de carte d’identité, nom et prénom, age, …
• Association: la relation, ou ce qui permet de connecter deux entités ou plus.
– Exemple:Affectation (employé- département, …)

Conception de BD
RK 18
 III.4. Modèle Entité / Association (suite)

• Type d’entité (TE): représentation abstraite d’un ensemble d’entités perçues comme
similaires, ayant les mêmes caractéristiques et le même comportement.

– Exemple: toutes les personnes (PERSONNE), les véhicules (VEHICULE), les

clients (CLIENTS), …, etc.

– Un attribut associe à chaque entité une valeur appartenant à un domaine.

• Type d’association (TE): représentation d’un ensemble d’associations ayant la même

sémantique et décrites par les mêmes caractéristiques.

– Nombre de liens autorisés entre entités

– Association N-aires, reliant plus de 2 entités

– Association binaire, reliant deux entités

Conception de BD
RK 19
 Ali Khaled
Jamel

Salem Kamel

modélisé par

Personne

Personne Achète Maison

Acheté
Acheteur
(Rôles)

Conception de BD
RK 20
 III.4.1 Exemples d’associations

Mari
• Unaire: 1

Personne Marié

1 femme

• Binaire: Enseignant donne Cours

Conception de BD
RK 21
 III.4.1 Exemples d’associations (suite)

• Plusieurs associations entre 2 types d’entité. Personne

possède conduit

• Ternaires
Fournisseur Voiture

Client Achète Produit

Conception de BD
RK 22
 III.4.2. Diagramme Entité/Association

• Un graphe entité–association constitue une technique pour représenter la structure

logique d’une base de données de manière graphique:
 Moyen simple et facilement compréhensible pour communiquer les
caractéristiques principales de la conception d’une BD particulière.
 Chaque entité est représentée par un rectangle contenant le nom du type de
l’entité correspondante.
 Chaque type d’association est représenté par un losange contenant le nom de
l’association considérée.
 Les attributs attachés aux entités sont représentés par des ellipses (en pointillé).

➢ Dans le diagramme E/A les clés sont soulignés

 Les arêtes qui relient les entités aux associations

Conception de BD
RK 23
 III.4.3. Types des associations
• Association binaire (A), reliant deux entités (E et F)
– de type 1:1 (un-à-un): si à une entité de E peut correspondre par l’association A au
plus une entité de F, et réciproquement.
– de type 1:n (un-à-plusieurs): si à une entité de E peut correspondre par l’association
A plusieurs entités de F mais à une entité de F au plus une entité de E
– de type n:m (plusiuers-à-plusieurs): si à une entité de E peut correspondre par
l’association A plusieurs entités de F et réciproquement.

N:m
Personne Possède Voiture

– Une personne peut posséder plusieurs voitures, et réciproquement une voiture

peut être possédée par plusieurs (bien très peu fréquent!)

Conception de BD
RK 24
 III.4.3. Types des associations --Cardinalité
N:m
Personne Possède Voiture

• Combien de voitures (minimum) une personne peut avoir?

• Combien de voitures (maximum) une personne peut avoir?
– Cardinalité d’un couple entité-association (E, A) est (m, M), où
• m (resp. M) est le nombre minimum (maximum) d’associations pouvant exister
pour l’entité E.
Type d’association
Cardinalité
N:m
Personne (0:n) (1:n) Voiture
Possède
Entité
Entité Association
Conception de BD
RK 25
 III.4.4. Les Attributs

• Décrit l’information (les propriétés) à conserver sur:

– Une entité
– Une association
– Un attribut.

Salaire Personne Mariée à

Nom Prénom
Date mariage

Jour Mois année

Conception de BD
RK 26
 III.4.4. Attributs (suite)
• Simple (atomique) non décomposé de valeur atomique (jour)
• Composé: décomposé en d’autres attributs (valeurs composées)
Exemples: date (jour,mois,année), adresse ( rue,ville,codep)
• Mono-valué: une seule valeur par occurrence
Exemples: nom, date de naissance
• Multi-valué: plusieurs valeurs par occurrence
Exemples: prénoms, téléphones
• Obligatoire: une valeur au moins par occurrence
Exemples: noms, prénoms,
• Manquant/optionnel: peut ne pas prendre de valeur (inconnu!)
Exemples: salaire, téléphones
Conception de BD
RK 27
 III.4.5. Identifiants des TE et TA

• Identifiant (clé): un attribut ou un ensemble minimum d’attributs dont les valeurs

identifient de manière unique les instances d’une entité (resp. association)
– Exemple : ETUDIANT( n°E, nom, prénoms, ddn, adresse)
• n°etudiant forme une clé. Par contre nom+prénom ne forment pas une clé car
deux étudiants ne sont pas distingués par les instances du TE étudiant employé
(si l’un ou l’autre sont toujours uniques).
époux
– Identifiant d’un TA: Salaire Personne Mariée à
épouse
époux.nom + épouse.nom
Nom Prénom
Date mariage

Jour Mois année

• NB. Le choix des attributs, des domaines et des clés constitue une étape essentielle lors
de la définition d’un modèle du monde réel!
Conception de BD
RK 28
 Démarche à suivre pour produire un
diagramme E/A

1. Identifier les entités

2. Identifier les associations entre les entités

3. Identifier les attributs de chaque entité et de chaque association

• ’’Il est fréquent de représenter initialement certaines associations par des attributs

pendant la conception du schéma conceptuel et d’ensuite convertir ces attributs en

associations au fur et à mesure que la conception progresse et est mieux comprise’’

4. Évaluer le type-d’association ainsi que les cardinalités (E, A)

Conception de BD
RK 29
 Les Règles de validation

• Cohérence du modèle E/A:

– Chaque entité possède une clé.
– Chaque attribut d’une occurrence d’entité ne possède, au plus, qu’une valeur.
– Tous les attributs sont élémentaires.
– Tous les attributs autres que la clé doivent dépendre pleinement et directement
de la clé.
– A chaque occurrence d’une association correspond une et une seule occurrence
de chaque entité participant delà l’association.
– Une cardinalité (0, 1) ou (1, 1) indique une contrainte d’intégrité fonctionnelle
et réciproquement:
• Une association particulière n’est en général pas nommée

Conception de BD
RK 30
 Conception de BD
RK 31
 Exemple d’un hypermarché

(0:n)
NumE Employé (0:1) Chef
Fournisseur
(0:1) (0:n)
Salaire
NomF Adresse

emploi Livraison

Quantité
(0:n) (0:n)
(0:n)
(0:n) (0:n) Article
Rayon Vente

NumR Etage Quantité NomA Type

Conception de BD
RK 32
 Exercice: VPC

• Vente par correspondance – spécifications

– Les clients sont caractérisés par un numéro de client, leur nom, prénom, date de
naissance, rue, code postal et ville.
– Ils commandent des produits à une date donnée et dans une quantité donnée
– Les produits sont caractérisés par un numéro de produit, leur désignation et leur
prix unitaire.
– Chaque produit est fourni par un fournisseur unique (mais un fournisseur peut
fournir plusieurs produits).
– Les fournisseurs sont caractérisés par un numéro de fournisseur et leur raison
sociale.
• Donnez le diagramme E/A correspondant auVPC.

Conception de BD
RK 33
 Représentation multiple

• Un objet peut avoir plusieurs représentations:

Articles
Habillement

HI-FI

Alimentaire
P. Laitiers Plusieurs points de vues:
Fruits légumes • un article
viandes • un article alimentaire
• un produit laitier

Conception de BD
RK 34
 Généralisation et Spécialisation

TE générique
Articles

Lien IS-A

Spécialisation Généralisation
Articles Articles Articles
Alimentaires habillement HI-FI

TE spécifique

Produits laitiers Viandes Fruits et légumes

Conception de BD
RK 35
 Etage

Chambre

Conception de BD
RK 36
 Entité Faible

Entité faible = entité sans identifiant propre.

• Identification: deux possibilités
1. par le ou les rôles assumés par d’autres entités qui participent à la même
association que l’entité faible à identifier.
2. par une combinaison d’attributs propres de l’entité et du ou des rôles
assumés par d’autres entités qui participent à la même association que
l’entité faible à identifier.
Remarques:
• La cardinalité du rôle de l’entité faible au sein de l’association
identifiante est (1,1)
• Concrètement, dans la base de données, l’identifiant de l’entité faible
sera formé par une combinaison d’attributs propres (s’il y a lieu) et par
un ou des identifiants des autres entités qui participent à la même
association que l’entité faible à identifier.

Conception de BD
RK 37
 Exemple
• Prenons l'exemple d'un cinéma, et de ses salles. On peut considérer chaque
salle comme une entité, dotée d'attributs comme la capacité, l'équipement en
son Dolby, ou autre. Il est diffcilement imaginable de représenter une salle
sans qu'elle soit rattachée à son cinéma. C'est en effet au niveau du cinéma que
l'on va trouver quelques informations générales comme l'adresse ou le numéro
de téléphone.
• Il est possible de représenter le lien en un cinéma et ses salles par une
association classique. La cardinalité « 1..1 » force la participation d'une salle à
un lien d'association avec un et un seul cinéma. Cette représentation est
correcte, mais présente un inconvénient : on doit créer un identifiant artificiel
id pour le type d'entité Salle, et numéroter toutes les salles, indépendamment
du cinéma auquel elles sont rattachées.
• On peut considérer qu'il est beaucoup plus naturel de numéroter les salles par
un numéro interne à chaque cinéma. La clé d'identification d'une salle est alors
constituée de deux parties :
1. la clé de Cinéma, qui indique dans quel cinéma se trouve la salle ;
2. le numéro de la salle au sein du cinéma.
• En d'autres termes, l'entité salle ne dispose pas d'une identification absolue,
mais d'une identification relative à une autre entité. Bien entendu cela force la
salle a toujours être associée à un et un seul cinéma.
Conception de BD
RK 38
 Exemple

Cinéma

1:n

1:1

Salle

Conception de BD
RK 39
 III. 5. Le modèle relationnel

III.5.1. INTRODUCTION
• Le modèle relationnel a été proposé par E.F. Codd en 1970 (IBM SAN-JOSE).
• Il est souvent considéré comme le plus simple et le plus élégant des modèles.
 Sa simplicité est due à une vision tabulaire des données très intuitive.

 Son élégance résulte de bases formelles issues de la théorie mathématique des

ensembles.
• Aujourd'hui utilisé par beaucoup de SGBD relationnels commerciaux (Oracle,
Informix, DB2, Ingres, Sybase, dBase, Access …) et SIG.

Conception de BD
RK 40
 III. 5. 1. Introduction (suite)
• Les objectifs du modèle relationnel étaient différents de ceux des modèles réseau et
hiérarchique :
– Permettre un haut degré d'indépendance entre les applications (programmes,
interfaces) et la représentation interne des données (fichiers, chemins d'accès).
– Etablir une base solide pour traiter les problèmes de cohérence et de redondance
des données.
☺ LMD (ensembliste) déclaratif (non procédural):
 spécifier ce que l'on souhaite obtenir sans dire comment l'obtenir (le SGBD est
responsable de la politique d'exécution des requêtes).
 LDD intégré au LMD.
☺ Un Standard

Conception de BD
RK 41
 III.5.2. Les modèles relationnels

• Deux modèles relationnels

1. Modèle formel
 relation, attribut, tuple, identifiant…
 normalisation
 algèbre relationnelle
 calculs relationnels
2. Modèle logique, implémenté : SQL
 table, colonne, ligne, clé primaire…
 SQL - définition et modification du schéma
 SQL - entrée et mise à jour des données
 SQL - requêtes

Conception de BD
RK 42
Le Modèle Relationnel Formel – Concepts de Base
• Ensemble de concepts pour formaliser la description des objets du
monde réel.

• Monde réel  Relationnel

objet → relation
propriété
(simple, monovaluée) → attribut
lien
(binaire, sans attribut) → identifiant externe
représentation multiple → /

Conception de BD
RK 43
 Concepts de Base (2)

• Etudiant (N°Etud, nom, prénom, ddn)

nom de la relation noms des attributs

Etudiant
Schéma
N°Etud nom prénom ddn

12304 Ali Mohamed 8/11/1984

23403 Salah Youssef 11/8/1983

Tuple/occurrence 34504 Tounsi Khaled 7/7/1984

Conception de BD
RK 44
 Schéma relationnel, Domaine
• Une BD = un ensemble de relations.
• Un schéma d'une BD relationnelle (sert à décrire les relations):
 un ensemble de schémas de relations : R1, R2, …, Rn
• Un schéma d'une relation = un ensemble d'attributs avec leurs domaines
 R = (A1:D1, A2:D2, …, Ap:Dp)
ou, plus simplement, R = (A1,A2, …,Ap)
 Attributs simples et monovalués
 Un domaine D est un ensemble de valeurs caractérisé par un nom – type de
données.
 Chaque valeur du domaine est atomique et donc indivisible.
 Cette notion permet de définir les ensembles de départ. Un domaine peut être
défini en extension en donnant la liste des valeurs composantes ou en
compréhension en définissant une propriété caractéristique du domaine.
 COULEUR = { jaune; vert; rouge; bleu; rose; orange; pourpre}
 ABONNE = {Personne possédant une carte d'abonné valide pour l'année en cours
}
Conception de BD
RK 45
 Relation
• Autre définition :
– Une relation R correspond au sous ensemble du produit cartésien de n domaines : R
 D1 x D2 x D3 x … x Dn
– n : degré de la relation (nombre d’attributs)
– attribut : rôle joué par un domaine dans une relation.
• Exemple:
– Pilote (NumPil, NomPil, adr, sal)
– Avion (NumAv, AvNom, loc, cap)
– Vol (NumVol, NumPil, NumAv,Ville_dep,Ville_arr, Heure_dep, Heure_arr)

Conception de BD
RK 46
 Exemple de relations
Etudiant N°Etud Nom Prénom Age
136 Tounsi Med 20
253 Ben Foulen Ali 19
101 Cherif Cherif 20

<253,Ben Foulen, Ali, 19> constitue un tuple

Cardinalité de Etudiant = Nombre de tuples

Cours NomC Horaire Prof

Algorithmique Lundi 10:30-12 Mr X
Système Lundi 14-15:30 Melle Y

Suit N°Etud NomC

136 Algorithmique
253 Système
101 Système
Conception de BD
RK 47
 Clé d’une relation – Clé primaire
• Une clé de relation est un sous-ensemble (minimal) d'attributs qui permet d’identifier de
manière unique chaque tuple de la relation.
– Il n'existe jamais 2 tuples ayant mêmes valeurs pour tous ces attributs
– Une clé n'admet jamais de valeurs nulles.
• Toute relation doit posséder au moins une clé (identifiant).
– La clé choisie est appelée clé primaire
– Par convention, lors de la définition d'un schéma cette clé est mise en évidence
(soulignement ou gras).
• Exemple
– Etudiant ( N°Etud , nom , prénom , age)
– Cours ( NomC , horaire, prof )
– Suit ( N°Etud , NomC )
• N°Etud référence un Etudiant
• NomC référence un Cours

Conception de BD
RK 48
 Clé Etrangère
• Groupe d’attributs devant apparaître comme clé primaire dans une autre relation
– Décrit les liens binaires entre les relations (TA)
• Les clés étrangères définissent les contraintes d’intégrité référentielles.
– Lors d'une insertion, la valeur des attributs doit exister dans la relation référencée
– Lors d'une suppression dans la relation référencée les tuples référençant doivent
disparaître.
• Exemple: la relation Suit contient les clés de Etudiant et Cours
– Suit traduit un TA entre Etudiant et Cours
– La valeur de N°Etud dans Suit est :
• celle de l'identifiant d'un tuple existant de Etudiant (intégrité référentielle)
• ou éventuellement nulle (si attribut facultatif)
– Même contrainte pour NomC de Suit

Conception de BD
RK 49
 Exemple de Schéma

• Etudiant (N°Etud, Nom, Prénom, Age)

• Cours (NomC,Horaire,Prof)

• Suit (#N°Etud,#NomC)

• Clés etrangères

– N°Etud Référence un Etudiant

– NomC Référence un Cours

Conception de BD
RK 50
 Diagramme des Liens

Etudiant N°Etud Nom Prénom Age Cours NomC Horaire. Prof

Suit N°Etud NomC

Conception de BD
RK 51
 Contraintes d’intégrité (CI)
• Une contrainte d’intégrité est une propriété du schéma, invariante dans le temps.
– Chaque relation doit respecter les contraintes d’intégrité
• Il existe différents types de contraintes d'intégrité:
– Structurelles ou statiques (liées au modèle)
– Applicatives ou dynamiques (contraintes de cohérences liées à l’application)
• CI de domaine
– «toute valeur d’un attribut doit appartenir à son domaine de définition»
• CI de relation
– «toute valeur de clé primaire existe et est unique»
• CI de référence
– «Toute valeur de clé étrangère (CE) existe dans la clé primaire CP associée»
– la valeur d'attribut de la relation R doit apparaître comme valeur de clé dans une
autre relation S

Conception de BD
RK 52
 Vérification de l'intégrité référentielle
• Automatiquement, par le SGBD
• Si un utilisateur veut entrer (INSERT) un tuple dans Suit avec un NomC qui n'existe pas
dans Cours
 refus
• Si un utilisateur veut modifier (UPDATE) le nom du cours d'un tuple dans Suit avec un
NomC qui n'existe pas dans Cours
 refus
• Si un utilisateur veut supprimer (DELETE) un tuple de Cours pour lequel il existe des
tuples dans Suit
 refus?
 Détruire les tuples de Suit correspondants ?
 Mettre à NULL la valeur de NomC dans Suit ?
• Si un utilisateur veut mettre à jour (UPDATE) le nom d'un cours pour lequel il existe des
tuples dans Suit
 refus?
 Propager la mise à jour de NomC dans Suit ?
Conception de BD
RK 53
 Contraintes de Modélisation (1)
• Les notions d'attribut multivalué ou complexe n'existent pas dans le modèle
relationnel. Il faut donc les modéliser autrement.
• Pour un attribut monovalué complexe, il faut choisir entre le composé ou les
composants.
• Pour un attribut multivalué, il faut créer une autre relation (ceci pour chaque attribut
multivalué).
• Représentation d'attribut monovalué complexe
– Soit pour Personne adresse : nom-rue , n° , ville , CP
– Solution 1: un attribut par composant :
• Personne (AVS, nom,…, nom-rue , n° , ville, CP)
• "Rue AbdelAziz Elaroui", "21", "Tunis", "1002"
• il est éventuellement possible de définir par ailleurs une vue restituant la
notion globale d'adresse
– Solution 2: un attribut adresse, de domaine : chaîne de caractères
• Personne (AVS, nom,…, adresse)
• "Rue AbdelAziz Elaroui, 21 Tunis 1002"
• le système ignore nom-rue, n°, ville et CP

Conception de BD
RK 54
 Contraintes de Modélisation (2)
• Représentation d'attribut multivalué
• Exemple: mémoriser les différents prénoms des étudiants
• Mauvaise modélisation: plusieurs attributs
– Etudiant (N°Etud, nom, prénom1, prénom2,… )
– 136 BenFoulen Mohamed Slim
– 101 Ali Mohamed Salah
– 253 Tounsi Fatma Null
• Bonne modélisation : créer une relation supplémentaire
– Etudiant (N°Etud, nom)
– EtudPrénoms ( #N°Etud, prénom )
• 136 Mohamed
• 136 Slim
• 101 Mohamed
• 101 Salah
• 253 Fatma
• Clé étrangère: N°Etud référence Etudiant

Conception de BD
RK 55
 Récapitulatif
• Un schéma relationnel se compose :
pour chaque relation de :
 nom de la relation
 définition
attributs + domaines
 clé
 éventuellement clé(s) étrangère(s)
 contraintes d'intégrité associées
 et des autres contraintes d'intégrité qui portent sur plusieurs
relations.

Conception de BD
RK 56
 III.5.3. Problème de la redondance
• [En dehors des clés étrangères]
• ex. Soit la relation COMMANDE_PRODUIT.

NumProd Quantité NumFour Adresse

101 300 901 Tunis
104 1000 902 Mannouba
112 78 904 Mannouba
103 250 901 Tunis

• Cette relation présente différentes anomalies.

Conception de BD
RK 57
III.5.3. Problème de la redondance (suite)

• Anomalies de modification : Si l’on souhaite mettre à jour l’adresse

d’un fournisseur, il faut le faire pour tous les tuples concernés.

• Anomalies d’insertion : Pour ajouter un fournisseur nouveau, il faut

obligatoirement fournir des valeurs pour NumProd et Quantité.

• Anomalies de suppression : ex. La suppression du produit 104 fait

perdre toutes les informations concernant le fournisseur 902.

Conception de BD
RK 58
 Normalisation (1)
• Objectifs de la normalisation :
 Suppression des problèmes de mise à jour
 Minimisation de l’espace de stockage (élimination des redondances)
 La taille des fichiers normalisés croît de façon arithmétique alors que la taille
des fichiers non normalisés croît de façon géométrique.
• Les dépendances Fonctionnelles
 Soient R(A1, A2 … An) un schéma de relation, X et Y des sous-ensembles de A1,
A2 …An
 On dit que X détermine Y ou Y dépend fonctionnellement de X (X →Y) ssi il
existe une fonction qui à partir de toute valeur de X détermine une valeur unique
de Y
• Exemple
– PRODUIT (NumProd, Dési, PrixUni)
– NumProd →Dési, Dési →PrixUni

Conception de BD
RK 59
 Définitions

• Une dépendance fonctionnelle X→A, est

dite élémentaire si
– A n’est pas inclus dans X
– il n’existe pas X’ inclus dans X tel que X’ → A
• Couverture minimale est un
– sous ensemble minimum de DF élémentaires
permettant de générer toutes les autres

Conception de BD
RK 60
 Normalisation (2)

Propriétés des dépendances fonctionnelles

• Réflexivité: Si Y  X alors X →Y
• Augmentation: Si W  Z et X →Y alors X, Z →Y, W
• Transitivité: Si X →Y et Y → Z alors X→Z
• Pseudo-transitivité: Si X →Y et Y, Z → T alors X, Z → T
• Union: Si X →Y et X → Z alors X →Y, Z
• Décomposition: Si Z Y et X →Y alors X→Z
• NB: La notation X,Y signifie XY

Conception de BD
RK 61
 Normalisation (3)

Les formes normales

• Objectifs

– Définir des règles pour décomposer les relations tout en préservant

les DF et sans perdre d'informations, afin de représenter des objets et
associations canoniques du monde réel (les molécules d'informations)

– Éviter les anomalies de mises a jour

– Éviter les réponses erronées

Conception de BD
RK 62
 Première Forme Normale

• Définition
– Une relation est en 1ère forme normale si tout attribut contient une
valeur atomique (unique)
• Exemple

PERSONNE NOM PROFESSION

DUPONT Ingénieur, Professeur

MARTIN Géomètre

• La relation PERSONNE n’est pas en 1FN!

• Elle doit être décomposée en répétant les noms pour chaque profession

Conception de BD
RK 63
Première Forme Normale -- Exemple

Soit une relation en 1FN:

▪ Fournisseur(NF,NomProduit,Adr,Tel,Prix)
▪ Problèmes
▪ Redondances NomProduit

▪ Mises à jour pour les insertions Prix

▪ Suppressions
NF Adr
▪ Mises à jours des tuples
Tél
▪ Décomposition
▪ Fournisseur1(NF,Adr,Tel)
▪ Catalogue(NF,NomProduit,Prix)
▪ Sans perte d’information, sans perte de DF

Conception de BD
RK 64
 Deuxième Forme Normale

• Définition
– une relation est en 2ème forme normale ssi :
• elle est en 1ère forme
• tout attribut non clé ne dépend pas d'une partie de clé
• Schéma

R K1 K2 X Y

Une telle relation doit être décomposée en

R1(K1, K2, X) et R2(K2, Y)
Conception de BD
RK 65
 Deuxième Forme Normale -- Exemples

• Exemple :
– Fournisseur2(NF, Pays,Ville)
• Redondance
• Décomposition
– Fourn(NF, Ville) NF Ville Pays

– Géo(Ville, Pays)
– Sans perte d’information, sans
perte de DF.

Conception de BD
RK 66
 Troisième Forme Normale
• Définition
– une relation est en 3ème forme normale ssi :
• elle est en 2ème forme
• tout attribut n'appartenant pas a une clé ne dépend pas d'un
autre attribut non clé
• Schéma

R K X Y Z

Une telle relation doit être décomposée en

R1(K, X, Y) et R2(X,Z)
Conception de BD
RK 67
 Troisième Forme Normale -- Exemple
• Exemple:
– Voiture (n° veh, marque, type, puissance, couleur)
 Type → marque
 Type → puissance
• Pas en 3ème forme !
• Il est bon que les relations logiques soient en 3ème forme :
– Pas de redondance
– Pas de perte d ’information
– Pas de perte de dépendance
• Représentation canonique du monde réel !
Conception de BD
RK 68
 Exemples de Décomposition

• Voiture (n° veh, marque, type, puissance, couleur)

– Se décompose en :
• Véhicule (n° veh, type, couleur)
• Modèle (type, marque, puissance)

• Réduction (cru, type, client, remise)

– Se décompose en :
• Remise (cru,client,remise)
• Type (cru,type)

Conception de BD
RK 69
Plus loin que la troisième forme
normale :
Les 3 premières formes normales ont été proposées par E.F. Codd ("inventeur" du
modèle relationnel) en 1972. La forme normale dite de Boyce-Codd a été proposée
en 1974. Les 4ème (1977) et 5ème (1979) formes normales ont été proposées ensuite
par Fagin, mais elles ne concernent que des cas rares et très spécifiques.

Pourquoi et comment ?
 Rappels

• Une relation est en 3FN si :

– pas de DF d'une partie d'une clé vers un
attribut non clé (2FN)
– pas de DF entre attributs non clés.
• Toute relation a au moins une
décomposition en 3FN qui :
– préserve les dépendances fonctionnelles (DF)
– et est sans perte

Conception de BD
RK 71
 Normalisation : Exemple FNBC
Considérons la relation suivante: Cours (Matiere, Classe, Professeur)
complétée par les règles de gestion suivantes:
un professeur n'enseigne qu'une seule matière,
une classe n'a qu'un seul enseignant par matière
desquelles on déduit les DF suivantes:
Matière, Classe → Professeur
Professeur → Matière
Cette relation est en 3NF, néanmoins il est impossible d'enregistrer un
professeur sans classe affectée (puisque classe est une partie de la
clé primaire de la table Cours), et la disparition d'une classe peut
entraîner la disparition de professeur.
Ceci est du au fait qu'une DF n'ait pas comme origine une clé de la
relation. Conception de BD
RK 72
Normalisation : Exemple FNBC
Problème : une DF d'un attribut non clé vers
une partie de la clé
On pourrait alors décomposer la relation Cours
en 2 relations:
Spécialité (Professeur, Matière)
Enseignant (Classe, #Professeur)
Mais la première DF serait alors perdue…
Les deux relations sont en FNBC.
Conception de BD
RK 73
• Une relation en BCNF peut comporter des redondances
• "L'étudiant de numéro NUMETUD pratique le sport
SPORT et suit le COURS."
– Pas de DF
– CLE = {NUMETUD, SPORT, COURS}
– R est en 3FN et en BCNF
– Cependant R contient des redondances :

R NUMETUD SPORT COURS

100 Foot Math
100 Foot Anglais
200 Foot Math
200 Tennis Anglais
200 Foot Anglais

Conception de BD
RK 74
• La notion de dépendance fonctionnelle ne suffit à définir toutes
les dépendances entre les données.

• Dépendance multivaluée (DM) :

– R (A1, A2, …, An)
– X sous-ensemble de {A1, A2, …, An}
– Y sous-ensemble de {A1, A2, …, An}
– X ->> Y : "X multidétermine Y"si, soit Z = R - X - Y,

• {(xyz) et (xy'z') ∈ R => (xy'z) et (xyz') ∈ R }

• "A chaque valeur de X, il y a un ensemble de valeurs de Y

associées et cet ensemble est indépendant des autres attributs."
Conception de BD
RK 75
• Exemple : R (NUMETUD, SPORT, COURS)
– NUMETUD->>SPORT
– NUMETUD->>COURS

<=> Pas de lien entre les cours suivis et les sports pratiqués.

• Contre-exemple : R (NUMEMP, LANGUE, PRODUIT)

"L'employé NUMEMP parle LANGUE et vend PRODUIT".

• Si pour vendre un produit, il faut parler la langue du pays où il

est distribué, il n'y a pas de dm (dépend. multiv.).

Conception de BD
RK 76
 4ème Forme Normale

• Une relation est en 4FN si les seules DM sont

celles dans lesquelles une clé multidétermine un
attribut.
• Remarques :
– une dépendance fonctionnelle est un cas particulier de
dépendance multivaluée
– 4FN => 3FN et BCNF
• en fait, on ne considère que les DM élémentaires
(parties gauche et droite minimale).
Conception de BD
RK 77
 Dépendance de jointure :

Soit R (A1, A2, …An)

X1, X2, …, Xm sous-ensembles de {A1, A2, …, An}

• Il existe une dépendance de jointure *{X1, X2, …, Xm}

si R = ΠX1 (R)∞ ΠX2 (R) ∞…∞ ΠXm (R)

• S'il existe une telle dépendance de jointure, alors R est

décomposable en m relations X1, X2, …, Xm.

Conception de BD
RK 78
Remarques :
• une DM est un cas particulier de DJ (dépend. de jointure) :

(X ->> Y , X ->> Z) => *{XY, XZ}

• si R (A1, A2, A3, A4) a 2 clés A1 et A2, on a les DJ

*{A1A2, A1A3, A1A4} et *{A1A2, A2A3, A2A4}

Conception de BD
RK 79
 Cinquième Forme Normale :

• Une relation est en 5FN si toutes les DJ sont impliquées

par les clés.

• Autre définition de la 5FN (équivalente) : Une relation est

en 5FN s'il n'est pas possible de créer la relation par
jointure de relations plus simples avec des clés différentes.

• Problème : trouver les DJ (elles n'ont pas d'interprétation

sémantique simple)

• Certaines tables n’ont pas de décomposition en 5FN.

Conception de BD
RK 80
 Méthode de décomposition en 3ème forme

• Sans perte d ’information

• Sans perte de DF.
• Créer pour chaque source de DF une relation comprenant comme
attributs la source et toutes les cibles de cette source.
• Si aucun des identifiants de R n’est présent dans au moins une des
relations créées ajouter une relation supplémentaire, constituées des
attributs composant un des identifiants de R.
• Génère parfois des décompositions redondantes.

Conception de BD
RK 81
 Comment concevoir un schéma
relationnel normalisé

• Concevoir un schéma entité/association puis le traduire en

relationnel.
• Créer une relation regroupant tous les attributs ( la relation
universelle) établir un graphe minimum des dépendances;
puis décomposer jusqu’en 3eme.
• Faire un graphe minimum; en extraire directement les
relations en 3eme forme normale:
– Créer pour chaque source de DF une relation comprenant comme
attributs la source et toutes les cibles de cette source.
– La source est la clé de la relation établi.

Conception de BD
RK 82
 III.5.4. Passage E/A → relationnel

schéma de relation avec tous les attributs de l’entité schéma

Entité (TE) →
de relation avec tous les attributs de l’entité.

on ajoute dans le schéma correspondant à l’entité de

Association (TA)
→ cardinalité 1, un identifiant des autres entités participantes à
1-1, 1-N
l’association et les attributs de l’association

nouveau schéma contenant un identifiant de chacune des

TA N-M →
entités participantes et les attributs de l’association

Conception de BD
RK 83
 Passage E/A en relationnel -- Exemple

• TE est représenté par une relation dans laquelle les attributs de l’entité
deviennent ceux de la relation

N°E
Etudiant NomE

Sexe Adresse

Etudiant(N°E, NomE,Adresse, Sexe)

Conception de BD
RK 84
Passage E/A en relationnel -- Exemple (suite)

• Chaque TA est représenté par une relation dans laquelle les clés des TE participants et les
attributs de l’association deviennent ceux de la relation.
Titre
Cours Ncours
0:n

Note obtenir Année

0:n
Prénom NEtud
Etudiants
Nom
• Obtenir(Ncours,Netud,Note,Année)
Modèle E/A Modèle Relationnel

Association Nom Relation

Attributs & clés Attributs

Conception de BD
RK 85
Passage E/A en relationnel -- Exemple (suite)
• Pour les TE pour cardinalité max =1, on ne crée pas de relation mais ce
sont les clés des types entités qui interviennent qui seront ajoutés au TE
dont la cardinalité max=1.

Faculté
Département NDépart
0:n

appart

1:1
Prénom NEtud
Etudiants
Nom

Etudiants(NEtud,Nom,Prénom, NDépart,)

Conception de BD
RK 86
 Bibliographies

• C. Date, « Introduction aux Bases de données », 6eme Edition, Thomson Pub.

1998.
• Jouffroy,C.Letang, « Les fichiers: pratique et choix de l ’organisation des
données informatiques », DUNOD 1977.
• N. Mangnenat, D. Thalman, « Gestion des fichiers et basses de données »,
GOETAN 1982.
• Georges Gardarin, « Maîtriser les bases de données: modèles et langages »,
EYROLLES, 1994.
• Serge Miranda, José-Maria Busta, «L’art des bases de données: Introduction
aux bases de données » , EYROLLES, 1987.
• Christian Carrez, « Des structures aux bases de données », DUNOD, 1990.
• R. Elmasri & S. B. Navathe, « Fundamentals of database systems », 3rd
Edition, the Benjamin/Cummings Pub. 2000.

Conception de BD
RK 87