Bonsoir,

je démarre un petit projet mais me suis tombé dans un chemin d'interrogations assez loufoques...
Soit le MLD suivant :

http://img13.imageshack.us/img13/4196/mldu.jpg

La table RessourceCatagorie dispose d'une clé primaire double, ainsi que de deux clés étrangères.
C'est étrange hein ? Je suis même certain qu'on a pas le droit et que c'est d'une façon inutile.
Cependant... Ce sont à la fois des clés étrangères et primaires, vous en conviendrez. Mais si je supprime une catégorie j'aimerai donc que tout se supprime de soit même.
D'où ma clé étrangère avec un ON DELETE CASCADE...
C'est où que je fonce dans le mur ? Dites moi ?

Au passage, je suis ouvert à toute critique, proposition, quant à mon MLD.
Le projet est un logiciel de réservation de ressources.
Un utilisateur fait une réservation dans une catégorie en sélectionnant plusieurs ressources pour une durée précise.

Salut,
ton modèle semble tenir la route.

Première observation, ce n'est pas un MLD mais un MPD (Modèle Physique de Données), mais c'est de la sémantique.

Pour ta table RessourceCatégorie, tu es dans le vrai : il y a une clé primaire composite et deux clés étrangères qui sont les colonnes composant la clé primaire, ce n'est en aucune manière contradictoire et même tout à fait valide. Un détail cependant, tu es limité aux moteurs supportant l'intégrité référentielle pour pouvoir indiquer les actions ONDELETE et ONUPDATE, ce qui se résume au moteur InnoDB pour l'instant avec MySQL.

Ensuite, il me semble qu'il manque une clé étrangère dans ta table Réservation, idRessource, alors qu'on y trouve un idUser ne correspondant à aucune table User... à vérifier.

Enfin, ne disposant pas de tous les éléments pour donner un avis pertinent, je resterai assez vague, mais une double relation entre Reservation et RessourceCategorie via d'un coté Categories et d'un autre Ressource me semble étrange alors que RessourcesCategorie est déjà une table relationnelle... Tu te retrouves avec une relation circulaire ouvrant la porte à des incohérences. J'ai quelques raisons de penser que les catégories concernent les ressources. Donc dans la mesure où tu as déjà un lien entre réservation et ressource, par transitivité, tu obtiens la catégorie, sauf que là, selon ton modèle, ça suppose qu'une ressource peut appartenir à 1:n catégories... Sauf qu'en principe, tu ne réserves pas une catégorie, tu réserves une ressource. Enfin bon, c'est assez subjectif faute d'éléments plus clairs... à voir.

Il manque les contraintes fortes en fait, une ressource ne peut être que dans une seule catégorie (sauf certaines bien particulières, mais qui devront être gérées au cas par cas via le code).
Je voulais pas m'encombrer de deux tables pour ces deux cas là, voilà pourquoi on se retrouve avec ça.

Pour la clé qui se balade sous un nom d'emprunt, c'est à cause de modifications. En fait c'est pas le nom de la clé mais de la contrainte qu'on voit... Faut que je change ça.
J'avais fait un micmac moitié anglais moitié français sans m'en rendre compte...

N.B : c'est bien un MLD que j'ai représenté et non un MPD pour un sgbd précis (bien qu'il soit à destination de MySQL donc forcement...)
D'autant plus que le MPD ne se représente pas à ce que je sache, ou tout du moins il n'y a aucun intérêt à le faire tellement il est proche du MLD.
Un MPD pour moi c'est davantage un script SQL qu'un schéma.

N.B : c'est bien un MLD que j'ai représenté et non un MPD pour un sgbd précis (bien qu'il soit à destination de MySQL donc forcement...)
D'autant plus que le MPD ne se représente pas à ce que je sache, ou tout du moins il n'y a aucun intérêt à le faire tellement il est proche du MLD.
Un MPD pour moi c'est davantage un script SQL qu'un schéma.

Soit, faisons donc un peu de sémantique. Je me base sur mes connaissances en matière de méthode MERISE de modélisation de schéma de données. La première étape consiste à créer un MCD, donc un modèle conceptuel. On est totalement indépendant de tout SGBD. Mais le point important est qu'au stade du MCD on ne parle pas encore de tables puisqu'on est au stade des entités/associations et des propriétés de ces entités. La phase suivante est le MPD et on est toujours indépendant du SGBD. Il pourra être généré du script SQL à partir du MPD selon le SGBD visé et ça pourra donner lieu à des variantes, mais ça ne modifie pas le MPD. Le MLD, pour être franc, je ne l'ai jamais utilisé autrement qu'à l'époque ou je suivais des cours sur le sujet, mais on commence à se rapprocher du modèle de traitement et en principe on est toujours indépendant du SGBD.

Autre détail, MySQL Workbench utilisé ici n'est pas conçu pour suivre la méthode MERISE de modélisation puisqu'il n'existe pas de possibilité d'y élaborer un MCD, on passe au MPD directement, modèle où sont représentées les tables avec leurs colonnes et leurs clés étrangères issues de relations s'il y a lieu, et ce même si le modèle créé est en fin de compte assez proche d'un résultat qui aurait été obtenu avec la méthode MERISE

My 2¢

Un MLD reprendra tout ce que j'ai affiché, alors que le MPD nécessite un peu plus.
D'ailleurs je ne peux actuellement rien générer sous MySQL Workbench du fait que je n'ai pas tout renseigné.
C'est de là que je disais que c'était un MLD.
Cyrano, piégé par l'interprétation du fond et des formes !

J'ai du louper une marche quelque part, parce que je saisis pas trop.

Je suis pourtant pas complètement pourri en modélisation de bases en méthode MERISE et je sais par ailleurs que non seulement MWB n'est pas un véritable AGL pour faire du MERISE et ensuite que le vrai bon outil n'est pas à portée de mes finances pour l'acquérir, ce serait PowerAMC qui fait du vrai MERISE. Je l'ai utilisé énormément à une époque et je visualise fort bien la transition entre MCP et MDP : maintenant, je ne sais en fait pas trop à quoi tu fais référence en disant qu'il manque des éléments dans ton modèle pour en faire un véritable MPD