Discussion :

[Super2016]

Bonjour :

Je vous felicite de votre article : La division relationnelle, mythe ou réalité ? , trés instructif.

Mais j'ai essayé de faire la conversion de la Base Entrepôt sur Access , mais je ne suis pas arrivé au même résultat que vous ;

Est ce que le schéma relationnel suivant valide pour le cas Entrepôt ? :



La relation entre entrepots et rayon n'est - elle pas pas du type ( 1 , n ) à ( 1 , n ) ??.

CDT.

[escartefigue]

Bonjour,

Vous faites certainement référence à cet article : http://sqlpro.developpez.com/cours/divrelationnelle/ ce serait bien de le préciser

Dans cet article, chaque ville peut avoir plusieurs types de rayons et chaque type de rayon peut se trouver dans plusieurs villes, c'est donc bien une cardinalité maxi n de chaque coté

Par contre

• dans l'article, la table entrepot est la table des liens entre ville et rayon, et non pas la table des villes. C'est donc la table issue de votre relation "possède"
• la PK de type char utilisée dans l'article (probablement pour ne pas alourdir le texte) n'est absolument pas une modélisation à retenir dans la vraie vie !
  Créez une colonne d'identifiant technique de type entier attribué par le SGBD, n'utilisez jamais d'identifiant primaire de type CHAR et encore moins VARCHAR

[Super2016]

Bonjour :

Merci de votre réponse ;

Oui, je fais référence à l'article http://sqlpro.developpez.com/cours/divrelationnelle/ .

"Dans cet article, chaque ville peut avoir plusieurs types de rayons et chaque type de rayon peut se trouver dans plusieurs villes, c'est donc bien une cardinalité maxi n de chaque coté

Par contre
dans l'article, la table entrepot est la table des liens entre ville et rayon, et non pas la table des villes. C'est donc la table issue de votre relation "possède"
la PK de type char utilisée dans l'article (probablement pour ne pas alourdir le texte) n'est absolument pas une modélisation à retenir dans la vraie vie !
Créez une colonne d'identifiant technique de type entier attribué par le SGBD, n'utilisez jamais d'identifiant primaire de type CHAR et encore moins VARCHAR".

Si je suis bien vos recommandations, il en advient le schéma suivant :



Donc on a la table Intermédiaire des ID's .

Mais le vrai problème que je ne comprend pas c'est comment l'auteur a t il utilisé cette table intermédiaire des ID's comme une table contenant les noms des villes et
les noms des rayons.

En des termes plus clairs et faciles : La transposition sur Access de cet article n'est pas automatique ( Bien que tous les raisonnement SQL soient justes ) .

CDT.

[escartefigue]

Encore une fois, je suis persuadé que l'auteur a utilisé ces tables extrêmement simplifiées pour la démonstration de la division relationnelle sans s'encombrer avec des tables un peu plus riches.

Du coup il ne s'est pas embarrassé de colonnes identifiantes, il a seulement utilisé des libellés à la fois comme PK et comme colonne fonctionnelle.
Donc la table que vous nommez "intermédiaire" est une table classique issue d'une relation "n-aire" sauf que les identifiants sont aussi des colonnes fonctionnelles, c'est à dire ce qu'il ne faut jamais faire

La compétence de l'auteur n'est pas en question, il suffit de lire le blog de SQLPro et les réponses qu'il publie régulièrement ici pour s'en convaincre, mais si l'exemple a le mérite d'être simple, il a aussi le défaut de modéliser des tables un peu bancales du coup.

Pour faire court : oubliez la structure des tables de cet exemple, n'en retenez que le principe pour la division relationnelle

[Super2016]

Bonjour :

Merci beaucoup pour votre réponse.

Tout est devenu Clair.

Le Blog de SQLPro est un des meilleurs sur le SQL sinon le meilleur de tous.

CDT.

[SQLpro]

Le Blog de SQLPro est un des meilleurs sur le SQL sinon le meilleur de tous.
CDT.

C'est gentil, mais je vais encore avoir des varices à cause de mes chevilles qui vont enfler !!!!

A +