Discussion :

[fsmrel]

Bonjour,

Je reprends votre premier message :

je pense mettre une clé externe dans la table Nomenclature pour la lier avec les détails des commandes.

Que je rapproche de ce que vous venez de préciser :

Un détail de commande fait référence exactement à une nomenclature.
Une nomenclature peut servir plusieurs détails de commande.

Dans les deux cas, il y a bien relation entre Detail_Commande et Nomenclature mais c’est votre 2e réponse qui est manifestement à prendre en compte.

il y a une date d'insertion dans la nomenclature ainsi que l'utilisateur qui a inséré la pièce ainsi que la quantité

Indépendamment d’autres considérations pouvant faire évoluer cette partie du modèle, je considère que les termes "pièce" et "article" sont synonymes. Pour le distinguer de l’acheteur, j’utilise ci-dessous le terme "magasinier" au lieu de "utilisateur", même si ça n’est peut-être pas le terme pertinent dans l’entreprise.
Par ailleurs, je propose la mise en œuvre d’une table Nomencl_Detail pour héberger, pour chaque nomenclature, la quantité, la date de l’événement et l’utilisateur (magasinier) ayant effectué l’opération. Dans la mesure où pour une nomenclature et un article, un magasinier pourrait saisir plus d’une quantité à la même date et à la même heure, on se contente ici d’enregistrer les ajouts successifs à l’aide d’un numéroteur ou séquenceur (Seq).

D’un point de vue tabulaire, on pourrait donc l’ébauche suivante (aux erreurs de copier/coller près) :

Table Article {IdArticle, ...}
Primary Key {IdArticle}

Table Magasinier {IdMagasinier, ...}
Primary Key {IdMagasinier}

Table Affaire {IdAffaire, ...}
Primary Key {IdAffaire}

Table Nomenclature {IdAffaire, IdArticle, ...}
Primary Key {IdAffaire, IdArticle}
Foreign Key {IdAffaire} References Affaire
Foreign Key {IdArticle} References Article

Table Nomencl_Detail {IdAffaire, IdArticle, Seq, Quantite, Date, IdMagasinier, ...}
Primary Key {IdAffaire, IdArticle, Seq}
Foreign Key {IdAffaire, IdArticle} References Nomenclature
Foreign Key {IdMagasinier} References Magasinier

Table Commande {IdAffaire, IdCommande, NoCommande, ...}
Primary Key {IdAffaire, IdCommande}
Unique {NoCommande}

Table Detail_Cde {IdAffaire, IdCommande, IdDetailCde, IdArticle, QteCde, QteLivree, ...}
Primary Key {IdAffaire, IdCommande, IdDetailCde}
Foreign Key {IdAffaire, IdArticle} References Nomenclature

Vous observerez que j’ai identifié la commande relativement à l’affaire. En effet, non seulement une commande fait référence à une seule affaire, mais en plus elle la caractérise. Cette façon de procéder permet de faire respecter la contrainte selon laquelle, pour un détail de commande donné, l’affaire de la commande est bien la même que celle de la nomenclature impliquée.
Vous pouvez bien entendu préférer une autre représentation, en sorte que l’attribut IdAffaire ne participe pas à la clé primaire de la table Commande, mais on ne peut plus dans ces conditions garantir la contrainte qui vient d’être énoncée, ce qui entraînera la mise en œuvre d’un trigger SQL pour y parvenir malgré tout.

Au fait, il serait temps de produire un MCD...

[Corben]

Bonjour, merci pour vos réponses
Je ne comprends pas l'utilité de la table details nomenclature dans le dernier schéma. Pour l'instant je récapitule ce que j'ai compris ci dessous pour moi il ne manque plus que la fameuse liaison entre la table nomenclature et details commande pour permettre à l'acheteur d effectuer un controle des achats restants sur la nomenclature d'une affaire.
Pourquoi creer une table details nomenclature ?

Tbl article
id_article clé primaire
reference
description
stock
...

Tbl affaire
id_affaire clé primaire
num_affaire
nom_affaire

Tbl commande
id_commande clé primaire
date
...

Tbl details_commande
id_details_commande clé primaire
id_commande clé externe
quantitecde
quantitercpte
date



Tbl nomenclature
id_nomenclature clé primaire
id_affaire clé externe
quantitenomenclature
id_article clé externe

[fsmrel]

Je ne comprends pas l'utilité de la table details nomenclature dans le dernier schéma

Vous avez précisé que pour une nomenclature donnée, c'est-à-dire pour une affaire et un article donnés, vous pouviez avoir plusieurs valeurs pour la quantité. Je reprends donc l’exemple fourni par JPhi33 (message #15) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Affaire   Article   Quantité
-------   -------   --------
A1        VISCHC5        100
A1        VISCHC5         50

En le complétant avec les attributs accompagnant la quantité, on obtient par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Affaire   Article   Quantité   Date         Seq    Magasinier
-------   -------   --------   ----------   ---    ----------
A1        VISCHC5        100   27/05/2008     1    M1
A1        VISCHC5         50   27/05/2008     2    M1

Ce qui peut se lire ainsi :

Concernant la nomenclature caractérisée par l’affaire A1 et l’article VISCHC5, une première fois, le 27/05/2008, le magasinier M1 a fourni 100 unités de l'article VISCHC5. Toujours pour cette nomenclature, une deuxième fois, le 27/05/2008, le magasinier M1 a fourni 50 unités de l'article VISCHC5.

La structure de la table correspondante est la suivante (peu importe l'ordre des attributs) :

Nomenclature (Affaire, Article, Seq, Date, Qte, Magasinier)

Dans laquelle la clé primaire ne peut plus être le couple {Affaire, Article}, puisque l’on ne garantirait plus la contrainte d’unicité des clés, mais doit être le triplet {Affaire, Article, Seq} (voire peut-être {Affaire, Article, Date} si Date était un timestamp).

En réalité, cette table correspond à la table Nomencl_Detail que j’ai proposée dans mon message précédent, mais il manque quelque chose dans cette affaire. En effet, une nomenclature est seulement définie par un couple {Affaire, Article}, tandis que la quantité n’en est qu’une propriété multivaluée, aussi j’en reviens à la table Nomenclature proposée par JPhi33 (message #11) :

Nomenclature (Affaire, Article, Quantite, ...)

En aménageant cette table, c'est-à-dire en tenant compte de la propriété multivaluée, elle devient la suivante :

Nomenclature (Affaire, Article, Quantite (Seq, Date, Qte, Magasinier, ...), ...)

Mais cette structure contrevient à la 1re forme normale, du fait de l'inclusion de la table Quantite dans la table Nomenclature, à la façon des poupées russes.

En conséquence, on la soumet au procédé de normalisation (déjà) décrit par Ted Codd en 1970, par lequel on obtient inéluctablement le couple de tables :

Nomenclature (Affaire, Article, ...)

Quantite (Affaire, Article, Seq, Date, Qte, Magasinier, ...)

Et vous retrouvez ainsi, de façon mécanique, les tables Nomenclature et Nomencl_Detail que je vous ai proposées dans mon précédent message.

L’exemple utilisé ci-dessus prend l'allure suivante (clés primaires en bleu et en italiques) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Nomenclature (Affaire   Article     ...)
              -------   -------     ---
              A1        VISCHC5     ...

Nomencl_Detail (Affaire   Article   Quantité   Date         Seq    Magasinier)
                -------   -------   --------   ----------   ---    ----------
                A1        VISCHC5        100   27/05/2008     1    M1
                A1        VISCHC5         50   27/05/2008     2    M1

Et quand vous dites «il ne manque plus que la fameuse liaison entre la table nomenclature et details commande», je réponds que cette liaison est obtenue ainsi, par le canal de la table Detail_Cde :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Nomenclature (Affaire   Article     ...)
              -------   -------     ---
              A1        VISCHC5     ...

Nomencl_Detail (Affaire   Article   Quantité   Date         Seq    Magasinier)
                -------   -------   --------   ----------   ---    ----------
                A1        VISCHC5        100   27/05/2008     1    M1
                A1        VISCHC5         50   27/05/2008     2    M1

Detail_Cde (Affaire  Commande  DetailCde  Article   QteCde  QteLivree, ...)
            ------   --------  ---------  -------   ------  ---------     
            A1       C1                1  VISCHC5     150         30

Au passage, je vous rappelle le mécanisme de l'intégrité référentielle (laquelle fait partie intégrante du Modèle Relationnel de Données) : Une clé étrangère F d’une table T1 (ce que vous appelez clé externe, pourquoi pas) est un ensemble d’attributs de T1, tel que cet ensemble représente aussi la clé primaire K d’une table T2 (non nécessairement distincte de T1), en sorte que chaque valeur prise par F soit aussi une valeur prise par K.

Ainsi, le couple {Affaire, Article} de la table Detail_Cde est clé étrangère par rapport à la clé primaire {Affaire, Article} de la table Nomenclature. La valeur <A1, VISCHC5> ne peut exister dans la table Detail_Cde que si elle existe d’abord dans la table Nomenclature.

Cela dit, vous ne voyez pas l'utilité de la table Nomencl_Detail. Supposons donc qu’elle soit inutile. Dans ces conditions, on la réintègre dans la table Nomenclature, mais celle-ci change de structure, pour tenir compte de la mise en rondelles de la quantité :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Nomenclature (Affaire   Article   Seq    Quantité   Date         Magasinier)
              -------   -------   ---    --------   ----------   ----------
              A1        VISCHC5     1        100    27/05/2008   M1
              A1        VISCHC5     2         50    27/05/2008   M1

Dans ces conditions, si vous cherchez à établir une relation entre une ligne de commande et une nomenclature, vous devrez faire intervenir l’attribut Seq, eu égard à la définition de l'intégrité référentielle, et la table Detail_Cde et son contenu ressembleront à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Detail_Cde (Affaire  Commande  DetailCde  Article   Seq  QteCde  QteLivree, ...)
            -------  --------  ---------  -------   ---  ------  ---------     
            A1       C1                1  VISCHC5     1     150         30

... Ou à cela, car 2 pourrait être jaloux de 1...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Detail_Cde (Affaire  Commande  DetailCde  Article   Seq  QteCde  QteLivree, ...)
            -------  --------  ---------  -------   ---  ------  ---------     
            A1       C1                1  VISCHC5     2     150         30

Bref, nous sommes arrivés chez les Branquignols...

Mais vous n’avez peut-être pas tout dit, en conséquence de quoi tout est peut-être à revoir : savoir rédiger les règles de gestion des données de façon exhaustive et précise n'est pas facile, mais c'est impératif si l’on ne veut pas tourner en rond et finir par mettre à la poubelle tout un travail de conception. Combien de grands projets on subi un tel sort...

Et de grâce, utilisez un outil de modélisation, comme vous l’a conseillé JPhi33, cela vous aidera à mieux comprendre les règles de l'art et les contraintes inhérentes.


Concernant les tables que vous proposez dans votre message précédent :

La table commande est dépourvue d’un attribut id_affaire, or vous aviez précisé qu’au niveau de la commande, on avait connaissance de l’affaire. (Cf. votre message #12 : " nous indiquons le numéro de l'affaire sur la commande").

La table details_commande devrait être identifiée relativement à la table commande. En effet, elle n’en est qu’une propriété multivaluée. C’est ce que j’ai fait (message #21), voyez ma table Detail_Cde (laquelle est du reste identifiée relativement à l’affaire, mais surtout pour une raison technique que j’ai expliquée).

La table nomenclature peut être débarrassée de l’attribut id nomenclature (qui n’apporte rien), au bénéfice du couple {id_affaire, id_article}, clé primaire authentique.

Bref revoyez tout cela en fonction de ce que JPhi33 et moi-même vous avons dit.