SI et bases de données

La thématique des données persistantes est une thématique technique du domaine
informatique. Historiquement, en adressant le problème de la conservation et de la
gestion des données, elle a toutefois fortement impacté la mise en œuvre des Systèmes
d’Information, qui sont pour leur part clairement ancrés dans les problématiques
entreprises.
Schématiquement, une information est une donnée que l’on sait interpréter. 13.25 est une
donnée, mais si vous savez que c’est le prix d’un paquet de nouilles exprimé en euros,
alors cela devient une information.
Dans la société dans laquelle nous vivons, un enjeu majeur est d’extraire des
connaissances à partir de données. Une connaissance est la capacité de dire si le prix de
13.25 est cher ou non. L’objectif de cette acquisition de connaissance est évidemment la
prise de décision : j’achète ou non ce paquet de nouilles.
On comprend mieux, dès lors, l’intérêt de la conservation et de la gestion des données
pour les SI des entreprises.
Revenons à la technique : une donnée est persistante quand elle « survit » au programme
qui l’a créée. La fonctionnalité de sauvegarde offerte par la plupart des logiciels (tableurs,
traitements de texte, etc.) permet de rendre des données persistantes, en se basant sur les
facilités offertes par le Système de Gestion de Fichier (SGF) du système d’exploitation
(OS pour Operating System).
Dans les outils associées à la persistance, il existe toutefois des systèmes plus complexes
que les SGF, mais aussi plus riches, les Systèmes de Gestion de Bases de Données
(SGBD). Dans ce support, nous nous consacrerons à une famille de SGBD très répandus
sur le marché et qui implantent un même modèle, c’est-à-dire une même façon de
représenter les données, le modèle relationnel.
1

Avant de suivre ce cours, vous avez participé à une petite classe abordant le problème de
la structuration des données.
Dans cette petite classe, vous manipuliez des informations concernant des employés
travaillant dans des départements, y exerçant un emploi et étant encadrés par un manager,
lui-même employé.
Cet exercice, qui n’utilisait qu’un tableur, a permis de montrer que, outre la seule
persistance des données, d’autres difficultés pouvaient être liées à la manipulation de
données. En particulier, une structuration inadéquate des données pouvait suivant les cas :
- être source de redondance, c’est-à-dire de répétition inutile d’information. Cette
redondance pouvant à son tour entrainer des incohérences lors de mise à jour, si on ne
modifie pas l’information redondante partout où elle est présente ;
- être contradictoire avec les hypothèses, et ne pas permettre de représenter une
information correcte ;
- avoir une incidence sur le nombre d’opérations nécessaire pour chercher une
information ou pour les mettre à jour.
Dans cette présentation d’introduction, nous allons essayer de caractériser un SGBD
relationnel et, à partir d’un exemple, de donner quelques généralités sur le langage SQL,
langage standardisé, qui permet d’interroger une base de données relationnelle.
2

3
Sur ce schéma, j’ai représenté une minuscule base de données relationnelle, composée
d’un seul tableau, que nous appellerons « relation » parce que ce tableau met en relation
des valeurs. Chaque colonne (appelée attribut dans le modèle relationnel) a un nom. Par
exemple, la première ligne du tableau (une ligne est appelée tuple dans le modèle
relationnel) indique que la valeur FIG INF304 (qui identifie un cours) est en relation avec
« Systèmes d’information et bases de données » (attribut titre), que c’est un cours du
domaine informatique (attribut domain), et qu’il est coordonné par l’enseignant identifié
par le numéro 327. C’est bien la mise en relation de ces valeurs au sein d’un même tuple
qui fournit de l’information. Imaginez les 4 attributs de cette relation éparpillés entre 4
relations composées chacune d’un seul attribut, on ne pourrait plus tirer aucune
information des données stockées…
On peut voir un SGBD comme un logiciel qui « encapsule » les données et offre un
moyen de « gérer » ces données. Dans les SGBD relationnels, cette gestion se fait grâce à
un langage, le langage SQL, qui a fait l’objet de plusieurs standardisations depuis 1986.
Ce langage SQL permet aussi bien :
- d’interroger les données (voir la requête Select) ou de les modifier (voir requête insert)
grâce à son LMD (Langage de Manipulation de Données)
- d’administrer les données, grâce à son LDD (Langage de Définition de Données) (voir
requêtes sur la gestion des droits)
- d’accéder à la base à partir d’un programme, grâce à ses interfaces programmatiques ou
autres langages associés (non présentés ici).

Donc, un SGBD n’est pas seulement un système de stockage ou de sauvegarde, puisqu’il
doit aussi offrir des services de recherche, de modification et, au-delà, de gestion des
données (définition des structures, autorisations, etc.).
L’objectif d’un SGBD est de permettre à différents utilisateurs de partager leurs
données en un ensemble de données logiquement cohérent sous réserve d’une certaine
qualité de service, en particulier :
- Qualité de service en interrogation : performance et pertinence du résultat
- Qualité en mise à jour : maintien de l’intégrité, même dans un environnement d’accès
concurrents
- Qualité en administration : gestion des structures, des droits d’autorisation
Il est nécessaire de mettre en œuvre des solutions particulières car les solutions de
stockage classique, qui permettent de rendre des données persistantes, ne permettent pas
de répondre aux exigences en terme de qualité (gestion des droits d’accès, interrogation
multi fichiers, par exemple)
4

Initialement créés dans un objectif de partage de données et de forts débits de mise à jour,
les SGBD ont vu leur utilisation largement banalisée au fur et à mesure que leur
utilisation devenait de plus en plus simple.
L’apparition de SGBD relationnels simples à installer et à administrer (MySQL en est
l’exemple typique), de langages facilitant le codage d’applications web à données
persistantes (PHP), de packages facilitant le déploiement cohérent d’un serveur SGBD et
d’un serveur Web ont permis à nombre d’utilisateurs de créer leur propre base, sans
qu’ils aient pour autant les contraintes de partage des premières applications.
A l’inverse, la gestion de données persistantes a rencontré de nouveaux challenges.
Certes, on n’utilise pas un SGBD relationnel pour stocker des données sur une carte SD,
mais les nouveaux supports de stockage viennent avec leurs contraintes propres et posent
eux-mêmes des problèmes de performance d’accès qui ne sont pas si éloignés des
problématiques anciennes de performances et d’accès.
Inversement, la montée en volume des données traitées par des systèmes comme Google,
Facebook, Amazon, etc. pose évidemment des difficultés qui ne peuvent pas être résolues
par les SGBD relationnels.
Enfin, Les entreprises mettent aujourd’hui l’accent sur la cohérence des décisions prises
par rapport aux informations de leur SI, ce qui pose le problème de l’utilisation des
données non plus dans les seuls processus opérationnels mais aussi les processus de
décision de l’entreprise.
5