voila ,
on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
relations differentes.
ex
produit -------> Variante ---------> logistique
| ^
| |
| |
| |
------ > Fiche ------------------------------
avec pour cardinalites :
produit variante (1,N) (1,1)
variante logistique (1,N) (1,1)
produit fiche (1,N)(1,1)
fiche logistique (0,N)(1,1)
est ce que ce shema est correcte en merise
(moi je pense que oui) mais on me soutient le
contraire (sans reel argument a part un modeliseur qui n'accepte
pas la relation (il double la cle de produit dans logistique )
Merci a tous
voila ,
on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
relations differentes.
ex
produit -------> Variante ---------> logistique
| ^
| |
| |
| |
------ > Fiche ------------------------------
avec pour cardinalites :
produit variante (1,N) (1,1)
variante logistique (1,N) (1,1)
produit fiche (1,N)(1,1)
fiche logistique (0,N)(1,1)
est ce que ce shema est correcte en merise
(moi je pense que oui) mais on me soutient le
contraire (sans reel argument a part un modeliseur qui n'accepte
pas la relation (il double la cle de produit dans logistique )
Merci a tous
voila ,
on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
relations differentes.
ex
produit -------> Variante ---------> logistique
| ^
| |
| |
| |
------ > Fiche ------------------------------
avec pour cardinalites :
produit variante (1,N) (1,1)
variante logistique (1,N) (1,1)
produit fiche (1,N)(1,1)
fiche logistique (0,N)(1,1)
est ce que ce shema est correcte en merise
(moi je pense que oui) mais on me soutient le
contraire (sans reel argument a part un modeliseur qui n'accepte
pas la relation (il double la cle de produit dans logistique )
Merci a tous
voila ,
on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
relations differentes.
ex
produit -------> Variante ---------> logistique
| ^
| |
| |
| |
------ > Fiche ------------------------------
avec pour cardinalites :
produit variante (1,N) (1,1)
variante logistique (1,N) (1,1)
produit fiche (1,N)(1,1)
fiche logistique (0,N)(1,1)
est ce que ce shema est correcte en merise
(moi je pense que oui) mais on me soutient le
contraire (sans reel argument a part un modeliseur qui n'accepte
pas la relation (il double la cle de produit dans logistique )
Merci a tous
voila ,
on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
relations differentes.
ex
produit -------> Variante ---------> logistique
| ^
| |
| |
| |
------ > Fiche ------------------------------
avec pour cardinalites :
produit variante (1,N) (1,1)
variante logistique (1,N) (1,1)
produit fiche (1,N)(1,1)
fiche logistique (0,N)(1,1)
est ce que ce shema est correcte en merise
(moi je pense que oui) mais on me soutient le
contraire (sans reel argument a part un modeliseur qui n'accepte
pas la relation (il double la cle de produit dans logistique )
Merci a tous
voila ,
on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
relations differentes.
ex
produit -------> Variante ---------> logistique
| ^
| |
| |
| |
------ > Fiche ------------------------------
avec pour cardinalites :
produit variante (1,N) (1,1)
variante logistique (1,N) (1,1)
produit fiche (1,N)(1,1)
fiche logistique (0,N)(1,1)
est ce que ce shema est correcte en merise
(moi je pense que oui) mais on me soutient le
contraire (sans reel argument a part un modeliseur qui n'accepte
pas la relation (il double la cle de produit dans logistique )
Merci a tous
bonjour,
en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est pas
tout à fait ton cas )
Tous cela est dans le domaine des dépendances fonctionnelles et sans être
trop technique
on parle de "forme normale".
Le but est de retrouver l'information, pour obtenir la donnée logistique
as donc 2 chemins
produit-->variante-->logistique
et
produit-->fiche-->logistique
Il faut voir à quoi sert variante par rapport à fiche et voir si les deux
peuvent en faire qu'une.
Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
requêtes.
Bonne continuation
Didier
"Firetox" a écrit dans le message de
news:bn8lmr$m40$
> voila ,
> on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> relations differentes.
> ex
>
> produit -------> Variante ---------> logistique
> | ^
> | |
> | |
> | |
> ------ > Fiche ------------------------------
>
> avec pour cardinalites :
>
> produit variante (1,N) (1,1)
> variante logistique (1,N) (1,1)
>
> produit fiche (1,N)(1,1)
> fiche logistique (0,N)(1,1)
>
> est ce que ce shema est correcte en merise
> (moi je pense que oui) mais on me soutient le
> contraire (sans reel argument a part un modeliseur qui n'accepte
> pas la relation (il double la cle de produit dans logistique )
>
> Merci a tous
>
>
>
bonjour,
en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est pas
tout à fait ton cas )
Tous cela est dans le domaine des dépendances fonctionnelles et sans être
trop technique
on parle de "forme normale".
Le but est de retrouver l'information, pour obtenir la donnée logistique
as donc 2 chemins
produit-->variante-->logistique
et
produit-->fiche-->logistique
Il faut voir à quoi sert variante par rapport à fiche et voir si les deux
peuvent en faire qu'une.
Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
requêtes.
Bonne continuation
Didier
"Firetox" <emprin.frederic@freesbee.fr> a écrit dans le message de
news:bn8lmr$m40$1@s1.read.news.oleane.net...
> voila ,
> on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> relations differentes.
> ex
>
> produit -------> Variante ---------> logistique
> | ^
> | |
> | |
> | |
> ------ > Fiche ------------------------------
>
> avec pour cardinalites :
>
> produit variante (1,N) (1,1)
> variante logistique (1,N) (1,1)
>
> produit fiche (1,N)(1,1)
> fiche logistique (0,N)(1,1)
>
> est ce que ce shema est correcte en merise
> (moi je pense que oui) mais on me soutient le
> contraire (sans reel argument a part un modeliseur qui n'accepte
> pas la relation (il double la cle de produit dans logistique )
>
> Merci a tous
>
>
>
bonjour,
en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est pas
tout à fait ton cas )
Tous cela est dans le domaine des dépendances fonctionnelles et sans être
trop technique
on parle de "forme normale".
Le but est de retrouver l'information, pour obtenir la donnée logistique
as donc 2 chemins
produit-->variante-->logistique
et
produit-->fiche-->logistique
Il faut voir à quoi sert variante par rapport à fiche et voir si les deux
peuvent en faire qu'une.
Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
requêtes.
Bonne continuation
Didier
"Firetox" a écrit dans le message de
news:bn8lmr$m40$
> voila ,
> on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> relations differentes.
> ex
>
> produit -------> Variante ---------> logistique
> | ^
> | |
> | |
> | |
> ------ > Fiche ------------------------------
>
> avec pour cardinalites :
>
> produit variante (1,N) (1,1)
> variante logistique (1,N) (1,1)
>
> produit fiche (1,N)(1,1)
> fiche logistique (0,N)(1,1)
>
> est ce que ce shema est correcte en merise
> (moi je pense que oui) mais on me soutient le
> contraire (sans reel argument a part un modeliseur qui n'accepte
> pas la relation (il double la cle de produit dans logistique )
>
> Merci a tous
>
>
>
bonjour,
en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est pas
tout à fait ton cas )
Tous cela est dans le domaine des dépendances fonctionnelles et sans être
trop technique
on parle de "forme normale".
Le but est de retrouver l'information, pour obtenir la donnée logistique
as donc 2 chemins
produit-->variante-->logistique
et
produit-->fiche-->logistique
Il faut voir à quoi sert variante par rapport à fiche et voir si les deux
peuvent en faire qu'une.
Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
requêtes.
Bonne continuation
Didier
"Firetox" a écrit dans le message de
news:bn8lmr$m40$
> voila ,
> on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> relations differentes.
> ex
>
> produit -------> Variante ---------> logistique
> | ^
> | |
> | |
> | |
> ------ > Fiche ------------------------------
>
> avec pour cardinalites :
>
> produit variante (1,N) (1,1)
> variante logistique (1,N) (1,1)
>
> produit fiche (1,N)(1,1)
> fiche logistique (0,N)(1,1)
>
> est ce que ce shema est correcte en merise
> (moi je pense que oui) mais on me soutient le
> contraire (sans reel argument a part un modeliseur qui n'accepte
> pas la relation (il double la cle de produit dans logistique )
>
> Merci a tous
>
>
>
bonjour,
en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est pas
tout à fait ton cas )
Tous cela est dans le domaine des dépendances fonctionnelles et sans être
trop technique
on parle de "forme normale".
Le but est de retrouver l'information, pour obtenir la donnée logistique
as donc 2 chemins
produit-->variante-->logistique
et
produit-->fiche-->logistique
Il faut voir à quoi sert variante par rapport à fiche et voir si les deux
peuvent en faire qu'une.
Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
requêtes.
Bonne continuation
Didier
"Firetox" <emprin.frederic@freesbee.fr> a écrit dans le message de
news:bn8lmr$m40$1@s1.read.news.oleane.net...
> voila ,
> on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> relations differentes.
> ex
>
> produit -------> Variante ---------> logistique
> | ^
> | |
> | |
> | |
> ------ > Fiche ------------------------------
>
> avec pour cardinalites :
>
> produit variante (1,N) (1,1)
> variante logistique (1,N) (1,1)
>
> produit fiche (1,N)(1,1)
> fiche logistique (0,N)(1,1)
>
> est ce que ce shema est correcte en merise
> (moi je pense que oui) mais on me soutient le
> contraire (sans reel argument a part un modeliseur qui n'accepte
> pas la relation (il double la cle de produit dans logistique )
>
> Merci a tous
>
>
>
bonjour,
en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est pas
tout à fait ton cas )
Tous cela est dans le domaine des dépendances fonctionnelles et sans être
trop technique
on parle de "forme normale".
Le but est de retrouver l'information, pour obtenir la donnée logistique
as donc 2 chemins
produit-->variante-->logistique
et
produit-->fiche-->logistique
Il faut voir à quoi sert variante par rapport à fiche et voir si les deux
peuvent en faire qu'une.
Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
requêtes.
Bonne continuation
Didier
"Firetox" a écrit dans le message de
news:bn8lmr$m40$
> voila ,
> on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> relations differentes.
> ex
>
> produit -------> Variante ---------> logistique
> | ^
> | |
> | |
> | |
> ------ > Fiche ------------------------------
>
> avec pour cardinalites :
>
> produit variante (1,N) (1,1)
> variante logistique (1,N) (1,1)
>
> produit fiche (1,N)(1,1)
> fiche logistique (0,N)(1,1)
>
> est ce que ce shema est correcte en merise
> (moi je pense que oui) mais on me soutient le
> contraire (sans reel argument a part un modeliseur qui n'accepte
> pas la relation (il double la cle de produit dans logistique )
>
> Merci a tous
>
>
>
encore moi, juste pour le fun
en partant du principe qu'il y a la théorie et la pratique, que tu n'est
dans une optique d'optimisation
ou de gestion de plusieurs millions d'enregistrement on peut dire que :
posons les relations suivantes : a->b->c->d->e->f->g->h et
a->i->h
pour à partir de a touver h ou à partir de h trouver a, on peut dire sans
problème que l'on passera
par i pour rechercher les données ( 3 tables à la place de 8 pour la
premiere chaîne ).
On peut estimer que dans cette optique la suite des 8 tables n'est pas
logique.
Tout ça pour dire, que si tu accède à une information par plusieurs chemin
en partant du même point
de départ vers un même point d'arrivée ....le chemin le plus court est le
plus simple et certainement
le plus efficace. Il y donc peut être une anomalie dans le modèle et c'est
la que l'analyste doit regarder de près.
A quoi sert un chemin si tu ne l'emprunte jamais ?
dans ton cas, tu peux te poser la question : quelle requête dois je
pour en partant de logistique
trouver le produit. Dans ton cas, 1 logistique n'est associée qu'à unet un
seul produit.
Par contre, je ne vois pas trop pourquoi tu as une clé "produit" dans la
table logistique ?!
ce qui voudrait dire que tu as une troisième relation
voilà, voilà ....
didier
"Didier" a écrit dans le message de
news:bnapig$58e$
> bonjour,
>
> en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est
> tout à fait ton cas )
> Tous cela est dans le domaine des dépendances fonctionnelles et sans
> trop technique
> on parle de "forme normale".
>
> Le but est de retrouver l'information, pour obtenir la donnée logistique
tu
> as donc 2 chemins
> produit-->variante-->logistique
> et
> produit-->fiche-->logistique
>
> Il faut voir à quoi sert variante par rapport à fiche et voir si les
> peuvent en faire qu'une.
> Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
> requêtes.
>
> Bonne continuation
>
> Didier
>
>
>
>
> "Firetox" a écrit dans le message de
> news:bn8lmr$m40$
> > voila ,
> > on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> > relations differentes.
> > ex
> >
> > produit -------> Variante ---------> logistique
> > | ^
> > | |
> > | |
> > | |
> > ------ > Fiche ------------------------------
> >
> > avec pour cardinalites :
> >
> > produit variante (1,N) (1,1)
> > variante logistique (1,N) (1,1)
> >
> > produit fiche (1,N)(1,1)
> > fiche logistique (0,N)(1,1)
> >
> > est ce que ce shema est correcte en merise
> > (moi je pense que oui) mais on me soutient le
> > contraire (sans reel argument a part un modeliseur qui n'accepte
> > pas la relation (il double la cle de produit dans logistique )
> >
> > Merci a tous
> >
> >
> >
>
>
encore moi, juste pour le fun
en partant du principe qu'il y a la théorie et la pratique, que tu n'est
dans une optique d'optimisation
ou de gestion de plusieurs millions d'enregistrement on peut dire que :
posons les relations suivantes : a->b->c->d->e->f->g->h et
a->i->h
pour à partir de a touver h ou à partir de h trouver a, on peut dire sans
problème que l'on passera
par i pour rechercher les données ( 3 tables à la place de 8 pour la
premiere chaîne ).
On peut estimer que dans cette optique la suite des 8 tables n'est pas
logique.
Tout ça pour dire, que si tu accède à une information par plusieurs chemin
en partant du même point
de départ vers un même point d'arrivée ....le chemin le plus court est le
plus simple et certainement
le plus efficace. Il y donc peut être une anomalie dans le modèle et c'est
la que l'analyste doit regarder de près.
A quoi sert un chemin si tu ne l'emprunte jamais ?
dans ton cas, tu peux te poser la question : quelle requête dois je
pour en partant de logistique
trouver le produit. Dans ton cas, 1 logistique n'est associée qu'à unet un
seul produit.
Par contre, je ne vois pas trop pourquoi tu as une clé "produit" dans la
table logistique ?!
ce qui voudrait dire que tu as une troisième relation
voilà, voilà ....
didier
"Didier" <toto@wanadoo.fr> a écrit dans le message de
news:bnapig$58e$1@news-reader5.wanadoo.fr...
> bonjour,
>
> en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est
> tout à fait ton cas )
> Tous cela est dans le domaine des dépendances fonctionnelles et sans
> trop technique
> on parle de "forme normale".
>
> Le but est de retrouver l'information, pour obtenir la donnée logistique
tu
> as donc 2 chemins
> produit-->variante-->logistique
> et
> produit-->fiche-->logistique
>
> Il faut voir à quoi sert variante par rapport à fiche et voir si les
> peuvent en faire qu'une.
> Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
> requêtes.
>
> Bonne continuation
>
> Didier
>
>
>
>
> "Firetox" <emprin.frederic@freesbee.fr> a écrit dans le message de
> news:bn8lmr$m40$1@s1.read.news.oleane.net...
> > voila ,
> > on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> > relations differentes.
> > ex
> >
> > produit -------> Variante ---------> logistique
> > | ^
> > | |
> > | |
> > | |
> > ------ > Fiche ------------------------------
> >
> > avec pour cardinalites :
> >
> > produit variante (1,N) (1,1)
> > variante logistique (1,N) (1,1)
> >
> > produit fiche (1,N)(1,1)
> > fiche logistique (0,N)(1,1)
> >
> > est ce que ce shema est correcte en merise
> > (moi je pense que oui) mais on me soutient le
> > contraire (sans reel argument a part un modeliseur qui n'accepte
> > pas la relation (il double la cle de produit dans logistique )
> >
> > Merci a tous
> >
> >
> >
>
>
encore moi, juste pour le fun
en partant du principe qu'il y a la théorie et la pratique, que tu n'est
dans une optique d'optimisation
ou de gestion de plusieurs millions d'enregistrement on peut dire que :
posons les relations suivantes : a->b->c->d->e->f->g->h et
a->i->h
pour à partir de a touver h ou à partir de h trouver a, on peut dire sans
problème que l'on passera
par i pour rechercher les données ( 3 tables à la place de 8 pour la
premiere chaîne ).
On peut estimer que dans cette optique la suite des 8 tables n'est pas
logique.
Tout ça pour dire, que si tu accède à une information par plusieurs chemin
en partant du même point
de départ vers un même point d'arrivée ....le chemin le plus court est le
plus simple et certainement
le plus efficace. Il y donc peut être une anomalie dans le modèle et c'est
la que l'analyste doit regarder de près.
A quoi sert un chemin si tu ne l'emprunte jamais ?
dans ton cas, tu peux te poser la question : quelle requête dois je
pour en partant de logistique
trouver le produit. Dans ton cas, 1 logistique n'est associée qu'à unet un
seul produit.
Par contre, je ne vois pas trop pourquoi tu as une clé "produit" dans la
table logistique ?!
ce qui voudrait dire que tu as une troisième relation
voilà, voilà ....
didier
"Didier" a écrit dans le message de
news:bnapig$58e$
> bonjour,
>
> en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est
> tout à fait ton cas )
> Tous cela est dans le domaine des dépendances fonctionnelles et sans
> trop technique
> on parle de "forme normale".
>
> Le but est de retrouver l'information, pour obtenir la donnée logistique
tu
> as donc 2 chemins
> produit-->variante-->logistique
> et
> produit-->fiche-->logistique
>
> Il faut voir à quoi sert variante par rapport à fiche et voir si les
> peuvent en faire qu'une.
> Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
> requêtes.
>
> Bonne continuation
>
> Didier
>
>
>
>
> "Firetox" a écrit dans le message de
> news:bn8lmr$m40$
> > voila ,
> > on me soutient que 2 entites ne peuvent pas etre relies par plusieurs
> > relations differentes.
> > ex
> >
> > produit -------> Variante ---------> logistique
> > | ^
> > | |
> > | |
> > | |
> > ------ > Fiche ------------------------------
> >
> > avec pour cardinalites :
> >
> > produit variante (1,N) (1,1)
> > variante logistique (1,N) (1,1)
> >
> > produit fiche (1,N)(1,1)
> > fiche logistique (0,N)(1,1)
> >
> > est ce que ce shema est correcte en merise
> > (moi je pense que oui) mais on me soutient le
> > contraire (sans reel argument a part un modeliseur qui n'accepte
> > pas la relation (il double la cle de produit dans logistique )
> >
> > Merci a tous
> >
> >
> >
>
>
il existe un lien "implicite" entre logistique et fiche : c'est produit
ton lien entre fiche et logistique est en trop.
puisque une logistique correspond à un seul produit, connaissant ce
tu peux avoir
sa fiche.
soit :
produit -------> Variante ---------> logistique
produit--------> Fiche
logistique te donne variante qui te donne produit qui ce dernier te donne
fiche, tu peux donc avoir
fiche en partant de logistique sans lier fiche à logistique.
A partir de fiche tu peux trouver logistique via produit, et à partir de
produit du fais le lien entre logistique
et fiche......
soit fiche------>produit<-----variante<------logisitque
il existe un lien "implicite" entre logistique et fiche : c'est produit
didier
"Didier" a écrit dans le message de
news:bnarkq$ds7$
> encore moi, juste pour le fun
>
> en partant du principe qu'il y a la théorie et la pratique, que tu n'est
pas
> dans une optique d'optimisation
> ou de gestion de plusieurs millions d'enregistrement on peut dire que :
>
> posons les relations suivantes : a->b->c->d->e->f->g->h et
> a->i->h
>
> pour à partir de a touver h ou à partir de h trouver a, on peut dire
> problème que l'on passera
> par i pour rechercher les données ( 3 tables à la place de 8 pour la
> premiere chaîne ).
> On peut estimer que dans cette optique la suite des 8 tables n'est pas
> logique.
> Tout ça pour dire, que si tu accède à une information par plusieurs
> en partant du même point
> de départ vers un même point d'arrivée ....le chemin le plus court est
> plus simple et certainement
> le plus efficace. Il y donc peut être une anomalie dans le modèle et
> la que l'analyste doit regarder de près.
> A quoi sert un chemin si tu ne l'emprunte jamais ?
>
> dans ton cas, tu peux te poser la question : quelle requête dois je
exécuter
> pour en partant de logistique
> trouver le produit. Dans ton cas, 1 logistique n'est associée qu'à unet
> seul produit.
>
> Par contre, je ne vois pas trop pourquoi tu as une clé "produit" dans
> table logistique ?!
> ce qui voudrait dire que tu as une troisième relation
produit-->logistique.
>
> voilà, voilà ....
>
> didier
>
>
>
> "Didier" a écrit dans le message de
> news:bnapig$58e$
> > bonjour,
> >
> > en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est
pas
> > tout à fait ton cas )
> > Tous cela est dans le domaine des dépendances fonctionnelles et sans
être
> > trop technique
> > on parle de "forme normale".
> >
> > Le but est de retrouver l'information, pour obtenir la donnée
> tu
> > as donc 2 chemins
> > produit-->variante-->logistique
> > et
> > produit-->fiche-->logistique
> >
> > Il faut voir à quoi sert variante par rapport à fiche et voir si les
deux
> > peuvent en faire qu'une.
> > Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
> > requêtes.
> >
> > Bonne continuation
> >
> > Didier
> >
> >
> >
> >
> > "Firetox" a écrit dans le message de
> > news:bn8lmr$m40$
> > > voila ,
> > > on me soutient que 2 entites ne peuvent pas etre relies par
> > > relations differentes.
> > > ex
> > >
> > > produit -------> Variante ---------> logistique
> > > | ^
> > > | |
> > > | |
> > > | |
> > > ------ > Fiche ------------------------------
> > >
> > > avec pour cardinalites :
> > >
> > > produit variante (1,N) (1,1)
> > > variante logistique (1,N) (1,1)
> > >
> > > produit fiche (1,N)(1,1)
> > > fiche logistique (0,N)(1,1)
> > >
> > > est ce que ce shema est correcte en merise
> > > (moi je pense que oui) mais on me soutient le
> > > contraire (sans reel argument a part un modeliseur qui n'accepte
> > > pas la relation (il double la cle de produit dans logistique )
> > >
> > > Merci a tous
> > >
> > >
> > >
> >
> >
>
>
il existe un lien "implicite" entre logistique et fiche : c'est produit
ton lien entre fiche et logistique est en trop.
puisque une logistique correspond à un seul produit, connaissant ce
tu peux avoir
sa fiche.
soit :
produit -------> Variante ---------> logistique
produit--------> Fiche
logistique te donne variante qui te donne produit qui ce dernier te donne
fiche, tu peux donc avoir
fiche en partant de logistique sans lier fiche à logistique.
A partir de fiche tu peux trouver logistique via produit, et à partir de
produit du fais le lien entre logistique
et fiche......
soit fiche------>produit<-----variante<------logisitque
il existe un lien "implicite" entre logistique et fiche : c'est produit
didier
"Didier" <toto@wanadoo.fr> a écrit dans le message de
news:bnarkq$ds7$1@news-reader5.wanadoo.fr...
> encore moi, juste pour le fun
>
> en partant du principe qu'il y a la théorie et la pratique, que tu n'est
pas
> dans une optique d'optimisation
> ou de gestion de plusieurs millions d'enregistrement on peut dire que :
>
> posons les relations suivantes : a->b->c->d->e->f->g->h et
> a->i->h
>
> pour à partir de a touver h ou à partir de h trouver a, on peut dire
> problème que l'on passera
> par i pour rechercher les données ( 3 tables à la place de 8 pour la
> premiere chaîne ).
> On peut estimer que dans cette optique la suite des 8 tables n'est pas
> logique.
> Tout ça pour dire, que si tu accède à une information par plusieurs
> en partant du même point
> de départ vers un même point d'arrivée ....le chemin le plus court est
> plus simple et certainement
> le plus efficace. Il y donc peut être une anomalie dans le modèle et
> la que l'analyste doit regarder de près.
> A quoi sert un chemin si tu ne l'emprunte jamais ?
>
> dans ton cas, tu peux te poser la question : quelle requête dois je
exécuter
> pour en partant de logistique
> trouver le produit. Dans ton cas, 1 logistique n'est associée qu'à unet
> seul produit.
>
> Par contre, je ne vois pas trop pourquoi tu as une clé "produit" dans
> table logistique ?!
> ce qui voudrait dire que tu as une troisième relation
produit-->logistique.
>
> voilà, voilà ....
>
> didier
>
>
>
> "Didier" <toto@wanadoo.fr> a écrit dans le message de
> news:bnapig$58e$1@news-reader5.wanadoo.fr...
> > bonjour,
> >
> > en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est
pas
> > tout à fait ton cas )
> > Tous cela est dans le domaine des dépendances fonctionnelles et sans
être
> > trop technique
> > on parle de "forme normale".
> >
> > Le but est de retrouver l'information, pour obtenir la donnée
> tu
> > as donc 2 chemins
> > produit-->variante-->logistique
> > et
> > produit-->fiche-->logistique
> >
> > Il faut voir à quoi sert variante par rapport à fiche et voir si les
deux
> > peuvent en faire qu'une.
> > Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
> > requêtes.
> >
> > Bonne continuation
> >
> > Didier
> >
> >
> >
> >
> > "Firetox" <emprin.frederic@freesbee.fr> a écrit dans le message de
> > news:bn8lmr$m40$1@s1.read.news.oleane.net...
> > > voila ,
> > > on me soutient que 2 entites ne peuvent pas etre relies par
> > > relations differentes.
> > > ex
> > >
> > > produit -------> Variante ---------> logistique
> > > | ^
> > > | |
> > > | |
> > > | |
> > > ------ > Fiche ------------------------------
> > >
> > > avec pour cardinalites :
> > >
> > > produit variante (1,N) (1,1)
> > > variante logistique (1,N) (1,1)
> > >
> > > produit fiche (1,N)(1,1)
> > > fiche logistique (0,N)(1,1)
> > >
> > > est ce que ce shema est correcte en merise
> > > (moi je pense que oui) mais on me soutient le
> > > contraire (sans reel argument a part un modeliseur qui n'accepte
> > > pas la relation (il double la cle de produit dans logistique )
> > >
> > > Merci a tous
> > >
> > >
> > >
> >
> >
>
>
il existe un lien "implicite" entre logistique et fiche : c'est produit
ton lien entre fiche et logistique est en trop.
puisque une logistique correspond à un seul produit, connaissant ce
tu peux avoir
sa fiche.
soit :
produit -------> Variante ---------> logistique
produit--------> Fiche
logistique te donne variante qui te donne produit qui ce dernier te donne
fiche, tu peux donc avoir
fiche en partant de logistique sans lier fiche à logistique.
A partir de fiche tu peux trouver logistique via produit, et à partir de
produit du fais le lien entre logistique
et fiche......
soit fiche------>produit<-----variante<------logisitque
il existe un lien "implicite" entre logistique et fiche : c'est produit
didier
"Didier" a écrit dans le message de
news:bnarkq$ds7$
> encore moi, juste pour le fun
>
> en partant du principe qu'il y a la théorie et la pratique, que tu n'est
pas
> dans une optique d'optimisation
> ou de gestion de plusieurs millions d'enregistrement on peut dire que :
>
> posons les relations suivantes : a->b->c->d->e->f->g->h et
> a->i->h
>
> pour à partir de a touver h ou à partir de h trouver a, on peut dire
> problème que l'on passera
> par i pour rechercher les données ( 3 tables à la place de 8 pour la
> premiere chaîne ).
> On peut estimer que dans cette optique la suite des 8 tables n'est pas
> logique.
> Tout ça pour dire, que si tu accède à une information par plusieurs
> en partant du même point
> de départ vers un même point d'arrivée ....le chemin le plus court est
> plus simple et certainement
> le plus efficace. Il y donc peut être une anomalie dans le modèle et
> la que l'analyste doit regarder de près.
> A quoi sert un chemin si tu ne l'emprunte jamais ?
>
> dans ton cas, tu peux te poser la question : quelle requête dois je
exécuter
> pour en partant de logistique
> trouver le produit. Dans ton cas, 1 logistique n'est associée qu'à unet
> seul produit.
>
> Par contre, je ne vois pas trop pourquoi tu as une clé "produit" dans
> table logistique ?!
> ce qui voudrait dire que tu as une troisième relation
produit-->logistique.
>
> voilà, voilà ....
>
> didier
>
>
>
> "Didier" a écrit dans le message de
> news:bnapig$58e$
> > bonjour,
> >
> > en général si a-->b-->c , il ne devrait pas y avoir a-->c ( ce n'est
pas
> > tout à fait ton cas )
> > Tous cela est dans le domaine des dépendances fonctionnelles et sans
être
> > trop technique
> > on parle de "forme normale".
> >
> > Le but est de retrouver l'information, pour obtenir la donnée
> tu
> > as donc 2 chemins
> > produit-->variante-->logistique
> > et
> > produit-->fiche-->logistique
> >
> > Il faut voir à quoi sert variante par rapport à fiche et voir si les
deux
> > peuvent en faire qu'une.
> > Dans l'absolu il n'y a pas de problème, il s'agit de faire les bonnes
> > requêtes.
> >
> > Bonne continuation
> >
> > Didier
> >
> >
> >
> >
> > "Firetox" a écrit dans le message de
> > news:bn8lmr$m40$
> > > voila ,
> > > on me soutient que 2 entites ne peuvent pas etre relies par
> > > relations differentes.
> > > ex
> > >
> > > produit -------> Variante ---------> logistique
> > > | ^
> > > | |
> > > | |
> > > | |
> > > ------ > Fiche ------------------------------
> > >
> > > avec pour cardinalites :
> > >
> > > produit variante (1,N) (1,1)
> > > variante logistique (1,N) (1,1)
> > >
> > > produit fiche (1,N)(1,1)
> > > fiche logistique (0,N)(1,1)
> > >
> > > est ce que ce shema est correcte en merise
> > > (moi je pense que oui) mais on me soutient le
> > > contraire (sans reel argument a part un modeliseur qui n'accepte
> > > pas la relation (il double la cle de produit dans logistique )
> > >
> > > Merci a tous
> > >
> > >
> > >
> >
> >
>
>
