Base de Données G3

Cours de Technique de Bases de Données
G3 Informatique de Gestion Ass Lucide Bula

Page 1 sur 1
INTRODUCTION GENERALE
Un système d'informations est un ensemble des ressources susceptibles de

recueillir l'information, de la transformer, de la sauvegarder et de la restituer sous la
forme d'un résultat attendu. Les bases de données, comme elles permettent de pouvoir
sauvegarder ces informations et aussi de définir les mécanismes d'accès à ces
informations, sont considérées comme "le cœur d'un système d'information". C'est
pourquoi leur conception est l’une des tâches les plus ardues du processus de
développement d’un système d’information.
1. Définition
Une base de données (B. D) est un ensemble de données mémorisées sur des
supports accessibles par un ordinateur pour satisfaire simultanément plusieurs utilisateurs
de façon sélective et en temps réel très court. Une base de données permet en fait de
stocker et d’organiser une grande quantité de données.
Avant de se lancer dans le vif de notre cours, il sied de signaler d'abord la

différence qui existe entre une base de données et une application base de données.
a. Les bases de données
Une base de données est un ensemble des données organisées d'une

certaine manière pour un certain but.
Les fiches de malades dans un hôpital, le formulaire d'inscription des étudiants
constituent des bases de données.
A ce niveau, les bases de données sont considérées comme étant des structures de
données manipulées dans le système d'information.
b. Les applications base de données
Les fiches et formulaires sur papiers nécessitent à ce que l'homme,

l'utilisateur du système, puisse y inscrire, supprimer ou modifier certaines valeurs de ces
données. Ainsi, la base de données ne sera plus considérée comme seulement ces
Lisez et relisez ce cours. C’est seulement votre volonté qui vous amènera à la compréhension ( Ass Bula)
Page 2 sur 2
données mais plutôt l'ensemble de ces données et les mécanismes permettant de
manipuler ces données: c'est ce que nous allons appeler "application base de données " ou
simplement " base de données".
Donc, ce cours ne se limitera pas à la seule conception de la base de

données comme structure de données mais aussi à savoir quels sont les voies et moyens
qui guideront le concepteur à concevoir des interfaces qui vont permettre aux utilisateurs
du système de pouvoir interagir avec ces données.
2. Caractéristiques
a. La structuration des données
Les informations contenues dans une base de données doivent être réparties
en enregistrements dont chacun d’eux doit avoir une structure bien définie.
b. La non redondance des données
Dans une base de données une information ne doit pas être répétée plusieurs
fois. Sauf pour de raisons historiques.
c. L’indépendance entre programme et données
La base de données doit être indépendante vis-à-vis des programmes qui y ont
accès.
3. Typologie
Il existe trois types de base des données :

a. Les bases de données hiérarchiques
Elles sont les plus anciennes et sont fondées sur une modélisation
arborescente des données.
Page 3 sur 3
b. Les bases de données objets
Elles consistent dans une organisation des données sous forme d’instances de
classes hiérarchisées qui possèdent leurs propres méthodes d’exploitation.
c. Les bases de données relationnelles
Elles organisent des données sous forme des tables qui sont exploitées à l’aide
d’un langage déclaratif.
Par exemple : ORACLE, MYSQL, ACCESS, etc.
Dans le cadre de ce cours, nous aborderons la conception et la mise en place

de bases de données relationnelles.
Une base de données relationnelles est celle structurée suivant les principes
de l’algèbre relationnel. La théorie des bases de données relationnelles est due à Edgar
Franck Codd. Elle est mise en œuvre au moyen d’un SGBDR.
4. Création d’une base de données
L’une des phases essentielles dans la conception d'une base de données

est de s'assurer que les données sont correctement réparties entre les différentes tables.
Lorsque les structures de données sont correctes, le reste de l'application (requêtes,
formulaires, états, codes, etc.) s'en trouve considérablement simplifié. L'appellation
formelle qui désigne la conception correcte d'une table est la normalisation de la base de
données.
Lorsque nous concevons une application, nous devons avoir une vision
globale du résultat final afin d'être sûr de disposer de toutes les données nécessaires et
d'en connaître la provenance. Par exemple, quelle apparence auront les états, d'où vient
chaque élément de données, toutes les données existent-elles ? Rien n'est plus
dommageable à un projet que de s'apercevoir, trop tard, qu'il manque des données pour
établir un état important. Voilà la nécessité d’une bonne conception de la persistance.
Page 4 sur 4
Lorsque nous savons de quelles données nous avons besoin, nous devons
déterminer leur provenance. Les données sont-elles importées d'une autre source ? Les
données doivent-elles être nettoyées ou vérifiées ? Est-ce l'utilisateur qui introduit les
données ?
La première étape pour concevoir une application base de données est

donc de savoir clairement quelles sont les données requises et d'où elles proviennent.
Notre cours se limitera juste à la conception de la couche persistance d’une application et
la détermination des acteurs et leur rôle dans le système informatique.
En effet, une erreur de conception pourrait en générer d’autre bien plus

graves lors de l’installation de la base ; allant parfois même jusqu’à la perte de certaines
données. C’est pourquoi, les méthodes de conception de bases de données ont été mise
sur pied afin d’éviter les erreurs majeures éventuelles. La méthode MERISE constitue
ainsi l’une des méthodes les plus employées.
En rapport avec la méthode MERISE, la modélisation se réalise en quatre

étapes principales qui correspondent à trois niveaux d’abstraction différents.
Univers d’application Niveau d’abstraction
Analyse
Elaboration du Niveau conceptuel
Modèle E-A
Passage au Modèle Niveau logique

Modélise Logique
Implantation sur le Niveau physique

SGBD-R cible
a. Niveau conceptuel
A ce niveau le contenu de la base est représenté en termes conceptuels,

indépendamment de toute considération informatique. Il s’agit de la formalisation des
données.
Page 5 sur 5
b. Niveau logique
Ce niveau résulte de la traduction du schéma conceptuel en un schéma

propre à un type de base de données. (Choix du type de base de données)
c. Niveau physique
Il s’agit ici de la description des méthodes d’organisation et d’accès aux

données de la base (Choix du SGBD).
5. Objectifs du cours
5.1. Objectif général
Ce cours vise à initier les étudiants finalistes du premier cycle en informatique

de gestion à la conception d’une base de données relationnelle.
5.2. Objectifs spécifiques
A la fin de ce cours l’étudiant devra être capable :

 de concevoir le schéma conceptuel de données d’un système d’information,
 de transformer le schéma conceptuel en un schéma logique de données,
 de positionner une base de données dans une application,
Page 6 sur 6
6. Plan du cours
INTRODUCTION GENERALE
CHAPITRE PREMIER : MODELISATION CONCEPTUELLE
1.1. Le modèle
1.2. Les entités
1.3. Les attributs
1.4. Les relations
1.5. La construction d’un schéma conceptuel
CHAP.II : MODELISATION LOGIQUE RELATIONNELLE

2.1. Les Concepts fondamentaux
2.2. Les contraintes d’intégrité
2.3. Les Règles de transformation du SCD en SLDR
2.4. La théorie de la normalisation
2.5. L’algèbre relationnelle
2.6. L’optimisation d’une base de données
CHAPIII. IMPLEMENTATION
3.1. Le SGBD
3.2. Le langage SQL
3.3. La position d’une base de données dans une application
EXERCICES
Page 7 sur 7
CHAPITRE I. MODELISATION CONCEPTUELLE
La modélisation conceptuelle est une étape fondamentale de la conception

d’une base de données dans la mesure où d’une part, on y détermine le contenu de la
base de B.D, et d’autre part, on y définit la nature des relations entre les concepts
principaux.
1.1.Le modèle
La modélisation d’un système consiste à construire un modèle pour ce

système. Construire un modèle d’un système réel ne peut se faire qu’en réduisant la
complexité de ce dernier, modéliser suppose une simplification du système à étudier et
une décision sur les aspects pris en compte et sur ceux délaissés.
Si dans son acception première un modèle est défini comme un objet ou

une personne à imiter, il est devenu dans le domaine scientifique une construction
matérielle ou abstraite "ressemblant" à l'objet modélisé, selon un certain nombre de
caractéristiques pertinentes eu égard aux données disponibles et à l'objectif poursuivi.
Très pragmatiquement, l'intérêt d'un modèle réside dans sa capacité à

apporter une réponse "satisfaisante" aux questions que l'on se pose à propos de l'objet
modélisé, ce qui nous renvoie encore une fois à l'objectif assigné au modèle qui doit bien
entendu précéder et orienter la conception et la construction du modèle (modèle
finalisé). On comprend mieux alors pourquoi, parmi l'infinité des modèles possibles d'un
objet, qui traduisent chacun un type de "ressemblance", un modèle particulier, qui n'est
pas nécessairement le plus complexe, puisse ou doive être préféré à tout autre.
Le modèle qui sera construit à ce niveau est le modèle Entité- Relation ou

Modèle Conceptuel de Données( MCD).
Les éléments de base du modèle ER (Entité-Relation) ou E-A (Entité-

Association) sont :
- Les entités ou objets ;
- Les attributs ou propriétés ;
- Type de relation : cardinalité
Page 8 sur 8
1.2. Entités ou objets
Une entité est définie comme étant un objet du système pouvant être identifié
distinctement, il est caractérisé par un nom et des attributs. Il existe deux catégories
d’entités :
a. L’entité régulière
Il s’agit d’une entité dont l’existence ne dépend pas de l’existence d’une autre
entité
b. L’entité faible
Il s’agit d’une entité dont l’existence dépend de celle d’une autre entité.
A titre illustratif, l’entité CONTRAT n’existe que si l’entité CLIENT

correspondante est présente.
Ainsi CLIENT, VEHICULE, CONTRAT sont considérés comme des

entités
1.3. Les attributs
Un attribut est une caractéristique ou une propriété d’une entité. Un attribut

peut être obligatoire ou facultatif et, avoir un domaine de valeurs ; celui-ci est un
ensemble de valeurs qu’un attribut peut prendre.
La notion de domaine de valeurs fait allusion au type de données que

l’attribut (considéré aussi comme une variable) peut accepter.
A titre illustratif, le Numclient, le Nomclient et l’Adresse sont de propriétés de

l’entité CLIENT.
L’attribut Numclient pourra puiser ses valeurs dans le domaine N (ensemble
des entiers naturels), Num client sera alors du type entier.
Page 9 sur 9
Parmi tous les attributs de l’entité, l’identifiant est un attribut ou un ensemble

d’attributs permettant de déterminer d’une manière unique une occurrence (exemplaire)
d’une entité, c’est-à-dire une et une seule occurrence à l’intérieur de l’ensemble.
Graphiquement les identifiants sont les attributs soulignés.
Il est a noter que l’entité faible aura un identifiant composé de l’identifiant de

l’entité dont elle dépend et d’un autre attribut.
1.4. Les relations
Les relations ou associations représentent les liens existants entre les entités.
Contrairement aux entités, les relations n’ont pas d’existence propre. Les relations sont
caractérisées, comme les entités par un nom et éventuellement des attributs.
La description complète d’une relation nécessite la définition précise de la

participation des entités dans cette relation. La cardinalité est en fait le nombre de
participations d’une entité à une relation. Elles dépendent directement des règles de
gestion du système à modéliser.
1.4.1. Types de cardinalités

a. Cardinalité un à un
Les deux entités que la relation relie, participent une et une seule fois dans la
relation.
Exemple :
Département Employé
NumDep 1 Directeur 1 Num employé
Adresse Nom
Adresse
Date d’entrée
Fonction
Un employé ne peut être directeur que dans un seul département et un

département n’a qu’un seul employé comme directeur
Page 10 sur 10
b. Cardinalité un à plusieurs
L’une des entités que la relation relie participe une seule fois dans la relation
et l’autre plusieurs fois
Département Employé
NumDep N Occuper 1 Num employé
Adresse Nom
Adresse
Fonction
Un département peut occuper plusieurs employés, mais un employé ne peut

être occupé que par un seul département.
c. Cardinalité plusieurs à plusieurs
Les deux entités participent plusieurs fois dans la relation
Usine Produit
NumUsine N Fabrique N NumProduit
Nom Libellé
Adresse Catégorie
Une usine donnée fabrique plusieurs produits et un même produit peut être
fabriqué par plusieurs usines.
Les cardinalités présentées ci-dessus sont appelées ‘’Cardinalités maximales’’

dans la mesure où elles représentent le nombre maximum de participation d’une entité à
une relation. La cardinalité minimale est le nombre minimal de participation d’une entité
à une relation. La cardinalité minimale est généralement 0 ou 1.
Le deux cardinalités ; maximale et minimale traduisent les contraintes

propres aux entités et relations.
Dans un schéma conceptuel (MCD), elles sont représentées comme suit :
Page 11 sur 11
0 - 1 : Aucune ou une seule

1 – 1 : Une et une seule
0 - N : Aucune ou plusieurs
1 – N : Une ou plusieurs
1.4.2. Types de relations
Il existe deux types de relations, les relations hiérarchiques et les

relations non hiérarchiques.
 une relation est dite hiérarchique si elle n’est pas porteuse de propriétés et si ses
cardinalités sont de la forme 1 à plusieurs. L’entité du coté 1 sera appelée entité
fille et l’autre du coté plusieurs sera appelée entité mère.
Une telle relation implique la présence d’une contrainte d’intégrité fonctionnelle
(CIF). C'est-à-dire l’entité du coté 1 dépend de l’entité du coté plusieurs.
MERE ENFANT
NumMere (1,n) Est mère de (1,1) NumEnfant

NomMere NomEnfant
 une relation est dite non hiérarchique si elle est porteuse de propriétés et si ses
cardinalités sont de la forme plusieurs à plusieurs.
ARTICLE CLIENT
CdeArticle (1,n) ACHETER (1,n) NumClient

Libelle Qte NomClientt
Prix
Page 12 sur 12
Exemple d’un schéma conceptuel de données
Client Contrat
NumClient (0,n) (1,1) NumContrat
Signe
Nom Type
Adresse Date
(0,n)
Appartient
(1,1)
Véhicule
Accident
NumVehicule
Marque (0,n) (0,n) NumAccident
Concerne
Modèle Date
Année
Remarque
Une situation à modéliser peut avoir plusieurs schémas différents ; chaque

modèle présentant des avantages et des inconvénients.
Il existe plusieurs critères permettant de mesurer la qualité d’un schéma E-R.

Et, ces critères sont à utiliser de manière combinée :
- L’expressivité : traduit la richesse sémantique du schéma ;

- La minimalité : tend à privilégier les schémas avec un nombre de
redondances minimales ;
- La lisibilité : consiste à évaluer la représentation graphique du schéma ;
- La simplicité : privilégie les schémas contenant un nombre de concepts
minimal. On peut la mesurer par exemple en calculant le nombre
d’entités et d’associations présentes sur un schéma
Page 13 sur 13
1.5. Construction d’un schéma conceptuel (MCD)
La construction d’un schéma conceptuel peut se réaliser de la manière

suivante :
- l’élaboration du dictionnaire de données et des règles de gestion de données,
- la structuration de données
Première partie : Elaboration du dictionnaire de données et des règles de gestion
Le dictionnaire de données est une liste de toutes les données qui seront
manipulées par la base de données. Les règles de gestion de données sont la manière
dont ces données apparaissent dans le système.
NB : Les données calculées peuvent être prise en compte seulement pour de raisons
historiques.
Deuxième partie : Démarche de structuration des données
La structuration de données est basée sur la notion de dépendances

fonctionnelles. Voici quelques notions essentielles sur le DF:
a. Dépendance fonctionnelle (DF)

a1. Définition et notation
Une dépendance fonctionnelle est un lien existant entre deux attributs

parmi lesquels il y a un attribut source et un attribut but.
On note: A  B et on lit A détermine B
A : est un attribut source
B : est un attribut but
NB: la source peut être simple ou composé.
Dans le cas où elle est simple, on parle d'une dépendance fonctionnelle à source simple,
dans le cas contraire c'est une dépendance fonctionnelle à source composée.
Exemple
Page 14 sur 14
CodeArticle  Prix cette DF est à source simple parce que l'attribut source est un
singleton
NumClient, CodeArticle  QuantiteVendue cette DF est à source composée parce

que la source est composée de deux attributs.
a2. Propriétés de DF
Soit une relation R définie par les attributs X, Y et Z

1. La réflexivité: X  X
2. L'augmentation.
Si X  Z alors X, Y  Z
3. La transitivité
Si X  Y et Y  Z alors X  Z
Remarque
Ces règles sont correctes car elles ne déduisent que de DF valides, et elles
sont complètes car elles permettent de déduire toute dépendance valide à partir des
axiomes de départ. On appelle ces règles les axiomes d'Armstrong en l'honneur de leur
auteur1.
Afin de faciliter les démonstrations, on est amené à construire à partir des axiomes
d'Armstrong, d'autres règles parfois plus simples à utiliser, il s'agit de :
- l'union: Si X  Y et X  Z alors X  Z, Y
- la décomposition: si X  Z, Y alors X  Y et X  Z
a3. Types de dépendances fonctionnelles

Nous allons distinguer deux types de dépendances fonctionnelles:
- les dépendances fonctionnelles totales ou élémentaires
- les dépendances fonctionnelles directes.
a31. Dépendance fonctionnelle totale

Une DF est dite totale si aucune partie de la source ne détermine le but.
Conséquences
1
PHILIPPE MATHIEU, Base de données, LIFL, USTL, 1999
Page 15 sur 15
- Si la source est simple, automatiquement la DF est totale.
- Si la DF est non totale, il y a automatiquement présence d'une
augmentation.
Exemple
CodeArticle  Prix cette DF est à source simple et est totale
NumClient, CodeArticle  QuantiteVendue cette DF est à source composée
Si NumClient à lui seul ne sait déterminer la quantité achetée parce que un client peut
acheter plusieurs articles à des quantités différentes, et CodeArticle aussi ne sait pas
déterminer la quantité parce que le même article peut être acheté à des quantités
différentes. Sous cette optique, nous pouvons dire que cette DF est aussi totale.
NumClient, CodeArticle  Libelle
On sait que le CodeArticle à lui seul peut déterminer le libellé de l'article, alors cette DF
n'est pas totale.
Remarque
Pour rendre totale une DF, il faut supprimer les attributs qui créent
l'augmentation.
a32. Dépendance fonctionnelle directe
Soit une relation R défini par les attributs X, Y et Z. la dépendance

fonctionnelle X  Y est dite directe si et seulement si il n'existe pas un autre attribut Z
de R tel que: X  Z et Z  Y.
Conséquence
- une dépendance indirecte implique automatiquement la présence d'une
transitivité.
- Une relation ayant seulement deux attributs, la dépendance fonctionnelle
entre ces deux attributs est automatiquement directe.
Rendre une DF indirecte directe
Pour rendre directe une DF indirecte de la relation R, il faut procéder à

une décomposition de la relation afin d’isoler les attributs qui créent la transitivité.
Processus de décomposition
Page 16 sur 16
La décomposition d’une relation en plusieurs autres relations doit obéir

aux règles suivantes :
Quand une relation pose des problèmes de transitivité, il faut

décomposer la relation initiale en plusieurs autres relations qui ne souffrent plus de cette
anomalie. Bien sûr, la relation initiale R doit toujours pouvoir être reconstruite par
opération de jointure des sous relations Ri. Ce qui implique que les relations Ri obtenues
doivent avoir un attribut commun qui jouera le rôle de pivot.
La structuration des données du dictionnaire des données s'effectue en 7

étapes :
1. Détermination de la liste des DF simples

2. Prise en compte des attributs non classés dans l'étape 1 et détermination des DF
composées
3. Détermination de la liste des DF entre les identifiants
4. Elimination des transitivités du schéma des DF
5. Construction, à partir des DF simples, des entités de la base de données
6. Construction, à partir des DF composées, des relations de la base de données
7. Construction du schéma et détermination des cardinalités de liaison.
Exemple :
Soit à produire le schéma conceptuel de données du système d’information

relatif à la gestion de payement à l’ISS.
Page 17 sur 17
CHAPITRE II. MODELISATION LOGIQUE
Ce chapitre sera consacré à la transformation du Schéma Conceptuel de

Données en un Schéma Logique de la base de données choisi. A ce niveau, on choisi le
type de la base de données qui sera utilisé. Notre choix a été porté sur le type relationnel.
2.1. Concepts fondamentaux
Le modèle relationnel s’appui sur trois concepts fondamentaux ; le domaine,

l’attribut et la relation ou table.
a. Domaine
Le domaine est l’ensemble de valeurs en extension ou en compréhension. Un

domaine peut être simple ou composé.
a. 1. Domaine simple
Un domaine est simple lorsque tous les éléments sont atomiques ou

indécomposables ;
Exemple les numéros ( Num = 1,2,3, etc.)
a. 2. Domaine composé
Un domaine est composé lorsque tous les éléments peuvent être décomposés
Exemple les dates sont décomposées en jours, mois et années.
La composition d’une propriété plus simple ne doit pas être systématique ;

elle doit surtout tenir compte de son exploitation dans le système. Si cette exploitation est
toujours globale, l’atomisation n’est pas nécessaire, dans les autres cas, il faut procéder à
l’isolement de chacune des composantes de la propriété et donc introduire de nouvelles
propriétés.
Page 18 sur 18
b. Attribut ou champ
Chaque colonne est appelée attribut et contient un ensemble de valeurs d’un

domaine. Chaque ligne représente un tuple. Un tuple est une occurrence d’une relation.
Une clé est un attribut qui était identifiant de l’entité au niveau conceptuel. Il
existe trois types de clés :
- Clé primaire
C’est l’ensemble minimum d’attributs qui permet de distinguer chaque

tuplet de la table par rapport à tous les autres. Chaque table doit avoir une clé primaire.
- Clé candidate
C’est l’ensemble minimum d’attributs susceptibles de jouer le rôle de la clé

primaire.
- Clé étrangère
C’est une clé qui fait référence à la clé primaire d’une autre table.
Exemple
Num client Nom client Adresse

001 Bula 12, eee,eerrr
002 Omba 24,ssss,sshhhh
003 Lucide 15,zzzz ;fffff
c. Relation ou table
Une relation est un tableau à deux dimensions. Le degré de la relation est le

nombre de colonnes ou champs de cette relation. La cardinalité d’une relation est le
nombre de tuples ou d’enregistrements.
Page 19 sur 19
Exemple
Table salaire (Code : entier,
Nom : Chaîne de caractères,
Grade : (Cadre, employé, assistant
Salaire : (1200, 1000, 5000)
Degré de la table : 4
2.2. Les contraintes d’intégrité
Les contraintes d’intégrité permettent d’assurer la cohérence des données

dans une base. Un bon SGBD assure la gestion de toutes ces contraintes.
Les contraintes d’intégrité sont :
a. La contrainte de domaine
C’est la restriction de l’ensemble de valeurs possibles d’un attribut.
b. La contrainte de clé
Elle définit un sous-ensemble minimal des colonnes tel que la table ne
puise contenir deux lignes ayant les mêmes valeurs pour ces colonnes.
3. Contrainte obligatoire
Précise qu’un attribut on plusieurs attributs doivent toujours avoir une
valeur. C'est-à-dire valeur nulle non autorisée.
4. Contrainte d’intégrité référentielle (CIR)
Une contrainte d’intégrité référentielle ou d’inclusion est une contrainte

qui lie deux colonnes ou deux ensembles de colonnes de deux tables différentes.
Cette contrainte est déterminée par la présence d’une clé étrangère.
Lors de l’existence d’une contrainte d’intégrité référentielle, il y a présence
d’une clé étrangère.
Soit les deux relations suivantes :

R1( A,B,) et R2(D,E,F,A)
Page 20 sur 20
Dans la relation R2, l’attribut A étant une clé primaire dans la R1 alors, il
sera appelé clé étrangère dans la relation R2. Et, il y a existence d’une contrainte
d’intégrité référentielle à partir de l’attribut A de R1 et A de R2. On dira que a relation
R2 fait référence à la relation R1.
2.3. Les Règles de transformation du SCD en SLDR
Les systèmes de gestion de bases de données relationnelles organisent les

données en tables (à la manière d'un tableur). Il est simple, facile à comprendre et fidèle à
un cadre mathématique (l'algèbre relationnelle). Le concept mathématique sous-jacent est
celui de relation de la théorie des ensembles, qui se définit comme un sous-ensemble du
produit cartésien de plusieurs domaines.
Une fois le MCD élaboré, le travail du concepteur de bases de

données consiste à faire le choix du type de la base de données cible et à traduire ce
modèle en un modèle plus proche du SGBD à utiliser: le MLD (modèle logique de
données). Dans le MLD relationnel, l'unique type d'objet existant est la table.
Les règles de transformation sont les suivantes:

a. Toutes les entités du MCD deviennent des tables en MLDR et leurs propriétés
deviennent des champs de la table, cette dernière admettra comme clé primaire,
l'identifiant de l'entité.
b. Pour une relation hiérarchique, l'identifiant de l'entité mère sera placé dans la
table issue de l'entité fille comme clé étrangère.
c. Pour une relation non hiérarchique, cette relation devient une table et admettra
comme champs, les propriétés de la relation s'il y en a et comme clé primaire, la
clé composée des identifiants des entités qu'elle lie.
Ces règles ne sont pas toujours toutes appliquées lors de la transformation

d'un MCD en MLDR. La deuxième et la troisième règle seront appliquées seulement si
le MCD contient une relation hiérarchique ou non hiérarchique.
Page 21 sur 21
Exemple 1
PERE FILS
NumPere 1,n 1,1 NumFils
Occuper
NomPere NomFils
Adresse
Si la relation est de type 1,n et si elle n’est pas porteuse de propriété, il y a

existence d’une contrainte d’intégrité fonctionnelle. C'est-à-dire un enfant ne peut pas
existé sans père.
Le schéma logique relationnel de ce schéma est donné par :

PERE( NumPere, NomPere, Adresse)
FILS(NumFils, NomFils)
La table FILS fait référence à la table PERE.

Exemple 2
Construire le MLDR du MCD suivant :
Client Contrat
NumClient (0,n) (1,1) NumContrat
Signe
Nom Type
Adresse Date
(0,n)
Appartient
(1,1)
Véhicule
Accident
NumVehicule
Marque (0,n) (0,n) NumAccident
Concerne
Modèle Date
Année
Page 22 sur 22
2.4. La théorie de la normalisation
2.4.1. Définition
La normalisation permet de définir formellement la qualité des tables au

regard du problème posé par la redondance des données. En d’autres termes, normaliser
une relation R est une opération qui consiste à examiner dans quelles conditions la
relation R peut être remplacée par deux relations R1 et R2 ou plusieurs relations tels que
l’espace des attributs de R1 et R2 ou ces relations contiennent les mêmes informations
qui sont dans R.
R1
R2
AVEC :
1° Degré(R1) + degré(R2) supérieur ou égal au degré(R)
2° Info(R1) + Info(R2) égal Info(R)
La normalisation permet de regrouper autour de la clé primaire les

attributs qui s'y attachent directement et de réduire la redondance.
Suivant cette approche, la structure d'une base de données sera construite

à partir de l'ensemble de données manipulées dans le système qui vont former une seule
relation ou table de la base de données qu'il faudrait normaliser en fonction de règles de
gestion.
La normalisation est basée sur la notion de dépendances fonctionnelles

étudiée ci-haut.
2.4.2. Formes normales
Nous allons considérer qu'une base de données relationnelle est

normalisée s'il toutes ses relations sont en troisième forme normale.
Page 23 sur 23
Première étape: Première forme normale (1NF)
Une relation est en première forme normale si elle a une clé primaire et si
tous ses attributs sont considérés comme atomiques. Cette étape va consister à :
- choisir la clé primaire si elle n'existe pas. Sachant que la clé doit
déterminer de manière unique tous les autres attributs.
- rendre tous les attributs atomiques. Cette opération ne doit pas être
systématique mais elle doit tenir compte de l'exploitation dans le système.
Deuxième étape: Deuxième forme normale (2NF)
Une relation est en deuxième forme normale si et seulement si:

- elle est en première forme normale
- toutes les dépendances fonctionnelles, partant de la clé primaire vers les
autres attributs, sont élémentaires.
Ce qui revient à dire que rendre une relation en deuxième forme normale consiste à:
- vérifier si elle est en première forme normale
- rendre élémentaires toutes les dépendances fonctionnelles, partant de la
clé primaire vers les autres attributs.
Troisième étape: Troisième forme normale (3NF)
Une relation est en troisième forme normale si et seulement si:

- elle est en deuxième forme normale
- toutes les dépendances fonctionnelles, partant de la clé primaire vers les
autres attributs, sont directes.
Ce qui revient à dire que rendre une relation en troisième forme normale consiste à:
- vérifier si elle est en deuxième forme normale
- rendre directes toutes les dépendances fonctionnelles, partant de la clé
primaire vers les autres attributs.
Page 24 sur 24
Ainsi, la normalisation fonctionne parfaitement pour permettre le stockage
des mêmes données dans un emplacement unique et elle simplifie les opérations
d'édition ; en revanche, il y a des cas où elle n'est pas souhaitable. Si vous avez besoin
d'un aperçu des données à des fins d'historique par exemple, il est important de le
prévoir dès le début dans la conception de votre base. En effet, une fois que les données
sont remplacées, il est impossible de revenir en arrière.
Exemple
Soit à normaliser la relation suivante :
RELATION (NumBD, NomBD, Description, NumTable, Nomtable, CleEtrangere,
Numchamp, NomChamp, Type, taille, Numtableau, Nomtableau,
utilite, Valeur, NumEnc, capaciteC )
Avec les règles de gestion suivantes :

1. une base de données peut avoir plusieurs tables
2. une table ne peut pas appartenir à plusieurs bases de données
3. une table contient plusieurs champs
4. un même champ ne peut pas appartenir à plusieurs tables
5. une même base de données peut avoir plusieurs encombrements suivant la
simulation faite
6. une table peut avoir plusieurs tableau de statistiques permettant de calculer le
nombre d’enregistrement ou la les 3 cardinalités
7. la valeur d’une simulation dépend du tableau et de la table concernée.
2.4.3. Avantage de la normalisation
La normalisation présente les avantages suivants :
1. La normalisation traduit une cohésion plus ou moins forte des attributs ;

2. La normalisation permet de regrouper autour de la clé primaire des attributs
qui s’y rattache directement ;
3. La suppression ou la diminution de la redondance et des I/0 en mise à jour
Page 25 sur 25
Exemple :
Client (Num client, Code Art, Adresse Client, Prix Art, Nom Client
NumClient codeArt PrixArt NomClient Adresse

C001 A001 500 CLIENT1 AD1
Si nous voulons changer l’adresse du client, C001, nous ferons 2 entrées et 2

sorties. Dans cette relation, il y a redondance des données.
Normalisation de la relation client
CLIENT (NumClient, CodeArt, PrixArt, NomClient, AdresseClient)

Règle de gestion : Le prix d’un article dépend d’un client à un autre
1NF : Cette relation est en 1NF car tous les attributs sont atomiques et il y a présence
d’une clé primaire qui est NumClient, CodeArt
2NF : Toutes les dépendances fonctionnelles partant de la clé vers les attributs non clé
doivent être totales ou élémentaires
NumClient, CodeArt  Prix oui elle est totale
Nom Client, Code Art  Nom Client Nom car Num client  Nom Client (1)
NumClient, Code Art  Adresse Client Nom car Num ClientAdress Client (2)
(1) NumClientNomClient
(2) Num Client AdresseClient
L’union de (1) et (2) donne NumClientNomClient, AdresseClient
La relation CLIENT est éclatée en deux relations :

CLIENT 1 (NumClient, NomClient, Adresse)
ARTICLE (NumClient, Code Art, Prix Article)
Page 26 sur 26
CLIENT 1 Article
NumClient NomClient AdresseClient NumClient CodeArt PrixArt
C001 CLIENT1 AD1 C001 A001 500
C003 CLIENT3 AD3 C001 A002 200
C003 A003 100
Après normalisation, nous ne ferons plus que 1 entrées et 1 sorties pour

modifier l’adresse du client C001.
4. La suppression des anomalies en insertion
Dans la relation non normalisée, il n’est pas possible d’ajouter un client

qui n’a pas encore acheté quelque chose. Du fait que la clé ne peut pas contenir une
valeur nulle, C003 ne sera jamais enrôlé. Or dans la relation normalisée, cela est possible
sans problème.
5. La suppression des anomalies en suppression
Dans une relation non normalisée, la suppression des informations a

souvent de répercutions anormales dans le système.
2.4..4. Les inconvénients de la normalisation
L’inconvénient de la normalisation se retrouve dans la consultation.

Exemple : supposons que l’on nous demande d’imprimer la liste suivante : NumClient,
AdressClient, CodeArt.
1er Cas : Dans la relation normalisée, nous ferons 3 I/0 (lecture simple) pour avoir la liste
C001, A001, AD1
C001, A002, AD1
C003, A002, AD2
ème
2 Cas : Dans la relation normalisée, nous allons lire certaines informations dans la
relation CLIENT et d’autres dans la relation Article et faire le JOINT par après.
Page 27 sur 27
Avec cette opération de jointure, nous allons effectuer 8 I/0 au lieu de 3 .
2.5. L’algèbre relationnelle
L’algèbre relationnelle a été définie en 1970 par le mathématicien Codd.

Elle va nous permettre d’interroger une base de données relationnelle. L’algèbre
relationnelle est un ensemble d’opérations que l’utilisateur aura à utiliser afin de recevoir
un résultat. Ce résultat sera une nouvelle relation résultant des relatons existantes.
Il existe deux types d’opérations :

1. Les opérations relationnelles ensemblistes ;
2. Les opérations relationnelles pures
2.5.1. Les opérateurs relationnelles ensemblistes
Ces opérateurs admettent comme opérandes les ensembles ou relations

du schéma logique.
Exemple : R1 X R2
R1 et R 2 sont des relations et X une opération relationnelle ensembliste
a. Union
L’union permet de mélanger les occurrences des relations concernées.
Condition d’application
1. Les relations doivent avoir le même degré ;
2. Les attributs de ces relations doivent avoir les mêmes domaines
Notation
R = R1UR2
Le résultat est une relation R ayant le même degré et même domaine que R1
et R2 et pour laquelle le nombre d’occurrence est égale à la somme de celles de R1 et R2.
R1 U R2 = T : T  R1 ou T  R2
Page 28 sur 28
Exemple
CLIENT 1 FOURNISSEUR
N° C NOM C Adresse N° F NOM F Adresse
C001 CLIENT1 AD1 F001 FNSS1 AD3
F003 FNSS3 AD5
CLIENT U FOURNISSEUR = R (Num, Nom, Adresse)
R
Num Nom Adresse
C001 CLIENT1 AD1
C002 CLIENT2 AD2
F001 FNSS1 AD3
F002 FNSS2 AD4
F003 FNSS3 AD5
b. Intersection
Cette opération permet de recueillir les occurrences à deux relations.
Condition d’application : Comme pour l’Union,
R= R1  R2
Exemple
R1 R2
N° C NOM Adresse N° NOM Adresse
F003 FNSS3 AD5
C001 CLIENT1 AD1
R=R1  R2 :
Page 29 sur 29
les enregistrements qui
appartiennent à R1 et à R2.
N° Nom Adresse
C001 CLIENT1 AD1
c. La différence
R =R1/R2 : Cette opération restitue les occurrences de R1 qui ne sont pas de R2.
Condition d’application
Mêmes conditions que celles de l’Union
Exemple
R1 R2
N° C NOM C Adresse N° F NOM F Adresse
F003 FNSS3 AD5
C001 CLIENT1 AD1
R =R1 / R2 : les enregistrements de R1 qui ne sont pas de R2.
N° Nom Adresse
C002 CLIENT2 AD2
d. Le produit cartésien
Le produit cartésien entre la relation R1 et la relation R2 est une
combinaison linéaire de chaque enregistrement de R1 avec tous les enregistrements de
R2.
Notation R = R1 * R2
Page 30 sur 30
R1 R2
NOM C Adresse N° Libelle Prix
CLIENT1 AD1 A001 ART1 200
A003 ART3 150
R=R1*R2 sera
NOM C Adresse N° Libelle Prix
Conséquence
 Le degré(R)=degré(R1)+degré(R2)
 La cardinalité(R)=cardinalité(R1)* cardinalité(R2)
2.5.2. Les opérations relationnelles pures
Les opérations relationnelles pures sont :
 La sélection ;
 La projection ;
 La jointure
Les deux premières sont des opérations unaires ou uni-relationnelles

c'est-à-dire les opérations qui s’appliquent sur une même relation tandis que la troisième
nécessite la présence de deux relations (opération binaire).
Page 31 sur 31
a. La sélection
La sélection permet de réduire la cardinalité d’une relation suivant un
certain critère donné.
T : est la table dans laquelle on veut sélectionner des lignes
R : est la table qui contiendra le résultat de la requête
 P est le prédicat de sélection ou critère de sélection.
On notera : R=S  P T
On lira : R reçoit les lignes sélectionnées de T qui répondent au critère P
Autre notation R=T : P
Conséquence :
- La relation R a un même degré et même domaine que T
- La cardinalité de R est < à celle de T
Exemple
Relation Produit
Code produit Libellé Prix
P 001 Bic 50 FC
P 002 Crayon 20 FC
P 003 Cahier 100FC 5 occurrences
P 004 Latte Latte 70 FC
P 005 Journal 150 FC
Si R = S  Prix < 100 Produit c'est-à-dire sélectionner sur la table Produit, les articles
dont le prix est strictement inférieur à 100.
R sera

P 001 Bic 50 FC
P 002 Crayon 20 FC 4 occurrences
P 003 Cahier 100FC
P 004 Latte 70 FC
Page 32 sur 32
NB : P est une condition, par conséquent, il sera une expression logique.
b. La projection
La projection permet de réduire le degré d’une relation. La projection

élimine un certain nombre d’attributs d’une relation.
T : est la table concernée

R : est la table qui contiendra le résultat
 A1, A2, … est la liste des attributs à sélectionner
On notera R =  A1, A2, … T
Autre notation R= T  A1, A2, …
Exemple : même exemple
R=  Libellé, Prix Produit : sélectionner seulement les champs Libellé et prix de la table
Produit.
R
Libellé Prix
Bic 50 FC
Crayon 20FC
Cahier 100 FC
Latte 70 FC
Journal 150 FC
Conséquences : La relation R a une même cardinalité que T
c. La composition des opérations de sélection et de projection
Pour effectuer successivement une sélection puis une projection à partir

d’une table T ; on peut écrire :
R1 = S  P T
Page 33 sur 33
R2 =  A1, A2, … R1
On peut aussi écrire : R2 =  A1, A2… ( SPT)
Exemple sur le produit
Editer la liste de produits (libellé et prix) dont le prix est  100 FC

L’expression algébrique sera :
R1 = S  Prix >=100 Produit
R1 sera
P 003 Cahier 100FC
P 005 Journal 150 FC
R2 =  libellé,Prix R1 sur la relation R1 sélectionner seulement la colonne libellé et prix.

Le résultat sera
R
Libellé Prix
Cahier 100 FC
Journal 150 FC
d. Le Joint (jointure ou composition)
Le joint est une opération qui permet de rapprocher deux relations par
l’intermédiaire d’un attribut commun qui sera appelé PIVOT. Le joint est un produit
cartésien sur lequel est appliqué une sélection ayant comme critère le Pivot.
T1 et T2 : sont deux relations

R : est la relation qui contiendra le résultat
 J : est la règle de jointure
On notera : R = T1  J T2
Page 34 sur 34
R : contiendra les attributs de T1 et de T2. Les lignes seront les combinaisons des lignes
de T1 avec les lignes T2 qui vérifient la règle de jointure.
NB. Si A1 est un attribut de T1 et A2 un attribut de T2, l’équijointure s’écrira :
T1. A1 = T2.A2
Démarche
1. Effectuer un produit cartésien

2. effectuer une sélection sur R ayant pour critère A1 = A2
NB : la démarche optimale exige à ce que l’on commence par la sélection sur la

deuxième table avant d’effectuer le produit cartésien.
Exemple
Relation Article
CdeArt Libelle Prix

A001 ARTICLE1 100
A002 ARTICLE2 200
A003 ARTICLE3 300
A004 ARTICLE4 400
Relation Acheter
NumClient CdeArt Qte
CL001 A001 2
CL001 A002 1
CL001 A003 2
CL002 A002 5
CL003 A001 1
CL003 A002 3
Editer la liste NumClient, CdeArt, Libelle, Prix, Qte
Page 35 sur 35
Ces données sont dans les deux tables, remarquons que ces deux tables ont un
attribut commun : le CdeArt = Pivot
Procédure
 Effectuer le produit cartésien entre Client et Article
R= Client * Produit
NumClient CdeArt Qte CdeArt Libelle Prix

CL001 A001 2 A001 ARTICLE1 100
CL001 A001 2 A002 ARTICLE2 200
CL001 A001 2 A003 ARTICLE3 300
CL001 A001 2 A004 ARTICLE4 400
CL001 A002 1 A001 ARTICLE1 100
CL001 A002 1 A002 ARTICLE2 200
CL001 A002 1 A003 ARTICLE3 300
CL001 A002 1 A004 ARTICLE4 400
CL001 A003 2 A001 ARTICLE1 100
CL001 A003 2 A002 ARTICLE2 200
CL001 A003 2 A003 ARTICLE3 300
CL001 A003 2 A004 ARTICLE4 400
CL002 A002 5 A001 ARTICLE1 100
CL002 A002 5 A002 ARTICLE2 200
CL002 A002 5 A003 ARTICLE3 300
CL002 A002 5 A004 ARTICLE4 400
CL003 A001 1 A001 ARTICLE1 100
CL002 A002 5 A002 ARTICLE2 200
CL002 A002 5 A003 ARTICLE3 300
CL002 A002 5 A004 ARTICLE4 400
CL003 A002 3 A001 ARTICLE1 100
CL003 A002 3 A002 ARTICLE2 200
CL003 A002 3 A003 ARTICLE3 300
Page 36 sur 36
CL003 A002 3 A004 ARTICLE4 400
 Sur la relation R sélectionner les lignes pour lesquelles il y a égalité (équijointure)

dans les deux colonnes CdeArt : lignes coloriées.
Ainsi R = Client  J Article

Avec J= Client.CdeArt=Article.CdeArt sera :
NumClient CdeArt Qte CdeArt Libelle Prix

CL001 A001 2 A001 ARTICLE1 100
CL001 A002 1 A002 ARTICLE2 200
CL001 A003 2 A003 ARTICLE3 300
CL002 A002 5 A002 ARTICLE2 200
CL003 A001 1 A001 ARTICLE1 100
CL002 A002 5 A002 ARTICLE2 200
CL003 A002 3 A002 ARTICLE2 200
NB : de manière optimale, supprimer l’article A004 avant d’effecteur le produit

cartésien.
Remarque
 Le joint est une opération coûteuse en I/0

 Grâce au joint on peut retrouver les informations qui sont éparpillées
dans plusieurs relations
 Chaque fois que la production d’une requête nécessitera l’application
de l’opération ‘’ Sélection’’ et ‘’ joint’’ il est conseillé de commencer
avec la ‘’Sélection’’ afin de rendre la requête optimale
Page 37 sur 37
2.5. L’optimisation de la base de données
Optimiser c’est chercher la meilleure solution. L’optimisation d’une base

de données consiste à diminuer la redondance et augmenter le temps d’accès.
Or, ces deux aspects évoluent dans deux sens opposés.
La diminution de la redondance est un gain en espace (la capacité diminue), or pour
augmenter le temps d’accès il faut dupliquer certaines des informations afin que l’accès
soit rapide.
Dans ce cas, qu’est qu’il faut faire : il faut trouver un meilleur

compromis entre le temps d’accès et la capacité : une solution qui vérifiera toutes ces
contraintes.
NB : ces contraintes sont directement liées aux matériels sur lesquels la base de données
sera implantée. Par matériel nous voyons : l’unité de stockage et le processeur.
Voilà pourquoi nous allons montrer comment estimer la capacité d’une

base de données et comment estimer le temps d’accès d’une requête.
2.5.1. Aspect statique d’une base de données
L’aspect statique représente la capacité de la base de données sur un

support.
Préalables
 Toutes les tables doivent avoir une clé primaire, mais la clé étrangère peut ou ne
peut pas exister.
 Nous allons distinguer trois catégories de tables dans une base de données :
- tables sans clé étrangère : ce sont des tables qui ne font pas référence
à d’autres tables de la base.
Page 38 sur 38
- Tables avec une clé étrangère : ce sont des tables qui font référence
à une seule table de la base.
- Tables avec plusieurs clés étrangères : ce sont des tables faisant
référence à plusieurs tables de la base.
2.5.1.1. Calcul de l’encombrement
L’encombrement d’une base de données sera donné par la somme des

encombrements de toutes les tables qui constituent la base de données. Chaque table
fournira un encombrement qui sera fonction de la taille de ses champs et le nombre de
ses occurrences.
Soit une base de n tables avec Ni et Li respectivement le nombre d’occurrences et la

longueur d’une occurrence de la table i.
n
Enc = N L
i 1
i i (1)
Enc : est l’encombrement de la base de données qui s’exprime en octet ou byte en

anglais.
a) Détermination de longueur d’une occurrence L
La longueur d’occurrence L d’une table i de k champs est la somme de

tailles de tous les champs qui composent la table.
k
Li   C ij (2)
j 1
k : nombre de champs de la table i
b) Détermination du nombre d’occurrences N
Le nombre d’occurrences N d’une table sera déterminé suivant que la

table est sans clé étrangère, avec une clé étrangère ou avec plusieurs clés étrangères.
b.1. Table sans clé étrangère
Page 39 sur 39
Une table sans clé étrangère comme nous l’avions dit ne fait référence à
aucune autre table. Par conséquent, le nombre de ses occurrences ne sera pas influencé
par une autre table. Alors, il sera question, pour déterminer ce que pourrait être le
nombre de ses occurrences, d’observer pour une période donnée la manière dont ces
occurrences ont évolué et essayer de déduire ce qu’ils pourront être après une autre
période fixée, période pendant laquelle la base de données sera opérationnelle.
Soit T une période donnée et T1, T2, T3,…., Tp les sous périodes de la période T tels que :
T1 = T2 = T3 =.......= Tp et
T1 + T2 + T3 +........+ Tp=T
C’est-à-dire les périodes T1, T2, T3,…., Tp ont même durée et leur somme donne la période
T.
Tableau n°1 : Répartition des occurrences par période Ti
Ti T1 T2 T3 ………………. Tp
Ni N1 N2 N3 …………….. Np
1er cas
si  i (i  1,2,3..... p ) Ni+1 – Ni = r avec r un nombre constant, alors la suite Ni suit une

progression arithmétique de raison r.
dans ce cas, le nombre d’occurrences de la table pour la période T+1 pourrait être
estimé à Np + r. Et, s’il faudrait estimer pour une période m après la période T on aura :
Nm = Np + m*r (3)
Nm : nombre d’occurrences à la fin de la période n + m
Np : nombre d’occurrences à la fin de la période T
m : la période après laquelle on veut estimer l’encombrement de la base de données
r : la raison
Page 40 sur 40
2e cas
si  i (i  1,2,3..... p ) Ni+1 / Ni = q avec q un nombre constant, alors la suite Ni suit une

progression géométrique de raison q.
après la période m, le nombre d’occurrences pourront être :
Nm = Np * qm (4)
Nm : nombre d’occurrences à la fin de la période n + m
Np : nombre d’occurrences à la fin de la période T
m : la période après laquelle on veut estimer l’encombrement de la base de données
q : la raison
3e cas
Dans le cas où la progression n’est ni arithmétique ou géométrique, il faudrait

apprécier la tendance de la progression et l’assimilé soit à la progression arithmétique ou
à la progression géométrique avec une raison qui sera la moyenne de ces différentes
raisons.
b.2. La table à une clé étrangère
La clé étrangère de cette table est automatiquement primaire dans une

autre table. C’est cette dernière qui influencera le nombre des occurrences de la table
concernée en fonction de la cardinalité moyenne.
b.2.1. Les cardinalités
Les cardinalités déterminent le nombre de participation d’une occurrence

d’une table dans une relation. Il existe trois types de cardinalité :
 cardinalité minimale(cmin) : le nombre minimum de participation

 cardinalité moyenne(cmoy) : le nombre moyen de participation
 cardinalité maximum(cmax) : le nombre maximum de participation
Page 41 sur 41
b.2.1.1. Détermination de cmin, cmoy, cmax
Nous allons distinguer ici la table mère, la table à la quelle une autre table
fait référence et la table fille qui contient un champ qui est clé primaire dans une table (
table mère).
Chaque occurrence de la table mère a un certain nombre d’occurrences

de la table fille qui font référence à elle.
Tableau n°2 : Répartition de nombre d’occurrences de la table fille qui font référence aux
occurrences de la table mère.
Ce tableau représente pour un certain nombre d’occurrences de la table

mère, le nombre d’occurrences de la table fille correspondantes, c'est-à-dire les
occurrences de la table fille qui admettent comme valeur de la clé étrangère les valeurs
des occurrences choisies de la table mère pendant une période T.
Ni O1 o2 o3 …….. op-1 op
Nombre d’occurrences k1 k2 k3 …….. kp-1 kp
- la cardinalité minimale sera toujours fixée à o ou 1 suivant que dans le MCD la

cardinalité du coté table mère est (o, n) ou (1, n)  cmin=0 ou cmin=1
Mais cela n’empêche, elle peut être fixée à la plus petite valeur contenue dans le tableau
no 2 : cmin = k tel que  i k  ki (i= 1,2…..p)
- la cardinalité maximale sera égale à cmax= k tel que  i k  ki
p
c min  c max
-la cardinalité moyenne sera égale à Cmoy= 1
P  ki
i 1
ou Cmoy=
2
(7)
Le nombre moyen des occurrences dans la table fille sera
k= N *cmoy (7)
Page 42 sur 42
b.3. La table à plusieurs clés étagères
Dans ce cas, les calculs se feront comme dans le cas précédent. Chacune de
ces clés étrangères est primaire quelque part dans une autre table qui doit déterminer le
nombre des occurrences de la table concernée par la formule établie précédemment.
k = N * cmoy
Soit s le nombre de clés étrangères,
k1= N1 * cmoy1
k2= N2 * cmoy2
ks= Ns *cmoys
En principe il faut que :
k1 = k2 = k3 =……..= ky
Il peut arrivée que les ki présentent des légères différences et que ces écarts ne sont pas
1 y
très grands, le nombre d’occurrences sera estimé à  ki
Y i 1
2.2. Application
L’application de notre modèle se présentera de la manière suivante :
1. Construction du MCD
2. Transformation du MCD en MLDR
3. Construction du MLDR quantifié
a. Spécifier les tables sans clé étrangère
-. Etablir le tableau no1
-. Calculer la raison
Page 43 sur 43
-. Calculer N suivant le type de la progression.
b. Spécifier les tables à une clé étrangère
-. Etablir le tableau no 2
-. Calculer cmoy, cmoy et cmax
-. Calculer k(le nombre d’occurrences)
c. Spécifier les tables à plusieurs clés étrangères
- calculer le ki produit par chaque table
k
4. Pour toutes les tables calculer Li   C ij
j 1
5. Appliquer la formule générale de l’encombrement
n k
Enc   N i Li or Li   C ij
i 1 j 1
alors l’encombrement peut être donné par :
n k
Enc   N i  C ij
i 1 j 1
Avec
Ni : nombre d’occurrences de la table i
f : nombre de champ de la table i
Cij : taille du champ j de la table i
Condition d’application : ce modèle sera d’application si la progression est géométrique,

arithmétique ou s’il peut être assimilée à l’une de deux.
Page 44 sur 44
CHAPITRE III. IMPLEMENTATION
L’implémentation consiste à rendre opérationnelle la base de données ;

cela nécessite le choix d’un gestionnaire de base de données adéquat. Et ce choix est
guidé par le type de la base de données choisi au niveau logique.
3.1. Système de gestion de base de données (SGBD)
Un SGBD est un ensemble logiciel / Matériel pour gérer et manipuler

une base de données. Un SGBD se compose de quatre niveaux fonctionnels suivants :
a. Niveau conceptuel : qui, par l’intermédiaire du schéma conceptuel des données

permet de représenter la structure logique de l’ensemble des données : Objet et
liens entre les objets.
b. Niveau global : qui est la représentation dans un modèle logique existant, du
schéma conceptuel à l’aide d’un langage de description des données : schéma
logique.
c. Niveau interne : qui correspond à la structure physique de la base de données :
Schéma physique.
d. Niveau externe : qui permet à chaque utilisateur de voir la base de données
suivant ses propres besoins.
A un niveau global correspond plusieurs niveaux externes. Les

utilisateurs disposent à ce niveau, d’un langage de manipulation de données qui sera
procédural ou non procédural (schéma externe).
Un SGBD doit pouvoir permettre les services suivants :
b. Persistance de données : les données survivent à l’exécution des programmes

c. Disponibilité de données : tout utilisateur doit ignorer l’existence d’autres
utilisateurs concurrents. Les performances du système ne doivent pas se
dégrader du fait de la présence de multiples utilisateurs
Page 45 sur 45
d. Partage de données : Plusieurs utilisateurs doivent pouvoir travailler en même
temps sur la base de données. Le SGBD doit gérer les accès simultanés au
même ensemble des données.
e. La fiabilité : les données sont chères et stratégiques : Elles doivent être fiables.
L’atomicité des transactions garantit que chaque transaction sera : Soit pas du
tout effectuée ou effectuée complètement.
Un GSBD doit permettre de supprimer une transaction non terminée ou de
pouvoir la terminée
f. Résistance aux pannes : la cohérence des données doit être garantie quel que
soit le type d’incident qui peut se produire.
Exemple : En cas de panne mémoire : retour aux dernières transactions
validées.
g. Gestion physique de données : Généralement les données sont trop
volumineuses pour tenir en mémoire centrale. Le SGBD utilise des
techniques spécifiques pour avoir une bonne performance :
1. Gestion de tampons
2. Regroupement des données sur disque
3. Index
h. Manipulation des données : Le langage de manipulation de données (LMD)
permet d’accéder facilement aux données de la base.
Un SGBD est caractérisé par deux langages :
1. Le langage de Définition de Données (DDL) qui permet de décrire le schéma

de la base de données et les contraintes portant sur les données. Il permet de
définir les contrôles d’accès pur déterminer :
1. Qui saisit les informations ;
2. Qui effectue quel type de modification ;
3. Quand a eu lieu la saisie des données ;
4. Quand est ce qu’on les modifie ;
5. Qui peut interroger quelles données ;
6. Qui est autorisé à modifier le schéma de la base ;
7. Qui peut développer les applications
Page 46 sur 46
2. Le langage de Manipulation de Données (LMD) permet d’accéder aux
informations suivant quatre modes :
1. Insertion
2. Modification
3. Suppression
4. Sélection
Dans la plupart des SGBD, il existe la possibilité de développer des

applications à l’aide de langages traditionnels (C, COBOL, FORTRAN, VB, etc.) en
incluant des requêtes SQL dans le code.
Un SGBD relationnel est un système qui manipule les BD relationnelles :

au niveau d’un SGBD, nous nous conviendrons d’appeler Table une relation et champ,
l’attribut. Il faut donner pour chaque champ au moins son ‘’ Type de données’’ et sa
longueur. D’autres propriétés peuvent être ajoutées pour chaque champ. Exemple
Access, Mysql, Oracle, etc.
3.2. Le langage SQL ( Structured Query Langage)
Le langage SQL est un langage de manipulation de données (LMD° qui

permet de rédiger des requêtes permettant d’accéder aux informations stockées dans les
tables (Select), ou des requêtes d’insertion d’information (Insert), de modification
(Update)= ou de suppression d’informations (Delete).
Les requêtes sélection, insertion, modification et suppression, sont

effectuées sur une ou plusieurs tables. Le langage SQL dispose aussi d’une instruction
permettant de créer une table.
3.2.1. Création des tables

Syntaxe
CREATE TABLE NomTable ;
Exemple : Create Table Client ;
Syntaxe
Page 47 sur 47
Create Table NomTable (Liste des champs NomChamp type (longueur) contrainte
obligatoire) ;
Exemple : Create Table Client (Numclient char (10) Non Null, NomClient char (30)
Non Null)
Définition de la clé primaire et étrangère.

Exemple
Create Table Client (NumClient char (10) Non Null, NomClient char (30) Non Null,
NumCat char (30) Non Null, Primary key (NumClient),
Foreign key (Num Cat reference Categorie));
Remarques
La contrainte d’unicité (Clause UNIQUE) permet d’assurer qu’il n’existe
pas de valeur dupliquée dans une colonne.
Exemple
Create Table Client (NumClient char (10) Not Null, NomClient char (20) Unique) ;
Le SGBD comprendra directement qu’il ne faudrait pas avoir deux client

portent le même nom.
La contrainte d’obligation (Clause NOT NULL) autorise et gère une

valeur particulière appelée la valeur nulle. Cette valeur nulle traduit à la fois la valeur
manquante et la valeur inexistante.
La contrainte de clé primaire (Clause Primary key) permet de choisir une

colonne (ou un groupe de colonnes) unique privilégiées dans une table.
La contrainte d’intégrité référentielle admet deux syntaxes selon qu’elle

porte sur une colonne (contrainte de colonne) ou sur plusieurs (contrainte de table).
Dans les deux cas on utilise les clauses REFERENCES et FOREIGN KEY.
Exemple :
Page 48 sur 48
Create Table Vehicule (NumVeh char (10) Not Null, NumPlaque,
NumClient char (10) Not Null),
Primary key (NumVeh),
Foreign key (NumClient) Reference Client);
Voici d’autres commandes liées à la manipulation des tables:
 ALTER TABLE : permet de modifier la structure d’une table ; ajout d’une

colonne, ajout d’une contrainte, modification de la définition d’une colonne,
suppression d’une contrainte, etc.
 DROP TABLE : permet de supprimer une table
 RENAME : permet de modifier le nom d’une table
3.2.2. Interrogation des données
Pour l’interrogation des données, le SQL s’appui sur les opérations de

l’algèbre relationnelle :
3. La projection,
4. La Sélection,
5. La jointure
a. La sélection
Syntaxe
SELECT DISTINCT liste d’attributs FROM Table ;

Ou SELECT Liste d’attributs FROM Table ;
Ou SELECT* FROM Table ;
Exemple
SELECT Libellé, prix FROM Article ;
NB : La clause DISTINCT permet d’éliminer les doublons
Page 49 sur 49
b. La sélection
Elle permet de ne retenir que les n-uplets répondant à une condition

exprimée à l’aide des opérateurs arithmétiques (=, >, <,> =,<=, <> ) ou logique de base
‘ET, OU, NON) ou (AND, OR, NOT) et aussi des opérateurs : IN ; BETWEEN,
LIKE, IS.
Exemple :
Soit la table :
ETUDIANT (NumEtudiant, Nom, Age, Code Postal, Ville)
Quel sera le résultat des requêtes suivantes :
1. SELECT* FROM ETUDIANT

WHERE Age BETWEEN LIKE 19 AND 23 ;

WHERE Age BETWEEN LIKE 19 AND 23 ;

WHERE Code Postal LIKE 42% ;

WHERE Ville IS NULL ;
c. La composition de la sélection et projection

Syntaxe
SELECT attr1, attr2,…FROM Table WHERE Condition ;
Exemple
SELECT Nom, Age FROM ETUDIANT
WHERE Age = 19;
Page 50 sur 50
d. Le joint (Opération jointure  Equijointure)
Remarque
Des jointures plus complexes que l’équijointure peuvent être réalisées en

généralisant l’usage de la condition de jointure à d’autres critères de comparaison que
l’égalité (<,>, <=,>=<>).
Syntaxe : En SQL de base
SELECT* FROM Table1, Table2

WHERE Table1.Attribut1 = Table 2. Attribut1;
Exemple:
SELECT* FROM Client, Article

WHERE Client.CdeArt=Article.CdeArt;
Pour les opérateurs ensemblistes nous aurons :
a. Union
Union (R1, R2)

Syntaxe
SELECT Liste d’attributs FROM Table 1
Union
SELECT Liste d’attributs FROM Table 2;
Exemple
SELECT NumArt, libelle FROM Article
Union
SELECT NumPrd Libelle FROM Produit
Page 51 sur 51
b. Intersection
R2= Intersection (T1, T2)

En SQL
Syntaxe
SELECT Attr1, Attri2, … FROM Table1
WHERE attr1 IN (SELECT Attr1 FROM Table2) ;
Ou
SELECT attr1, attr2, … FROM table1
INTERSECT
SELECT attr1, attr2, … FROM table2;
Exemple:
SELECT NumEnseignant, NomEnseignant FROM E1
WHERE NumEnseignant IN (SELECT n° Enseignant FROM E2)
c. Différence
E = Différence (R1, R2)

En SQL
SELECT Attr 1, Attr2, …FROM table1
WHERE NOT IN (SELECT Attr1 FROM table2) ;
d. Produit
R= Produit (R1, R2)

En SQL
SELECT* FROM Table1, Table2 ;
Exemple
SELECT* FROM Etudiant, Epreuves ;
3.2.3. Insertion de données

La requête SQL INSERT est rédigée à partir des mots clés : INSERT,
INTO, VALUES et peut contenir une requête SELECT.
Page 52 sur 52
Syntaxe
INSERT INTO NomTable (liste attributs)
VALUES (Valeur1 ; Valeur2, …) ;
Ou INSERT INTO NomTable values ( Val1, Val2 ;…)
Exemple
INSERT INTO Article (N°article, Désignation, Prix)
VALUES ( 1001, Ecran, 5000) ;
Ou
INSERT INTO Article
VALUE (A001 ; Ecran, 5000’)
NB. Si un attribut n’a pas de valeur, la clause NULL sera d’application.
Exemple :
Insérer un article dont on ne connaît pas encore le prix.
INSERT INTO Article
VALUES (‘ A002 ; Clavier ; NULL)
3.2.4. Suppression de données

Une requête SQL de suppression est rédigée à partir des mots clés :
DELETE, FROM et WHERE. Une requête DELETE s’applique à une seule Table.
Syntaxe
DELETE FROM NomTable
WHERE Condition ù
Exemple
DELETE FROM Article

WHERE N° Article = A001;
Page 53 sur 53
3.2.5. Modification de données
Une requêtes SQL de modification est rédigée à partir des mots clés :
UPDATE, SET et WHERE. La clause WHERE peut comporter une sous-requête
SELECT. La clause SET peut être suivie de l’affectation de plusieurs attributs. Une
requête UPDATE s’applique à une seule table.
Syntaxe
UPDATE NomTable SET Attribut à modifier
WHERE Condition ;
Attribut à modifier : la modification à apporter
Exemple
UPDATE Article SET Prix = ‘4500’
WHERE N° Article = ‘A001’ ;
Ou
UPDATE Article SET Prix = ‘2500’
WHERE N° Article = ‘A001’ ou N° Article A002’;
3.2.5. Les fonctions d’agrégats
Ce sont des fonctions qui agissent sur des ensembles (multi-ensembles) de valeurs :
AVG : la valeur moyenne de l'ensemble
MIN : la valeur minimale
MAX : la valeur maximale
SUM : le total des valeurs de l'ensemble
COUNT : le nombre de valeur dans l'ensemble
SELECT COUNT(Titre) FROM Programme

Cette requête retourne le nombre de films programmés à Bordeaux.
Attention : Un même titre peut être compté plusieurs fois s'il est programmé à des heures
différentes et dans des salles différentes.
SELECT COUNT( DISTINCT Titre) FROM Programme
Page 54 sur 54
Agrégats et GROUP BY
Le nombre de films programmés dans chaque salle :
SELECT NomCiné, COUNT (DISTINCT Titre)
FROM Programme
GROUP BY NomCiné
Les attributs qui apparaissant dans la clause SELECT en dehors des agrégats doivent
être associés à la clause GROUP BY
Agrégats et la clause HAVING

Les salles où sont programmés plus de 3 films :
SELECT NomCiné, COUNT(DISTINCT Titre)

FROM Programme
GROUP BY NomCiné
HAVING COUNT (DISTINCT Titre) > 3
Le prédicat associé à la clause HAVING est testé après la formation des groupes
définis dans la clause GROUP BY.
3.3. Les couches d’une application

Toute application informatique est constituée de trois couches :
 La couche persistance ou couche de données ;
 La couche de traitement ;
 La couche interface
Pour l’implantation de nos bases de données relationnelles, nous allons

utiliser le SGBD Access. Il nous reviendra maintenant d’associer à chacune de ces trois
couches, les objets qu’Access dispose pour la mise en place d’une application Access.
3.3.1. La couche persistance

La couche persistance d’une application constitue son fondement même,
et est constituée par les bases de données qui, en Access seront représentées par les Objet
‘’ Table’’.
Page 55 sur 55
Une table est une transformation au niveau physique d’une relation du
schéma logique.
Pour manipuler tous les objets d’une base de données, Microsoft Access
utilise la fenêtre ‘’ Base de données’’. Un Clique sur un type d’objet, la fenêtre base de
données affiche la liste des objets de ce type. Utiliser le bouton dans la barre d’outils de la
fenêtre base de données ou les options ‘’ Créer’’ ; ‘’ Modifier’’ en haut de la liste pour
créer de nouveaux objets. Utiliser le bouton Modifier pour modifier la structure de ces
objets existants
a. Création d’une base de données Access

Une base de données Access est créée comme un fichier Word, Excel,
etc. il suffit de cliquer avec le bouton droit de la souris sur le bureau ou dans n’importe
quel dossier, pointer sur nouveau et cliquer sur ‘’ Base de données Access’’. Donner un
nom à la base, puis valider.
Utiliser les outils disponibles pour concevoir les trois 3 couches.
Page 56 sur 56
Application
3.1. Application de l’approche par vue descriptive
Etant donné la vue descriptive pour le système d'information qui

permet de calculer l’encombrement d’une base de données.
L’encombrement d’une base de données est donné par la somme des

encombrements de toutes les tables qui constituent la base de données. Chaque table
fournira un encombrement qui sera fonction de la taille de ses champs et le nombre de
ses occurrences.
Soit une base de n tables avec Ni et Li respectivement le nombre d’occurrences et la

longueur d’une occurrence de la table i.
n
Enc = N L
i 1
i i (1)
Le système consistera à calculer l’encombrement de plusieurs bases de

données. Une certaine base de données sera caractérisée par un numéro d’ordre est un
nom pour la distinguer des autres. Chaque base est constituée d’une ou plusieurs tables
qui contiennent des champs ayant un nom, un type et une taille.
Ces tables sont regroupées en deux catégories :
 table sans clé étrangère : est celle qui ne fait référence à aucune autre table. Un
tableau des statistiques est associé à cette table pour permettre de déduire le
nombre de ses enregistrements.
 table avec clé étrangère : est celle qui fait référence à d’autres tables. A cette
dernière est associé un tableau qui permet de trouver les valeurs de trois
cardinalités (Min, Moy et Max).
Plusieurs simulations peuvent être faites afin d’apprécier ce que pourrait
être l’encombrement de la base de donnée et, ces différents résultats doivent être gardés
dans le système.
Page 57 sur 57
Application de la démarche
Première partie : Elaboration du dictionnaire de données et des règles de gestion

Dictionnaire de données
Identifiant Nom Type Taille Observation

NumBD N°base de donnée AN 5 Unique
NomBD Nom de la base de données AN 30
Description Description AN 100
NumChamp N°propriété N 4 Unique
Nmhamp Nom propriété AN 9
Type Type propriété AN 5
Taille Taille propriété N 4
Numtable N°table AN 6 Unique
Nmtable Nom de la table AN 10
CleEtrangere Clé étrangère Booléen
NumTableau N°Tableau AN 4 Unique
NomTableau Nom Tableau AN 25
Utilite Utilité AN 30
Valeur Valeur N 4
NumEncomb N°Encombrement N 4 Unique
CapacitéC Capacité calculée N 4
Règles de gestion

5. une même base de données peut avoir plusieurs encombrement suivant la
simulation faite
Page 58 sur 58
Deuxième partie : Démarche de structuration des données
La structuration des données du dictionnaire des données s'effectue en 5

étapes :
1. Détermination de la liste des DF simples
Source
1 4 8 10 14
But
1 NumBD *
2 NomBD 1
3 Description 1
4 NumChamp *
5 NmChamp 1
6 Type 1
7 Taille 1
8 Numtable *
9 Nmtable 1
10 NumTableau *
11 NomTableau 1
12 Utilite 1
13 Valeur
14 NumEncombrement *
15 Capacite 1
16 CleEtrangere 1
Ces DF renseignent sur les entités et leurs propriétés respectives.
2. Détermination de la liste des DF entre les identifiants
Source
1 2 3
But
1 NumBD *
2 NumTable 1 *
3 Numchamp 1 *
4 NumEnc 1
Ces dépendances permettent de déduire les relations hiérarchiques que

l’on aura dans le schéma conceptuel de données.
3. Prise en compte des attributs non classés dans l'étape 1 et détermination des DF
composées
Source
DF1
But
1 NumTable G
2 NumTableau G
3 Valeur D
Page 59 sur 59
C'est-à-dire le numéro de la table et celui du tableau déterminent la valeur.
4. Elimination des transitivités du schéma des DF
Dans notre cas la transitivité n’existe pas.
5. Construction, à partir des DF simples, des entités de la base de données
Nous aurons les entités suivantes :
Base de données : NumBD, NomBD et Description
Table : NumTable, Nomtable et CleEtrangere
Champ : NumChamp, NomChamp, type et taille
Tableau : Numtableau, NomTableau et utilité
Encombrement : NumEnc et capaciteC
6. Construction, à partir des DF composées, des relations non hiérarchiques de la

base de données
Une seule relation non hiérarchique entre l’entité Table et Tableau et

cette relation a pour propriété « valeur ».
Page 60 sur 60
7. Construction du schéma
ENCOMBREM CHAMP
NumEnc NumChamp
CapaciteC NomChamp
Type
Taille
(1,1) (1,1)
Occuper Appartenir
(1,n) (1,n)
BASEDONNE TABLE
NumBD (1,n) Contenir (1,1) NumTable
NomBD Nomtable
Description CleEtrangere
(1,n)
TABLEAU Affecter
valeur
NumTableau
Nomtableau
(1,n)
Utilite
Transformation du MCd en MLDR
En vertu de la première règle nous urons :
BASEDONNEE ( NumBD, NomBD, Description)
TABLE ( NumTable, Nomtable, CleEtrangere)
CHAMP ( NumChamp, NomChamp, type, taille)
TABLEAU ( Numtableau, NomTableau, utilite)
ENCOMBREMENT ( NumEnc, capaciteC)
En vertu de la deuxième règle :
Les tables TABLE, CHAMP et ENCOMBREMENT deviennent :
Page 61 sur 61
TABLE (NumTable, Nomtable, CleEtrangere, NumBD#)
CHAMP ( NumChamp, NomChamp, type, taille, Numtable#)
ENCOMBREMENT ( NumEnc, capaciteC, NumBD#)
En vertu de la troisième règle :
AFFECTER ( Numtable#, Numtableau#, valeur)
Ainsi le MLDR est
BASEDONNEE ( NumBD, NomBD, Description)
TABLEAU ( Numtableau, NomTableau, utilite)
TABLE(NumTable, Nomtable, CleEtrangere, NumBD#)
CHAMP ( NumChamp, NomChamp, type, taille, Numtable#)
ENCOMBREMENT ( NumEnc, capaciteC, NumBD#)
AFFECTER ( Numtable#, Numtableau#, valeur)
C’est ce MLDR et le dictionnaire de données qui vont permettre à

construire la couche persistance de notre application.
Soit à normaliser la relation suivante :


simulation faite
Page 62 sur 62
15. Une même base de données peut avoir plusieurs encombrements suivant la
simulation faite.
16. une table peut avoir plusieurs tableaux de statistiques permettant de calculer le
nombre d’enregistrement ou la (les) cardinalité (s)
Première forme normale
- Choix de la clé primaire
NumBD, NumTable, NumChamp, NumTableau, NumEnc
- Rendre tous les attributs atomiques
Vu les dictionnaires de données et connaissant l’exploitation de

différents attributs dans le système, nous pouvons dire que tous les attributs sont
atomiques.
Deuxième forme normale
- Elle est en première forme normale

- Rendre totales toutes les DF partant de la clé primaire vers les autres attributs
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Description (1)

NumBD, NumTable, NumChamp, NumTableau, NumEnc → Nomtable (2)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → CleEtrangere (3)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → NomChamp (4)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Type (5)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Taille (6)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Nomtableau (7)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Utile (8)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Valeur (9)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → Capacité(10)
NumBD, NumTable, NumChamp, NumTableau, NumEnc → NomBD (10’)
A ce stade, nous allons vérifier si toutes ces DF sont totales, c’est-à-dire

si toute la partie détermine la partie de droite. Sinon on élimine l’augmentation.
Page 63 sur 63
(1) Non parce que NumBD → Description (11)

(2) Non parce que NumTable → NomTable (12)
(3) Nom parce que Numtable→ CleEtrangere (13)
(4) Nom parce que NumChamp→ NomChamp (14)
(5) Nom parce que NumChamp→ Type (15)
(6) Nom parce que NumChamp→ Taille (16)
(7) Nom parce que NumTableau→ NomTableau(17)
(8) Nom parce que NumTableau→ Utile(18)
(9) Nom parce que NumTable→ Valeur(9)
(10) Nom parce que NumEnc→ CapaciteC(10)
(10’) Nom parce que NumBD→ NomBD(11)
Regroupement de DF ayant la même source et application de l’union :
NumBD→ Description(11)
NumBD→ NomBD(10’)
En appliquant l’union, on aura : NumTable→ NomTable, CleEtrangere(22)

NumChamp→ NomChamp(14)
NumChamp→ Type(15)
NumChamp→ Taille(16)
En appliquant l’union, on aura : NumChamp→ NomChamp, Type, Taille(23)
NumTableau→ NomTableau(17)
NumTableau→ Utile(18)
En appliquant l’union, on aura : NumTableau→ NomTableau, Utilite (24)
On obtient ainsi les relations suivantes :
R1 (NumBD, Description, NomBD)

R2 (NumTable, NomTable, CleEtrangere)
R3 (NumChamp, NomChamp, Type, Taille)
R4 (NumTableau, NomTableau, Utilite)
R5 (NumTable, NomTableau, Valeur)
R6 (NumEnc, CapaciteC)
Troisième forme normale
Page 64 sur 64
- En deuxième forme norme : OK
- Rendre directe toutes les DF
R5 et R6 ayant seulement la clé et un attribut, automatiquement toutes leurs DF sont

directes.

En rapport avec les règles de gestion, nous avons remarqué qu’il n’y a
pas présence d’une clé secondaire dans ces quatre relations. Ce qui implique que, à part
la clé primaire, il n’existe pas un attribut qui peut déterminer les autres attributs créant
ainsi une transitivité. Alors nous pouvons dire que ces 4 relations sont en troisième
forme normale.
Les relations normalisées qui vont former la couche persistante sont :

R5 (NumTable, NomTableau, Valeur)
R6 (NumEnc, CapaciteC)
Il ne reste qu’à nommer ces relations de manière descriptive c’est-à-dire

donner les noms qui reflètent le contenu.
BASEDONNE ( NumBD, Description, NomBD)

TABLE (NumTable, NomTable, CleEtrangere)
CHAMP (NumChamp, NomChamp, Type, Taille)
TABLEAU (NumTableau, NomTableau, Utilite)
AFFECTER (NumTable, NumTableau, Valeur)
ENCOMBREMENT (NumEnc, capaciteC)
L’étape suivante dans la création d’une application base de données est

le recensement des acteurs et le rôle de chacun dans le système. Le rôle d’un acteur dans
Page 65 sur 65
le système ou le « use case » permet de connaître le type d’interface qu’il faudrait
mettre à la disposition de celui-ci pour qu’il puisse bien jouer son rôle.
Par type d’interface, nous entendons les données manipulées par l’acteur, les traitements
et les différents liens entre les interfaces susceptibles d’être accédé par l’acteur à partir
de cette dernière.
En fin de compte, une bonne conception de la base de données doit

permettre un équilibre entre un stockage efficace des données et la facilité d'extraction
et d'analyse de ces mêmes données.
EXERCICE
SERIE A.
1. Au moyen d’un exemple concret, parlez de l’expressivité d’un schéma conceptuel
de données.
2. Pourquoi normaliser une relation ?
3. L’absence d’une clé étrangère implique directement l’existence d’une contrainte
d’intégrité référentielle. Oui ou Non, justifiez votre réponse.
4. Votre voisin a dit qu’il aime une relation non normalisée. Quelles sont les
difficultés auxquelles il peut être buté.
5. Dans quel cas la contrainte obligatoire peut être appliquée à une clé primaire
6. Votre ami a dit que Le choix du type de la base de données est effectué au niveau
physique. Est-ce qu’il a raison.
7. Donner un exemple montrant que le langage SQL est un langage de
manipulation de données
8. La présence d’une clé étrangère implique directement l’absence d’une contrainte
d’intégrité référentielle. Oui ou Non, justifiez votre réponse.
9. Une relation avec clé étrangère est une relation fille. Réagissez.
10. A quoi sert la deuxième forme normale
11. Votre voisin a dit que le choix du SGBD est effectué au niveau conceptuel est-ce
qu’il a raison.
12. L’absence d’une clé étrangère implique directement la non existence d’une
contrainte d’intégrité référentielle. Oui ou Non, justifiez votre réponse.
13. Donner un exemple montrant que le langage SQL est un langage de description
de données.
Page 66 sur 66
14. A quoi sert la troisième forme normale
15. Quand est ce qu’une relation est considérée comme normalisée
16. le choix du type de la base de données est effectué au niveau conceptuel
17. dans quel cas la contrainte obligatoire ne peut être appliqué à une clé primaire
18. dans le processus de normalisation d’une relation, le choix de la clé primaire est
effectué au niveau de la deuxième forme normale. Réagissez.
SERIE B
B.1.
Dans un hôpital, chaque malade est caractérisé par un nom et une
adresse. Pour chaque consultation, le médecin consultant prescrit une liste de produits à
prendre et la quantité. Chaque produit est caractérisé par un code produit, un libellé, prix
et la catégorie à laquelle le produit appartient.
Règles de gestion
- un malade peut être consulté par plusieurs médecins à des dates différentes
- deux malades peuvent avoir un même nom
- un même médecin peut consulter plusieurs malades
- une catégorie peut contenir un ou plusieurs produits
- un même produit ne peut pas appartenir à plusieurs catégories
Question
1. Construire le schéma conceptuel de données
2. Produire le Modèle Logique de Données Relationnel
3. quelles sont les CIR produites par les relations non hiérarchiques
4. Quel type de relation existe entre Nom Malade et Code Produit
5. Montez que Votre MLDR obtenu est normalisé.
B.2.
Gestion des matériels
Dans ce système d'information, chaque ordinateur est caractérisé par la
capacité de son disque dur, de sa mémoire RAM, la vitesse du processeur, le coût de
Page 67 sur 67
fabrication et son appartenance à une maison de fabrication qui se trouve à une adresse
donnée.
Règles de gestion
- un même ordinateur ne peut pas appartenir à plusieurs maisons de fabrication,

- une même maison fabrique plusieurs ordinateurs,
- chaque jour les ordinateurs entrent et sortent du stock à de quantités différentes
- le coût de fabrication d'un ordinateur ne change pas
- A une fabrication donnée sont attachés plusieurs ordinateurs fabriqués
Question
6. Construire le schéma conceptuel de données
7. Produire le Modèle Logique de Données Relationnel
8. quelles sont les CIR produites par les relations hiérarchiques
9. Quel type de relation existe entre Capacité disque dur et Capacité Mémoire RAM
10. Votre MLDR obtenu est normalisé. Démontrez
B.3.
Gestion des comptes
Dans ce système d'information, un client ouvre un compte en une date donnée et qui est
caractérisé par: un numéro de compte, le numéro du client (proposer aussi les autres
coordonnées du clients) et la catégorie ( FC ou dollars).
Les mouvements de ce compte sont le dépôt ou le retrait qui sont caractérisés par: la date
et le montant.
Questions
1. Editer la liste de tous les comptes de la catégorie X.
2. Quel est le nom de l'opération de l'algèbre relationnelle qu'il faudrait utiliser pour
avoir la liste des clients de la catégorie " FC".
3. Pourquoi un bon SGBR doit gérer l'atomicité de transactions
4. Posez vous une question exigeant l'utilisation de la jointure et écrivez cette requête
en SQL
5. Quels sont les points communs entre la projection et la sélection
Page 68 sur 68
B.4.
Soit la relation AGENT (Mat, Nom, Salaire, Dépôt, formation)
1. Donner la liste des agents (Nom et salaire) pour lesquels le salaire est compris
entre 1000 et 1500
2. donner la liste des agents (Nom, fonction et dépôt)
3. Concevoir une base de données de gestion de payement des frais d’études à l’ISS
(Jour, soir et Likasi).
Un étudiant est caractérisé par le numéro matricule, le nom et le sexe. Au début

de chaque année, l’étudiant s’inscrit en payant le frais d’inscription. Au cours de
l’année l’étudiant les différents frais exigés jusqu’à leur apurement.
B.5.
Normalisez la relation suivante

simulation faite
B.6.
Page 69 sur 69
Soit la base Cinéma ayant le schéma Cinéma (Film, Lieu, Pgme_hebdo). Les schémas
de relation sont les suivants
Films(Titre, Réalisateur, Acteur), Lieu(Salle, Adresse, Tel) et Pgme_hebdo(Salle, Titre,

jour, horaire). Exprimer les requêtes suivantes en SQL
1. Qui est le réalisateur de "The big Lebowsky" ?

2. Dans quelles salles passe le film "Cris et chuchotements" (On veut le nom de la
salle ainsi que son adresse) ?
3. Quels sont les réalisateurs qui jouent dans leurs propres films
4. Donner les paires de personnes (Pi, P2) telles que Pi a dirigé P2 dans un film et
P2 a dirigé Pi dans un autre.
5. Quelles sont les salles où je pourrais voir un film de où joue "J.P Bacri"'?
6. Quelles sont les salles qui programment tous les films de où joue "J.P Bacri"?
7. On veut pour chaque réalisateur, le nombre de ses films qui sont programmés, à
condition que ce nombre soit supérieur à 3.
8. Quels sont les réalisateurs qui ont dirigé le plus d'acteurs.
9. Quels sont les réalisateurs qui ont dirigé plus d'acteurs que Bergman et Hitchcok
B.7.
Soit la base Enseignement(Etudiant, Cours, Inscrit, Enseignant) où les schémas des

relations sont respectivement
Etudiant(NumE, NomE, AgeE)

Cours(NomC, HoraireC, SalleC, EnsC)
Inscrit(NumE, NomC)
Enseignant(NumEn, NomEn, NumDept)
Exprimer les requêtes suivantes en SQL
1. Quels sont les cours ayant lieu en salle 123?

2. Quels sont les cours pour lesquels il y a plus de 5 inscrits ?
Page 70 sur 70
3. Quels sont les noms des étudiants inscrits à au moins deux cours prévus aux
mêmes horaires ?
4. Quels sont les enseignants qui ont moins de 20 étudiants (en considérant tous les
cours qu'ils assurent) ?
5. Quels sont les noms des étudiants ayant le plus d'inscriptions ?
6. Quels sont les étudiants qui ne sont inscrits à aucun cours ?
Page 71 sur 71
B.8.
Votre société veut créer une petite base de données de gestion des commandes
pour contrôler ses stocks et ainsi pouvoir alimenter ses clients de manière ininterrompue,
et ce qu'elle que soit la demande.
Chaque client est une société avec une raison sociale et un numéro de client
interne à votre entreprise. Pour des raisons pratiques, vous possédez le nom d’un contact
et sa fonction au sein de l’entreprise. Votre société, pour des raisons d’organisation, ne
veut avoir à faire qu’à un et un seul contact. De plus, vous connaissez évidemment le
numéro de téléphone, le fax et l’adresse de votre client.
Vous possédez une gamme de produits en catalogue, parmi lesquels les clients
peuvent commander. Un produit possède une référence, un nom et un prix unitaire. Il
entre dans une catégorie codée. Chaque catégorie a en plus d’un code, un nom et une
description. Elle référence logiquement plusieurs produits.
Vous recevez ainsi des commandes d’un client, chacune d’entre elles pouvant
contenir un ou plusieurs produits. Cette commande est numérotée et datée. Le ou les
produits qui la composent sont vendus à un prix de vente qui peut différer du prix
unitaire, puisque votre société décide de sa marge selon ses clients.
A partir de ce texte :
* construire un dictionnaire de données,
* construire les dépendances fonctionnelles,
* construire le MCD et le MLD.
* proposer quelques requêtes et leurs instructions SQL
* proposer quelques utilisateurs du système et leur rôle + interface
* + Implémentation en Access.
Page 72 sur 72
CONCLUSION GENERALE
Dans le processus de création d'une base de données, l'établissement du

schéma relationnel de la base de données représente l'étape fondamentale. Il est inutile
d'aller plus loin, et de se ruer sur l'ordinateur, tant que cette étape n'est pas parfaitement
maîtrisée.
Comme nous pouvons le constater, on n'utilise pas de moyens
informatiques au cours de cette étape. Il existe certes des logiciels d'aide à la création du
schéma relationnel, qui rendent service dans les cas très complexes, mais les cas que
nous rencontrerons nécessiteront surtout de la réflexion, de la méthode et du bon sens.
Nos outils seront du papier, un crayon... et une bonne gomme !
Lorsque le schéma relationnel parait admissible, nous devons le testez par

simulation sur papier. Nous devons suivre les relations et vérifier que les tables peuvent
être remplies sans problème. Alors, mais alors seulement, nous pouvons nous asseoir
devant l'ordinateur, et lancer le SGBD cible. Mais là encore, soyons prudent : dès que
nous avons introduit une petite quantité de données, testons le système et retestons-le.
Car corriger le schéma relationnel d'une BD qui est déjà remplie de données est
presque toujours une opération douloureuse.
Page 73 sur 73
BIBLIOGRAPHIE
1. Christian Carrez, Des structures aux bases de données ; Dunod, Paris, France, 1990.
2. T. Conolly, C Begg, and A Strachan, Database systems, A practical approach to

design, implementation and
management; Addison Wesley,
Harlow, England, 1996, ISBN
3. PHILIPPE MATHIEU, Base de données, LIFL, USTL, 1999
4.Joshua S.,Dupin J.J., Introduction à la didactique des sciences et des mathématiques,

PUF,1993, Paris
5. Jacky Akoka and Isabelle Comyn-Wattiau. Conception des bases de données

relationnelles. Vuibert informatique, 2001.
6. Didier Banos and Michel Mouyssinat. De Merise aux bases de données. Eyrolles,
1990.

Base de Données G3

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Base de Données G3

Transféré par

Droits d'auteur :

Formats disponibles

Cours de Technique de Bases de Données

G3 Informatique de Gestion Ass Lucide Bula

Un système d'informations est un ensemble des ressources susceptibles de

Avant de se lancer dans le vif de notre cours, il sied de signaler d'abord la

a. Les bases de données

Une base de données est un ensemble des données organisées d'une

b. Les applications base de données

Les fiches et formulaires sur papiers nécessitent à ce que l'homme,

Donc, ce cours ne se limitera pas à la seule conception de la base de

b. La non redondance des données

c. L’indépendance entre programme et données

Il existe trois types de base des données :

c. Les bases de données relationnelles

Dans le cadre de ce cours, nous aborderons la conception et la mise en place

4. Création d’une base de données

L’une des phases essentielles dans la conception d'une base de données

La première étape pour concevoir une application base de données est

En effet, une erreur de conception pourrait en générer d’autre bien plus

En rapport avec la méthode MERISE, la modélisation se réalise en quatre

Univers d’application Niveau d’abstraction

Passage au Modèle Niveau logique

Implantation sur le Niveau physique

A ce niveau le contenu de la base est représenté en termes conceptuels,

Ce niveau résulte de la traduction du schéma conceptuel en un schéma

Il s’agit ici de la description des méthodes d’organisation et d’accès aux

Ce cours vise à initier les étudiants finalistes du premier cycle en informatique

5.2. Objectifs spécifiques

A la fin de ce cours l’étudiant devra être capable :

CHAP.II : MODELISATION LOGIQUE RELATIONNELLE

La modélisation conceptuelle est une étape fondamentale de la conception

La modélisation d’un système consiste à construire un modèle pour ce

Si dans son acception première un modèle est défini comme un objet ou

Très pragmatiquement, l'intérêt d'un modèle réside dans sa capacité à

Le modèle qui sera construit à ce niveau est le modèle Entité- Relation ou

Les éléments de base du modèle ER (Entité-Relation) ou E-A (Entité-

A titre illustratif, l’entité CONTRAT n’existe que si l’entité CLIENT

Ainsi CLIENT, VEHICULE, CONTRAT sont considérés comme des

1.3. Les attributs

Un attribut est une caractéristique ou une propriété d’une entité. Un attribut

La notion de domaine de valeurs fait allusion au type de données que

A titre illustratif, le Numclient, le Nomclient et l’Adresse sont de propriétés de

Parmi tous les attributs de l’entité, l’identifiant est un attribut ou un ensemble

Il est a noter que l’entité faible aura un identifiant composé de l’identifiant de

1.4. Les relations

La description complète d’une relation nécessite la définition précise de la

1.4.1. Types de cardinalités

Un employé ne peut être directeur que dans un seul département et un

Un département peut occuper plusieurs employés, mais un employé ne peut

c. Cardinalité plusieurs à plusieurs

Les deux entités participent plusieurs fois dans la relation

Les cardinalités présentées ci-dessus sont appelées ‘’Cardinalités maximales’’

Le deux cardinalités ; maximale et minimale traduisent les contraintes

Dans un schéma conceptuel (MCD), elles sont représentées comme suit :

0 - 1 : Aucune ou une seule

1.4.2. Types de relations

Il existe deux types de relations, les relations hiérarchiques et les

NumMere (1,n) Est mère de (1,1) NumEnfant

CdeArticle (1,n) ACHETER (1,n) NumClient

Une situation à modéliser peut avoir plusieurs schémas différents ; chaque

Il existe plusieurs critères permettant de mesurer la qualité d’un schéma E-R.

- L’expressivité : traduit la richesse sémantique du schéma ;

1.5. Construction d’un schéma conceptuel (MCD)

La construction d’un schéma conceptuel peut se réaliser de la manière