Support de Cours BD

Support de cours
Bases de Données Avancées

Pour 1ère Année Master
De la spécialité Génie Logiciel
Réalisé par
Mme NGUEYAP
Année universitaire
2022/2023
Bases de données avancées
Introduction....................................................... 10
CHAPITRE 1
Système d’Information
1.1. Définition d’un SI ....................................................................................................................... 13
1.2. Composantes d’un SI ................................................................................................................. 14
1.3.1. Sous-systèmes d’un SI ........................................................................................................... 15
1.3.1. Sous-système opérationnel ............................................................................................... 15
1.3.2. Sous-système décisionnel.................................................................................................. 15
1.3.3. Sous-système d’information (ou de communication) ....................................................... 15
1.4. Processus de développement d’un système d’information ...................................................... 16
1.4.1. Cycle de développement ................................................................................................... 16
1.4.2. Cycle de vie ........................................................................................................................ 17
1.4.3. Les modèles de cycle de vie .............................................................................................. 17
1.4.3.1. Modèles linéaires ...................................................................................................... 17
1.4.3.2. Modèles itératifs ....................................................................................................... 18
1.4.3.3. Modèles agiles ........................................................................................................... 19
1.5. Notion de base de données (BD) ............................................................................................... 21
1.5.1. Définition d’une BD ........................................................................................................... 21
1.5.2. Fonctions d’une base de données ..................................................................................... 21
1.6. Système de Gestion de base de données (SGBD) ..................................................................... 22
1.6.1. Définition d’un SGBD ......................................................................................................... 22
1.6.2. Niveaux d’abstraction ........................................................................................................ 23
1.6.2.1. Niveau conceptuel ..................................................................................................... 23
1.6.2.2. Niveau interne ......................................................................................................... .. 24
1.6.2.3. Niveau externe .......................................................................................................... 24
1.6.3. Historique des SGBDs ........................................................................................................ 25
1.6.4. Avantages des SGBDs ........................................................................................................ 26
1.7. En résumé .................................................................................................................................. 28
1.8. Exercices .................................................................................................................................... 28
Exercice 1 : ......................................................................................................................................... 28
2
Exercice 2 : ......................................................................................................................................... 28
1.9. Références du chapitre ............................................................................................................. 29
CHAPITRE 2
Bases de données relationnelles
2.1. Modèle relationnel : description des données.......................................................................... 31
2.2. Normalisation par décomposition ............................................................................................. 32
2.2.1. Contraintes d’intégrité ...................................................................................................... 32
2.2.1.1. Définition de la clé de relation .................................................................................. 33
2.2.1.2. Définition de la dépendance fonctionnelle ............................................................... 33
2.2.2. La décomposition d’une relation ....................................................................................... 34
2.2.3. Formes normales ............................................................................................................... 34
2.2.3.1. Première forme normale ........................................................................................... 35
2.2.3.2. Deuxième forme normale ......................................................................................... 35
2.2.3.3. Troisième forme normale .......................................................................................... 35
2.2.3.4. Forme normale de Boyce and Codd .......................................................................... 36
2.3. Langage de requêtes SQL .......................................................................................................... 37
2.3.1. Data Definition Langage (DLL) ........................................................................................... 37
2.3.1.1. Création d’un schéma ................................................................................................ 37
2.3.1.2. Création d’une table .................................................................................................. 37
2.3.1.3. Les clés de relation .................................................................................................... 39
2.3.1.4. Opérations sur les tables ........................................................................................... 39
2.3.2. Data Manipulation Langage (DML) .................................................................................... 41
2.3.2.1. Requêtes simples ....................................................................................................... 41
2.3.2.2. Données dérivées ...................................................................................................... 42
2.3.2.3. Fonctions statistiques ................................................................................................ 43
2.3.2.4. Condition par sous requêtes ..................................................................................... 44
2.3.2.5. Extraction de données de plusieurs tables................................................................ 45
2.3.2.6. Extraction de données groupées ............................................................................... 45
2.3.2.7. Modification des données ......................................................................................... 46
2.3.2.8. Mise à jour et contraintes référentielles ................................................................... 47
2.4. En résumé .................................................................................................................................. 48
2.5. Exercices .................................................................................................................................... 48
Exercice1 : .......................................................................................................................................... 48
Exercice2 : .......................................................................................................................................... 49
3
Exercice3 : .......................................................................................................................................... 49
Exercice4 : .......................................................................................................................................... 49
2.6. Références du chapitre ............................................................................................................. 50
CHAPITRE 3
Base de données objet
3.1. Historique des bases de données objet .................................................................................... 52
3.2. Concepts fondamentaux ........................................................................................................... 53
3.2.1. Objet .................................................................................................................................. 53
3.2.2. Classe ................................................................................................................................. 53
3.2.3. Objets complexes .............................................................................................................. 54
3.2.4. Identité de l’objet .............................................................................................................. 54
3.2.5. Encapsulation .................................................................................................................... 54
3.2.6. Extensibilité ....................................................................................................................... 54
3.2.7. Classes hiérarchiques et Héritage ...................................................................................... 54
3.2.8. Redéfinition et surcharge .................................................................................................. 55
3.3. Base de données Orientées Objet (OODB) ................................................................................ 55
3.3.1. Langage de définition objet ODL ....................................................................................... 55
3.3.1.1. Les classes .................................................................................................................. 55
3.3.1.2. Les attributs et les contraintes .................................................................................. 56
3.3.2. Langage de requête objet OQL .......................................................................................... 59
3.3.2.1. Les résultats d’une requête OQL ............................................................................... 59
3.3.2.2. Utilisation des méthodes dans les requêtes ............................................................. 60
3.3.2.3. Les requêtes embarquées ......................................................................................... 60
3.3.2.4. La quantification existentielle et universelle ............................................................. 61
3.3.2.5. Ordonner le résultat .................................................................................................. 61
3.3.2.6. Collection ................................................................................................................... 62
3.3.2.7. Agrégation et groupement ........................................................................................ 62
3.4. Bases de données Relationnelles-Objet (BDRO) ...................................................................... 63
3.4.1. Les types de données intégrés .......................................................................................... 63
3.4.1.1. Le type ligne .............................................................................................................. 63
3.4.1.2. Les types collections .................................................................................................. 64
3.4.2. Types de données définis par l’utilisateur (UDTs) ............................................................. 65
3.4.2.1. Les types distincts ...................................................................................................... 65
3.4.2.2. Les types structurés ................................................................................................... 66
4
3.4.2.3. Méthode définie par l’utilisateur .............................................................................. 66

3.4.3. Types, tables et hiérarchie ................................................................................................ 66
3.4.4. Relation.............................................................................................................................. 68
3.5. En résumé .................................................................................................................................. 68
3.6. Exercices .................................................................................................................................... 69
Exercice 1..................................................................................................................................... 69
Exercice 2: ................................................................................................................................... 69
Exercice 3:.................................................................................................................................... 70
CHAPITRE 4
Base de Données Distribuées
4.1. Motivation ................................................................................................................................. 72
4.2. Définition d’une BDD ................................................................................................................. 72
4.3. Définition d’un SGBDD .............................................................................................................. 73
4.4. Avantages des SGBDD ............................................................................................................... 73
4.4.1. Indépendance des données .............................................................................................. 73
4.4.2. Transparence de la distribution ......................................................................................... 73
4.4.3. Transparence de la fragmentation .................................................................................... 73
4.4.4. Fiabilité garantie par les transactions distribuées ............................................................. 73
4.4.5. Performance améliorée ..................................................................................................... 73
4.5. Architectures des BDDs ............................................................................................................. 74
4.5.1. Modèle Client/Server .................................................................................................... 74
4.5.2. Modèle Peer to Peer (P2P) ............................................................................................ 74
4.5.3. Modèle Multi-BDs.......................................................................................................... 75
4.6. Conception d’une BDD ........................................................................................................ 75
4.6.1. Conception descendante ................................................................................................... 75
4.6.1.1. Fragmentation ........................................................................................................... 76
4.6.1.1.1. Fragmentation horizontale ........................................................................................ 77
a) Fragmentation horizontale primaire ................................................................................. 78
b) Fragmentation horizontale dérivée ................................................................................... 78
4.6.1.1.2. Fragmentation verticale ............................................................................................ 79
4.6.1.1.3. Fragmentation hybride .............................................................................................. 80
4.6.1.2. Allocation .................................................................................................................. 81
4.6.2. Conception ascendante ..................................................................................................... 82
5
4.7. Réplication ..................................................................................................................... 82

4.7.1. Objectifs de la réplication .................................................................................................. 82
4.7.2. Types de réplication .......................................................................................................... 83
4.8. Traitement et optimisation des requêtes ............................................................................. 83
4.8.1. Complexité et mesures ...................................................................................................... 83
4.8.2. Décomposition des requêtes et localisation des données ................................. 84
4.8.3. Optimisation des requêtes ................................................................................................ 85
4.9. Gestion des transactions distribuées ........................................................................................ 86
4.9.1. Propriétés ACID ....................................................................................................................... 86
4.9.2. Contrôle de concurrence ........................................................................................................ 86
4.9.2.1. Approche d’isolation multiversion ................................................................................... 87
4.9.2.2. Approche à verrouillage ................................................................................................... 87
4.10. En résumé ..................................................................................................................................... 88
4.11. Exercices ............................................................................................................................... 88
Exercice 1 : ......................................................................................................................................... 88
Exercice 2 : ......................................................................................................................................... 89
CHAPITRE 5
Data Warehouse
5.1. Motivation et objectifs des DWs ............................................................................................... 92
5.2. Définition d’un Data Warehouse ............................................................................................... 94
5.3. L’approche Data Warehouse ..................................................................................................... 94
5.4. Architecture des DWs ................................................................................................................ 97
5.4.1. Le niveau préparation des données .................................................................................. 98
a) Extraction........................................................................................................................... 98
b) Transformation .................................................................................................................. 98
c) Loading (chargement) ....................................................................................................... 98
5.4.2. Le niveau Data Warehouse................................................................................................ 98
5.4.3. Le niveau OLAP .................................................................................................................. 99
5.4.4. Le niveau frontal ................................................................................................................ 99
5.5. Data Warehouse vs Datamart ................................................................................................... 99
5.6. Modèle multidimensionnel ..................................................................................................... 100
5.6.1. Cubes ............................................................................................................................... 101
5.6.2. Dimensions ...................................................................................................................... 102
6
5.6.3. Faits .................................................................................................................................. 102

5.6.4. Mesures ........................................................................................................................... 103
5.6.5. Opérations OLAP.............................................................................................................. 103
5.7. ROLAP, MOLAP et HOLAP ........................................................................................................ 105
5.8. En résumé ................................................................................................................................ 105
5.9. Exercices .............................................................................................................................. 105
Exercice 1 :........................................................................................................................................... 105
Exercice 2 :........................................................................................................................................... 106
Exercice 3 :........................................................................................................................................... 106
Conclusion ........................................................................................................................................... 107
7
Introduction
Depuis le début de l’automatisation de la gestion d’organisation, l’évolution de
la notion de base de données (BD) a influencée considérablement de façon
directe dans la gestion de données et de façon indirecte dans la performance des
organisations et des entreprises en particulier.
Dans le présent support de cours nous traçons le parcours d’évolution de la

notion de BD depuis l’ère où les premiers essais de stockage et de partage de
données ont vu le jour, jusqu’à l’ère de l’exploitation des données dans des
processus d’analyse dans le but d’aide à la prise de décision ou la prédiction en
général dans une organisation.
Afin de suivre cette évolution de la notion de BD de manière pédagogique, nous

avons opté pour une démarche qui consiste en premier lieu à décrire le contexte
d’une organisation à travers la notion de Système d’Information (SI) dans le but
de montrer à quel endroit du SI, le stockage et le partage des données est
nécessaire et à quel endroit du SI, les données sont par la suite exploitées dans la
prédiction. La suite de la démarche consiste à discuter les différents modèles de
BDs qui ont été développés durant cette évolution.
Ce support de cours est organisé de la manière suivante :
Le chapitre 1 commence d’une part par définir la notion de SI et ses

composantes. Ensuite, nous détaillons les sous-systèmes constituant un SI où les
différents modèles de BDs peuvent être utilisés dans son développement. Ainsi,
les différents cycles de vie de développement d’un SI sont brièvement discutés.
De l’autre part, le chapitre définit la notion de BD et ses fonctions. Ensuite, la
notion de Système de Gestion des Bases de Données (SGBD) et le langage SQL
sont définis et La modélisation des SGBDs en niveaux d’abstraction proposée
par ANSI est détaillée. Le chapitre est finalisé par un historique résumant
l’évolution du développement des SGBDs.
10
Introduction Bases de données avancées
Le chapitre 2 lance la discussion sur les différents modèles de BD avec le

fameux modèle relationnel qui a dominé pendant longtemps le domaine des
BDs. Le chapitre est entamé par la description de la manière avec laquelle les
données sont décrites dans le modèle relationnel. Ensuite, le concept de
normalisation est discuté en focalisant sur les concepts : contraintes d’intégrité,
décomposition des relations et formes normales. Le chapitre comprend aussi des
définitions détaillées sur les deux modules du langage SQL à savoir le langage
de définition des données (DDL) et le langage de manipulation des données
(DML) appuyées par des exemples illustratifs.
Le chapitre 3 enchaîne avec le modèle des Bases de Données Objet (BDO) qui
a suivi deux chemins dans son développement dans la littérature. Le premier
concerne le modèle des Bases de Données Orientées Objet (BDOO) et le second
concerne le modèle des Bases de Données Relationnelles-Objet (BDRO). Après
la définition des principaux concepts de l’orienté objet (tels que l’objet,
l’encapsulation, …), les deux langages utilisés dans les BDOOs à savoir le
langage de définition objet (ODL) et le langage de requête objet (OQL) sont
définis avec des exemples illustratifs. Ensuite, une section est consacrée aux
BDROs où une discussion détaillée de l’adaptation du SQL pour intégrer les
concepts orientés objet est également donnée avec des exemples illustratifs.
Le chapitre 4 aborde le modèle des Bases de Données Distribuées (BDDs) en

définissant la notion de BDD ainsi que le Système de Gestion des Bases de
Données Distribuées (SGBDD). Après l’explication des principaux avantages de
l’utilisation des SGBDDs (tels que l’indépendance des données et la
transparence de la distribution et de la fragmentation), L’architectures des BDDs
est discutée. Ensuite, la conception des BDDs est détaillée en focalisant sur le
type de conception descendante alors qu’une brève définition est donnée pour le
type de conception ascendante puisqu’elle concerne le modèle Data Warehouse
abordé dans le chapitre 5. Dans la conception descendante, il est question de
définir la notion de fragmentation des données, y compris ses types (horizontale,
verticale et hybride), ainsi que la notion d’allocation des données. Finalement,
des concepts très importants pour les BDDs sont discutés en détail tels que la
réplication, l’optimisation des requêtes et la gestion des transactions distribuées.
Le chapitre 5 présente le modèle Data Warehouse (DW) en expliquant les

principaux objectifs des DWs. Nous expliquons par un exemple l’idée derrière
l’utilisation des DWs. Puis, une description détaillée d’une architecture typique
d’un DW est donnée. L’important concept du modèle multidimensionnel est
11
Introduction Bases de données avancées
abordé ainsi que les modèles basés sur ce dernier à savoir ROLAP, MOLAP et
HOLAP.
12
CHAPITRE 1
Système d’Information
Le traitement de l’information est un moyen de création de la valeur dans une

organisation ou en particulier dans une entreprise. Plus que ça, une bonne
exploitation de l’information et sa mise en disponibilité contribuent pleinement
dans l’atteinte des objectifs de l’entreprise. A partir des années 70, les systèmes
d’information ont pu rendre les bases de données en véritables gisements
d’informations. Les bases de données ont été utilisées à des fins décisionnelles à
partir des années 80 grâce aux travaux de Ralph Kimball. En 1990, le concept
d’entrepôt de données ou « Data Warehouses » a vu le jour grâce aux travaux de
William H. Inmon.
Dans ce chapitre nous présentons l’essentiel des concepts relatifs aux systèmes
d’informations (SIs) à savoir : la définition du SI, ses composantes ainsi que les
différents cycles de vie des SIs. Les notions de Base de Données (BD) et de
Système de Gestion des Bases de Données (SGBD) seront étudiées en
particulier.
1.1. Définition d’un SI

Le système d'information (SI) est un ensemble organisé de ressources qui permet
de collecter, stocker, traiter et distribuer de l'information (De Courcy 1992).
13
Chapitre 1 : Système d’information
Les ressources peuvent être humaines, matérielles, logicielles (i.e. programmes

et procédures de traitement), de données (i.e. bases de données) et de réseaux
(i.e. voies de communications).
Les fonctions d’un SI peuvent être détaillées comme suit :
Collecter : il s’agit d’acquérir les informations à partir de l’environnement

interne ou externe.
Stocker : il s’agit de conserver l’information acquise et de la rendre disponible.
Traiter : il s’agit de transformer l’information en modifiant le fond ou la forme

et la rendre adaptée au traitement.
Distribuer : il s’agit de diffuser l’information dans l’environnement interne ou

externe du système.
1.2. Composantes d’un SI

Comme illustré dans la figure 1, tout système d’information est constitué de
quatre types de composantes : les inputs, les traitements, les dépôts de données
et les outputs.
Figure 1 : Composantes d'un système d'information (Rivard 2001)
Des inputs (données) sont émis par une ou plusieurs sources et traités par le
système, lequel utilise aussi des données entreposées préalablement. Les
résultats du traitement (outputs) sont transmis à une ou plusieurs destinations ou
mettent à jour des données entreposées (Rivard 2001).
14
1.3.1. Sous-systèmes d’un SI

Dans toute organisation, le périmètre d’un système d’information couvre trois
sous-systèmes qui interagissent entre eux : le sous-système opérationnel, le sous-
système décisionnel et le sous-système d’information.
Le sous-système d’information se positionne au cœur de l’organisation en

assurant la communication des informations collectées et modifiées du système
opérationnel au système décisionnel qui se charge de contrôler et prendre des
décisions (Figure 2).
1.3.1. Sous-système opérationnel

Les systèmes opérationnels également appelés OLTP (On-Line Transactional
Processing) regroupe les tâches de base et répétitives (insertion, modification et
suppression) réalisées quotidiennement par les membres (ex. employés) de
l’organisation (ex. entreprise). Certaines entreprises, assurent la gestion de ses
métiers par des Progiciels de Gestion Intégrée (PGIs) ou Entreprise Ressource
Planning (ERPs) qui intègrent les données et les processus d’une entreprise
(finance, ressources humaines, ventes, stock,…) dans un même système. Les
ERPs utilisent une base de données unique qu’est accessible par tous les
modules du système.
1.3.2. Sous-système décisionnel

Les systèmes décisionnels également appelés OLAP (On-Line Analytical
Processing) se focalisent sur le management de l’organisation (ex. entreprise)
dans le sens d’aider les décideurs dans leur pilotage en leur offrant une vision
transversale sur l’organisation. Certaines entreprises mettent en place des
entrepôts de données (Data Warehouses) comme système décisionnel.
1.3.3. Sous-système d’information (ou de communication)

Ce système se charge de collecter, stocker, transformer et diffuser des
informations dans les sous-systèmes opérationnel et décisionnel. Il assure donc
l’échange d’informations avec les deux autres sous-systèmes.
15
Sous-système décisionnel
Communication Génération
Traitement
Mémorisation
Sous-système d’information
Communication
Sous-système opérationnel
Figure 2: Interaction entre les sous-systèmes d'une organisation
1.4. Processus de développement d’un système d’information
1.4.1. Cycle de développement

Un cycle de développement comprend généralement les phases suivantes :
- La définition des objectifs :

C’est à ce niveau, que la décision de fabriquer, de développer ou d’acheter un
nouveau produit (SI) est prise.
- Analyse des besoins et faisabilité :
La formalisation détaillée des besoins à satisfaire et les contraintes auxquelles le
produit doit obéir
- Planification et gestion des projets :
Planification des tâches du projet dans le temps ainsi qu’une estimation des
coûts.
- La conception globale :
La définition de l’architecture du logiciel ainsi que l’interface entre ses
différents modules.
- Codage et test unitaire :
Codage de chaque module du produit et son test indépendamment des autres
(test unitaire).
- Intégration :
Chaque module est intégré avec les autres modules du produit et testé.
16
- Qualification :
Le test du produit est réalisé en vrai grandeur dans les conditions normales
d’utilisation.
- Maintenance :
La maintenance accompagne le produit jusqu’à son retrait en exploitant la
documentation faite pendant les phases précédente.
1.4.2. Cycle de vie

Afin de maîtriser les risques, les délais, les coûts et offrir un produit de qualité
conforme aux besoins, un cycle de vie est établit en décrivant les phases allant
de la création à la disparition du produit y compris son distribution sur le
marché. Le cycle de développement s’insère donc dans le cycle de vie.
1.4.3. Les modèles de cycle de vie

On peut regrouper les modèles de cycle de vie en trois catégories : les modèles
linéaires, les modèles itératifs et les modèles agiles (Suki 2018).
1.4.3.1. Modèles linéaires

Parmi les modèles linéaires nous citons les suivants :
- Modèle en cascade : Introduit en 1970, ce modèle est le plus ancien.
Puisqu’il est séquentiel (Figure 3), on ne passe à une étape qu’après
l’achèvement de l’étape qui lui précède et les conséquences en amont du cycle
ont un impact important sur les coûts en aval (Royce 1970).
Figure 3 : Modèle en cascade
17
- Modèle en V : Comme dans le modèle en cascade, dans le modèle en V

qui a été introduit par Goldberg en 1986, tout changement opéré dans
une étape a un impact important sur les étapes suivantes (Figure 4).
Néanmoins, le modèle en V est une amélioration du modèle en cascade
dans le sens où il permet en cas d’anomalie de limiter un retour aux
étapes précédentes. La conformité du produit aux spécifications doit être
respectée dès les phases de conception (Firesmith 2013).
Figure 4 : Modèle en V
1.4.3.2. Modèles itératifs

Le modèle spirale et le modèle incrémental sont des exemples des modèles
itératifs
- Modèle spirale : Défini par Barry Boehm en 1988, le modèle spirale

reprend les étapes du modèle en V tout en mettent l’accent sur la gestion
des risques (Boehm 1988). Le modèle spirale peut être déroulé sur quatre
phases à savoir : (i) détermination des objectifs, des alternatives et des
contraintes, (ii) analyse des risques, (iii) développement et vérification
de la solution retenue, et (iv) revue des résultats et vérification du cycle
suivant (Figure5).
18
Figure 5 : Modèle spirale (Boehm 2000)
- Modèle incrémental :
Dans le modèle incrémental, les modules (fonctionnalités) du produit une fois
développés, sont greffés à un noyau du logiciel. Cette manière de faire du
modèle incrémental (Figure 6) est adaptée aux cas où les fonctionnalités ou la
plupart d’entre elles sont connues au début d’un projet de longue durée (Suki
2018).
Figure 6 : Modèle incrémental
1.4.3.3. Modèles agiles

En réalité, c’est des modèles basés sur les modèles itératifs mais ils se
démarquent par rapport à ces derniers par le fait qu’ils impliquent au maximum
19
le client où des versions fonctionnelles du produit sont régulièrement livrées et

des feedbacks sur ces versions sont recueillis du client jusqu’à ce que ce dernier
décide qu’il est satisfait de la version de test livrée. Ils sont donc gérés d’une
manière adaptative, incrémentale et itérative.
Nous citons parmi les modèles agiles les plus populaires : XP, Scrum et FDD.
- eXtreme Programming (XP) :

Ken Beck, de la société Chrysler, a conçu le modèle XP dans le but d’assurer la
collaboration étroite de tous les acteurs du projet en optant pour des itérations de
développement très courtes (Figure 7). Beck a défini quatre activités principales
pour XP: codage, test, écoute et conception (Beck 2001).
Figure 7 : La boucle de planification et de feedback dans XP
- Scrum:
Le mot Scrum est repris du monde du rugby qui veut dire que le projet peut
modifier sa direction au fur et à mesure de son avancement. Si le projet arrive à
un stade où sa réussite ne soit pas évidente. Il est alors permet de réorienter le
projet pour repartir sur de meilleurs bases. La méthode est bien adaptée au cas
où le client n’a pas encore défini toutes les fonctionnalités dont il a besoin.
Proposée en 1996 par Ken Scwaber,
Scrum n’a pas été défini par ce dernier comme une méthode au sens strict du
mot mais plutôt comme étant un cadre de travail fondée sur le changement, les
résultats, la transparence et la communication, le respect des utilisateurs et
l’esprit de l’équipe (Collignon 2016).
20
- Feature Driven Development (FDD) :

Introduit pour la première fois en 1999, FDD pour Développement Dirigée par
les Fonctionnalités est une méthode de gestion de projet basée sur les itérations
courtes autour de fonctionnalités (Coad 1999).
La FDD procède par les étapes suivantes : (i) la définition d’un modèle générale
du produit qui détermine le périmètre globale de la réalisation, (ii) détermination
de la liste complète des fonctionnalités à réaliser, (iii) conception technique des
fonctionnalités (iv) et réalisation.
1.5. Notion de base de données (BD)

Les systèmes de gestion des fichiers (SGF) ont montré leurs limites dans la
gestion des données notamment quand ces dernières deviennent gigantesques.
En effet, de telles représentations souffrent, d’un côté de la redondance des
données qui souvent devienne plus importante notamment lorsque les
applications ne sont pas réalisées dans le cadre d’une démarche globale de
développement. De l’autre côté, elles souffrent aussi de la forte dépendance des
programmes aux données dans le sens où la modification de l’organisation des
données mène d’office à la modification des programmes existants.
L’avènement du concept de base de données a été justement vu comme la

solution adéquate aux problèmes liés aux SGFs.
1.5.1. Définition d’une BD

Boudjlida définit une base de données comme une collection de données
opérationnelles, enregistrées (sur un support adressable) et utilisées par des
systèmes d’application (les programmes) d’une organisation (humaine)
particulière. En outre, la collection de données est structurée indépendamment
d’une application particulière, elle est cohérente, de redondance minimale et
accessible simultanément par plusieurs utilisateurs (Boudjlida 2002).
La structuration de données a pour principal objectif d’éliminer les redondances

de données dans la base. Alors que la mémorisation des informations permet
d’un côté d’assurer une indépendance entre les programmes et les données et de
l’autre côté elle permet d’intégrer toutes les données de l’entreprise dans un
même support.
1.5.2. Fonctions d’une base de données

Une base de données étant contenant des données structurées peut assurer les
fonctions fondamentales suivantes :
21
- Stocker l’information d’une manière permettant la restitution facile de

cette dernière.
- Traiter de grandes masses de données.
- Traiter les données de manière optimale en temps d’accès et espace de
stockage.
- Contrôler l’accès aux données.
- Partager des données par le fait que ces dernières sont séparées des
programmes.
1.6. Système de Gestion de base de données (SGBD)
1.6.1. Définition d’un SGBD

Un système de gestion de bases de données (SGBD) est un ensemble d’outils
logiciels permettant la création, la manipulation et le contrôle de bases de
données.
Il inclut donc : les données, le matériel, les applications et les utilisateurs (Date
2004).
Gardarin précise que le principal objectif d’un SGBD est d’assurer

l’indépendance des programmes aux données, c’est-à-dire la possibilité de
modifier les schémas conceptuel et interne des données sans modifier les
programmes d’applications, et donc les schémas externes vus par ces
programmes (Gardarin 1994).
Afin d’assurer ces fonctionnalités, un langage de base de données

« Structured Query Language » (SQL) est défini dans les SGBDs et qu’est
composé des sous-langages suivants :
- Un langage de Définition de Données (LDD) qui permet à l’utilisateur de

décrire des objets (étudiants, formation,…), leurs attributs (le nom des
étudiants, le libellé des formations,…), leurs liens (une personne est
inscrite à une formation) et des contraintes éventuelles sur ces objets.
- Un Langage de Manipulation de Données (LMD) qui offre à l’utilisateur
le moyen de rechercher, de créer, de modifier et de supprimer des
informations.
- Un Langage de Contrôle de Données (LCD) qui assure l’intégrité des
données ainsi que l’accès sécurisé à ces dernières.
22
1.6.2. Niveaux d’abstraction

Les SGBD assurent une abstraction des données sauvegardées sur les supports
physiques afin de simplifier la vision des utilisateurs. Cette abstraction a été
proposée par le groupe ANSI/X3/SPARC (ANSI 1978) qui consiste à modéliser
la description des données en trois niveaux d’abstraction : Conceptuel, Interne et
Externe (Figure 8).
Cette manière de conception en trois niveaux d’abstraction est derrière

l’importante caractéristique qui donne de la puissance au SGBD à savoir
l’indépendance des données en séparant les niveaux logiques (schémas
conceptuel et externe) du niveau interne (physique).
Schéma externe 1 … Schéma externe i … Schéma externe n
Schéma Conceptuel
Schéma interne
Disque
Figure 8: Niveaux d’abstraction d’un SGBD
1.6.2.1. Niveau conceptuel

A ce niveau, un schéma conceptuel décrit les données d’une entreprise ou d’une
partie d’une entreprise en terme de types indépendants de toute représentation en
machine, correspondant à une vue canonique globale de la portion d’entreprise
modélisée (Gardarin 1994).
Comme illustré dans la figure 9, le schéma conceptuel (ou logique)

permettra par exemple de définir:
- Les types de données élémentaires (ex. Nom, Prénom, Titre, …)
- Les types de données composées (ex. Etudiant, Formation,
Inscription)
23
Les règles que devront suivre les données au cours de leur vie (ex. tout étudiant
doit avoir une inscription, une durée de formation est 3 ans pour le niveau
Licence ou 2 ans pour le niveau Master)
Types= d’objets :
Etudiant(Nom, Prénom, Adresse)
Formation(Titre, Niveau, durée)
Type de relations :
Inscription(Etudiant, formation, Année)
Figure 9: Exemple de schéma conceptuel
1.6.2.2. Niveau interne

A ce niveau, un schéma interne décrit des données d’une base au niveau de la
représentation physique en machine correspondant à une spécification des
structures de stockage et des méthodes d’accès utilisées pour stocker les données
sur disque (Gardarin 1994).
Le schéma interne résume, donc, comment les données décrites dans le schéma
conceptuel sont enregistrées dans les équipements de stockage. Cela se fait en
déterminant les types de fichiers dans lesquels seront enregistrées les données et
en définissant des structures de données supplémentaires, appelées indexes, qui
aident à effectuer les opérations de recherche de données.
1.6.2.3. Niveau externe

A ce niveau, un schéma externe décrit une partie de la base de données
correspondant à la vision d’un programme ou d’un utilisateur, donc à un
arrangement particulier de certaines données (Gardarin 1994).
Le schéma externe permet, donc, de personnaliser l’accès des utilisateurs aux

données. Ainsi, contrairement aux schémas conceptuel et interne qui décrivent
toute une base de données, on peut avoir plusieurs schémas externes chacun
décrivant la partie des données présentant un intérêt pour un utilisateur ou un
groupe d’utilisateurs.
24
Etudiants
Etudiants Nom
Prénom
Nom
Adresse
Prénom
Adresse
Titre_de_formation
Formations_suivies
Niveau_de_formation Titre
Niveau_de_formation
Nombre_des_inscrits
Schéma externe 1
Schéma externe 2
Figure 10: Exemples de schémas externes
Un schéma externe est une collection de vues considérées conceptuellement

comme des relations, dont les enregistrements ne sont pas stockés mais plutôt
calculés à partir de relations définies dans le schéma conceptuel (Figure 10).
1.6.3. Historique des SGBDs

Depuis les premiers jours de l’informatique, le stockage et la manipulation des
données ont suscité beaucoup d’attention. Ramakrishnan et al, ont résumé
l’historique de l’évolution des SGBDs de la façon suivante (Ramakrishnan
2003):
- En 1960, Charles Bachman conçut le premier SGBD au sein de la firme

General Electric en USA, et le nomma Integrated Data Store.
- A la fin de l’année 1960, IBM développa « Information Management
System » (IMS). Presque au même moment, le système SABRE fut
développé conjointement par American Airlines et IBM pour faire les
réservations aériennes et il permettait à plusieurs utilisateurs d’accéder
aux mêmes données à l’aide d’un réseau.
- En 1970, Edgar Codd proposa au sein d’IBM une nouvelle
représentation des données appelée modèle relationnel de données
« Relational Data Model » (Codd 1970). L’avènement de ce modèle
constitua un tournant dans le développement des systèmes de bases de
données. En effet, ces systèmes devinrent une discipline académique et
25
l’utilisation des SGBDs pour la gestion des données dans les entreprises devint
une pratique standard.
- En 1980, le modèle relationnel des données consolida sa position
dominante de paradigme dans le domaine des systèmes de bases de
données par l’avènement du langage des requêtes SQL développé par
IBM.
- A la fin des années 1980 et 1990, des progrès ont été réalisés dans
différents domaines relatifs aux systèmes de bases de données
notamment, le perfectionnement d’un langage de requêtes plus puissant
et l’enrichissement des modèles de données. Plusieurs firmes ont pu
étendre leurs systèmes en les rendant capables de stocker de nouveaux
types de données (tels que les images et les textes) et d’interroger les
bases de données par des requêtes plus complexes. Ainsi, des systèmes
spécialisés ont été développés pour la création des entrepôts de données
(Data Warehouses) et l’intégration des données à partir de différentes
bases.
Une branche intéressante s’est développée par l’émergence de plusieurs
progiciels de gestion intégrée « Entreprise Resource Planning » (ERPs) qui
ajoutent principalement des couches de fonctionnalités au-dessus des SGBDs.
Après l’avènement de l’Internet, plusieurs SGBDs ont pu remplacer les
systèmes opérationnels dans le stockage des données utilisées par les sites
Internet.
1.6.4. Avantages des SGBDs

Beaucoup d’avantages ont été cités dans (Date 2004) (Ramakrishnan 2003)
(Gardarin 1994). Dans ce qui suit, nous donnerons un résumé sur chaque
avantage cité dans une des références mentionnées ci-dessus:
- Indépendance physique :
Les SGBDs fournissent une vue abstraite des données qui cachent les détails des
données aux applications. Grâce à cette propriété très importante, il est possible
de modifier le schéma interne sans avoir à modifier le schéma conceptuel
malgré que les schémas interne et conceptuel représentent les mêmes données.
- Indépendance logique :
L’indépendance logique permet de modifier un schéma externe sans avoir à
modifier le schéma conceptuel. Cela assure aussi une
26
indépendance entre les différents utilisateurs à travers leurs schémas externes

correspondant.
- Manipulation des données par des langages non procéduraux :
Les SGBDs sont dotés de langages non procéduraux tels que SQL qui
permettent aux utilisateurs (utilisateurs interactifs ou des programmes) de
manipuler les données sans préciser d’algorithmes d’accès.
- Accès plus efficace aux données :
Afin d’assurer aux utilisateurs un accès efficace et rapide aux données, les
SGBDs fournissent des techniques sophistiquées telles que l’utilisation des
mémoires caches pour que les accès aux données se fassent en mémoire du fait
que les Entrées/Sorties disques représentent un goulot d’étranglement.
- Intégrité et sécurité des données :
Afin d’assurer l’intégrité des données, les SGBDs appliquent des contraintes
lors des mises à jour effectuées sur les données. Par exemple, lors d’une
inscription d’un étudiant dans une formation, le SGBD peut contrôler si
l’étudiant n’est pas déjà inscrit.
La protection des données est aussi assurée par les SGBDs en appliquant des
mécanismes adéquats pour autoriser, contrôler ou enlever des droits d’accès des
utilisateurs à tout ensemble de données.
- Administration centrale des données :
La centralisation de l’administration des données dans les SGBDs a pour but de
minimiser les redondances et adapter le stockage de données dans le sens
d’obtenir une recherche de données efficace.
- Accès simultané et récupération après incident :
Dans les SGBDs, les utilisateurs jouissent d’un accès simultané aux données de
telle manière qu’ils pensent que les données sont accédées par un seul utilisateur
à la fois. En plus, les données sont protégées lors d’une panne de système.
- Réduction de temps dans le développement d’application :
Le développement des applications est plus facile et rapide avec les SGBDs de
fait que ces derniers intègrent beaucoup de fonctions communes aux
applications en plus d’une interface de haut niveau avec les données.
27
1.7. En résumé
Dans ce chapitre, nous avons donné la définition d’un système d’information et
sa composition. Ensuite, nous avons défini les sous-systèmes qui existent dans
toute organisation ainsi que l’interaction qui les relie.
Le développement de pareils systèmes n’étant pas toujours évident, nous avons

dressé brièvement quelques cycles de vie qui ont été défini dans le domaine de
gestion des projets.
Finalement, nous avons terminé par discuter en particulier les concepts de base
de données et des systèmes de gestion de bases de données.
1.8. Exercices
Exercice 1 :
Déterminer, pour chaque traitement ci-dessous, s’il prépare spécifiquement une
prise de décision en précisant, le cas échéant, des décisions qui peuvent en
découler.
a) Préparation d’un bon de livraison.
b) Analyse des ventes saisonnières.
c) Étude de devis pour la rénovation d’un entrepôt.
d) Préparation du bilan comptable annuel.
e) Simulation des effets d’une augmentation des salaires.
Exercice 2 :
Tout système d’information est scindé en trois niveaux : sous-système
opérationnel, sous-système de communication et sous-système décisionnel.
Donner des exemples du rôle du système à chaque niveau.
28
29
30
Base de données avancées
CHAPITRE 2
Bases de données relationnelles
Historiquement, durant trois générations d’évolution des bases de données

à savoir : (i) fichiers systèmes, (ii) bases de données hiérarchiques, (iii) bases de
données CODASYL, le développement de ces modèles a connue des
insuffisances qui persistaient. Effectivement, le manque d’indépendance des
données et la difficulté d’accès à la base de données ont justement donné
naissance à la quatrième génération des bases de données à savoir la technologie
des Bases de Données Relationnelles (BDRs) ou Relationnel Databases
caractérisées principalement par la notion de requête déclarative (Kim 1990).
Dans ce chapitre, nous allons définir les principaux concepts sur lesquels sont
basées les BDRs à savoir la description des données, la normalisation par
décomposition ainsi que le langage SQL.
2.1. Modèle relationnel : description des données

La structuration des données dans le modèle relationnel repose sur deux
principaux concepts : le domaine et la relation (Hainaut 2012).
Un domaine est un ensemble nommé de valeurs donné a priori. Chaque valeur

est supposée désigner un objet concret ou abstrait du monde réel.
Une relation contienne des informations sur les objets et les liens. La relation
peut être définit comme un ensemble d’agrégats de n valeurs, chacune
31
Chapitre 2 : Base de données relationnelles
appartenant à un domaine. Un agrégat est appelé ligne et les composants de

même rang des lignes forment un attribut de la relation.
Théoriquement une relation est définie comme une partie du produit cartésien
d’une suite de domaines. Soient D1, D2, …, Dn des domaines non
nécessairement distincts. Une relation R(A1 :D1, A2 :D2, …, An :Dn) ou R(A1,
A2, …, An) est définie comme :
R D1 x D2 x … x Dn
Finalement, la description des données en terme de modèle est appelée un

schéma qui spécifie pour chaque relation son nom, le nom de chaque attribut
(champ ou colonne) et son type.
2.2. Normalisation par décomposition

La redondance d’informations dans une base de données cause énormément de
problèmes dans la conception des bases de données tels que la redondance de
stockage, les anomalies de mise à jour, les anomalies d’insertion et de
suppression.
Le concept de normalisation a été justement défini comme une solution à ce

phénomène dans le sens où elle permet de réaliser un raffinement de la base de
données.
Plusieurs procédés de normalisation ont été adoptés pour pallier aux problèmes
liés à la redondance d’informations à savoir la normalisation par décomposition,
par synthèse, par dépendances multivaluées et par dépendances de jointure.
Dans ce manuscrit, nous ne pouvons nous permettre de détailler tous les types de
normalisations que le lecteur peut les trouver en détails dans la littérature
(Ramakrishnan 2003) (Boudjlida 2002) (Hainaut 2012). Néanmoins, nous
expliquerons le premier type de normalisation proposé par Codd (1970) à savoir,
la normalisation par décomposition. Les autres procédés sont aussi bons et
peuvent parfois révéler des redondances qui ne peuvent être détectées par la
normalisation par décomposition (Ramakrishnan 2003).
2.2.1. Contraintes d’intégrité

Le raffinement de la base de données qui vise à éliminer au maximum la
redondance de données doit être guidé par le strict respect des contraintes
32
d’intégrité. Dans ce sens, nous nous focalisons sur deux concepts importants: il
s’agit de la clé de relation (ou l’identifiant) et la dépendance fonctionnelle.
Justement, la notion de normalisation par décomposition se base principalement

sur les rapports qui existent entre ces deux concepts.
2.2.1.1. Définition de la clé de relation

La clé de relation est définie comme un ensemble d’attributs dont les valeurs
permettent de distinguer les n-uplets de la relation.
Toutefois, une relation peut avoir plusieurs clés. Nous en choisirons une qui sera
alors appelée clé primaire et les autres seront appelées clés candidats
Exemples : On indique une clé de relation en soulignant ses composants.
VENTE(ARTICLE, MAGASIN, PRIX) : Un article n’est vendu que dans
un seul magasin et à prix fixe.
VENTE(ARTICLE, MAGASIN, PRIX) : Un article peut être vendu par
plusieurs magasins, son prix dépend du magasin qui le vend.
VENTE(ARTICLE, MAGASIN, PRIX) : Un magasin peut vendre un même
article à différents prix.
2.2.1.2. Définition de la dépendance fonctionnelle

Dans une relation R(A, B, C, D), il existe une dépendance fonctionnelle AB
si, à tout instant, deux lignes de R qui ont même valeur de A ont aussi même
valeur de B.
ACHAT
CLIENT PRODUIT PRIX
Mohamed Café 700
Manga Café 700
Manga Vinaigre 30
Momo Lit 25
Momo Vinaigre 30
Tableau 1: Dépendance fonctionnelle dans une relation
33
Le Tableau 1 montre que quelles que soient les valeurs des attributs de la
relation ACHAT, le PRIX ne dépond que du PRODUIT. On dit qu’il existe une
dépendance fonctionnelle (DF) de PRODUIT vers PRIX, ce qu’on notera :
PRODUIT PRIX
On dira que :
PRODUIT est le déterminant et PRIX est le déterminé de la dépendance
fonctionnelle
2.2.2. La décomposition d’une relation

Selon Delobel et al, une la relation R(A, B, C, D), qui a une dépendance
fonctionnelle AB peut être décomposée en deux relations R1(A, B) et R2(A,
C, D) (Delobel 1973).
Pour l’exemple de la relation ACHAT, la décomposition sera comme suit :
ACHAT(CLIENT, PRODUIT, PRIX), PRODUITPRIX peut être décomposée
en deux relations TARIF(PRODUIT, PRIX) et ACHAT(CLIENT, PRODUIT)
2.2.3. Formes normales

La dépendance fonctionnelle est à la base des trois premières formes normales et
celle de Boyce and Codd (Figure 11).
Figure 11: Les formes normales (Meier 2006)
34
2.2.3.1. Première forme normale

Une relation est dite en première forme normale (1NF), si chacun de ses
attributs a un domaine atomique mono-valué.
C’est-à-dire, les relations avec attributs dont les valeurs sont des ensembles ou
des listes ne sont pas en 1NF. Toutefois, on signale ici que les travaux menus
dans le cadre des modèles orientés objet et des modèles relationnels-objet visent
justement à surpasser cette contrainte de 1NF.
2.2.3.2. Deuxième forme normale

Une relation R est en deuxième forme normale (2NF) si et seulement si (i) elle
est en 1NF et que (ii) tout attribut n’appartenant pas à une clé ne dépend pas
d’une partie de la clé de R.
Exemple : la relation EVALUATION (MODULE, FORMATION, LIBELLE,

NOTE) où la dépendance FORMATION LIBELLE n’est pas en 2NF car
l’attribut LIBELLE ne dépend que de la partie FORMATION de la clé
MODULE, FORMATION.
2.2.3.3. Troisième forme normale

Une relation est en troisième forme normale (3NF) si (i) elle est en 2NF et si (ii)
tout attribut n’appartenant pas à la clé ne dépend pas d’un attribut non clé (ou
encore ne dépend pas transitivement de la clé).
Exemple : La relation AVION(NO_AVION, CONSTRUCTEUR, TYPE,

CAPACITE, PROPRIETAIRE) du Tableau 2 n’est pas en 3NF puisque les
attributs CONSTRUCTEUR et CAPACITE n’appartiennent pas à la clé et
dépendent de l’attribut non clé TYPE. Par contre les relations
AVION1(NO_AVION, TYPE, PROPRIETAIRE) et MODELE(TYPE,
CONSTRUCTEUR, CAPACITE) obtenues par décomposition sont en 3NF.
AVION
NO_AVION CONSTRUCTEUR TYPE CAPACITE PROPRIETAIRE
AH321 Boeing B747 C1 Air Algérie
AF564 Airbus A320 C2 Air France
BA777 Boeing B747 C1 British Airways
Tableau 2: La relation avion (Boudjlida 2002)
35
2.2.3.4. Forme normale de Boyce and Codd

Une relation R est en forme normale de Boyce and Codd (BCNF) si et seulement
si les seules dépendances fonctionnelles élémentaires qu’elle comporte sont
celles où une clé détermine un attribut.
Exemple (Figure 12): Malgré que la relation LIVRE(TITRE,

PREMIER_AUTEUR, NATIONALITE_AUTEUR, PAGES,
ANNEE_EDITION, NUM_EDITION) avec les dépendances fonctionnelles
TITRE PREMIER_AUTEUR et TITRE PREMIER_AUTEUR,
NATIONALITE_AUTEUR est en 3NF mais les redondances ne sont pas toutes
éliminées. La forme normale de Boyce and Codd permet d’éliminer ce type de
redondance.
LIVRE
Titre Premier Nationalite Pages Annee Num
Auteur Auteur Edition Edition
Database Management Raghu Américaine 1065 2003 3
Systems. Ramakrishnan
Bases de données et Nacer Boudjlida Française 279 2002 1
systèmes d’information, le
modèle relationnel :
langages, systèmes et
méthodes.
Bases de données : Jean-Luc Belge 702 2012 2
Concepts, utilisation et Hainaut
développement.
Le data Warehouse: Guide Ralph Kimball Américaine 575 2005 1
de conduite de projet.
The Data Warehouse Ralph Kimball Américaine 564 2013 3
Toolkit: The Definitive
Guide to Dimensional
Modeling.
Livre Auteurs
Titre Premier Pages Annee Num Premier Nationalite
Auteur Edition Edition Auteur Auteur
Database Management Systems Raghu 1065 2003 3 Raghu Américaine
Ramakrishnan Ramakrishnan
Bases de données et systèmes Nacer 279 2002 1 Nacer Française
d’information, le modèle Boudjlida Boudjlida
relationnel : langages, systèmes Jean-Luc Belge
et méthodes Hainaut
Bases de données : Concepts, Jean-Luc 702 2012 2 Ralph Kimball Américaine
utilisation et développement Hainaut
Le data Warehouse: Guide de Ralph 575 2005 1
conduite de projet. Kimball
The Data Warehouse Toolkit: Ralph 564 2013 3
TheDefinitive Guideto Kimball
Dimensional Modeling.
Figure 12: La relation LIVRE
36
Les relations LIVRE(TITRE, PREMIER_AUTEUR, PAGES,

ANNEE_EDITION, NUM_EDITION) et AUTEURS(PREMIER_AUTEUR,
NATIONALITE_AUTEUR) obtenues de la décomposition de la relation LIVRE
sont en BCNF tout en constatant que la dépendance TITRE
PREMIER_AUTEUR, NATIONALITE_AUTEUR a disparu.
2.3. Langage de requêtes SQL

Dans ce qui suit nous présentons les deux sous-langages du SQL (Structured
Query Langage) à savoir : Data Definition Langage (DLL) et Data Manipulation
Langage (DML) en utilisant la norme SQL2 du langage largement disponibles
dans les SGBDs (Hainaut 2012).
2.3.1. Data Definition Langage (DLL)

Dans cette section nous décrivons les principales commandes de définition et de
manipulation des structures : créer, supprimer et modifier une table, un domaine
ou une contrainte.
2.3.1.1. Création d’un schéma

Une base de données est définie par son schéma.
create schema ETUDEVAL

Les schémas sont rassemblés dans un catalogue qui représente un ensemble de
base de données. Un site peut contenir plusieurs catalogues.
2.3.1.2. Création d’une table

Par la requête create table on spécifie le nom de la table et la description
de ses colonnes (nom de la colonne et le type de ses valeurs).
create table ETUDIANT ( NETUD char(10),
NOM, PRENOM char(40),
GENRE char(1),
DATE_NAISS DATE,
LIEU_NAISS char(30),
ADRESSE char(80)) ;
create table MODULE ( CODE_MOD char(10),
LIBELLE_MOD char(60)) ;
SQL propose des types de base dans la déclaration de colonne. On citera les
principaux :
37
SMALLINT : entier signé long (par ex. 16 bits),

INTEGER ou (INT) : entier signé long (par ex. 32 bits),
NUMERIC(p, q) : nombre décimal de p chiffres dont q après le point décimal
(q prend par défaut la valeur de 0),
FLOAT(p) ou (FLOAT) : nombre en virgule flottante d’au moins p bits
significatifs,
CHARACTER(p) ou (CHAR) : chaîne de longueur fixe de p caractères,
CHARACTER VARYING ou (VARCHAR(p)) : chaîne de longueur variable d’au plus
p caractères,
BIT(p) : chaîne de longueur fixe de p bits,
BIT VARYING: chaîne de longueur variable d’au plus p bits,
DATE: date (année, mois de et jour),
e
TIME: instant (heure, minute, seconde, éventuellement 1000 de seconde),
TIMESTAMP: date + temps,
INTERVAL: intervalle en années/mois/jours entre dates ou en
heures/minutes/secondes entre instants,
Il est possible de déclarer des domaines de valeurs pour les types de base
comme suit :
create domain NOTE decimal(2,2)
create domain MATRICULE char(10)
create domain LIBELLE char(60)
create table ETUDIANT (NETUD MATRICULE,
NOM, PRENOM LIBELLE,
GENRE char(1),
DATE_NAISS DATE,
ADRESSE char(80)) ;
create table MODULE ( CODE_MOD MATRICULE,

LIBELLE_MOD LIBELLE) ;
38
2.3.1.3. Les clés de relation

Elle peut être primaire :
create table ETUDIANT (NETUD MATRICULE,
NOM, PRENOM LIBELLE,
GENRE char(1),
DATE_NAISS DATE,
ADRESSE char(80)
primary key (NETUD)) ;
Comme elle peut être secondaire en utilisant le prédicat unique:
create table HEBERGEMENT ( NUM_HEBERG MATRICULE,
NETUD MATRICULE,
NUM_CHAMBRE char(5),
primary key (NUM_HEBERG),
unique (NETUD)) ;
Comme elle peut être étrangère en référençant la table par la clause
foreign key:
create table EVALUATION( NETUD MATRICULE,
CODE_MOD MATRICULE,
NOTE_EXAM,
NOTE_TD,
NOTE_TP NOTE,
DATE_EXAM DATE,
primary key (NETUD,CODE_MOD), foreign key (NETUD) reference
ETUDIANT, foreign key (CODE_MOD) reference MODULE) ;
2.3.1.4. Opérations sur les tables

Une table peut être supprimée et son contenu sera perdu.
drop table EVALUATION
La commande suivante ajoute la colonne NATIONALITE à la table

ETUDIANT :
alter table ETUDIANT add column NATIONALITE char(30);
La commande suivante élimine la colonne DATE_EXAM de la table

EVALUATION :
39
alter table EVALUATION drop column DATE_EXAM;
Une caractéristique d’une colonne peut être modifiée :
alter table ETUDIANT alter column GENRE set default ‘M’;
alter table ETUDIANT alter column GENRE drop default;
Un domaine peut être modifié ou supprimé :
alter domain NOTE set default 0.0;
drop domain MATRICULE ;
Il est possible d’ajouter une clé primaire :
alter table ETUDIANT add primary key (NETUD);
ou étrangère:
alter table EVALUATION add foreign key (NETUD) references ETUDIANT;
Lors de la déclaration d’une contrainte, Il est possible de la nommée:
create table EVALUATION ( NETUD MATRICULE,

CODE_MOD MATRICULE,
NOTE_EXAM
NOTE_TD,
NOTE_TP NOTE,
DATE_EXAM DATE,
constraint CT1 primary key (NETUD,CODE_MOD),
constraint CT2 foreign key (CODE_MOD) reference MODULE) ;
Il est possible d’ajouter une contrainte à une table existante
alter table EVALUATION add constraint CT3 foreign key (NETUD)

references ETUDIENT;
Il est aussi possible de supprimer une contrainte nommée existante:
alter table EVALUATION drop constraint CT3;
40
2.3.2. Data Manipulation Langage (DML)

Dans cette section nous examinons les principes de l’extraction et de la
modification de données d’une table.
L’extraction est réalisée par une seule commande : la requête select qui contient
trois parties principales.
- La clause select précise les colonnes à extraire

- La clause from précise la ou les table(s) à partir desquelles les
données seront extraites
- La clause where précise les conditions à respecter lors de la
sélection des lignes.
2.3.2.1. Requêtes simples

Afficher toutes les colonnes de la table ETUDIANT
select * from ETUDIANT;
Afficher certaines colonnes NETUD, NOM, PRENOM de la table ETUDIANT

select NETUD, NOM, PRENOM from ETUDIANT;
Afficher certaines lignes sélectionnées de la table ETUDIANT
select NETUD, NOM, PRENOM from ETUDIANT where LIEU_NAISS =

‘Tiaret’;
Pour éliminer les lignes en double, on peut utiliser la clause distinct

comme suit :
select distinct LIEU_NAISS from ETUDIANT where DATE_NAISS =

‘21/12/1971’;
Au lieu de l’égalité, on peut utiliser d’autres relations de comparaison (>, <,

<>, >=, <=) qui correspondent respectivement à (plus grand que, plus petit que,
différent de, plus grand que ou égal, plus petit que ou égal).
Une condition peut porter sur l’existence de la valeur NULL :
DATE_NAISS is null
DATE_NAISS is not null
Une condition peut également porter sur l’appartenance à un ensemble :
41
GENRE in (‘F’, ‘M’) ou GENRE not in (‘F’, ‘M’)
Ou à un intervalle:
NOTE_EXAM between 0.0 and 20.00
NOTE_EXAM not between 0.0 and 9.99
Ou encore sur la présence de certains caractères dans une valeur

PRENOM like ‘M_STAPHA’
ADRESSE like ‘%Tiaret%’ ou ADRESSE not like ‘%Tiaret%’
DATE_NAISS like ‘%1971%’
Le signe “_” désigne un caractère quelconque et “%” désigne toute suite de
caractères.
Pour utiliser les deux signes ensemble dans une même recherche, il suffit de les
préfixer par un caractère spécial comme suit :
ADRESSE like ‘%$_chaine%’
Les conditions peuvent êtres composées :
select NOM, NOTE_EXAM from EVALUATION where NOM =’M%’ and

NOTE_EXAM>=10 ;
2.3.2.2. Données dérivées
En plus des données extraites de la base de données, il est possible de spécifier
des données dérivées, des constantes et des alias de colonnes:
select ‘TVA de’, NPROD as Produit, ‘=’, 0,17*PRIX*QSTOCK;
select ‘Moyenne de’, NETUD as ETUDIANT, ‘=’,

0.6*NOTE_EXAM+0.2*NOTE_TD+0.2*NOTE_TP as moy;
from EVALUATION
where moy>=10.00
Cette requête affiche le tableau suivant :
Moyenne de NETUD = Moy
Moyenne de 3827 = 16.5
Moyenne de 5827 = 11.05
Moyenne de 9827 = 13.75
Moyenne de 21827 = 10.00
42
Encore, il est avec la possible de dériver des données en utilisant des fonctions
clause select insert. ou la clause where et aussi avec les instructions update et
char_length(ch) : donne le nombre de caractrères de la chaîne ch,
position(ch1 in ch2) : donne la position de la chaîne ch1 dans la chaîne ch2, 1 si
ch1 est vide et 0 si ch1 n’apparaît pas dans ch2 ;
ch1 || ch2 : concatène les deux chaînes ch1 et ch2 ;
lower(ch) : transforme les caractères de ch en minuscules;
upper(ch) : transforme les caractères de ch en majuscules;
substring(ch from I for L) : donne une chaîne formée de L caractères de la chaîne
ch partant de la position I ;
trim(e c from ch) : supprime les caractères c à l’extrémité e de la chaîne ch ; les
valeurs de e sont leading, trailing et both
Il est aussi possible d’utiliser une fonction de sélection comme suit :
select NOM, PRENOM,
case GENRE
when ‘M’ then ‘Masculin’
when ‘F’ then ‘Féminin’
else ‘inconnu’
end, ADRESSE
from ETUDIANT;
A chaque fois que GENRE retourne ‘M’ ou ‘F’, il est affiché respectivement
‘Masculin’ ou ‘Féminin’.
Des valeurs d’environnement de l’utilisateur peuvent êtres fournit :
current_user : l’identificateur de l’utilisateur courant,
current_date : la date courante,
current_time : l’instant courant,
current_timestamp : date+instant courant,
2.3.2.3. Fonctions statistiques

count(*) : retourne le nombre de lignes trouvées,
43
count(nom-colonne) : retourne le nombre de valeurs de la colonne,

avg(nom-colonne) : retourne la moyenne des valeurs de la colonne,
sum(nom-colonne) : retourne la somme des valeurs de la colonne,
min(nom-colonne) : retourne la minimum des valeurs de la colonne,
max(nom-colonne) : retourne la maximum des valeurs de la colonne.
2.3.2.4. Condition par sous requêtes

La requête suivante donne les étudiants qui ont passé les examens des modules
dont leurs libellés comportent la chaine de caractère ‘Algo’.
select *
from ETUDIANT
where NETUD in
(select NETUD
from EVALUATION
where (DATE_EXAM is not null) and
(CODE_MODULE in
(select CODE_MOD
from MODULE
where LIBELLE_MOD = ‘Algo%’)));
Dans la requête suivante on utilise des sous requêtes corrélées pour sélectionner
les étudiants dont leur note d’examen est supérieure à la moyenne des notes
d’examens du même module.
select NETUD
from EVALUATION A
where NOTE_EXAM > (select avg(NOTE_EXAM)
from EVALUATION
where CODE_MOD = A.CODE_MOD);
La requête suivante montre comment utiliser une condition d’association
quantifiée pour rechercher les étudiants qui ont passé au moins deux examens.
select NETUD, NOM, PRENOM
from ETUDIANT A
where (select count(*)
from EVALUATION
where NETUD = A.NETUD) >=2);
44
2.3.2.5. Extraction de données de plusieurs tables

La requête suivante réalise une jointure entre les tables ETUDIANT et
EVALUATION où les lignes obtenues sont formées d’une ligne de chacune des
deux tables. Les lignes couplées ont la même valeur de la colonne NETUD qui
constitue une clé étrangère dans la table EVALUATION et primaire dans la table
ETUDIANT.
select EVALUATION.NETUD, EVALUATION.DATE_EXAM,
ETUDIANT.NETUD, ETUDIANT.NOM, ETUDIANT.ADRESSE from
EVALUATION, ETUDIANT
where EVALUATION.NETUD = ETUDIANT.NETUD
On peut fusionner les lignes obtenues d’une requête à celles obtenues d’une
autre requête en utilisant l’opérateur union comme suit :
select ADRESSE from ETUDIANT where LIEU_NAISS <> ‘Tiaret’

union
select ADRESSE from ETUDIANT where GENRE=’F’
Cependant, l’utilisation de l’opérateur union all empêche l’élimination des
lignes en double.
2.3.2.6. Extraction de données groupées
Par exemple, on peut obtenir le nombre d’étudiants pour chaque groupe
d’étudiants classés en utilisant la clause group by pour une colonne donnée
comme suit :
select NOM, PRENOM, count(*) as NOMBRE_ETUDIANTS
from ETUDIANT
group by GENRE
Pour imposer des conditions sur les groupes, la clause having est dédiée à de
telles situations afin d’éviter toute confusion avec la clause where qui porte
uniquement sur les lignes. La requête suivante donne les étudiants qui ont
obtenu une note d’examen inférieure à 10.00 au moins une fois :
select NETUD, count(*)
from ETUDIANT
where NETUD in(select NETUD
from EVALUATION
where NOTE_EXAM < 10.00)
group by NETUD
having count(*) >= 1;
45
La requête suivante montre comment combiner la jointure et le groupement

pour, par exemple, obtenir pour chaque étudiant le nombre d’examens auxquels
a assisté.
select A.NETUD, A.NOM, A.GENRE, count(*) as nombre_examens from

ETUDIANT A, EVALUATION B
where A.NETUD = B.NETUD and B.NOTE_EXAM is not null
group by A.NETUD, A.NOM, A.GENRE;
On signale l’utilisation de NOM et GENRE au niveau de la clause group pour
permette leur présence au niveau de la clause select et non pour le groupement
lui-même. En d’autres termes, on pourrait ignorer la mention de NOM et GENRE
au niveau de la clause group si on n’a pas besoin d’afficher le NOM au niveau de
la clause select.
On peut aussi grouper par des expressions de calcul comme la requête suivante
qui constitue des groupes d’étudiants selon la première lettre de leur nom.
select substring(NOM from 1 for 1) as NOM, count(*) as N from

ETUDIANT
group by substring(NOM from 1 for 1);
Les données sélectionnées dans une requête peuvent être classées par ordre
croissant ou décroissant sur une colonne ou plusieurs en utilisant la clause order
by avec la mention asc ou desc pour spécifié respectivement un ordre ascendant
ou descendant.
Par exemple, la requête suivante classe les lignes par NOM en ordre décroissant
puis dans chaque NOM elle les classe par PRENOM en ordre décroissant.
select *
from ETUDIANT
order by NOM, PRENOM desc;
Il est à noter que la clause order by n’admet pas l’utilisation d’un alias de
colonne, par contre on peut utiliser l’ordre de la colonne : order by 2 desc.
2.3.2.7. Modification des données
On peut ajouter des lignes à une table existante par l’instruction insert.
L’ordre des valeurs doit respecter l’ordre des colonnes lors de leurs créations.
Toute colonne non spécifiée prend la valeur null ou la valeur par défaut.
46
Insert into EVALUATION values (‘1201’, ‘Algo1’, 14.5, 16.00, 15.00,

‘21/12/2019’);
On peut ajouter à la table ETUDIANT_MASCULIN(NUMERO, NOM,
ADRESSE) des données extraites d’une ou plusieurs tables comme illustré dans
la requête suivante :
insert into ETUDIANT_MASCULIN
select NETUD, NOM, ADRESSE
from ETUDIANT
where GENRE = ‘M’;
On peut supprimer des lignes d’une table désignées par la clause where comme
suit :
delete from ETUDIANT
where NETUDIANT = ‘1201’;
La requête suivante supprime de la table ETUDIANT les lignes qui spécifient
un étudiant qui n’a passé aucun examen :
delete from ETUDIANT
where NETUD not in (select NETUD
from EVALUATION);
De la même façon, des modifications peuvent être effectuées sur les lignes d’une
table spécifiées dans la clause where comme suit :
update ETUDIANT
set ADRESSE = ‘Rue el Amir Abdelkader, Tiaret’
where NETUD = ‘1201’;
2.3.2.8. Mise à jour et contraintes référentielles
Tous les SGBDs garantissent l’intégrité des données en respectant les
contraintes d’intégrité au moment des mises à jour effectuées par les utilisateurs.
La définition de la structure de la table EVALUATION dans les requêtes
suivante comporte la mention on delete no action pour refuser la suppression
d’une ligne de la table ETUDIANT s’il existe une ou plusieurs lignes de
EVALUATION dépendantes (c’est-à-dire dont EVALUATION.NETUD =
ETUDIANT.NETUD).
create table ETUDIANT( NETUD MATRICULE not null, primary

key (NETUD) ) ;
create table EVALUATION ( CODE_MOD MATRICULE not null,
NETUD MATRICULE not null,
47
primary key (CODE_MOD),

foreign key (NETUD) references ETUDIANT on delete no action) ;
Par contre, avec la mention on delete cascade et on delete set null la
suppression est acceptée, mais la première (cascade) entraîne la suppression
conjointe des lignes de EVALUATION dépendantes et la deuxième (set null)
attribue la valeur null à la colonne NETUD des lignes dépendantes et rend ces
dernières indépendantes.
Les mêmes actions sont préconisées pour la modification de la valeur de
l’identifiant NETUD de ETUDIANT avec la mention on update. Refus s’il
existe des lignes de EVALUATION dépendantes (no action). Propagation par
modification des clés étrangères pour les évaluations dépendantes (cascade) et
mise à null des clés étrangères (set null).
2.4. En résumé
Les BDRs sont connues principalement par l’indépendance des données et la
facilité d’accéder à ces données ainsi que l’utilisation d’un langage déclaratif
facilitant leur manipulation. Dans ce chapitre, les principaux concepts ont été
discutés tels que la structuration des données en se basant sur la notion du
domaine ainsi que la notion de relation. Un autre concept très important a été
abordé en détail, est celui de la normalisation des données par décomposition.
Cette dernière est basée sur les notions de contraintes d’intégrité, décomposition
des relations et formes normales. Le célèbre langage déclaratif SQL a été décrit
en expliquant, par des exemples de requêtes, ses deux modules à savoir le
langage de définition des données (DLL) et le langage de manipulation des
données (DML).
2.5. Exercices
Exercice1 :
Décomposer la relation suivante :
EVALUATION (NETUD, CODE_MOD, LIBELLE_MOD, NOTE_EXAM)
NETUD CODE_MOD, NOTE_EXAM
CODE_MOD LIBELLE_MOD
48
Exercice2 :
Décomposer la relation suivante :
ENSEIGNE (NENSEIGNANT, NOM, PRENOM, SALLE, HEURE,
CODE_MOD, LIBELLE_MOD, CODE_FORMATION,
LIBELLE_FORMATION)
NENSEIGNANT  CODE_MOD, CODE_FORMATION, SALLE, HEURE
NENSEIGNANT NOM, PRENOM
CODE_MOD LIBELLE_MOD
CODE_FORMATION LIBELLE_FORMATION
Exercice 3 :
Soit les relations suivantes:
EMPLOYE(NEMP, NOM, AGE, SALAIRE)
AFFECTATION(NEMP, NSERV)
SERVICE(NSERV, LIBELLE_SERVICE, NCHEF_SERVICE)
a) Donnez les requêtes SQL nécessaires à la création des tables

correspondantes aux relations précédentes incluant les contraintes
d’intégrité sur les clés primaires et étrangères.
b) Définissez la relation SERVICE en SQL de manière à garantir un chef

de service pour chaque service.
c) Ecrivez la requête SQL qui ajoute l’employé MANGA

avec NEMP = 71, AGE = 29 et SALAIRE= 30000.
d) Ecrivez la requête qui ajoute à tous les employés une augmentation de

salaire de 10%.
Exercice4 :
Soit les informations suivantes relatives à une base de données pour gérer des
équipes de Football participant à une compétition :
- Chaque équipe a un identificateur, un nom, 22 joueurs, un entraineur,

une couleur.
- Chaque joueur a un identificateur, un nom et un prénom, un poste, une
date de naissance.
49
- Dans la compétition, il y a 16 équipes qui sont divisées en quatre

ème
groupes pour jouer un 16 de final dont les deux premiers du
ème
classement de chaque groupe joueront un 8 de final. les gagnants
ème
du 8 final joueront en quart de final. les gagnants de ce dernier
joueront en demi final et les gagnants de ce dernier joueront la finale.
- Chaque match a un numéro, équipe 1, équipe 2, une date, heure de
début et heure de fin, un score en temps règlementaire, éventuellement
un score en temps supplémentaire, éventuellement un score de tirs au
ème ème ème
but, et une phase (16 , 8 , quart de 8 , demi final ou la finale).
Répondez aux questions suivantes :
a) Définissez les relations qui expriment les informations précédentes
b) Ecrivez les requêtes SQL qui définissent les tables relatives aux
relations définies dans la réponse à la question précédente tout en
incluant les contraintes d’intégrité nécessaires aux clés primaires et
étrangères.
c) Ecrivez une requête qui affiche tous les matchs nuls en temps
règlementaires.
Ecrivez les requêtes qui affichent pour chaque équipe : le nombre de

matchs gagnants, perdants et nuls, le nombre de buts marqués et le nombre
de buts encaissés.

Support de Cours BD

Transféré par

Droits d'auteur :

Formats disponibles

Support de Cours BD

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

Support de Cours BD

Transféré par

Droits d'auteur :

Formats disponibles

Support de cours

Bases de Données Avancées

3.4.2.3. Méthode définie par l’utilisateur .............................................................................. 66

4.7. Réplication ..................................................................................................................... 82

5.6.3. Faits .................................................................................................................................. 102

Conclusion ........................................................................................................................................... 107

Dans le présent support de cours nous traçons le parcours d’évolution de la

Afin de suivre cette évolution de la notion de BD de manière pédagogique, nous

Ce support de cours est organisé de la manière suivante :

Le chapitre 1 commence d’une part par définir la notion de SI et ses

Le chapitre 2 lance la discussion sur les différents modèles de BD avec le

Le chapitre 4 aborde le modèle des Bases de Données Distribuées (BDDs) en

Le chapitre 5 présente le modèle Data Warehouse (DW) en expliquant les

Le traitement de l’information est un moyen de création de la valeur dans une

1.1. Définition d’un SI

Les ressources peuvent être humaines, matérielles, logicielles (i.e. programmes

Les fonctions d’un SI peuvent être détaillées comme suit :

Collecter : il s’agit d’acquérir les informations à partir de l’environnement

Stocker : il s’agit de conserver l’information acquise et de la rendre disponible.

Traiter : il s’agit de transformer l’information en modifiant le fond ou la forme

Distribuer : il s’agit de diffuser l’information dans l’environnement interne ou

1.2. Composantes d’un SI

Figure 1 : Composantes d'un système d'information (Rivard 2001)

1.3.1. Sous-systèmes d’un SI

Le sous-système d’information se positionne au cœur de l’organisation en

1.3.1. Sous-système opérationnel

1.3.2. Sous-système décisionnel

1.3.3. Sous-système d’information (ou de communication)

Figure 2: Interaction entre les sous-systèmes d'une organisation

1.4. Processus de développement d’un système d’information

1.4.1. Cycle de développement

- La définition des objectifs :

1.4.2. Cycle de vie

1.4.3. Les modèles de cycle de vie

1.4.3.1. Modèles linéaires

Figure 3 : Modèle en cascade

- Modèle en V : Comme dans le modèle en cascade, dans le modèle en V

1.4.3.2. Modèles itératifs

- Modèle spirale : Défini par Barry Boehm en 1988, le modèle spirale

Figure 5 : Modèle spirale (Boehm 2000)

Figure 6 : Modèle incrémental

1.4.3.3. Modèles agiles

le client où des versions fonctionnelles du produit sont régulièrement livrées et

- eXtreme Programming (XP) :

Figure 7 : La boucle de planification et de feedback dans XP

- Feature Driven Development (FDD) :

1.5. Notion de base de données (BD)

L’avènement du concept de base de données a été justement vu comme la

1.5.1. Définition d’une BD

La structuration de données a pour principal objectif d’éliminer les redondances

1.5.2. Fonctions d’une base de données

- Stocker l’information d’une manière permettant la restitution facile de

1.6. Système de Gestion de base de données (SGBD)

1.6.1. Définition d’un SGBD

Gardarin précise que le principal objectif d’un SGBD est d’assurer

Afin d’assurer ces fonctionnalités, un langage de base de données

- Un langage de Définition de Données (LDD) qui permet à l’utilisateur de

1.6.2. Niveaux d’abstraction

Cette manière de conception en trois niveaux d’abstraction est derrière