Aller au contenu

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

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

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

base de données  

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

 

base de données

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 ?

 

 

Comme d'habitude, tous les commentaires sont les bienvenus.
Inscrivez-vous à la lettre d'information. Celle-ci vous parviendra dès la parution de nouveaux articles. Vous trouverez la zone d'inscription à la lettre d'information en haut à droite de l'écran.
 
Et enfin, pour toutes vos questions techniques, utilisez le forum. D 'autre utilisateurs pourront vous répondre et vous aider. Cliquez ici pour accéder au forum...
Étiquettes:

2 commentaires sur “C’est quoi une base de données ? – Partie 3”

  1. Très complète cette série d’articles, et aussi très opérationnelle avec l’exemple des factures ! De mon côté j’ai choisi l’exemple des bonbons pour expliquer les bases de données : http://www.rocketprojet.com/bases-donnees-mine-or-tpe-pme/
    Et j’ai complété en listant à la fin des pistes pour exploiter les données de son entreprise.

    Pour info, j’ai bien lu les 3 articles de la série, mais je n’ai pas trouvé l’explication sur les fichiers qui faisaient craindre le bug de l’an 2000, comme vous l’avez mentionné dans la partie 1 ! Pour moi ce bug était lié aux problèmes de comparaison de dates sur 2 chiffres au lieu de 4 (l’an 2000, codé 00, se situant donc avant 1999, codé 99). Je suis intéressé de lire une autre anecdote à ce sujet !

    1. Bonjour Thibault,
      oui le bug de l’an 2000 était bien lié au nombre de digit de stockage des dates. Pour économiser l’espace à l’époque, on stockait les dates sur 2 caractères.
      A bientôt

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ads Blocker Image Powered by Code Help Pro

Ads Blocker Detected!!!

We have detected that you are using extensions to block ads. Please support us by disabling these ads blocker.

Powered By
Best Wordpress Adblock Detecting Plugin | CHP Adblock