Discussion :

[Azharis]

Bonjour tout le monde,

Je cherche à gérer un mieux un cas un peu complexe mais auquel je me heurte souvent et dont je n'ai jamais été très content de la solution.

Il s'agit d'un problème d'héritage mais qui tirerai plutôt sur des notions d'interface.

Avant de rédiger ce message, je suis passé par ce tuto : https://sqlpro.developpez.com/cours/...tion/heritage/
Ca marche très bien pour les cas en exemple, car les notions d'héritages sont associées à des données qui se ressemblent.

Maintenant mon problème (que je simplifie ici) :

Je dois valider des choses au travers de différentes étapes qui vont varier suivant l'élément.
Mais ce que je dois valider peut être de nature très hétérogène, par exemple : des produits, des lancements en productions, des packagings (voir des choses abstraites).

Donc basiquement, je voudrais créer une table PROCESS (qu iva englober les étapes) avec un id pour chaque élément qui peut être validé (id_produit, id_packaging...), et un seul id sera renseigné.
Et c'est ça que je ne trouve pas super, la liste des id (on peut imaginer avoir une dizaine d'id différents).

Donc en utilisant l'héritage, je pourrais faire une table PROCESS_ITEM dont hériterait tous les éléments (produits, packagings...).
Dans ma table PROCESS, je n'aurais donc plus qu'un id vers un PROCESS_ITEM.

Et c'est pour ça que je dis qu'il s'agit plus d'interface que d'héritage, car ca va rassembler des choses qui n'ont potentiellement rien à voir entre eux.

De plus, je vais avoir un autre problème du même genre mais qui n'a rien à voir avec de la validation, qui va concerner certains éléments ci-dessus, mais également d'autres.
Donc en objet, je pourrais faire une autre interface, et donner deux interfaces aux éléments voulus, mais en base de données ce n'est pas possible.

Ou alors je fini par faire hériter (quasiment) toutes mes tables par une table principal comme OBJET, mais à première vu, c'est extrêment mauvais.

Donc si vous avais de quoi m'aider, pour éviter de faire des listes d'id un peu de partout, je suis preneur.

Merci.

[CinePhil]

Donc basiquement, je voudrais créer une table PROCESS (qui va englober les étapes)...

STOP !

Vous êtes ici dans un forum de modélisation et vous allez trop vite directement vers les tables.

Écrivez les règles de gestion des données et la modélisation sera facilitée.

Revenez nous proposer ces règles de gestion et le début du schéma que vous aurez dessiné, de préférence avec un logiciel de modélisation.

[Azharis]

J'ai parlé de table pour essayer de rendre la chose plus compréhensible.
Mais je cherche surtout une solution à un problème courant.

Donc je vais essayer de résumer juste avec les règles de gestion du coup.

J'ai un process de validation.
Ce process pourra concerner tout un tas de choses dans ma base de données, des choses qui n'ont rien à voir entre elles.
Et ce nombre de choses pourra évoluer avec le temps.

Le but principal serait d'avoir un minimum de dépendance entre un process de validation et l'objet concerné.

L'idée première serait donc de gérer mes objets en héritage, comme ça j'aurais un lien entre le process et la table mère.
Mais ca forcerait à ressembler des objets qui n'ont pas vraiment la même nature.

En plus du process de validation, j'aurais d'autres fonctionnalités qui necessiterai le même besoin d'indépendance pour pouvoir faire évoluer l'ensemble le plus facilement possible.

[CinePhil]

Donc je vais essayer de résumer juste avec les règles de gestion du coup.

Alors donnez-nous au moins quelques règles de gestion en prenant des cas de validation de choses totalement indépendantes. Pour le moment, c'est trop vague pour qu'on puisse envisager une solution pertinente.

Mais ce que je dois valider peut être de nature très hétérogène, par exemple : des produits, des lancements en productions, des packagings (voir des choses abstraites).

Posez-vous la question aussi de savoir si ces processus de validation sont de même nature.
Un produit peut-être validé suite à des mesures, des tests...
Un lancement en production peut être validé par la vérification que toutes les données d'entrée (disponibilité des composants du produit final, des machines, commande suffisante pour justifier une série de production...) sont satisfaites.
Un packaging peut être validé par l'approbation du service design, de la direction, la faisabilité technique du packaging envisagé...

À vous de vérifier si ce ne sont pas des validations tellement différentes qu'en fait il faut les considérer séparément.

Vous pouvez aussi considérer l'héritage, non pas de ce que vous validez, mais de la validation.

Règles de gestion :
R1 : Une validation de produit est une validation et une validation peut être une validation de produit.
R2 : Une validation de lancement en production est une validation et une validation peut être une validation de lancement en production.

MCD :
validation_produit -(1,1)----être----0,1- validation
validation_production -(1,1)----être---0,1----|

Tables :
te_validation_val (val_id, [colonnes communes à toutes les validations])
th_validation_produit_vpd (vpd_id_validation, [colonnes spécifiques aux validations de produit])
th_validation_production_vpr (vpr_id_validation, [colonnes spécifiques aux validations de production])

[Azharis]

Pour ce qui est de l'héritage de la validation, il y en aura surement mais au niveau de chaque étape de la validation.
Pour savoir comment valider une étape (booléen, nombre entier, liste de valeur...).

Après la validation elle-même, elle doit au final me renvoyer un booléen pour dire si c'est OK ou pas.
La validation doit masquer toute la complexité des étapes de validation.

Je viens de faire le résumé de ce que je pense pour le moment :



A droite : les différents objets (j'ai pas mi le détail, et potentiellement il y en aura beaucoup plus).
A gauche : toute la gestion d'un process de validation (je parle de validation, mais en fait il s'agit d'un workflow, qui pourait gérer autre chose que des validations).
Au milieu : des interfaces entre des choses métiers (demande d'échantillon, validation licence...), et des objets qui peuvent être concernés.

Tout n'est pas rigoureusement juste, j'ai juste voulu modéliser mon problème qui concerne les tables process, echantillon_item, licence_item qui possèdent des liste d'id qu'il faudra enrichir au fur et à mesure que de nouveaux objets s'ajouteront.

Et ce que je recherche, c'est si il existe une méthode plus intéressante pour gérer ce genre de problème de "switch/hub" de tables.

Meri.

[CinePhil]

Je viens de faire le résumé de ce que je pense pour le moment :

Et toujours sans règle de gestion des données...

Commençons par le côté process qui, si j'ai bien compris, est votre process de validation...

1) Vous avez une boucle process -> scenario -> etape_scenario -> process qui fait que vous pouvez enregistrer dans le process une étape de scénario qui ne fasse pas partie des étapes du scénario associé au process !

2) En plus, sauf si vous avez mis une contrainte d'unicité, vous pouvez avoir plusieurs fois la même étape de scénario pour un même process.

3) Ce que je crois comprendre est qu'un process est constitué d'étapes et que ce sont ces étapes qui respectent un scénario donc qui sont associées au étapes de scénario.
Vous avez mis des associations partout ; c'est le bordel !

Ceci dit, vous n'échapperez peut-être pas à un problème de boucle mais il sera temps de le résoudre quand vous aurez enfin compris qu'il faut commencer par les règles de gestion des données pour ne pas faire n'importe quoi !


Ensuite, vous avez deux solutions :
A) Soit vous faire un héritage des "choses" à valider et c'est cette "chose" que vous associez au process ;
B) Soit vous faites un héritage des validations, comme je l'ai proposé dans mon message précédent et vous associez chaque type de "chose" à chaque type de validation.


Votre table licence_item me laisse à penser qu'il n'y aura, pour une ligne de la table, qu'une seule des clés étrangères qui sera renseignée. De plus, si vous ajoutez un nouveau type de chose objet d'une licence, vous devrez modifier la structure de votre table et les programmes qui utilisent la table.
=> C'est le signe typique d'une mauvaise modélisation des données !


Enfin, j'ai aussi l'impression que votre modèle est pour le moment un modèle générique : Un produit de type biglotron doit être validé selon le process 12 qui suit le scénario 5.
Mais je pense que vous devrez enregistrer ensuite les résultats pour le biglotron n° 8224 produit par la mise en production 2019-10, non ?
Enfin, on verra ça plus tard...

[Azharis]

Vous avez mi le doigt exactement sur le problème.

=> C'est le signe typique d'une mauvaise modélisation des données !

C'est ça, dans la liste des id, un seul sera renseigné à chaque fois. Et c'est ça que j'aimerai savoir si on peut faire autrement.

Mais c'est le contexte qui est compliqué.

Je souhaite rendre les choses un maximum indépendante, car les règles des gestions changeront avec le temps. L'objectif est donc de pouvoir faire évoluer une partie de l'application sans mettre en péril le reste.
C'est l'entreprise qui fonctionne comme ça, je n'y peux rien. Si je fais des choses trop vérrouillées, dans 6 mois on refait tout.

Comme par exemple, le détail que vous avez donné des scénarios. Un process est lié un scénario. Dans l'idéal, lorsqu'une étape est validé, on avance à l'étape suivante. Mais dans la réalité, on va aussi faire des boucles sur certaines étapes. Et pire, dans certains cas, on va sortir du scénario.
Il faut un truc méga flexible.

D'où toutes ces tables. Et c'est pour ça que je ne voulais pas proposer mon modèle, mais plutôt poser le problème général qui est cette liste d'id avec un seul renseigné.

[CinePhil]

Il faut y aller étape par étape. Comme a dit mon chef en réunion hier : "En informatique, on ne sais pas résoudre des gros problèmes mais des petits... les uns derrière les autres."

Comme par exemple, le détail que vous avez donné des scénarios. Un process est lié un scénario. Dans l'idéal, lorsqu'une étape est validé, on avance à l'étape suivante. Mais dans la réalité, on va aussi faire des boucles sur certaines étapes. Et pire, dans certains cas, on va sortir du scénario.

Je commence à écrire des règles de gestion sur ce que je comprends et je vous laisse continuer et dessiner le MCD en conséquence (ou le Entity/Relationship Diagram de MySQL Workbench mais vu la complexité du truc, ce serait vraiment mieux de commencer par un MCD). Vous pouvez utiliser JMerise ou DBMain pour faire un vrai MCD.

Règle de gestion :
R1 : Un scénario comprend de une à plusieurs étapes et une étape est comprise dans un scénario.
=> À vous de savoir si une étape peut faire partie de plusieurs scénarios, auquel cas il faut modifier la règle de gestion, ce qui change le MCD et encore plus les tables !
=> Selon ma règle de gestion, une étape ne peut exister en dehors d'un scénario. Il convient donc d'utiliser l'identification relative dans le MCD.

MCD 1 :
Scenario -1,n----comprendre----(1,1)- Etape_scenario

=> Cardinalités entre parenthèses = identification relative. La table issue de Etape_scenario aura pour identifiant un couple de colonne composé de l'identifiant du scénario et un numéro d'ordre ou un auto-incrément classique. Voir ci-dessous. Il ne s'agit pas d'un héritage de données mais d'une composition. Ce mode d'identification est d'ailleurs utile pour contrer les effets de boucle ; nous y reviendrons en temps utile.

Tables :
te_scenario_scn (scn_id, scn_code, scn_nom...)
te_etape_scenario_esc (esc_id_scenario, esc_numero...)

Dans l'idéal, lorsqu'une étape est validé, on avance à l'étape suivante. Mais dans la réalité, on va aussi faire des boucles sur certaines étapes. Et pire, dans certains cas, on va sortir du scénario.

On verra cette partie plus tard.


Voilà la démarche que vous devez entreprendre.
Et commencez aussi par définir clairement la notion de process par rapport au scénario parce que ce n'est pas clair pour moi.
Est-ce que le scénario fait partie d'un process plus global et comprenant d'autres choses ?
Est-ce que le process est l'application particulière d'un scénario à une "sorte de chose" ou même à une "chose" ?

[Azharis]

Un process est une liste d'étapes rattachée à une chose (ex : demande d'échantillons, validation d'un visa, production d'un article).
Un process suivra un scénario, mais pourra y déroger si nécessaire (le scénario pré-défini sert d'aide à la saisie pour 90% des cas).
Lors de la validation d'une étape :
- soit on passe à l'étape suivante logique
- soit le process est fini (c'était l'étape finale, réussite ou échec)
- soit on passe à une autre étape (retour arrière pour boucler, étape spécifique pour un cas particulier et dans ce cas on sort du scénario)

Potentiellement, chaque étape pourrait être attachée à un service, ce qui permettrait de faire une todo list. Mais ca, c'est très hypotéthique.

Il y aura une grande diversité de choses, et ça évoluera avec le temps.

[CinePhil]

Je commence à me demander si votre souci ne relève pas plutôt du domaine dynamique que du domaine statique.

Une base de données contient des données cohérentes à un instant T : c'est statique.

Pour modéliser un enchaînement d'opérations, on utilise plutôt, en méthode Merise, un MCT (modèle conceptuel des traitements) ou en UML un diagramme de séquence.

J'ai du mal à comprendre en quoi une demande d'échantillon est un process qui doit subir une validation.
Sur le plan statique des données, on peut modéliser une demande d'échantillon avec une référence à un produit qui est fabriqué par un fournisseur ; la demande a une date de demande et une date de réception de l'échantillon. Tout tient en une table et c'est l'application qui gère les demandes d'échantillons qui va gérer les étapes et enregistrer l'initialisation de la demande avec sa date de demande et sa fermeture avec la date de livraison de l'échantillon.
À moins que ce dont vous parlez soit totalement différent, je ne vois aucun process à modéliser en base de données pour ça.
Par contre, la demande d'échantillon elle même peut faire partie d'un process général de fabrication d'un produit, entre les phase de design et de lancement en production. Cela constituerait donc plutôt une étape d'un process.

Bref, votre notion de process n'est toujours pas claire pour moi !

Dans quel contexte industriel êtes-vous ? Ça pourrait déjà aider à la compréhension.

[Azharis]

Je m'exprime surement mal.

Il est vrai que quand il y aura une demande d'échantillon, au final je vais un oui ou un non.
Mais ca ne se fera pas en une étape.
Pour être concret, il va falloir faire une demande d'échantillon au fournisseur, puis réceptionner les échantillons, les faire valider par un service, puis un autre, puis envoyer au client, puis recevoir la validation du client.
A ce moment là, je peux définir si ma demande est validée ou pas.
Chaque étape stockant des informations (qui, quand, pourquoi, fichiers liés...).

Sauf qu'avec l'expérience, on a pu constater que ce fil d'étape, à besoin d'être un peu plus flexible.

Et dans un autre module de l'application qui est la validation des licences, on se retourve à avoir le même comportement théorique : suivant la licence et l'objet que l'on valise, il y aura une ou pluseurs étapes à valider.

Et l'idée aurait été d'extraire cette notion d'étapes de validation (process) afin de pouvoir l'appliquer à tout ce qu'on aura besoin.

Donc pour revenir sur le modèle statique, à un instant t, je pourrais connaitre par exemple toutes les demandes d'échantillons en cours, et l'étape où en est chacune.

Le soucis c'est pour traiter les données en SQL (et en PHP) le plus simplement possible.

Pour l'instant je suis parti sur une liste d'id avec un seul qui soit renseigné à la fois. Donc ca veut dire se lier en plein de tables en SQL si on veut un bilan de tous les process par exemple.
Ca fonctionne, mais la question aurait été de savoir si pour des personnes qui ont surement plus d'expérience que moi (j'en ai quand même pas mal), et qui ont travaillé sur des projets importants, ils ont surement rencontré ce même genre de problème de devoir se lier a des tables qui n'ont pas forcément de liens entre elles. Et d'après leur expérience, est-ce que la liste des id est une bonne solution avec un travaille important en PHP par exemple, ou alors est-ce que ce genre de modèle fini par dérailler et qu'il faut mieux passer par d'autres techniques (mais je ne vois pas comment).

Donc c'est plutôt un retour d'expérience sur ce genre de problèmes que je viens chercher, plutôt qu'une réponse à un problème concret.

Pour moi, ça restera comme ça, et le travaille se fera en PHP pour essayer d'être le plus rapide possible.
Mais ca fait longtemps que je rencontre ce problème, et à chaque fois je me demande si il n'existe pas une meilleure technique.

Par exemple, au lieu de mettre une liste d'id, mettre un seul id et un champ énuméré qui va préciser quelle table est concernée.
C'est une autre technique, la table est plus "propre", et en cas d'ajout d'objet, on ajoute une valeur à l'énuméré, et pas une nouvelle colonne id.
Mais dans ce cas, fini les clés étrangères. Ce qui est affreux à mon sens.

J'espère avoir été clair.

En tout cas merci pour vos réponses.

[CinePhil]

Pour être concret, il va falloir faire une demande d'échantillon au fournisseur, puis réceptionner les échantillons, les faire valider par un service, puis un autre, puis envoyer au client, puis recevoir la validation du client.
A ce moment là, je peux définir si ma demande est validée ou pas.
Chaque étape stockant des informations (qui, quand, pourquoi, fichiers liés...).

Là je vois un processus de TRAITEMENT d'un échantillon plus qu'un processus de validation. La validation est une étape (finale) du processus.

Donc si on découpe ça, un échantillon est :
- demandé à un fournisseur à une date D1 ;
- réceptionné à une date D2 > D1 ;
- validé ou refusé par un à plusieurs services à des dates Dx > D2 ;
- envoyé au client à une date D3 > toutes les Dx suite à la validation par les différents services ;
- validé par le client à une date D4 > D3 ;
- validé en interne par X à une date D5 > D4.

En terme de données, on a besoin de :
- une référence de demande d'échantillon (j'imagine, ainsi peut-être qu'une description, une référence à un produit, une commande...) ;
- la référence à un fournisseur ;
- des dates ;
- des témoins de validation booléens ;
- la référence à un client (sauf si on passe par le biais d'une référence à une commande de ce client) ;
- peut-être des commentaires associés aux témoins de validation.

Est-ce que c'est ça que vous appelez scénario ?

Vite fait, on peut modéliser ainsi...

Règles de gestion :
R1 : Un échantillon est demandé à un fournisseur et un fournisseur peut se voir demander plusieurs échantillons.
R2 : Un échantillon est proposé à un client et un client peut se voir proposer plusieurs échantillons.
R3 : Un échantillon est validé par un à plusieurs services et un service peut valider plusieurs échantillons.

MCD :
Client -0,n----proposer----1,1- Echantillon -1,1----demander----0,n- Fournisseur
Service -0,n----valider----1,n---------|

Tables :
te_client_clt (clt_id,...)
te_fournisseur_frn (frn_id...)
te_service_srv (srv_id,...)
te_echantillon_ech (ech_id, ech_id_client, ech_id_fournisseur, ech_date_demande, ech_date_reception, ech_date_envoi_client, ech_date_retour_client, ech_ok_client, ech_ok_final...)
tj_ech_valider_srv_evs (evs_id_echantillon, evs_id_service, evs_date_envoi_echantillon, evs_date_validation, evs_ok_service...)

Et dans un autre module de l'application qui est la validation des licences, on se retourve à avoir le même comportement théorique : suivant la licence et l'objet que l'on valise, il y aura une ou plusieurs étapes à valider.

Décrivez le processus des licences et en le modélisant, on verra ce qu'on peut généraliser.

[Azharis]

Tout ceci est juste, mais la partie qui me pose problème est le faite qu'un échantillon puisse être de nature très différente.
Et c'est ce lien entre mon parcours de traitement et l'objet que ca concerne que j'aimerai faire le plus propre possible.

Pour les licences, le coeur reste le même fonctionnement. Des témoins de validation plus ou moins nombreux suivant ce qu'on valide et la licence concernée, sur des objets de natire différentes (un produit, un packaging, un lancement en production...).

[CinePhil]

la partie qui me pose problème est le faite qu'un échantillon puisse être de nature très différente.

Expliquez plus concrètement.

Et vous remarquerez que dans ma table te_echantillon_ech, il n'y a rien qui concerne la nature de l'échantillon.
Si vous avez besoin de spécialiser les échantillons selon leur type, faites un héritage !

Pour les licences, le coeur reste le même fonctionnement. Des témoins de validation plus ou moins nombreux suivant ce qu'on valide et la licence concernée, sur des objets de natire différentes (un produit, un packaging, un lancement en production...).

Soyez plus précis !
Une licence sur un produit ; j'arrive à comprendre.
Une licence sur un packaging ; j'ai déjà plus de mal.
Une licence sur un lancement en production ; je ne vois vraiment pas de quoi il peut s'agir !

Bref, pour la Nième fois, écrivez vos règles de gestions des données (aspect statique) pour vous aider à modéliser ça correctement par un MCD !