Discussion :

[mhz42]

Bonjour tout le monde,

J'aurais une petite question à vous soumettre. Je suis en train de concevoir une base de données MySQL via DB designer 4... et l'un de ses comportements me semble quelque peu étrange (c'est peut-être un simple problème d'incompréhension dû à mon inexpérience).

Soit trois tables: A, B et C, possédant uniquement une clé primaire chacune. J'ai des relations entre ces tables tel que:

A 1->n B 1->n C

Étant donné ces relations, DB designer (en mode MySQL) va automatiquement créer pour la table B, une clé étrangère vers la clé primaire de C. Jusque là rien d'anormal... Sauf qu'il va également prendre la liberté d'ajouter cette nouvelle clé étrangère dans le PRIMARY index de la table B (qui sera dès lors composé de la clé primaire initial de B et de cette clé étrangère vers C).

De la même manière depuis la table A, une clé étrangère sera ajoutée pour tous les champs faisant partis du PRIMARY index de B. A se retrouvera donc avec deux clés étrangères supplémentaires, l'une pointant vers la clé primaire de B, et l'autre vers la clé étrangère contenu dans B (et qui va elle-même vers C)...

Ces deux clés étrangères sont également intégrées dans le PRIMARY index de A qui se retrouve composé de 3 clés en tout, et ainsi de suite... Ce comportement est également observable dans les cas de généralisation.

Maintenant que j'approche d'une vingtaine de tables, certaines d'entre-elles se retrouvent avec 8 clés étrangères (dont la moitié ne seront probablement jamais accédées dans le cadre de nos requêtes). DB designer refuse de les supprimer sans supprimer également la relation auxquelles elles se rattachent.


Ma question est la suivante: pourquoi DB designer rajoute il autant de clé étrangères que de clés présentes (primaires ou étrangères) dans le PRIMARY index de la table cible. Est-ce un comportement propre à MySQL qui les créera de toute façon automatiquement ? Ou est-ce une technique de normalisation que je ne connaîtrai pas ?

Toutes les réponses/conseils sont les bienvenus
Merci Beaucoup

Marc H.

[mhz42]

Ok, je me répond à moi-même... l'unique problème était que j'utilisais des relations de type "identifying" qui ajoute automatiquement toutes les clés de la table cible dans l'index primaire.

Je suis assez dubitatif quant à l'utilité de cette fonctionnalité (à part quelques cas hyper spécifiques)... mais bon, avec les relations mises en non-identifying, tout rentre dans l'ordre.

Excellente journée à tous
Marc H.

[Maljuna Kris]

Saluton,
Je suis en train de finaliser la traduction de la documentation html en ligne de DBDesigner et je t'avoue que la partie explicative des types de relations me pose quelques soucis.
Ainsi, l'exemple et l'explication de la relation de type 1:n (Non Identifying), me semble tout sauf claire et explicite.
J'ai, comme toi, fait l'expérience à l'utilisation qu'il vaut mieux l'utiliser que l'autre relation 1:n.
Dans la vie professionnelle j'ai rencontré un cas, sous DBM, dans lequel un empilement quasi hiérarchique de tables faisait qu'on se retrouvait avec un identifiant composé de six rubriques (CROUS, CAMPAGNE, INE, RANGVOEU, IDAIDE, MOISDEPAIEMENT) dans la table LIGNECREANCE, clés étrangères des parents des différents étages.
On m'a expliqué alors qu'il s'agissait d'une 'optimisation' afin d'éviter des jointures dans certaines requêtes.
Je pense que cette partie de la traduction va nécessiter une [NDT] pour tenter de mieux expliciter la problématique.