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
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). 3
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
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. 10
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. 11
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. 12
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