Re: [fr-users] Initiation laborieuse à Base

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