Re: [fr-users] Initiation laborieuse à Base

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




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