Bonjour,
 
je dois modéliser la gestion d'un projet en SQL et un problème m'apparaît lorsque je veux utiliser des entités faibles :
 
Un projet identifié par son nom est constitué de plusieurs phases. Une phases est identifié par un numéro de phase, et par le projet auquel elle est attaché. Je ne vois pas comment modéliser celà à la création de la table, car impossible d'utiliser PRIMARY KEY pour le numéro de phase, il est ensuite impossible d'avoir une phase 0 pour le projet A et une phase 0 pour le projet B. J'ai essayé aussi de rajouter un attribut nom en FOREIGN KEY avec comme valeur le projet auquel est rattaché la phase, mais là encore SQL me fait des misère à la création de plusieurs phases avec le meme numéro mais un projet différent.
 
Voilà, la question est comment modéliser cela ?
Merci d'avance.
Patrick.
 
 
Ah résolu, avec les deux attributs dans la meme primary key .
Merci quand meme.

De retour avec le même problème à un autre étage, car les phases de mon projet sont elle-même constituées de différentes Taches, qui est également une entité faible, mais entité faible qui se rapporte au numéro de phase(qui est lui meme une entité faible qui se rapporte au nom du projet, voir plus haut), et :
 
Projet [nom] --> Phase [numéro_P, Projet.nom] --> Tache [numéro_T, Phase.numéro_P]
 
 
Or lorsque j'applique la meme technique que pour Phase, SQL me dit :
 
no matching unique or primary key for this column-list.
 
 
HELP )
 
 
 
je ne sais pas si mon problème est très clair, donc voici un autre exemple avec la meme idée :
 
 Prenons l'exemple d'un cinéma, et de ses salles. On peut considérer chaque salle comme une entité, dotée d'attributs comme la capacité, l'équipement en son Dolby, ou autre. Il est difficilement imaginable de représenter une salle sans qu'elle soit rattachée à son cinéma. C'est en effet au niveau du cinema que l'on va trouver quelques informations générales comme l'adresse ou le numéro de téléphone.
Il est possible de représenter le lien entre un cinema et ses salles par une association classique, comme le montre la figure a. La cardinalité "1…1" force la participation d'une salle à un lien d'association avec un et un seul cinéma. Cette représentation est correcte, mais présente un inconvéniant : on doit créer un identifiant artificiel id pour le type d'entité Salle, et numéroter toutes les salles, indépendamment du cinema auquel elles sont rattachées.
On peut considérer qu'il est beaucoup plus naturel de numéroter des salles par un numéro interne à chaque cinéma. La clé d'identification d'une salle est alors constituée de deux parties :
- La clé de Cinéma, qui indique dans quel cinéma se trouve la salle
- Le numéro de la salle au sein du cinéma
 
En d'autre termes, l'entité salle ne dispose pas d'une identification absolue, mais d'une identification relative à une autre entité. Bien entendu cela force la salle à toujours être associée à un et un seul cinéma.
 
Si maintenant, l'on rajoute dans chaque salle des chaises que l'on souhaite numéroter de 0 à x dans chaque salle, il s'agira d'identifé faible, dépendant à la fois de la salle et du cinéma, là est mon problème, comment modéliser cela.

Ahhh c'était une question de mon partiel du mois dernier ... t'a essayé d'atribué une CONSTRAINT id_salle à la clé primaire de la salle?, ou ca na rien a voir?