< Retour au sommaire de l’arbre programmatique <

 

Les bases de données

 

 

 

Le sommaire :

  1. Présentation de la base de données.
  2. Le recensement des données.
  3. Les tables.
  4. Les relations.
  5. Le schéma des tables et relations.

 

 

Présentation de la base de données

 

Une base de données est un ensemble de données structurées.

Lorsque vous souhaitez stocker des données récupérées depuis une application, vous devez optimiser l’organisation de stockage de ces données, et ce, afin d’en rendre l’exploitation pratique et efficace.

Un fichier de données est un fichier texte qui permet d’enregistrer de façon linéaire les différentes données liées à une opération d’enregistrement réalisée depuis une application.

D’après vous, comment le carnet d’adresses de WINDOWS stocke-t-il les différents contacts pour lesquels vous exigez l’enregistrement ?

 

Eh bien, il crée un fichier texte qu’il appelle par exemple « contacts.txt ».

A l’intérieur de ce fichier, il va prévoir une ligne par contact, et par ligne, les différentes données d’un contact rangées systématiquement dans le même ordre, par exemple :

 

Pascal ;DUPONT ;MARSEILLE ;04 33 22 11 44 

Tony ;DURAN ;PARIS ;01 99 88 77 66 ;

Florence ;AMSTRONG ;LILLE ;02 32 32 44 55

 

Bien sûr, dans le véritable fichier de données du carnet d’adresses, il y a davantage de données par ligne, c’est-à-dire par contact…

 

Ainsi, l’application du carnet d’adresses comprend parfaitement que chaque ligne de ce fichier de données est un contact, puisqu’il y a un contact par ligne, et que chaque donnée du contact est séparée de la suivante par un point virgule.

Le point virgule est dit « Séparateur »…

 

En quelque sorte, nous faisons une forme de tableau sans quadrillage…

Voici donc tout bêtement ce qu’est un fichier de données !

 


Le recensement des données

 

 

 

Premier travail à réaliser, recenser les données dont on a besoin.

 

 « Nom du client », « Prénom du client », « Adresse », « CodePostal », « Ville », « Téléphone », « Fax », «

EMail », « Observation de l’article », « Description de l’article », « Prix unitaire », « Fabricant «, « Date facture », « Quantité d’un article » et « TauxTVA ».

 


Les tables

 

Dans l’univers des bases de données, une table est un fichier de données, une ligne de la table est un enregistrement et chacune des données de l’enregistrement est un champ.

Bon, on change un peu le vocabulaire voilà tout…

 

Nous devons donc associer les champs précédemment listés par table…

Pour bien réussir cette mission, il faut dès maintenant que vous preniez connaissance de 2 règles de base fondamentales :

 

  1. Une base de données ne doit pas contenir de champs en double.
  2. Une base de données ne doit pas contenir de champs qui soient le résultat de calculs pour lesquels vous disposez des valeurs élémentaires qui ont permis d’obtenir le résultat du calcul. Logique, imaginez qu’une donnée élémentaire soit modifiée, le champ contenant le résultat deviendrait alors faux. Les calculs doivent donc être réalisés par l’application et uniquement lorsqu’on en a besoin. Dans le cas par exemple du calcul d’un montant TTC, vous enregistrez dans une table le prix unitaire d’un article, la quantité et le taux de la TVA. Ainsi, lorsqu’on désirera voir afficher le TTC, l’application fera le calcul en un temps éclair !

 

Ah, autre chose, en créant les tables, on doit définir le type et la taille pour chacun des champs.

 

Donc, si on regroupe les champs par table en respectant les 2 règles, voici les tables qui surgissent du néant, MDR.

 

Pour un client, donc table « Clients » :

« Nom », Champ de type texte, 25 caractères.

« Prénom », Champ de type texte, 25 caractères.

« Adresse », Champ de type alphanumérique, 80 caractères.

 « CodePostal », Champ de type alphanumérique, 5 caractères.

« Ville », Champ de type texte, 50 caractères.

« Téléphone », Champ de type alphanumérique, 14 caractères.

« Fax », Champ de type alphanumérique, 14 caractères.

« EMail », Champ de type alphanumérique, 50 caractères.

« Observations », Champ de type alphanumérique, 300 caractères.

 

Pour les articles, donc table « Articles » :

« Description de l’article », Champ de type alphanumérique, 80 caractères.

« Prix unitaire », Champ de type réel.

« Taux TVA », Champ de type Réel.

« Fabricant «, Champ de type alphanumérique, 50 caractères.

 

Concernant les factures, donc table « Factures » :

« Date facture », Champ de type date, 10 caractères.

 

Et pour les détails d’une facture, donc la table « DétailsFactures » :

« Quantité », Champ de type entier, 3 caractères.

 

Remarque sur les types de données :

Contrairement au type « Texte », le type « alphanumérique » supporte les chiffres.

Quant au type « réel », c’est une valeur décimale.

Le type « Entier » est un nombre sans partie décimale.

 

Dans cette étape, nous devons maintenant nous soucier de l’identification des enregistrements des différentes tables qui viennent de prendre naissance…

Ce sont des champs « identifiant » que l’on appelle « Clef ».

 

Pour un enregistrement de la table « Clients », je propose un champ de type entier dont le numéro sera un identifiant unique par enregistrement, donc par client.

Pas besoin de déterminer nous-mêmes le numéro à chaque création d’un client, on va utiliser un numéro qui s’incrémentera tout seul, donc numéro 1 pour le premier client, numéro 2 pour le second etc.…

Dans l’enregistrement de la table « Clients », on rajoute alors une clef nommée « NumClient », dont le type est un entier d’une longueur de 5 caractères, on a de l’ambition !

Reste à déterminer les propriétés de cette clef…

Pour une clef qui est le principal identifiant de l’enregistrement, c’est une clef « primaire », sinon elle est « secondaire ».

Pour une clef qui doit être utilisée qu’une seule fois dans la table, elle est dite « unique », sinon, elle est dite « avec doublon ».

 

Dans le cas de « NumClient », comme un client doit avoir son propre identifiant et qu’il s’agit de la principale clef de l’enregistrement, on écrira la définition de la clef de la façon suivante :

« NumClient », Champ de type entier, 5 caractères, clef primaire et unique en auto incrémentation.

 

Voilà, donc maintenant nous avons un nouveau champ dans l’enregistrement de la table « Clients », et ce, dans l’unique but de pouvoir identifier un client.

 

Pour les articles, donc dans la table « Articles », voici le nouveau champ qui va jouer le rôle d’identifiant d’un article :

« NumArticle », Champ de type entier, 5 caractères, clef primaire et unique en auto incrémentation.

 

Pour la table « Factures », rajoutons également un identifiant :

« NumFacture », Champ de type entier, 5 caractères, clef primaire et unique en auto incrémentation.

 

Il nous reste la table « DétailsFactures », voici donc sa clef :

« NumDétailsFacture », Champ de type entier, 6 caractères, clef primaire et unique en auto incrémentation.

 

Voilà, les tables sont terminées…

 

 


Les relations

 

 

Vu que les tables sont construites, il faut désormais, dans cette nouvelle étape, créer des relations entre les enregistrements des différentes tables qui composent la base de données.

 

Dans ce but, nous allons devoir rajouter des champs à l’intérieur des enregistrements, dont le rôle, cette fois, sera d’établir des correspondances entre les enregistrements des tables à relier.

 

Prenons le cas de la table « Factures » et de la table « Clients ».

Comment établir une relation entre les enregistrements de ces 2 tables ?

 

En effet, selon la description des enregistrements que l’on vient de réaliser dans l’étape précédente, rien ne permet de savoir à quel client appartient une facture !

Alors, rajoutons le champ « NumClient » dans l’enregistrement de la table « Factures ».

C’est vite réglé ! Grâce à ce nouveau champ, dont le travail est de permette la relation, on pourra savoir à quel client appartient une facture…

Toutefois, comme un client pourra avoir plusieurs factures, donc, qu’un enregistrement de la table « Clients » pourra posséder plusieurs enregistrements dans la table « Factures », il ne faut pas que ce nouveau champ, dans la table « Factures », soit unique. Sinon, un client ne pourra avoir qu’une seule facture, ce serait une catastrophe commerciale !

Par conséquent, rajoutons le champ suivant dans l’enregistrement de la table « Factures » :

« NumClient », Champ de type entier, 5 caractères, clef secondaire avec doublon.

 

La première relation est faite.

 

Maintenant faisons la relation entre la table « factures » et la table « DétailsFactures ».

Pour une facture, peut correspondre plusieurs articles vendus, donc un enregistrement de la table « factures » peut avoir plusieurs enregistrements dans la table « DétailsFactures ».

Alors, là aussi, pour concrétiser la relation, il faut qu’une facture puisse identifier ses détails ! Non ?

Rajoutons immédiatement le champ « NumFacture » dans l’enregistrement de la table « DétailsFactures ».

« NumFactures », Champ de type entier, 5 caractères, clef secondaire avec doublon.

 

La relation entre la table « Factures » et la table « DétailsFactures » est faite.

 

Pour finir, reste à connecter les tables « détailsFactures » et « Articles ».

Puisque le détail d’une facture concerne un article, rajoutons le champ « NumArticle » dans l’enregistrement de la table « DétailsFactures ».

Voici la définition du nouveau champ :

« NumArticle », Champ de type entier, clef secondaire avec doublon.

 

Voilà, nous sommes prêts maintenant à établir les différentes contraintes des relations…

Dans la méthode d’analyse fonctionnelle « Merise », cette étape est appelée « cardinalité ».

 

 


 Le schéma des tables et relations.

 

 

 

Il ne s’agit pas en fait d’une nouvelle étape, mais plutôt de la continuité de l’étape précédente, celle qui concerne la construction des relations entre les tables.

 

En effet, pour mieux comprendre ce qu’on est en train de construire, je vais tenter d’illustrer le tout…

 

Prenez votre plume et une feuille blanche dans votre imagination.

 

En haut à gauche, dessinez un rectangle, c’est la table « Clients ».

Au-dessus de la barre supérieure, écrivez le nom de la table, en l’occurrence, « table clients ».

A l’intérieur du rectangle, écrivez ligne par ligne les différents champs de la table ainsi que leur type :

« NumClient », Champ de type entier, clef primaire unique en auto incrémentation.

« Nom », Champ de type texte, 25 caractères.

« Prénom », Champ de type texte, 25 caractères.

« Adresse », Champ de type alphanumérique, 80 caractères.

 « CodePostal », Champ de type alphanumérique, 5 caractères.

« Ville », Champ de type texte, 50 caractères.

« Téléphone », Champ de type alphanumérique, 14 caractères.

« Fax », Champ de type alphanumérique, 14 caractères.

« EMail », Champ de type alphanumérique, 50 caractères.

« Observations », Champ de type alphanumérique, 300 caractères.

  

Maintenant, dessinez un second rectangle en haut au milieu de la page.

C’est la table « Factures ».

Du coup, au-dessus du trait supérieur, écrivez le nom de la table, en l’occurrence, « table Facture ».

Dans le rectangles, toujours ligne par ligne, écrivez les différents champs qui composent l’enregistrement de cette table, sans oublier le champ qui va jouer le rôle d’identifiant pour la relation avec la table « clients ».

 

« NumFacture », Champ de type entier, 5 caractères, clef primaire unique en auto incrémentation.

« NumClient », Champ de type entier, 5 caractères, clef secondaire avec doublon.

« DateFacture », Champ de type date, 10 caractères.

 

Nous devons schématiser la relation entre ces deux tables.

Toutefois, une relation prend en compte une contrainte, c’est le nombre minimal et maximal de la participation d’un enregistrement d’une table par rapport à l’autre.

Du coup, comme il y a deux tables dans une relation, il y a deux contraintes, la première correspond à la participation de la table 1 vis-à-vis de la table 2, et la seconde correspond à la participation de la table 2 vis-à-vis de la table 1.

Il va falloir concrétiser la relation par deux flèches parallèles, la première part de l’enregistrement de la table 1 pour pointer sur l’enregistrement de la table 2, et la deuxième flèche part de l’enregistrement de la table 2 pour pointer l’enregistrement de la table 1. Ici dans notre exemple, la table 1 n’aura qu’à être la table « Clients », et la table 2, ça coule de source, sera la table « Factures »…

Attention néanmoins à ne pas faire partir les flèches de n’importe où sur les enregistrements des deux tables.

Il faut que les flèches prennent naissance et pointent la clef qui est utilisée pour établir la relation, et ce, respectivement dans les deux tables.

Alors, ici les flèches naissent depuis, et pointent les champs « NumClient » des 2 tables.

 

Nous devons maintenant établir les contraintes de la relation.

Pour chacune des flèches, nous devons répondre à 2 questions :

  1. L’enregistrement qui donne naissance à la flèche, à combien d’enregistrements, au minimum, peut-il être relié dans la table pointée.
  2. L’enregistrement qui donne naissance à la flèche, à combien d’enregistrements, au maximum, peut-il être relié dans la table pointée.

 

En clair, on doit déterminer la participation minimale et maximale pour chacune des flèches de la relation.

Prenons la flèche qui part de la table « Clients » pour pointer la table « Factures ».

Répondons à la première question, est-ce qu’un client peut avoir aucune facture ou bien, doit-il en avoir au moins une ?

La réponse ici est 1. En effet, comment un client peut-il être client s’il n’a jamais été facturé ?

Deuxième question, est-ce qu’un client peut avoir plusieurs factures ? La réponse est oui, donc « P » pour plusieurs…

Alors, à proximité de la flèche que nous sommes en train de traiter, écrivez 1-P.

« 1 », pour la participation minimale d’un enregistrement de la table « Clients » à la relation,« 

« P », pour la participation maximale de l’enregistrement de la table « Clients » à la relation.

 

Il faut maintenant poser les questions pour l’autre flèche, c’est-à-dire pour la participation d’un enregistrement de la table « factures » à la relation.

La réponse est 1-1.

« 1 », pour la participation minimale d’un enregistrement de la table « Factures » à la relation,

« 1 », pour la participation maximale d’un enregistrement de la table « Factures » à la relation.

 

En effet, une facture se rattache au moins à un client, et à un seul.

Notez alors 1-1 juste à côté de la seconde flèche, puisqu’il s’agit ici de la contrainte de la participation de la table « Factures » à la relation.

 

Allez, dessinez un troisième rectangle en haut à droite de la feuille.

Précisez le nom de la table et ces champs.

A savoir :

Table « Articles ».

« NumArticle », Champ de type entier, 5 caractères, clef primaire et unique.

« Description de l’article », Champ de type alphanumérique, 80 caractères.

« Prix unitaire », Champ de type réel.

« Taux TVA », Champ de type Réel.

« Fabricant «, Champ de type alphanumérique, 50 caractères.

 

Faisons la dernière table, dessinez un rectangle plus bas, au milieu de la page.

C’est la table « DétailsFacturs ».

Table « DétailsFactures ».

« NumDétailsFactures », Champ de type entier, clef primaire et unique en auto incrémentation.

« NumFacture », Champ de type entier, 5 caractères, clef secondaire avec doublon.

« NumArticle », Champ de type entier, 5 caractères, clef de type secondaire avec doublon.

« Quantité, Champ de type entier, 2 caractères.

 

Bon, établissons la relation entre la table « DétailsFactures » et sa maman, table « Factures ».

Faites partir une flèche du champ « NumFacture » de la table « DétailsFactures » à destination du champ du même nom de la table « Factures », et inversement pour la seconde flèche.

Quelle est la participation des enregistrements des 2 tables par rapport à la relation ?

Bon, en prenant le cas de l’enregistrement de la table « Factures », une facture a au moins un détail et peut en avoir plusieurs !

En découle alors une cardinalité de type 1-P. Écrivez 1-P à côté de la flèche qui part de la table « Factures ».

 

Dans l’autre sens, un détail de la facture appartient au moins à une facture, et à une seule facture.

A côté de la flèche qui part de la table « DétailsFactures », écrivez 1-1.

 

Faisons la dernière relation du schéma.

Faites partir une flèche de « NumArticle » de la table « DétailsFactures » à destination du même champ dans la table « Articles », et inversement.

 

Un article peut-il participer au moins une fois à la relation ?

En fait, non, un article peut ne pas être vendu !

Alors la première valeur est 0.

Un article peut-il être vendu plusieurs fois ? Heureusement que oui…

La deuxième valeur est P.

Écrivez 0-P à côté de la flèche qui part de la table « Articles ».

 

Dans l’autre sens, un article vendu appartient-il obligatoirement à la table « Articles » ? Si on a bien fait notre travail, oui.

La valeur est donc 1.

Un article vendu peut-il appartenir à plusieurs articles de la table « Articles » ?

Bien sûr que non, un article est un seul article point barre…

La réponse est donc 1.

A côté de la flèche qui part de la table « DétailsFactures », écrivez 1-1.

 

Bon, pas mal !

Il faudrait maintenant pouvoir écrire cela de façon linéaire…

Qu’en pensez-vous ?

 

Il suffit de remplacer les flèches par les signes « inférieur » et « supérieur » !

En noir, le signe « inférieur » pointe vers la gauche, et le signe « supérieur » pointe vers la droite ;

Le signe « inférieur » peut donc jouer le rôle de flèche gauche, et inversement, le signe « supérieur » le rôle de flèche droite.

 

Voici donc la syntaxe :

Nom de la Table 1, (Clef de relation), cardinalité de table 1><Cardinalité de table 2, Nom de la table 2.

 

Maintenant passons au concret :

 

Table « Clients », (NumClient), 1-P><1-1, Table « Factures ».

Table « Factures », (NumFacture), 1-P><1-1, Table « DétailsFactures ».

Table « Articles », (NumArticle), 0-P><1-1, Table « DétailsFactures ».

 

Voilà, merci pour les efforts fournis…

 

 

< Retour au sommaire de l’arbre programmatique <