Initiation aux BDD

Un article de Mangue.org, l'encyclopéde libre.

Ce petit cours sans prétention n'a nullement pour objectif de faire de vous des experts en bases de données, mais plutôt de donner aux débutants (ou aux autres) une idée claire de ce que sont les bases de données et de ce que peut apporter leur utilisation.
Nous allons, autour d'un exemple, expliquer comment nous pourrions nous débrouiller sans bdd, (Bases De Données) puis voircomment nous aurions pu faire en les utilisant, tout en mettant en avant les avantages que cela comporte.

Problématique

La manipulation de données a toujours été le fort de l'informatique.La démocratisation de l'outil et la montée en puissance des ordinateurs a conduit à traiter des masses de données de plus en plus importantes, c'est pourquoi il a fallu se pencher sur des solutions simples d'utilisation et optimisées pour classer et stocker les données, afin de faciliter leur consultation et les recherches.Pour bien comprendre les problèmes qui se posent, nous allons prendre un petit exemple.
Considérons que sans base de données, nous serions contraints de stocker nos informations "à la main" dans des fichiers sur disque.Imaginons un disquaire qui souhaite informatiser la gestion de ses stocks et de ses clients, et qui souhaiterait par la même occasion être en mesure de calculer des statistiques sur ses ventes, afin de savoir par exemple quel genre de musique doit être le plus présent dans son magasin, ou de pouvoir adresser à une clientèle spécifique des offres promotionnelles.
On peut imaginer qu'il aura un fichier Clients, contenant à chacune de ses lignes les informations concernant un client, avec son nom, son prénom et ses coordonnées. S'il veut garder une trace de ses ventes, il créera un fichier Ventes, qui contiendra sur chaque ligne le nom du client, et la référence du disque acheté. Enfin, il aura un fichier Disques qui contiendra, pour chaque référence de disque, le style de musique qu'il contient, le nom de l'album et le nom de l'interprète.
Supposons maintenant qu'il veuille connaitre le nom des clients qui consomment en majorité du hard-rock pour leur faire profiter d'une offre spéciale. Voici ce qu'il devra faire:

ouvrir le fichier Ventes
tant que la fin du fichier Ventes n'est pas atteinte
  lire une ligne et en récupérer la référence du disque
  ouvrir le fichier Disques et trouver le disque correspondant à la référence
  si ce disque est un disque de hard-rock
    ouvrir le fichier Client et trouver le Client correspondant à la vente courante
    afficher les coordonnées de ce client
  fin si
fin tant que

Quand on connait la lenteur des opérations de lecture/écriture dans les fichiers sur disque, on peut s'imaginer que cette façon de procéder sera extrêmement lente. De plus, on s'aperçoit assez facilement que l'ajout de nouvelles fonctionnalités au programme sera extrêmement fastidieuse. En effet, si l'on veut implémenter une nouvelle recherche, (par exemple, récupérer les adresses des clients nés avant une certaine date) il faudra de nouveau écrire un algorithme de ce type, ce qui va très vite s'avérer long et ennuyeux. De même, les possibilités d'évolution sont limitées par la structure des données: dans la majorité des cas on devra, si l'on modifie la structure d'un fichier, réécrire toutes les fonctions qui l'utilisent.

Solution

Les bases de données représentent la solution à ces problèmes. Dans le fond, ça n'est qu'un façon différente d'organiser les données, de manière à faciliter les recherches.
Dans une bdd, les informations sont organisées en tables. Ces tables regroupent les informations relatives à un sujet particulier, un peu à la façon de ce qu'on pourrait faire avec un objet en programmation. Chaque information contenue dans une table est appelée un champ. On établit ensuite entre chacune de ces tables des relations en fonction de ce que l'on souhaite faire. Ces relations ne sont en fait pas physiquement établies, on décide plutôt que "tel champ de telle table contiendra le même numéro que tel champ de telle table si elles sont liées".Une fois les tables, champs et relations définies, nous avons la structure de la base de données.Eclaircissons un peu tout cela avec une illustration. Si nous reprenons l'exemple précédent, voici une base de données que l'on pourrait utiliser:

La table "Client" correspond à notre ancien fichier Client. Celle-ci peut contenir les nom, prénom, adresse et numéro de téléphone d'un client, mais nous aurions tout aussi bien pu y ajouter la date de naissance, ou quelque information que ce soit. Vous noterez que nous y avons adjoint un champ "id", qui est l'identifiant du client. Nous y reviendrons lorsque nous parlerons de la notion de clé primaire.
La table "Vente" correspond à notre ancien fichier Vente. Ici, au lieu de stocker le nom et le prénom du client, nous stockons son identifiant, ce qui permet de ne pas avoir de redondance d'information comme c'était le cas auparavant. De même, nous stockons l'identifiant du disque vendu, ainsi que la date de la transaction.
La table "Disque" correspond à notre ancien fichier Disque. En plus de son identifiant, elle contient le titre du disque et son interprète, ainsi que l'identifiant d'un genre.
La table "Genre" ne correspond à aucun ancien fichier. Elle sert à définir les styles de musique que nous associons aux disques. Cela permet une gestion des styles plus souples que si nous inscrivions directement le style dans la table Disque. En effet, si par exemple nous désirions changer le genre "Hard Rock" en "Nü Rock", il suffirait de changer cela dans la table Genre, plutôt que de parcourir la table Disque et d'effectuer le changement à chaque fois que nous rencontrons le style "Hard Rock".

Dans le précédent schéma, vous remarquerez que certains champs sont notés en gras. Ces champs sont les clés primaires de leur tables. Ces champs servent à identifier une occurence de table. (i.e un client en particulier par exemple pour la table Client)Une clé primaire sert à identifier à coup sûr une et une seule occurence de table. Elle est donc unique sur toutes les occurences de la table qu'elle concerne. Pour notre table client, cela permet par exemple de régler les problèmes d'homonymie: si on identifie un client par son nom, que se passe-t-il lorsqu'on a deux clients s'appelant "Roger Martin" ? Il est donc plus efficace d'attribuer un identifiant différent (un numéro) à chaque occurence de la table, afin d'être certains que chaque occurence possède un élément qui la différencie des autres.

Ces identifiants sont utilisés dans les autres tables lorsqu'on souhaite faire référence à une occurence de table. Par exemple, dans la table "Vente", le champ disque va contenir un identifiant de la table Disque. Plus concrètement, si nous avons dans ce champ le chiffre 12, nous saurons que cette vente concerne le disque portant comme identifiant le numéro 12. C'est ce qu'on appelle une clé étrangère. Vous l'aurez compris, dans la table Vente, le champ client est également une clé étrangère.

Avoir une base de données, c'est bien beau, mais encore faut-il pouvoir l'exploiter. C'est le rôle des SGBD (Système de Gestion de Bases de Données) ou SGBDR (Système de Gestion de Bases de Données Relationnelles). Ces systèmes, comme par exemple MySQL, Oracle, SQLServer ou encore PostGreSQL, permettent, chacun avec leurs petits plus, de gérer une base de données. Certains d'entre eux, par exemple, surveillent automatiquement l'intégrité référentielle de vos bases de données. Ce terme barbare désigne le fait que votre base est cohérente dans ses références entre tables. Par exemple, il sera impossible, avec un SGBDR qui surveille l'intégrité référentielle, de créer une occurence de la table Vente qui référencerait le disque d'identifiant 12 si aucune occurence de la table Disque portant cet identifiant n'existe. Ce petit aparté étant terminé, passons aux possibilités communes offertes par les SGBDR.
Premièrement, ces systèmes déchargent complètement l'utilisateur de la gestion de la base au niveau des fichiers: en général, on a affaire à un programme auquel on donne des commandes en langage SQL (nous y reviendrons) afin de créer les tables, et c'est le système qui se débrouille et s'organise lui-même avec les fichiers sur disque. On n'a donc plus du tout à s'en soucier. Il va de soi que toutes les phases de lecture et d'écriture sur ces fichiers ont été optimisées au maximum, afin de ne pas pâtir de la lenteur de ces opérations.
Deuxièmement, ils permettent la gestion complète des bases, avec ajout, modification et suppression de données, et surtout la possibilités d'effectuer des recherches, tout cela se faisant bien sûr très rapidement, grâce à des techniques telles que l'indexation, sur lesquelles nous ne nous attarderons pas.

Comme il existe moults SGBDR différents, on pourrait penser que chacun utilise son petit langage de commandes propriétaires, liant chaque base de données au SGBDR sur lequel elle a été créé. Heureusement, il n'en est rien, et chaque SGBDR comprend le langage SQL (Structured Query Language). Ce langage permet d'effectuer toutes les opérations possibles sur une base de données, de la création à la recherche. L'apprentissage de ce langage n'étant pas l'objet de ce cours, nous ne nous attarderons pas sur le sujet.

Pour résumer, voici une petite liste (non-exhaustive) des avantages liés à l'utilisation des bases de données:

• Plus besoin de gérer les fichiers contenant les données
• Elimination (si toutefois la base est bien pensée ;-)) de la redondance d'information
• Optimisation des opérations de lecture/écriture (gains de vitesse)
• Langage SQL très puissant permettant d'effectuer des recherches précises et rapides
• Accès de la base de données via un réseau (internet, par exemple)
• Possibilité de construire une interface pour administrer et consulter sa base à partir de nombreux langages
• Simplicité d'utilisation
• Evolutivité
• etc...