Cours Base de Données

PROGRAMME DE BASE DE DONNEES
Chapitre I : Concepts de Système d’Information

1. Système d’Information
2. Information / Données
Chapitre II : Concepts de Base de données

1. Introduction
2. Définition d’une Base de données
3. Les fondements des Bases de données
4. Propriétés des Bases de données
5. Le Système de Gestion des Bases de Données (SGBD)
6. Processus de conception d’une Base de données
7. Les concepts associés aux Bases de données
8. Exemples de Bases de données
9. Conception du Modèle Conceptuel des Données (MCD)
10. Modèle Logique des Données (MLD)
11. Modèle Physique des Données (MPD)
Chapitre III : Etude des Bases de données relationnelles

1. Présentation
2. Le modèle relationnel
3. Présentation des composants d’une Base de données relationnelle
4. Opérations de Mise à Jour (MAJ)
5. L’algèbre relationnelle
6. Calcul relationnel
_____________________________________________________________________________________
Christian Serge MBERI Tél : 06 975 62 86/05 562 24 46
Page 1 sur 69
Chapitre I : CONCEPTS DE SYSTEMES D’INFORMATION
1 – Système d’information
a) Définition
Un système d’information d’une organisation sociale est l’ensemble des moyens
humains et matériels, et des méthodes se rapportant au traitement des différentes
formes d’informations rencontrées dans les organisations.
b) Rôle
On distingue quatre (04) rôles essentiels du système d’information (SI) :
 Produire des informations légales ou quasi-légales réclamées par
l’environnement socio-économique : factures, bulletins de paie, états pour le
fisc, bulletins de notes, …
 Déclencher des programmes suivant telle condition (exemple : lancement du
réapprovisionnement du stock dès que le stock d’alerte est atteint).
 Aider à la prise de décisions non programmées en fournissant aux décideurs
de l’organisation un ensemble d’informations brutes ou modélisées
(Statistiques, Tableaux de bord, Simulation, …).
 Assurer la coordination des tâches en permettant les communications entre
les individus de l’organisation.
2 – Information / Données
a) Information
L’information est le principal élément de vie du SI. C’est un renseignement, une
nouvelle, un ensemble de faits, de notions qui se présentent à nous à un moment
sur un sujet donné ; c’est donc un support des connaissances. Il est caractérisé par
un langage, un support et le code utilisé (cas de : livre, journal TV, cahier de cours,
…).
b) Données
La donnée est un fait, une notion, la valeur, qu’on donne à l’information.
L’information étant bien entendu un ensemble de données significatives ; alors
l’ensemble des données constituent une information.
Une donnée se caractérise par une désignation claire et précise, une nature, un
type et une dimension (longueur).
c) Différents types d’informations

Il existe deux (02) catégories d’information qui sont :
 L’information naturelle,
 L’information structurée.
c-1) L’information naturelle

Information telle qu’est produite ou appréhendée par l’Homme avec ses moyens
d’expression naturels.
Elle peut prendre des formes différentes parmi lesquelles : écrite, picturale, orale,
tactile, olfactive ou sonore, …
_____________________________________________________________________________________
Page 2 sur 69
c-2) L’information structurée (la Donnée)
La donnée permet de représenter de manière plus rigoureuse les informations
naturelles qui sont souvent difficilement appréhendables et manipulables.
Cette information est généralement obtenue à la suite d’une extraction manuelle
ou automatique d’une information naturelle (on parle d’une extraction de
données).
L’intérêt d’extraire des données d’une information naturelle est double :
 Le premier est la concision de l’information permettant de diminuer les temps
de communication, d’assurer une plus grande fiabilité et de minimiser
l’espace de stockage sur les supports,
 Le deuxième réside dans la possibilité de faire subir aux données des
traitements algorithmiques.
_____________________________________________________________________________________
Page 3 sur 69
Chapitre II : CONCEPTS DE BASES DE DONNEES
1 – Introduction
Suite aux problèmes du genre description des fichiers à fournir dans les programmes
d’application, rendant ainsi lourdes, multiples et fréquentes les modifications de
tous les programmes en cas d’ajout ou de modification de format (Type et
Longueur) pour les données préexistantes, et autres, rencontrés dans l’utilisation des
fichiers classiques, est apparu pendant la décennie 1960, le vocable « BASE DE
DONNEES ».
C’est grâce à cette évolution qui a pris de l’ampleur avec la technologie des
micro-ordinateurs (année 1980) que se sont orientés les informaticiens pour assurer
la mise en œuvre des applications (PRG) complexes sur des données définies et
décrites une fois et dont on ne ferait que citer dans les applications afin d’en tirer
les données.
L’approche Base de Données (BD) permet enfin de définir les structures de données
avant d’envisager les traitements à effectuer. Cette approche postule de la
sémantique (sens) des objets à traiter autorise d’abord la conception d’un modèle
de données (MCD) capable de répondre ultérieurement à tous les besoins
(requêtes de l’utilisateur).
2 – Définition d’une Base de Données

Une BD est une collection des données (Tables ou Fichiers) inter-reliées par des
pointeurs (Clés secondaires) multiples aussi cohérents entre eux que possibles et
stockées ensemble avec aussi peu de redondance que possible pour servir une ou
plusieurs applications de façon optimale c’est-à-dire de manière à répondre
efficacement à une grande variété de requêtes.
Cependant pour la gérer, il faut avoir un SGBD (Système de Gestion de Base de
Données).
NB : La différence entre la BD et le fichier classique réside dans les possibilités
d’utilisation des données :
 Fichier classique : utilisation limitée, spécifique ;
 BD : extraction des données suivant tous les critères souhaités à la
convenance de l’utilisateur.
Ainsi pour mériter le terme de BD, une structure de données doit être interrogeable
selon n’importe quel critère.
Exemples :
Produit ayant code, désignation, prix unitaire et autre …
On devrait être capable de donner la liste des produits dont le prix est inférieur à
1 000 FCFA.
Etudiant ayant Numéro, Nom, Prénom, Sexe, Adresse

On peut sortir la liste des Etudiantes dont les noms commencent par E.
3 – Les fondements des Bases de Données

Le vocable BD est apparu au début de la décennie 1960. C’est vers cette période
que les structures classiques de fichiers se sont révélées insuffisantes pour assurer la
_____________________________________________________________________________________
Page 4 sur 69
mise en œuvre d’applications complexes. Différentes notions correspondant à des
évolutions souhaitées lui étaient associées, ce sont :
a) Intégration
Un des gros problèmes posés par les structures de fichiers est la difficulté d’assurer
une certaine intégration entre les applications différentes mais liées. La notion
d’intégration correspond donc à la volonté d’inhiber cette difficulté.
L’idée sous-jacente est de rassembler les données d’une Entreprise dans un grand
« Réservoir » où chaque usager pourrait venir puiser commodément en fonction de
ses besoins (Approche Système intégré de Gestion : S.I.G).
En pratique, cette vision simpliste s’est vite révélée utopique car un réservoir unique
est difficile à organiser et à gérer. La plupart des BD existantes ne servent qu’à un
nombre réduit d’applications. Un organisme est donc généralement amené à
mettre en œuvre plusieurs BD plus ou moins indépendantes (Exemples : BD Gestion
du Personnel, BD Gestion de la production).
L’idéal serait qu’on établisse une liaison entre ces différentes BD mais c’est un
problème qui n’est pas facile à surmonter.
b) Exploitation Multimode
Les de l’époque ne permettaient l’exploitation d’un fichier que dans un seul mode :
Traitement par lots ou Traitement en temps réel. Bien entendu cette situation est
préjudiciable pour des nombreuses applications où il est indispensable qu’une
même structure de Données puisse être, selon les cas, exploitée dans l’un ou l’autre
mode. La notion d’exploitation multimode correspond donc à la volonté d’exploiter
une BD selon les deux cas (Batch ou TR). Les BD actuelles autorisent effectivement
une telle possibilité.
c) Non Redondance
Dans les structures complexes basées sur des fichiers traditionnels, un grand nombre
de données peuvent apparaître en redondance (Présents deux (02) fois au moins).
Les causes de cette redondance sont multiples :
 Utilisation diverse des Données,
 Versions diverses des Données,
 Nécessité de pratiquer des liaisons entre fichiers.
La redondance est difficile à maîtriser et pendant longtemps, les techniques ont

souhaité l’émergence des nouvelles structures de données évitant toute
redondance. Il est maintenant presque unanimement admis qu’une non
redondance complète n’est pas souhaitable, ne serait-ce que pour des questions
de performance ou pour passer d’une table à une autre grâce aux clés
propagées.
En effet, une donnée en redondance peut être accédée de manières différentes :
il est donc possible de rechercher pour chaque interrogation la méthode d’accès
assurant le temps de réponse le plus court.
Dans les BD actuelles, on accepte une certaine redondance. Toutefois, cette
redondance est contrôlée sévèrement à tous les niveaux par des mécanismes
appropriés.
A propos, voici les inconvénients d’une redondance non contrôlée :
_____________________________________________________________________________________
Page 5 sur 69
 Volume de stockage plus grand,
 Multiples opérations de MAJ,
 Existence de diverses copies d’une même Donnée à des stades de MAJ
différentes et en conséquence risque d’incohérence momentanée ou
permanente.
d) Evolution Aisée : Modification de la Structure de la Base de Données

Il est difficile avec la lourdeur de mise en œuvre des fichiers traditionnels de suivre
l’évolution constante des traitements et des structures de Données d’une Entreprise.
Cette notion correspond donc à la volonté de s’affranchir de cette lourdeur.
C’est ainsi qu’ajouter un champ, retirer un champ, modifier le nom, le type et la
dimension d’un champ se font facilement sans que cela ne suscite des
remaniements des programmes.
e) Indépendance des Données et des Programmes

Dans les systèmes de gestion des fichiers traditionnels, il existe une association
étroite entre un programme et ses Données. Chaque programme possède son
propre ensemble de Données structurées d’une manière spécifique. Il en résulte
une grande redondance de Données, des MAJ multiples, des risques
d’incohérence, des difficultés d’évolution.
Face à une telle situation, on a entrevu rapidement tous les avantages que peut
procurer une indépendance effective entre les programmes et les Données. Vision
globale des Données permettant une réelle intégration des applications et un
partage de Données entre plusieurs usagers, approche commune pour l’insertion et
la MAJ des Données avec contrôle sévère de cohérence, possibilité de faire
évoluer la structure des Données sans avoir à réécrire tous les programmes (c’est-à-
dire ceux qui « voient » toujours la même structure de Données).
Pour atteindre cet objectif, il est nécessaire de mettre en œuvre des mécanismes
complexes. La plupart des systèmes actuels incluent effectivement de tels
mécanismes. Cependant l’indépendance Données-Programmes n’est pas toujours
atteinte complètement.
f) Administration des Données

Pour faciliter l’intégration entre les différentes Données d’une Entreprise, il est vite
apparu que la conception, l’installation et la maintenance des collections des
Données devaient être assurées d’une manière cohérence et coordonnée. Ce rôle
est dévolu à une personne ou une équipe dénommée « Administration des
Données » ou « Administrateur de la Base de Données », selon qu’elle supervise
l’ensemble des Données ou seulement les Données d’une base.
Ainsi, une Administrateur de la BD est la personne responsable de la description
(définition) des Structures des Bases de Données.
Les tâches de l’administration de la base sont :

 Tâche de conception en aidant les utilisateurs non Informaticiens à exprimer
leurs besoins, à structurer les Données, à définir les procédures de saisie et de
MAJ,
 Tâche de création en aidant les Informaticiens dans la mise en œuvre de ces
procédures,
_____________________________________________________________________________________
Page 6 sur 69
 Tâche de maintenance en assurant l’intégrité, la sécurité, l’efficacité et
l’évolution des Données,
 Tâche d’arbitre pour résoudre les conflits éventuels entre les différentes
classes d’usagers de la BD.
4 – Propriétés des Bases de Données

 Une BD est toujours enregistrée sur des supports à accès aléatoire pour leur
utilisation parce qu’elle exige l’accès direct ;
 Usages multiples des données : les données sont disponibles à des usagers
variés, chacun percevant différemment les données qu’il peut employer de
façon différente ;
 Accès facile : la complexité réelle de la structure est transparente à l’usager.
Les manipulations ne nécessitent pas obligatoirement des connaissances
spécialisées ;
 Accès rapide : des mécanismes variés assurent pout tout type d’accès le
meilleur temps de réponse. Exemple : Accès sur un enregistrement à partir de
l’identifiant ou sur une autre rubrique ou champ de la base ;
 Accès protégé : les accès non habilités sont interdits par le système ;
 Accès souple : les Données sont accessibles de différentes manières pour un
usager ;
 Accès partagé aux Données : cet accès permet aux différents usagers
d’accéder simultanément aux mêmes enregistrements de la base ;
 Coût réduit de stockage, de MAJ et de saisie ;
 Disponibilité : toutes les données sont disponibles à tout instant ;
 Exactitude : des contrôles sont effectués en permanence pour garantir
constamment l’exactitude des données et interdire en particulier
l’introduction des données erronées ;
 Cohérence : si une certaine redondance est acceptée, le système assure la
cohérence des diverses copies d’une même donnée ;
 Protection : les données sont protégées contre les disparitions, destructions,
mauvaises manipulations et autres accidents volontaires des Données : toutes
les données sont disponibles à tout instant. Des contrôles sont effectués en
permanence pour garantir constamment l’exactitude des données erronées ;
 Confidentialité garantie grâce à la répartition des privilèges de voir ou de
faire telle ou telle action.
5 – Le Système de Gestion des Bases de Données (SGBD)

a) Définition
Un SGBD est un ensemble de logiciels est un ensemble de logiciels systèmes
permettant aux utilisateurs de structurer, d’insérer, de modifier et de rechercher
efficacement les données spécifiques dans une grande masse d’informations
partagées par des multiples utilisateurs.
Le SGBD comprend les interfaces nécessaires aux différentes formes d’utilisations de
BD. Il se greffe sur le SE du Micro-ordinateur.
b) Rôle
Le rôle du SGBD consiste à :
 Assurer la définition (description) de la base ;
_____________________________________________________________________________________
Page 7 sur 69
 Assurer la cohérence des Données ;
 Assurer l’indépendance des programmes vis-à-vis des Données ;
 Assurer la sécurité et l’intégrité des données ;
 Assurer la manipulation des données par des langages assertionnels ;
 Faciliter l’administration des données ;
 Assurer l’efficacité d’accès aux données ;
 Assurer le partage des données entre différents utilisateurs ;
 Protéger la BD contre les MAJ erronées ou non autorisées ;
 Assurer la restitution des éléments de réponse aux différentes requêtes de
différentes formes des usagers de la BD ;
 Assurer les contrôles de concurrence et de sécurité.
c) Architecture des Systèmes de Gestion des Bases de Données (SGBD)

D’une vue générale, voici comment se présentent les applications utilisateur par
rapport au Système de Gestion des Bases de Données.
Applications en
Applications en Applications L3G sous SQL
L4G en L4G
Ainsi toutes les

Applications passent par le
SGBD. SGBD
BD
Mais, il existe trois architectures différentes de Systèmes de Gestion Bases de

Données :
 Architecture Opérationnelle ;
 Architecture Client Ŕ Serveur ;
 Architecture Fédérée.
C1) Architecture Opérationnelle

De ce point de vue, un Système de Gestion des Bases de Données est un ensemble
de processus et de tâches qui supportent l’exécution du code du Système de
Gestion de Bases de Données pour satisfaire les demandes des utilisateurs. Cela
correspond aux rôles traditionnels des Systèmes de Gestion des Bases de Données.
C2) Architecture Client – Serveur

Depuis l’avènement des exploitations d’ordinateurs d’une manière décentralisée
ou distribuée autour d’un réseau (Local en particulier), les Systèmes de Gestion des
Bases de Données sont désormais organisés selon l’architecture Client Ŕ Serveur.
_____________________________________________________________________________________
Page 8 sur 69
C3) Architecture Fédérée
Cette architecture ajoute à l’architecture client multiserveur, un SGBD géré sur la
station du client par le processus du client.
d) Fonctions
d1) Fonctions principales
d1 – 1) Fonction Description (Définition)
Elle permet de décrire les structures des données à leurs trois (03) niveaux (externe,
conceptuel, interne). C’est par l’intermédiaire du LDD (Langage de Définition de
Données) que cette fonction est activée. Les différentes descriptions et les règles de
correspondance entre niveaux sont mémorisées après la compilation dans une
structure spécifique appelée dictionnaire des données.
d1 – 2) Fonction Manipulation
La structure de la base étant définie et mémorisée, le SGB doit offrir les plus grandes
facilités pour créer les données ou modifier, supprimer et extraire des données
existantes. Cette fonction est activée le LMD (Langage de Manipulation de
Données).
d1 – 3) Fonction Interrogation
L’interrogation directe est pratiquée par l’intermédiaire du LDI (Langage
d’Interrogation de Données) permettant à un utilisateur, non forcément
Informaticien spécialiste de formuler directement des requêtes.
Exemple : Locate For Age>=16 .AND. Age<=35 (en Dbase IV)

Select * From Etudiant Where Age Between 16 and 35.
d2) Fonctions Annexes

d2 – 1) Fonction Protection
Le rôle de cette fonction est de permettre une personnalisation des accès à la
base. Ce rôle comprend la détermination de l’identification d’un usager (mot de
passe, n° d’accès) et la vérification de ses droits d’accès. Suivant les besoins de
l’entreprise, la protection peut intervenir à différents niveaux : Fichier ou Table,
Enregistrement ou Tuple, Rubrique ou Champ, …
d2 – 2) Fonction Sécurité
Cette fonction assure la disponibilité des données. Elle prend une importance
considérable dans un contexte BD pour les raisons suivantes :
 Grand volume des données traitées,
 Diversités des utilisateurs,
 Diffusion à grande échelle,
 Centralisation des données,
 …
d2 – 3) Fonction Intégrité
Elle assure l’intégrité c’est-à-dire l’exactitude des données stockées dans la base.
Elle recouvre deux (02) aspects :
_____________________________________________________________________________________
Page 9 sur 69
 Le 1er concerne la vérification des contraintes dites d’intégrité qui peuvent se
situer à 2 niveaux :
 Niveau intrinsèque basé sur la valeur propre au sein d’un ensemble
(Exemple : l’âge d’un employé légalement autorisé à travailler est
compris entre 16 et 65 ans) ;
 Niveau extrinsèque basé sur la dépendance entre données (Exemple :
une rubrique représentant le nombre de Commandes effectivement
présentes dans la base pour ce Client).
Le SGBD doit veiller à ce que les données respectent en permanence ces

contraintes et notamment lors des opérations de MAJ.
 Le 2ème concerne le maintien de la cohérence entre les copies multiples

d’une même donnée car, en cas d’incident de fonctionnement, il peut y
avoir perte de cohérence. Il convient alors par l’intermédiaire des
mécanismes d’annulation et de reprise de transaction, de rétablir la
cohérence dans les meilleurs délais.
Noter enfin, qu’une règle ou contrainte d’intégrité est une assertion ou condition
que doit vérifier une donnée pour justifier sa présence dans la BD ; autrement dit,
c’est une règle spécifiant les valeurs permises pour certaines données,
éventuellement en fonction d’autres données et, permettant d’assurer une
certaine cohérence de la BD.
Voici quelques exemples de contraintes d’intégrité :

 Unicité de clés,
 Attribut clé non nulle.
d2 – 4) Fonction Optimisation des Ressources

Il s’agit d’une fonction très utile pour une bonne gestion d’une base. Des statistiques
judicieuses élaborées régulièrement peuvent permettre au Gestionnaire de situer
l’utilisation des diverses ressources et de procéder à des réorganisations.
A titre indicatif, voici quelques exemples de statistiques :

 Nombre et durée des exploitations des différents traitements ;
 Taux d’utilisation et de MAJ des différentes données ;
 Temps d’utilisation de l’Unité Centrale et Canaux.
Dans certains cas, le SGBD peut comprendre des procédures de réorganisation

automatique.
e) Fonctionnement
La façon dont le SGBD opère pour effectuer les opérations de Lecture Ŕ Ecriture
dans la base pour le compte d’un programme d’application est schématisée sur la
figure suivante :
_____________________________________________________________________________________
Page 10 sur 69
Programme Programme
d’application A d’application B Sous – Sous –
Application Schéma Schéma
Zone de Zone de A B
liaison A liaison B
2
9 1
3
Administration BUFFERS 7 SGBD Schéma
4
6
5
Base Physique Système Description

d’Exploitation Physique
Manipulation Description
Ainsi, la nature des diverses opérations intervenant lors d’un échange est explicitée
de la manière suivante :
 1 Ŕ le programme d’Application A émet une demande de Lecture à
l’intention du SGBD,
 2 Ŕ le SGBD consulte le sous Ŕ schéma relatif à A pour obtenir la description
logique de ses Données,
 3 Ŕ le SGBD consulte le Schéma et détermine la structure logique des
Données à extraire,
 4 Ŕ le SGBD examine la description physique de la base et détermine
l’enregistrement physique à lire,
 5 Ŕ le SGBD lance une commande au Système d’Exploitation pour provoquer
la lecture de l’enregistrement physique,
 6 Ŕ le Système d’Exploitation provoque le transfert de l’enregistrement entre la
base physique et les buffers du SGBD,
 7 Ŕ le SGBD, à partir du sous Ŕ schéma A, extrait les données à communiquer
au programme d’application A,
 8 Ŕ le SGBD, provoque le transfert des données dans la zone de liaison A,
 9 Ŕ le SGBD retourne au programme d’application A les informations d’état
relatives à l’échange (en particulier les codes des erreurs éventuelles).
Enfin, les données sont alors disponibles pour le programme d’application.
_____________________________________________________________________________________
Page 11 sur 69
En cas d’erreurs, ce dernier peut éventuellement demander d’état et selon leurs
valeurs de déterminer s’il est effectivement opportun de poursuivre l’échange.
f) Les Langages
f1) Définition (ou Description)
Puisque le SGBD agit comme un intermédiaire entre les applications et les données
physiques, la Définition des données dans un environnement BD doit satisfaire trois
(03) exigences :
 D’abord, elle doit spécifier l’organisation logique et les caractéristiques des

données en accord avec le modèle de données (Hiérarchique, Réseau,
Relationnel, Orienté Objet) ainsi que les correspondances entre Schéma et
Sous-Schéma,
 Ensuite elle doit spécifier l’organisation physique des données de façon à
assurer leur placement sur le dispositif physique de stockage,
 Enfin, elle doit spécifier la correspondance entre l’organisation physique et
l’organisation logique de façon à permettre au SGBD de transformer une
organisation physique en une organisation logique.
Toutes ces facilités sont fournies par le LDD (Langage de Définition de Données).
Dans certains cas, le LDD peut fournir également des facilités pour charger une
base, spécifier les contraintes d’intégrité, …
L’organisation logique des données est décrite par un schéma et des sous-
schémas. Schéma et sous-schéma sont définis au moyen du LDD.
Un LDD est généralement un langage autonome qui offre les possibilités suivantes :
 Nommer la base de données et toutes les unités logiques (Types de champs,

Types d’enregistrements),
 Décrire et éventuellement nommer les liaisons qui existent entre ses unités
logiques (Liens entre types d’enregistrements, pointeurs enregistrements).
 Spécifier pour chaque unité de logique élémentaire, la longueur, le domaine
de valeurs, d’éventuelles, unités associées (Francs, Mètres, …),
 Spécifier les clés d’accès aux unités logiques,
 Définir le nombre d’éléments dans certains ensembles,
 Spécifier l’ordre logique d’opposition des éléments dans certains ensembles,
 Spécifier les contraintes d’intégrité,
 Spécifier les mots de passe et autorisation d’accès,
 Spécifier le mode d’utilisation des données (Interrogation seulement, MAJ,
…).
L’organisation physique des données est spécifiée par l’intermédiaire d’un LDP
(Langage de Description Physique des Données). Ses principales possibilités sont :
 Spécifier les caractéristiques physiques du support,
 Décrire la correspondance entre l’organisation logique et l’organisation
physique c’est-à-dire entre types d’enregistrements de fichiers,
 Spécifier l’ordre physique d’apparitions des données,
 Spécifier le type de codage des données (Binaire, Décimal).
_____________________________________________________________________________________
Page 12 sur 69
f – 2) La Manipulation
Le LMD (Langage de Manipulation de Données) est l’interface principale entre un
utilisateur et le SGBD. Il doit satisfaire de nombreuses exigences.
D’abord, il doit être facile à utiliser, précis et complet. Ses opérations concernent la
recherche de données et leur transfert vers l’environnement du programme
d’application, la création, la modification et la suppression des données et
nécessaire la libération des ressources telles que les buffers.
On distingue trois grands types de commandes primitives :
 Commandes de Contrôle,
 Commandes de Recherche,
 Commandes de Modification.
Les commandes de contrôle concernent l’identification de l’application, la
détermination de la base à accéder, l’allocation des ressources du système telles
que les fichiers et les buffers, la reconnaissance de la nature des commandes
qu’une application peut utiliser.
Une commande de recherche consiste en une sélection de données suivie par une
action sur les données sélectionnées.
Une commande de modification comprend trois types d’opérations sur la base, à
savoir :
 Insertion (Ajout),
 Mise à jour,
 Suppression.
g) Différents types de Systèmes de Gestion des Bases de Données

Il est usuel de rattacher les SGBD en cinq types que sont :
 Hiérarchiques,
 Réseaux,
 Relationnels,
 Orientés Objets,
 Déductifs
qui se différencient par les caractéristiques du Modèle de Données (MLD) qu’ils
utilisent. On peut aussi citer les Systèmes Experts (SE) dans cette liste.
g – 1) Système de Gestion des Bases de Données

Hiérarchiques
Modèle le plus ancien, modèle à structure arborescente (Arbre : racine et feuilles
sur chaque branche) symbolisant les associations entre ensemble d’entités mais les
relations existantes sont celles d’un père ayant plusieurs fils.
Ici, on accède aux données toujours à partir de la racine de la hiérarchie, ce qui
induit le temps de réponse important.
Ce modèle est actuellement abandonné au profit des autres modèles.
g – 2 Les Systèmes de Gestion des Bases de Données

Réseaux
Modèle à existence de plusieurs chemins d’accès à une donnée, d’où plus de
redondance de données. On constate également l’existence des pointeurs gérés
par le système qui a permis d’éviter la redondance. Ici, le fils (Record Member) peut
avoir plusieurs parents (Record Owner).
_____________________________________________________________________________________
Page 13 sur 69
g – 3) Les Systèmes de Gestion des Bases de Données
Relationnels
Ici, les types d’enregistrement (Entités ou Objets) et liaisons (Associations ou
Relations) sont tous représentés par l’intermédiaire des tables encore appelées
« Relation Normalisée » c’est-à-dire Tables de Données dont les colonnes appelées
Attributs sont associées aux Rubriques et, dont les lignes appelées Tuples
représentent les enregistrements.
Relation R
Att-1 Att-2 … Att-n
Tuples ou N-uplets
Pour chaque Tuple, un Attribut présente une valeur numérique.
Ce modèle trouve son fondement dans l’utilisation des fonctions de l’Algèbre

Relationnelle.
Exemples
 ORACLE ;
 Access ;
 INFORMIX ;
 SYBASE ;
 SQL Server ;
 …
g – 4) Les Systèmes de Gestion des Bases de Données Orientés Objet

C’est l’une des dernières trouvailles des Systèmes de Gestion des Bases de Données.
Ces SGBD sont issus des Réseaux Sémantiques et des langages de programmation
orientés objets (cas du C++, LISP). Ils regroupent les concepts essentiels pour
modéliser de manière progressive des objets complexes encapsulés par des
opérations de manipulation liées (par liste).
Son modèle de données autorise les relations et des constructions plus élaborées
que ceux des trois premiers Systèmes de Gestion des Bases de Données. Les Entités
(Objet) sont modélisées directement au regard du monde réel avec un
comportement et un état : on dit alors que le concept est celui d’Objet.
_____________________________________________________________________________________
Page 14 sur 69
Ce modèle supporte des modèles de données extensibles intégrant le relationnel et
l’objet, ainsi que des architectures mieux reparties, permettant une meilleure
collaboration entre les users concurrents. Ces modèles intègrent donc une
structuration conjointe des programmes et des données en types (CLASSES) avec
possibilité de définir des sous types (sous CLASSES) par héritage. On les appelle aussi
Relationnel-Objet à cause de l’utilisation du SQL.
Enfin, l’approche BD orientée Objet ou BD objet est née à partir de LISP (Langage
de Gestion d’éléments présentés par liste : voir intelligence artificielle).
Exemples
 SMALLTALK ;
 ORION : construit en LISP
 JAVA : construit à partir du C++ pour des raisons de performance et de
popularité du C++. C’est un langage d’avenir pour :
 sa très grande portabilité ;
 la sécurité de son code intermédiaire généré (Fameux byte-Code qui
est facile à distribuer). Enfin Java est un langage de choix pour des
applications Client / Serveur et Web à plusieurs niveaux de code
applicatif.
 DB2 UniversalDatabase ;
 O2 ;
 INFORMIX Universal ;
g – 5) Notions de Systèmes de Gestion des Bases de Données Déductifs

Le SGBD Déductif est tout d’abord un Système de Gestion des Bases de Données.
En ce sens, il doit posséder un LDD permettant de définir des prédicats de la base
B1, B2, …, Bn sous forme de relations et les contraintes d’intégrité associées. Il offre
un LDI permettant de poser des questions et d’effectuer des MAJ.
Ce type de SGBD intervient dans la gestion classique ou prévisionnelle : aide à la
décision, la médecine, la robotique, la productique et plus généralement toutes les
applications de type SE (Systèmes Experts) nécessitant de grands volumes de
données qu’on appelle ici : Faits et Règles.
Ici, son interface est le « Langage des Règles » car il est utilisé pour définir les
relations déduites composant la base intentionnelle permettant des programmes
de règles du style <Condition>→<Action> ici, Condition (Prémisse) puis Action ou
Conclusion.
Ce langage permet donc de spécifier les parties « Condition » et « Actions des
règles de déduction ».
En SGBD Déductif, on parle de :
 Prédicats ou Bases Extensionnels : Prédicat dont les instances (Occurrences)
sont stockées dans la BD sous forme de tuples listé ;
Père(Makita, Makita-Moulongo) ; Inscrit(Samba, AN2),…
 Prédicats intensionnels : Prédicat calculé par un enregistrement constitué de
règles logiques dont les instances ne sont pas stockées dans la BD c’est-à-dire
constitué des règles permettant de déduire d’autres faits à partir des
éléments de la base extensionnelle.
Si Père(x, y) Alors Parent(x,y)
Si Père(x,y) et Père(x,z) Alors Frère(y,z)
_____________________________________________________________________________________
Page 15 sur 69
En fait, on l’appelle Déductif parce qu’il permet de déduire des informations
(Conclusion ou Actions) à partir des données stockées par utilisation d’un
mécanisme d’inférence logique. Les informations sont les tuples des prédicats
intensionnels ; elles peuvent être déduites lors de l’interrogation des prédicats
intentionnels ou lors des MAJ des prédicats extensionnels.
6 – Processus de conception d’une Base de Données

 Analyse de l’univers du discours ;
 Modèle Conceptuel des Données (MCD) ;
 Choix du type de SGBD utilisé ;
 Modèle Logique des Données (MLD) adapté au type de SGBD ;
 Modèle Physique des Données.
7 – Les Concepts associés aux Bases de Données

Un modèle de Données est un ensemble de concepts qui peuvent être utilisés pour
décrire la structure des données d’une base : Type de Données, Type d’Entité, Type
d’Association, Contraintes d’intégrité. Ainsi, les concepts associés aux Bases de
Données sont :
7 – 1) Objet (ou Entité ou Individu)

C’est une image concrète ou abstraite de l’univers du discours pourvue d’une
existence propre, manipulée par l’organisme d’étude, conformément à ses choix
de gestion. Autrement dit, c’et le reflet d’une entité concrète manipulée par
l’organisme étudié ou l’image d’une entité abstraite à laquelle l’organisme étudié
s’accorde à reconnaître une existence propre.
Un objet doit avoir un nom clair et précis, puis il est toujours porteur des propriétés
qui le caractérisent. Son nom doit être conforme au vocabulaire de la maison
d’étude.
On reconnaît un objet par l’aspect de distinction des différents éléments qui le
composent (Client, Magasin, Produit, Personne, Etudiant, Matière, …)
Exemple : Le client MITORY a passé la commande C1 contenant les produits P1 et

P2.
 Le même client a passé la commande C2 contenant les produits P1 et P3.
 Le client AYESSA a passé la commande C3 contenant les produits P1 et P2.
 Le même client AYESSA a passé la commande C4 contenant les produits P2
et P3.
 La commande C1 a donné lieu à la facture F1.
On peut utiliser cet exemple par le tableau suivant :
_____________________________________________________________________________________
Page 16 sur 69
Clients Commandes Produits Factures
MITORY C1 P1, P2 F1
C2 P2, P3 F2
AYESSA C3 P1, P2 F3
C4 P2, P3 F4
Nous observons que cette description du réel perçu fait apparaître :

 Un ensemble dénommé « CLIENTS » {MITORY et AYESSA} ;
 Un ensemble dénommé « COMMANDES » {C1, C2, C3, C4} ;
 Un ensemble dénommé « PRODUITS » {P1, P2, P3, P4} ;
 Un ensemble dénommé « FACTURES » {F1, F2, F3, F4}.
Nous dirons enfin que sur cet exemple, nous avons les entités suivantes :
 CLEINT avec pour propriétés Nom du client ;
 COMMANDE avec pour propriétés N° commande, Date commande
 PRODUIT avec pour propriétés N° Facture, Date Facture.
Technique utilisée : recenser les mots clés puis appliquer la définition de l’objet sur
chacun des mots clés avec exigence de la notion de distinction.
Autre exemple : L’employé Christian Serge MBERI travaille à l’Office National de
l’Emploi et de la Main d’Œuvre (ONEMO) tandis qu’Allan Arnaud MASSAMBA
travaille à La Solution Informatique (LSI). M. DEKAMBI dispense les cours d’Analyse
Informatique en utilisant la méthode MERISE.
Trouver les entités.
TAF : Les entités sont : Employé, Entreprise, Cours, Méthode.
7 – 2) Relation (ou Association)

Une Relation (ou Association) est une liaison perçue entre entités. Elle est
dépourvue d’existence propre mais elle est conforme aux choix de gestion de
l’entreprise.
Elle peut ou ne pas être porteuse de propriétés. Une association doit avoir un nom.
On reconnaît une relation entre deux objets à travers la phrase de l’univers du
discours faisant allusion aux deux objets, alors dans ce cas, le verbe utilisé donne
son nom à l’infinitif à la relation. L’application d’une règle de gestion dite contrainte
d’intégrité fonctionnelle (CIF) nous fait aussi dégager l’existence d’une relation
entre deux objets.
Exemple : Suivant l’exemple des clients MITORY et AYESSA, nous pouvons de

manière analytique citer les principales associations entre les entités
précédemment identifiés ; ce sont :
 Passer commande (Client Ŕ Commande) ;
 Commander produit (Commande Ŕ Produit) ;
_____________________________________________________________________________________
Page 17 sur 69
 Facturer produit (Produit Ŕ Facture) ;
 Facturer (Commande Ŕ Facture).
Autre exemple :
L’étudiant MITORY vit à Makélékélé, AYESSA vit quand à lui vit à Talangaï.
TAF : Identifier les entités et relations.
Les entités sont : Etudiant et Commune.

La relation est : vivre
NB : Une relation peut ou ne pas être porteuse de propriétés.

 Passer commande (Non porteuse) ;
 Commander produit Quantité commandée (Porteuse).
Toutefois, il existe quatre (04) types d’associations :

 Association Binaire (deux (02) entités) ;
 Association Ternaire (trois (03) entités) ;
 Association N-aire (N entités) ;
 Association Réflexive (ou Récursive) c’est-à-dire d’une Entité (objet) sur elle-
même.
Exemple :
Agents Epouser
7 – 3) Propriété, Rubrique, Attribut

C’est une donnée élémentaire que l’on perçoit, caractérisant ou qualifiant un
Objet ou une relation d’entités. Elle doit avoir une désignation claire conforme au
vocabulaire de la maison, un code (nom symbolique ou mnémonique), un type,
une longueur (ou dimension) et de nature « Elémentaire non calculée ». Une
donnée calculée ne peut pas être une propriété.
Exemple :
 Nom de l’étudiant, quantité commandée, date de la facture
 Nom du client, immatriculation du véhicule, note de l’étudiant à une matière
 Désignation du produit, …
NB : Une propriété caractérise un et un seul Objet ou une et une seule Relation : pas
non plus tel objet et tel(le) autre Objet/Relation.
7 – 4) Les Dépendances
Les principales dépendances qui peuvent être mises en évidence dans un
ensemble de données (Objet/Relation) sont : les Dépendances Fonctionnelles (DF),
Dépendances Multivaluées (DM), et les contraintes d’Intégrité Fonctionnelle (CIF).
Pour ce qui est de la DF, on peut dire que soient (P1, P2) deux propriétés de l’objet,
P2 dépend fonctionnellement de P1 que l’on note P1 → P2 si ‘’ à toute valeur de P1
on ne peut associer à tout instant qu’une et une seule valeur de P2’’. On dit que P1
est la Source alors que P2 est le but.
_____________________________________________________________________________________
Page 18 sur 69
Pour cela, à partir du dictionnaire de données obtenu, procéder à la recherche
des DF en observant les définitions des données puis en repérant les identifiants
d’éventuels objets ; puis faire :
Référence Produit → Désignation Produit ; Numéro Client → Nom Client ;
Référence Produit, Numéro Commande → Quantité commandée.
Cette notion vous aiderait même à découvrir des relations entre objets et surtout à
déterminer les propriétés de chacune de vos relations.
On dit donc que la DF met en évidence deux données au moins. L’une appelée
Source et l’autre le But de la DF. En effet, à une valeur de la donnée Source
correspond une et une seule valeur de la donnée But. En revanche, à une valeur
de la donnée But peut correspondre plusieurs valeurs de la donnée Source : cas de
Numéro Client → Ville Client qui signifierait qu’à une valeur de ville donnée, il n’est
pas exclu que plusieurs clients résident dans une même ville.
La DF se note Source → But.
Cette notion a pour principal intérêt de faciliter le regroupement des propriétés par
objet et/ou relation.
Cependant, on distingue des :
 DF dites élémentaires : Source unique → But ;
 DF dites Directes : DF non transitive ;
 DF non Elémentaires : au moins deux Sources;
 DF Réciproque : l’une et l’autre sont à la fois Source et But.
Exemples :
Numéro Client → Nom Client ; Numéro Client → Date de Naissance Client
Numéro Demande, Code Produit → Quantité demandée.
NB : La Source est ce qu’on appelle finalement Identifiant (et qui sera plus tard Clé).
Pour dégager certaines relations, on se sert de la notion de DF et quelque fois de
CIF.
7 – 5) Occurrence ou Instance
L’occurrence d’un Objet ou d’une Relation (association) est un élément particulier
(ou individualisé) de cette entité ou de cette association. Cette notion s’assimile à
un enregistrement.
7 – 6) Domaine
Ensemble des valeurs pouvant être prise par un attribut.
Exemple : L’attribut coefficient de matière ne peut avoir qu’une valeur comprise
entre 1 et 9.
7 – 7) Cardinalités
Les cardinalités d’un Objet (ou Entité) dans une Relation (ou Association) mesurent,
lorsque l’on parcourt l’ensemble des occurrences (enregistrements) de cet Objet, le
minimum et le maximum de leur participation à la Relation. Autrement dit, c’est le
nombre de fois qu’une occurrence d’un objet participe au minimum et au
maximum aux occurrences de la relation.
_____________________________________________________________________________________
Page 19 sur 69
NB :
 la cardinalité minimale est de 0 ou 1 ; 0 (optionnel) ; 1 (obligatoire) ;
 la cardinalité maximale est de 1 à N ;
 les cardinalités peuvent être 2, 5 c’est-à-dire situation limitée ou délimitée.
X Y X Y
1,n Passer 1,1

CLIENT COMMANDES
X = cardinalité minimale, nombre minimal d’instances d’association auxquelles participe une instance de l’objet
Y = cardinalité maximale, nombre d’instances d’association auxquelles participe une instance de l’objet.
7 – 8) Identifiant
Parmi les propriétés qualifiant un Objet, au moins l’une d’entre elles doit permettre
de caractériser chacune des occurrences de cet objet de manière unique. Cette
propriété est ce qu’on appelle Identifiant de l’Objet. C’est enfin une propriété
particulière de l’objet qui permet de distinguer une et une seule occurrence de cet
objet.
Attention, la relation n’a pas d’identifiant mais l’on pourrait admettre que
l’identifiant de la Relation est la juxtaposition des identifiants des Objets mis en
liaison.
Exemple : Numéro commande pour commande ; Numéro fournisseur pour
Fournisseur ; Numéro pour Etudiant ; Numéro client pour Client ; Code filière pour
Filière.
TAF :
 Identifier les entités, les associations ;
 Regrouper les propriétés par entités et associations ;
 Désigner les identifiants de chaque entité.
8 – Exemples de Base de Données

Construisons une Base de Données pour faciliter la Gestion de la fabrication des
pièces d’une Entreprise. On distingue à priori deux types d’entités :
 PIECES ayant les attributs : Numéro, Désignation, Couleur, Poids.
 SERVICE ayant les attributs : Numéro, Intitulé, Localisation.
En effet, chaque service passe des ordres (commandes) de fabrication pour le

compte de ses Clients. On a besoin de mémoriser la Quantité de chaque pièce
ordonnée par chaque service.
Dans cette optique, une association « ORDRE » avec pour attributs Quantité
ordonnée est créée.
Enfin, il est nécessaire de gérer la nomenclature (la composition) des pièces. Une
nomenclature est un arbre où chaque nœud est relatif à une pièce et indique le
niveau de la pièce dans l’assemblage avec la quantité correspondante. En
conséquence, une autre association (Nomenclature) est créée avec pour attribut
Quantité utilisée.
Les associations à prendre en compte doivent permettre d’établir des liaisons entre
les entités suivantes :
_____________________________________________________________________________________
Page 20 sur 69
 Service et Ordre ;
 Pièces et Ordre ;
 Pièces et Nomenclature pour obtenir l’assemblage d’une pièce ;
 Pièces et Nomenclature pour obtenir les Nomenclatures dans lesquelles
intervient une pièce.
PIECES SERVICE
1,n 1,n
Ordre
0,n
1,n
Composer
Par rapport à l’exemple de BD, voyons les différentes possibilités qu’offre chaque
type de SGBD.
Schéma Hiérarchique
PIECES SERVICES
NOP NOS
Désignation Intitulé
Couleur Localisation
Poids
Assemble Compose Pièce-Ordre Service-Ordre
NOP NOP NOS NOP

Quantité Quantité
Ce schéma est basé sur deux structures hiérarchiques différentes :

 La 1ère hiérarchie a pour racine le segment Pièce et trois segments
dépendants que sont Assemble, Compose et Pièce-Ordre.
 Assemble fournit pour une pièce donnée, les NOP composantes du 1 er
niveau.
 Compose fournit pour une pièce donnée, les NOP pour lesquelles elle
entre dans la composition.
_____________________________________________________________________________________
Page 21 sur 69
Dans les deux cas, un pointeur vers Pièce permet de référencer chaque
occurrence concernée.
 Pièce-Ordre fournit pour une pièce donnée, le NOS ayant cette pièce
en commande et les renseignements complets sur chaque service
grâce au pointeur vers Service
 La 2 ème hiérarchie a pour racine le segment Service et un segment
dépendant Service-Ordre qui fournit les NOP des pièces commandées par
chaque Service avec les quantités correspondantes. Un pointeur vers pièce
permet d’obtenir toutes les caractéristiques des pièces concernées.
Comme vous le voyez, cette structure nécessite donc une certaine redondance de
données si on veut implanter tous les types d’associations.
En résumé, les relations hiérarchiques Père-Enfant, représentées sur cette figure par
des traits simples, peuvent être implantées de diverses manières : Contiguïté
physique, Pointeurs, Index, …
Schéma Réseau
Pièce Service
PIE-ORD SER-ORD
Assemble
Compose
Nomenclature Ordre
Quantité Quantité Ordonnée

Composante
Le Set SER-Ord fournit les quantités commandées par chaque service.

Pour chacune des pièces, on peut remonter au Record Propriétaire Pièce par
l’association (Set) PIE-ORD.
Pour chacune des pièces, on peut remonter au Record Propriétaire Service.
Le Set « Compose » fournit les assemblages où intervient une pièce.
Le Set « Assemble » fournit les pièces d’un assemblage au niveau immédiatement
inférieur.
Schéma Relationnel
Pièce (NOP, Désignation, Couleur, Poids)
Service (NOS, Intitulé, Localisation)
Ordre (NOP, NOS, Quantité commandée)
Nomenclature (NOPA, NOPC, Quantité)
_____________________________________________________________________________________
Page 22 sur 69
PIECES SERVICE
1,n 1,n
Ordre
0,n
1,n
Composer
Ces quatre (04) relations accueillent les différents attributs. Les associations sont
modélisées grâce à la redondance de certains champs. Ainsi, pour chaque tuple
de Ordre, on a dupliqué NOS et NOP de façon à obtenir le Service et la Pièce
concernée par chaque Commande.
Par ailleurs, pour chaque tuple de nomenclature, on a fait figurer le NOP deux (02)
fois NOPA (assemblage) et NOPC (composant), la quantité associée représente le
nombre de composants pour cet assemblage.
9 – Conception du Modèle Conceptuel des Données (MCD)

Le MCD présente les liens qui existent entre les différentes entités (Objets) et
associations (Relations) de la Base de Données. C’est pour cela qu’il faut regrouper
toutes formes de données manipulées par l’organisme d’étude dans les concepts
appelés Objets et/ou Relations.
9 – 1 Objectif
L’objectif du MCD est de donner une représentation aux Données mémorisables
sans se soucier des traitements futurs, ni des choix d’organisation de la
mémorisation.
Une donnée même non mémorisée doit figurer dans la liste de données.
Cependant, une donnée non élémentaire ou calculée ne doit pas être mémorisée
à ce stade de la conception.
9 – 2 Concepts et Formalismes
Les concepts du MCD sont :
 Objets (Entités)
NOM DE L’OBJET
--- Formalisme
--- Liste des
--- propriétés
L’identifiant doit être la 1ère propriété de la liste puis il doit être souligné.
L’entité est toujours porteuse de propriétés.
_____________________________________________________________________________________
Page 23 sur 69
Exemple :
ETUDIANT
N° Inscription
Nom
Prénom
Date de naissance
 Relation (Association)
Nom Association
---
--- Liste des
--- propriétés
Elle peut ou ne pas être porteuse des propriétés. Il existe cependant quatre (04)
types d’association :
 Association entre deux (02) entités (Association Binaire) ;
 Association entre trois (03) entités (Association ternaire) ;
 Association entre N entités (Association N-aire) : N>3 ;
 Association dite Réflexive ou Récursive c’est-à-dire Association d’une
entité sur elle Ŕ même.
Exemple :
ETUDIANT NIVEAU
N° inscription Code Niveau
Nom S’inscrire Code Cycle
Prénom Libellé Niveau
Date de naissance
PERSONNEL CONTRAT
Code Personnel Numéro Contrat
Nom Intervenir Date signature
Prénom
Date de naissance
QUALIFICATION
Code Qualification
Désignation
_____________________________________________________________________________________
Page 24 sur 69
EMPLOYE
Numéro Employé
Nom Epouser
Prénom
Date de naissance
Un agent ne peut épouser qu’une collègue
PIECES Composer
Numéro Pièce
Qté utilisée
 Cardinalités
La cardinalité désigne le nombre qu’une occurrence d’un Objet participe aux
occurrences de la Relation.
La cardinalité se met toujours dans le sens Objet vers la Relation.
PERSONNEL CONTRAT
0,n 1,n
Prénom
Date de naissance
0,n
QUALIFICATION
Code Qualification
Désignation
 Propriétés
(voir cours sur les concepts associés)
Retenez qu’une propriété ne doit caractériser qu’un objet ou une relation, ceci pou
éviter la redondance.
 Identifiant
Voir les concepts.
 Les DF et CIF
Voir les concepts
_____________________________________________________________________________________
Page 25 sur 69
9 – 3 Description des Fiches
FICHE RELATION :
Propriétés
Code Désignation T/L Observation
Objet en Relation :
Cardinalités : Côté 1er :
Côté 2ème :
NB : Les noms qu’on donne aux objets et aux relations doivent être conformes au
vocabulaire utilisé dans la maison.
Dictionnaire des données recueillies :
N° Nom symbolique Désignation Type Longueur Règles Observation
9 – 4 Démarche d’élaboration du MCD

Remarque :
Une propriété non calculée est une propriété qui doit être introduite dans le SI soit
par saisie, soit par importation. Elle doit être absolument mémorisée c’est-à-dire elle
doit être une propriété d’un objet ou d’une relation.
Une propriété calculée est une propriété obtenue à partir d’autres propriétés
existantes dans le SI. Moralité, une propriété calculée n’est pas mémorisable à cette
étape-ci de la conception).
Pour concevoir un MCD, il existe deux approches possibles :
 Par l’univers du discours, qui exprime des besoins ou des règles de gestion ;
 Par l’analyse des flux d’informations (Documents), qui sont porteurs des
Données.
 Première Démarche
A partir de l’univers du discours (la narration du travail du gestionnaire) exprimant
les principales fonctionnalités de l’Organisme étudié, on doit dégager les objets
(Entités) et les Relations (Association), mais rarement les propriétés qu’il faut obtenir
en discutant avec le Gestionnaire.
En général, suivant l’univers du discours, un sujet ou un complément est un Objet
(Entité), un verbe utilisé dans une phrase faisant allusion à deux objets, détermine
l’existence d’une Relation entre deux Objets. Les Contraintes d’Intégrité
Fonctionnelle (CIF) permettent de dégager les relations entre objet : On trouve une
Classe par Cycle au Centre de Formation en Informatique. (Cycle ---→Classe).
Elaborer la liste des données présentant pour chacune d’elles désignation, nature,
contraintes lui concernant.
Attention : Un objet qui n’a qu’une seule occurrence ne se modélise pas.
_____________________________________________________________________________________
Page 26 sur 69
A chaque fois que, pour une Relation, on ne peut en distinguer les occurrences
qu’en rajoutant la notion de temps, il faut fortifier la relation en rajoutant une patte
vers un Objet « Date ».
{Adhérent} ----- {Adhérer} ------ {Catégorie}
{Date}
 Deuxième Démarche
Analyse des flux d’informations (Documents) c’est-à-dire il s’agit d’étudier tous les
documents présentés par le Gestionnaire.
Pour chaque document, recenser toutes les données y contenues.
Pour chaque donnée lui trouver une désignation (Dénomination) claire et précise.
Définir si elle est calculée ou pas, élémentaire ou composée.
Si elle est calculée, formaliser sa règle d’obtention : les données citées dans la règle
doivent être dans la liste de données.
Si elle est composée, décomposer là en complétant la liste de données par ses
données décomposées.
Une fois que les flux sont étudiés, élaborer une liste exhaustive des données
recueillies d’abord document par document puis dresser une liste globale,
regrouper les données par Objets et/ou Relations dégagés, définir pour chaque
objet son identifiant et contrôler que l’ensemble des regroupements est en 3 ème FN.
NB : Si, un document contient des données présentes dans deux Objets différents
c’est qu’il y a un lien entre ces deux Objets.
Attention : Un objet qui n’a qu’une seule occurrence ne se modélise pas.
A chaque fois que, pour une Relation, on ne peut en distinguer les occurrences
qu’en rajoutant la notion de temps, il faut fortifier la relation en rajoutant une patte
vers un Objet « Date ».
{Adhérent} ----- {Adhérer} ------ {Catégorie}
{Date}
 Troisième Démarche
Les deux premières sont réunies (univers du discours et Documents) : identifier les
Objets et les Relations grâce à la 1ère démarche et regrouper les propriétés grâce à
la 2ème démarche.
9 – 5 Conseils Pratiques
Que vous soyez dans le 1er cas où vous n’avez que l’univers du discours ou
dans le 2ème cas où vous avez les documents et les objectifs à atteindre ou dans le
3ème cas où vous avez les deux premiers réunis, on vous demande de dresser une
liste exhaustive des données manipulées.
Cette liste de données ne doit pas présenter des polysèmes (noms différents
mais ayant le même sens : parmi les deux, il faut prendre une seule donnée) et des
synonymes (noms différemment écrits mais ayant la même signification : parmi les
deux, il faut prendre une seule donnée). Cette liste doit avoir les éléments suivants :
 Désignation
 Nature
 Objet / Relation
 Règles
_____________________________________________________________________________________
Page 27 sur 69
Pour dégager un Objet, je vous conseille de dresser une liste des mots clés contenus
dans le texte ou perçus à partir des désignations des données puis procéder par
élimination suivant la définition de l’Objet.
9 – 6 Les Règles du MCD

9 – 6 – 1 Les Règles Générales
 Chaque Objet doit avoir une existence propre, alors que la
Relation n’a d’existence que par rapport aux objets mis en
liaison.
 Un Objet qui n’a qu’une seule occurrence ne se modélise pas.
 Chaque occurrence d’un Objet ou d’une Relation doit être
distinguable et identifiable.
 Chaque occurrence d’un Objet ou d’une Relation doit être
dotée des mêmes propriétés.
 Pour chaque occurrence d’une Relation, il ne doit exister qu’une
et une seule occurrence de chacun des Objets mis en liaison.
9 – 6 – 2 Les Règles Qualifiantes

o Règles de Vérification et de Normalisation d’un MCD
Règles concernant les Objets
Règle 1 : Existence d’un Identifiant pour chaque Objet, l’application de cette règle
permet de vérifier l’existence d’un Objet conformément aux choix de gestion de
l’Organisme étudié : un présumé Objet sans identifiant n’est pas un Objet au sens
de la modélisation.
Ainsi, si l’on considère la situation suivante : les Clients réservent leur table dans un
Restaurant.
CLIENTS TABLE
Code Client Numéro Table
1,n Réserver 0,n
Date
Heure
Aussi, les Clients réservent ou demandent la réservation de couchettes au CFCO

par téléphone.
Clients Réservations
Code Client Numéro Réservation
1,n Demander 1,1
Date
1,n
Couchettes 0,n
Numéro Couchette Concerner
_____________________________________________________________________________________
Page 28 sur 69
Règle 2 : Pour chaque occurrence d’un Objet, chaque propriété ne peut prendre
qu’une seule valeur. Autrement dit, on ne peut avoir de valeurs répétitives pour une
même propriété.
Soit l’Objet Employé
Numéro Employé
Nom Eployé
Prénom Employé
Adresse Employé
Prime de Qualification
Domiciliation Bancaire
Prénom Enfant → Cette propriété peut prendre plusieurs valeurs selon le
nombre d’enfants.
D’où il faut créer l’Objet Enfant(N°Ordre-N°Employé, Prénom, Date de Naissance).
Contrainte : Si les Conjoints Parents de cet enfant sont tous les deux de la même
Entreprise, il faut rattacher les enfants à leur Père.
Règle 3 : Toutes les propriétés doivent être élémentaires et non calculées, donc non
décomposables.
Cas de la Domiciliation Bancaire de l’Employé (Code Banque, Code Guichet,
Numéro Compte, Clé RIB)
NB : 1ère FN.
Règle 4 : Toutes les propriétés de l’objet autre que l’identifiant doit dépendre
pleinement et directement de l’identifiant. Pour cela, il existe deux notions pour
cette règle :
o Notion de dépendance pleine : les propriétés d’un Objet doivent
dépendre de tout identifiant et non pas d’une partie de cet
identifiant (2ème FN)
Exemple :
Enfant
N°Ordre-N°Employé
Nom de l’Employé
Prénom de l’Enfant
Date de Naissance
Nom de l’Employé ne dépend pas pleinement de l’identifiant (N° Ordre-

N°Employé) mais plutôt d’une partie de cet identifiant. En effet, il dépend du N°
Employé et non du N° Ordre. D’où,
Enfant
N°Ordre-N°Employé
Prénom de l’Enfant
Date de Naissance
o Notion de dépendance directe : Chaque propriété doit
dépendre directement de l’identifiant et non par l’intermédiaiare
d’une ou plusieurs propriétés. Autrement dit, la dépendance
transitive n’est pas acceptée (3ème FN).
Exemple : Après complément d’informations concernant les modalités d’attribution
de la prime de qualification, nous apprenons que celle-ci dépend en fait de la
_____________________________________________________________________________________
Page 29 sur 69
qualification de l’Employé ; par conséquent dans l’Objet Employé vue
précédemment, la propriété Prime de qualification ne dépend pas directement de
l’identifiant « N° Employé » mais d’abord de la propriété « Qualification ». Ainsi, nous
dévons créer l’Objet Qualification (Numéro qualification, Désignation, Prime de
qualification) et donc retirer la prime de qualification de l’Objet Employé.
Enfant Employé
Numéro Employé
1,1 Avoir 0,n
N°Employé-N°Ordre Nom Employé
Date de naissance Prénom Employé
Prénom Adresse de l’Employé
Code Bancaire
Numéro Compte
Qualification 0,n 1,1 Clé RIB
Appartenir
Numéro Qualification
Désignation
Prime
NB : Le MCD obtenu est dit Brut mais il y aura un dit Normalisé intégrant les CIF puis
un MCD Générique.
o Règles concernant les Relations

Règle 5 : A chaque occurrence d’une association correspond une et une seule
occurrence de chaque Objet participant à cette relation. D’où les deux règles
suivantes :
 Deux occurrences d’un Objet ne peuvent participer à une
même occurrence de la relation.
Exemple : Réservation de chambre d’hôtel par les clients

CLIENTS CHAMBRES
Code Client Réserver Numéro Chambre
1,n 0,n
Nom Date
Prénom Heure
Adresse Nombre de jours
 Pour une occurrence de la relation, qu’il n’y a pas une

participation optionnelle d’une occurrence de l’Objet.
_____________________________________________________________________________________
Page 30 sur 69
Exemple : Gestion des représentants dans le cadre du suivi commercial.
BRANCHE SECTEUR GEOGRAPHIQUE
Code Branche Numéro Secteur
0,n 0,n
Désignation Vendre Objectif C A
Objectif C A
1,n
REPRESENTANT
N° Représentant
Nom
CA
Règle 6 : Pour chaque occurrence d’une Relation (Association), il ne peut exister

qu’une et une seule valeur pour chaque propriété de la relation.
CLIENTS CHAMBRES
Code Client Réserver Numéro Chambre
1,n 0,n
Nom Date
Prénom Heure
Adresse Nombre de jours
Règle 7 : Toutes les propriétés d’une relation doivent dépendre pleinement de

l’identifiant de la relation. Ainsi, chaque propriété doit dépendre de tout et non pas
d’une partie de cet identifiant.
Sachant que, l’identifiant de la relation est la juxtaposition des objets mis en
relation.
Exemple :
EMPLOYE BATIMENT
Numéro Employé Affecter Numéro Bâtiment
1,n 0,n
Nom Date Début Adresse
Date fin
Prime
géographique
1,n
SERVICE
Numéro Service
Désignation
Budget alloué
_____________________________________________________________________________________
Page 31 sur 69
Sur les applications de la règle, on constate que la prime géographique ne dépend
réellement que des Objets Service et Bâtiment.
Employé Bâtiment
1,n Affecter
Numéro Employé Numéro Bâtiment
Nom Date début Adresse
Date fin
1,n
1,n
Allouer
Service Prime
géographique
Numéro Service
Désignation
1,1
Budget alloué
10 – Le Modèle Logique des Données (MLD)

NB : Le MCD se fait à chaque niveau de conception c’est-à-dire à l’étude de
l’existant (MCD actuel) puis après avoir critiqué, proposé et fait accepter la solution
future (MCD Futur). On élabore ensuite le MLD. On dit donc que le MLD est élaboré
sur le MCD Futur sauf sue demande expresse de l’User. Toutefois, ce MLD est dit Brut.
10 – 1 Objectif
L’objectif du MLD est de chercher à obtenir la meilleure organisation des données
en respectant la sémantique initiale du MCD et intégrant l’organisation de la
mémorisation choisie en rapport avec le type de SGBD choisi.
10 – 2 Démarche d’Elaboration
Le MCD a permis de représenter les données indépendamment des choix
techniques. Cependant, le MLD sera construit à partir du MCD en tenant compte
des éléments suivants :
 Le niveau et le type d’automatisation : (il s’agit de ne retenir dans le
MLD que la partie du MCD qui sera automatisé). Le type
d’automatisation (Temps Réel ou Temps Différé) sera étudié lors de
l’optimisation du MLD.
 L’orientation des choix techniques concernant le SGBD :
o Orientation BD de type Réseau (CODASYL) ;
o Orientation BD de type Relationnel ;
o Orientation BD de type Orienté Objet ;
o Orientation BD de type déductif.
C’est ainsi que nous allons successivement étudier l’élaboration du système de Base
de données en privilégiant les SGBD Relationnels.
_____________________________________________________________________________________
Page 32 sur 69
10 – 2 – 1 Le Modèle CODASYL (Réseau)
a) Les Concepts
Ce modèle est parfaitement adapté lorsque l’on utilise le SGBD de type réseau :
IDSII, TOTAL, CLIO, …
Il a été normalisé par le groupe de travail DBTG (Data Base Task Group) sous le label
CODASYL (Conference On Data SystemsLanguages).
Le Record
C’est un ensemble des données élémentaires qui représentent un enregistrement
logique dans un environnement BD. Il peut être propriétaire (Owner) ou membre
(Member).
Un record est caractérisé par :
o La liste de ses propriétés aussi appelées DATA ITEM.
o Le mode d’accès aux occurrences du record.
o Le nom qui est attribué au record.
Les deux principaux modes d’accès à un Record sont :

o CALC (pour les accès calculés sur clé) : une propriété joue le rôle de la clé
d’accès au record (il peut exister plusieurs clés).
o VIA SET (par les liens logiques) : l’accès à une occurrence d’un record se fera
par l’intermédiaire d’un lien qui matérialise une relation avec un autre record.
Formalisme du Record
Exemple :
Nom du PATIENT
RECORD
NB : Selon les règles de passage du MCD au MLD que nous verrons, tout Objet est
un Record, une Relation peut être un Record ou un Set.
Le Set
Il représente un lien entre un Record appelé OWNER (Propriétaire) et un autre
Record appelé MEMBER (Membre).
Formalisme du Set
OWNER MEMBER
SET
CLIENT COMMANDE
CLIENT COMMANDE
Code Client Passer-Cde Numéro
1,n 1,1
Nom Client Commande
Date commande
Le SET « Passer-Cde » représente la relation de type Père au Fils (1-N) entre Client et
Commande. A une occurrence de Client, le Set « Passer-Cde » permettra de faire
correspondre les N occurrences de Client qui lui sont associés.
_____________________________________________________________________________________
Page 33 sur 69
b) Les Règles d’élaboration du Modèle Réseau
Règle 1 : Tout Record peut être Membre de plusieurs Sets différents.
CLIENT FOURNISSEUR
SET Cder SET Fournir
PRODUIT
PRODUIT est un Record Membre du Set CDER et avec pour Propriétaire CLIENT et du
Set Fournir avec pour Propriétaire FOURNISSEUR.
CLIENT PRODUIT
Code Produit
1,n Commander 1,1
Code Client Libellé
Nom
1,1
FOURNISSEUR
1,n
Numéro Fournisseur Fournir
Nom
Règle 2 : Tout Record peut être propriétaire de plusieurs Set différents.

Set Facturer
PRODUIT LIGNE FACTURE
Set Commander
LIGNE COMMANDE
_____________________________________________________________________________________
Page 34 sur 69
LIGNE FACTURE PRODUIT
Code Produit
1,1 Facturer 0,n
Code Client Libellé
Quantité
Nom
0,n
LIGNE COMMANDE
1,1
N°Ligne Commande Commander
Quantité
Règle 3 : Tout Record peur être à la fois :

o Propriétaire d’un ou plusieurs Set différents à la fois, mais aussi,
o Membre dans un ou plusieurs Set différents.
Application Ligne Programme
Appliquer Prog-Ligne
Programme
APPLICATION PROGRAMME
Appliquer Numéro Programme
1,n 1,1
Code Application Nom Programme
Nom Application
1,n
LIGNE PROGRAMME
1,1 Programmer
N°Ligne Programme
_____________________________________________________________________________________
Page 35 sur 69
Règle 4 : Deux Record peuvent être reliés entre eux par un nombre quelconque de
Set différents.
Set louer
IMMEUBLE OCCUPANT
Louer
1,n 0,1
IMMEUBLE OCCUPANT
Code Immeuble Code Occupant
Nom Immeuble 1,n 0,1 Nom Occupant
Co-Patron
Adresse
Règle 5 : Un record peut participer dans le même Set à la fois comme OWNER et
MEMBER (Relation Récursive).
0,1
Employé
Code Employé
Marier
Nom
Prénom
0,1
Employé
Set marier
Règle 6 : Pour une occurrence de SET, il existe toujours un OWNER.
Règle 7 : Un record peut n’être rattaché à aucun Set.
c) Règles de passage du MCD au MLD (Réseau)

Règle 1 : Chaque Objet se transforme en record, l’identifiant dévient la clé du
record.
Règle 2 : Une relation ayant les caractéristiques suivantes :

 Dimension deux (relations entre deux Objets)
 Cardinalité des Objets participants à la relation.
A 1,1 R 1,n B
0,1 0,n
Cette relation ne se transforme pas en SET.

Exemple :
_____________________________________________________________________________________
Page 36 sur 69
MCD
CLIENT COMMANDE
Code Client Passer Numéro
1,n 1,1
Nom Client Commande
Date commande
MLD
Set Passer
CLIENT COMMANDE
Dans le cas où la relation est porteuse de propriétés, celles-ci immigrent vers le

Record Ŕ Member (COMMANDE), le Record Ŕ Member reçoit la clé du record
propriétaire en se présentant comme CléA-CléB.
Règle 3 : Une relation ayant les caractéristiques suivantes :

 Dimension deux (qui relie deux Objets)
 Cardinalité des objets participants à la relation du genre :
,n ,n
A R B
0,1 0,n
1,n 1,n
Cette relation « R » se transforme en un Record Ŕ Member ayant deux SET, et les

deux objets sont dits record Propriétaires.
FOURNISSEUR PRODUIT
Numéro Fournir Code Produit
,n ,n
Fournisseur Prix Libellé Produit
Nom Fournisseur
Adresse
FOURNISSEUR PRODUIT
Catalogue Fournisseur
Catalogue Produit
FOURNIR
Que le Record Ŕ Member reçoit les clés des Records mis en relation (Record
Propriétaires), pour en être sa clé.
Règle 4 : Une relation de dimension supérieure à deux se transforme en un Record Ŕ

Member et autant de SET qu’il y a d’objets participant à la relation.
_____________________________________________________________________________________
Page 37 sur 69
PERSONNEL CONTRAT
0,n 1,n
Prénom
Date de naissance
0,n
QUALIFICATION
Code Qualification
Désignation
PERSONNEL Intervenir CONTRAT
QUALIFICATION
Règle 5 : Une relation de dimension deux dans le cas de cardinalités 1 Ŕ 1 se

transforme en SET en choisissant l’un de deux Records comme Propriétaire.
10 – 2 – 2 Le Modèle Relationnel
Il consacre l’exploitation des données par des tables ayant des colonnes
(représentant des Attributs ou Champs) et des lignes (représentant des Tuples ou
Enregistrements). A cette étape de l’étude, nous allons nous contenter de
déterminer les colonnes d’une table. Les lignes seront l’affaire de l’exploitation de la
table avec des données réelles que seront des enregistrements sur un SGBD (Cas
de Microsoft Office Access).
a) Les concepts
Domaine
Le domaine est un ensemble de valeurs que peut prendre un Attribut.
Exemple : Soit le Domaine D1 sur la rubrique marque de voitures : FIAT, PEUGEOT,
TOYOTA, …
Exemple : Soit le Domaine D2 sur la couleur d’un pantalon : NOIR, BLEU, …
Relation Normalisée (TABLES)

C’est un sous ensemble du produit cartésien de domaine, il sera désigné par un
nom qui sera le Nom de la table.
_____________________________________________________________________________________
Page 38 sur 69
Exemple : Relation Voiture ayant pour Attribut marque et couleur.
Attribut
Marque Couleur Degré d’une relation = nombre d’attributs

d’une relation
Cardinalité d’une relation = nombre
de tuples
Tuples = Enregistrements
Attribut
Attribut représente une colonne d’une relation. Il est caractérisé par un Nom.
NB : Attribut (Table) correspond à Propriété (Objet ou Relation).
Exemple : Marque, Couleur
Clé d’une Relation

Une clé est constituée d’un ou plusieurs Attributs, dont les valeurs définissent d’une
manière unique chacun des tuples de la relation. Voir clé principale, clé candidate
(attribut dont les qualités sont telles qu’il pourrait repérer un tuple de manière
alternative à la clé principale.
Exemple : Employé (Numéro Employé, Nom, Prénom, Date de Naissance)
b) Règles de passage du MCD au MLD Relationnel

Règle 1 :
-,n -,n
A R B
Les Objets A et B et la relation R deviennent des relations normalisées

(TABLES). L’identifiant de A devient la clé de la relation normalisée A (TABLE « A »),
l’identifiant de B devient la clé de la table B.
La table « R » reçoit en les juxtaposant les identifiants des Objets A et B
constituant désormais sa clé.
Les propriétés de A deviennent les attributs de la table A et les propriétés de B
deviennent les attributs de la table B et les propriétés de R deviennent les attributs
de la table R (dans le cas où elle est porteuse des propriétés).
Règle 2 :
-,1 -,n
A R B
Les Objets A et B deviennent des Tables, la relation R ne sera pas une Table ;
cependant, si elle est porteuse des propriétés, ces propriétés deviennent d’autres
attributs de la Table A.
_____________________________________________________________________________________
Page 39 sur 69
L’identifiant de l’objet A devient la clé de la Table A et l’identifiant de l’Objet
B devient la clé de la Table B. enfin, la Table A recevra en terme d’autres attributs la
clé de la Table B.
Les propriétés de l’Objet A deviennent les attributs de la Table A.
Les propriétés de l’Objet B deviennent des attributs de la Table B.
Règle 3 :
-,1 -,1
A R B
Les Objets A et B deviennent des Tables, la Relation R ne sera pas une Table ;
cependant, si elle est porteuse des propriétés, choisir de balancer ces propriétés
dans une Table créée du côté voulu.
L’identifiant de l’Objet A devient la clé de la Table A et l’identifiant de l’Objet
B devient la clé de la Table B.
Les propriétés de l’Objet A et B deviennent respectivement leurs attributs.
Enfin, les Tables A et B se changent des clés, en terme d’autre attribut.
Exemple : MCD
CLIENT COMMANDE
Numéro Client Passer Numéro
,n ,n
Nom Commande
Adresse Date Commande
MLD Relationnel
(Application de la RP2)
CLIENT(Numéro CLIENT, Nom, Adresse)
COMMANDE(Numéro Commande, #Numéro Client, Date Commande)
Remarques :
Remarque 1 :Cas de Relation Récursive N-N
-,n
-,n
A R
-,n
L’Objet devient une table, ses propriétés deviennent ses attributs, la relation R
devient une table et reçoit deux fois l’identifiant de l’Objet en les distinguant selon
la sémantique du lien.
_____________________________________________________________________________________
Page 40 sur 69
Exemple :
MCD
0,n
PIECE
Numéro Pièce Composer
Désignation 0,n
Couleur Quantité
Poids
MLD Relationnel
PIECE(Numéro Pièce, Désignation, Couleur, Poids)
Composer(Numéro PièceA, Numéro PièceB, Quantité)
Remarque 2 : Cas de Relation Récursive de type (1-1)

-,1
A R
-,1
L’Objet devient une Table, ses propriétés deviennent ses attributs, la relation
disparaît. Mais pour marquer le lien ou la dépendance fonctionnelle, il faudra
repérer sa clé dans la table créée en ajoutant une lettre afin d’en distinguer.
Exemple :
MCD
0,1
EMPLOYE
Numéro Employé 0,1 Etre marié
Nom
Prénom
MLD Relationnel
EMPLOYE(Numéro Employé Epoux, Numéro Employé Epouse, Nom, Prénom)
Remarque 3 : Cas de double relation entre deux objets, mais de type (1-n)
-,1 -,n
A B
-,1 -,n
_____________________________________________________________________________________
Page 41 sur 69
Les deux objets sont des Tables et les deux relations ne sont pas des Tables.
Mais leurs propriétés respectives seront transférées vers la Table A comme autres
attributs.
Cependant, la Table A recevra deux fois la clé de la Table B en distinguant
suivant la sémantique des deux liens.
Exemple :
MCD
IMMEUBLE OCCUPANT
Numéro Client Louer Numéro Occupant
1,n 1,1
Adresse Date Nom
Prénom
1,n 0,1
Co-patronner
MLD Relationnel
IMMEUBLE(NuméroImmeuble, Adresse)
OCCUPANT(NuméroOccupant,#NuméroImmeubleL,#NuméroImmeubleC, Nom,
Prénom)
Remarque 4 : Particularités sur les liaisons 1 – 1

 Liaison Parallèle
1,1 1,1
A R B
Dans ce cas, seule la relation B recevra la clé de A. En CODASYL, CléB-CléA.
 Liaison Facultative
0,1 0,1
A R B
Dans ce cas, les relations A et B s’échangent les clés. Cas très rare mais possible de
le rencontrer. En CODASYL, CléB-CléA.
 Liaison de Complément
0,1 1,1
A R B
_____________________________________________________________________________________
Page 42 sur 69
Dans ce cas, seule B reçoit la clé de A. Cas très rare mais possible de le rencontrer.
En CODASYL, CléB-CléA.
10 – 2 – 3 Le MLD Orienté Objet

Rappel sur les SGBD Objet
Ces SGBD regroupent les concepts essentiels pour modéliser de manière
progressive des objets complexes encapsulés par des opérations (Attributs de
Comportement) de manipulation liées (par liste).
En effet, son modèle de Données autorise les relations et des constructions plus
élaborées que ceux des trois premiers SGBD. Les entités (Objets) sont modélisés
directement au regard du monde réel avec un état et un comportement : on dit
alors que le concept est celui d’objets constitué de deux types d’attributs :
 Attributs d’état (Nom, Prénom, Age, …)
 Attributs de comportement (Vieillir(), Démarrer(), …) ces attributs
s’appellent aussi Opération.
Concepts et Formalisme
Classe, sous-classe, Attributs d’état, Opérations (ou Attributs de Comportement),
Liens d’héritage.
Règles de passage
Il faut retenir que :
 Tout Objet devient une Classe.
 Toute Relation de type N-N se transforme en Classe (image de Table) comme
en relationnel.
 Une Relation de type 1-n ne se transforme pas en Classe mais ses propriétés
deviennent les attributs de la classe A (Objet à la cardinalité maximale 1) puis
fait recevoir à cette classe l’identifiant de l’Objet B (Objet à cardinalité
maximale n).
Cependant selon les attributs d’une classe, celle-ci peut donner naissance à des
sous-classes.
Exemple :
Etudiant
Numéro
Nom
Prénom
Sexe
_____________________________________________________________________________________
Page 43 sur 69
Classe
ETUDIANT
Numéro
Nom
Prénom
ETUDIANTE ETUDIANT
Sexe Féminin Sexe Masculin
Vin : Code, Libellé, Degré → CL Vin(Code, Libellé) et SC1 (Liqueur) et 2 (Alcoolisée).

Cela dit, le MLD obtenu quelque soit son type est dit MLD Brut, il doit falloir
aboutir au MLD optimisé (ou affiné) afin d’améliorer les performances des accès
logiques.
Cependant, pour le faire, il faut disposer :
 Du MOT (Modèle Organisationnel des Traitements) voire une ébauche du
MOpT (Modèle Opérationnel des Traitements) qui précise les types et les
fréquences des accès aux Données puis le type de fonctionnement (Temps
Réel, ou Temps Différé) des Traitements.
 Des dénombrements d’occurrences (Record, Table, Fichier, Classe).
11 – Modèle Physique des Données (MPD)

11 – 1 Objectif et Principe
Il n’existe pas d’approche normalisée de description et de présentation du niveau
physique des données. Celles qui existent sont des approches individuelles et donc
sujets à discussion. En effet le description d’un MPD est étroitement liée aux choix
techniques informatiques concernant le système de gestion des données.
Dans la pratique professionnelle, le MPD se résout à élaborer une structuration des
tables qui elle-même se fait dans le langage du SGBD correspondant à la solution
choisie (Relationnel, Orienté Objet, … voire Réseau). Aussi, l’environnement
technique de développement influe largement dans la description du MPD. Cela
dit ; les outils suivants ont une influence sur l’environnement de développement :
 Outils de génération d’Ecran,
 Outils de Simulation,
 Outils de Génération de code (tel que WinDev).
Le MPD s’obtient donc à partir du MLD Optimisé.
11 – 2 Optimisation du MLD
Pour préparer le passage du MLD Brut au MPD, une étape intermédiaire peut se
faire : Elaboration du MLD Optimisé ou Affiné. Cette étape consiste donc à
optimiser l’organisation physique des Données afin de répondre au mieux aux
traitements mais aussi d’améliorer les performances des accès logiques. Pour cela,
on utilise le MPD Brut obtenu et, il doit travailler à partir des sorties demandées.
Exemples : Factures, Bulletin, Liste du Personnel, Relevé de Banque, …
_____________________________________________________________________________________
Page 44 sur 69
Puis des matériels et logiciels utilisés. C’est ainsi que l’élaboration du MLD Optimisé
portera sur : (avec la participation effective du gestionnaire).
 Les données calculées,
 La clé secondaire,
 La Redondance,
 Le Rapprochement physique.
Remarque : La démarche d’élaboration du MLD Optimisé abordé ici, est faite à
l’image du MLD Brut Relationnel.
11 – 2 – 1 Etude des Données Calculées

Ces Données dites Calculées doivent l’être lors des traitements, c’est pourquoi, on
doit se poser des questions suivantes :
 Est-ce que ces Données Calculées une fois calculées ne peuvent pas être
mémorisées afin d’accélérer les prochains ou les autres traitements ? et donc
éviter de les recalculer à chaque fois que le besoin se fera sentir ?
 Est-ce que les Données constantes nécessaires à nos calculs (TVA, …) ne
peuvent pas être mémorisées ?
Les réponses à ces questions sont liées à l’appréciation des critères suivants :
 La fréquence d’utilisation de la Donnée Calculée ;
 La complexité du Calcul ;
 Le Volume de la Table(Base) ;
 La possibilité de recalcule ultérieur.
11 – 2 – 2 Etude des clés secondaires

Ici, on va déterminer s’il est nécessaire de créer des clés secondaires en fonction
des traitements à effectuer. Cette notion correspond à celle d’Index sur critère
d’application, on l’appelle élément de navigation.
Exemple :
CLIENT(Numéro Client, Nom)
COMMANDE(Numéro Commande, #Numéro Client, Date)
11 – 2 – 3 Redondance calculée
Ici, on se propose de mettre dans une Table quelques attributs d’une autre Table.
11 – 2 – 4 Rapprochement Physique
Ce cas est envisagé lorsqu’on a deux Objets pour lesquels les cardinalités
maximales sont à 1 (*,1 ------- *,1) notamment celui de liaison parallèle.
Ici, il faudra faire une seule Table qui contiendra les attributs de ces deux Objets, ce
qui ferait gagner de la place et donc réduirait le nombre d’occurrences de même
nature bien que présent dans deux Objets différents. Toutefois, attention au
rapprochement à tous les coups car, les problèmes éventuels de réservation vide
de place et même de choix de clé de la Table nouvellement créée.
11 – 3 Structuration des Tables (Modèle Relationnel)

Ici, on vous demande de structurer chacune des tables de votre base de données.
Ainsi, structurer une table veut dire la nommer, nommer symboliquement chacun
_____________________________________________________________________________________
Page 45 sur 69
de ses attributs de préférence sans espace ni accent, déterminer le type et une
dimension à chaque attribut.
Nom Table Champs Type Longueur Observations
Nom d’Index ou de Repère : Critère :
11 – 4 Dictionnaire de Données
N° Ordre Désignation Mnémonique Type Longueur Observation
_____________________________________________________________________________________
Page 46 sur 69
Chapitre III : ETUDE DES BASES DE DONNEES RELATIONNELLES
1 – Présentation
La grande popularité des BD relationnelles SGBDR s’explique en 1 er lieu par
leur aptitude à supporter des langages d’interrogation puissants et déclaratifs,
s’orientant vers les outils normalisés tels que : La Norme S.Q.L. (Structured Query
Language : Langage d’Interrogation des Structures). Les SGBDR trouvent leur
fondement autour du SQL (langage assertionnel).
Ces SGBDR sont orientés valeur de Table, les résultats, des requêtes sont aussi
des Tables. Les opérations peuvent être combinées et chaînées pour résoudre les
requêtes complexes.
Une caractéristique du modèle relationnel est le fait d’être d’une grande
simplicité et l’absence de considérations physiques car le choix des organisations
physiques de base est généralement pris en charge par le système (SGBDR) lui-
même.
En SGBDR, on peut facilement faire évoluer le schéma conceptuel d’une
base (Ajouter, Supprimer un champ, Modifier les noms, type et dimension d’un
champ). On dit alors que le modèle relationnel autorise une grande dynamique de
la structure de la base soit en revenant à la phase de définition soit en utilisant le
langage de manipulation des données.
La description d’une base comprend obligatoirement la définition des
domaines sur lesquels les attributs prennent leurs valeurs et la définition des relations
(Tables). Sachez que les attributs d’une relation doivent tous porter un nom
différent, un type, une dimension et que chaque relation puisse avoir
obligatoirement une clé primaire.
Les SGBDR peuvent être construits d’une manière entièrement spécifique ou
obtenus en greffant une interface relationnelle sur un SGBD classique ; d’où
l’architecture générale d’un SGBDR suivante :
Programme d’application
Interface Relationnelle
SGBD Spécifique ou Classique
Accès à la Base de Données
Très schématiquement, on peut distinguer trois (03) niveaux de manipulation de

données sous forme relationnelle :
 Manipulation au niveau des tuples correspondant à un langage de très bas
niveau et nécessitant la connaissance des organisations physiques de base
(séquentielle, séquentielle indexée, directe, …) et des chemins d’accès.
_____________________________________________________________________________________
Page 47 sur 69
 Manipulation au niveau des relations (tables) par l’intermédiaire des
opérateurs de l’algèbre relationnelle qui agissent directement sur les relations
(Tables). L’utilisation de ces opérateurs ne nécessite pas la connaissance des
organisations physiques et des chemins d’accès. Cependant, pour résoudre
une requête, l’user doit préciser la succession des opérations à effectuer.
 Manipulation au niveau des requêtes (calcul relationnel) par l’intermédiaire
des prédicats (condition booléenne ou assertion à vérifier) spécifiant des
requêtes. L’user doit cependant préciser ce dont il a besoin sans indiquer les
différentes étapes nécessaires à la production du résultat; c’est lui-même
(SGBDR) qui produit l’algorithme à la résolution à partir des spécifications.
2 – Le Modèle Relationnel
2 – 1 Les Relations
Le modèle relationnel représente les données d’une base comme une collection
des relations (Tables).
Informellement, chaque relation peut être assimilée à une table. Une ligne de la
table est appelée « un Tuple » (Enregistrement). Un nom de colonne est appelé
« Un Attribut ». Les valeurs que peut prendre un attribut appartiennent à un
domaine.
2 – 2 Représentation des Objets (Entités) et des Relations

(Associations)
Une table telle que la table « Employé » peut être considérée comme une
représentation de l’objet « Employé » caractérisé par les attributs (Matricule, Nom,
Age, …). Mais une table peut aussi permettre de représenter les relations
(Associations) présentes dans les liens de type n-n entre deux objets.
Ainsi, pour exprimer qu’un employé exerce dans une entreprise parmi plusieurs
autres ayant pour caractéristiques (N° Registre, Raison sociale, Siège, …), il suffit de
faire :
EMPLOYE ENTREPRISE
Matricule Exercer Numéro Registre
1,1 1,n
Nom Raison sociale
Age Siège
EMPLOYE(Matricule, #Numéro Registre, Nom, Age)

ENTREPRISE(Numéro Registre, Raison sociale, Siège)
Plus généralement, pour représenter une association de type 1-n entre les objets A
et B, il suffit de propager dans l’objet fils la clé de l’objet père.
Pour représenter une association de type n-n, il faudra créer trois tables A, B et R qui
contiendra en plus de ces attributs éventuels, les clés des objets A et B constituant
ainsi sa clé.
_____________________________________________________________________________________
Page 48 sur 69
FOURNISSEUR PIECES
Code Numéro Pièce
1,n Approvisionner 1,n
Adresse Désignation
Prix
Délai livraison
FOURNISSEUR(Code, Adresse)
PIECES(Numéro Pièce, Désignation)
Approvisionner(Code,Numéro Pièce, Prix, Délai)
On remarque que la clé de la table Approvisionner est la juxtaposition des clés

propagées.
On dit qu’une clé est propagée lorsqu’elle est étrangère c'est-à-dire primaire dans
une autre table (Numéro Registre est propagé dans Employé).
Notez enfin que les clés propagées ou étrangères constituent une forme de
redondance obligatoire et il est indispensable de contrôler systématiquement celle-
ci.
2 – 3 Définition en Extension d’une relation

Une relation peut être définie en extension conformément à la vision tabulaire. Soit
un ensemble (A1, A2, …, An) d’attributs, chaque Ai prenant ses valeurs dans un
certain domaine noté Dom(Ai).
Une relation R sur (A1, A2, …, An) est donc un sous ensemble du produit cartésien
du domaine associé aux attributs.
A1 A2 … An
Tuples
Définition en Exetension
Chaque Tuple T de la relation R est une suite des valeurs T=<V1,V2, …, Vn> où Vi est
soit une valeur du domaine Dom(Ai) soit une valeur nulle. Il existe des règles
appelées contraintes d’intégrité qui permettent de décider parmi les éléments du
produit cartésien ce qui appartient à R et ce qui n’appartient pas à R.
NB : Une contrainte d’intégrité est une règle assertionnelle ou une condition que
doit vérifier une Donnée contenue dans la Base.
Exemple : Unicité de clé, attribut clé non nul, âge compris entre 16 et 60 ans. Une
relation est généralement notée sous forme R(A1, A2, …, An). Cette notion est
appelée Définition en Intention.
Grâce à cette notion basée sur les attributs, l’ordre des colonnes est indifférent. Le
degré d’une relation est égal à N (Nombre d’attributs) et sa cardinalité est égale
au nombre de Tuples.
_____________________________________________________________________________________
Page 49 sur 69
Exemple : Employé Définition en Extension
Matricule Nom Age Service

1100 MBERI 30 INFORMATIQUE
1119 MAKOSSO 25 COMPTABILITE
1110 AYESSA 42 PRODUCTION
1150 MASSAMBA 24 INFORMATIQUE
1152 OKOSSO 25 PERSONNEL
Sa définition en Intention est la suivante :

EMPLOYE(Matricule, Nom, Age, Service)
La définition en Extension est bien adaptée pour présenter les diverses possibilités de
manipulation d’une Table. Elle se relève insuffisante pour étudier les propriétés des
relations et en particulier leurs normalisation. Il est alors nécessaire de s’appuyer sur
une définition en intention de la Table privilégiant la structure et les contraintes
d’intégrité.
2 – 4 Définition en Intention d’une Table

Elle correspond à la notion des schémas des relations. Un schéma de relation R
repose sur trois (03) éléments :
 Un ensemble d’attributs (A1, A2, A3, …, An)
 L’affectation d’un domaine Dom(Ai) à chaque attribut (Ai)
 Un prédicat R de T qui pour tuple (t) défini sur l’ensemble des attributs
fournissent une valeur vraie ou fausse permattant ainsi de décider de
l’appartenance de t à R.
NB : Le prédicat est une assertion (condition) équivalente à la contrainte d’intégrité

formulée sur R.
R(A1, A2, …, Rn) → en Intention :
Exemple :
Employé(Numéro Employé, Nom Employé, Age)
A1 A2 … An
En extension
Exemple : EMPLOYE
Numéro Nom Age

015 NIAKISSA 25
025 MBANZOUMOUNA 24
030 LEBANI 24
La définition en Extension est bien adaptée pour présenter diverses possibilités

de manipulation d’une relation. Cependant, elle se relève insuffisante pour étudier
_____________________________________________________________________________________
Page 50 sur 69
les propriétés (rubriques ou attributs) des relations en particulier leur normalisation
(les Formes Normales).
Il est alors nécessaire de s’appuyer sur une définition en Intension privilégiant
la structure d’intégrité.
Exemple :
ETUDIANT MATIERE
Obtenir Code
0,n 0,n
Numéro Note Libellé
Nom
Prénom
Date de naissance
0,n
EXAMEN
1,n
Code Examiner
Libellé Date
Coefficient
2 – 5 Normalisation
2 – 5 – 1 Présentation
On fait généralement l’hypothèse que les valeurs des attributs sont simples
c’est-à-dire insécables (non décomposables). Au cours des manipulations, ces
valeurs peuvent être décomposées, une relation dont tous les attributs sont simples
est dite Normalisée en 1FN.
Il existe cependant des extensions du modèle relationnel pour lesquels cette
hypothèse est levée.
Exemple : Un nom de relation peut apparaître comme nom d’attribut dans une
autre Table.
De telles extensions permettent la composition l’imbrication des relations. C’est
pourquoi, nous allons tour à tour étudier :
 L’intérêt de la Normalisation ;
 Problèmes de redondance ;
 Problèmes de valeurs nulles ;
 Les dépendances et les Formes Normales.
2 – 5 – 2 Intérêt de la Normalisation
Outre la suppression des problèmes de la MAJ, la Normalisation présente un autre
intérêt : celui de minimiser l’espace de stockage pour une relation. Cette
normalisation entraîne en général un nombre plus grand d’enregistrements, mais un
nombre total d’occurrences plus faible. Il faut bien remarquer en effet que, la taille
des Tables Normalisées croît de façon arithmétique alors que la taille des Tables non
Normalisées croît de façon géométrique.
_____________________________________________________________________________________
Page 51 sur 69
2 – 5 – 3 Les Outils de la Normalisation
2 – 5 – 3 – 1 Problèmes de Redondance
En dehors des clés étrangères, un schéma relationnel peut comporter des éléments
redondants. Cette redondance induit généralement des difficultés relatives aux
problèmes de MAJ.
Exemple : Soit Commande(NOP, Quantité, NOMFOUR, ADRFOUR).
Cette relation présente un certain nombre d’anomalies :

 Anomalies de modification : si l’on souhaite mettre à jour l’adresse d’un
Fournisseur, il faut le faire pour tous les tuples relatifs à ce Fournisseur. Ceci est
dû au fait que la relation fait intervenir ses données en redondance.
 Anomalies d’Insertion : pour introduire le nom et l’adresse d’un Fournisseur, il
faut également fournir une valeur pour chacun des attributs NOP et quantité
ou introduire des valeurs nulles, ce qui pose d’autres problèmes du genre
aucune pièce n’a un NOP nul.
 Anomalies de Suppression : par exemple : la suppression de la pièce de
NOP=102 fait perdre toute information concernant le Fournisseur Dupont.
NOP Quantité NOMFOUR ADRFOUR

101 10 Durand 10 Rue Mpouya
102 20 Dupont 15 rue Loussala
Ces anomalies proviennent du fait qu’on a voulu rassembler dans une relation des
attributs qui ne caractérisent pas un même Objet. Il est alors urgent d’y remédier en
décomposant cette relation en deux autres qui sont :
 PIECECOM(NOP, #NUFOUR, Quantité)
 FOURNISSEUR(NUFOUR, NOMFOUR, ADRFOUR)
Au cas où vous avez déjà dans votre base ce type de relation (Commande),
décomposez-les.
Ici, la décomposition se reposera sur deux opérations élémentaires de l’algèbre

relationnelle que sont : La Projection et la Jointure.
2 – 5 – 3 – 2 Problèmes de Valeurs Nulles

Dans un certain nombre de situation, il n’est pas possible d’attribuer une valeur nulle
à un attribut lorsqu’un Tuple est créé. On dit alors que la valeur de la clé attribut est
nulle ou indéterminée. Une valeur indéterminée peut avoir diverses interprétations
telles que :
 L’attribut ne s’applique pas au Tuple créé ;
 La valeur de l’attribut n’est pas connue pour ce Tuple ;
 La valeur est connue mais n’a pas encore été enregistrée.
_____________________________________________________________________________________
Page 52 sur 69
La présence des valeurs indéterminées induit de nombreuses difficultés de
traitement, particulièrement lors des jointures entre Relations et lors des Calculs
avec les fonctions d’Agrégat.
Aussi, il est indispensable, soit d’éviter des valeurs indéterminées, soit de prévoir des
traitements spécifiques pour ces valeurs. Toutefois, il est interdit d’attribuer une
valeur nulle à un attribut clé d’une Relation quelque soit le Tuple.
2 – 5 – 3 – 3 Les Dépendances
Les principales dépendances qui peuvent être mises en évidence dans une
relation (Table) sont les Dépendances Fonctionnelles (DF), encore appelées
Contraintes d’Intégrité Référentielle (CIF) et les Dépendances Multivaluées (DM).
D’autres ont été définies, ce sont : Dépendance de Produit, Dépendances
Hiérarchiques et Dépendances d’Inclusion.
Les Dépendances Fonctionnelles

Soit R(x,y,z), une Relation. On dit que y dépend fonctionnellement de x et on note
x→y si c’est toujours la même valeur de y qui est associée à une valeur de x dans R.
Une DF spécifie une contrainte sur les valeurs possibles des tuples d’une relation.
Exemple : Compagnie(Numéro Vol, Numéro Avion, Numéro Pilote)

Vol → Avion Vol → Pilote Avion → Pilote
Il est important de remarquer que les DF résultent des hypothèses sémantiques

choisies pour modéliser le monde réel. On dit donc que la DF est un lien entre
attribut de relation, alors qu’une CIF est un lien obligatoire défini par l’organisme
d’études à travers ses choix de gestion ; c’est ainsi qu’on dit qu’une CIF s’impose au
concepteur lors de la conception du MCD, qui se doit de l’exprimer sur ce dernier.
La DF ou la CIF permet de symboliser le lien entre deux ou plusieurs objets.
Ainsi, si l’on suppose qu’un avion peut être piloté par des pilotes différents, la DF
Avion → Pilote disparaît.
On dit enfin que les DF vérifient un certain nombre de propriétés remarquables

suivantes : soit la relation R(x,y,z,t).
 Réflexivité : x → x ;
 Augmentation : si x → y alors xz → yz ;
 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 x → y,z alors x → y et x → z.
Les trois premières sont encore connues sous le nom de règles d’inférence
d’AMSTRONG. Elles constituent un ensemble valide et complet. La validité
correspond à la propriété suivante : étant donné un ensemble F de dépendances
vérifiées sur une relation R, alors toute dépendance inférée de F est aussi vérifiée sur
R.
_____________________________________________________________________________________
Page 53 sur 69
La complétude signifie que toute dépendance qui est la conséquence d’un
ensemble F, peut être obtenue par applications répétées de ces trois règles.
Les Dépendances Multivaluées

Cette notion généralise celle des DF. On dit qu’il existe une DM entre x et y et on
note x −>> si la connaissance de la seule valeur de x, indépendamment de celle
des autres sous ensembles d’attributs, détermine un ensemble de valeurs relatives à
l’attribut y.
Exemple : Soit Etudiant(Nom, Langue, Sport)
Nom Langue Sport Considérons cette relation où l’on

MAHOUNGOU Anglais Basket suppose maintenant que chaque
MAHOUNGOU Anglais Tennis Etudiant étudie un ensemble de
MAHOUNGOU Allemand Boxe langues et pratique un ensemble
BAYONNE Anglais Karaté de sport. Les DM seront donc :
BAYONNE Russe Karaté Etudiant −>> Langue,
SITA Arabe Football Etudiant −>> Sport.
SITA Espagnol Judo
2 – 5 – 4 Déterminants et Clés
Un attribut y est totalement dépendant de l’attribut x si la DF x → y est élémentaire.
Ainsi, on appelle déterminant, tout attribut V tel qu’il existe un attribut totalement
dépendant de V.
Puisqu’une relation est un ensemble des tuples distincts les uns des autres, il existe
alors une clé, sous ensemble minimal d’attributs de la relation dont les valeurs
permettent de distinguer les tuples des autres. Il peut exister plusieurs clés différentes
pour une même relation. Toutes les clés potentielles appelées clés candidates ;
parmi celles-ci, une d’elles est arbitrairement choisie comme clé dite Primaire :
toute clé de relation doit être soulignée.
Exemple : Employé(Numéro Employé, Nom, Age, Adresse)

Obtenir(Numéro Etudiant, Code Matière, Note)
2 – 5 – 5 Les Formes Normales

Il faut retenir qu’il y a deux façons d’obtenir les tables : par le MCD et le MLD
relationnel mais on peut aussi directement constituer des tables sur la base du flair ;
pour ce faire, il est conseillé d’appliquer les FN proposées par CODD et KENT.
Ainsi, les anomalies de MAJ peuvent être étudiées à partir des dépendances ; mais
les FN ont été suggérées pour résoudre ces différents types d’anomalies.
La classification des FN se repose sur la nature des dépendances existant entre la
clé et les autres attributs de la relation dans le but de mieux regrouper les attributs
en table normalisée.
Première Forme Normale (1FN)

Une relation R est en 1ère FN si tout attribut n’est pas décomposable : élémentaire et
non calculé.
_____________________________________________________________________________________
Page 54 sur 69
Deuxième Forme Normale (2FN)
Une relation R est en 2ème FN si et seulement si tout attribut non clé est totalement
dépendant de la clé de R.
Exemple : Employé(Matricule, Nom, Prénom, Age) est en 2FN

Cependant Commande(NOP, Quantité, Adrfour) n’est pas en 2FN ca nous avons
des DF non similaires : NOP → Quantité et NUFOUR → Adrfour.
D’où la création de deux relations :
 PIECECOM(NOP, #NUFOUR, Quantité)
 FOURNISSEUR(NUFOUR, Adrfour)
Cependant, une relation en 2FN n’est pas exempte d’anomalies : par exemple la
relation Compagnie(Vol, Avion, Pilote) avec les DF Vol→Avion, Avion→Pilote et
Vol→Pilote est en 2FN mais présente encore des anomalies de MAJ. Il n’est pas
possible d’introduire un nouvel avion sur un nouveau vol sans préciser le Pilote
correspondant. La 3FN résoudra ce problème.
Troisième Forme Normale (3FN)

Une relation R est en 3ème FN si pour chaque DF x →a, x est toujours clé c'est-à-dire
qu’il ne doit pas exister de DF des attributs non clé, les DF entre les attributs non clés
conduisent à la création d’une 2ème relation avec y → a.
Exemple :
Compagnie(Vol, Avion, Pilote) n’est pas en 3FN, nous avons deux relations.
Compagnie1(Vol, Avion)
Compagnie2(Avion, Pilote)
Cette décomposition n’est pas totalement satisfaisante car, elle fait perdre la DF
Vol → Pilote. Les problèmes de MAJ déjà signalés proviennent justement de cette
situation. Toutefois avec les relations Compagnie1, on vérifie aisément grâce à la
propriété de transitivité que cette décomposition permet effectivement de
retrouver toutes les DF initiales. D’où la création de Compagnie3(Vol, Pilote).
Troisième Forme Normale BOYCE-CODD-KENT (3FN BCK)

Une relation n’est pas exemptée de toutes anomalies.
Exemple : CP(Ville, District, Code)
Ville District Code

MADZIA KINKALA 1150
KIBOSSI KINKALA 1150
MPANDI MOUYONDZI 2560
Cependant, si on supprime le 3èmeTuple, on perd la liaison entre le District et le

Code. De même, on ne peut introduire un District et un Code que si on donne le
nom de ce District. Ainsi, la 3ème FNBCK ressoude ce type de problème.
Une relation R est en 3FNBCK relativement à un ensemble D de D(f), si pour chaque
D(f) x → a de l’ensemble D tel que x, a (ce sont des attributs), x est une clé de R.
In n’existe pas toujours pour une relation R, une décomposition en relations 3FNBCK
qui préservent les DF. Alors CP sera décomposée en :
CP1(Code, District)
_____________________________________________________________________________________
Page 55 sur 69
CP2(Code, Ville)
On constate que, on a perdu la DF Ville, District → Code.
Quatrième Forme Normale (4FN)

Les relations qui possèdent des DM échappant aux normalisations 1, 2, 3 et peuvent
cependant représenter des anomalies de MAJ. Ainsi, la relation ETUDIANT ayant les
attributs :
Etudiant(Nom, Langue, Sport) avec les DM suivants :
Nom −>> Langue, Nom −>>Sport.
Cette relation échappe aux normalisations 1,2 et 3FN mais elle est en 3 ème FNBCK.
Pourtant, en raison de multiples redondances, les problèmes de MAJ subsistent. La
4FN est une généralisation de la 3ème FNBCK pour les relations présentant les DM.
R est en 4FN relativement à un ensemble D de D(f) et DM, si pour toutes DM non
triviales, x ─>> y de D tel que x, y (des attributs), x est une super clé de R
relativement au D(f) de D.
La DF étant un cas particulier de DM, toute relation en 4FN est aussi en 3ème FNBCK
et en 3FN.
On montre que toute relation qui n’est pas en 4FN peut être décomposée en
relations en 4FN.
Exemple :
Etudiant1(Nom, Langue)
Etudiant2(Nom, Sport)
En conclusion, noter qu’il existe aussi la 5FN.
2 – 6 Contraintes d’Intégrité
Une CI est une assertion ou condition que doit vérifier une Donnée contenue dans
la Base.
Pour définir complètement une relation R, il est nécessaire de préciser toutes les CI
que doivent vérifier les tuples. Ces contraintes sont des règles qui permettent de
vérifier la validité des opérations de MAJ (Ajout, Modifier, Supprimer) d’une relation.
Exemple :
 Selon la législation du travail, l’âge d’un Employé doit être compris entre 18 et
60 ans dans la relation Employé.
 La note d’un étudiant à une matière ou à une évaluation doit être comprise
entre 0 et 20 dans la relation évaluer.
Les CI peuvent être de nature très diverses et faire intervenir :
 Un seul attribut de la Relation ;
 Plusieurs attributs de la Relation ;
 Des attributs des relations différentes.
Les formes de CI sont :
Les contraintes structurelles
 La contrainte de clé (Unicité de clé) ;
 La Contrainte d’Entité (la valeur de l’Attribut Clé Primaire doit être non nulle) ;
 La contrainte de Référence (Clé étrangère d’une Relation correspond à la
Clé Primaire d’une autre Relation de la Base) ;
_____________________________________________________________________________________
Page 56 sur 69
 Contrainte de domaine ;
 Contrainte de non nullité.
Les contraintes non structurelles :
 Dépendance fonctionnelle ;
 Dépendance multivaluée ;
 Dépendance d’inclusion ;
 Contrainte temporelle ;
 Contrainte équationnelle.
Quelques systèmes tel que : DB2 d’IBM permettent de spécifier les contraintes sous
la forme assertionnelle. Pour les systèmes n’offrant pas cette facilité, les contraintes
sont exprimées à travers des procédures écrites dans le langage de
Programmation.
2 – 6 – 1 Contraintes Structurelles
Une contrainte structurelle fait partie intégrante du modèle relationnel et s’applique
sur les structures de base (table, attribut, ligne). Elles permettent d’exprimer
explicitement certaines propriétés (contraintes) des relations et des domaines des
attributs. On en distingue :
Unicité de clé
Cette contrainte stipule qu’il doit y avoir un attribut ou un ensemble d’attributs non
nul dont la valeur permet de déterminer un tuple unique dans une table.
Exemple :
Emprunt(Matricule, Date Emprunt, Montant)
Clé Multi attribut
Vins(Numéro Vin, Cru, Degré)
Clé Mono attribut
Intégrité de Référence
On définit plus précisément la notion de clé étrangère : appelons Domaine
Primaire, un domaine sur lequel une clé primaire est définie ; un attribut clé défini sur
un Domaine Primaire et qui n’est pas une clé primaire correspond à une clé
Secondaire (Etrangère, Propagée).
Une relation R est dite Primaire s’il existe une autre relation ayant comme clé
étrangère la clé primaire de R.
Exemple :
Commander(Numéro Commande, Montant, Datecom, #Numéro Client)
Clé primaire Clé secondaire
Client(Numéro Client, Nom, Prénom, Adresse)
_____________________________________________________________________________________
Page 57 sur 69
Certaines manipulations sur une relation qui possède une clé étrangère ne sont
possibles que si les valeurs de cette clé apparaissent dans la relation Primaire de la
Base.
D’où, le principe d’intégrité de référence énoncé par CODD :
« Soit une relation R1 ayant une clé primaire X multi attributs. Si l’attribut A de X est
définit sur un Domaine primaire D alors, pour chaque valeur K de A dans R1, il doit
exister une relation R2 dans la Base avec une clé primaire Mono attribut définit sur D
ayant K comme valeur. On dit souvent que la relation R1 est référençante et que la
relation R2 est référencée et que A est un attribut référençant ».
Exemple :
R1(référençante)=Commander(N°Cde, Montant, #N°Clt, Datecom)
R2(référencée)=CLIENT(N°Clt, Nom, Prénom, Adresse)
Attribut référençant=N°Clt
Contrainte de Domaine
Elle permet de restreindre la plage des valeurs du domaine d’un attribut. En
général, un domaine est défini par un type et un éventuel domaine de variation
spécifié par une contrainte de domaine. Une CD peut simplement préciser la liste
des valeurs permises ou une plage de valeurs permises à un attribut.
Exemple : NOMET peut avoir MAVOUNGOU, MASSAMBA, NKOUIKA.

NOTEOB doit être <=20.
Contrainte de non Nullité

Elle spécifie que la valeur d’un attribut doit toujours être renseignée.
Contraintes Non Structurelles

Elles traitent de l’évolution des données suite aux MAJ. Elles sont souvent appelées
contraintes de comportement. C’est donc une série de contraintes d’intégrité
exprimant une règle d’évolution que doivent vérifier les données lors de leur
insertion. Ce sont :
Dépendances Fonctionnelles, Dépendances Multivaluées
 Dépendances d’Inclusion : elles permettent de spécifier que les valeurs d’un
groupe de colonne d’une table doivent rester incluses dans celle (valeur)
d’un groupe de colonne d’une autre table. Exemple : Localité(Code, libellé),
Etudiant(Numéro, nom, prénom, lieu de naissance), un Etudiant qui déclare
un lieu de naissance ne peut appartenir que dans Localité.
 Contraintes Temporelles : elles font intervenir la notion de temps. Elles
permettent de comparer l’ancienne valeur d’un attribut à la nouvelle valeur
après MAJ. Exemple : le salaire d’un agent ne peut croître au cas où on le
décidait.
 Contraintes Equationnelles : il s’agit là de comparer deux expressions
arithmétiques calculées à partir des données de la Base et de forcer l’égalité
ou l’inégalité. Exemple : Sur Produit, on peut exprimer le fait que la quantité
en Stock soit égale à la Somme des Quantités achetées Ŕ Somme des
quantités vendues.
_____________________________________________________________________________________
Page 58 sur 69
Moment d’Expression de ces CI
Lors de la création des tables. Il y en a qu’on exprime dans une fenêtre (ou
formulaire).
3 – Présentation des Composants d’une Base de Données Relationnelle

3 – 1 Définition (Description) d’une BD Relationnelle
Sa définition consiste simplement à décrire séparément les différentes relations qui
la composent.
Une relation est décrite par son nom alphanumérique de préférence sans espace ni
accent et par les noms de ses attributs aux mêmes caractéristiques.
Une clé (Attribut clé) doit être unique c'est-à-dire que lorsqu’on définit que tel
attribut est clé de telle relation, la valeur de cet attribut pour chaque Tuple doit être
différente.
3 – 2 Notions d’Index d’une Relation

Une possibilité est donnée aux BD Relationnelles de créer des Index avec des
relations de la BD sur tout groupe d’attributs. Ainsi, ces index permettront de rendre
très rapide l’accès aux Informations des relations et donc d’améliorer les temps de
réponse, même si par ailleurs, les index provoquent l’accroissement du volume de
la Base à cause de la Table d’index résultante de l’indexation.
3 – 3 Notions de Vue d’une Relation

Une autre possibilité offerte par les BD Relationnelles est de créer des vues sur
des relations. Une vue est assimilée à une relation virtuelle construite sur des relations
réelles pour répondre aux besoins précis des Programmes d’application (cas de vos
requêtes en Access).
Elle est virtuelle en ce sens qu’elle n’est pas créée sur le Disque Dur comme
les autres relations. En effet, seule sa définition (sa description) est mémorisée sur
Disque mais ne sera en mémoire et plus tard à l’écran que le résultat de l’exécution
de la requête la définissant.
C’est donc ce résultat qu’on manipulera comme toutes les autres relations.
On dit donc qu’une Vue est obtenue en application d’une requête (demande) de
l’utilisateur notamment en combinant arbitrairement des relations réelles par les
opérateurs de l’algèbre relationnelle.
D’où une vue présente trois principaux intérêts qui sont :
 La simplification de l’accès aux données car étant donné qu’une vue
correspond à la vision simplifiée pour l’usager, alors elle permet à celui-ci de
manipuler plus commodément la base.
 Support de l’indépendance logique car elle permet de dissimuler aux usagers
non avertis tous les problèmes résultant des jointures entre relations. Ainsi,
grâce aux vues, une même base peut être perçue de manières différentes.
 Renforcement de la sécurité des données car les vues offrent une
contribution supplémentaire pour la mise en place des procédures de
sécurité, en permettant d’inhiber (interdire, empêcher) l’accès à certaines
données pour certains usagers.
_____________________________________________________________________________________
Page 59 sur 69
3 – 4 Exemple de Définition de Vues
3 – 4 – 1 Définition d’une Vue créée sur une Relation
Pièce(NOP, Désignation, Couleur, Poids)
CREATE VIEW Pieceleg(NOP, Désignation, Couleur, Poids) AS SELECT NOP,

Désignation, Couleur, Poids FROM Pièce WHERE Poids<50 ;
(Vue Pieceleg des pièces de poids<50).
CREATE VIEW Pieceleg1(NOP, Désignation, Couleur, Poids) AS SELECT NOP,

Désignation, Couleur, Poids FROM Pièce WHERE Poids>50 AND Poids<=50 ;
(Vue Pieceleg1 des pièces de poids<50 et <=100).
3 – 4 – 2 Définition d’une Vue créée sur deux Relations

Pièce(NOP, Désignation, Couleur, Poids)
Et
Demander(NOP, NOS, Datdem, Qtedem)
On veut avoir dans piececom, les pièces demandées avec leurs quantités et
services qui ont passé la commande.
CREATE VIEW Piececom(NOP, Désignation, Couleur, NOS, Qtedem) AS SELECT

Pièce.NOP, Pièce.Désignation, Pièce.Couleur, Demander.NOS, Demander.Qtedem
FROM Pièce, Demander WHERE Pièce.NOP = Demander.NOP ;
3 – 5 Conseils Pratiques
Une vue peut être MAJ, mais certains SGBDR imposent des règels restrictives pour
autoriser une MAJ d’une Vue ; ce sont (Règles) :
 Le mot DISTINCT doit être absent de la définition ;
 La clause FROM doit faire référence à une seule relation sur laquelle les
opérations de MAJ sont autorisées ;
 <l’élément de Sortie> dans la clause AS SELECT doit être une référence
directe à l’une des colonnes de la relation sous-jacente : les colonnes
calculées sont prohibées ;
 Les clauses GROUP BY et HAVING doiventêtre absentes.
En conclusion, les SGBDR proposent rarement une séparation entre la définition et la
manipulation de la base. Les langages relationnels sont généralement très intégrés
et rassemblent au même niveau les commandes de définition et de manipulation.
Il en résulte une grande dynamique d’utilisation : les tables, les index et les vues
peuvent être créés à tout instant et utilisés aussitôt sans passer par de longues
phrases de compilation.
Une relation peut être restructurée (ajout ou retrait de champs, …) en interactif et
réutilisée immédiatement.
4 – Opérations de Mise à Jour (MAJ)

Tout langage doit comprendre les opérations de MAJ pour permettre toute
manipulation sur la base ; ce sont :
_____________________________________________________________________________________
Page 60 sur 69
 Insertion (Ajout des données) : si une insertion ne respecte pas une contrainte
d’intégrité, deux attitudes sont possibles à savoir rejeter l’insertion en
fournissant la cause du rejet à l’usager ou corriger la cause du rejet. Par
exemple, si une valeur nulle est introduite pour un attribut clé, le système peut
inviter l’usager à introduire une valeur non nulle, cependant dans ce cas, la
correction serait difficile à mettre en œuvre avec la contrainte de référence
pour cause de correction en cascade ;
 Suppression de données qui ne peut concerner que la contrainte de
référence lorsque le tuple supprimé est référencé ;
 Modification de données : une modification d’un attribut qui n’est ni clé
primaire, ni clé étrangère (ou propagée) n’induit à aucun problème. Si une
valeur de clé primaire est modifiée, les problèmes se ramèneront à ceux
d’une suppression et d’une création. Si une valeur de clé étrangère est
modifiée, le SGBDR doit s’assurer que la nouvelle valeur fait référence à un
tuple existant dans la relation référencée.
5 – L’Algèbre Relationnelle
Elle est aux relations, ce qu’est l’arithmétique aux entiers. En effet les bases de
Données Relationnelles trouvent leur fondement dans elle. C’est un ensemble
d’opérateurs qui s’appliquent aux relations (tables) dans leur totalité. Ces
opérateurs peuvent être utilisés pour sélectionner des tuples dans une relation ou
pour combiner des tuples de relations différentes. Le résultat de chaque opération
est une nouvelle relation qui peut à son tour être manipulée par les mêmes
opérateurs.
Il existe trois groupes d’opérateurs :
 Les opérateurs issus de la théorie des ensembles (Union, Intersection, Division,
Produit Cartésien, Différence) ;
 Les opérateurs spécifiques (Projection, Sélection, Jointure) ;
 Les Extensions (Eclatement, Complément).
Remarque :
Si vous rencontrez un astérisque (*) dans une requête, cela signifie une alternative
permettant de retenir tous les attributs de la table définie dans la clause FROM.
DISTINCT permet d’éliminer les lignes en double ; cependant ALL permet de
conserver les lignes en double.
_____________________________________________________________________________________
Page 61 sur 69
5 – 1 Opérateurs de la théorie des ensembles
5 – 1 – 1 Union
L’Union de deux relations R et S de même structure est une Relation T de même
structure contenant l’ensemble des tuples qui appartiennent soit à R, soit à S, soit
aux deux relations. L’union est commutative.
T Ceci consiste à prendre les N-Uplets de R,

puis ceux de S et de les mettre tous dans
T (Relation résultante).
U Select * FROM R UNION Select * FROM S
R S
5 – 1 – 2 Intersection
L’Intersection de deux relations R et S de même structure est une relation T de
même structure contenant l’ensemble des tuples qui appartiennent à la fois à R et
à S. l’intersection est commutative.
T Ceci consiste à prendre les N-Uplets identiques
que l’on trouve dans R et dans S et de les mettre
dans T.
∩ Select * FROM R INTERSECT Select * FROM S
R S
5 – 1 – 3 Diffrérence
La Différence entre deux relations R et S de même structure est une relation T de
même structure contenant des tuples qui appartiennent à R et qui n’appartiennent
pas à S. La Différence est non commutative.
T Cela consiste à mettre dans le relation T tous

les N-Uplets de R non présents dans S.
─ Select * FROM R MINUS Select * FROM S
R S
_____________________________________________________________________________________
Page 62 sur 69
5 – 1 – 4 Division
La Division de la relation R par la relation S contenant des attributs de R est une
relation T formée sur les attributs de R qui n’appartiennent pas à S. Les tuples de T
correspondent aux tuples de R ayant la même structure que T.
T Cela consiste à supprimer les attributs de R
présents dans S et T aura pour attributs le
reste d’attributs puis ses Tuples
correspondent aux tuples de R sur le reste
. d’attributs.
.
R S
5 – 1 – 5 Produit Cartésien
Le Produit Cartésien de deux relations R et S de structure quelconque est une
relation T ayant pour attributs la concaténation des attributs de R et de S. les tuples
de T sont obtenus par différentes concaténations possibles entre un tuple de R et un
tuple de S.
T Cela consiste à présenter T constituée des attributs

de R et de S, puis de répéter chaque tuple de R en
autant de tuples de S, en compétant les N-Uplets
par les valeurs des N-Uplets de S correspondant.
X
R S
5 – 2 Les Opérateurs Spécifiques

5 – 2 – 1 La Projection
La Projection d’une Relation R sur un ensemble d’attributs a, b, c, … est une relation
T ne contenant ces attributs (a, b, c, …). Les tuples de T sont obtenus à partir de
ceux de R par élimination des valeurs des attributs de R n’appartenant pas à T et
par suppression des tuples en double.
T (a, b, c) choisir certains attributs de R dont on

souhaite voir dans T qui n’aura pour
attributs que ceux de la projection.
a, b, c
R (a, b, c, d, e, f)
_____________________________________________________________________________________
Page 63 sur 69
5 – 2 – 2 La Sélection (ou Restriction)
La Restriction d’une relation par une Qualification Q est une relation T de même
structure que R. T sera constituée des tuples de R satisfaisant la qualification Q.
Q est une condition booléenne de la forme :
<Nom-Attribut><Opérateur de comparaison><Constant>/<Nom-Attribut>
Des Q complexes peuvent être obtenues par combinaison de Q élémentaires à
l’aide des opérateurs booléens (ET, OU, NON).
T L’objectif de la sélection est de présenter dans T

les tuples de R satifaisant à Q posée sur la relation
R.
Q Select * From R Where <Q>
5 – 2 – 3 La Jointure
La jointure de deux relations R et S selon une Qualification Q est une relation T
constituée par l’ensemble des tuples du produit cartésien R x S satisfaisant Q. la
jointure est commutative.
T Produit cartésien R x S → T
Faire Restriction suivant Q sur T.
Select * From R, S Where <Q>

Q
R S
5 – 3 Fonctions d’Agrégat et Clause de Groupement

Un certain nombre de requêtes ne peuvent pas être exprimées avec les opérateurs
standard de l’algèbre relationnelle ; d’où :
5 – 3 – 1 Fonctions d’Agrégat
Elles permettent d’effectuer des calculs mathématiques sur des valeurs d’attributs
ou d’occurrences (Tuples) des relations. On peut citer quelques uns :
 MIN() : renvoie le minimum ;
 MAX() : renvoie le maximum ;
 SUM() : renvoie la somme des valeurs ;
 AVG() : renvoie la moyenne des valeurs ;
 COUNT() : renvoie le nombre des valeurs ;
_____________________________________________________________________________________
Page 64 sur 69
5 – 3 – 2 Clause de Groupement
La Clause de Groupement permet de regrouper en sous-ensembles les tuples
présentant des mêmes valeurs sur un sousŔensemble d’attributs, puis d’appliquer
une fonction d’agrégat à chacun de ces sous-ensembles.
GROUP BY suivi quelque fois HAVING ou de ORDER BY.
5 – 3 – 3 Fermeture Récursive
Ce type d’opérateur concerne les associations récursives sur un même objet, par
exemple l’association Nomenclature sur les pièces. Admettons qu’on nous
demande de retrouver toutes les pièces intervenant dans l’assemblage
(composition) d’une pièce donnée, nous serions obligé de faire une opération de
fermeture récursive car avec les opérateurs standard de l’algèbre relationnelle, il ne
nous sera pas possible de spécifier une telle requête surtout à cause du mécanisme
de bouclage nécessaire. On dit que certaines versions de SQL (notamment SQL+)
et le langage « ORACLE » offrent cet opérateur : CONNECT BY.
Nomencla(NOPA, NOPC, Niveau, Quantité)
Pièces intervenant dans la composition de la pièce P7.
SELECT NOPC FROM Nomena WHERE CONNECT BY PRIOR NOPC = NOPA START WITH
NOPC = ‘’P7’’ ;
Ici Prior donne le sens de parcours: se positionner d’abord sur NOPC.
Pièces intervenant dans la composition de la pièce P7 avec son niveau dans la
hiérarchie.
Select NOPC, Niveau, Quantité From Nomencla Where CONNECT BY Prior NOPC =
NOPA Start With NOPC = ‘’P7’’ ;
5 – 4 Opérateurs Arithmétiques
Les opérateurs arithmétiques (+, -, *, /) sont très utiles pour spécifier des calculs
divers sur les données extraites de la Base. La plupart des Langages Relationnels
commercialisés offrent ce type de possibilité.
6 – Calcul Relationnel
Ce calcul est basé sur le calcul des prédicats. Un prédicat est une condition
booléenne de la forme : X=1 et Y=0 → X=1 AND Y=0.
Voyons ici donc les principes fondamentaux du calcul relationnel.
6 – 1 Calcul des Prédicats

En logique, un prédicat est l’expression d’une propriété (Qualification) permettant
de réunir tous les objets qui la possèdent. Un tel objet est dit Prédiqué, il est un
argument du prédicat. Un prédicat peut avoir plusieurs arguments. Un prédicat
n’est ni vrai ni faux en lui-même.
Mais on asserte (propose) qu’un objet particulier (par exemple le nombre 10) est
prédiqué par le prédicat P (par exemple « Est un Entier »), on obtient une
proposition P(a) (par exemple « 10 est un Entier ») qui est soit vraie soit fausse.
Exemple : soit l’existence de la table Etudiant, on peut vouloir effectuer des
extractions (sélection ou restriction) des étudiants suivant certaines conditions du
genre :
 Etudiants nés avant le 31/07/1979 ;
 Etudiants nés avant le 31/07/1979 et inscrits en 2 ème année Analyste.
_____________________________________________________________________________________
Page 65 sur 69
1er Argument 2ème Argument
Prédicat
Dans un prédicat, on peut utiliser des constantes réelles, littérales. Quand il y a
combinaison d’au moins deux arguments, il faut obligatoirement utiliser des
opérateurs logiques (ou booléens).
Aussi quand cela est nécessaire, on peut utiliser les parenthèses.
6 – 2 Calcul Relationnel des Tuples

Ce calcul se déduit du calcul des prédicats en interprétant les formules indiquées à
travers les exemples ci-après :
Attention :
Une requête dans le calcul relationnel des tuples s’exprime sous la forme :
{(x1, x2, …, xn) : F(x1, x2, …, xn)} F(x1, x2, …, xn) où est une formule dans laquelle les
seules variables libres sont x1, x2, …, xn. Il est bien entendu que chacune de ces
variables est associée à une relation et une seule, mais des variables différentes
peuvent être associées à une même relation. La réponse sera en effet constituée
par l’ensemble des valeurs qui se subsistent à (x1, x2, …, xn) et qui rendent la
formule vraie.
Exemples :
 Désignation et Couleur de toutes les pièces : {Desig.Pieces, Couleur.Pieces}
 Désignation des pièces de couleur « Ivoire » : {Desig.Pieces, and
Couleur=’’Ivoire’’}
 Intitulé des Services ayant en Commande la pièce P2 : {Intitul.Service : Э les
relations Pièces, Ordonner, Service and (NOS.Ordonner=NOS.Service) and
(NOP.Ordonner=NOS.Pieces) (Couleur.Pieces=’’Ivoire’’)}.
6 – 3 Calcul Relationnel de Domaines

Ce calcul se déduit du calcul de prédicat en interprétant les formules ayant la
forme suivante :
{(x1, x2, …, xn) : F(x1, x2, …, xn)} où F(x1, x2, …, xn) est une forme dans laquelle les
seules variables libres sont x1, x2, …, xn. La réponse étant constituée par l’ensemble
des valeurs qui se substituent à (x1, x2, …, xn) et qui rendent la formule vraie.
Exemples (en rapport avec ceux du calcul relationnel des tuples) :
 {x, y : Pieces(Desig : x, Couleur : y)}
 {(x : Э y : Pieces (Desig : x, Couleur : Y) et (y=’’Ivoire’’)}
 …
6 – 4 Etude des Prédicats Usuels

6 – 4 – 1 Prédicat BETWEEN
Les deux formes prédicatives BETWEEN et NOT BETWEEN permettent de déterminer si
une valeur NUMERIQUE appartient ou n’appartient pas à un intervalle (bornes
incluses).
Exemple : Numéros de pièces dont le poids est compris entre 50 et 100.
Select NOP From Pièces Where Poids Between 50 And 100;
_____________________________________________________________________________________
Page 66 sur 69
6 – 4 – 2 Prédicat IS NULL
Les deux formes prédicatives IS NULL et IS NOT NULL permettent de tester si un tuple
(enregistrement) d’une table présente ou ne présente pas une valeur nulle dans
une colonne (Attribut).
Exemple : Numéros de Service qui ont commandé sans déterminer la quantité et les
NOP correspondantes.
Select NOS, NOP From Ordonner Where Quantité IS NULL ;
6 – 4 – 3 Prédicat IS LIKE
IS LIKE et IS NOT LIKE permettent de déterminer si une forme particulière existe ou
n’existe pas dans une chaîne de caractères. Le symbole % joue un rôle de joker
comme indiqué ci-après :
X IS LIKE ‘’LYON’’ prend vraie si X est identique à LYON
X IS LIKE ‘’%LYON%’’ prend vraie si X contient LYON
X IS LIKE ‘’LYON%’’ prend vraie si X débute par LYON
X IS LIKE ‘’%LYON’’ prend vraie si X se termine par LYON
Exemple : NOP dont la désignation se termine par ‘’ON’’ et dont le poids est
compris entre 40 et 65.
Select NOP From Pièces Where Désignation IS LIKE ‘’%ON’’ And Poids BETWEEN 40
And 65;
6 – 4 – 4 Prédicat IN
Les deux formes prédicatives IN et NOT IN permettent de déterminer si une valeur
quelque soit le type appartient ou n’appartient pas à une liste de valeurs de même
type. Ces formes autorisent l’imbrication de requêtes d’une manière très naturelle.
Elles fournissent une autre alternative pour examiner une équijointure.
Exemple1 : Désignation de pièce de couleur Ivoire, Rouge ou Blanc.

Select Désignation From Pièces Where Couleur IN(‘’Ivoire’’, ’’Rouge’’, ’’Blanc’’)
Exemple2 : NOP et Désignation des pièces commandées par le Service S1

Select NOP, Désignation From Pièces Where NOP IN(Select NOP From Ordonner
Where NOS=’’S’’) Order By NOP;
Exemple3: NOP et Désignation des Pièces commandées par un Service Diffusion.

Select NOP, Désignation From Pièces Where NOP IN (Select NOP From Ordonner
Where NOS IN(Select NOS From Service Where Intitulé IS LIKE ‘’Diffusion%’’)) Order
by NOP ;
Ces prédicats autorisent la comparaison d’une valeur avec d’autres valeurs. Cette
dernière peut être le résultat d’une requête. Mais il est important de s’assurer que le
résultat comprend une ligne (un Tuple) unique.
Exemple1 : NOS qui ont commandé la pièce P3 avec une quantité inférieure à la
quantité moyenne commandée pour cette pièce.
_____________________________________________________________________________________
Page 67 sur 69
Select NOP, NOS, Quantité From Ordonner Where NOP=’’P3’’ And Quantité<(Select
AVG(Quantité) From Ordonner Where NOP=’’P3’’) ;
Exempe2 : caractéristiques de chaque pièce ayant un poids < à la moyenne des

poids des pièces de leur couleur.
Select * From Pièces Where Poids<(Select AVG(Poids) From Pièces Where
Couleur=Pièces.Couleur) Order By NOP ;
6 – 4 – 6 Prédicats Quantifiés
Prédicats ALL ou ANY
Un prédicat ALL ou ANY a la même forme qu’un prédicat de comparaison
scalaire ; la différence provenant du second opérande qui est précédé par ALL ou
ANY. La requête pleine peut fournir un résultat avec un nombre quelconque de
valeurs nulles ou non nulles.
 Un prédicat ALL prend la valeur Vrai, la requête pleine ne fournit valeur ou si
le prédicat de comparaison associé prend la valeur Vrai pour toutes les
valeurs scalaires fournies par la requête pleine.
 Le prédicat prend la valeur ‘’inconnue’’, si la requête pleine fournit
uniquement des valeurs nulles.
Ces deux prédicats ne sont pas équivalents aux Quantificateurs Universels et

Existentiels. Ils peuvent seulement être considérés comme une implémentation
partielle lorsque la formule quantifiée est une comparaison scalaire.
Exemple : NOS ayant commandé au moins une pièce en quantité>à chacune des
quantités de pièces commandées par le Service S1.
Select Distinct NOS From Ordonner Where Quantité > ALL (Select Quantité From
Ordonner Where NOS=’’S1’’);
Prédicats EXISTS
Ce prédicat prend la valeur la valeur Faux si la requête pleine a comme résultat
l’ensemble vide. Sinon, il prend la valeur Vrai. Ce prédicat constitue une
implémentation complète du Quantificateur Existentiel : Toute requête du calcul
relationnel de tuple ne faisant intervenir que le Quantificateur Existentiel peut être
reformulée complètement en SQL à l’aide de EXISTS.
Exemple1 : Services ayant commandé au moins une pièce.

Select Intitulé From Services Where EXISTS (Select * From Ordonner Where
Services.NOS=Ordonner.NOS);
Exemple2: Services n’ayant pas commandé de pieces.
Select Intitulé From Services Where NOT EXISTS (Select * From Ordonner Where
Services.NOS=Ordonner.NOS);
6 – 5 Utilisation des Clauses GROUP BY et HAVING

Groupement
Lorsque la clause GROUP BY est présente dans une spécification de requêtes, les
lignes de la Table sont d’abord sélectionnées en fonction de la condition de la
clause WHERE. Les lignes restantes sont ensuite reparties en groupes disjoints en
_____________________________________________________________________________________
Page 68 sur 69
fonction de leurs valeurs pour les colonnes spécifiées dans GROUP BY : toutes les
lignes d’un groupe ont les mêmes valeurs pour ces colonnes. La relation résultant
comprend autant de lignes qu’il y a de groupes. Un élément de sortie du résultat
doit obligatoirement présenter la même valeur pour chaque ligne du groupe. Les
colonnes du résultat sont donc, soit des expressions faisant uniquement intervenir les
colonnes de groupement, soit des fonctions d’agrégat appliquées aux lignes d’un
groupe. Certaines versions de SQL exigent la présence d’une fonction d’agrégat.
Exemple : Quantité commandée pour les pièces P1, P2, P3.

Select NOP, SUM(Quantité) From Ordonner Where NOP IN(‘’P1’’, ‘’P2’’, ‘’P3’’)
Group By NOP Order By NOP ;
HAVING
La clause HAVING permet d’effectuer une sélection sur les groupes : seuls les
groupes satisfaisant à la condition associée participent au résultat. Les arguments
de la condition sont de même nature que les éléments de sortie. On considère alors
que tous les Tuples de la Table forme un seul groupe.
Dans certaines versions de SQL, la clause HAVING peut être spécifiée
indépendamment de la clause GROUP BY.
Exemple : Quantité moyenne commandée pour les Pièces faisant l’objet de plus de
trois Commandes.
Select NOP, AVG(Quantité) From Ordonner Where Group By NOP Having
Count(*)>3 Order By NOP;
_____________________________________________________________________________________
Page 69 sur 69

Cours Base de Données

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours Base de Données

Transféré par

Droits d'auteur :

Formats disponibles

PROGRAMME DE BASE DE DONNEES

Chapitre I : Concepts de Système d’Information

Chapitre II : Concepts de Base de données

Chapitre III : Etude des Bases de données relationnelles

c) Différents types d’informations

c-1) L’information naturelle

2 – Définition d’une Base de Données

Etudiant ayant Numéro, Nom, Prénom, Sexe, Adresse

3 – Les fondements des Bases de Données

La redondance est difficile à maîtriser et pendant longtemps, les techniques ont

d) Evolution Aisée : Modification de la Structure de la Base de Données

e) Indépendance des Données et des Programmes

f) Administration des Données

Les tâches de l’administration de la base sont :

4 – Propriétés des Bases de Données

5 – Le Système de Gestion des Bases de Données (SGBD)

c) Architecture des Systèmes de Gestion des Bases de Données (SGBD)

Ainsi toutes les

Mais, il existe trois architectures différentes de Systèmes de Gestion Bases de

C1) Architecture Opérationnelle

C2) Architecture Client – Serveur

Exemple : Locate For Age>=16 .AND. Age<=35 (en Dbase IV)

d2) Fonctions Annexes

Le SGBD doit veiller à ce que les données respectent en permanence ces

 Le 2ème concerne le maintien de la cohérence entre les copies multiples

Voici quelques exemples de contraintes d’intégrité :

d2 – 4) Fonction Optimisation des Ressources

A titre indicatif, voici quelques exemples de statistiques :

Dans certains cas, le SGBD peut comprendre des procédures de réorganisation

Base Physique Système Description

Enfin, les données sont alors disponibles pour le programme d’application.

 D’abord, elle doit spécifier l’organisation logique et les caractéristiques des

 Nommer la base de données et toutes les unités logiques (Types de champs,

g) Différents types de Systèmes de Gestion des Bases de Données

g – 1) Système de Gestion des Bases de Données

g – 2 Les Systèmes de Gestion des Bases de Données

Att-1 Att-2 … Att-n

Pour chaque Tuple, un Attribut présente une valeur numérique.

Ce modèle trouve son fondement dans l’utilisation des fonctions de l’Algèbre

g – 4) Les Systèmes de Gestion des Bases de Données Orientés Objet

g – 5) Notions de Systèmes de Gestion des Bases de Données Déductifs

6 – Processus de conception d’une Base de Données

7 – Les Concepts associés aux Bases de Données

7 – 1) Objet (ou Entité ou Individu)

Exemple : Le client MITORY a passé la commande C1 contenant les produits P1 et

On peut utiliser cet exemple par le tableau suivant :

Nous observons que cette description du réel perçu fait apparaître :

7 – 2) Relation (ou Association)

Exemple : Suivant l’exemple des clients MITORY et AYESSA, nous pouvons de

Les entités sont : Etudiant et Commune.

NB : Une relation peut ou ne pas être porteuse de propriétés.

Toutefois, il existe quatre (04) types d’associations :

7 – 3) Propriété, Rubrique, Attribut

1,n Passer 1,1

8 – Exemples de Base de Données

En effet, chaque service passe des ordres (commandes) de fabrication pour le

Assemble Compose Pièce-Ordre Service-Ordre

NOP NOP NOS NOP

Ce schéma est basé sur deux structures hiérarchiques différentes :

Quantité Quantité Ordonnée

Le Set SER-Ord fournit les quantités commandées par chaque service.

9 – Conception du Modèle Conceptuel des Données (MCD)

Un agent ne peut épouser qu’une collègue