Déjà plus de
1 million
d'inscrits !
Système de gestion de bases de données (SGBD)
Déjà plus de
1 million
d'inscrits !
Introduction :
L’objectif de ce chapitre est d’identifier les enjeux que représentent les bases de données informatisées et les besoins qui découlent de l’exploitation de ces bases.
Dans un premier temps dans ce cours, nous nous pencherons sur les besoins à l’origine des bases de données informatiques. Puis nous déroulerons un bref historique concernant les techniques employées pour leur mise en œuvre. Enfin, nous détaillerons en quoi consiste un système de gestion de base de données ainsi que les différents moyens d’interagir avec celui-ci.
Qu’attend-on des bases de données informatisées ?
Des attentes au niveau des données elles-mêmes
Le but de regrouper un ensemble d’informations dans une base de données est de pouvoir les retrouver facilement, en faisant appel à des critères de recherche.
Dans cette première sous-partie nous utiliserons l’exemple de données relatives aux recettes et adhérent·e·s d’un club de cuisine.
Le volume d’informations que les organisations sont amenées à brasser est toujours grandissant. Aussi, si l’on souhaite retrouver tous les adhérent·e·s de moins de trente ans dans cette base de données, celle-ci sera informatisée dans le but premier de limiter le temps des recherches.
Dans la base recensant des recettes de cuisine, certaines recettes sont enregistrées avec l’ingrédient « yaourt », d’autres avec « yogourt ». Ainsi, en cherchant les recettes à bases de « yaourt », on ne retrouvera pas celles enregistrées à base de « yogourt ».
Toujours dans notre base, on stocke le nom, le prénom, l’adresse de messagerie ainsi que l’ adresse, le code postal et la commune où habite chaque adhérent·e du club. Cette information « code postal +ville » va se trouver dupliquée dans la base autant de fois qu’il y a d’auteur·e·s de recette qui habitent la même commune.
C’est le rôle d’une base de données informatisée, que l’on aura conçue selon des règles précises, que de permettre d’éviter les incohérences et redondances.
Des attentes au niveau des performances
L’optimisation du temps pris par les opérations dans une base de données informatisée implique une réflexion sur l’architecture matérielle employée.
On identifie trois grands rôles (niveaux) dans un système d’informations :
Les architectures peuvent comporter plusieurs couches, généralement appelées « tiers » (ex. : 1-tier, 2-tiers, … n-tiers).
Le terme « tiers » est un anglicisme et un faux-ami signifiant en français « niveau », « couche » ou « étage ».
L’interaction client-serveur repose sur des échanges entre plusieurs programmes : l’un (le client) contacte l’autre (le serveur) et lui envoie des requêtes auxquelles ce dernier doit répondre.
Cette architecture, aujourd’hui un peu dépassée, impliquait l’installation des applications sur chacun des postes de travail. Cette répartition rendait la gestion du parc matériel assez lourde. Les données étaient alors à l’époque plutôt réparties dans des fichiers individuels (et non dans un SGBD, tel qu’étudié plus loin).
Architecture 1-tiers
Cette architecture nécessite l’installation sur chaque poste de l’IHM particulière aux traitements. Les traitements eux-mêmes et la gestion des données sont, quant à eux, assurés par un serveur qui peut se trouver sur un réseau différent de celui du client.
Architecture 2-tiers
Cette architecture nécessite l’installation sur chaque poste d’une application légère de visualisation, telle qu’un navigateur web par exemple. Les traitements et la gestion des données sont chacun assurés par un serveur différent.
Architecture 3-tiers
Cette architecture répartit les trois rôles sur des serveurs différents.
Architecture 4-tiers
Notons que le serveur de données peut lui-même faire l’objet d’une répartition : pour des besoins de performance ou de sécurité, les bases de données peuvent être dupliquées ou réparties techniquement sur plusieurs serveurs.
Nous avons identifié les attentes vis-à-vis des bases de données informatisées, étudions à présent comment celles-ci se sont développées au fil des années.
Plusieurs modèles de données
Le développement des bases de données a démarré à partir des années 1960, lorsque les ordinateurs se sont démocratisés et ont commencé à étendre, au-delà du calcul, leurs capacités à des traitements d’informations plus élaborées.
Plusieurs modèles de données ont émergé jusqu’à nos jours.
Modèle de données :
Un modèle de données définit la manière dont l’information est structurée dans la base de données. Il est une représentation, exploitable par l’informatique, d’informations du monde réel.
Le modèle hiérarchique
Dans le modèle hiérarchique, les éléments d’information sont reliés entre eux par une arborescence dans laquelle chacun d’eux n’est rattaché qu’à un seul possesseur.
La recherche d’une information est contrainte de suivre un parcours défini par un système de chaînage interne : à chaque étape du chaînage, un pointeur stocké avec la donnée indique où trouver la donnée suivante Pour accéder à une donnée, on part du niveau qui lui est supérieur et on parcourt séquentiellement, de proche en proche, grâce aux pointeurs, l’ensemble de ses entités filles, pour trouver la donnée cherchée.
Exemple d’informations du monde réel organisées selon un modèle hiérarchique : l’organisation du territoire français en communes/départements/régions
Le modèle hiérarchique a, entre autres projets, servi à la gestion des données relatives au projet Apollo de la NASA. Cependant, le monde réel n’est pas toujours organisé selon une hiérarchie rigoureuse au sein de laquelle les liaisons transversales ne sont pas toutes immédiates.
En effet, dans l’exemple du découpage du territoire français, pour récupérer la liste de tous les départements de France (approche transversale), il est nécessaire d’emprunter des liaisons transversales mais aussi verticales.
Il n’est pas possible de parcourir l’arbre de façon uniquement transversale : Seine-Maritime, Calavados, Côtes d’Armor puis Finistère, car Calvados et Finistère n’ont pas le même possesseur.
Le modèle réseau
Le modèle réseau lève certaines limitations du modèle hiérarchique, en particulier en autorisant des liens transversaux. Le système de chaînage interne, formant un graphe, s’en voit inévitablement, et malheureusement, plus compliqué. Une structure en graphe se substitue à la structure en arbre du modèle hiérarchique.
Pour mieux comprendre son principe voici l’exemple de deux usines : Usine A et Usine B produisent respectivement les engins Jeep A, Camion D et Char F pour l’une ; Jeep A et Avion G pour l’autre.
Si l’on traduit cette situation par un modèle hiérarchique, on obtient le résultat suivant.
Modèle hiérarchique appliqué à notre exemple
Avec l’utilisation du modèle hiérarchique, on constate un problème de redondance : Jeep A est renseignée deux fois.
Alors qu’avec l’utilisation d’un graphe structuré en modèle réseau, on obtient le résultat suivant.
Modèle réseau appliqué à notre exemple
Des données intermédiaires sont de nature technique et ne font donc pas partie des données issues du monde réel modélisé (ici identifiées 23000, 22501, 17000, etc…). Elles stockent divers pointeurs qui permettent d’établir des parcours chaînés entre les données.
La complexité de ce modèle s’accompagne d’une grande dépendance entre les données et les programmes qui les manipulent.
Le modèle relationnel
C’est en 1970 qu’a émergé le concept du modèle relationnel, proposé par l’informaticien britannique Edgar Frank Codd, alors directeur de recherche chez le constructeur IBM. Il faudra une dizaine d’années pour que l’idée débouche sur un produit abouti, nommé « Oracle », alors commercialisé par Relational Software. Il sera suivi plus tard par DB2, commercialisé par IBM.
Ce modèle a pour vocation première d’améliorer l’indépendance des données par rapport à leurs traitements : contrat qu’il remplit avec succès.
Il s’appuie sur des tableaux à deux dimensions nommés « relations ». Ceux-ci sont liés à d’autres relations (ou « tables ») par un mécanisme d’associations qui repose sur l’algèbre relationnelle. Ces associations définissent et précisent les liens entre les relations.
Les accès aux enregistrements ne reposent pas sur des pointeurs, tels que ceux utilisés dans les systèmes de chaînage évoqués dans les modèles précédents. Ils sont assurés par des clés primaires ou étrangères accessibles par des index.
L’index est une sorte de répertoire qui indique où trouver sur le disque l’enregistrement relatif à une clé donnée.
Par ailleurs, c’est grâce au processus de modélisation abordé dans les chapitres précédents que l’on parvient à définir les liaisons entre les tables.
Le modèle objet et relationnel-objet
Ces modèles intègrent la notion d’objet, c’est-à-dire celle employée par les langages de programmation orientée objet. Ce concept d’objet s’avère en particulier utile pour modéliser des informations complexes, comme par exemple celles de type multimédia.
Ces modèles sont encore en phase de réflexion et de recherche. Nous n’en développerons pas plus le principe ici.
Ces différents modèles ont été conçus pour traiter des données fortement structurées et finement catégorisées. Ils sont en revanche peu adaptés aux besoins croissants de stockage et de traitements, souvent en temps réel, de données massives. Ces mégadonnées (communément appelées "big data") sont alors gérées avec des SGDB de type NoSQL. Cette appellation NoSQL désigne collectivement une famille hétérogène de bases de données différentes du modèle relationnel : s’appuyant sur différents paradigmes (clés-valeurs, colonnes, documents, graphes, multi-modèles, etc.), ces SGBD NoSQL sont capables de traiter de très gros volumes de données possiblement hétérogènes.
Pour conclure sur cet inventaire, nous pouvons noter qu’il subsiste encore, en particulier dans le secteur bancaire, des bases de données hiérarchiques qui s’avèrent plus performantes pour la gestion de certaines informations que les bases de données relationnelles.
Mais retenons que le modèle relationnel est celui qui est le plus largement répandu de nos jours.
Il est temps maintenant de nous intéresser aux SGBD, systèmes qui permettent de mettre en œuvre un modèle de données.
Les missions d’un SGBD
Une base de données informatisée est un ensemble d’informations stockées sous forme de données sur un support numérique.
SGBD :
Un SGBD, sigle signifiant « Système de gestion de base de données », est un logiciel spécialisé pour manipuler des données stockées en base.
Parmi les SGBD relationnels les plus connus et utilisés, on peut citer :
Système d’informations :
Un système d’informations est l’ensemble constitué par la base de données, le SGBD et les programmes d’applications qui lui sont associés.
L’architecture ANSI/SPARC spécifie l’architecture d’un SGBD selon un découpage en trois niveaux.
Voyons un peu plus en détail ce qu’apporte chacun de ces niveaux.
Le niveau physique
Vous trouverez listées ci-dessous les différentes missions du niveau physique.
Notons que l’on peut mesurer la qualité des opérations de modifications d’un SGBD en vérifiant les propriétés ACID que voici.
Le niveau conceptuel
Le niveau conceptuel est indépendant du niveau physique.
Vous trouverez listées ci-dessous les différentes missions du niveau conceptuel.
Le niveau externe
Le niveau externe est indépendant du niveau conceptuel.
Vous trouverez listées ci-dessous les différentes missions du niveau externe.
Nous connaissons dorénavant les missions d’un SGBD. Mais comment l’utiliser ? C’est ce que nous allons voir maintenant, en recensant les différents moyens d’interagir avec lui.
Modes d’interaction avec un SGBD
Pour agir sur la base de données, que ce soit dans le but de la créer, de la mettre à jour ou de la consulter, il est nécessaire de solliciter le SGBD. Selon les situations et les utilisateur·rice·s, plusieurs moyens permettent d’interagir avec le SGBD. Quels sont-ils ?
La ligne de commande
À l’aide de l’application « Terminal » ou « Console » (sous Linux ou Unix) ou de l’« invite de commandes » (sous Windows), il est possible de solliciter le SGBD via des commandes entrées en mode texte, donc au clavier.
Ce mode d’interaction, assez rudimentaire et peu ergonomique, est plutôt employé par les informaticien·ne·s. Ces dernier·e·s formulent leurs commandes en ayant recours au LDD, LMD et LID.
L’intérêt de la ligne de commande est qu’elle exige peu de ressources, ce qui peut être utile dans certains cas de situations dégradées.
Sous Windows avec MySQL : connexion à la base de données « recettes » et commande pour obtenir la liste des tables de la base de données.
Le mode « ligne de commande » pour le SGBD MySQL
L’interface graphique
Les SGBD s’accompagnent d’une interface graphique d’administration. Une partie des instructions passées avec le LDD, le LMD ou le LID en ligne de commande y sont substituées par de simples clics. Notons qu’il est nécessaire de se connecter au SGBD au préalable afin que les données et les opérations proposées par l’interface ne soient que celles qui sont autorisées.
Par exemple, PhpMyAdmin est une interface d’administration très répandue de bases MySQL. Il en existe d’autres. PHPMyAdmin se présente sous la forme d’une application Web accessible via un navigateur. Dans l’exemple donné ci-dessous, un seul clic de souris dans l’interface PHPMyadmin suffit pour demander au SGBD la suppression de la table « auteur ».
L’interface graphique phpMyAdmin pour le SGBD MySQL
Les bibliothèques spécialisées
Les bibliothèques spécialisées sont les éléments de code qui permettent à des programmes de solliciter un SGBD, que ce soit pour lui adresser des instructions de consultation, modification, suppression de donnée ou plus encore, de modification de la structure de la base de données elle-même.
L’exemple ci-dessous est un programme écrit en PHP qui effectue la même opération que celle effectuée via l’interface PHPMyAdmin dans l’exemple précédent : la suppression de la table « auteur ».
Notons au passage que PHPMyAdmin n’est ni plus ni moins qu’une application PHP qui a été écrite en faisant appel aux bibliothèques spécialisées relatives au SGBD MySQL.
Conclusion :
Nous connaissons maintenant l’intérêt des bases de données informatisées ainsi que la richesse des SGBD. Il est temps d’apprendre à les exploiter. C’est ce que nous allons aborder dans les deux chapitres qui suivent. Nous y découvrirons SQL, et plus précisément les sous-ensembles LID et LMD de langage.