dans cette présentation d’introduction, nous allons...
TRANSCRIPT
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
Ce cours est consacré aux bases de données relationnelles, à savoir des données
formatées en relations (ou tableaux). C’est évidemment extrêmement réducteur.
De la même manière qu’on utilise pas un tableur pour écrire un rapport, ni un traitement
de texte pour stocker des données tabulaires, la structure des données que l’on veut traiter
a une influence majeure sur les fonctionnalités que doit offrir l’outil qui permet de les
gérer et de les manipuler. L’apparition, avec le web, des langages HTML et plus
globalement des données semi-structurées (voir grammaire XML) a posé le problème de
l’outil adapté au stockage et à la gestion de ce nouveau type de données. Des problèmes
de même nature vont se poser pour les différents types de données, qu’il s’agisse de
plans, d’images, etc.
Il est donc important, au-delà de la présentation du modèle relationnel faite dans ce cours,
de comprendre les problèmes que ce modèle a l’ambition de résoudre, et ceux qu’il ne
prétend pas résoudre, mais pour lesquels des démarches similaires peuvent être
développées.
6
Pendant de nombreuses années, la modélisation des données de l’entreprise était la base
du système d’information. Les applications n’étaient envisagées que par rapport à cette
représentation des données : enchainements d’écrans statiques.
Les choses ont radicalement changé au fur et à mesure que les SGBD se sont fiabilisés et
banalisés.
Le monde du logiciel a mis en avant les besoins fonctionnels des utilisateurs par rapport
aux données ainsi qu’une vision système (montée en puissance d’UML, développement
des architectures techniques, etc.).
Plus récemment encore, les processus métier viennent structurer et mettre de la cohérence
dans le SI.
Dans ce contexte, les SGBD restent un élément fondamental du système informatique,
car ils restent souvent la « mémoire » de l’entreprise (son catalogue, ses fiches clients,
etc.). Mais leur gestion et leur évolution ne peut se faire de manière indépendante des
applications qui les manipulent. Cette cohérence entre le monde du stockage des données
(largement dominé par le paradigme relationnel) et celui de l’application (en cours de
domination par le paradigme objet) reste un aspect complexe à gérer.
7
Les quatre première étapes sont extrêmement classiques et doivent permettre aux
étudiants de savoir créer et utiliser une base de données relationnelle simple.
La montée en complexité consistera à changer de contexte et à imaginer une base de
données d’abord plus complexe, puis utilisée par une multitude d’applicatifs variés. Cela
imposera tout d’abord de revoir les modèles utilisés en étape de structuration des
données, et d’examiner l’impact de cette complexité sur le développement d’application.
A ce sujet, nous découvrirons un framework, appelé Hibernate, très utilisé dans
l’industrie, qui vise à combiner harmonieusement l’approche objet (on parle de
paradigme objet) utilisée en programmation et l’approche relationnelle utilisée pour la
gestion de données persistantes.
8
On passe au deuxième item
9
10
Sur ce transparent, on présente un exemple simple de schéma relationnel constitué ici de
trois relations : Les informations des relations Personnes et Vins peuvent elles-mêmes
être mises en relation au moyen d’une relation production qui précise quelle personne
(identifée par son attribut Id, renommée en np, pour numéro de personne) produit quel
vin (identifié par son attribut nv, pour numéro de vin).
Pour des raisons de place, on a réduit les relations au minimum mais on aurait pu avoir
davantage d’attributs ou de tuples dans chacune des relations.
Par le terme de relation, on désigne tantôt la structure des relations, ce qu’on appelle le
schéma de la relation, mais aussi son instance, c’est-à-dire les données qui peuplent ce
schéma. Ici, les trois tuples qui peuplent la relation Personnes constitue une instance de
Personnes.
Cet exemple illustre également une caractéristique importante du modèle relationnel.
Pour rapprocher les informations concernant les vins et les personnes, on doit comparer
les valeurs des champs id de Personnes et np de Production, ou nv de production et nv de
vins. On dit que le modèle relationnel est un modèle par valeur. Les modèles par valeur
s’opposent aux modèles antérieurs, dits navigationnels (SGBD hiérarchiques et réseaux),
qui nécessitaient de « suivre des liens » pour passer d’une entité à une autre. Ici, il n’y a
pas de lien prédéfinis mais juste des comparaison de valeurs. Alors que les liens des
modèles navigationnels étaient dirigés, la comparaison de valeur n’impose aucun sens, on
peut au choix aller de la relation Production à la relation Personnes ou l’inverse.
11
Sur la base de l’exemple précédent, on exprime ici une requête en français et sa
traduction en SQL. ATTENTION, on prend ici volontairement la syntaxe originelle
de SQL. Une syntaxe plus récente et légèrement différente sera vue dans les TD et
TP SQL.
On voit sur la requête les trois relations utilisées (clause FROM), les comparaisons de
valeur derrière la clause WHERE, et la structure du résultat recherché derrière la clause
SELECT.
Au-delà de sa syntaxe, une des caractéristiques intéressante de SQL réside dans les deux
façons d’interpréter les requêtes exprimées à l’aide de ce langage.
La première sémantique est logique. On lit la requête de la manière suivante : on cherche
s’il existe (au moins) un tuple de personnes, un tuple de production et un tuple de vins tel
que l’id de ce tuple de personne soit égal au np de ce tuple de production, et qu’on ait
aussi égalité entre les nv des deux tuples de production et de vins. La solution est donc
constituée des tuples qui vérifient la solution proposée. Cette sémantique ne dit rien de la
manière de trouver ces tuples.
La deuxième sémantique est procédurale. Elle consiste à expliquer comment trouver ces
tuples. Par exemple, dans notre cas, on peut procéder au produit cartésien des 3 relations,
puis appliquer les critères du where. Le résultat est sur le slide suivant.
12
Le produit cartésien a généré 3x5x4 tuples (=60). Mais seulement quelques-uns
respectent le critère de restriction (tuples surlignés). Les autres tuples ne nous intéressent
pas.
Au passage, on voit que cette solution nous amène à générer une relation très
volumineuse (le produit cartésien) puis à extraire un sous-ensemble des tuples qui nous
intéresse en comparant les valeurs de certaines colonnes sur chaque ligne.
Alors, première conclusion intuitive de ces deux façons de « lire » une même requête
SQL. On dit que SQL est un langage déclaratif parce qu’il permet de dire ce qu’on
cherche sans dire comment l’obtenir (sémantique logique). C’est une propriété
intéressante pour un utilisateur qui ne connait pas bien les données, qui n’est pas
nécessairement informaticien et n’a pas à réfléchir à la meilleure manière de procéder
pour « sortir » le résultat de sa requête.
Mais en même temps, le fait de pouvoir exprimer cette requête sous la forme d’un
enchainement d’opérations indique qu’il y a un mode opératoire naturel de cette requête,
lequel pourra éventuellement être optimisé automatiquement.
On touche ici à un point particulièrement intéressant des SGBD : leur volonté d’être
accessible au plus grand nombre, en déchargeant l’utilisateur de prendre en charge les
problèmes liés par exemple à la volumétrie des données.
Deuxième grande caractéristique de SQL, le langage est fermé, ce qui signifie qu’une
requête, qui prend en entrée des relations, rend en sortie… Une relation (ici la relation
constituée de deux attributs nom et cru). Cette propriété très intéressante permettra de
cacher à l’utilisateur une structure de données trop complexes (trop d’attributs) en
restructurant ses données sous une forme plus adaptée.
13
Vous pouvez à la suite de ce cours réaliser les PC et TP SQL.
Pour vous perfectionner sur les requêtes, vous pouvez également examiner le support
dédié aux requêtes avec agrégats et requêtes avec négation. Le support traitant de la
logique du premier ordre apporte également beaucoup d’information utile pour les
requêtes complexes.
Vous êtes également encouragés à enrichir le glossaire disponible sur moodle.
14