Discussion :

[Parvus]

Bonjour,

Je suis confronté à un problème de structure dans la réalisation de ma base de donnée. Problème auquel je n'ai jamais fait face jusqu'à présent et pour lequel je n'ai jamais vu d'exemple. Je vais simplifier mon problème et le ramener sur 3 tables pour faciliter la compréhension, le problème étant actuellement porté sur environ 18 tables (si je compte bien).

Ma question est : comment trouver une information en recoupant différentes données ?

Le cas concret est le suivant :
J'ai une table contenant des articles :

Code :

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

1
2
3
4
Article     ID     NOM     DESCRIPTION
----------------------------------------------
            1      Roue    Une roue de voiture
            2      Jante   Une jante de voiture

Une table contenant des clients :

Code :

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

1
2
3
4
Client      ID     NOM        PRENOM
----------------------------------------------
            1      DUPONT     Jean
            2      DUPUIS     Bernadette

Une dernière table contenant des dossiers

Code :

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

1
2
3
Dossier      ID     NOM
----------------------------------------------
             1      Réapprovisionnement JUIN

Mon besoin étant qu'en fonction des informations saisies dans une commande, je sache où ranger cette commande.
J'ai donc créé une table que j'ai nommé "correspondance" qui en fonction de ces informations, me retourne une valeur.

Code :

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

1
2
3
4
5
Correspondance      VALEUR      ARTICLE     CLIENT     DOSSIER
--------------------------------------------------------------------
                    Ventes      Roue        NULL       NULL
                    VentesVIP   Roue        DUPONT     NULL
                    VentesJUIN  Roue        NULL       Réappro JUIN

Pour illustrer cela, si j'ai une commande de Roue du client Dupuis, je devrais mettre cela dans les Ventes.
Si j'ai une commande de Roue du client Dupuis pour le dossier Réapprovisionnement JUIN, je devrais mettre cela dans les VentesJUIN.
Si j'ai une commande de Jante du client Dupont, je ne devrais pas ranger ce cela.

La principale contrainte étant qu'une commande donnée ne peut se classer que dans un seul endroit, pour un article, un client et un dossier donné. Je ne peux trouver qu'une seule et unique valeur (ce que j'ai traduit par un index unique dans ma table Correspondance sur l'article, le client et le dossier pour ne pas avoir de doublon).

Jusque là, ça me semblait plutôt "correct" (sans en être satisfait) mais le problème est que je n'ai pas simplement un article, un client et un dossier, mais j'ai 18 informations au total et il n'est pas possible dans mon SGDB (MSSQL) d'avoir un index unique sur 18 zones (le max étant 16) ce que je peux comprendre. J'ai donc remis en cause ma solution, mais ne trouve pas d'alternative (mis à part la concaténation de mes informations dans une seule zone, et l'index unique sur cette zone, mais je ne suis pas convaincu par cette solution).

Si vous pouviez m'orienter vers des informations sur ce genre de structure, ce serait formidable ! (Rien que le nom me serait d'une grande aide, ce genre de problématique doit bien avoir un nom).


P.S : Si il y a besoin d'information supplémentaire, de plus d'exemples ou de préciser un point, n'hésitez pas à me demander.

[Richard_35]

Bonjour Parvus,

(Rien que le nom me serait d'une grande aide, ce genre de problématique doit bien avoir un nom).

==> c'est une sorte de ventilation d'écritures comptables (comptabilité générale) en comptabilité analytique : ta table serait donc une table de ventilation.

D'autre part, les valeurs NULL de cette table de validation semblent vouloir dire "Tous". Dans ce cas, il faut remplacer NULL par "*ALL", par exemple (je ne sais pas pourquoi mais cette valeur devrait plaire à Fsmrel...) : il faut éviter les valeurs NULL, a fortiori dans des champs d'index.

Enfin, du fait même de la valeur "*ALL", il faudra déterminer une sorte de priorité de ventilation. Par exemple :

Si j'ai une commande de Roue du client Dupuis pour le dossier Réapprovisionnement JUIN, je devrais mettre cela dans les VentesJUIN.

==> OK, mais si cette ligne existe :

Code :

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

                    VentesJUIN  Roue        Dupuis       Réappro JUIN

==> quelle est la valeur prioritaire ?... "Réappro JUIN" ou "Dupuis" ?

[Parvus]

==> c'est une sorte de ventilation d'écritures comptables (comptabilité générale) en comptabilité analytique

Merci, voila qui va me permettre de faire de nouvelles recherches sur les structures à mettre en place pour traiter cette problématique.
Personnellement, c'est exactement mon cas (trouver un n° de compte en fonction de différentes informations) mais j'ai tenu à exprimer ce problème d'une autre façon pour rester plus sur le fond, que sur la forme (peut-être à tord) et je trouve que c'est un bon exercice pour voir si j'ai bien compris mon problème.

il faut éviter les valeurs NULL, a fortiori dans des champs d'index.

Cela aurait un impact sur les performances, ou se serait plus dans une optique de compréhension des données ?

Enfin, du fait même de la valeur "*ALL", il faudra déterminer une sorte de priorité de ventilation. Par exemple :

Code :

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

                    VentesJUIN  Roue        Dupuis       Réappro JUIN

==> quelle est la valeur prioritaire ?... "Réappro JUIN" ou "Dupuis" ?

Tout à fait, il y a d'ailleurs une priorité qui est gérée directement lorsque l'on fait une requête sur cette table. Dans le cas présent, en ordonnant par article, puis par client et enfin par dossier; la première valeur retournée sera alors celle qui correspondra le mieux aux informations saisies.

Exemple de requête :

Code SQL :

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

1
2
3
SELECT Valeur FROM Correspondance
WHERE (Article = 'Roue' OR Article = '*ALL') AND (Client = 'Dupuis' OR Client = '*ALL') AND (Dossier = 'Réappro JUIN' OR Dossier = '*ALL')
ORDER BY Article DESC, Client DESC, Dossier Desc

Le problème étant que si les informations (Article, Client, etc...) qui nous permettent de trouver la bonne Valeur sont trop nombreuses (>16 pour MSSQL), alors l'unicité des données n'est plus maintenue.

Est-ce plus correct de s'assurer de l'unicité des données de la table directement dans l'applicatif (avant insertion d'une nouvelle ligne) ou de laisser SQL gérer ce problème en concaténant les champs devant être utilisé pour tester l'unicité dans une nouvelle colonne ? (Dans le deuxième cas, la valeur *ALL pour remplacer les NULL prend tout son sens)

[Richard_35]

Cela aurait un impact sur les performances, ou se serait plus dans une optique de compréhension des données ?

==> les deux !... NULL est parfois mal géré, a fortiori dans les index. Et si NULL veut dire "Tous", alors stockons "Tous" (ou "*ALL").

Tout à fait, il y a d'ailleurs une priorité qui est gérée directement lorsque l'on fait une requête sur cette table. Dans le cas présent, en ordonnant par article, puis par client et enfin par dossier; la première valeur retournée sera alors celle qui correspondra le mieux aux informations saisies.
Le problème étant que si les informations qui nous permettent de trouver la bonne Valeur sont trop nombreuses (>16 pour MSSQL), alors l'unicité des données n'est plus maintenue.

==> nous ne parlons pas, ici, d'unicité, mais de priorité. Considérons l'exemple :

Code :

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

1
2
3
4
5
6
Correspondance      VALEUR      ARTICLE     CLIENT     DOSSIER
--------------------------------------------------------------------
                    Ventes      Roue        *ALL       *ALL
                    VentesVIP   Roue        DUPONT     *ALL
                    VentesVIP   Roue        DUPUIS     *ALL
                    VentesJUIN  Roue        *ALL       Réappro JUIN

Si j'ai bien compris, une commande de Roue du client Dupuis pour le dossier Réapprovisionnement JUIN serait classée dans VentesVIP, c'est bien cela ?

[Parvus]

==> les deux !... NULL est parfois mal géré, a fortiori dans les index. Et si NULL veut dire "Tous", alors stockons "Tous" (ou "*ALL").

Précieux conseil ! Merci.

Considérons l'exemple :

Code :

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

1
2
3
4
5
6
Correspondance      VALEUR      ARTICLE     CLIENT     DOSSIER
--------------------------------------------------------------------
                    Ventes      Roue        *ALL       *ALL
                    VentesVIP   Roue        DUPONT     *ALL
                    VentesVIP   Roue        DUPUIS     *ALL
                    VentesJUIN  Roue        *ALL       Réappro JUIN

Si j'ai bien compris, une commande de Roue du client Dupuis pour le dossier Réapprovisionnement JUIN serait classée dans VentesVIP, c'est bien cela ?

C'est tout à fait ça. De même, toujours en suivant votre exemple, une commande de Roue du client Tartempion serait classée dans Ventes.

[Richard_35]

OK, donc :

Article => Client => Dossier ==> ??

Il manque le classement des 15 autres paramètres.

Après, nous pourrons peut-être définir une stratégie de ventilation.

[fsmrel]

Bonsoir Parvus et Richard ⁽¹⁾,


Je n’ai pas encore regardé les échanges avec Richard (qui a bien vu le coup du bonhomme NULL), mais je poste ce que j’ai écrit à la seule lecture de votre message initial.
Voici donc le verbatim de ce que j’ai écrit, désolé s’il y a de la redondance ou des contradictions en relation avec vos échanges, mais pour résumer l’approche, disons que je passe par une étape analytique pour en inférer la partie synthétique... :

Je n’ai pas tout compris de votre problème, mais je vais m'appuyer sur la présence du bonhomme NULL qui fait penser que votre table Correspondance est l’amalgame de données venant de différentes sources, qu’elle est donc virtuelle (c'est-à-dire une vue), ce qui montre que la modélisation est à revoir.

On y trouve la paire <Ventes, Roue> ce qui donne à penser qu’au niveau conceptuel on a la situation suivante :



Le « 1,1 ? » traduit un doute de ma part : un article peut-il être associé à plusieurs valeurs ou seulement à une seule ? Peu importe à ce stade.

On trouve encore dans votre exemple le triplet <VentesVIP, Roue, Dupont>, ce qui donne à penser qu’au niveau conceptuel on a aussi la situation suivante :




Situation dans laquelle 'VenteVIP' est une valeur prise par l’association CDE_ART quand Dupont (je suppose ici qu’il s’agit en fait d’une commande de Dupont) et Roue sont parties prenantes.

La flèche rouge signifie que pour une commande et un article il n’y a qu’une seule valeur :

COMMANDE X ARTICLE → VALEUR

On trouve aussi dans votre exemple le triplet <VentesJuin, Roue, RéapproJUIN>, ce qui donne à penser qu’au niveau conceptuel on a aussi la situation suivante :



La flèche rouge signifie que pour un dossier et un article il n’y a qu’une seule valeur :

DOSSIER X ARTICLE → VALEUR

Soit globalement :




Si vous voulez ne pas mélanger les valeurs selon leur typologie, vous pouvez procéder à une spécialisation dotée d’une contrainte d’exclusion (X) :



Et établir les connexions (flèches rouges) avec le sous-type qui va bien plutôt qu’avec VALEUR.

Cela dit, j'espère que les 18 cas ne fichent pas tout par terre, tout comme une mauvaise interprétation de ma part...


P.-S. Évitez de parler d’index au stade la modélisation !

_______________________________________
Fin du verbatim

⁽¹⁾ Au vu des sources latino/francique, "Parvus" et "Richard" sont un peu antonymes...

[fsmrel]

Une incidente :

Et si NULL veut dire "Tous", alors stockons "Tous" (ou "*ALL").

Code :

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

1
2
3
4
5
6
Correspondance      VALEUR      ARTICLE     CLIENT     DOSSIER
--------------------------------------------------------------------
                    Ventes      Roue        *ALL       *ALL
                    VentesVIP   Roue        DUPONT     *ALL
                    VentesVIP   Roue        DUPUIS     *ALL
                    VentesJUIN  Roue        *ALL       Réappro JUIN

Pour ma part, je préfère appeler un chat un chat : NULL prend plutôt ici le sens d’« inapplicable » au sens de Codd, c'est-à-dire « sans objet » (dont « tous » est ici une conséquence logique). Mais que l’on utilise le terme « tous» ou « sans objet », il ne s’agit là que de cache-misère, utilisables seulement au niveau d’une vue (d'union) à laquelle participent ARTICLE, CLIENT (ou COMMANDE), DOSSIER et VALEUR (ce qui est sous-entendu dans mon message précédent quand j’ai parlé d’amalgame et de vue). Autrement dit, au niveau des tables, exeunt NULL, « tous » et « sans objet ».

[Parvus]

Pour trouver ma valeur, j'ai besoin de ces différentes informations (dans l'ordre des priorités) :

• Article
  
  • Critère article 1
  • Critère article 2
  • Critère article 3
  • Critère article 4
  • Critère article 5
  • Classification article 1
  • Classification article 2
  • Classification article 3
• Client
  
  • Critère client 1
  • Critère client 2
  • Critère client 3
  • Critère client 4
• Type paiement
• Dossier
• Taxe

J'ai au total 17 informations différentes, qui permettent de retrouver une valeur spécifique. Cependant, ces 17 informations ne devraient jamais être toutes renseignées. Non pas qu'il y ai une contrainte spécifique, il est possible de le faire, mais cela n'a pas de sens ⁽¹⁾.

Un Article, contient des informations qui permettent de le ranger dans des "boites" (les 5 Catégories, les 3 Classifications), par exemple, les articles fragiles ou encore les articles périssables, un article pouvant cumuler cela (le nombre de catégorie/classification est totalement arbitraire, il est en effet possible d'en avoir plus que ce qui est indiqué).
Le principe est le même pour les Clients, qui peuvent être à titre d'exemple, des particuliers, des fournisseurs de produit dangereux, des supermarchés etc...
Le Type de paiement parle de lui-même (CB, chèque etc...) et la Taxe aussi (19.6, 5.5, 7 etc...) quant au Dossier il s'agit d'une notion un peu abstraite (ex : Réapprovisionnement JUIN, Achat Noël etc...) comme vu dans les messages précédents.

Toutes ces informations sont contenues, directement (articles, clients, type de paiement, dossier, taxe) ou indirectement (catégories, classification) dans une commande. Indirectement, car la classification et les catégories sont contenues dans l'article lui-même et le client (d'où les listes imbriquées).
Une commande :

• est passée par un et un seul client (1-1)
• peut contenir une ou plusieurs sous-commandes (1-n)
• est payée d'une seule façon : type de paiement (1-1)
• peut faire partie d'un dossier (0-1)

Une sous-commande :

• est rattachée à une et une seule commande (1-1)
• contient un et un seul article (1-1)
• est taxée d'un et seul pourcentage (1-1)

Avec ces différentes informations, je peux maintenant classer chaque sous-commandes en fonction des informations qu'elles contiennent. Je vais essayer d'être le plus exhaustif possible dans mes exemples pour expliquer comment sont classées les commandes car je ne pense pas pouvoir expliquer de façon assez précise le fonctionnement global. Avant cela, il est important de savoir que le classement est choisi par l'utilisateur, c'est lui-même qui choisi où ranger sa commande (il crée donc les valeur qu'il veut).

Les exemples :

1. Je veux que les sous-commandes soient par défaut dans un dossier "Vente"
2. Je veux que les sous-commandes de Mme Dupont soient dans un dossier "VenteVIP"
3. Je veux que toutes mes sous-commandes d'articles dangereux soient dans un dossier "Dangereux"
4. Je veux que mes sous-commandes de "Roue" soient dans un dossier "VenteRoues"
5. Je veux que toutes mes sous-commandes associées au dossier "Réappro. JUIN" soient classées dans "VenteJUIN"
6. Pour finir, je veux que toutes mes commandes de "Roue" passée par des clients "Particulier" soient dans un dossier "VenteRouesParticulier".

Ces affirmations se traduiront par :

1. Tous les champs avec '*All' et la Valeur à "Vente"
2. Le champ Client à "Dupont" le reste à '*All' et la Valeur à "VenteVIP"
3. Le champ Critère article 1 à "Article dangereux" le reste à '*All' et la Valeur à "Dangereux"
4. Le champ Article à "Roue" le reste à '*All' et la Valeur à "VenteRoues"
5. Le champ Dossier à "Réappro. JUIN" le reste à '*All' et la Valeur à "VenteJUIN"
6. Le champ Article à "Roue" le Critère client 1 à "Particulier" le reste à '*All' et la Valeur à "VenteRouesParticulier"

J'espère qu'avec ces exemples il sera possible de comprendre le fonctionnement de tout cela (si ce n'est pas le cas, n'hésitez pas à me reprendre sur certain point pour que je précise un peu plus).
Je vous remercie pour vos messages qui m'ont déjà permis d'avoir une vue un peu différente sur l'implémentation de cette fonctionnalité que ce à quoi j'avais pensé.

Je m'excuse de ne pas avoir fais de modèle concret, je vais essayer de me dégager un peu de temps pour faire quelque chose de plus propre pour la structure.

⁽¹⁾ si je précise un article spécifique par exemple, le fait de préciser un critère article n'a plus de sens car le critère permet d'englober un ensemble d'article alors que l'article précise 1 et 1 seul article.

________________________________________

Au vu des sources latino/francisque, "Parvus" et "Richard" sont un peu antonymes...

Vu sous cet angle, c'est tout à fait vrai !

[Richard_35]

Bonjour Parvus,

Ta ventilation analytique ne pourra donc ne se traiter que par code à partir de ta table Correspondance ayant la structure suivante :

Correspondance(Id_Correspondance, OrdrePriorité, Article, Critère article 1, Critère article 2, Critère article 3, Critère article 4, Critère article 5, Classification article 1, Classification article 2, Classification article 3, Client, Critère client 1, Critère client 2, Critère client 3, Critère client 4, Type paiement, Dossier, Taxe)
==> index unique sur OrdrePriorité

OrdrePriorité te permettra de jouer avec les priorités sans toucher à l'identifiant unique d'une règle de ventilation analytique.

Ensuite, lors du traitement d'une commande/sous-commande (en temps réel ou différé), il faudra balayer dans l'ordre des priotités la table Correspondance et s'arrêter lorsque les 17 informations de la sous-commande rentrent dans le giron de la règle de ventilation analytique (en tenant compte des différents *ALL).

Je ne vois pas d'autres solutions, en tout cas pas avec une simple requête.

PS : pardonnez mon inculture, mais si vous pouviez m'expliquer ce qui s'est passé entre Parvus et Richard, ça m'arrangerait... (je n'ai pas trouvé simplement, dans Wikipédia)

[fsmrel]

Bonsoir Parvus et Richard,

Ta ventilation analytique ne pourra donc ne se traiter que par code à partir de ta table Correspondance ayant la structure suivante :

Correspondance(Id_Correspondance, OrdrePriorité, Article, Critère article 1, Critère article 2, Critère article 3, Critère article 4, Critère article 5, Classification article 1, Classification article 2, Classification article 3, Client, Critère client 1, Critère client 2, Critère client 3, Critère client 4, Type paiement, Dossier, Taxe)
==> index unique sur OrdrePriorité

Hum... Indépendamment de NULL et de ses avatars, que deviendra la structure de la table quand de nouveaux critères, classifications et autres informations seront à prendre en compte (en rafales bien sûr...) ? Vous vectorisez, alors qu’en modélisation E/A ou Merise, on « verticalise », tout comme en relationnel.

Je rappelle par ailleurs que les index sont étrangers à la modélisation, il faut parler de clés (candidates ou alternatives).

La clé de l'assemblage des données « verticalisées » (pardon pour ce néologisme) est l’opération d’UNION (au sens relationnel ou SQL), mais on reviendra sur ce sujet.

Un Article, contient des informations qui permettent de le ranger dans des "boites" (les 5 Catégories, les 3 Classifications), par exemple, les articles fragiles ou encore les articles périssables, un article pouvant cumuler cela.

Merci Parvus pour vos explications détaillées et la qualité de votre rédaction, mais une question préalable : quelle différence y a-t-il entre un critère et une classification ? Y a-t-il une relation entre ces deux concepts ? De quel concept un article fragile et/ou dangereux relève-t-il ?

Le nombre de catégorie/classification est totalement arbitraire, il est en effet possible d'en avoir plus que ce qui est indiqué.

Le « en avoir plus » m’intrigue. Vous présentez 5 critères et 3 classifications comme éléments d’un ensemble de 17 éléments : si on peut en avoir N en plus, la cardinalité de l’ensemble passera à 17 + N...

Qu’en est-il ?


Pour le moment, je pense que le MCD que j'ai proposé sera à adapter, mais sa structure de base devrait aller, on vérifiera cela.

PS : pardonnez mon inculture, mais si vous pouviez m'expliquer ce qui s'est passé entre Parvus et Richard, ça m'arrangerait... (je n'ai pas trouvé simplement, dans Wikipédia)

En latin, parvus veut dire petit, humble et par extension, pauvre, tandis que riche vient du francique riki (et non pas francisque, coquille de ma part, corrigée...)
J’espère que vous me pardonnerez ce rapprochement approximatif sinon douteux...

[Parvus]

Bonsoir Fsmrel, bonsoir Richard

Correspondance(Id_Correspondance, OrdrePriorité, Article, Critère article 1, Critère article 2, Critère article 3, Critère article 4, Critère article 5, Classification article 1, Classification article 2, Classification article 3, Client, Critère client 1, Critère client 2, Critère client 3, Critère client 4, Type paiement, Dossier, Taxe)
==> index unique sur OrdrePriorité

Le problème avec cette structure, que je rencontre aussi, c'est qu'il est possible d'avoir plusieurs fois la même ligne de correspondance renvoyant vers une valeur différente :

Code :

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

1
2
3
4
Correspondance       Valeur       OrdrePriorite      Article
----------------------------------------------------------
                     Vente        1                  Roue
                     Vente2       2                  Roue

Je n'ai renseigné que l'article volontairement, les autres champs étant vide. Dans ce cas là, je ne peux pas savoir si je dois récupérer la valeur "Vente" ou "Vente2" dans le cas d'une commande de "Roue" (avec comme postula que l'ordre de priorité 1 et 2 font passer l'article comme prioritaire sur tout autres champs).

quelle différence y a-t-il entre un critère et une classification ? Y a-t-il une relation entre ces deux concepts ? De quel concept un article fragile et/ou dangereux relève-t-il ?

Ce sont deux concept qui se rejoignent, se ressemblent. Il n'y a cependant aucune relation entre un critère et une classification.

La classification est une table assez simple puisqu'elle est construite de cette façon :

Code :

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

Classification (Identifiant, Code, Designation)

Avec une contrainte d'unicité sur le "Code". La classification peut se résumer à une simple information "visuelle" pour les utilisateurs, cette information n'ayant aucun impact majeur sur l'applicatif.

La table des critères, quant à elle, est plus complexe puisqu'elle définie un article. Cette table contient un ensemble de valeur qui permet d'initialiser un article pour en faciliter la saisie.
Prenons ces deux exemples de critères ("inventé" pour l'occasion mais utilisé par tout le monde) :

• Produit fini : un article ayant cela comme critère sera par exemple "Fabriqué", "Vendu", "Géré en stock", "Stocké à l'unité".
• Matière première : un article ayant cela comme critère sera par exemple "Acheté", "Géré en stock", "Stocké au kg", "Non périssable".
• Dangereux : un article ayant cela comme critère sera par exemple "Fabriqué", "Acheté", "Stocké dans un environnement protégé", "Périssable".

Cela défini donc les règles de gestion de l'article, ce qui influe énormément sur l'applicatif. Pour reprendre l'exemple, un article fragile serait donc plus une classification (pour retrouver cette information sur un carton d’emballage par exemple) et un article dangereux serait plus un critère qui permettrait de définir des règles de gestion interne.

Le « en avoir plus » m’intrigue. Vous présentez 5 critères et 3 classifications comme éléments d’un ensemble de 17 éléments : si on peut en avoir N en plus, la cardinalité de l’ensemble passera à 17 + N...

Qu’en est-il ?

Il est effectivement possible d'avoir N éléments en plus. Cependant, dans la pratique, il est extrêmement rare qu'une personne utilise 5 critères et 3 classifications, la majorité étant d'environ 2-3 critères et 1-2 classification.

Pour le moment, je pense que le MCD que j'ai proposé sera à adapter, mais sa structure de base devrait aller, on vérifiera cela.

Le MCD que vous avez proposé correspond beaucoup à ce que j'ai déjà au niveau commande / article / client (le dossier étant directement lié à la commande). Cependant, j'ai peur que le dernier diagramme ne réponde pas tout à fait à mon besoin (mais j'avoue ne pas être sûr de l'avoir bien compris) étant donné qu'un article A avec un client C1 donnera une valeur V1 et que ce même article A avec un client C2 donnera une valeur V2.

_______________________________________________

En latin, parvus veut dire petit, humble et par extension, pauvre, tandis que riche vient du francique riki (et non pas francisque, coquille de ma part, corrigée...)
J’espère que vous me pardonnerez ce rapprochement approximatif sinon douteux...

Je ne sais pas pourquoi, richard m'a fait pensé à Richard coeur de lion que j'ai associé avec "Le grand". Il n'y a pourtant pas de rapport avec le roi et l'adjectif "grand" mais l'association c'est faite d'elle même.

[Richard_35]

Bonjour Parvus,

Le problème avec cette structure, que je rencontre aussi, c'est qu'il est possible d'avoir plusieurs fois la même ligne de correspondance renvoyant vers une valeur différente :

Code :

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

1
2
3
4
Correspondance       Valeur       OrdrePriorite      Article
----------------------------------------------------------
                     Vente        1                  Roue
                     Vente2       2                  Roue

Je n'ai renseigné que l'article volontairement, les autres champs étant vide. Dans ce cas là, je ne peux pas savoir si je dois récupérer la valeur "Vente" ou "Vente2" dans le cas d'une commande de "Roue" (avec comme postula que l'ordre de priorité 1 et 2 font passer l'article comme prioritaire sur tout autres champs).

==> non : la priorité impose l'ordre de lecture de la table correspondance lors du traitement de ventilation analytique. Sachant que

il faudra balayer dans l'ordre des priorités la table Correspondance et s'arrêter [de balayer la table] lorsque les 17 informations de la sous-commande rentrent dans le giron de la règle de ventilation analytique (en tenant compte des différents *ALL).

[Parvus]

Bonjour Richard,

la priorité impose l'ordre de lecture de la table correspondance lors du traitement de ventilation analytique.

Mea culpa, je n'avais pas bien compris l'utilité de la priorité.

Pour savoir si j'ai bien compris, est-ce que l'exemple suivant est juste ?

Code :

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

1
2
3
4
Correspondance      Valeur      OrdrePriorite     Article     Client
----------------------------------------------------------------------------
                    Vente       1                 Roue        *ALL
                    VenteVIP    2                 Roue        Dupuis

Si j'ai une commande de Roues de Mme Dupuis, dans ce cas là, ma valeur sera Vente.
Si j'inverse les ordres de priorité, alors, à ce moment là, ma valeur sera VenteVIP.
Est-ce bien cela ?

[Richard_35]

Code :

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

1
2
3
4
Correspondance      Valeur      OrdrePriorite     Article     Client
----------------------------------------------------------------------------
                    Vente       1                 Roue        *ALL
                    VenteVIP    2                 Roue        Dupuis

Si j'ai une commande de Roues de Mme Dupuis, dans ce cas là, ma valeur sera Vente.
Si j'inverse les ordres de priorité, alors, à ce moment là, ma valeur sera VenteVIP.
Est-ce bien cela ?

==> oui, c'est bien cela. Au moment de la recherche de la ventilation analytique d'une commande, c'est à toi de définir le moment où la recherche doit s'arrêter.

Si j'ai bien tout compris :

• les derniers enregistrements de la table comporteront beaucoup de *ALL : les ventilations analytiques "par défaut", en quelque sorte ;
• les premiers enregistrements de la table comporteront moins de *ALL : les ventilations analytiques "plus affinées", en quelque sorte.

Je reposte plus tard pour l'objection légitime de Fsmrel.

[Richard_35]

Je reposte plus tard pour l'objection légitime de Fsmrel.

Ta ventilation analytique ne pourra donc ne se traiter que par code à partir de ta table Correspondance ayant la structure suivante :
Correspondance(Id_Correspondance, OrdrePriorité, Article, Critère article 1, Critère article 2, Critère article 3, Critère article 4, Critère article 5, Classification article 1, Classification article 2, Classification article 3, Client, Critère client 1, Critère client 2, Critère client 3, Critère client 4, Type paiement, Dossier, Taxe)
==> index unique sur OrdrePriorité

Hum... Indépendamment de NULL et de ses avatars, que deviendra la structure de la table quand de nouveaux critères, classifications et autres informations seront à prendre en compte (en rafales bien sûr...) ? Vous vectorisez, alors qu’en modélisation E/A ou Merise, on « verticalise », tout comme en relationnel.

Effectivement, cela vaut le coup de se pencher dessus... dans le système "vertical", les tables seraient les suivantes :

Correspondance_Entete(Id_Correspondance, OrdrePriorité)
Correspondance_Detail(#Id_Correspondance, Critère, Valeur, Ventilation)

contenant :
Correspondance_Entete

Code :

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

1
2
3
4
Id_Correspondance  OrdrePriorité  Ventilation
1                  1              Ventes
2                  2              VentesVIP
...

et :

Code :

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

1
2
3
4
5
Id_Correspondance Critère                   Valeur
1                 Article                   Roue
2                 Article                   Roue
2                 Client                    Dupuis
...

Donc, plus généralement :
Correspondance_Detail

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Id_Correspondance Critère                   Valeur
1                 Article                   valeur particulière ou pas d'enregistrement
1                 Critère article 1         valeur particulière ou pas d'enregistrement
1                 Critère article 2         valeur particulière ou pas d'enregistrement
1                 Critère article 3         valeur particulière ou pas d'enregistrement
1                 Critère article 4         valeur particulière ou pas d'enregistrement
1                 Critère article 5         valeur particulière ou pas d'enregistrement
1                 Classification article 1  valeur particulière ou pas d'enregistrement
1                 Classification article 2  valeur particulière ou pas d'enregistrement
1                 Classification article 3  valeur particulière ou pas d'enregistrement
1                 Client                    valeur particulière ou pas d'enregistrement
1                 Critère client 1          valeur particulière ou pas d'enregistrement
1                 Critère client 2          valeur particulière ou pas d'enregistrement
1                 Critère client 3          valeur particulière ou pas d'enregistrement
1                 Critère client 4          valeur particulière ou pas d'enregistrement
1                 Type paiement             valeur particulière ou pas d'enregistrement
1                 Dossier                   valeur particulière ou pas d'enregistrement
1                 Taxe                      valeur particulière ou pas d'enregistrement
2                 Article                   valeur particulière ou pas d'enregistrement
2                 Critère article 1         valeur particulière ou pas d'enregistrement
2                 Critère article 2         valeur particulière ou pas d'enregistrement
2                 Critère article 3         valeur particulière ou pas d'enregistrement
2                 Critère article 4         valeur particulière ou pas d'enregistrement
2                 Critère article 5         valeur particulière ou pas d'enregistrement
2                 Classification article 1  valeur particulière ou pas d'enregistrement
2                 Classification article 2  valeur particulière ou pas d'enregistrement
2                 Classification article 3  valeur particulière ou pas d'enregistrement
2                 Client                    valeur particulière ou pas d'enregistrement
2                 Critère client 1          valeur particulière ou pas d'enregistrement
2                 Critère client 2          valeur particulière ou pas d'enregistrement
2                 Critère client 3          valeur particulière ou pas d'enregistrement
2                 Critère client 4          valeur particulière ou pas d'enregistrement
2                 Type paiement             valeur particulière ou pas d'enregistrement
2                 Dossier                   valeur particulière ou pas d'enregistrement
2                 Taxe                      valeur particulière ou pas d'enregistrement
...

En conséquence, comme le souligne Fsmrel, si un autre critère est ajouté, il suffit de créer un ou plusieurs enregistrements dans Correspondance_Detail (verticalité) qui "pointent" sur un enregistrement de Correspondance_Entete donnant la ventilation analytique.

Autre conséquence, plus de *ALL : ils sont remplacés par l'absence d'enregistrement.

[Parvus]

Merci beaucoup pour votre aide, avec vos réponses j'ai tous les éléments qu'il me faut pour avancer là-dessus. La solution en-tête / détail me paraît la plus appropriée.

Encore un grand merci pour votre aide.