Index ou table intermédiaire ?

[n00bi]

J'ai un modèle comme suit

Personne----(0,N)--------(0,1)----Animal
IDPers IDAnimal
Prenom Nom, Couleur


En relationnel on peut représenter cela de la manière suivante

1 : Personne(IDPersonne, Prenom); Animal(IDAnimal, Nom, Couleur #fkPers);

2: Personne(IDPersonne, Prenom);
Animal(IDAnimal, Nom, Couleur);
PersAnim(#fkPers, #fkAnimal)
avec un UNIQUE sur fkAnimal

Quelle est la plus performante des deux modélisations si l'on souhaite naviguer principalement de PERSONNE vers ANIMAL ? Pourquoi ?

[Maître Kenobi]

Bonjour,
s'il te plaît, les UP sont interdits. Merci de respecter cette rêgle.

[n00bi]

Autant pour moi. J'ai du louper la ligne en lisant les règles du forum. Et je vous prie de m'en excuser !


Pour en revenir au sujet : elle me semble basique cette question mais je n'ai malheureusement pas la réponse. J'aurais dit que pour naviguer à partir de l'entité Personne, la deuxième représentation doit être la mieux ... mais c'est juste une intuition.

Le problème c'est que dans ma BD j'ai de nombreuses relations de ce type (une sorte de hiérarchie d'entités) et ca m'embeterait de devoir créer une table par relation.

Merci de vos avis.

[SQLpro]

1 : Personne(IDPersonne, Prenom); Animal(IDAnimal, Nom, Couleur #fkPers);

Vrai

2: Personne(IDPersonne, Prenom);
Animal(IDAnimal, Nom, Couleur);
PersAnim(#fkPers, #fkAnimal)
avec un UNIQUE sur fkAnimal

totalement faux, même avec une contrainte d'unicité (ce qui serait pire encore) !

Apprenez les régles de passage du MCD au MPD.
Lisez l'article que j'ai écrit sur le sujet :
http://sqlpro.developpez.com/cours/m.../?page=passage

A +

[n00bi]

Merci pour votre réponse.

En lisant votre article il n'y a plus de problème. Je vais utiliser la première modélisation donc.

Cependant je ne comprends pas pourquoi ma deuxième modélisation est fausse. Même si elle l'est !


--RAJOUT A l'EDITION--

Je viens d'emprunter un bouquin de C. SOUTOU intitulé de "UML à SQL". Dans la transformation LOGIQUE --> PHYSIQUE il précise (p.190) :

Envoyé par C. SOUTOU

[...]Pour chaque association binaire (réflexive ou pas) ou n-aire, il est possible de définir un schéma physique faisant intervenir une table supplémentaire, qui contiendra autant de clés étrangères qu'il y a de tables à relier et sur lesquelles existera ou non une contrainte de type UNIQUE. [...]

Ma modélisation serait-elle alors possible ?

[TheLeadingEdge]

Bonjour,

La régle est en général :
1<-->1 1 seule table,
1<-->n 2 tables, Les 2 entités. La PK de 1 devient 1 FK de n.
n<-->n 3 tables. Les 2 entités et la relation.

Je suis plutôt d'accord avec SQLPro, quel est l'intérêt de transformer 1 relation ''1<-->n'' en table, surtout si c'est pour mettre 1 contrainte d'unicité sur 1 des clefs ?
Mais comme tu cites C.Soutou, (à qui j'accorde également 1 gros capital confiance ;-) ), je me dis qu'il y peut-être 1 lézard. Je regarderai le passage que tu précises dans son contexte ce soir à la maison.

[edit]

Envoyé par ''De ULML à SQL'' C. SOUTOU

Cette solution présente l'avantage de pouvoir faire évoluer le schéma plus facilement si les cardinalités viennent à changer dans le temps. ...

[/edit]