Module BDD : Introduction aux BDD Mme H.

CHELLAKH

Introduction aux bases de données

I. Introduction :
De nos jours les entreprises manipulent un volume important d’informations. Poussées
par un souci d’amélioration continuelle de leurs performances, ces entreprises doivent penser
à une manière efficace de sauvegarder, rechercher et mettre à jour l’information qu’elles
manipulent.
Les systèmes classiques de gestion de fichiers (SGF) s’avèrent limités lorsqu’il s’agit
de manipuler une masse importante de données comportant des liens entre elles. Ces données
souvent réparties entre différents fichiers avec énormément de redondances dans leur
représentation.
En effet, chaque application dispose de ses propres fichiers et de ses propres
programmes qui doivent maintenir la cohérence des données manipulées.
En plus, les organisations des données sur disque, offerts par les SGF n’autorisent
souvent l’accès que par le biais de la clé des enregistrements. Une recherche basée sur un
autre critère nécessite un effort supplémentaire de programmation.
Pour pallier ces insuffisances, la notion de base de données (BD) est apparue. Celle-ci
est une collection de données cohérentes, non redondantes (ou peu redondante), structurées
indépendamment de l’application qui les manipule. Le système qui doit gérer une DB est
appelé Système de Gestion de Base de Données (SGBD), c’est un logiciel qui permet aux
utilisateurs de définir, créer et maintenir une BD et qui fournit un accès contrôlé au données.

2. Système d’information et gestion des données :

Afin de bien fixer les idées, prenons l’exemple de la gestion d’une scolarité. Les
données disponibles dans tel environnement, concernent les enseignants, les étudiants, les
modules enseignés, les notes obtenues, …etc.
La direction de la scolarité envisage, l’exploitation de l’outil informatique, pour une
gestion efficace de ces données. Pour cela les données doivent être stockées sur un support
informatique (mémoire secondaire), pour être ensuite sujettes à des traitements automatisés
(calcul des moyennes, édition de la liste des étudiants admis, calculs statistiques…etc.)
La tâche est confiée à un jeune programmeur, qui fait le raisonnement suivant :
1- les données doivent être stockées dans un ou plusieurs fichiers d’enregistrements.
2- La structure des enregistrements doit permettre de représenter les informations à
stocker : par exemple on pourrait avoir un fichier pour les notes des étudiants où les
enregistrements seraient structurés plus ou moins comme suit :
Record of
Matricule : string [8] ;
Nom, Prénom : string [30] ;
Note1, Note2, Note3 : real ;
End ;
Il serait alors possible d’alimenter le fichier décrit, par des données respectant cette structure:
0211 Belhocine Samir 10 12 14 12 0512 Ameur Fateh 9 7 7 8.33

Notre programmeur devra par la suite écrire des programmes, qui exploitent les
fichiers, (dont il connaît la structure), pour automatiser les traitements voulus.
Bien que cette réflexion ait des chances d’aboutir à une solution provisoire, elle ne risque pas
de donner lieu à une automatisation durable, et efficace.
Les reproches qui pourraient être faits :

1
Module BDD : Introduction aux BDD Mme H.CHELLAKH

1- Comment définir de façon claire et efficace, les structures des fichiers, en évitant les
redondances, et les incohérences.
2- La solution proposée, ne peut résister, ou s’adapter facilement à un changement, par
exemple rajouter une quatrième note.
3- L’ajout, la suppression, et la modification d’enregistrements, ainsi que les contrôles de
saisie, devront être programmés explicitement, et influeront sur le temps d’accès, aux
données.
4- En cas de démission de notre jeune programmeur, il sera difficile à son remplaçant de
maintenir l’application, sans avoir une connaissance complète des détails
d’implémentation.
En résumé, une application solide de gestion, ne peut être le résultat d’un bricolage, même
si elle est l’œuvre d’un programmeur de génie. En fait il faut remarquer, que certains des
inconvénients, que nous reprochons à la solution précédente, sont dus à l’absence d’une
démarche de conception claire, et décidable. Alors que d’autres sont liés aux limites du
système de gestion de fichiers (SGF), qui n’offre pas des techniques spécifiques à une telle
application.

2.1 Pourquoi une démarche de conception ?

La complexité des systèmes d’information, ne peut être dépassée, qu’à travers une
démarche, claire, efficace, qu’un concepteur devrait suivre pour aboutir à une solution
standard et cohérente.
La conception est une étape préalable à la programmation. Elle consiste à définir
l’ensemble des éléments, et des liens qui les relient. Dans notre exemple précédent, il s’agit de
proposer une représentation, des intervenants dans la scolarité : les étudiants, les enseignants,
les modules, les salles d’enseignement,…etc. ainsi que des liens entre eux : quel enseignant
assure quel module ? …etc.
Pour représenter cette réalité un concepteur doit s’appuyer sur une démarche, et un
modèle conceptuel, qui en résulte.
Plusieurs modèles ont été proposés, dans le cas des systèmes d’information. Parmi
lesquels nous citons : le modèle hiérarchique, le modèle réseau, le modèle relationnel et plus
récemment le modèle orienté objet.
Parmi ces modèles, le modèle relationnel, est celui qui a eu le plus de succès,
notamment sur le plan commercial. Alliant à la fois, simplicité et richesse d’expression, et se
basant sur des fondements mathématiques solides, il est à la base de la majorité des systèmes
d’information.

2. 2 Limites des SGF :

Les systèmes de fichiers informatisés ont un certain nombre de problèmes :
1. Redondance des données :
La répétition en différents endroits de données identiques pose de difficiles problèmes lors
des mises à jour ; chaque modification doit être répercutée sur toutes les occurrences de
l’objet concerné. Par exemple, le changement de nom d’un employé doit être effectué aussi
bien au service du personnel qu’à la comptabilité, etc.
Les effets de la redondance :
 Les coûts de stockage sont augmentés.
 De multiples mises à jour doivent être effectuées pour actualiser les différents
fichiers.
 Peut mener à une incohérence de données.
 Rend les normes difficiles à appliquer.

2
Module BDD : Introduction aux BDD Mme H.CHELLAKH

2. Incohérence des données :

Des liens sémantiques existent très souvent entre les données : le poste d’un employé,
figurant dans le fichier du service du personnel, n’est pas sans rapport avec le salaire qui lui
est versé par la comptabilité. Pourtant la modification de l’un n’entraîne pas automatiquement
celle de l’autre. Des incohérences apparaissent trop fréquemment du fait de la difficulté et du
coût qu’implique le contrôle de « contraintes d’intégrité » liant les données entre elles.
3. Manque de normalisation :
Que se passent t-il lorsque l’on change de système d’exploitation ou de support de
stockage ? Dans la plupart des cas, les applications développées sont si fortement liées aux
possibilités propres du système et du gestionnaire de fichiers qu’il est parfois aussi difficile de
les actualiser que de les réécrire entièrement. Si la normalisation des langages de
programmation est de plus en plus fréquente, les accès aux fichiers dépendent la plupart du
temps de la machine ; le manque de séparation entre le code de l’interface et celui du
traitement des données interdit de faire une simple modification du code.
4. Problème de sécurité :
Garantir de la sécurité physique de l’information est une des tâches de base d’un système
informatique. Qu’arrive t-il si une panne interrompt un programme augmentant tous les
salaires de 3% ? Combien de modifications ont été prises en compte : où reprendre le travail ?
La présence de la même information en plusieurs exemplaires n’est évidemment pas de nature
à faciliter la tâche du SGBD et des programmes de reprise après panne. De même, la
confidentialité de l’information est plus facile à assurer avec une seule occurrence de
l’information à protéger.
5. Dépendance des données :
Dans un système de fichiers, les données dépendent des applications qui les utilisent.
6. Partage limité des données :
Dans un système de fichier, chaque application possède ses propres données enregistrées
dans les fichiers séparés, ce qui rend le partage de données difficiles.

3. Notions préliminaires : BD et SGBD

3.1 Base de données :
Une base de données peut être vue comme une collection de données persistantes,
opérationnelles, enregistrées en mémoire secondaire (disque dur par exemple). Ces données
doivent être cohérentes, non redondantes (ou de redondance minimale) accessibles
simultanément par plusieurs programmes (ou utilisateurs). Il faut noter q’une base de données
est indépendante des programmes d’application qui l’utilisent.
Exemple :
Cet exemple présente une collection de données représentant une partie d’un emploi du
temps dans un établissement scolaire :
Jour Heure Local Cod-mod Num-ens An_étude Section
Samedi 8h 00 L1 Algo E1 2 A
h
Samedi 13 00 L2 Archi E2 2 A
Lundi 9h 00 L1 Algo E4 2 B
h
Mardi 11 00 L3 Log E3 2 B
h
Samedi 13 00 L3 Sys E4 2 A

3
Module BDD : Introduction aux BDD Mme H.CHELLAKH

3.2 Système de gestion de base de données (SGBD) :

C’est un ensemble d’outils logiciels permettant la création et la manipulation des bases de
données, ses principales fonctionnalités sont résumées dans les points suivants :
 La définition des données :
Un SGBD doit fournir à l’utilisateur des outils (primitives) pour décrire les entités de la
base de données (exemple : Etudiant, module, enseignant,…), les attributs de chaque entité
(matricule, nom, prénom, code module,…), ainsi que les liens entre eux et les contraintes
éventuelles qui les concernent. La définition des données se fait au moyen d’un langage de
définition de données (LDD)
 La manipulation de données :
Un SGBD doit offrir aux utilisateurs des moyens pour la manipulation des données de la
base, il s’agit des primitives permettant la recherche, la modification, l’ajout et la suppression
de données. Ces primitives constituent le langage de manipulation de données (LMD).
 L’intégrité des données :
Un SGBD doit garantir la qualité (fiabilité) de l’information enregistrée, il s’agit par
exemple, de propriétés que doivent vérifier certains attributs (plage de valeurs permises) et
spécifiées lors de la définition des données par LDD. D’autres contraintes peuvent être plus
complexes et doivent être programmées.
 Les accès concurrents :
Un SGBD doit offrir des mécanismes de gestion des accès simultanés à une base de
données, ceci est nécessaire lorsque plusieurs utilisateurs dans un réseau veulent accéder aux
données de la même base.
 La confidentialité :
Lorsque la base de données est accédée par plusieurs utilisateurs, l’utilisation de sous-
schémas est nécessaire pour garantir la confidentialité des données. Ainsi chaque utilisateur
n’accède qu’à une partie de la base de données. La confidentialité est assurée au moyen de
mots de passe et de privilèges attribués aux utilisateurs.
 La sécurité de fonctionnement :
Doit être assurée en cas d’incident matériel et/ou logiciel. Tout SGBD doit disposer de
moyens (exemple : la journalisation) lui permettant la reprise après panne.

SGBD Utilisateur 1
Application 1

Utilisateur 2
Application 2

BD
Application 3 Utilisateur 3

Représentation simplifiée d’un système de bases de données Utilisateur 4

4
Module BDD : Introduction aux BDD Mme H.CHELLAKH

3.3 Les niveaux d’une architecture de BD :

Dans une architecture de base de données, on distingue généralement trois niveaux qui sont :
 Le niveau externe :
C’est le niveau où les utilisateurs voient les données, il est appelé aussi niveau utilisateur.
 Le niveau physique :
Ce niveau est relatif à la mémoire physique (disque dur par exemple), il s’agit du niveau où
les données sont stockées, appelé aussi niveau interne.
 Le niveau conceptuel :
C’est le niveau intermédiaire entre les deux précédents, appelé aussi niveau logique.
Il existe plusieurs vues externes, chacune spécifique à un utilisateur particulier. Par
contre, il existe une seule vue conceptuelle qui donne la représentation abstraite de la totalité
de la base de données et une seule vue interne représentant la totalité de la base de données
telle qu’elle est enregistrée en mémoire.

Niveau
Vue Vue Vue
Externe
externe 1 externe 2 externe n
.....

Niveau
Logique Vue conceptuelle

Niveau Vue physique

Physique

Les trois niveaux d’une architecture de Base de données

3.4 Modèles de représentation de données :
La classification des SGBD est faite selon le type de modèle de représentation de
données qu’ils supportent. Celui des systèmes de type CODASYL comporte les concepts de :

 Attribut (data item)

 Type d’enregistrement (record type)
 Lien fonctionnel (set type) entre deux types d’enregistrements différents. Un des
types d’enregistrement est dit owner (propriétaire) du set et l’autre est dit member
(membre)

5
Module BDD : Introduction aux BDD Mme H.CHELLAKH

- Matricule
Etudiant - Nom
- Prénom
- Adresse

Est inscrit

- Cod-mod
Module - Libellé-mod
- Coeff

Exemple de structure CODASYL

Un type de set exprime une liaison père-fils entre deux types record
Les SGBD CODASYL supportent deux types de modèles : le modèle hiérarchique et
le modèle réseau.
 Le modèle hiérarchique :
Les SGBD hiérarchique gèrent des schémas dans lesquels un type de record peut être
propriétaire de plusieurs types de sets mais il ne peut être membre que d’un seul type de set. Il
permet de représenter les entités (classes) et des relations de type « père-fils » entre ces
classes, ce qui génère une représentation sous forme arborescence de ces entités. Les SGBD
de type hiérarchique gèrent les liens « père-fils », ils offrent des primitives pour naviguer dans
de telles structures
- Matricule
- Nom
Etudiant - Prénom
- Adresse

Est inscrit

- Cod-filière
Filière - Libellé-filière

Comporte

- Cod-mod
Module
- Libellé-mod
 Le modèle réseau :

Dans un schéma réseau, un type record peut être propriétaire de plusieurs types de
sets, et peut être membre de plusieurs types de sets.

Il permet aussi la représentation de classe et de liens de type « père-fils » entre ces

classes. En plus, il autorise à une classe « fille » d’avoir plusieurs classes « mères ». Comme
le modèle hiérarchique, les SGBD réseau sont aussi de type navigationnel.

6
Module BDD : Introduction aux BDD Mme H.CHELLAKH

Exemple :

- Num-ens - Cod-mod
- - Nom-ens - Libellé-mod
Enseignant Module
- Prénom-ens - Coeff

- Jour
- Heure
Emploi du
- Local
temps

Au-delà des SGBD CODASYL, existent les SGBD relationnels et les SGBD objets.
 Le modèle relationnel :
Il permet de voir une base de données comme un ensemble de tables, il est doté d’une
algèbre relationnelle. Les langages relationnels de manipulation de données se caractérisent
par leur nature déclarative.
Contrairement aux SGBD réseau ou hiérarchique, les SGBD relationnels (SGBDR)
offrent un langage de manipulation de données standard (SQL fondé sur l’algèbre
relationnelle).
 Le modèle orienté objet :
Permet de voir une base de données comme un ensemble de classes d’objets, ayant des
liens d’héritage, d’agrégation, de composition ou de simple association entre elles.

Moyen de transport

Représentation de l’héritage

Voiture Avion Bus Train

Représente le lien d’agrégation

1 4
Moteur Roue

Dans chacune des classes représentées, il faudra spécifier les attributs et les méthodes
correspondantes.

7
Module BDD : Introduction aux BDD Mme H.CHELLAKH

3.5 Objectifs des SGBD

1. Indépendance physique :
Un des objectifs essentiels des SGBD est de permettre de réaliser l’indépendance des
structures de stockage aux structures de données du monde réel, c.a.d entre le schéma interne
et le schéma conceptuel. Ces deux schémas décrivent les mêmes données, mais à des niveaux
différents. Il s’agit donc de pouvoir modifier le schéma interne sans avoir à modifier le
schéma conceptuel, en tenant compte seulement des critères de performance et de flexibilité
d’accès. On pourra par exemple ajouter un index, regrouper deux fichiers en un, changer
l’ordre ou le codage des données dans un article, sans mettre en cause les entités et
associations définies au niveau conceptuel.
2. Indépendance logique :
L’indépendance logique est la possibilité de modifier un schéma externe sans modifier le
schéma conceptuel. Elle assure aussi l’indépendance entre les différents utilisateurs, chacun
percevant une partie de la base via son schéma externe, selon une structuration voire un
modèle particulier. Les avantages de l’indépendance logique sont les suivants :
 Permettre à chaque groupe de travail de voir les données comme il le souhaite ;
 Permettre l’évolution de la vue d’un groupe de travail (d’un schéma externe) sans
remettre en cause, le schéma conceptuel de l’entreprise ;
 Permettre l’évolution d’un schéma externe sans remettre en cause les autres schémas
externes.
En résumé, il doit être possible d’ajouter des attributs, d’en supprimer d’autres, d’ajouter
ou de supprimer des associations, d’ajouter ou de supprimer des entités, etc., dans des
schémas externes mais aussi dans le schéma conceptuel sans modifier la plus grande partie
des applications.
3. Manipulation des données par des langages non procéduraux :
Les utilisateurs, parfois non professionnels de l’informatique, doivent pouvoir
manipuler simplement les données, c.a.d les interroger et les mettre à jour sans préciser les
algorithmes d’accès. Plus généralement, si les objectifs d’indépendance sont atteints, les
utilisateurs voient les données indépendamment de leur implantation en machine. De ce fait,
ils doivent pouvoir manipuler les données au moyen de langages non procéduraux, c.a.d en
décrivant les données qu’ils souhaitent retrouver (ou les mettre à jour) qui est propre à la
machine.
4. 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.
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. Ces 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.
5. 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

8
Module BDD : Introduction aux BDD Mme H.CHELLAKH

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 bon 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 communication de contextes.
6. Redondance contrôlée 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. 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.
7. Cohérence des données :
Bien que les redondances anarchiques entre données soient évitées, 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ées élémentaire doit respecter un format et ne peut souvent prendre une
valeur quelconque. Par exemple, un salaire mensuel doit être supérieur au SMIG et doit
raisonnablement rester inférieur à un seuil. Un SGBD 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é.
8. partage des données :
L’objectif est 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 cours 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 de transactions.
9. Sécurité des données :
Cet objectif a deux aspects. Tout d’abord, 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

9
Module BDD : Introduction aux BDD Mme H.CHELLAKH

autoriser, contrôler ou enlever les droits d’accès de n’importe quel usager à tout ensemble de
données. D’un autre côté, la sécurité des données doit aussi être assurée en cas de panne d’un
programme ou d’un système, voire de la machine. Un bon SGBD doit être capable de
restaurer des données cohérentes après une panne disque, à partir de sauvegardes précédentes.
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, le SGBD doit assurer l’intégrité de la base et par suite défaire la transaction qui a
échoué. Une transaction doit ê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.

10