Discussion :

[StringBuilder]

Bonjour,

Je me pose une question à propos d'un modèle des données.

Le modèle utilise des clés composées. En donnant l'exemple du modèle, j'ai réfléchi à l'intérêt de mettre des clé atomiques, ça ne change rien au problème, donc je laisse le modèle "tel quel".

J'ai trois tables :
TTI (Type de tiers)
typtie
typfam (type tiers de la famille) fk vers TTI.typtie
nom

FAM (Famille)
typtie (type de tiers)
codfam (code de la famille)
nom

TIE (Tiers)
id
typtie (type du tiers) fk vers TTI.typtie
codfam (code famille) => Comment faire la FK ?

Explication :
Un tiers de type "CLI" client doit être dans une famille de type "CLI" (client).
Un tiers de type "PRO" prospect doit être dans une famille de type... "CLI" (client).
C'est donc le sens du champ TTI.typfam.

Lorsque je crée un TIE (tiers) de typtie "PRO", alors je dois saisir une famille de typtie "CLI".

Comment matérialiser un contrôle simplement ?

Je peux le faire avec un trigger, mais c'est assez lourd.

N'existe-t-il pas un mécanisme entre la FK et le trigger, qui permette de faire une FK conditionnée par une fonction ou une requête ?

C'est à dire, au lieu d'avoir :

TIE.CODFAM references FAM.CODFAM

Avoir :

(TIE.TYPTIE, TIE.CODFAM) references (select tti.typtie, fam.codfam from tti inner join fam where fam.typtie = tti.typfam)

Ou un mécanisme du genre ?

La solution permettant d'avoir une FK serait de recopier le TYPFAM dans la table TIE, mais on va à l'encontre des bonnes pratiques de modélisation, puisqu'on duplique de l'information pour rien, et surtout, rien n'empêchera alors d'avoir un tiers qui est rattaché à un type de famille qui n'a rien à voir avec celui déclaré dans TTI...


Aussi, existe-t-il un mécanisme permettant de faire pointer une FK sur un champ d'une vue et non d'une table ? (champ non calculé, la vue servant juste de filtre)

[Richard_35]

Bonjour StringBuilder,

Intéressant...

De par :

Un tiers de type "CLI" client doit être dans une famille de type "CLI" (client).
Un tiers de type "PRO" prospect doit être dans une famille de type... "CLI" (client).

==> il me semble qu'il manque une entité .

Si j'ai bien compris, tu as le schéma suivant (désolé, j'ai renommé les entités car j'ai travaillé sur un document à part et c'est plus parlant) :

Code :

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

1
2
3
Tiers -1,1---[Etre de type]---------1,n- TypeTiers -1,1---[Etre du type de famille]---1,n- TypeFamille
  |                                                                                            |
  |----1,1---[Etre de la famille]---1,n- Famille ---1,1---[Etre du type de famille]---1,n------|

ce qui donnerait les tables suivantes :

TypeFamille(IdTypeFamille, nom, …)

Code :

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

1
2
1   CLI
2   XXX

Famille(IdFamille, nom, #IdTypeFamille, …)

Code :

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

1
2
3
1   Famillex   1
2   Familley   1
3   Famillez   2

TypeTiers(IdTypeTiers, nom, #IdTypeFamille, …)

Code :

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

1
2
3
4
1   Client       1
2   Prospect     1
3   TypeTiers1   2
4   TypeTiers2   2

Tiers(IdTiers, nom, #IdTypeTiers, #IdFamille, …)

Code :

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

1
2
3
4
1   Tiers1   1   1
2   Tiers2   2   1
3   Tiers3   3   2  
4   Tiers4   4   2

Mais, je ne suis pas certain d'avoir bien compris.

[StringBuilder]

Hmmm, en effet, c'est tout bête.

Foutue modélisation où les mêmes entités servent à plusieurs choses à la fois... En effet, même si c'est le même code, TYPTIE != TYPFAM. Ça devrait donc être deux entités distinctes...

Je suis trop pollué par la façon de penser de l'ERP sur lequel je bosse : à force de vouloir rendre le modèle de données générique en utilisant les mêmes tables pour gérer plusieurs entités, ça devient un joyeux bordel dans ma tête ^^

[Richard_35]

C'est vrai.

En fait la phrase qui tue est :

Un tiers de type "CLI" client doit être dans une famille de type "CLI" (client).
Un tiers de type "PRO" prospect doit être dans une famille de type... "CLI" (client).

qui ne veut pas dire la même chose que :

Un tiers de type "CLI" client doit être dans la famille "CLI" (client).
Un tiers de type "PRO" prospect doit être dans la famille "CLI" (client).

[StringBuilder]

En fait, le modèle se lit plus exactement "Les CLI sont du même type de famille des CLI, qui est CLI", et "Les PRO sont du même type de famille que les CLI, qui est CLI". Il y a fusion entre "type de famille" et "type de tiers". C'est en effet, le cas, puisque dans la table "famille", on n'a pas de "typfam", mais bien un "typtie".

Il s'agit d'une "astuce" pour rendre le modèle plus compact tout en conservant sa généricité, mais en même temps, ça oblige à dénormaliser : dans l'ERP, il n'y a aucune clé étrangère, tout est géré au niveau du logiciel. Au premier abord, ça semble une hérésie. En regardant de plus près, on se rend compte que ça permet de rendre paramétrage les clés étrangères, ce qui est obligatoire quand on regarde ce qui est stocké dans certains champs (selon des valeurs, les mêmes champs ont pour référence des tables différentes, le tout étant décrit dans des tables de paramétrage) Un peu le bordel, mais super puissant.

[pachot]

Bonjour,

Un peu le bordel, mais super puissant.

super puissant pour stocker n'emporte quoi, oui, mais pas très puissant pour stocker des données intègres, performantes, et accédées par plusieurs utilisateurs en même temps.

C'est sûr, on peut aussi tout stocker dans une seule table avec une colonne TYPE et une colonne texte où on peut mettre un peu n'importe quoi dedans. C'est effectivement - et malheureusement - le cas de beaucoup d'ERP qui semblent avoir été modélisés du temps des cartes perforées.

Si 2 enregistrements n'ont pas la même foreign key, alors ils n'appartiennent pas à la même table. En objet, ce seraient peut être 2 spécialisations d'un même héritage. En relationnel, c'est 2 tables.

Le temps que l'on gagne à faire du générique sans modélisation stricte sera perdu plus tard pour débugger des erreurs d'exécution, des données corrompues, des problèmes de performances,...

Cordialement,
Franck.

[Richard_35]

Bonjour Franck,

Effectivement, cela peut paraître étonnant... mais bon, les ERP doivent prévoir le multi-plateformes, le multi-OS, le multi-bases de données... difficile.

J'ai "tâté" un peu de HR ACCESS (progiciel RH) qui, lui, utilise bien des clés primaires et étrangères, mais qui a pris l'option "une table par champ" (pratiquement), du moins dans la version "tâtée" en question. Cela ne marche pas trop mal, en final, mais cela paraît bizarre pour le commun des "BdDeurs".

[StringBuilder]

Le vrai problèmes des ERP surtout, c'est qu'ils doivent proposer une base de données et des programmes qui s'adaptent aux besoins du client, sans devoir systématiquement modifier le modèle des données ou les programmes.

Par conséquent, certes, c'est parfois contre-performant (et encore, ça demande à être mesuré), l'intégrité n'est pas toujours gérable au niveau de la base, etc. mais en contre-partie, le programme est capable de s'adapter aux flux de l'entreprise en modifiant juste le paramétrage, et ainsi le comportement des tables et programmes.

Generix, pour ne parler que de lui, puisque c'est le seul que je connais très bien, est justement conçu dans cette optique. Un jeu de table restreint permet de gérer un nombre "infini" de flux, dont le nombre d'étapes peut à nouveau être "inifini".

C'est à dire qu'au lieu d'avoir par exemple un flux "devis->commande->livraison->facture" on peut avoir "devis->commande->expédition container vers plateforme->tranpalletisation->livraison pdl->livraison particulier->facture" (par exemple). Le tout avec les mêmes tables et les mêmes binaires.

D'autres ERP, tels que Navision, préfèrent la génération à la volée de nouvelles tables et de binaires. J'imagine que cette vision est plus "propre", au détail près que l'éditeur et l'intégrateur ne maîtrisent rapidement plus ce qui est chez le client, et qu'ils sont incapables de transposer son savoir-faire d'un client à l'autre.

C'est tout du moins mon avis.