Bonjour,
Encore merci fsmrel
Je n'ai pas compris pourquoi tu as modifié la relation qui est maintenant de plusieurs à plusieurs au lieu de 1 à Plusieurs .
Si tu pouvais m'expliquer un peu pourquoi ce choix.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Bonjour,
Encore merci fsmrel
Je n'ai pas compris pourquoi tu as modifié la relation qui est maintenant de plusieurs à plusieurs au lieu de 1 à Plusieurs .
Si tu pouvais m'expliquer un peu pourquoi ce choix.
Au nom de la symétrie
Bonjour,
Avant tout, quelques rappels méthodologiques...
Quand on modélise le QUOI, c'est-à-dire les données, il y a certaines règles à respecter, établies il y a 40 ans par les tenants de l’approche entité-relation (Peter Chen aux États-Unis, les concepteurs de Merise en France, etc.), ou encore par les uéméliens un peu plus tard, avec les diagrammes de classes.
Pour construire un modèle, on part des règles de gestion des données rédigées disons en français, donc de façon informelle.
Parmi ces règles, on relève celles-ci :
(RG1) Une série est composée d’au moins un produit et au plus plusieurs ;
(RG2) Un produit peut entrer dans la composition de plusieurs séries.
Règles que le concepteur a réussi à obtenir de la part de l’utilisateur (un concepteur pratique la maïeutique, c’est un accoucheur...)
En passant, on note une symétrie évidente dans les relations entre les produits et les séries.
On formalise alors ce qui jusqu’ici est informel, au moyen d’un MCD (modèle conceptuel des données) ou d’un DC (diagramme de classes). Par exemple avec l’AGL DB-MAIN (gratuit), on produit le MCD suivant, où PRODUIT et SERIE sont des entités-types (types d’entités) et COMPOSITION une association entre entités-types :
Un produit entre dans la composition de 0à N séries ;
Une série est composée de 1 à N produits.
Pour en savoir plus sur l’art de la modélisation, voyez par exemple le chapitre 4 « Modèle conceptuel de données » de l’ouvrage Parlez-vous Merise ? de Michel Diviné (gratuit et téléchargeable, merci Michel !)
En descendant d’un cran, au niveau dit « logique », le MCD est automatiquement traduit par l’AGL en MLD (modèle logique des données). Dans ce MLD ce sont désormais des tables qui sont représentées :
Diagramme qui ressemble comme par hasard à celui proposé par ACCESS :
Et à partir du MLD, l’AGL permet de produire le script de création des tables.
En vertu de ce qui précède, il y a non pas une seule, mais deux relations de un à plusieurs, symétrie oblige...Envoyé par Willyson
Cette symétrie n’aurait pas lieu d’être si les produits n’étaient pas des entités à par entière, mais seulement des propriétés multivaluées des séries, non partageables entre les séries, à l’image des lignes de facture qui sont des propriétés multivaluées des factures, mais non partageables entre les factures.
En passant, n’oubliez pas de voter pour les réponses qui ont pu vous être utiles.
Ah oui Je viens de comprendre cette relation qui me laissait toujours perplexe , Super merci
De ta précédente réponse, j'ai compris que je n'avais pas précisé ce qui suit:
En réalité je n'avais pas que 3 produits (j'en ai plusieurs) et les produits ne sont pas des entités à part entière mais sont seulement des propriétés multivaluées des séries, non partageables entre les séries.
Du coup quelle doit etre la méthode et la relation?
J'essayais de simplifier les tables mais j'ignorais que ce genre d'infos pouvait aider à débloquer le problème
Je m'en excuse
Identification relative
Bonjour,
Ah ! Ça change bien des choses...
Cette fois-ci, la série "série 1" peut donc être composée des produits non partageables disons "a1", "a2", "a3",... , "an", tandis que la série "série 2" peut être composée de ses propres produits, non partageables eux non plus, "b1", "b2", "b3",... , "bn", et la série "série j" peut être composée de ses propres produits, non partageables, "j1", "j2", "j3",... , "jn".
On est dans la logique des commandes et lignes de commande : la même ligne de commande ne peut pas être partagée par deux commandes (ce qui n’empêche pas que, ponctuellement, des lignes de différentes commandes aient la même valeur : quantités égales, montants égaux pour le produit tartempion).
Le modèle conceptuel correspondant est le suivant :
Où l’on observe que l’identifiant de l’entité-type PRODUIT n’est pas le singleton {IdProduit}, mais la paire {COMPOSITION.SERIE, IdProduit}, c'est-à-dire que, comme on dit dans le jargon merisien, cette entité-type est identifiée relativement à l’entité-type SERIE, via l’association COMPOSITION. On retrouve — à la sauce merisienne — la technique utilisée en 1970 par Ted Codd (cf. la figure 3(b) dans l’article fondateur A Relational Model of Data for Large Shared Data Banks).
Le MLD qui en est dérivé :
Du fait de l’héritage par PRODUIT de l’attribut SerieId de SERIE, l’identifiant de PRODUIT s’est matérialisé en la paire {SerieId, IdProduit}.
Équivalent ACCESS (comme on descend d’un cran, l’identifiant conceptuel est devenu clé primaire) :
Vous retrouvez votre chère relation de 1 à plusieurs (un tantinet revue...) Mais il est important de noter que là aussi, la table Table_Produit est cette fois-ci identifiée relativement à Table_Serie. On parle ici de clés plutôt que d’identifiants, mais quoi qu’il en soit, la clé primaire de Table_Produit est bien la paire {ID_Serie, ID}, sachant que {ID_Serie} est en même temps clé étrangère par rapport à la clé primaire {ID} de Table_Serie.
Concernant l’association entre Table_Produit et Table_Serie :
Notez que la case « Cascade Update Related Fields » est décochée car, en réalité, comme je l’ai déjà signalé, les valeurs prises par l’attribut ID_Serie n’ont aucune raison d’être remplacées (invariance des clés primaires). Plus intéressant, la case « Cascade Delete Related Records » est cochée : en effet, Table_Produit étant une propriété multivaluée de Table_Serie, si on supprime une série, lorsque le stimulus correspondant parvient à ses produits, ceux-ci ne peuvent qu’accepter de mourir, puisque leur vie n’a de sens que via celle de leur série. On est dans la logique du métabolisme des commandes : si on supprime une commande, ses lignes de commande sont de facto elles aussi supprimées.
Contenu théorique de la table Table_Serie :
ID Serie -- ------- 1 série 1 2 série 2 3 série 3
Table_Produit
ID_Serie ID Produit -------- -- ------- 1 1 a1 1 2 a2 1 3 a3 1 ... ... 1 x ax 2 1 b1 2 2 b2 2 3 b3 2 ... ... 2 y by 3 1 c1 3 2 c2 3 3 c3 3 ... ... 3 z cz j 1 j1 j 2 j2 j 3 j3 j ... ... j n jn
Où, pour chaque série, la colonne ID prend successivement les valeurs 1, 2, 3, ..., m (où m représente le nombre de produits d’une série). Comme vous l’avez écrit, les produits ne sont pas partageables entre les séries, mais comme dans le cas des lignes de commande, rien n’interdit évidemment que des produits de séries différentes aient ponctuellement la même valeur.
Avant d’aller plus avant, sommes-nous en phase ?
Bonjour,
Oui fsmrel, jusque là on est bien en phase , c'est bien ce que je veux faire.
Ma question porte sur comment doit être conçu le fameux formulaire?
Merci d'avance
Bonsoir,
N’étant pas très au fait des formulaires d’ACCESS, j’en ai créé un (Serie_form) avec lequel l’utilisateur Raoul fournit le nom d’une série à définir ("série 1" dans l’exemple). Dans le sous-formulaire des produits à créer, il fournit les noms des produits qui composent la série ("a1", "a2", "a3" dans l’exemple). Une fois saisis les noms des produits, il clique sur le bouton « créer » et à coup de requêtes SQL, dans du code VBA, les tables Table_Serie et Table_Produit sont mises à jour. Raoul ne s’occupe que des données « naturelles », les clés primaires sont calculées par le code (à l’image de que j’ai présenté comme contenu des tables, dans mon message précédent).
Là aussi, vous pouvez jeter un coup d’œil au fichier .mdb que je joins. Ce n’est évidemment qu’un brouillon, à étoffer, secouer et tout ça...
Restons nous en phase ?
Bonjour,
Encore merci fsmrel ,
Je suis d'accord avec toi , sauf que mon plus grand problème est, que je ne veux pas que l'utilisateur ait à saisir encore des produits , je voulais que lorsqu'il choisit une série qu'un panel de produits associés lui soit proposés .
Bonjour,
Raoul doit donc pouvoir choisir dans un panel de produits, d’accord, et appelons Produit_Catalogue la table correspondante. Dans la dernière mouture que j'ai proposée, Raoul invente ses noms de produit. Désormais, il devrait donc pouvoir récupérer des noms de produit présents dans la table Produit_Catalogue, mais a-t-il aussi le droit d'inventer des noms, c'est-à-dire absents de la table Produit_Catalogue ? Si c'est oui, on fera évoluer le dernier formulaire en conséquence, si c'est non, on en revient au scénario des posts #20, #22...
Quelle est votre position ?
Dans la plupart des temps, Raoul ne sera pas amener à créer d'autres produits, mais il pourra un bon jour être obligé lui même de rajouter d'autres produits en cas d'évolution du business , il serait donc plus prudent de prévoir ça dès à présent.
Bonsoir,
Disons qu’en toute logique, chaque produit doit être présent dans la table Table_Produit considérée comme référentiel Produits (cf. le post #20). Si Raoul doit lui-même ajouter des produits X, Y, Z, etc., disons dans l’urgence, il faudra par la suite ne pas oublier d’ajouter ces produits dans le référentiel Produits, sinon le système deviendra instable. En effet si on omet de le faire et si Fernand se trouve dans la même situation, lui aussi va ajouter les produits X, Y, Z, etc., Vincent, Paul et les autres en feront autant et ça deviendra le foutoir (d’expérience, je sais ce qu'il en est).
Or on sait bien qu’il arrivera qu’on omette de faire figurer X, Y, Z. dans le référentiel, errare humanum est : mieux vaut prévenir que guérir, Raoul et ses collègues ne doivent pouvoir agir que si X, Y, Z sont présents dans le référentiel.
C’est un peu cruel, mais plus sain : à mon sens, le scénario du post #20 s’impose. Raoul a besoin des produits X, Y, Z ? Lui ou celui qui est habilité devra les faire figurer dans le référentiel, avant de quiconque ne puisse créer une série dans laquelle figurent ces produits.
Dura lex, sed lex ...
Oui je vois , mais sauf que dans le Poste 20 , Raoul est obligé de saisir les séries et en plus lorsqu'une série est créée tout est initialisé, c'est à dire que la table produit à retenir ne garde que les produits de la dernière série sélectionnée.
Bonsoir,
Dans le post#5, vous joignez une capture des deux tables, Table_Produit et Table_Série :
Or la table Table_Série est vide : on est donc amené à conclure qu’il faut créer les séries. Question donc :
En fait, les séries préexistent-elles ?
Si oui, je vire la partie « création d’une série » dans le code VBA, ça simplifie !
La table Produits_a_retenir n’est qu’une table de travail. C’est dans la table Table_Composition qu’au moyen du formulaire sont enregistrés les liens entre les séries et les produits.
Question donc :
Les liens entre les séries et les produits préexistent-ils ?
Si oui, le formulaire que j’ai proposé ne répond pas à ce que vous attendez, puisqu’il sert ici à créer les séries et leurs produits ! Je vais donc essayer d’en comprendre l’objet...
En passant, j’ai bien pris note que les produits ne sont en fait pas partageables pour les séries :
Autrement dit, les diagrammes du post #24 sont ceux qui sont pertinents. On est d'accord ?
Regardons maintenant de près votre propre formulaire :
En fait, il y figure le mot « Commande ». Autrement dit, quelque part votre formulaire concerne la prise de commandes. Pour une certaine commande Raoul choisit la série 6, et il faut qu’il puisse procéder comme dans le post #20, c'est-à-dire cocher tout ou partie des produits de cette série.
C’est bien cela ?
Si oui, si la série 6 comporte les produits "p6a", "p6b", "p6c", Raoul va par exemple retenir "p6a" et "p6b" :
Ce que je comprends pour le moment :
Les séries et leurs produits préexistent avant que Raoul ne fasse ses saisies de commandes (les diagrammes du post #20 sont caducs, on conserve ceux du post #24).
Pour chaque commande, Raoul va procéder de la même façon : choisir une série et cocher tout ou partie des produits de la série.
Si c’est cela, la table Produits_a_retenir peut servir cette fois-ci à stocker l’ensemble des résultats.
Questions :
— La numérotation des commandes n’intervient pas ?
— Pourquoi dans votre sous-formulaire y a-t-il un champ Id_Série ? Dans votre exemple, il vaut 1 : quel rapport entre la série 1 et la série 6 ? Je rappelle que vous avez bien précisé que les produits sont des propriétés multivaluées des séries, donc non partageables.
Je mettrai à jour le .mdb en fonction de vos réponses.
Bonjour,
Le champ Id_Série dans le sous-formulaire était juste là pour la visibilité (pour savoir réellement si , chaque enregistrement de produits correspondait bien à tout moment à la série sélectionnée plus haut)
Je suis parfaitement d'accord avec la structure du post 24 , par contre je voudrais juste que tu m'expliques comment tu fait pour créer la table produit à retenir et je pense que le tour sera joué .
Je vois le bout du tunnel
Encore Merci fsmrel ,
Bonjour,
Dans le fichier .mdb, j’ai valorisé les tables Table_Serie et Table_Produit, puisque séries et produits préexistent. La table produits_a_retenir reste une table de travail. En revanche, c’est la table Produits_retenus qui contiendra les produits retenus par Raoul pour chaque série traitée par celui-ci.
Est-ce qu’on s’approche de ce que vous attendez ?
Bonjour,
Encore merci fsmrel
On s'approche de la solution, mais sauf que dans le fichier que vous avez joins,le formulaire serie_form n'est pas pré-rempli par nos produits.
Bonjour Willyson,
Normal. Dans la logique des produits qui ne sont que des propriétés multivaluées des séries (post #24), tant qu’une série n’est pas précisée, on ne peut afficher que ceci :
En revanche, dès que Raoul a précisé une série (série 6 dans l’exemple), alors le programme pré-remplit le formulaire avec les produits de cette série :
Je rappelle que le modèle correspondant est le suivant (post #24) :
Et non pas celui-là qui ne vous a pas convenu (post #20), où pré-remplir les produits se justifie :
Si vous voulez que, dans la logique actuelle, le formulaire serie_form soit pré-rempli par tous vos produits, alors il faut aussi le pré-remplir avec toutes les séries...
Si vous voulez afficher les produits, en vertu de ce qui précède, il faut afficher les séries :
Avez-vous utilisez une requête pour afficher la série?Si oui laquelle?
Merci d'avance
Ça n’est pas une série, mais toutes les séries (après avoir ajouté la colonne Serie dans la table Produits_a_retenir). La requête est la suivante :
Je joins le fichier .mdb correspondant.INSERT INTO Produits_a_retenir (Serie, Produit, Drapeau) SELECT y.Serie, x.Produit, False FROM Table_Produit AS x, Table_Serie AS y WHERE x.ID_Serie = y.ID ;
Bonjour fsmrel,
Je ne sais pas comment te remercier pour avoir résolu mon problème et surtout pour tout le temps que tu y as consacré.
J'ai appris plein de choses de tous vos postes
Encore Grand Merci à vous pour votre aide
Merci aussi à madefemere pour ses interventions.
J'avais une autre question sur la même base, mais concernant un nouveau problème , c'est un peu abusé d'en poser une autre après qu'une autre soit résolue , mais j'ai pas de choix surtout que vous êtes celui qui connais le mieux la base en question .Je pense créer une nouvelle discussion pour ça et votre expertise me sera d'une grande utilité.
Voici mon problème
Nous avons le formulaire (série-produit) qu'on vient de construire , je l'ai modifié un peu en transformant le TextBox série en liste de choix ComboBox , et donc pour chacune des séries sélectionnées dans la combo il affiche les produits associés et Raoul coche les produits à retenir (J'ai fais une requête dans laquelle je fais un filtre sur la valeur de ce combox , je lui demande d'afficher les produits ,pour la quelle, la série prend la valeur sélectionée dans [Forms]![Combo8], ce qui fonctionne bien.
Mais Comme pour une la commande , on a besoin des infos sur l'utilisateur (Raoul), J'ai donc créer un autre formulaire que j'ai appelé Info(qui contient le nom de Raoul et son code employé). Lorsque j'utilise le formulaire serie-Produit comme sous formulaire de ce dernier , il ne reconnait plus la valeur du Combo8 , donc il ne fait plus le filtre des produits.
Comment pourrais-je résoudre ce problème?
Merci d'avance
Répondre avec citation
Partager