< Retour au sommaire de l’arbre programmatique <

Les tables de type relation

 

 

 

Le sommaire :

  1. Introduction.
  2. Présentation de l’exercice à réaliser.
  3. Recensement des données.
  4. Création des tables.
  5. Création des relations.
  6. L’analyse en clair, étape par étape.

 

 

Introduction

 

Dans l’univers des bases de données tel que nous venons de le découvrir, les choses ne se résument pas aussi simplement que je vous l’ai présentées dans les chapitres précédents…

 

En effet, pour l’instant, nous avons traité des types de relations simples entre les différentes tables de la base.

 

Cependant, dans l’étude de certaines bases de données, nous allons nous confronter à des relations qui posent des difficultés dans le cadre de l’application des 2 règles fondamentales de base :

  1. Aucune redondance de champ dans une base de données (autre que les champs de type clé),
  2. Aucune donnée qui soit le résultat de calculs lorsque l’on dispose des données élémentaires qui permettent de réaliser le calcul.

 

C’est la première règle qui va nous intéresser ici…

Accrochez-vous !

 

Toutefois, pour rendre la progression pédagogique plus douce dans la suite de l’étude des bases de données, nous allons travailler directement depuis l’étude d’un exemple concret.

 

 


Présentation de l’exercice à réaliser

 

-         Un utilisateur travaille dans un service de renseignements concernant des pièces détachées de voitures.

Régulièrement, des mécaniciens lui téléphonent afin de l’interroger pour obtenir les références d’une pièce et pour savoir quels sont les fournisseurs en mesure de la livrer.

 

 


Le recensement des données :

 

Raison sociale du fabricant,

Raison sociale du fournisseur,

Nom de la pièce détachée,

Référence de la pièce détachée,

Modèle du véhicule,

Référence du véhicule.

 

 


La création des tables

 

(Étape 2, cette étape permet d’établir les tables et leur clé d’identification.)

 

Table « fabricant »

NumFabricant, entier en auto incrémentation, clé primaire et unique.

RaisonSocialeFabricant, alphanumérique de 50 caractères.

 

Table « fournisseurs »

NumFournisseur, entier en auto incrémentation, clé primaire et unique.

RaisonSocialeFournisseur, alphanumérique de 50 caractères.

 

Table « Véhicules »

RéférenceVéhicule, alphanumérique de 25 caractères, clé primaire et unique.

ModèleVéhicule, alphanumérique de 25 caractères.

 

Table « PiècesDétachées »

RéférencePièce, alphanumérique de 25 caractères, clé primaire et unique.

NomPièce, alphanumérique de 25 caractères.

 

Voilà, aucune difficulté pour cette étape…

Pour regrouper nos données de base, nous avons dû créer 4 tables qui se sont très naturellement distinguées !

 

Dans le cas des pièces détachées et des véhicules, les références établies par les fabricants vont nous servir comme clés.

Par conte, pour les fabricants et les fournisseurs, nous avons créé des clés dont leurs valeurs s’incrémenteront à chaque nouvel enregistrement…

 

 


La création des relations

 

Commençons par relier la table « PiècesDétachées » à la table « fabricant », qu’en dites-vous ?

 

Puisqu’une pièce détachée ne peut être fabriquée que par un seul fabricant, et qu’un fabricant peut fabriquer, heureusement pour lui d’ailleurs, plusieurs pièces détachées, nous allons rajouter la clé de relation « NumFabricant » dans la table « PiècesDétachées ».

 

Voici alors le contenu de la table « PiècesDétachées » :

RéférencePièce, alphanumérique de 25 caractères, clé primaire et unique.

NomPièce, alphanumérique de 25 caractères.

NumFabricant, entier, clé secondaire avec doublon.

 

Maintenant nous pouvons établir la relation !

 

Table « fabricants » (NumFabricant) 1-P >

< 1-1 (NumFabricant) table « PiècesDétachées ». 

 

Voilà, maintenant essayons d’établir la relation entre la table « PiècesDétachées » et la table « fournisseurs ».

 

Top ! Et oui, voici une difficulté, enfin…

Puisqu’un fournisseur peut livrer plusieurs pièces détachées, et qu’une pièce détachée peut être livrée par plusieurs fournisseurs, la table « PiècesDétachées » verra l’enregistrement d’une pièce détachée répété autant de fois qu’elle appartiendra à un fournisseur…

 

Imaginez que la pièce détachée « portière », dont la référence est « 313B », peut être livrée par 2 fournisseurs, « Auto-livraison75 «  dont l’identifiant est « 004 », et

« Finale-Mécanique » dont l’identifiant est « 023 ».

 

Dans la table « PiècesDétachées », il faudrait 2 enregistrements pour exprimer cet état de fait !

Le premier enregistrement serait alors :

Pour le champ « RéférencePièce » « 313B »,

Pour le champ « NomPièce », « portière »,

Pour le champ « NumFabricant », par exemple « 100 »,

Pour le champ « NumFournisseur », « 004 ».

 

Le second enregistrement serait ensuite:

Pour le champ « RéférencePièce » « 313B »,

Pour le champ « NomPièce », « portière »,

Pour le champ « NumFabricant », par exemple « 100 »,

Pour le champ « NumFournisseur », « 023 ».

 

Vous voyez donc ici que pour exprimer l’appartenance d’une pièce détachée à ses fournisseurs, nous avons dû créer 2 enregistrements en répétant 2 champs autres qu’une clé de relation, « NomPièce » & « « NumFabricant ». En effet, ces 2 champs font partie des données recensées dans la première étape de l’analyse, Ils n’ont pas à être dupliquées !

La règle numéro 1 n’est donc pas respectée…

Pire encore, la clé d’identification « RéférencePièce » est également dupliquée, alors que dans la table « PiècesDétachées », elle doit être primaire et sans doublon…

 

Du coup, on est obligé de créer une table de type relation entre les tables « PiècesDétachées » & « fournisseurs ».

Cette table qui va jouer le rôle de relation aura le nom de :

Table relation « livraisons ».

Nous sommes satisfaits car nous n’allons rajouter aucun champ de type « clé de relation » dans les tables « PiècesDétachées » & « fournisseurs », seule la table relation « livraisons » doit être décrite immédiatement ici !

Pour les tables « PiècesDétachées » & « fournisseurs », aucune description donc, elles ne changent pas…

Par contre, voici la table relation « livraisons » :

RéférencePièce, alphanumérique de 25 caractères, clé secondaire avec doublon.

NumFournisseur, entier, clé secondaire avec doublon.

 

Vous êtes prêts pour la relation ?

Go !

 

Table « PiècesDétachées » (RéférencePièce) 1-P >

< 1-1 (RéférencePièce) Table « livraisons » (NumFournisseur) 1-1 >

< 1-P (NumFournisseur) table « fournisseurs ».

 

Décrivons un peu ce schéma…

 

En haut, la table « PiècesDétachées » avec comme clé de relation à la table relation « livraisons », « RéférencePièce » qui est la clé primaire de la table « PiècesDétachées ».

Sa participation à la relation est de type 1-P, (1) pour indiquer qu’une pièce doit être livrée au minimum par un fournisseur, et (P) pour indiquer qu’une pièce peut être livrée par plusieurs fournisseurs.

En clair, un enregistrement de la table « PiècesDétachées » appartient à un ou plusieurs enregistrements de la table relation « livraisons », tandis qu’un enregistrement de la table relation « livraisons » appartient obligatoirement à un enregistrement de la table « PiècesDétachées », et un seul.

Cette analyse s’exprime clairement sur le schéma, regardez la partie gauche de la ligne qui décrit la table relation « livraisons  et qui pointe sur la table « piècesDétachées » !

 

Du côté du fournisseur, la cardinalité est (1-P), car un fournisseur doit au minimum pouvoir livrer une pièce, donc (1), et peut en livrer plusieurs, donc (P) !

Quant à la participation de la table relation « livraisons » par rapport à la table « fournisseurs », la cardinalité est (1-1), (1) car un enregistrement de la table relation « livraisons » appartient au minimum à un fournisseur, et (1), car au maximum l’enregistrement n’appartient qu’à un seul fournisseur, et un seul.

Voilà, le problème est résolu…

 

Concernant la relation entre les tables « PiècesDétachées » & « Véhicules », comme nous avons la même difficulté, alors nous allons créer une table relation qui s’appellera « CompositionVéhicules ».

Dans cette nouvelle table relation, nous allons y placer 2 champs de type clé de relation :

RéférencePièce, (pour faire la relation avec la table « PiècesDétachées »), alphanumérique de 25 caractères, clé secondaire et avec doublon.

RéférenceVéhicule, (pour faire la relation avec la table « véhicules »), alphanumérique de 25 caractères, clé secondaire avec doublon.

 

Voici le schéma :

 

Table « PiècesDétachées » (RéférencePièce) 1-P) >

< 1-1 (RéférencePièce) table relation « CompositionVéhicule » (RéférenceVéhicule) 1-1 >

< 1-P (RéférenceVéhicule) table « véhicules ».

 

 

 


L’analyse en clair, étape par étape

 

Étape 1, le recensement des données :

 

Raison sociale du fabricant,

Raison sociale du fournisseur,

Nom de la pièce détachée,

Référence de la pièce détachée,

Modèle du véhicule,

Référence du véhicule.

 

 

Étape 2, les tables :

 

Table « fabricant »

NumFabricant, entier en auto incrémentation, clé primaire et unique.

RaisonSocialeFabricant, alphanumérique de 50 caractères.

 

Table « fournisseurs »

NumFournisseur, entier en auto incrémentation, clé primaire et unique.

RaisonSocialeFournisseur, alphanumérique de 50 caractères.

 

Table « Véhicules »

RéférenceVéhicule, alphanumérique de 25 caractères, clé primaire et unique.

ModèleVéhicule, alphanumérique de 25 caractères.

 

Table « PiècesDétachées »

RéférencePièce, alphanumérique de 25 caractères, clé primaire et unique.

NomPièce, alphanumérique de 25 caractères.

 

Table relation « livraisons » :

 

RéférencePièce, alphanumérique de 25 caractères, clé secondaire avec doublon.

NumFournisseur, entier, clé secondaire avec doublon.

 

Table relation « CompositionVéhicules » :

 

RéférencePièce, alphanumérique de 25 caractères, clé secondaire avec doublon.

RéférenceVéhicule, alphanumérique de 25 caractères, clé secondaire avec doublon.

 

 

Étape 3, les relations :

 

Table « fabricants » (NumFabricant) 1-P >

< 1-1 (NumFabricant) table « PiècesDétachées ». 

 

Puis :

 

Table « PiècesDétachées » (RéférencePièce) 1-P >

< 1-1 (RéférencePièce) Table « livraisons » (NumFournisseur) 1-1 >

< 1-P (NumFournisseur) table « fournisseurs ».

 

Puis :

 

Table « PiècesDétachées » (RéférencePièce) 1-P) >

< 1-1 (RéférencePièce) table relation « CompositionVéhicule » (RéférenceVéhicule) 1-1 >

< 1-P (RéférenceVéhicule) table « véhicules ».

 

Fin de l’analyse…

< Retour au sommaire de l’arbre programmatique <