Discussion :

[NicolasGrabo]

Merci fs! Je crois que tout fonctionne correctement désormais! C'est parfait!

J'ai un peu de mal pour les requêtes que je ne comprends pas encore bien comment formuler mais ça va rentrer!

[NicolasGrabo]

Je cherche à faire la requete suivante :
"Chercher les organismes qui travaillent avec chaque client, et combien de fois ils travaillent avec chaque client."

Comment faire, sachant que le role_id des clients est 1, et que les roles des autres organismes va de 2 à 8?

[NicolasGrabo]

Par ailleurs, léger problème pour ce type de requête :
"Afficher le nom des clients, ainsi que leur adresse, pour lesquels les honoraires sont inférieurs à 3000 euros pour au moins une affaire"

Quand j'affiche ma requête ainsi, ça fonctionne :


Mais quand j'ajoute la table ville dans les relations, ça ne met plus que les clients dont l'adresse est à Paris et dont l'affaire se trouve à Paris... Pourtant, je souhaiterais que le nom de la ville apparaisse également.


Comment faire?

[fsmrel]

Je cherche à faire la requete suivante :
"Chercher les organismes qui travaillent avec chaque client, et combien de fois ils travaillent avec chaque client."
Comment faire, sachant que le role_id des clients est 1, et que les roles des autres organismes va de 2 à 8?

Vous êtes en train de quitter le domaine de la modélisation pour celui de la manipulation des données : il est temps que vous basculiez vers les forums SQL et/ou ACCESS pour poser vos questions. Des as comme Waldar vous aideront, mais commencez par présenter l’ébauche de vos requêtes (sous forme de SELECT SQL dans le cas du forum SQL) en précisant votre SGBD et sa version. Il ne s'agit pas que les autres fassent le travail à votre place...

Concernant votre question, il y a ambiguïté. Signifie-t-elle : Quels organismes travaillent avec tous les clients ?

Quoi qu’il en soit, faites comme si vous aviez une table des clients (et des références des affaires dans lesquels ils trempent) et une table des autres organismes (et des références des affaires dans lesquels ils trempent eux aussi). Définissez pour cela une vue (une requête dans le cas d’ACCESS) OrganismesClients et une vue OrganismesNonCLients que vous pourrez joindre sur l’attribut AffaireId.

Vue OrganismesClients (clients) :




Vue OrganismesNonClients (organismes non clients) :




Il devient facile de mettre en relation les clients et les non clients par jointure sur l'attribut AffaireId. Pour le reste : voyez les as...

[NicolasGrabo]

Merci fm!

Tu m'as été d'une grande aide!

[NicolasGrabo]

Dans l'entreprise, des débats nous font désormais hésiter entre ces deux modèles ci...





Laquelle est la bonne et pourquoi?

[fsmrel]

Laquelle est la bonne et pourquoi?

A) Si on se limite à une seule adresse pour un organisme, on peut se contenter du 1er modèle. Toutefois, pour éviter les incohérences, il est préférable de mettre en œuvre une table Commune (que pour votre part vous avez nommée Ville, mais ce terme est trop restrictif). En effet, selon votre modèle, rien n’interdit les incohérences du genre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
OrganismeId    ...    Code Postal    Ville    ... 
     1                  75011        Toulouse 
     2                  75011        Paris

La modélisation suivante est préférable :




B) Si un organisme peut avoir plusieurs adresses, alors le modèle évolue ainsi :



A noter que la table Adresse est identifiée relativement à la table Organisme, d'où la clé composée des deux attributs OrganismeId, AdresseId (dans cet ordre). On considère en l'occurrence qu'une adresse est une propriété multivaluée de l'organisme. En plus, au plan des performances, on s'y retrouve largement.

[NicolasGrabo]

L'attribut role_id doit donc toujours figurer dans la table participation?

[fsmrel]

Bien sûr ! Si je n'ai pas fait figurer la table Role, c'est pour avoir une image moins grande à l'affichage, mais cette table existe toujours.

[NicolasGrabo]

Par rapport à mes deux propositions en haut, et au placement de la table rôle, y a-t-il une erreur?

[fsmrel]

Par rapport à mes deux propositions en haut, et au placement de la table rôle, y a-t-il une erreur ?

Je n’avais pas vu que la relation qu’avait la table Rôle avec les autres tables différait selon les représentations graphiques. Dans le 1er cas, les tables Organisme et Rôle sont directement en relation, ce qui signifie qu’un organisme joue un rôle et un seul, donc toujours le même quelles que soient ses participations aux affaires.

Dans le 2e cas, le rôle que joue un organisme peut être différent d’une participation à l’autre.

Il n'y a pas d'erreur du point de vue de la modélisation, mais vous devez choisir l'option qui vous paraît la plus pertinente (et la justifier dans votre dossier de conception...)

[NicolasGrabo]

Dans le second cas, un organisme peut-il avoir plusieurs rôles différents par participation?
Si oui, comment faire car j'ai des problèmes de doublons? Quel réglage?

[fsmrel]

Dans le second cas, un organisme peut-il avoir plusieurs rôles différents par participation?

Tout dépend de la composition de la clé.

1) La clé est composée des deux seuls attributs OrganismeId et AffaireId : pour un organisme et une affaire il ne peut y avoir qu’un rôle.

2) La clé est composée des trois attributs OrganismeId, AffaireId et RoleId : pour un organisme et une affaire on peut avoir plusieurs rôles, pour un organisme et un rôle on peut avoir plusieurs affaires, etc.