Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


Bonjour ;

Un excellent tutoriel de Pierre-Yves ici : http://user.services.openoffice.org/fr/forum/ftopic6460.html

Bernard

PS : le fichier n'est pas passé. Il faut le mettre à disposition via cijoint.fr par exemple.

Mon intervention n'a pas de rapport direct avec la question initiale, mais sur un détail du fil ci-dessus. Elle s'adresse donc principalement à Pierre-Yves. Elle n'est pas une critique de son travail, plus exactement pas dans le sens négatif de "critique" - certainement pas ! -, mais avec le souci d'apporter quelque chose de précis à la communauté.

Du point de vue de la modélisation d'une situation donnée, la table "FournisseursProduits" ne me paraît pas répondre d'une manière satisfaisante au problème posé (un fournisseur propose plusieurs produits, un produit est proposé par plusieurs fournisseurs). En effet, l'introduction d'un identifiant spécifique peut amener à avoir dans la table une duplication de l'information réellement utile (le couple référence produit/référence fournisseur). Rien n'interdit en effet qu'on ait sous les identifiants 45 et 87 par exemple, les données F4 et P2 (fournisseur 4 et produit 2). Du point de vue du moteur, il n'y a pas de doublon, mais du point de vue de la règle d'unicité des données, c'est une erreur : la même information (le fournisseur F4 propose le produit P2) est présente deux fois.

Hypothèse plausible : si on imagine que chaque fournisseur peut proposer un prix différent pour chaque produit, et que l'organisation souhaite conserver cette information, la modélisation proposée devient inadaptée : quel est le prix exact demandé par F4 pour P2, celui de la ligne 45 ou celui de la ligne 87 ? Il faudrait rajouter un champ "Date", faire une requête pour extraire le prix le plus récent... Un peu compliqué, surtout qu'il y a manière plus simple.

En fait, si on raisonne en modèle entité-association, il n'y a pas d'entité "FournisseurProduit". C'est une association non hiérarchique reliant les entités Fournisseur et Produit, qui pourrait être éventuellement porteuse de données, si on souhaitait conserver le prix d'achat proposé par chaque fournisseur pour un produit donné.

Traduit en modèle relationnel, cela donnerait :

FOURNISSEUR (_Réf. Fournisseur_, Nom, ...)
PRODUIT (_Réf. Produit_, Désignation, ...)
PROPOSER (_#Réf. Fournisseur, #Ref. Produit_, Prix achat (éventuellement))

La relation PROPOSER traduit une association non hiérarchique (cardinalités 0,n ou 1,n sur chaque branche) et a pour clé primaire la concaténation des identifiants des deux entités qu'elle relie.

Au niveau physique, elle remplace la table "FournisseurProduit". Chaque clé composée ainsi est unique, il ne peut pas y avoir deux fois le même couple fournisseur/produit, et on peut associer à chaque couple un prix donné, qui serait le dernier prix d'achat proposé par le fournisseur pour ce produit.

Il y a une autre table, toujours dans ce modèle, qui est construite sur le même principe, c'est "DétailCommande". Mais le problème n'est pas le même. On peut en effet penser (c'est un cas que j'ai rencontré souvent) que sur une même commande le même produit figure plusieurs fois, avec des quantités et des prix différents. Un exemple vécu, chez un grossiste en matériaux : un client négocie un prix spécial sur les briques pour un chantier donné, mais conserve son prix habituel pour ses autres chantiers. Sur une même commande, il peut très bien demander des livraisons sur plusieurs de ses chantiers. On aura donc la même référence produit, mais avec deux prix différents.C'est le cas également avec des produits sous nomenclature détaillée, la même référence pouvant apparaître sur plusieurs sous-ensembles.

Dans le cas de "DétailCommande", on fait référence à une autre entité, dont l'identifiant est un numéro de ligne de commande. Pour une commande donnée, chaque ligne est indépendante des autres et peut porter sur les mêmes produits. On peut très aisément concevoir que le modèle soit adapté à ce cas de figure.

Pour la relation PROPOSER, si l'organisation veut aller plus loin et garder une historisation des prix proposés par chaque fournisseur, c'est possible, mais cela modifie sensiblement le modèle. On sort du contexte de cet article.

Il me semble important de montrer que Base est capable de traiter le problème des clés concaténés, extrêmement courant dans les bases de données qu'on peut implanter. Le problème posé par Pierre-Yves s'y prête, il suffit juste de l'adapter.

Cordialement ;
Marc Romano

--
Envoyez un mail à users+help@fr.libreoffice.org pour savoir comment vous désinscrire
Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/
Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être 
supprimés

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.