Salut à tous.
 
Tout d'abord, j'epère avoir posté dans la bonne catégorie.
 
Mon problème est le suivant :
 
J'ai une base de dvd theque et j'ai une entité "nationalité" que je souhaite associer à trois autres entités (Film, Realisateur & Acteur).
Voici mon MCD pour que vous vous fassiez une idée:
 

 
Je veux eviter la boucle qui relie les trois entites vers l'entité nationalite, en creant des vues, mais je ne sais pas comment les representer.
Est-ce que comme j'ai fait là ca marche???
 
J'aimerais savoir comment on représente, en MCD, la notion de vues...
 
J'espère m'etre bien fait comprendre, et je vous remercie de votre aide.

rien compris.
Si une relation existe entre tes tables, tu les associes, sinon tu les associes pas, point barre.
Une vue ça n'est pas de la modélisation, c'est un outil fourni par ton sgbd.

j'ai pas compris ta question, mais peut tu me dire avec quel logiciel tu as fais ce MCD ?

Hummm.... C'est amusant j'ai exactement le même MCD sur papier dans un bouquin sur Merise. Après consultation de la correction ta boucle ne peut pas être supprimée.

Voici mon MCD après quelques modifs...
Pour blastman : je n'ai pas trouvé de logiciel interessant pour faire des MCD, je l'ai donc fait avec Microsoft Excel...

Et les apatrides, alors?

T'as dû t'amuser avec excel!
 

il va quand même pas mettre du 0,N?
On créé juste une nationnalité qui s'appelle Apatride....
 
 
Comme dans le cas de proffession où on met souvent : sans emploi.

non ca a tet vite avec excel...
j'avais commencé avec paint et puis j'en ai eu marre, et avec excel c'est vachement mieux

Paint????????????
Quelle galére, je n'ose même pas imaginer! PwerAMCD j'l'aime bien même si ce n'est pas le cas de tout le monde. Bon sinon je maintiens, ta boucle n'est pas supprimable!

 
Chuuuuuuut tu me bousilles ma question piège!

J'hésitais entre ignard ou plaisantain.
J'me suis trompé et je m'en excuse.  

Pas grave.
Et ignare.
 
...et après réflexion je suis en train de me dire que c'est pas forcément si con que ça, le (0,n)...la nationalité ne me parait pas un champs important au point de le rendre obligatoire...

Ouai mais ca plombe la base de donnée pour rien un 0,N. Si c'est pas important tu vire l'entité et c'est tout.

euh...pour quelle raison?

+1
un film, un acteur ou un realisateur peuvent etre de plusieurs nationnalites ou de nationnalite inconnue.
de plus un acteur d'un film peux egalement etre le realisateur dudit film ou d'un autre, donc a ta place je n'aurrait qu'une table personne et une relation film <- Participe (qualite=realisateur, acteur, metteur en scene, producteur ...)-> personne  
 

  du 0,N. Il vaut mieux y penser au debut que d'etre coincer apres ...

0,N => Associations multiples => Nouvelle table
0,1 => Ca ouai je veux bien.
 

 
Comma l'a très justement dit skeye, la nationnalité n'est d'une importance capitale alors si on en a déjà une c'est bon ! Alors je maintiens le 1,1 ou 0,1.

Bien sur que oui il faut une table des nationalités!
Ca peut être une table pré-remplie, avec un nombre d'enregistrements relativement faible, ce n'est pas de faire une jointure là-dessus qui va te "plomber la base"...

 
Non, un film peut avoir plusieurs nationalités, une personne aussi. Tu délires, là, franchement. Non seulement tu ne permets pas de stocker toutes les infos, mais en plus dans certains cas tu obliges à stocker de l'info qui n'existe pas.

Oui mais l'association de nationnalité à acteur va nous créer une nouvelle table! Si on a du N des deux coté c'est forcé....
 
Donc ca rajoute une table qui n'est pas forcément indispensable. Bon le mot "plombe" est un peu fort pour ce que je voulais dire.

 
Mais oussa une nouvelle table? Il faut UNE table des nationalités, point barre!!!

[Acteur]0,N---------|ETRE DE|--------0,N[NATIONNALITE]
 
Dis moi simplement comment, dans la pratique, tu va faire la correspondance entre les deux????

euh oui, très juste.
 
Dans la pratique, pour pas alourdir la structure, je collerais probablement plusieurs champs de nationalité dans acteur.

A priori, fredhali2000 est le seul juge pour savoir si c'est indipensable ou non
 

Bien sur qui va creer une nouvelle table :
personne (id_personne, ...)
nationalite (id_nationnalite, ...)
relation_persone_nationnalite (id_personne, id_nationnalite)

 
C'est bon, j'avais oublié de réfléchir.
Mais dans la pratique jamais tu fais ça, tu rajoutes un champs ou deux dans personne et basta.

 
  pas tres pratique pour lister tous les acteurs d'une certaine nationnalite ... Et si tu veux ajouter une troisieme nationnalite pour une persone, tu doit non seulement modifier la base de donnee mais aussi l'application ..

 
MERCI!!!
Je commencais à me demandais si j'étais con???!!! Je m'enervais sur mon pauvre clavier....
 
Ouai j'aurais dû balancer un MLD moi aussi ca aurait été plus clair!

euh.
select nom from acteur where (cod_nat1 = 'truc' or cod_nat2 = 'truc' or cod_nat3 = 'truc' )

Tu fais trop de php, toi.
 
[edit]
 
ah tiens, message effacé.

tu peux me donner ton vrai nom ? que je mette ton CV directement a la poubelle si tu postule dans ma boite  

c'est d'un laid.
et s'il en a 4 ??  
et s'il en a pas ?
 
beurk

bah écoute mon CV tu le verras jamais si t'es pas capable de comprendre que parfois faut savoir faire des choix de ce genre pour pas bloater ta structure.
 
Je bosse quotidiennement sur un soft avec une base oracle de plusieurs gigas comportant plus de 400 tables, et oui pour ce genre de conneries il arrive qu'on utilise des astuces de ce style. Et non, la structure n'est pas de moi.

 
Ouai parcequ'en faites je me suis dis une chose :
Avec la fonction in_array(), on a un tableaux dans lequel on stock les valeurs. Or dans le cas de ta requêtes c'est les différents noms de champs qu'il faut chercher et ça ne peut pas vraiment fonctionner avec in_array(). Quoique en fait si on donnait les valeurs des champs au tableau ca marcherais... Enfin bon ca existe pas, ou alors je suis pas au courant.
 
Et oui je fais trop de php, en plus je suis sûr que l'algo de recherche tiens pas compte du tri ou non, enfin bon.... J'sui HS là...

Non, les tableaux on appelle ça des tables, en sql...
Evidemment la solution idéale au point de vue conception est d'avoir une table dédiée à l'association personne/nationalité...

 
En fait j'pensais à un truc du genre (pour ta conception a toi ou tu met plusieurs champs nationnalité) :
select nom from acteur where in_array('id_nat',array(cod_nat1,cod_nat2,cod_nat3))
 
Et là on pourrait en mettre à la pelle sans se compliquer la vie.

'fin bref, c'est un choix à faire. Sur une grosse base, créer une table spécifique risque de te bouffer des perfs pour une utilisation marginale.
 
A contrario, sur une petite base niveau perfs tu verras pas la différence, et c'est nettement plus propre.

tres impressionnant    
 
Ou est ce qu'il as ecrit qu'il voulait faire une base de donnees de 400 tables ? j'ai du louper un message pour le moment j'en compte que 8 et de toutes manieres l'optimisation doit se faire apres la modelisation  
 

Moi je vois plus une base bien construite et après une bonne optimisation du traiment et de l'utilisation, au niveau du programme donc.

 
euh il faut garder à l'esprit que c'est un choix d'implémentation pour des cas très spécifiques, et où on sait qu'un des N de ta relation (N,N) a une valeur très faible.

sur ce coup la, skeye a raison, il faut parfoit faire des concessions au niveau de la base de donnees, mais dans le cas qui nous concerne, ca ressemble plus a une base perso