C’est quoi une base de données ? – Partie 3

Suite de : C’est quoi une base de données ? – Partie 2

J’ai beaucoup hésité avant de poursuivre ces articles sur les bases de données. Car depuis le début, j’ai abordé les bases de données en m’attardant sur l’organisation et le stockage des données. Maintenant, il s’offrait à moi 2 possibilités distinctes et plutôt opposées : soit continuer à introduire le concept des bases de données, tel que je l’ai commencé, c’est à dire en regardant les données et leur stockage, et en y ajoutant tout doucement tout les fonctionnalités et le vocabulaire que l’on peut y trouver, soit arrêter de parler théorie des bases et montrer des schémas sur le fonctionnement des bases de données mais sans parler des données proprement dit.   Je n’ai pas réussi à me décider, et du coup : je vous ai fait les 2. Vous trouverez ci-dessous la suite de ce qui est commencé, et ici : les schémas sur Comment ça marche une base de données ? Je pense qu’au final, les 2 approches sont très complémentaires.

Les relations entre les tables.

Dans la partie 2, nous avons vu des données stockées dans une seule table. Mais dans la « vraie vie », cela est très rare car on doit stocker bien plus d’informations. Ces informations sont en relations entre elles (ou pas) alors comment faire pour stocker tout cela sans que ce soit trop le bazar ?

Pour bien comprendre, prenons un exemple simple de logiciel de facturation qui doit gérer :

• les clients,
• les articles des factures,
• et les factures

Pour que tout cela reste clair, j’ai volontairement simplifié.

Comment faire pour stocker tout cela dans une table ou plusieurs tables ?

On comprend facilement qu’il faut au moins avoir une table client et une table article, voici ce qu’on pourrait avoir :

Table client :

 

code_client	Nom	Prénom	Adresse	Code postal	Ville
1	Durand	Michel	Rue des Mouettes	75016	Paris
2	Dupond	Karine	Avenue des Champs	92000	Courbevoie
3	Mensoif	Gérard	Impasse de la Bière	75001	Paris
etc …

Table article :

code_article	désignation	prix_unitaire
1	Orange	1,50 €
2	Fraise	4,00 €
3	Pomme	0,80 €
etc …

et maintenant, il faut stocker les factures qui sont composées d’un client et d’un ou plusieurs articles.

Le mauvais exemple

Si je suis un mauvais élève ou un mauvais informaticien, je vais faire simple et créer une table facture qui ressemblerait à ça si

• Karine achetait 1 Kg d’oranges et 2 Kg de pommes
• Gérard achetait 5 Kg de fraises et 1 Kg de pommes
• et enfin Karine rachetait 2Kg d’oranges

 

C’est vraiment très mauvais, et ce pour plusieurs raisons :

• A chaque facture, j’enregistre le nom et l’adresse complète du client :
  • beaucoup de données enregistrées pour rien : j’alourdis le stockage.
  • si mon client change d’adresse, je dois tout modifier.
• A chaque facture, j’enregistre l’article complet, là encore ça ne sert à rien.
  • si je modifie la désignation d’un article, là encore je dois tout modifier.
• Lorsque Gérard paiera sa facture, je serai obligé de rechercher tous les enregistrements de la table pour marquer que la facture est payée (ici, 2 enregistrements)

 

Ce qu’il faudrait faire :

Il faut optimiser tout cela, en essayant de réfléchir, on peut se dire que :

• une facture est réalisée pour un et un seul client.
• Certaines informations sont uniques pour la facture : la date de facture, le fait que la facture soit payée ou non.
• une facture est constituée de lignes. Ces lignes sont constituées d’un ou plusieurs articles.

Voila, nous commençons à modéliser les données, et cela pourrait nous donner les tables suivantes :

Table facture

num_facture	date_facture	payée	code_client
1	15/12/2016	oui	2
2	17/12/2016	non	3
3	23/12/2016	oui	2
etc …

La table facture ne contient que le nécessaire :

• le numéro de la facture,
• la date de la facture,
• l’état du règlement,
• et le client

On peut noter que l’index primaire de cette table est constitué du champ : « num_facture ». Car il ne peut y avoir qu’une seule facture avec le même numéro.

 

Table lignes_facture

Ici, c’est un peu plus compliqué, car cette table doit contenir le détail des lignes. Il peut y avoir 1 ou plusieurs lignes par facture. Voici ce que ça pourrait donner :

num_facture	num_ligne_facture	code_article	quantite
1	1	1	1
1	2	3	2
2	1	2	5
2	2	3	1
3	1	1	2
etc …

C’est pas très lisible. Mais c’est optimisé, voici pourquoi :

• le détail des articles n’est pas directement enregistré. Donc, si je change le libellé d’un article dans la table article, cela changera automatiquement dans mes factures.
• les données non utiles ne sont pas enregistrées (comme par exemple: la désignation de l’article qui est déjà dans la table article).

Notez bien l’index primaire de cette table : constitué de deux champs :

Num_facture;Num_ligne_Facture

Car avec cette combinaison, chaque enregistrement est bien unique. (Il ne peut pas y avoir 2 factures avec le même numéro, ni une facture avec 2 lignes ayant le même n° d’ordre).

 

Base de données relationnelle

Voila, dans cet exemple nous venons de créer des tables qui sont en relation entre elles. Notre base de données est dite : relationnelle.

Intégrité référentielle

Bien évidemment, il existe des règles entre ces tables. Comme par exemple il est impossible de supprimer un article (dans la table article) si celui-ci est utilisé pour une facture (dans la table lignes_facture) : on parle alors d’intégrité référentielle.

Trigger (ou déclencheur)

Un trigger est une fonctionnalité qui va déclencher une action lorsqu’un événement se produit sur les données d’une table (ajout, suppression, modification, …).

Reprenons nos exemples pour mieux comprendre :

Si nous avions une table « solde client ».

Nous pourrions très bien avoir un trigger sur la table « facture » qui lancerait le calcul du « solde client » lorsqu’une facture est créé ou modifiée.

 

La modélisation des bases de données relationnelles

Sur cet exemple, c’était simple. Mais vous comprendrez aisément qu’il n’est pas facile sur des centaines de tables de réaliser des relations et des optimisations. C’est pourquoi il existe des méthodes qui vont nous permettre de modéliser les bases de données, telles que :

• Merise
• UML
• …

Je ne vais pas m’étendre sur ces méthodes (vous pouvez trouver énormément d’articles sur ces sujets) mais il faut juste comprendre que ces méthodes vont permettre de poser simplement les relations entre les différentes entités (tables) et en déduire les différentes tables à créer.

Exemple : On va écrire les relations suivantes

• entre « facture » et « client » : Une facture ne peut contenir que 1 et 1 seul client et un client peut avoir 0 ou plusieurs factures,
• entre « article » et « facture » : une facture peut contenir 1 ou plusieurs articles et un article peut être utilisé 0 ou plusieurs fois dans une facture.
• …

Tout cela nous donnera des modèles qui permettront ensuite de générer les tables.  Dans l’exemple ci-dessus, la table « lignes_facture » est créée automatiquement par la relation : « 1 facture contient n lignes. »

 

Le NoSQL

Puisque je parle de modélisation des bases de données relationnelles, il faut parler un peu des bases NoSQL qui ne sont pas modélisées de la même façon. Dans le NoSQL, on ne cherche pas forcément les relations cartésienne (0,1), (1,1), (0,n) et (1,n) telles qu’on les retrouve dans les méthodes classiques des bases de données relationnelles. L’objectif n’est plus d’éviter la duplication des données, mais de stocker les données en fonction des requêtes que l’on va effectuer (en fonction des besoins) quitte à redonder l’information. Donc les bases de données NoSQL ne sont pas des bases de données relationnelles.

 

Je ne veux pas m’étendre plus sur les différents types de modélisation et de bases de données car il faut rester simple. Vous pouvez retrouver des tonnes d’informations sur Internet à ce sujet. J’espère simplement que ces notions vous paraîtrons un peu plus claires.

 

Voici tous les articles liés aux bases de données :

C’est quoi une base de données ?

C’est quoi une base de données ? – partie 2 

C’est quoi une base de données ? – partie 3 

et

Comment ça marche une base de données ?