Re: [fr-users] Initiation laborieuse à Base

Le 17/12/2011 10:27, andriant.sandy a écrit :
> Le 17/12/2011 06:40, Marc Romano a écrit :
> > 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
>
> Bonjour,
>
> Il ne faut peut-être pas vouloir réinventer l'eau chaude.
> Ceux qui en sont à ce stade peuvent parfaitement profiter de cours en 
> ligne :
> http://access.developpez.com/cours/?page=langagevba#vbabases
>
> Cordialement,
> Sandy-Pascal Andriant

> Il ne faut peut-être pas vouloir réinventer l'eau chaude. 
A en croire la page où tu nous envoies, cela veut-il dire qu'en matière 
bureautique il faut s'en tenir à Access, et autres produits MS ? Je 
n'ose croire que dans ce domaine aussi existe une "pensée unique" et que 
ce lien est en fait une erreur involontaire :-)

Bernard


--
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