Discussion :

[wam35]

Bonjour à tous, et merci beaucoup pour ce forum qui a m'a déjà été salutaire plus d'une fois dans d'autres domaines.

Je viens à vous aujourd'hui car je souhaite réaliser une base de données permettant de gérer une médiathèque, avec une interface php. Pour l'instant, je me concentre sur la partie "dvd", c'est à dire la partie permettant de gérer la collection de films et de séries.
Par exemple, chaque film sera représenté par une fiche présentant les diverses informations le concernant, ainsi que les acteurs, le réalisateur, etc qui auront eux aussi leur fiche de présentation. Il y aura aussi des albums photos pour chaque film, série et "personne" (acteur ou réalisateur).
Voilà en gros pour la présentation sommaire de la première étape de mon projet.

J'ai créé un modèle de cette base de données (sous DBDesigner 4), en créant des tables de type innoDB pour permettre d'avoir des relations entre mes tables. Par contre, je suis un grand débutant en bases de données, et j'ai peur d'avoir rendu "bancale" mon modèle en essayant d'avoir les tables les plus génériques possible.

Mais venons-en à la situation qui me préoccupe :
J'aimerai pouvoir gérer les relations la table photo et les autres, pour permettre la suppression automatique des photos qui ne sont plus référencées. Or une photo peut aussi bien appartenir à un film (ou une série) qu'à un acteur ou un réalisateur, ce qui fait que l'utilisation de ON DELETE CASCADE ne convient pas dans ce cas. J'ai cru que RESTRICT ou NO ACTION pourraient convenir, mais apparemment dans le cas où on voudrait supprimer un film représenté par une photo qui elle même représente un acteur, cela bloque toute l'opération et rien n'est supprimé. (désolé si ce n'est pas clairement expliqué...)

je voudrais donc savoir si mon modèle est valable, et si oui quelle solution je peux utiliser pour gérer les relations entre les tables.

Merci d'avance !
Cordialement.

[fsmrel]

Bonsoir,

Si j’ai bien compris...

Supposons que l’on veuille supprimer une photo non utilisée par une série. Concernant la relation entre la table Photo, la table personne_has_photo et la table Personne, la difficulté est la conséquence des cardinalités 0,1. En effet, en ayant des cardinalités 1,1, le Restrict côté Photo ne serait pas un problème : si un tuple T existait dans la table personne_has_photo pour la photo à supprimer, l’opération échouerait et la personne associée conserverait sa photo. Si le tuple T n’existait pas, la suppression de la photo fonctionnerait et personne ne serait lésé.

Si maintenant la photo à supprimer n'est partagée avec quelque personne que ce soit au sein de la table personne_has_photo, et qu’il faille la supprimer malgré le RESTRICT, parce qu’elle n’est donc la propriété que d’un tuple Film, il devient nécessaire d’utiliser un trigger, qui s’assure que les photos à supprimer ne sont pas partagées avec quelque personne que ce soit au sein de la table personne_has_photo et qui, si tel est le cas, effectue directement les suppressions dans la table personne_has_photo.

Concernant les relations avec la table Série, l’approche est la même.

Ce que j'ai écrit n'est peut-être pas limpide, à vous de me dire...

Incidemment, vous devriez remplacer NULL par NOT NULL dans vos tables.

[wam35]

Bonjour,

merci beaucoup d'avoir pris le temps de me répondre un dimanche soir !

Supposons que l’on veuille supprimer une photo non utilisée par une série. Concernant la relation entre la table Photo, la table personne_has_photo et la table Personne, la difficulté est la conséquence des cardinalités 0,1. En effet, en ayant des cardinalités 1,1, le Restrict côté Photo ne serait pas un problème : si un tuple T existait dans la table personne_has_photo pour la photo à supprimer, l’opération échouerait et la personne associée conserverait sa photo. Si le tuple T n’existait pas, la suppression de la photo fonctionnerait et personne ne serait lésé.

En fait, j'avais défini des cardinalités 0,1 car une photo peut n'être liée par exemple qu'à un film, et à aucune personne (ou inversement). Mais maintenant, avec votre réponse, je me rends compte que je n'ai pas assez bien analysé mon modèle...

Si maintenant la photo à supprimer n'est partagée avec quelque personne que ce soit au sein de la table personne_has_photo, et qu’il faille la supprimer malgré le RESTRICT, parce qu’elle n’est donc la propriété que d’un tuple Film, il devient nécessaire d’utiliser un trigger, qui s’assure que les photos à supprimer ne sont pas partagées avec quelque personne que ce soit au sein de la table personne_has_photo et qui, si tel est le cas, effectue directement les suppressions dans la table personne_has_photo.

Je me suis renseigné un peu sur les triggers (que je ne connaissais pas du tout), et effectivement cela semble prometteur pour me permettre d'automatiser la gestion de la base de données. Par contre je n'ai pas l'impression que DBDesigner 4 me permette de développer ces triggers, donc il va falloir que je trouve un autre logiciel gratuit qui le permette (à moins qu'on puisse les ajouter "à la main" ?)... j'avoue que tout ça est encore assez obscur pour moi...

[fsmrel]

Bonsoir,

Je me suis renseigné un peu sur les triggers (que je ne connaissais pas du tout), et effectivement cela semble prometteur pour me permettre d'automatiser la gestion de la base de données.

Personnellement, je les définis au niveau du SGBD, par exemple dans un contexte T-SQL avec SQL Server 2005 Express.

Bon courage à vous.