École Nationale des Sciences Informatiques

A. U. 2017-2018

Conception de Bases de Données

II2
Cours Intégré de 45H (15 semaines de 3 heures)
R. KHCHERIF
Raoudha.khcherif@ensi-uma.tn
(Bureau 208)
 Plan du cours

• Introduction aux Bases de données

• Les systèmes de Fichiers et les SGBD
• Les principaux modèles de données
• Conception d’une base de données relationnelle
• Algèbre relationnelle
• Langage de requêtes SQL

Conception de BD
RK 2
 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 3
 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 4
 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 5
 Avec base de données

Base de données Filtre (vues) Applications

BP 2536 Facturation

Commercial

Prospects

Conception de BD
RK 6
 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 7
 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 8
 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 9
 SGF v.s. SGBD

Figure prise du livre de Rob & Coronel, Database Systems: Design, Implementation, and Management, Sixth Edition
Conception de BD
RK 10
 Vision simplifiée d’un SGBD

SGBD externe
SGBD interne

Terminaux

Programmes Gestionnaire de fichiers

Conception de BD
RK 11
 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 12
 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 13
 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 14
 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 15
 Architecture Fonctionnelle de Référence
Requête

Analyse syntaxique
ANALYSEUR Analyse sémantique
Gestion des schémas

Modification de requêtes
META-BASE TRADUCTEUR Contrôle d'intégrité
Contrôle d'autorisation

Ordonnancement
OPTIMISEUR Optimisation
Élaboration d'un plan
Exécution du plan
Plan d'Accès EXECUTEUR Méthodes d'accès
Contrôle de concurrence
Atomicité des transactions

BD

Conception de BD
RK 16
 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 17
 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
• … les « Data WareHousing »!

Conception de BD
RK 18
II. Les Systèmes de Fichiers et les SGBDs

Conception de BD
RK 19
 II. 1. Introduction aux fichiers (1)

SGBD
Demande Enregistrement
d’enregistrement mémoire
mémoire retourné

Gestionnaire
de Fichiers
Demande Page
de page
mémoire
mémoire
retournée ?
Gestionnaire
de disque
Opération Données
d’entrée/sortie lues sur
sur disque le disque

BD

Conception de BD
RK 20
 II. 1. Introduction aux fichiers (2)

• Fichier
 Notion introduite dans les années 1950s afin de simplifier l’utilisation des
mémoires secondaires des ordinateurs, fournir des récipients de données plus
manipulables aux programmes.
• Système d’exploitation : contient un SGF standard.
• SGBD : deux niveaux indépendants (logique et physique)
 Traiter et conserver des quantités importantes de données, et de partager ces
données entre plusieurs programmes.
 En général, n’utilise pas le système de fichiers standard pour des raisons de
performance;
Basé au niveau interne des SGBD, complété par des méthodes d’accès
spécifiques.
 offre d'autres fonctionnalités :
 concurrence, reprise sur pannes, confidentialité…

Conception de BD
RK 21
 II. 1. Introduction aux fichiers (3)

• Système de fichiers propre au SGBD pour quelles données

 Données

 Informations (afin de gérer les données)

 sur le schéma logique

 structure des données, autorisation,…

Information sur le schéma physique

 Metabase

 statistiques

Conception de BD
RK 22
 II.3. Notions de base sur les fichiers et SGF (1)

• Fichier (file) = ensemble d'informations stockées sur une mémoire secondaire (MS),
structurées en enregistrements.
– Pourquoi sur MS? La mémoire centrale (MC) est limitée en taille, chère, et volatile
(à conserver toujours sous tension, sinon perte des informations).
– Les MS (disques, disquettes, ...) sont peu coûteuses, non volatiles et de grande
capacité. Mais elles ne sont pas accessibles par le processeur central des ordinateurs.
Il faut transférer l'information de la MS vers la MC pour pouvoir la traiter
• Problèmes:
– Les transferts entre MC et MS (appelés entrées-sorties ou E/S) sont lents
(millisecondes –10-3).

Conception de BD
RK 23
 II.3. Notions de base sur les fichiers et SGF (2)

• Enregistrement (article, record) = élément d'un fichier, qui est l'unité logique de
transfert MC-MS, et l'unité de traitement des programmes exploitant ce fichier.
 Unité de transfert avec la mémoire secondaire : Blocs (taille fixe)
 Plusieurs blocs forment un segment
• Format des enregistrements du fichier = description de la liste des données (attributs,
champs, data items, attributes, fields) contenues dans chaque enregistrement.
 Les champs sont de types élémentaires (entier, caractère, pointeur,…)(nom, âge,
adresse)
 Exemple: format pour un fichier d'étudiants:
nom prénom n°carte datenaissance sexe adresse téléphone section année
15c 10c e8 date 1c 100c e8 15c e4

• RK
Conception de BD
24
 II.3. Notions de base sur les fichiers et SGF (3)
• Fonctions d'un système de fichiers (SGF):
– Fonctions élémentaires (enregistrement)
• ajouter/insérer/chercher/mettre à jour/supprimer
– Fonctions globales (fichier):
• créer/détruire/lister/trier/copier/fusionner deux fichiers,...
– Gestion
• De la protection contre les pannes;
• de la confidentialité des fichiers;
• de la concurrence (partage simultané des fichiers).
• Les appels aux fonctions SGF sont effectués au moyen de requêtes dans un programme.
– Les requêtes permettent de modifier le contenu des fichiers
• Les SGBD permettent d'effectuer ce qu'offrent les SGF sous une autre forme, beaucoup
plus puissante (traitements plus globaux), ainsi que d'autres fonctions (gestion des
données et non d'enregistrements, liens entre fichiers, ...).
• Des produits à mi-chemin entre SGF et SGBD existent sur le marché (e. g. dBASE).

Conception de BD
RK 25
 II.5. Organisations et méthodes d'accès

• Comment sont organisés les enregistrements sur disque --organisation de fichiers.

➢ Selon l’allocation de l’espace disque qu’utilise les SGF
 Organisation séquentielle: les enregistrements d’un même fichier sont contigus.

 Organisation séquentielle chaînée: les enregistrements d’un même fichier sont

chaînés entre eux.
• Une méthode d'accès est une façon d'accéder à un enregistrement dans un fichier.
➢ Selon la valeur d'un attribut de l'enregistrement.

 2 méthodes d’accès: l'accès séquentiel et l'accès sélectif

 Choix de la meilleure méthode d’accès

• Les organisations et accès des SGF adaptés.

Conception de BD
RK 26
 II.5.1 Organisation Séquentielle

• Consiste à mettre les enregistrements dans le fichier les uns après les autres selon leur
ordre d'arrivée (de création), sans mémoriser l'endroit où ils ont été écrits.
– Ne permet que l'accès séquentiel.
– Elle est efficace dans les cas où les traitements nécessitent de lire ou d'écrire tous les
(ou une grande partie des) enregistrements du fichier.
• Le blocage d’enregistrements:
– 1 bloc = n enregistrements
– Lorsque plusieurs enregistrements sont transférés ensemble lors d’un échange, on
dit qu’ils sont bloqués.
– Le facteur de blocage est le nombre n d’enregistrements par bloc.
• Calculé de manière à occuper au mieux les blocs physiques
• Dans l'organisation séquentielle sans blocage, chaque enregistrement occupe un bloc
physique et nécessite une E/S pour être lu ou écrit.

Conception de BD
RK 27
 II.5.1 Organisation Séquentielle (suite)
• Fichier Séquentiel (interface)
– lire premier
– lire suivant
– écrire
– supprimer
• Avantages de l'organisation séquentielle avec blocage:
– excellente organisation pour l'accès séquentiel : 1/b E/S par
instruction en moyenne (on ne peut pas faire mieux)
– très bonne utilisation des MS
• Inconvénients:
– Impossibilité d'insérer ou de supprimer un article (sauf recopie de
tout le fichier)
– pas d'accès sélectif

Conception de BD
RK 28
 II.5.2. Organisation Aléatoire (1)

• Organisation séquentielle + format fixe des enregistrements

• Organisation relative:

– Les enregistrements ont des numéros relatifs (1, 2, 3, ...), appelés clés, qui est
leur numéro d'ordre dans le fichier.

• #enregistrement → adresse
• L'adresse relative dans le fichier de l'enregistrement de numéro i est :

(i-1)*longueur de l'enregistrement.

– Méthodes d'accès: sélective sur le numéro et éventuellement séquentiellement.

– Avantage: très bonne en accès sélectif (1 E/S par lecture)

Conception de BD
RK 29
 II.5.2. Organisation aléatoire (2)

• Le fichier est constitué de blocs qui contiennent les enregistrements.

• Chaque enregistrement possède un attribut (ou liste d'attributs) qui identifie

l'enregistrement, et qui est appelé clé de l'enregistrement.

• Une fonction est associée au fichier : n°bloc = f(clé).

– Exemple : modulo le nombre total de blocs du fichier

• Avantage: accès direct aux blocs en temps constant

• Inconvénient: Extension d’un fichier

– Nécessité/connaissance de la taille du fichier, ou le déplacement du fichier lors de

son extension

Conception de BD
RK 30
 Le Hachage

• Fichier à N enregistrements
• Table T de N pointeurs vers les blocs de données
• Fonction mathématique H
– H : domaine de la clé → [0..N-1]
– Un enregistrement de clé K se trouve dans le bloc pointé par T[H(K)]
• Accès direct au bloc
• Statique/dynamique (moins utilisé)
– Dynamique: selon le nombre d’enregistrements, la taille de T est 1, 2, 4, 8, …, 2N
• Gain de place
• Collision possible

0
1
Ki H(Ki)
2
3
T
Conception de BD
RK 31
 Techniques de débordement de blocs

• Il y a plusieurs solutions pour le choix d'un nouveau bloc de débordement à associer à

un bloc qui déborde:

– bloc(s) suivant. Il faut alors noter la liste des blocs de débordement dans l'en-tête
du bloc, ou chaîner les enregistrements ayant débordé;

– blocs de débordement spéciaux. On chaîne les blocs de débordement au bloc qui

déborde;

– seconde fonction pour les débordements. On note si le bloc a débordé. Cette

solution a l'avantage de répartir les gros débordements, mais elle multiplie les
déplacements des têtes de lecture/écriture.

Conception de BD
RK 32
 Organisation aléatoire (suite)

• Avantages:

– La clé peut être quelconque.

– S'il n'y a pas de débordement, très bonnes performances: 1 E/S par lecture.

• Inconvénients:

– S'il y a de nombreux débordements, les performances se dégradent.

– Le taux de remplissage est faible (environ 75%).

– Taille fixe du fichier (recherches sur le hachage).

– L'accès séquentiel selon l'ordre des clés impossible.

Conception de BD
RK 33
 II.5.3. Organisation indexées (1)
• Supposant qu’on a :
– Le fichier est trié suivant une clé
– Les enregistrements sont chaînés à l’aide de pointeurs
• Insertion
– Il y a de la place dans un même bloc que l’enregistrement précédent:
l’enregistrement à insérer est dans l'ordre de la clé
– dans un autre bloc en cas d'absence de place
• Suppression
– simple si on ne cherche pas à compacter
• Problèmes
1. Les mises à jour sont rapidement compliquées
2. Ne marche bien que si la taille du fichier est à peu près connue.
3. ACCESTROP LENTS  INDEX (le plus courant)
Fichier de données + table d’index
Conception de BD
RK 34
 Index

• Index : Structure de données permettant d’accélérer certains accès

– Deux champs: la clé d’index et l’adresse du bloc de données contenant la clé.
• NB: la clé est la valeur de un ou plusieurs attributs du fichier
• Index dense :
Index dans lequel chaque valeur de la clé est représentée
(nécessaire quand le fichier n’est pas trié)
nombre d'entrées dans l'index = nombre d‘enregistrements
• Index non-dense
– un index non dense impose un fichier trié
DENSITE / EFFICACITE / ESPACE /
• Solution : index non dense avec une entrée par bloc
– Mise à jour de la base
– Mise à jour des index
Conception de BD
RK 35
 Les opérations sur les index

Recherche : parcours de l’index + une lecture

Insertion

• index dense : insérer la clé dans l’index si elle n'y est pas

• index non dense : pas de changement dans l'index si l'insertion est réalisée dans un

bloc existant. Sinon, insérer la première clé du nouveau bloc dans l’index.

Suppression

• dense : détruire la clé dans l'index

• non dense : la plupart du temps pas de changement

Conception de BD
RK 36
 Index dense --Exemple

Fichier avec un index trié dense (i.e., toutes les clés existantes y sont répertoriées)

Conception de BD
RK 37
 Index hiérarchisé --Exemple

Fichier avec un index hiérarchisé à deux niveaux; les blocs d'index contiennent 4 clés,
les blocs d'enregistrements 3 enregistrements. La recherche d'une clé coûte 2 E/S.

Index

Niveau des enregistrements

Conception de BD
RK 38
 Coût de recherche dans un index

• Recherche rapide d'une entrée de l'index dont on connaît la clé.

• Index comprenant n blocs (chaque bloc contenant c clés, c étant généralement
compris entre 10 à 100 selon la longueur des clés)
• La recherche nécessite :
– si l'index est non trié: n/2 lectures en moyenne
– si l'index est trié et la recherche dichotomique: log2(n) lectures en moyenne
– si on indexe les blocs d'index (l'index est trié et hiérarchisé à plusieurs niveaux)
une E/S par niveau de l'index.
– Cette dernière solution est retenue dès que l'index est trop grand pour tenir en
MC, car la plus efficace.

Conception de BD
RK 39
 Autres Index
✓ 1. Index primaire
Sur un attribut clé : un enregistrement au plus pour chaque valeur de la clé
• 2. Index secondaire
Sur un attribut non clé (en général dense)
• 3. Index croisé sur un ensemble d’attributs
Fichier inverse indexé sur tous ses attributs
• 4. Quand l’index grossit (e.g. index dense) → stocker l’index dans un
fichier
– On peut le trier et indexer lui-même.
– Dans chaque bloc, on note la clé la plus petite, et on construit une table.
– Le fichier d’index est stocké, comme les enregistrements, sur mémoire
secondaire, et il est découpé en blocs qui constituent l'unité de lecture et
d'écriture.
 Idée des B-tree
Conception de BD
RK 40
 Les index secondaires

• Objectif: permettre l'accès par plusieurs attributs (ou groupes d'attributs) différents

et qui ne sont pas nécessairement identifiants.

• Par exemple sur un fichier Etudiant, accéder par le numéro de carte, par le nom

(homonymes possibles), par l'année de naissance, ...

• Le fichier a une organisation quelconque.

• Pour chaque attribut (ou groupe d'attributs), appelé clé secondaire, on crée un index.

Ces index sont appelés index secondaires ou fichiers inversés.

Conception de BD
RK 41
 Index secondaire --Exemple

Conception de BD
RK 42
• Avantage des index secondaires:
– Plusieurs accès sélectifs selon des attributs différentes possibles, en plus des accès dus à
l'organisation de base du fichier.
• Inconvénients:
– Multiplier les index secondaires multiplie les E/S lors des mises à jour des fichiers.
• Il n'est intéressant de faire un index sur une clé que si:
– le nombre d'accès en lecture sur cette clé est très supérieur au nombre de mises à jour
(suppressions, insertions, modifications de l'attribut clé secondaire) d'enregistrements
– la valeur de la clé est stable (rarement modifiée)
– le "pouvoir sélectif", p, de la clé (nombre total de valeurs prises par la clé dans le
fichier) est supérieur au facteur de blocage des enregistrements. En effet, une
recherche séquentielle des enregistrements répondant au critère: attribut = valeur,
coûte: N/b E/S
• La même recherche via un index secondaire sur cet attribut coûte en moyenne: v
+ N/p E/S (v=nombre de niveaux de l'index)
• L'index est donc utile si: v + N/p < N/b et donc si: p>b .

Conception de BD
RK 43
 La famille B-tree
• B-tree
– Utilisée dans la plupart des SGBD commercialisés.
– Hiérarchie des index sous forme d’arbre équilibré (implantation dynamique).
• Structure de données de B-tree d’ordre n:
– Nœud interne: stocke l’information de l’index
• p-1 valeurs de clés et p pointeurs vers les sous-arbres, ⎾n/2˥ ≤ p ≤ n.
• K1 < K2 <…< Kp < … < Kn-1
• Sauf le nœud racine contient au moins 1 clé et deux pointeurs.

– Nœud feuille (pointe sur le fichier de données): p clés, ⎾n/2˥ ≤ p ≤ n.

– Tous les nœuds feuilles sont au même niveau.
– Chaque nœud (index/données) correspond à un bloc disque.

Conception de BD
RK 44
 La famille B-tree

aux clés K < K1 aux clés

aux clés
Soit K ≥ Kn-1
soit K1≤ K <K2
soit K > Kn-1
soit K1< K <K2

• N.B.
– B-tree stocke aussi les pointeurs vers les enregistrements

Conception de BD
RK 45
 Exemple de B-tree
B1 o 25 o 144 o

B2 o 9 o - o B3 o 64 o 100 o B4 o 196 o - o

1 4 - 9 16 - 25 36 49 64 81 - 100 121 - 144 169 - 196 225 256

B5 B6 B7 B8 B9 B10 B11
ARBRE-B INITIAL

B15 o 64 o - o APRES L’INSERTION de 32.

B1 o 25 o - o B14 o 144 o - o

B2 o 9 o - o B3 o 36 o - o B13 o 100 o - o B4 o 196 o - o

1 4 - 9 16 - 25 32 - 36 49 - 64 81 - 100121 - 144169 - 196225

B5 B6 B7 B12 B8 B9 B10 B11
Conception de BD
RK 46
 Exemple de B-tree (suite)

B14 o 25 o 81 o

B2 o 9 o - o B3 o 36 o - o B13 o 144 o 196 o

4 - 9 16 - 25 32 - 36 49 - 81 100 121 144 169 - 196 225 256

B5 B6 B7 B12 B8 B10 B11

APRES SUPPRESSION de 64

Conception de BD
RK 47
 B-tree: Insertion

Insertion d’un enregistrement dans un B-tree:

• Si le B-Tree est vide:
– Créer une racine de type feuille
– Y insérer l’enregistrement
• Sinon, rechercher la feuille l ou insérer l’enregistrement
– Si l n’est pas pleine
• Insérer l’enregistrement en préservant l’ordre
– Si l est pleine
• Créer une nouvelle feuille l’
• Repartir les enregistrement entre l et l’
• Remonter la clé au milieu vers le niveau supérieur
• retirer les mêmes étapes pour les niveaux supérieurs
• Si on remonte jusqu’à la racine, on la divise en deux et on crée une nouvelle
racine avec deux successeurs

Conception de BD
RK 48
 B-Tree: Suppression

Effacement d’un enregistrement de clé k d’un B-tree

• Si le B-tree n’est pas vide
• Soit l la feuille contenant l’enregistrement à supprimer, après avoir
supprimer 3 cas peuvent se présenter
1. La feuille l est la racine et elle est devenue vide. On supprime cette feuille et le
b-tree devient vide
2. La feuille l comprend au moins n/2 +1. Si la clé k apparaît dans un noeud
d’index, mettre l’index à jour
3. La feuille l ne contient que n/2 . Réorganiser les enregistrements de l et ceux
d’une feuille voisine l’ d’une des deux manières suivantes:
1. Si l’ a plus de n/2 enregistrements distribuer équitablement les enregistrement entre
l et l’
2. Si l’ a exactement n/2 enregistrements fusionner les éléments de l et l’ et supprimer
la feuille devenue vide
3. Propager cette mise a jour en remontant vers la racine. Si on l’arrive a la racine du B-
tree et celle ci ne comporte plus qu’un sous arbre supprimer la racine, le B-tree se
réduisant à ce successeur unique.

Conception de BD
RK 49
 Les méthodes d’accès --Résumé

• Comment accéder aux emplacements des enregistrements?

• Quelques méthodes d’accès:
– Séquentielle si organisation séquentielle
– Séquentielle chaînée si séquentielle indexée
– Calculée si organisation aléatoire
– Relative si organisation relative
– Directe si adresse physique connue
– Indirecte si 1er accès donne adresse du second
• Un SGF gère quelques méthodes
• Ces méthodes sont parfois particulières au SGF
• Elles dépendent des organisations de fichiers

Conception de BD
RK 50
 Conclusion
• Contrairement au SGF, avec un SGBD:
– l’organisation interne des données est transparente
– les applications manipulent des structures de données logiques
 indépendance logique/physique
• Chaque SGBD a son propre SGF avec ses caractéristiques:
– Les fichiers sont souvent de taille fixe
– des organisations et des accès appropriés
• méthode indexée (données + index avec clé): la plus courante
implantations différentes selon le SGBD
– Arbre-B les plus utilisés dans les SGBD
• Hachage statique très utilisé

Conception de BD
RK 51
 III. Les principaux modèles de données

1. Introduction

2. Le modèle hiérarchique

3. Le modèle réseau

4. Le modèle Entité-Association

5. Le modèle relationnel

Conception de BD
RK 52
 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 53
 III.2. Modèle Hiérarchique

III.2.1 Principes
• Modèle hiérarchique (1960)
• Schéma de base arborescent dans lequel les relations entre les éléments d’un niveau à ceux
du niveau immédiatement inférieur sont de type un à « plusieurs ».
• Il permet une représentation approchée du réel au prix d’une redondance plus ou forte
des données.
• Il impose un chemin d’accès unique à chaque élément de données (depuis la racine).
• Inconvénient majeur: pas de séparation nette entre le niveau conceptuel (la
représentation du monde) et le niveau physique (c-à-d l’indépendance entre données et
traitements n’est pas réalisée).
Conception de BD
RK 54
 III.2.1 Principes (suite)

• Concepts du modèle hiérarchique

 Champ (field): plus petite unité de données possédant un nom.

 Segment: collection de champs rangés consécutivement dans la base, portant un

nom.

 une occurrence constitue l’unité d’échange entre la BD et les applications

 Arbre de segments (segment tree): collection de segments reliés par des

associations père-fils sous la forme d’hiérarchie.

 Base de données hiérarchique: BD constituée par une forêt de segments.

Conception de BD
RK 55
 III.2.2 Caractéristiques du modèle

• Permet aux type de segments d’être reliés par des relations parents-
enfants (1:n) Enseignant
1
n

Etudiant

• Les structures qui traduisent ces éléments sont fonction du type de

requêtes à réaliser:

Etudiant Enseignant cours Enseignant Cours

Cours Cours Enseignant

Cours Etudiant Enseignant Etudiant
Enseignant Etudiant Etudiant

Conception de BD
RK 56
 III.2.3 Limitations du modèle

• Difficulté d’exprimer des relations de type n:m

Enseignant Enseignant Etudiant

n
m
Etudiant Etudiant Enseignant

• Une modification de l’utilisation peut entraîner une perte d’efficience du système.

• Un espace de stockage très important.
• L’impossibilité d’exprimer des parents multiples
• la difficulté d’exprimer des relation cyclique

Conception de BD
RK 57
 III.2.4 Avantages du modèle

• Les BDs modélisent des informations du monde réel

 Souvent au travers des hiérarchies.

 Plusieurs applications nécessitent uniquement des relations de type 1:n

• le modèle hiérarchique est conceptuellement simple à comprendre et à utiliser.

• Le premier support d’IBM qui a introduit le premier système hiérarchique appelé IMS.

Conception de BD
RK 58
 Exemple

Conception de BD
RK 59
 Exemple

Conception de BD
RK 60
 Ordre de visite dans l’arbre

1. Visite l’enregistrement
s’il n’a pas été visité
1
2. Sinon, visite l’enfant le
plus à gauche, non visité
3. Sinon, si aucun enfant, 2
grand-enfant, etc. 6 8 9
n’existe, revient à
l’enregistrement parent 3 4 5 7

Conception de BD
RK 61
 III.2.5 Système IMS

• IMS (Information Management System) d’IBM, est l’un des principaux

SGBD disponible.

• Développé par IBM et North American Aviation pour la gestion des

informations du programme Appolo dans les années 1960s.

• Un système DB-DC ( Data Base and Data Communication)

Conception de BD
RK 62
 Architecture IMS (1)

• Un schéma se compose de un ou plusieurs BD Physiques

interconnectées.

• Chaque BD, P, est décrite dans une description de BD (DBD )

• Un bloc de contrôle de programmes (PCB):

– Structure de données permettant de mémoriser des positionnements sur la BD
(c-à-d un sous ensemble de la DBD).

• L’ensemble des PCB pour un user ou un programme d’application est

un PSB (utilisé par un seul programme)

Conception de BD
RK 63
 Architecture IMS (2)

Zone entrée sortie Prog App1 Prog App2 Zone entrée sortie

PSB A PSB B
PCB A1 PCB A2 PCB B1 PCB B2

BD L BDL
BD P BDP

Organisation physique
des données et chemin d’accès

Supports de
stockage
Conception de BD
RK 64
 Architecture IMS (3)

• Les programmes écrits en COBOL, PL/1 ou autres communiquent avec la BD IMS

par l’intermédiaire du LMD (DL1).

 Langage très complexe!!

• DL1 est le langage pour l’accès aux données et leur manipulation

• Le transfert de données entre IMS et les programmes d’applications se fait par les

zones d’entrées/sorties

Conception de BD
RK 65
 La base de données physique

• Composée d’une structure hiérarchique arborescente formée de type de

segments, un segment se compose d’un nombre arbitraire de champs.

• Toutes les occurrences d’un type de segment qui ont le même parent
sont appelées « jumeaux ».

• « frères » désigne les types de segments situés à un même niveau

• Il y a une relation 1:N entre un segment-parent et chacun de ses

segments-enfants.

Conception de BD
RK 66
 Description de la BD physique
DBD NAME=PROFESSEURDB
SEGM NAME=PROFESSEUR, BYTE=25
FIELD NAME=(PROFNOM,SEQ),BYTES=15 START 1 ProfNom Specialité Annxp Professeur
FIELD NAME=SPECIALITE,BYTES=8 START 16
FIELD NAME=ANNXP,BYTES=2 START 24
SEGM NAME=UNIVERSITE, BYTE=40,PARENT=PROFESSEUR Université Étudiant
FIELD NAME=(UNIVNOM,SEQ),BYTES=15 START 1 UnivNom Adr EtudMat EtudNom AdrEt
FIELD NAME=ADRESSE,BYTES=25 START 16
SEGM NAME=ETUDIANT, BYTE=44 , PARENT=PROFESSEUR
FIELD NAME=(ETUDMAT,SEQ),BYTES=4 START 1
FIELD NAME=ETUDNOM,BYTES=15 START 5
FIELD NAME=ADRET,BYTES=1525 START 20 cours
SEGM NAME=COURS, BYTE=18,PARENT=ETUDIANT CourDes Semestre Niv
FIELD NAME=(COURSDES,M),BYTES=15 START 1
FIELD NAME=SEMESTRE,BYTES=1 START 16
FIELD NAME=NIV,BYTES=2 START 17
DBDGEN
FINISH
END
Conception de BD
RK 67
 Les sous-schémas PCB et PSB

• Un sous-schéma est un sous ensemble logique cohérent de la

description de la BD.
• Un ensemble de PCB est stocké dans une librairie, appelée PSB.
• Un PCB est un sous ensemble de la structure hiérarchique des
segments.
• Un PCB est un sous arbre de la DBD.
• Un nombre quelconque de programmes peuvent utiliser le même PCB
par l’intermédiaire de PSB différents.

Conception de BD
RK 68
 Exemple
PCB TYPE = DB, DBNAME = PROFESSEURDB, KEYLEN = 34
SENSEG NAME = PROFESSEUR, PROCOPT = G
SENSEG NAME = ETUDIANT, PARENT = PROFESSEUR, PROCOPT= I
SENSEG NAME = COURS, PARENT = ETUDIANT, PROCOPT = GIR
PSBGEN LANG = COBOL, PSBNAME = SOUSPROF.
Professeur

ProfNOM Specialité Annxp

Étudiant

EtudMAt EtudNom AdrEt

Cours

CoursDes Semestre Niv

Conception de BD
RK 69
 La manipulation des données: DL1
• Langage procédural d’accès aux données

 Langage de manipulation navigationnel.

• Transfert des données et communication par une zone entrée sortie:

 Le nom de la PSB , on en déduit les PCB
 Le numéro de niveau hiérarchique du dernier segment auquel on a accédé
 Un code ou statut indiquant le succès ou l’échec de la dernière commande DL1
 Un code de traitement indiquant les traitement qu’on peut effectuer sur le
segment atteint
 Le nom du dernier segment atteint
 La longueur de la clé hiérarchique du dernier segment atteint
 Le nombre de segments sensibles utilisés par le programme
 La valeur de la clé hiérarchique du dernier segment atteint

Conception de BD
RK 70
 Les commandes DL1
Recherche directe (1ère occurrence) GET UNIQUE (GU)
Recherche l’occurrence du segment suivant
celle mémorisée dans le PCB (parcours
GET NEXT (GN)
séquentiel de haut en bas puis de gauche à
droite)
Recherche à l’intérieur des descendants du
GET NEXT WITHIN PARENT (GNP)
segment courant
Mêmes opérations que les 3 premières GET HOLD UNIQUE (GHU)
commandes mais permet de garder le GET HOLD NEXT (GHN)
segment en mémoire GET HOLD NEXT WITHIN PARENT (GHNP)
Mise à jour d’un segment REPLACE (REPL)
Insertion d’un nouveau segment INSERT (ISRT)
Destruction d’un segment DELETE (DLET)

Conception de BD
RK 71
 Les Méthodes d’accès aux données
• Les méthodes d’organisation des données utilisées par IMS:
– Organisation séquentielle hiérarchisée
• HSAM (Hierarchical Sequentiel Access Method)
– On accède séquentiellement aux segments, stockés selon l’ordre hiérarchique.
• HISAM (Hierarchical Idexed Sequentiel Access Method)
– Les segments-racines sont stockés dans un fichiers séquentiel indexé et pointe vers
leurs enfants auxquels on accède ensuite de façon séquentielle
– Organisation directe hiérarchisée
• HDAM (Hierarchical Direct Access Method)
– On accède aux segments racines par un algorithme d’adressage puis aux enfant par
une chaîne de pointeurs
» Chaîne enfant/jumeau
» Chaîne hiérarchique
• HIDAM (Hierarchical Idexed Direct Access Method)
– Les segments-racines sont stockés dans un fichier séquentiel indexé et pointent
vers leurs enfants qui sont reliés par une chaîne de pointeurs ( enfant/jumeau ou
hiérarchique)

Conception de BD
RK 72
 III. 3. Le Modèle Réseau

III.3.1 Principe
• Le modèle réseau apporte plus de souplesse car il permet de créer des liens logiques
entre des faits ou objets différents.
• L’accès aux données n’est pas limité aux chemins descendants/ascendants du modèle
hiérarchique, peut se faire de plusieurs façons différentes pour une même donnée.
• Article (Record): collection d’atomes (champs) –type d’articles
• Lien (Set): type d’association orientée entre articles propriétaires vers n articles
membres.
Conception de BD
RK 73
 III.3.2 Caractéristiques

• Les liens entre les articles sont de type 1:n et représentés par une flèche portant le nom
du lien.
• La différence majeure avec le modèle hiérarchique est la capacité du modèle réseau à
représenter les parents multiples d’un types d’articles.
• Exemple:

Compagnie Division

Dépôt Fournisseurs service

Pièces détachées
Employés

Conception de BD
RK 74
 III.3.2 Caractéristiques (suite)

• Le modèle réseau de base exclut les liens de type n:m.

– Seules sont permises les liens de type 1:n avec des parents multiples
provenant de différent types d’articles.

Fournisseurs Fournisseurs Pièces détachées

Pièces détachées Fournisseurs-Pièces

Conception de BD
RK 75
 En conclusion ….

• Le modèle réseau est une évolution logique du modèle hiérarchique.

• Il a permis d ’éliminer les redondances de données et la création de
chemin d ’accès multiples à une même donnée.
• Il est née des recherches du groupe Codasyl (Conference on Data
System Language) entre 64 et 71.
• Ne permet pas la prise en compte réelle des phénomènes les plus
complexes.
• Ne permet pas de résoudre le problème d ’indépendance entre
traitements et structures de données.

Conception de BD
RK 76
 LDD CODASYL

• Spécificités

– Types d'article

• structure complexe

• Clé

– Attributs

• Simple/complexe

• Mono/Multivalué

– Types de Set

• Binaires

Conception de BD
RK 77
 Schéma exemple

Conception de BD
RK 78
 Type d'article:

RECORD Hôpital,
……..
02 nom-hôpital TYPE CHARACTER 25,
02 adresse,
03 numéro TYPE INTEGER,
03 rue TYPE CHARACTER 25,
03 code postal TYPE INTEGER,
03 ville TYPE CHARACTER 25,
02 budget-99 TYPE REAL,
……..

Conception de BD
RK 79
 Attributs multivalués

RECORD consultation,
…….
02 prescription TYPE CHARACTER 30
OCCURS 10 TIMES,

RECORD service,
…….
02 nombre-infirmières TYPE INTEGER,
02 infirmière OCCURS nombre-infirmières TIMES,
03 nom TYPE CHARACTER 20,
03 qualification TYPE CHARACTER 50,

Conception de BD
RK 80
 Placement des articles

• Modélisation du schéma physique

• La base de données est partitionnée en zones nommées (AREAs)

AREA NAME IS F-Hop, F-Doc, F-Mal

• Le placement des occurrences d'articles se fait par type d'article, dans une zone

– placement direct (self-standing): dans la zone x

– placement indirect: en fonction du placement d'une autre occurrence

Conception de BD
RK 81
 Placement direct

RECORD Hôpital,
LOCATION MODE IS CALC VIA nom-hôpital DUPLICATES
ARE NOT ALLOWED
WITHIN F-Hop,
……..
• Placement direct par fonction de hachage sur un attribut
(organisation aléatoire)
• Placement dans l'AREA spécifiée

Conception de BD
RK 82
Placement indirect-1
RECORD Service,
LOCATION MODE IS VIA constitué WITHIN F-Hop,
……..
• placement indirect par proximité avec l'occurrence
propriétaire dans le set "constitué"
• placement dans la même AREA que le propriétaire

Conception de BD
RK 83
Placement Indirect 2

RECORD Docteur,
LOCATION MODE IS VIA emploie WITHIN F-Doc,
……..
• placement indirect par homothétie avec l'occurrence
propriétaire dans le set "emploi"
• placement dans une autre AREA que le propriétaire

Conception de BD
RK 84
 LDD

• SCHEMA NAME IS gestion-consultations.

• AREA NAME IS F-Hop, F-Doc, F-Mal.
___________________________________
RECORD NAME IS nom-type-d'article,
LOCATION MODE IS
– CALC USING nom-attribut [DUPLICATES NOT ALLOWED]
– VIA nom-set
WITHIN nom-area

• Attributs
• [ { numéro nom-att TYPE IS INTEGER
REAL
CHARACTER nb [OCCURS nbx
TIMES] … } ]

Conception de BD
RK 85
RECORD NAME IS Hôpital,
LOCATION MODE IS CALC USING
nom-hôpital DUPLICATES
NOT ALLOWED WITHIN F-Hop,
02 nom-hôpital TYPE CHARACTER
25,
02 adresse,
03 numéro TYPE INTEGER,
03 rue TYPE CHARACTER 25,
03 code postal TYPE INTEGER,
03 ville TYPE CHARACTER 25,
02 budget-99 TYPE REAL,
……..
Conception de BD
RK
RECORD NAME IS Service,
LOCATION MODE IS VIA constitué
WITHIN F-Hop,
02 nom-service TYPE CHARACTER 20,
02 nombre-lits TYPE INTEGER,
02 nom-chef TYPE CHARACTER 20,
02 nombre-infirmières TYPE INTEGER,
02 infirmière OCCURS nombre-
infirmières TIMES,
03 nom TYPE CHARACTER 20,
03 qualification TYPE CHARACTER 50,
……..
86
 RECORD NAME IS Docteur,
LOCATION MODE IS VIA emploie WITHIN F-Doc,
02 nom-docteur TYPE CHARACTER 20,
……..
RECORD NAME IS Malade,
LOCATION MODE IS CALC USING numéro-malade
WITHIN F-Mal,
02 numéro-malade TYPE CHARACTER 20,
02 nom-malade TYPE CHARACTER 20,
……..
RECORD NAME IS Consultation,
LOCATION MODE IS VIA passe WITHIN F-Mal,
02 date TYPE CHARACTER 8,
02 horaire TYPE CHARACTER 5,
02 prescription TYPE CHARACTER 30 OCCURS 10
TIMES,
……..
RK
Conception de BD
87
Placement

Conception de BD
RK 88
 Type de Set

SET NAME IS constitué,

OWNER IS Hôpital,
MEMBER IS Service,
INSERTION IS AUTOMATIC
RETENTION IS MANDATORY
SET SELECTION IS THRU constitué
OWNER IDENTIFIED BY CALC KEY

Conception de BD
RK 89
 Syntaxe

SET NAME IS nom-set,

OWNER IS nom-type-d'article-propriétaire,
MEMBER IS nom-type-d'article-membre.,
INSERTION IS AUTOMATIC/MANUAL
RETENTION IS MANDATORY/OPTIONAL
SET SELECTION IS THRU nom-setx OWNER
IDENTIFIED BY CALC KEY/APPLICATION
[ THEN THRU nom-sety WHERE OWNER
IDENTIFIED BY nom-att2 ]
ORDER IS INSERT FIRST /LAST /NEXT / PRIOR
SORTED BY{ ASC/DESC nom-att3 }... [ DUPLICATES NOT]
Conception de BD
RK 90
Type de set emploie

SET NAME IS emploie,

OWNER IS Service,
MEMBER IS Docteur,
INSERTION IS AUTOMATIC
RETENTION IS OPTIONAL
SET SELECTION IS THRU constitué OWNER IDENTIFIED BY
CALC KEY
THEN THRU emploie WHERE OWNER IDENTIFIED BY nomservice
ORDER IS INSERT SORTED BY ASC nom-docteur DUPLICATES
NOT

Conception de BD
RK 91
LMD CODASYL:Navigationnel

« Quel docteur le malade numéro 130 a-t-il consulté enjanvier 90? »

• En pseudo-Codasyl:

Chercher le malade n° 130

Récupérer la première consultation de ce malade dans le set « passe »
Tant qu ’il reste encore une consultation pour ce malade dans le set
" passe " faire:
Tester la date = Janvier 90
Si oui - Récupérer le docteur propriétaire de cette consultation dans le set
« donne »
- Afficher le docteur
Fin si
Passer à la consultation suivante pour ce malade dans le set « passe »
Fin tant que
Conception de BD
RK 92
 Principe de navigation

Pointeurs courants dans la base de données:

• Chaque instruction Codasyl fait positionner les pointeurs courants de la
base de données sur l’article accédé/mis à jour. L’instruction suivante
part du dernier pointeur courant.
• A chaque programme utilisateur sont associés différents pointeurs
courants:
• le pointeur courant du programme,
• un pointeur courant pour chaque type d ’article du sous-schéma (ou du
schéma) ouvert par le programme,
• un pointeur courant pour chaque type de set du sous-schéma (schéma)
ouvert par le programme.
Conception de BD
RK 93
Exemple d’évolution des pointeurs

RABTA

H. Militaire

Conception de BD
RK 94
 Exemple d’évolution des pointeurs

Pour le programme traitant la requête nom du chef du

service de chirurgie de l’hôpital Militaire, les pointeurs
évoluent de la façon suivante:

Pointeurs:
• Ouverture de la base
• Chercher ‘H.Militaire’
• Ouverture Chirurgie pour Militaire

Conception de BD
RK 95
Programme utilisateur/SGBD

Conception de BD
RK 96
 Accès sélectif aux articles d’organisation CALC

Exemple: recherche du malade numéro 130

Malade. Numéro malade : = 130
FIND ANY Malade
Le SGBD positionne les pointeurs programme, malade et passe
sur l’article 130 (s’il existe, sinon il y a un code d ’erreur "article
non trouvé" dans le SGBD-STATUS).
• Si le type article placé en CALC peut avoir des doublons de même valeur pour la clé:
attribut clé: = xx
FIND ANY nom-type-article
Tant que SGBD-STATUS = ok faire:
FIND DUPLICATE nom-type-article
….. Traitement de l ’article …..
Fin tant que
Conception de BD
RK 97
Balayage séquentiel d ’un type d ’article

Exemple: la liste de tous les docteurs

FIND FIRST nom-type-article
Tant que SGBD STATUS ≠"fin de type d ’article"
faire
traitement de l ’article…
FIND NEXT nom-type-article
Fin tant que.
NB: On peut aussi effectuer un balayage arrière:
FIND LAST FIND PRIOR.

Conception de BD
RK 98
 Balayage séquentiel des membres
d’un propriétaire
Exemple: Liste des consultations passées par le malade n° 130

Malade . Numéro-malade : = 130

FIND ANY Malade
Si SGBD-STATUS = "non trouvé alors (message;fin) finsi
FIND FIRST Consultation WITHIN passe
Tant que SGBD-STATUS = "ok" faire
Traitement de la consultation
FIND NEXT consultation WITHIN passe
Fintantque
…….
Conception de BD
RK 99
 Balayage séquentiel des membres
d’un propriétaire
• Suite: Evolution des pointeurs:
- après l ’exécution de l ’instruction 2, les pointeurs programme,
malade, et passe sont positionés sur le malade num éro 130 (s ’il
existe)
- après l ’exécution de l ’instruction 4, les pointeurs programme, consultation,
passe et donne sont positionés sur la 1 ère consultation du malade 130; le
pointeur malade ne bouge pas lors de l ’instruction 9, une fois exécuté le
dernier FIND NEXT, les pointeurs sont à nouveau sur le propriétaire du set,
c’est-à-dire sur le malade n° 130 (pointeur programme, malade, passe); le
pointeur consultation reste sur la dernière consultation du malade.

N.B. : comme pour un type d ’article, on peut aussi effectuer un balayage arrière.

Conception de BD
RK 100
 Remonter d ’un membre à son
propriétaire
• Exemple: Quels sont les médecins qui
ont ordonné du xxx au malade 130; on
veut les noms du médecin et de
l’hôpital.
Malade . Numéro-malade : = 130
FIND ANY Malade
Consultation. Prescription : = xxx
FIND consultation WITHIN CURRENT OF
passe USING
prescription.
Tant que SGBD-STATUS = "ok" faire
FIND OWNER WITHIN donne
/* positionne sur le docteur*/
Conception de BD
RK
• Suite:
GET docteur; Print docteur/* affiche le
docteur*/
FIND OWNER WITHIN emploie /*
positionne sur le service*/
FIND OWNER WITHIN constitué /*
positionne sur l ’hôpital */
GET HOPITAL ; Print Hpital/* affiche
l’hôpital */
FIND DUPLICATE WITHIN CURRENT
OF passe USING prescription
Fin tant que
Remarque: Pour pouvoir utiliser un FIND
sur un set (FIND….WITHIN nom-set),
il faut que le pointeur du set soit
initialisé.
101
 Repositionnement sur un article
accédé auparavant
• Les instructions de lecture et de mise à jour (autres que celle d’insertion d ’un
nouvel article) travaillent toutes sur l ’article référencé par le pointeur
programme. Il arrive que certains traitements nécessitent de lire ou de mettre à
jour un article qui ne soit pas le dernier accédé, et donc pas l ’article courant
du programme. Pour pouvoir repositionner les pointeurs sur cet article,
Codasyl offre deux solutions:
"FIND CURRENT nom-type-article"
accède à l ’article référencé par le pointeur du type d ’article et (repositionne dons
les pointeurs programme et sets) ;
- mémorisation et mise à jour directement par le programme
utilisateur des pointeurs:
nom-variable:=CURRENT OF nom-type-article
/*met dans la variable (non accessible au programme) la
valeur du pointeur du type d ’article */
FIND nom-type-article BY DATABASEKEY nom-variable
/* accède à l ’article référencé par la valeur contenue dans la variable, et met donc
à jour les pointeurs programme, type d ’article et types de set */
Conception de BD
RK 102
 Lire un article: GET
L ’instruction FIND positionne les pointeurs, mais ne lit pas! Les lectures se font
par l ’instruction: "GET nom-type-article" qui lit l ’article courant du
programme (le dernier accédé par un "FIND").

Insérer un article : STORE

"STORE nom-type-article" ==> :
1) Dans quel fichier est ce type d ’article, et avec quelle organisation ? ==> calcul
de l ’adresse de la page où écrire l ’article (si Calc : formule de calcul ; si Via
recherche du propriétaire).
2) De quels types de sets l ’article est-il propriétaire?
==>initialisation ces sets à vide (en général par un pointeur pointant l’article
lui-même).
3) De quels types de sets l ’article est-il membre avec insertion automatique?
.==> recherche de l ’occurrence définie par la SET SELECTION et insertion
de l ’article selon l’ordre du set (clause OD"RDER…: mise à jour des
chaînages de ces sets pour y insérer le nouveau membre en bonne place).
Paramètres du STORE (mis par l ’utilisateur dans la zone de communication
SGBD-utilisateur): les valeurs des attributs de l ’article à écrire, et de tous les
attributs qui servent aux SET SELECTION Des sets dont l ’article est déclaré
membre à INSERTION AUTOMATIQUE, et aux clauses ORDER … .
Conception de BD
RK 103
 Insérer un article STORE

Exemple: insérer le docteur <Foulen,…..> pour le

service de cardiologie de l ’hôpital RABTA:
Hôpital. nom-hopital : = « RABTA" */paramètre/*
Service. nom-service : = "Cardiologie"
*/paramètre/*
Docteur. nom-docteur := " Foulen" ;
Docteur. Catégorie : = …… */valeur de l ’article/*
STORE docteur

Conception de BD
RK 104
Rattacher (détacher) un article membre à son
propriétaire

CONNECT nom-type-article TO nom-type-set

INSERTION MANUAL ou/et RETENTION
OPTIONAL.
Le propriétaire est choisi selon la SET SELECTION
définie pour ceset dans le schéma.
DISCONNECT nom-type-article FROM nom-
type-set
RETENTION OPTIONAL.

Conception de BD
RK 105
Rattacher (détacher) un article membre à son
propriétaire

Exemple: Changer un docteur de service: Foulen du service

chirurgie de RABTA passe au service des urgences.
Hôpital . Nom-hopital := RABTA ;
Service. Nom-service := chirurgie ;
Docteur. Nom-docteur := Foulen ;
FIND ANY HOPITAL ;
FIND Service WITHIN CURRENT OF Constitué USING nom--service;
FIND Docteur WITHIN CURRENT OF Emploie USING nom-docteur ;
/* le docteur voulu est pointé par le pointeur courant programme */
DISCONNECT Docteur FROM Emploie ;
/* détache l ’article courant du set emploie de "chirurgie" */
Service. nom-service : = urgences ;
CONNECT Docteur TO Emploie ;
/* rattache le docteur au set emploie des urgences*/

Conception de BD
RK 106
 Supprimer un article : ERASE

ERASE nom-type-article:
supprime l ’article courant programme, et:
- si l ’article est membre dans un set, décroche cet article du set avant de supprimer l ’article,
- si l ’article est le propriétaire d ’un set non vide: problème !
Solution 1 :
Selon la clause RETENTION :
- Si le set a pour clause "RETENTION OPTIONAL" les Membres sont détachés,
- Si le set a pour clause "RETENTION MANDATORY« L ’instruction ERASE est refusée.
Solution 2 :
Une clause facultative est ajoutée à l ’instruction ERASE :
ERASE nom-type-article [ALL MEMBERS]
- Si la clause "ALL MEMBERS" est présente, l ’instruction ERASE est récursive : elle
détruit l ’article et tous ses articles membres et leurs articles membres et…..

- Si la clause "ALL MEMBERS" n ’est pas présente, et si l ’article à détruire est propriétaire
de set (s) non vide (s), l ’instruction ERASE est refusée.

Conception de BD
RK 107
 Supprimer un article : ERASE

Le positionnement des pointeurs après une instruction ERASE se

fait de la façon suivante:
- pointeurs programme, type d ’article et des types de sets
passant par ce type d ’article mis à nul (Ø),
- afin de permettre au programme utilisateur de continuer son
exécution en balayant le type d ’article ou le set, le SGBD
conserve, pour le type d ’article et pour les sets dont l ’article
était effectivement membre, deux valeurs : la référence des
articles précédant et suivant l ’article supprimé. Les instructions
FIND NEXT/PRIOR… peuvent donc être utilisées après un
ERASE.

Conception de BD
RK 108
 Modifier les valeurs des attributs
d’un article :MODIFY

L ’instruction "MODIFY nom-type-article" réécrit

l’article courant programme en prenant sa valeur
dans la zone de communication.
Il est interdit de mettre à jour l ’attribut clé du
CALC, mais il est possible de mettre à jour les
attributs de tri des membres d ’un set
(dans ce cas il y a mise à jour du chaînage du set par
le SGBD).

Conception de BD
RK 109
Ouverture/fermeture de la BD et de
ses fichiers

L ’instruction "INVOKE nom_schéma (ou nom

sous-schéma)« ouvre la base de données ou un
sous-schéma de la base de données et initialise la
zone de communication utilisateur-SGBD.
Les instructions "READY/FINISH nom_fichier" ….
ouvrent/ferment le (s) fichier (s), et initialisent les
tables du SGBD (mise des pointeurs à nul).

Conception de BD
RK 110
 LMD CODASYL

LANGAGE DE MANIPULATION DES DONNEES (simplifié)

INVOKE nom-schéma
nom-sous-schéma WITHIN nom-schéma
READY {nom-area}…. .
FINISH {nom-area}…. .
FIRST
FIND ANY nom-article . FIND NEXT nom-article .
DUPLICATE PRIOR
LAST
FIRST
NEXT
FIND PRIOR nom-article WITHIN nom-set .
LAST

Conception de BD
RK 111
 LMD Suite

FIND OWNER WITHIN nom-set

FIND nom-article WITHIN [CURRENT OF] nom-set USING Att.
DUPLICATE
FIND CURRENT nom-article .
FIND CURRENT nom-set .
GET nom-article .
STORE nom-article .
MODIFY nom-article .
ERASE nom-article [ALL MEMBERS] .

Conception de BD
RK 112
 LMD Suite

CONNECT nom-article TO nom-set .

DISCONNECT nom-article FROM nom-set .

Variable contenant la réponse du SGBD: SGBD-STATUS, de

valeurs possibles: OK, erreur d ’argument, début/fin de type
d ’article, pas trouvé, type de set/type d ’article non initialisé,
set vide, article non rattaché au set, c ’est le propriétaire du
set, fichier saturé, erreur d ’E/S, ….

Conception de BD
RK 113
 En conclusion ….

• Modèles très performants car très proches du niveau physique.

• Le modèle réseau est une évolution logique du modèle hiérarchique.
– Il a permis d’éliminer les redondances de données et la création de chemin d’accès multiples
à une même donnée.
– Il est née des recherches du groupe Codasyl (Conference on Data System Language) entre
les années 1964 et 1971.
• Il ne permet pas la prise en compte réelle des phénomènes les plus complexes.
• Ne permet pas de résoudre le problème d’indépendance entre traitements et
structures de données.

Conception de BD
RK 114
 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 115
 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 116
 Ali Khaled
Jamel

Salem Kamel

modélisé par

Personne

Personne Achète Maison

Acheté
Acheteur
(Rôles)

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

Mari
• Unaire: 1

Personne Marié

1 femme

• Binaire: Enseignant donne Cours

Conception de BD
RK 118
 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 119
 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 120
 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 121
 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 122
 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 123
 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 124
 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 125
 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 126
 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 127
 Conception de BD
RK 128
 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 129
 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 130
 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 131
 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 132
 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 133
 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 134
 Exemple

Cinéma

1:n

1:1

Salle

Conception de BD
RK 135
 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 136
 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 137
 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 138
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 139
 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 140
 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 141
 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 142
 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 143
 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 144
 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 145
 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 146
 Diagramme des Liens

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

Suit N°Etud NomC

Conception de BD
RK 147
 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 148
 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 149
 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 150
 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 151
 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 152
 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 153
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 154
 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 155
 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 156
 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 157
 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 158
 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 159
 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 160
 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 161
 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 162
 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 163
 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 164
 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 165
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 167
 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 168
 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 169
• 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 170
• 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 171
• 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 172
 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 173
 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 174
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 175
 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 176
 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 177
 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 178
 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 179
 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 180
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 181
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 182
 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 183