Les bases de données/Le vocabulaire de base des BDD

Un livre de Wikilivres.
Sauter à la navigation Sauter à la recherche

Pour faire simple, la gestion des données mémorisées sur un support quelconque (disque dur, DVD, CD-ROM, …) demande de gérer deux choses bien différentes : le stockage des données et leur manipulation. Pour commencer, nous allons nous intéresser au stockage des données, comment celles-ci sont organisées pour être mémorisées durablement. Les concepts que nous allons voir dans cette page sont les bases de ce cours et les connaitre est très important. La plupart des termes que nous allons voir forment le vocabulaire minimal qu'il faut savoir pour aborder ce domaine.

Tables, enregistrements et attributs[modifier | modifier le wikicode]

Que ce soit dans un fichier ou dans une base de données, les données à mémoriser sont ce qu'on appelle des enregistrements. Ces enregistrements mémorisent toutes les informations liées à un objet, une personne, une entité, une chose. Prenons le cas d'une entreprise qui veut mémoriser la liste des commandes qu'elle a passé à ses fournisseurs : chaque commande sera mémorisée dans l'ordinateur dans un enregistrement, qui contiendra toutes les informations liées à la commande. Prenons maintenant l'exemple d'un établissement scolaire qui veut mémoriser la liste de ses élèves : chaque élève sera mémorisé par un enregistrement, qui contiendra toutes les informations sur l'élève en question. Et enfin, prenons comme dernier exemple un biologiste qui veut établir la liste de toutes les espèces animales découvertes à ce jour : chaque espèce découverte se verra attribuer un enregistrement, qui contiendra toutes les informations sur l'espèce.

Les enregistrements sont des équivalents des structures dans les langages de programmation comme le C ou le C++.

Enregistrements et attributs[modifier | modifier le wikicode]

Comme les exemples plus haut vous l'ont certainement fait remarquer, chaque entité, chaque enregistrement, est décrite par plusieurs informations : on a souvent besoin de mémoriser plusieurs informations distinctes pour chaque enregistrement.

Par exemple, une entreprise aura besoin de stocker, pour chaque client :

  • son nom ;
  • son prénom ;
  • son adresse ;
  • ses commandes en cours ;
  • etc.

Comme autre exemple, un établissement scolaire devra mémoriser pour chaque élève :

  • son nom ;
  • son prénom ;
  • son adresse ;
  • son âge ;
  • sa classe ;
  • sa filière d'étude ;
  • etc.

Comme dernier exemple, un garage aura besoin de mémoriser, pour chaque voiture :

  • son numéro d'immatriculation ;
  • sa marque ;
  • son modèle ;
  • etc.

Toutes ces informations sont des informations distinctes, mais qui appartiennent à la même personne, au même objet, à la même entité : on doit les regrouper dans un seul enregistrement. Pour cela, chaque enregistrement est un regroupement d'attributs, chaque attribut étant une information élémentaire, qui ne peut pas être décomposée en informations plus simples. Ces attributs sont équivalents aux variables des langages de programmation. Définir un enregistrement, c'est simplement définir l'ensemble des attributs qu'il contient : il faut préciser son type et sa valeur. Mais il faudra aussi lui donner un nom, pour pouvoir le récupérer.

Type d'un attribut[modifier | modifier le wikicode]

Ces attributs peuvent prendre des valeurs bien précises, définies à l'avance : les valeurs que peuvent prendre chaque attribut sont déterminés par ce qu'on appelle le type de l'attribut. Les types autorisés par les systèmes de gestion de données sont ceux couramment utilisés en informatique, à savoir : les nombres entiers et à virgule, les caractères et autres formes de texte, les booléens, etc.

Reprenons les exemples vus plus haut, pour voir quel est le type adéquat pour mémoriser chaque attribut. Pour l'exemple d'une entreprise qui a besoin de mémoriser la liste de ses clients, voici le type de chaque attribut :

  • son nom : chaine de caractère ;
  • son prénom : chaine de caractère ;
  • son adresse : chaine de caractère ;
  • le numéro de la commande : nombre entier ;
  • .

Prenons maintenant l'exemple d'une infirmerie scolaire qui veut mémoriser des informations médicales obtenues lors des visites médicales. Celui-ci doit mémoriser, pour chaque élève :

  • son nom : chaine de caractère ;
  • son prénom : chaine de caractère ;
  • son numéro de sécurité sociale : nombre entier ;
  • son adresse : chaine de caractère ;
  • sa taille : nombre à virgule ;
  • son poids : nombre à virgule ;
  • son âge : nombre entier ;
  • son groupe sanguin : chaine caractère ;
  • son groupe rhésus : booléen ;
  • sa tension artérielle : nombre à virgule ;
  • etc.

Comme l'exemple de l'établissement scolaire qui doit mémoriser pour chaque élève :

  • son nom : chaine de caractère ;
  • son prénom : chaine de caractère ;
  • son adresse : chaine de caractère ;
  • son âge : nombre entier ;
  • sa classe : chaine de caractère ;
  • sa filière d'étude : chaine de caractère ;
  • etc.

Comme dernier exemple, un garage aura besoin de mémoriser, pour chaque voiture :

  • son numéro d'immatriculation : chaine caractère ;
  • sa marque : chaine caractère ;
  • son modèle : chaine caractère ;
  • etc.

Valeur NULL[modifier | modifier le wikicode]

Dans certains cas, il arrive que certaines informations ne soient pas connues lorsqu'on crée l'enregistrement. Par exemple, quand un élève rentre dans une école, on peut très bien ne pas connaitre son établissement de l'année précédente. Et des cas similaires sont légions : soit l'information est inconnue, soit elle n'existe pas. On doit alors remplir l'attribut correspondant par une valeur qui indique que l'attribut a une valeur inconnue, que l'attribut n'a pas été rempli. Cette valeur est appelée la valeur NULL.

Par exemple, l'exemple suivant, qui correspond aux informations d'une personne, est parfaitement possible :

  • nom de famille : Braguier ;
  • premier prénom : Jean-Paul ;
  • second prénom : NULL ;
  • troisième prénom : NULL ;
  • etc.

Modèles relationnel et de fichiers[modifier | modifier le wikicode]

D'ordinaire, les entreprises et autres utilisateurs ont besoin de mémoriser de grandes quantités d'informations basées sur un même moule. Par exemple, les informations à mémoriser pour chaque élève d'un établissement scolaire seront identiques : tous les élèves ont un âge, un nom, un prénom, etc. Dans une liste de commandes passées par des clients, toutes les commandes sont définies par les mêmes informations : quel est le client, le produit commandé, la quantité à fournir, etc. En clair, tous les enregistrements d'une même liste ont des attributs semblables : ils ont le même type, le même nom et la même signification, seul leur valeur change. Elles ont besoin de mémoriser des listes d'enregistrements. Généralement, les informations sont classées dans plusieurs listes, par souci de simplification. Par exemple, si on prend le cas d'une librairie, celle-ci rangera les informations liées aux commandes de livres dans une liste séparée des informations sur les clients, et ainsi de suite : on aura une liste de client, une liste de commande de livre, une liste pour les livres en rayon, etc.

Les modèles de données[modifier | modifier le wikicode]

Illustration du stockage par fichiers.

Dans les cas les plus simples, on peut mémoriser chaque liste dans un fichier : les enregistrements y sont placés les uns à la suite des autres. Mais l'utilisation de fichiers a un défaut : le traitement de fichiers doit être programmé de zéro. En effet, les langages de programmation ne permettent que de récupérer les informations d'un fichier unes par unes, ou d'en ajouter à la fin du fichier, mais sans plus : on ne peut pas dire au langage de programmation qu'on ne veut récupérer que les données qui respectent une certaine condition, ni fusionner le contenu de deux fichiers, etc. Un autre défaut est que ce modèle ne permet pas de représenter les relations entre listes d'enregistrements. Et ces relations peuvent être très importantes pour interpréter les données ou permettre de les manipuler efficacement. Le modèle à base de fichier se contente de placer chaque liste dans un fichier, le programme devant connaitre de lui-même les relations entre données. D'autres systèmes de gestion des données permettent cependant de représenter ces liens avec une grande efficacité.

Modèle de stockage par fichier.

Pour pouvoir faire cela nativement, sans avoir à programmer un morceau de programme qui le fasse à notre place, on peut utiliser ce qu'on appelle des bases de données. Ces bases de données sont en quelque sorte des fichiers, mais qui sont gérées par un logiciel qui fait le café : ces logiciels sont appelés des systèmes de gestion de base de données, ou SGBD. Avec ces SGBD, le rangement des informations dans un fichier n'est pas spécifié par le programmeur : le SGBD s'occupe de gérer tout ce qui a rapport avec la manière dont les données sont rangées sur le disque dur. En plus, les bases de données effectuent automatiquement des opérations assez puissantes et peuvent faire autre chose que lire les informations unes par unes dans un fichier, les modifier, ou y ajouter des informations : on peut décider de récupérer les données qui respectent une certaine condition, de fusionner des données, etc. Mais leur intérêt principal est de modéliser les relations entre chaque liste d'enregistrement efficacement, d'une manière qui permet de traiter les données rapidement.

Ces bases de données utilisent des méthodes assez distinctes pour représenter les relations entre informations, méthodes qui permettent de distinguer les BDD arborescentes, en réseau, relationnelles, déductives et orientées-objet. Les plus simples sont de loin les BDD en réseau et arborescentes. Celles-ci codent les relations entre listes par des pointeurs, chaque enregistrement pouvant faire référence à un autre, situé dans une autre liste. La différence entre BDD en réseau et arborescentes tient dans le fait que certaines relations sont interdites dans les BDD arborescentes, qui ont une forme d'arbre (non-binaire, le plus souvent). Le modèle relationnel sera vu plus loin : c'est lui que nous étudierons dans ce cours. Le fait est que toutes les BDDs actuelles utilisent le modèle relationnel. Les modèles orientés-objet et déductifs sont plus difficiles à décrire, du moins pour qui ne sait pas ce que sont les langages de programmation orientés-objet ou logiques.

BDD à pointeurs
Modèle de stockage hiérarchique. Modèle de stockage en réseau.
BDD sans pointeurs
Modèle de stockage orienté-objet. Modèle de stockage relationnel.

Le modèle relationnel[modifier | modifier le wikicode]

Une base de donnée relationnelle permet de gérer des listes de données, qui sont appelées des tables, sont organisées en lignes et en colonnes. Chaque ligne mémorise un enregistrement, la succession des lignes permettant de mémoriser plusieurs enregistrements les uns à la suite des autres, en liste. Comme dit plus haut, les enregistrements d'une liste ont des attributs de même nom et de même type, seul leur valeur changeant : les attributs de même nom et type sont placés sur une même colonne, par simplicité. Évidemment, tous les enregistrements d'une table ont exactement les mêmes attributs, ce qui fait que toutes les lignes d'une table ont le même nombre de colonnes.

Exemple de table simplifiée qui mémorise une liste de personnes
Nom Prénom Age Ville
Dupont Jean 25 Lille
Marais Sophie 45 Paris
Dupond Mathieu 35 Paris
Salomé Saphia 24 Lyon
Queneau Raymond 53 Marseille
Tepes Vlad 29 Lille

Il existe un vocabulaire assez précis pour nommer les enregistrements, colonnes et autres particularités d'une table. Ceux-ci sont illustrés dans les deux schémas ci-dessous.

Figure structure relationnelle.

Une formulation équivalente à la précédente utilise les termes suivants :

Table relationnel

Évidemment, ces tables ne serviraient strictement à rien si on ne pouvait pas récupérer leur contenu : on peut récupérer une ligne dans la table sans que cela pose problème. On peut aussi ajouter des lignes dans une table, ainsi qu'en supprimer : si on prend l'exemple d'une liste de commandes tenue par une entreprise, on peut ajouter des commandes quand un client passe un contrat, ou en supprimer une fois la commande honorée. Et enfin, on peut modifier certaines lignes, quand celles-ci contiennent des données erronées ou dont la valeur a changé : si on prend une liste d'employé d'une entreprise, on peut vouloir changer le nom d'une employée suite à un mariage, par exemple. Ainsi, gérer des données dans une table demande de pouvoir faire quatre opérations de base :

  • CREATE (créer) : créer une nouvelle ligne ;
  • READ (lecture) : récupérer une ligne dans la table ;
  • UPDATE (modifier) : modifier le contenu d'une ligne ou d'un attribut ;
  • DELETE (supprimer) : supprimer une ligne devenue inutile.

Ces quatre opérations sont regroupées sous l'acronyme CRUD.

Remarque de fin[modifier | modifier le wikicode]

Il est évident qu'il vaut mieux éviter de mémoriser des informations inutiles dans une base de données. Par données inutiles, on veut dire : données qui peuvent se déduire à partir des données déjà présentes dans l'enregistrement. Par exemple, le prix d'une commande client peut se déduire à partir du prix unitaire d'un produit et des quantités commandées. Dans ces conditions, mieux vaut éviter de mémoriser ces données facilement déductibles : le programme qui manipulera les informations de la base de donnée les calculera lui-même, ce qui est très rapide (plus que de lire les données depuis une BDD ou un fichier). Une fois cela fait, les données de la table forment un ensemble minimal de données. Mais toutes n'ont pas le même poids, le même intérêt.

Conclusion[modifier | modifier le wikicode]

Ce chapitre s'est limité au vocabulaire de base, le vocabulaire des bases de données étant assez important. Pour vous en rendre compte, vous pouvez avoir une petite idée des termes du domaine en allant en voir la liste, disponible sur wiktionnaire, via ce lien :

Une partie des termes de cette liste seront vus dans les chapitres suivants.