Discussion :

[Invité]

Bonjour,

Après avoir réfléchi à mon problème, la solution qui me paraissait être la meilleure se révèle ne pas être la bonne dans tous les cas. J'ai donc panser à d'autres possibilités, mais à chaque fois, quelque chose me chiffonne dedans, donc je viens vous demander votre avis.

En fait, il faudrait que j'arrive à modéliser (pour une future base), des sortes de catégorie finale (en bout de chaîne et identifiée par un id unique) faisant partie de catégories étant elles-même dans d'autres catégories, etc ...


Mon problème est qu'une catégorie (en tout cas sa désignation) peut se retrouver dans plusieurs catégories, exemple avec Ballon ci-dessous :



Je pensais faire des catégories génériques et unique (par leur désignation on va dire), du coup ballon n'aurait été qu'une catégorie dans ma base, ce qui aurait donné au final quelque chose comme ça :


Mais, d'après ce modèle, comment savoir si le ballon que j'ai sélectionné fait partie de matériel ou basket directement ?

Voilà j'espère que quelqu'un pourra m'éclairer afin de voir si les autres solutions auquelles j'ai pu penser peuvent-être valable (je l'ai détaille pas ici, car j'en ai plusieurs :p )

Merci

[gwen_oc]

je suis pas experte du tout, mais je crois que c'est pas possbile directement (a moins bien sur de mettre un champs "sport" dans ballon, mais ça sert pu a grand chose de faire une base pour çà)...

vu ton schema, c'est comme si tu avais 2 bases distinctes

je ferai plutot une table "ballon", reliée a une table "sport", et ensuite tu spécialise en fonction des sports que tu veux mettre

en gros :

ballon --- sport
+rouge -> Foot
+bleu + champs pour Foot
+... -> Basket
+ champs pour Basket

je pense que tout ce qui est "commun" (comme ballon, chaussures...) doit avoir sa propre table et ensuite etre relié au sport spécifique


tu as surement du faire l'exemple tres scolaires de "gestion d'eleves", une table eleve, une table classe, une table prof, et tu les attache ensemble
et non pas une table classe avec a linterieur les eleves...

jarrive pas trop a mexpliquer mais je n'ai pas de logiciel pour te faire le schema

hesite pas a reposter

bon courage ! ça a pas l'air tres compliqué

[Invité]

En fait j'ai pas été très maline, car j'ai posté des schéma d'exemples inventés, et pas les vrais exemples (trop complexes lol).

En fait il s'agit de catégorie d'erreurs. Ces erreurs sont identifiables par un numéro unique à 4 chiffres. Pour simplifier le système d'erreurs, des catégories ont été créées.

Donc en fait une erreur fait partie de plusieurs catégories, rangées les une dans les autres. Tout d'abord la catégorie très généraliste A, puis plus détaillée B, encore plus détaillée C , toujours et encore plus détaillée D, etc ...

Sauf que parfois, une catégorie (exemple C) peut se retrouver dans une autre catégorie généraliste X. Le seul point commun entre les deux catégorie C, c'est l'appelation de la catégorie (et l'identifiant si on dit que c'est la même catégorie). C'est d'ailleurs tout ce qu'il y a dans les catégories.
Du coup si je dis que les deux C sont la même catégorie, je n'ai plus aucun moyen de savoir par la suite, si je parle de C dans A ou C dans X, et c'est là le problème.

Schématisation :



On voit bien deux fois la catégorie B, D et E à des niveaux différents et dans des catégories différentes.

Je sais pas si je suis claire. En tout cas merci de ta réponse !

[gwen_oc]

si si cest bien clair t'inquiete

je me pose dessus en soirée, repasse dans la nuit...

[Invité]

Ok merci beaucoup, parce que j'ai de gros doutes sur comment faire ça.

[JPhi33]

poopsinou, je trouve normal que tu aies ce problème. Si je prends l'exemple de la catégorie D dans ton dernier schéma, tu modélises le fait que D peut avoir 2 mères : C et I.
C --> D
I --> D
Ensuite tu veux, simplement en regardant D et ses liens, savoir si sa mère est C ou bien I. C'est impossible : ce n'est pas ce que tu as modélisé. Tu modélises tous les "chemins" possibles, mais ce dont tu as besoin (sous réserve que j'aie bien compris le sujet), ce sont des "chemins" particuliers, des "contextes".
Dit autrement :
- ce que tu modélises : D est fille de C et de I


- ce que tu veux : D dans le contexte "fille de C" et D dans le contexte "fille de I".


La modélisation conceptuelle (MCD MERISE) correspondant au premier cas est


et son modèle logique


(dans ma notation, "#" marque un identifiant, le soulignement marque une clé étrangère. La table LIEN est identifiée par des clés étrangères, cas typique des tables issues d’associations)

Exemple d’illustration :


Ce que tu veux, c’est situer les liens dans un "contexte" particulier (qui peut être nommé "chaîne" ou "hiérarchie" par exemple). Je propose cette modélisation :

MCD :


MLD :


Table LIEN avec l'exemple :


Cette modélisation contraint à propager le CONTEXTE tout au long de la chaîne de liaison, mais elle répond au problème.


Par contre, si tu as un moyen de connaître à tout instant le contexte dans lequel tu te trouves, il est possible de modéliser de cette façon :
MCD :


MLD :


Dans la table LIEN, la clé étrangère CONTEXTE n’est plus un identifiant. De plus, elle est facultative (cardinalité 0,1) donc on peut ne la renseigner que lorsque c’est nécessaire.


En contrepartie, dans cette denière modélisation, tu ne peux pas retrouver tous les liens faisant partie d’un contexte. A toi de choisir.



J’espère ne pas être à côté de la plaque et que cette solution pourra t’aider.

[Invité]

Merci pour ton message.

Je pense à peu près avoir compris ta solution, mais je ne vois pas comment la mettre en oeuvre, ni ce que représenterait contexte.
Et je suis pas sûre que ça marcherait tout le temps.

Exemple :


Prenons Elt5. En partant de lui, (puisque l'on partira toujours des éléments pratiquement) : on sait qu'il fait parti de C mais ensuite comment savoir qu'il fait parti de E et non de B ?

[JPhi33]

Je vais te montrer comment se traduisent concrètement les deux modélisations que j'ai proposées avec ton exemple. Ce que j'ai appelé "contexte" peut être nommé "chaîne" qui semble être un terme plus approprié au vu de ton exemple.

Dans le 1er MCD, l'association LIEN est ternaire. La table LIEN qui en est issue contient 4 chaînes :

1 : A --> B --> C
2 : A --> B --> D
3 : A --> E --> C
4 : A --> E --> D

enregistrées comme suit dans la table :


Elt5 fait partie de la chaîne 3 et il est rattaché à C. Dans la chaîne 3, la mère de C est E et la mère de E est A. Tu retrouves toutes les sur-catégories. C'est bien ce que tu voulais ?

Evidemment, dans cette 1ère modélisation, il y a des informations redondantes par rapport à ton exemple. En effet, B est fille de A, et cà, que l'on soit dans la chaîne 1 ou dans la 2. On pourrait donc se passer d'une des 2 lignes : le lien A --> B est indépendant de la chaîne. Idem pour le lien A --> E. Rien que dans ton exemple, on économise 20% du volume de la table LIEN.

C'est pourquoi j'ai proposé une 2e modélisation. Mais comme je te l'ai dit, il y a une condition : elle est que tu dois avoir le moyen de savoir dans quelle chaîne tu te situes. Comme je ne connais pas le reste de ton environnement fonctionnel, je vais faire 2 suppositions (toujours au vu de ton exemple) :
1) qu'un élément donné ne peut se situer que dans une chaîne
2) que tu pars toujours d'un élément final

Si elles sont exactes (tu me le diras) alors tu peux à tout instant savoir dans quelle chaîne tu te situes : il suffit de relier l'élément final à la chaîne. Dans ces conditions, seuls les liens des catégories ayant plusieurs mères doivent être enrichies par la chaîne. La table LIEN dans le 2e MCD avec ton exemple :


Le 2e MCD complété avec l'élément final relié à la chaîne.


Tu noteras la cardinalité (0,1) qui signifie qu'il n'est pas nécessaire de lier un élément à une chaîne dans le cas où cette chaîne ne contient aucune catégorie ayant plusieurs mères.

Voila, j'espère avoir été plus clair cette fois-ci.

[gwen_oc]

la classe JPhi33 !

[JPhi33]

Merci gwen_oc, ça me va droit au coeur !

[Invité]

Merci pour les réponses.

Donc en gros si j'ai bien compris l'histoire des chaînes, il faut que j'enregistre la "chaîne" pour l'élément si ce dernier est contenu dans une categorie qui est elle-même contenue dans une catégorie et ainsi de suite, c'est ça ?

Par contre concrètement, les "chaînes" ne représentent rien ? Elles sont juste là pour donner une indication de plus sur le fait qu'une catégorie appartient à telle catégorie et ainsi de suite, c'est ça ?

Par contre, si un élément se retrouve sur 2 chaines, comment ça marche du coup ? Exemple :



Peut-être que j'ai encore compris de travers

[JPhi33]

poopsinou, dans ton exemple je ne vois pas quel élément est contenu dans 2 chaînes...

[Invité]

J'ai dû comprendre de travers, je parlais de l'élément Elt5.

Pour savoir quel est son parent, c'est facile c'est F.
Pour savoir quel est le "papa" de F, on le trouve facilement, c'est C, et on le trouve parce que dans Elt5 on a dit que Elt5 faisait partie de la chaîne 3.

Mais après ?? Comment dire que C est dans E et pas dans B, puisqu'on ne sait pas qu'il faut utiliser la chaîne 1 ?

EDIT : on a dit que l'élement ne devait être que dans une seule chaîne pour que cela marche. Je suis OK, mais s'il faut distinguer les chemins (comme dans l'exemple) pour pouvoir s'y retrouver, qu'est-ce qui se passe ?

[JPhi33]

Ca y est, j'ai compris ce que tu n'a pas compris !

Regarde bien ton schéma du 03/09 à 08h11 et compare-le avec ceci (dans mon message du 04/09 à 02h14 - oui, je sais, je me couche tard ! ) :
1 : A --> B --> C
2 : A --> B --> D
3 : A --> E --> C
4 : A --> E --> D

Tu vois que le lien A --> B fait partie des chaînes 1 et 2. On numérote les chaînes de catégories, pas les "traits" sur le schéma. Plusieurs chaînes peuvent passer par le même "trait" (du moins dans ma 1ère proposition).

Je reprends ton dernier schéma auquel j'ajoute les numéros de chaînes ainsi que la chaîne dont dépend chaque élément :


Si je prends Elt5 (chaîne 3), il est lié à F. F n'a qu'une mère : C. Jusque là, pas de problème. Mais C a deux mères B et E, laquelle faut-il prendre ? C'est E, forcément, puisqu'on est dans la chaîne 3 !

Là, je suis sûr que tu as compris

Exercice (non, je plaisante !) : Je te laisse en déduire ce qui se passe avec la 2e modélisation pour laquelle le numéro de chaîne est une clé étrangère dans la table LIEN qu'on ne valorise que lorsqu'une catégorie a plusieurs mères.

[Invité]

C'est ce que j'avais pensé à faire hier, mais j'étais pas sure que c'est ce que tu disais. Donc avant de faire un truc, peut-être que y'avait un autre truc beaucoup mieux, j'ai donc demandé explications

Donc j'ai très bien compris. Je vais essayer d'y mettre en place car je pense que ça marchera

Merci pour la réponse, ça a l'air résolu


EDIT : et pour être totalement sure de ne pas faire de bêtise, est-ce que le schéma dessous correspond ? (j'ai gardé ta notation, # pour clé primaire et souligné pour clé étrangère) :


Et pour ta 2° modélisation, ca donnerait ça, c'est ca ?


Mais ne vaudrait-il mieux pas utiliser la 1° modélisation, au cas où un jour la catégorie qui n'avait qu'une seule mère, se retrouve à en avoir plusieurs ? Ca éviterait de retoucher la base de données pour mettre à jour les liens, non ?


De plus, la table chaîne ne sert qu'a contenir un chiffre ici (et dans mon cas ça serait pareil), c'est vraiment bien ? Ne pourrait-on pas mettre ce chiffre dans Elt directement(ou alors directement utiliser la clé primaire de l'élément) et faire disparaitre la table chaine ?

Par contre, pour une categorie qui aurait plusieurs éléments finaux, ça ferait autant de chaînes que d'éléments finaux, c'est peut-être pas un bon plan ... Et on ne saurait plus, non plus, les éléments empruntant le même chemin. C'est dommage ça économisait une table C'est un peu bizarre une table ayant qu'un seul champ qui ne représente rien concrètement ...
A moins qu'on fasse un truc dans le genre :

Après en fonction du développement que je vais faire pour mon application, ça peut marcher...

QU'est-ce que vous en dites ?

[Invité]

En fait, je pense que le dernier schéma que j'ai fait marcherait, en mettant une contrainte check sur le champ chaine de la table des element, pour etre sure que la chaine existe dans la table lien.

Merci pour l'aide, reste plus qu'à y faire fonctionner.

[JPhi33]

et pour être totalement sure de ne pas faire de bêtise, est-ce que le schéma dessous correspond ? (j'ai gardé ta notation, # pour clé primaire et souligné pour clé étrangère)

Oui, il correspond.

Et pour ta 2° modélisation, ca donnerait ça, c'est ca ?

Oui, sauf pour F et G qui n'ont qu'une mère ; il est inutile de numéroter les liens C --> F et C --> G.

Mais ne vaudrait-il mieux pas utiliser la 1° modélisation, au cas où un jour la catégorie qui n'avait qu'une seule mère, se retrouve à en avoir plusieurs ? Ca éviterait de retoucher la base de données pour mettre à jour les liens, non ?

Il y a du pour et du contre. Pour : les traitements à effectuer vont être plus simples. Contre : on va gérer un volume de données plus important dans la table LIEN.

Avec le 1er modèle, lorsqu'on introduit un nouveau lien (avec ou sans nouvelle catégorie), on ne se pose aucune question, on crée une nouvelle chaîne en faisant +1 sur le dernier numéro. Par exemple, si j'ajoute la catégorie F à la suite B, je crée la chaîne 6 et j'ajoute les triplets (A, B, 6) et (B, F, 6) à la table LIEN.

Avec le 2e modèle, il faut se poser plusieurs questions : nouvelle catégorie ou non ? Si oui, j'ajoute les liens après avoir créé la gatégorie. Si non, je dois aller rechercher les liens pour lesquels la catégorie en question est fille, numéroter ces liens (s'ils ne le sont pas déjà) c'est-à-dire identifier la chaîne dans laquelle ils se situent pour en récupérer le numéro. Récupérer le dernier numéro de chaîne attribué pour faire +1 et (enfin) insérer le lien et le numéroter.
Même exemple qu'au dessus (j'ajoute la catégorie F à la suite B) : ce n'est pas une nouvelle catégorie ==> je recherche les lignes ayant F pour fille, je trouve (C, F, Null) ==> je redescends à l'élément pour récupérer la chaine, je trouve "3" ==> je mets à jour le lien (C, F, Null) en (C, F, 3) ==> j'ajoute la ligne (B, F, 6). C'est quand même plus compliqué.

Donc tout dépendra du volume de données dans la table LIEN à terme. Si le stockage des donnée n'est pas un problème, tu as tout intérêt à choisir la 1e modélisation.

De plus, la table chaîne ne sert qu'a contenir un chiffre ici (et dans mon cas ça serait pareil), c'est vraiment bien ? Ne pourrait-on pas mettre ce chiffre dans Elt directement

C'est vrai, elle ne contient qu'un chiffre (un chiffre, c'est banal !), mais il ne faut pas s'arrêter à cet aspect. Ce chiffre a une valeur sémantique très importante dans le modèle, c'est lui qui identifie les chaînes ; sans lui, une chaîne n'existe pas. Et la chaîne, c'est quand même l'épine dorsale de la solution.
On peut mettre ce chiffre directement dans ELEMENT. Oui mais on perd en efficacité : calculer le prochain numéro de chaîne devient plus long. La fonction MAX() sera toujours plus longue dans la table ELEMENT ou LIEN que dans la table CHAINE.

(ou alors directement utiliser la clé primaire de l'élément) et faire disparaitre la table chaine ?

Par contre, pour une categorie qui aurait plusieurs éléments finaux, ça ferait autant de chaînes que d'éléments finaux, c'est peut-être pas un bon plan ... Et on ne saurait plus, non plus, les éléments empruntant le même chemin. C'est dommage ça économisait une table.

Tu peux utiliser un élément pour identifier une chaîne, c'est possible. Mais tu n'auras pas autant de chaînes que d'éléments. Dans l'exemple, Elt5 et Elt6 sont liés à une seule chaîne (3). Il faudrait juste choisir quel élément utiliser pour identifier la chaîne. En plus, est-ce correct de dire qu'un élément final caractérise un lien entre deux catégories ?

Il ne faut pas toujours penser en économie de table. Je pense que ce ne serait vraiment pas une économie sur les traitements. Pour en juger tu peux construire l'algorithme d'une fonction de ton application avec un schéma et un autre et comparer les deux. C'est ce que j'ai fait de manière informelle ci-dessus pour l'ajout de la catégorie F à la suite B.

C'est un peu bizarre une table ayant qu'un seul champ qui ne représente rien concrètement...

Je ne suis pas d'accord. Ca peut faire toute la différence entre une solution solide, optimisée et une usine à gaz (je parle en général, pas forcément du problème qui nous occupe).

A moins qu'on fasse un truc dans le genre

Là c'est mieux. Si vraiment cette table CHAINE te gêne, tu peux faire ça. Mais rappelle-toi que l'économie n'est pas toujours là où on la voit de manière évidente.



Tu es parée maintenant !
Bon courage pour le développement.

[Invité]

Je pense que tu as raison.

Garder la table chaine faciliterait beaucoup les traitements (par rapport à mon dernier schéma), et j'en aurai sûrement moins à faire !

Donc voilà, c'est parti, cette fois je m'y mets et je pense garder cette table (donc faire ce que tu m'as conseillé dès le début), et je vais prendre la première méthode sûrement, car il n'y aura pas énormément de données je pense (je les connais déjà quasiment toutes).

Merci beaucoup pour l'aide !!