Contenu du module Bases de données (2ème SC)

Chapitre 1 : Introduction aux bases de données

Introduction
1. Base de données
1.1 Définitions
1.2 Modélisation des données
1.3 Niveaux de représentation des données
2. Système de gestion de base de données (SGBD)
2.1. Définition
2.2. Les fonctions d’un SGBD
2.3 Architectures des SGBD
2.3.1. Architectures fonctionnelles
2.3.2. Architectures opérationnelles
2.4 Objectifs d’un SGBD
2.5 Exemples de SGBD
2.6 Evolution des SGBD
Chapitre 2 : Le modèle relationnel
Introduction
1. Concepts de base
2. Conception de schéma relationnel
2.1 Perception du réel
2.2. Problèmes soulevés par une mauvaise perception du réel
2.3 . Approche par décomposition
3. Dépendances fonctionnelles
3.1 . Définition
3.2. Propriétés des dépendances fonctionnelles
3.3 Fermeture transitive
3.4 Couverture minimale
4. Notion de clé
5. Normalisation de relation
5.1. Première forme normale
5.2. Deuxième forme normale
 5.3. Troisième forme normale
6. Forme normale de Boyce Codd
7. Dépendances multivaluées
6.1. Définition
6.2. Propriétés des dépendances multivaluées
7. Quatrième forme normale
8. Dépendances de jointure
9. Cinquième forme normale
Chapitre 3 : Les langages de manipulation des données relationnelles
Introduction
1. Algèbre relationnelle
1.1. Opérations de base
1 .1.1. Opérations unaires
1.1.2. Opérations binaires
1.2. Opérations additionnelles
1.3.Expression de requête
2. Le langage SQL
2.1 Expression de projection
2.2 Expression des sélections
2.3 Expression des jointures
2.4 Expression d’union, différence, intersection
2.5 Expressions de calcul
2.6 Commandes de mises à jour
2.7. Quelques commandes de Définition
Conclusion

Bibliographie
• [Gar-1986] Georges Gardarin, « Bases de Données, les Systèmes et leurs Langages ».
Eyrolles. 1986.
• [Gar-2003] Georges Gardarin, « Bases de données ». Eyrolles. 5ème édition 2003.
• [Cod-2017] Eric Godoc et Anne-Christine Bisson, «SQL Les fondamentaux du
langage». Edition Eni. 2017.
• [Hai-2015] Jean-Luc Hainaut , «Bases de données : concepts, utilisation et
développement». Édition DUNOD. 2015.
 Chapitre 1
Introduction aux bases de données

Introduction
Les progrès technologiques permettant le stockage de grandes masses de données avec
des coûts de plus en plus faible, le besoin des entreprises nécessitant dans leurs organisations
une connaissance plus fine de leurs activités et en solution aux problèmes posés par les
fichiers, la notion ou concept de base de données est apparu vers les années soixante.
Depuis, des concepts, des méthodes et des outils ont été développés pour mieux gérer les
données stockées en mémoire secondaire.

1. Base de données
1.1. Définitions
Définition1
Une base de données (BD) est un ensemble structuré de données enregistrées sur des
supports accessibles par l’ordinateur pour satisfaire simultanément plusieurs utilisateurs de
manière sélective et en un temps opportun.

Ainsi une BD est faite pour enregistrer des faits, des événements qui surviennent dans le cycle
de vie d’une organisation, ou pour les restituer à la demande, ou encore pour en tirer des
conclusions en rapprochant des faits les uns aux autres.
Exemple : au niveau de l’université on besoin de stocker des informations sur les enseignants,
les étudiants, les enseignements et les conditions d’inscription à un enseignement. On a besoin
aussi des associations qui lient ces différentes informations. Par exemple inscription lie
étudiant à un enseignement. Ces informations pourront être partagées par le service de
scolarité pour les inscriptions et le service de pédagogie pour établir par exemple les emplois
du temps.

Définition2
Une base de données est un ensemble de données modélisant les objets d’une partie du
monde réel et servant de support à une application informatique.

Cet ensemble de données doit être interrogeable par le contenu, c.-à-d. on peut retrouver un
ensemble d’objets satisfaisant un certain critère. Il doit être possible de retrouver leurs
structures, par exemple, le produit possède un nom, un prix et une quantité.
1.2. Modélisation des données
L’idée fondamentale des BDs est la séparation entre la description des données en termes de
types de la manipulation.

1.2.1 Instances et schémas

Toute description de données consiste à définir des propriétés d’ensembles d’objets modélisés
dans la BD et non pas d’objets particuliers. On distingue :

a- Type d’objet : spécifie un ensemble d’objets possédant des caractéristiques similaires

et manipulables par des opérations identiques. Par exemple type d’objet « produit »
possédant les propriétés (numéro, désignation, année-production, et quantité) muni des
opérations consommer et approvisionner qui diminue et augmente la quantité ;
 b- Instance d’objet : représente un élément particulier d’un type d’objet caractérisé par
un identifiant et des valeurs des propriétés. Exemple l’élément « 10, Livre, 2015, 60 »
est une instance du type d’objet « produit ».

Toute description de données se fait au niveau type selon un modèle de description des
données qui représente un ensemble de concepts et de règles de composition de ces
concepts permettant de décrire des données (ex. modèle relationnel, objet, relationnel objet,
etc…). Cette description sera mise en œuvre à l’aide d’un langage de définition des
données LDD. Un LDD est un langage supportant un modèle de description de données et
permettant de décrire des données d’une BD d’une manière assimilable par une machine.

Un schéma est une description au moyen d’un langage déterminé d’un ensemble de type
d’objets.

1.3. Niveaux de représentation des données

On distingue trois niveaux de représentation des données :

1.3.1. Niveau conceptuel

Consiste à décrire en termes abstrais mais fidèles une certaine réalité d’une organisation et
de ses processus de gestion nécessitant la mise en œuvre d’une base de données. Le passage
du monde réel vers le schéma conceptuel correspond à un processus de modélisation.

Exemple 1 : le schéma qui suit modélise le fait qu’un véhicule appartient à une seule
personne et qu’une personne peut ou non posséder un ou plusieurs véhicules.

Personne 0-N 1-1 Véhicule

Num Appartient Numéro
Nom Marque
Adresse Modèle
Année

Fig.1.1 : Exemple 1 de schéma conceptuel

Exemple 2 : le schéma conceptuel suivant modélise la gestion des produits où un client peut
acheter un ou plusieurs produits et un produit peut être acheté par un ou plusieurs clients, la
date et quantité d’achat dépendent du client et du produit. Une usine fabrique un ou plusieurs
produits et un produit peut être fabriqué par un ou plusieurs usines

Client Produit
Code 1-N 1-N Numéro
Achat
Nom Désignation
Date_Achat
Adresse Année
Quantité
1-N
Usine Est-fabriqué
Numéro 1-N
Nom
Lieu
Fig.1.2 Exemple 2 de schéma conceptuel
1.3.2. Niveau externe
Ce niveau correspond à une vision de tout ou d’une partie du schéma conceptuel par un
groupe d’utilisateurs concernés par une application et chargés de mettre en œuvre des
programmes d’utilisations. Ce qu’on appelle schéma externe ou vue. Par un exemple pour
la gestion des achats des produits, dans le schéma conceptuel présenté dans la figure Fig.
1.2, on ne va s’intéresser qu’à la partie client-achat-Produit. Ainsi pour calculer pour un
client la quantité de produits achetés il suffit de cumuler (la somme) les quantités de tous les
produits achetés par ce client.

1.3.3. Niveau interne

Appelé aussi niveau physique et a pour but de spécifier comment les données seront
stockées sur les supports périphériques de l’ordinateur. De façon fine les bits et plus large
les enregistrements et fichiers. Ce niveau a une existence matérielle et correspond à la BD
physique stockée sur mémoire auxiliaire.

En synthèse pour une base de données particulière, il existe un seul schéma interne et un seul
schéma conceptuel. En revanche, il existe en général plusieurs schémas externes. Un schéma
externe peut être défini par un groupe d'utilisateurs. À partir de là, il est possible de construire
des schémas externes pour des sous-groupes du groupe d'utilisateurs considéré. Ainsi, certains
schémas externes peuvent être déduits les uns des autres. La figure Fig. 1.3 illustre les
différents schémas d'une base de données centralisée.

Fig. 1.3 : Les niveaux de représentation des données

2. Système de gestion de base de données (SGBD)
2.1. Définition : un SGBD est un ensemble de logiciels systèmes permettant aux utilisateurs
d’insérer, de modifier, et de rechercher efficacement des données spécifiques dans une grande
masse d’informations (pouvant atteindre plusieurs milliards d’octets ) partagée par de
multiples utilisateurs.

2.2. Les fonctions d’un SGBD

Le SGBD est le principal logiciel responsable de gérer à tous les niveaux les structures se
trouvant dans une BD. Cette gestion intègre les fonctions suivantes :

2.2.1. La définition de données

La définition des différents schémas est effectuée par les administrateurs de données ou par
les personnes jouant le rôle d’administrateur. Le SGBD offre donc aux utilisateurs des
interfaces pour décrire:

- les objets/entités qui vont constituer la BD (comme des personnes possédant des voitures, les
voitures appartenant à ces personnes, …).

- Les attributs/données relatifs à ces objets (comme les noms de personnes, les types de
voitures,…)

- Les liens qui peuvent rendre ces objets inter-liés (comme une personne peut posséder un ou
plusieurs voitures, …).

Ces moyens constituent ce que l’on appelle le Langage de Description de Données (LDD).

Exemple : sous Oracle, la commande Create table pour créer une table, Create index on pour
créer un index sur une table, Define view pour la définition des vues etc…

2.2.2. La manipulation de données

La manipulation de données concerne les outils et les mécanismes qui permettent de
manipuler le contenu d’une BD par les utilisateurs.
Ainsi pour les informations à utiliser, les SGBD offrent souvent sous diverses formes des
capacités de :
- Recherche
- Insertion
- Modification
- Suppression
Ces moyens constituent ce que l’on appelle généralement Langage de Manipulation de
Données (LMD)
Exemple
Pour la BD correspondant au schéma donné Fig.1.1, on peut prévoir :

- la saisie et l’enregistrement des données relatives aux personnes et aux voitures en utilisant
la commande INSERT.
- La possibilité de les modifier, par la commande UPDATE
- La possibilité d’avoir la liste de personnes qui ont plus qu’une voiture, la commande
SELECT.
-…
2.2.3. L’intégrité de données
Les informations dans une BD doivent être fiables. Pour être fiable, l’information doit parfois
vérifier certaines propriétés comme l’appartenance à une liste de valeurs permises (comme un
nom d’une personne non vide, une voiture appartenant à une personne appartenant à l’entité
personne, …).
A cet effet, le SGBD Offre la possibilité de définir des règles permettant de maintenir
l’intégrité (ou la cohérence) de la BD. Ces règles sont les contraintes d’intégrité.

2.2.4. La gestion des accès concurrents

Une BD est généralement accessible à plusieurs administrateurs (par ex. Les agents de
finance,…) en même temps. Un SGBD doit offrir cette possibilité, et garantir la détection de
cas de conflits et les traiter correctement.

2.2.5 La confidentialité
Le SGBD offre des mécanismes afin de vérifier les droits d’accès aux utilisateurs.
Généralement cette confidentialité est assurée par l’utilisation de mots de passe et de
privilèges d’accès (par ex. un seul administrateur a le droit de suppression, d’ajout de
voitures, … les autres utilisateurs ont uniquement le droit de consultation ou recherche).

2.2.6. Gestion de transaction et sécurité

Une transaction est un groupe d’actions qui fait passer la base d’un état cohérent à un
nouveau état cohérent. (commandes début et fin transaction). Les états successifs doivent être
cohérents et donc respecter les contraintes d’intégrité. Lorsqu’une transaction est
partiellement exécutée, les données peuvent passer par des états incohérents transitoires, qui
seront corrigés par les mises à jour suivantes de la transaction. Pendant cette période
d’activité, les effets de la transaction ne doivent pas être visibles aux autres transactions.

Une transaction doit satisfaire les propriétés (ACID) suivantes :

Atomicité : Une transaction est totalement exécutée ou pas du tout
Correction : Respecter la cohérence de la BD en fin de transaction
Isolation : Ne pas laisser visible à l’extérieur les données modifiées avant la fin de transaction
Durabilité : Pouvoir conserver durablement les mises à jour des transactions

La sécurité permet d’éviter les accès non autorisés aux données par des mécanismes de
contrôle de droits d’accès, mais aussi de restaurer des données correctes en cas de pannes ou
d’erreurs.
2.3. ARCHITECTURE DES SGBD
Il existe différentes architectures de SGBD

2.3.1. ARCHITECTURE FONCTIONNELLE

a) Architecture de référence d’un SGBD
Analyse syntaxique
Analyseur Analyse sémantique
Gestion des schémas

Modification de requêtes
Contrôleur Contrôle d'intégrité
Métabase
Contrôle d'autorisation

Ordonnancement
Optimiseur Optimisation
Élaboration d'un plan

Exécution du plan
Exécuteur Méthodes d'accès
Contrôle de concurrence
Atomicité des transactions

BD

Fig. 1.4 : Architecture de référence d’un SGBD

Du point de vue de la description de données, un SGBD gère un dictionnaire de données,

encore appelé métabase car souvent organisé comme une base de données qui décrit les
autres bases. Ce dictionnaire est alimenté par les commandes de définition du schéma (par
exemple CREATE TABLE, CREATE INDEX) et de définition des vues (par exemple
DEFINE VIEW). Ces commandes sont analysées et traitées par le processeur d’analyse
(ANALYSEUR), plus spécifiquement par la partie traitant le langage de description de
données de ce processeur. Celle-ci fait souvent appel aux fonctions plus internes du SGBD
pour gérer le dictionnaire comme une véritable base de données.

Du point de vue de la manipulation des données, les requêtes (par exemple, SELECT,
INSERT, UPDATE, DELETE) sont tout d’abord prises en compte par l’analyseur de
requêtes. Celui-ci réalise l’analyse syntaxique (conformité à la grammaire) et sémantique
(conformité à la vue référencée ou au schéma) de la requête. Celle-ci est alors traduite en
format interne, les noms étant remplacés par des références internes.

Une requête en format interne référençant une vue doit tout d’abord être traduite en une (ou
plusieurs) requête(s) référençant des objets existant dans la base, c’est-à-dire des objets décrits
au niveau du schéma. Cette fonction, accomplie au niveau du contrôleur de requêtes Fig.1.4,
est appelée modification de requêtes, car elle consiste à changer la requête en remplaçant les
références aux objets de la vue par leur définition en termes d’objets du schéma.
 C’est aussi au niveau du contrôleur que sont pris en compte les problèmes de contrôle de
droits d’accès (autorisation de lire ou d’écrire un objet) et de contrôle d’intégrité lors des
mises à jour. Le contrôle d’intégrité consiste à vérifier que la base n’est pas polluée lors des
mises à jour, c’est-à-dire que les règles de cohérence des données restent vérifiées après mise
à jour.

L’optimiseur de requêtes est un composant clé du SGBD. Son rôle essentiel est d’élaborer
un plan d’accès optimisé pour traiter la requête. Pour se faire, il décompose en général la
requête en opérations d’accès élémentaires (e.g., sélection d’index, lecture d’article, etc.) et
choisit un ordre d’exécution optimal ou proche de l’optimum pour ces opérations. Il choisit
aussi les méthodes d’accès à utiliser. Pour effectuer les meilleurs choix, l’optimiseur s’appuie
souvent sur un modèle de coût qui permet d’évaluer le coût d’un plan d’accès avant son
exécution. Le résultat de l’optimisation (le plan d’accès optimisé) peut être sauvegardé en
mémoire pour des exécutions multiples ultérieures ou exécuté directement puis détruit.

L’exécuteur de plans a enfin pour rôle d’exécuter le plan d’accès choisi et élaboré par
l’optimiseur. Pour cela, il s’appuie sur les méthodes d’accès qui permettent d’accéder aux
fichiers via des index et/ou des liens. C’est aussi à ce niveau que sont gérés les problèmes de
concurrence d’accès et d’atomicité de transactions. Les techniques utilisées dépendent
beaucoup de l’architecture opérationnelle du SGBD qui s’exprime en termes de processus et
de tâches.

b) L’ARCHITECTURE À TROIS NIVEAUX DE L’ANSI/X3/SPARC

Les groupes de normalisation se sont penchés depuis fort longtemps sur les
architectures de SGBD. À la fin des années 70, le groupe ANSI/X3/SPARC DBTG a proposé
une architecture intégrant les trois niveaux de schémas : externe, conceptuel et interne.
Bien qu’ancienne, cette architecture permet de bien comprendre les niveaux de description et
transformation de données possible dans un SGBD.

Fig. 1.5 : Architecture à 3 niveaux

L’architecture est articulée autour du dictionnaire de données et comporte deux parties :
1. un ensemble de modules (appelés processeurs) permettant d’assurer la description de
données et donc la constitution du dictionnaire de données ;
2. une partie permettant d’assurer la manipulation des données, c’est-à-dire l’interrogation et
la mise à jour des bases.
Dans chacune des parties, on retrouve les trois niveaux interne, conceptuel et externe.
L’architecture proposée est représentée figure Fig. 1.5. Les fonctions de chacun des
processeurs indiqués sont les suivantes. Le processeur de schéma conceptuel compile le
schéma conceptuel et, dans le cas où il n’y a pas d’erreur, range ce schéma compilé dans le
dictionnaire des données. Le processeur de schéma externe compile les schémas externes et
les règles de correspondance externe à conceptuel et, après une compilation sans erreur, range
le schéma compilé et les règles de correspondance dans le dictionnaire des données. Le
processeur de schéma interne a un rôle symétrique pour le schéma interne.

Le processeur de transformation externe à conceptuel traduit les manipulations externes en

manipulations conceptuelles et dans l’autre sens les données conceptuelles en données
externes.
Une requête externe peut donner naissance à plusieurs requêtes au niveau conceptuel. Le
processeur de transformation conceptuel à interne traduit les manipulations conceptuelles en
manipulations internes et dans l’autre sens les données internes en données conceptuelles.
Finalement, le processeur de transformation interne à stockage traduit les manipulations
internes en programmes d’accès au système de stockage et délivre les données stockées en
format correspondant au schéma interne.

Les diverses interfaces indiquées correspondent successivement à (les numéros se rapportent à

la figure Fig. 1.5) :

(1) Langage de description de données conceptuel, format source ; il permet à l’administrateur

de définir le schéma conceptuel en format source. Il correspond par exemple aux commandes
CREATE TABLE.

(2) Langage de description de données conceptuel, format objet ; il résulte de la

compilation du précédent et permet de ranger le schéma objet dans le dictionnaire des
données.

(3) Description de données conceptuel, format d’édition ; cette interface permet aux
administrateurs de consulter le schéma conceptuel afin de définir les règles de
correspondance. Il pourrait s’agir par exemple d’une visualisation graphique des diagrammes
entité-association.

(4) Langages de description de données externes, format source ; ils peuvent être multiples si
le SGBD supporte plusieurs modèles de données. Ils permettent aux administrateurs de
définir les schémas externes et les règles de correspondance avec le schéma conceptuel. Par
exemple, la commande DEFINE VIEW introduite illustre ce type de langage, qui permet donc
de définir des schémas externes encore appelés vues.

(5) Langages de description de données externes, format objet ; ils correspondent à la

compilation des précédents et permettent de ranger les schémas externes objets dans le
dictionnaire de données.
(6) Langages de description de données internes, format source ; il permet à l’administrateur
de bases de données de définir le schéma interne et les données de correspondance avec le
schéma conceptuel. Par exemple, la commande CREATE INDEX se situe à ce niveau
d’interface.

(7) Langage de description de données internes, format objet ; il correspond à la

compilation du précédent et permet de ranger le schéma interne objet dans le dictionnaire des
données.
(8) Langages de manipulation de données externes, format source ; ils permettent aux
programmeurs d’applications, voire aux non-informaticiens, de manipuler les données
décrites dans un schéma externe. Ils comportent des commandes du type recherche, ajout,
modification et suppression référençant les objets décrits dans un schéma externe.

(9) Langages de manipulation de données externes, format objet ; ils correspondent aux
schémas compilés des précédents.

(10) Langage de manipulation de données conceptuelle, format objet ; il est généré par les
processeurs de transformation externe à conceptuel afin de manipuler les données logiques
décrites dans le schéma conceptuel. Ils comportent des primitives correspondant à la
compilation des commandes du type recherche, ajout, modification et suppression référençant
cette fois les objets décrits dans le schéma conceptuel.

(11) Langage de manipulation de données interne, format objet ; il est généré par le
processeur de transformation conceptuel à interne afin de manipuler les données internes. Il
permet par exemple d’accéder aux articles de fichiers via des index.

(12) Langage de stockage de données, format objet ; il correspond à l’interface du système de

stockage de données. Il permet par exemple de lire ou d’écrire une page dans un fichier.

(13) Interface mémoires secondaires ; elle permet d’effectuer les entrées-sorties sur les
disques.

(14) Interface d’accès au dictionnaire des données ; elle permet aux divers processeurs de
transformation d’accéder aux schémas objets et aux règles de correspondance.

2.3.2. ARCHITECTURES OPÉRATIONNELLES DES SGBD

a) Architecture Client-Serveur
L’application se compose d'un client (premier niveau) et un serveur (deuxième niveau) qui
pourraient fonctionner sur des machines différentes. Les caractéristiques essentielles de cette
architecture se résument dans :
– Une séparation claire des préoccupations entre client et serveur
– Un client léger vs client lourd
– Plus ou moins de la logique d'application sur le côté client
– Prise en charge des environnements d'entreprise décentralisés
 Fig. 1.6 Architecture client serveur

b) Architecture parallèle

Fig. 1.7 Architecture parallèle

Cette architecture se base sur des machines parallèles (plusieurs processeurs) qui peuvent être
utilisés pour accélérer le traitement des transactions.

Il existe différents modèles pour les architectures de bases de données parallèles :

- multiprocesseurs à mémoire partagée,

- architectures à disques partagés,
- architectures sans partage
- architectures hiérarchiques
b.1. Multiprocesseurs à mémoire partagée (Shared memory)

Les processeurs et disques ont accès à une mémoire partagée via un bus. La communication
entre processeurs est très efficace.
Ex.: XPRS, DBS3 et Volcano

b.2. Architectures à disques partagés (Shared disk)

– Tous les processeurs peuvent accéder à tous les disques via un réseau d’interconnexion.
– Chaque processeur a sa propre mémoire.
– Un certain degré de tolérance aux pannes en cas de défaillance du processeur/ de la
mémoire
– Les disques peuvent également avoir une tolérance aux pannes (par exemple, l'architecture
RAID)
– L'interconnexion aux systèmes de disques devient un goulot d'étranglement

b.3. Architectures sans partage (Shared nothing)

– Chaque nœud se compose d'un processeur, d'une mémoire et d'un ou plus de disques
– Un réseau d'interconnexion haut débit entre processeurs
– Plus évolutif que la mémoire partagée ou le modèle de disque partagé
– Augmentation des coûts de communication pour l'accès au disque non local
b.4. Architectures hiérarchique (Hierarchical)

– Combine les différents modèles (composition)

– Le niveau supérieur ne partage rien entre les nœuds
– chaque nœud peut être une mémoire partagée ou un "sous-système" de disque partagé

c. Architecture distribuée

L’architecture distribuée se caractérise par les points qui suivent :

- Une Base de Données Distribuée

C’est une collection logiquement connexe de données partagées et des métadonnées qui est
distribué sur un réseau.

- Un SGBD Distribué
Représente un système logiciel pour gérer la base de données distribuée de façon transparente.
Il se caractérise par :

- Une Distinction entre les transactions locales et globales

Transaction locale: Accède uniquement les données du site à partir duquel l'opération a été
amorcée.
Transaction globale: Accède aux données à partir de plusieurs sites différents.

Les raisons de la construction d'un SGBD distribués

- Le partage de données : la possibilité d'accéder aux données qui réside à d'autres côtés
- L’Autonomie : chaque site conserve un certain degré de contrôle sur les données locales
- La disponibilité : si un site est off, les autres sites peuvent encore être en mesure de
continuer à fonctionner. Des données peuvent être répliquées sur plusieurs sites pour une
disponibilité accrue
- Coûts et évolutivité: l'utilisation grappe de PC à la place de grands systèmes Mainframe
- Intégration des SGBD existants: La coexistence des systèmes existants avec de nouvelles
applications
- Une structure organisationnelle dynamique .
2.2. Objectifs d’un SGBD

- Indépendance physique
Pouvoir modifier les structures de stockage ou les index sans que cela ait de répercussion
au niveau des applications Les disques, les méthodes d’accès, les modes de placement, le
codage des données ne sont pas apparents.

- Indépendance logique
Permettre aux différentes applications d’avoir des vues différentes des mêmes données et
à l’administrateur de BD de modifier le schéma logique sans que cela ait de répercussion
au niveau des applications

- Description des données

Décrire des données indépendamment des applications en offrant un langage de définition
des données (LDD).

- Manipulation des données par des langages non procéduraux

Interroger et mettre à jour les données sans préciser d'algorithme d'accès dire QUOI sans
dire COMMENT en utilisant un langage de requêtes déclaratif appelé langage de
manipulation des données (LMD).

- Administration facilitée des données

Un SGBD doit fournir des outils pour décrire les données, à la fois leurs structures de
stockage et leurs présentations externes. Il doit permettre le suivi de l’adéquation de ces
structures aux besoins des applications et autoriser leur évolution aisée. Les fonctions qui
permettent de définir les données et de changer leur définition sont appelées outils
d’administration des données.
Afin de permettre un contrôle efficace des données, de résoudre les conflits entre divers
points de vue pas toujours cohérents, de pouvoir optimiser les accès aux données et
l’utilisation des moyens informatiques, on a pensé à centraliser ces fonctions entre les
mains d’un petit groupe de personnes hautement qualifiées, appelées administrateurs de
données.

En fait, la centralisation des descriptions de données entre les mains d’un groupe
spécialisé a souvent conduit à des difficultés d’organisation. Aussi, l’évolution des SGBD
modernes tend à fournir des outils permettant de décentraliser la description de données,
tout en assurant une cohérence entre les diverses descriptions partielles.

Un dictionnaire de données dynamique pourra ainsi aider les concepteurs de bases de

données. Pour permettre une évolution rapide, les descriptions de données devront être
faciles à consulter et à modifier. L’évolution va donc vers le développement d’outils
intégrés capables de faciliter l’administration des données et d’assurer la cohérence des
descriptions.

- Efficacité des accès aux données

Les performances en termes de débit (nombre de transactions types exécutées par
seconde) et de temps de réponse (temps d’attente moyen pour une requête type) sont un
problème clé des SGBD. L’objectif de débit élevé nécessite un overhead minimal dans la
gestion des tâches accomplie par le système.
 L’objectif de bons temps de réponse implique qu’une requête courte d’un utilisateur
n’attende pas une requête longue d’un autre utilisateur. Il faut donc partager les
ressources (unités centrales, unités d’entrées-sorties) entre les utilisateurs en optimisant
l’utilisation globale et en évitant les pertes en commutation de contextes. Le goulot
d’étranglement essentiel dans les systèmes de bases de données reste les E/S disques.
Une E/S disque coûte en effet quelques dizaines de millisecondes.

Afin de les éviter, on utilisera une gestion de tampons en mémoire centrale dans de
véritables mémoires caches des disques, afin qu’un grand nombre d’accès aux données se
fasse en mémoire. Un autre facteur limitatif est dû à l’utilisation de langages non
procéduraux très puissants afin d’interroger et mettre à jour la base de données.

Ainsi, il devient possible de demander en une requête le tri d’un grand volume de
données. Il devient donc aussi nécessaire d’optimiser l’activité de l’unité centrale pour
traiter les opérations en mémoire.

En résumé, un SGBD devra chercher à optimiser une fonction de coût de la forme

C(Q) = a * ES(Q) + b * UC(Q) pour un ensemble typique de requêtes (recherches et
mises à jour) Q ; ES(Q) est le nombre d’entrées-sorties réalisées pour la requête Q et
UC(Q) est le temps unité centrale dépensé ; a et b sont des facteurs convertissant entrées-
sorties et temps d’unité centrale en coûts.

- Contrôle de redondance des données

Dans les systèmes classiques à fichiers non intégrés, chaque application possède ses données
propres. Cela conduit généralement à de nombreuses duplications de données avec, outre la
perte en mémoire secondaire associée, un gâchis important en moyens humains pour saisir et
maintenir à jour plusieurs fois les mêmes données.

Avec une approche base de données, les fichiers plus ou moins redondants seront intégrés
en un seul fichier partagé par les diverses applications. L’administration centralisée des
données conduisait donc naturellement à la non-duplication physique des données afin
d’éviter les mises à jour multiples. En fait, avec les bases de données réparties sur plusieurs
calculateurs interconnectés, il est apparu souhaitable de faire gérer par le système des copies
multiples de données. Cela optimise les performances en interrogation, en évitant les
transferts sur le réseau et en permettant le parallélisme des accès. On considère donc
aujourd’hui que la redondance gérée par le SGBD au niveau physique des données n’est pas
forcément mauvaise.
Il faudra par contre éviter la redondance anarchique, non connue du système, qui
conduirait les programmes utilisateurs à devoir mettre à jour plusieurs fois une même
donnée. Il s’agit donc de bien contrôler la redondance, qui permet d’optimiser les
performances, en la gérant de manière invisible pour les utilisateurs.

- Cohérence des données

Bien que les redondances anarchiques entre données soient évitées par l’objectif précédent,
les données vues par l’utilisateur ne sont pas indépendantes. Au niveau d’ensemble de
données, il peut exister certaines dépendances entre données. Par exemple, une donnée
représentant le nombre de commandes d’un client doit correspondre au nombre de
commandes dans la base. Plus simplement, une donnée élémentaire doit respecter un format
et ne peut souvent prendre une valeur quelconque. Par exemple, la note d’un étudiant à un
examen doit être comprise entre 0 et 20. Un système de gestion de bases de données doit
veiller à ce que les applications respectent ces règles lors des modifications des données et
ainsi assurer la cohérence des données. Les règles que doivent explicitement ou
implicitement suivre les données au cours de leur évolution sont appelées contraintes
d’intégrité.

- Partage des données

L’objectif est ici de permettre aux applications de partager les données de la base dans le
temps mais aussi simultanément. Une application doit pouvoir accéder aux données comme
si elle était seule à les utiliser, sans attendre mais aussi sans savoir qu’une autre application
peut les modifier concurremment. En pratique, un utilisateur exécute des programmes
généralement courts qui mettent à jour et consultent la base de données. Un tel programme
interactif, appelé transaction, correspond par exemple à l’entrée d’un produit en stock ou à
une réservation de place d’avion. Il est important que deux transactions concurrentes (par
exemple, deux réservations sur le même avion) ne s’emmêlent pas dans leurs accès à la base
de données (par exemple, réservent le même siège pour deux passagers différents). On
cherchera donc à assurer que le résultat d’une exécution simultanée de transactions reste le
même que celui d’une exécution séquentielle dans un ordre quelconque des transactions.

- Sécurité des données

La sécurité concerne deux aspects :
1. Sécurité contre les accès non autorisés : les données doivent être protégées contre les
accès non autorisés ou mal intentionnés. Il doit exister des mécanismes adéquats pour
autoriser, contrôler ou enlever les droits d’accès de n’importe quel usager à tout
ensemble de données. Les droits d’accès peuvent également dépendre de la valeur des
données ou des accès précédemment effectués par l’usager.
Par exemple, un employé pourra connaître les salaires des personnes qu’il dirige mais
pas des autres employés de l’entreprise.

2. Sécurité suite à une reprise de la BD après une panne: la sécurité des données doit
aussi être assurée en cas de panne d’un programme ou du système, voire de la machine.
Un bon SGBD doit être capable de restaurer des données cohérentes après une panne
disque, bien sûr à partir de sauvegardes. Aussi, si une transaction commence une mise à
jour (par exemple un transfert depuis votre compte en banque sur celui de l’auteur) et est
interrompue par une panne en cours de mise à jour (par exemple après avoir débité votre
compte en banque), le SGBD doit assurer l’intégrité de la base (c’est-à-dire que la
somme d’argent gérée doit rester constante) et par suite défaire la transaction qui a
échoué. Une transaction doit donc être totalement exécutée, ou pas du tout : il faut
assurer l’atomicité des transactions, et ainsi garantir l’intégrité physique de la base de
données.
2.3. Exemples de SGBD

Oracle: Il s’agit d’un environnement de développement complet comportant notamment un

noyau de SGBD relationnel puissant (et relationnel-objet dans ses dernières versions) très
reconnu pour les applications professionnelles.

DB2 : c’est un SGBD relationnel développé par IBM.

MySQL : représente un SGBD relationnel appartenant à la famille de logiciels libre

(licence GPL et commerciale), simple d'accès et très utilisé pour la réalisation de sites Web
dynamiques. Depuis la version 4 MySQL implémente la plupart des fonctions attendues
d'un SGBD relationnel.

PostgreSQL est un SGBD relationnel et relationnel-objet, donnant plus de fonctionnalités

que MySQL, très puissant et offre une alternative open source aux solutions commerciales
comme Oracle ou IBM.

Access est un SGBD relationnel Microsoft, qui offre une interface graphique permettant de
concevoir rapidement des applications de petite envergure ou de réaliser des prototypes.

SQL Server C’est un SGBD relationnel développé par Microsoft pour succéder à Access
pour des grosses applications.

2.4. Evolution des SGBD

1960: systèmes de gestion de fichiers

1965: début des SGBD réseaux et hiérarchiques proches des systèmes de gestion de fichiers,
pas d’interrogation sans savoir où est l'information recherchée ("navigation") et sans écrire de
programmes.

1970: définition du modèle relationnel par CODD, fondement de la théorie des bases de
données relationnelles, mise en œuvre des SGBDs INGRES à Berkeley supportant le langage
QUEL et System R IBM à San Jose supportant les langages SEQUEL et QBE.

1980 : Apparition des SGBD relationnels sur le marché (Oracle, Ingres, Informix, Sybase,
DB2 …)

1990 : début des SBGD orientés objet (Gemstone, O2, Orion, Objectstore, Versant,
Matisse...).

Aujourd’hui : le relationnel-objet, semi-structuré, et multi-média…