Discussion :

[kitdjine]

message supprimé!

[CinePhil]

Pas mal de choses à dire sur votre schéma...

Déjà, ce n'est pas un MCD mais, semble t-il un diagramme de relations du logiciel Access. Il contient des tables reliées alors qu'un MCD contient des entités et des associations.

Maintenant, occupons-nous de cette pauvre table solitaire appelée 'rôles'.
Elle contient des informations relative aux utilisateurs. Dès lors, pourquoi ne pas l'avoir appelée 'utilisateurs', ou mieux 'utilisateur' au singulier, si on se décide à faire un MCD, donc une entité-type représentant un modèle d'utilisateur.
Il y figure aussi cette notion de 'rôle'. Est-ce à dire qu'un utilisateur a un rôle et qu'un rôle ne peut être attribué qu'à un seul utilisateur ? Si plusieurs utilisateurs peuvent avoir le même rôle, alors il faut une entité appelée Role (sans accent circonflexe car selon le SGBD utilisé ça peut poser des problèmes donc prenons de bonnes habitudes) qu'on associera à l'entité Utilisateur de la façon suivante sur un MCD :
Utilisateur -1,1----Assumer----0,n- Role

Ce qui donnera plus tard les tables suivantes :
Role_ROL (ROL_Id, ROL_Nom)
Utilisateur_UTI (UTI_Id, UTI_Nom, UTI_Prenom, UTI_Login, UTI_MotDePasse, UTI_IdRole)

3 - j'ai défini une table rôles, qui doit en particulier indiquer
les utilisateurs gestionnaires des ressources et les super-utilisateurs
pouvant ajouter des rôles.

Nous avons donc des utilisateurs qui peuvent gérer des ressources et des ressources qui sont gérées par des utilisateurs.
Le pluriel est ici gênant. Il faut déterminer combien un utilisateur peut gérer au moins et au plus de resources et par combien d'utilisateurs au moins et au plus une ressource peut être gérée, afin de déterminer les cardinalités (les chiffres 1,1 et 0,n du MCD précédent) de l'association Gerer entre les entités Utilisateur et Ressource.
Je vais supposer qu'une seule personne gère une ressource mais qu'une personne peut gérer plusieurs ressources. On a alors le morceau de MCD suivant :
Utilisateur -0,n----Gerer----1,1- Ressource

Ce qui donnera plus tard les tables suivantes :
Utilisateur_UTI (UTI_Id, UTI_Nom, UTI_Prenom, UTI_Login, UTI_MotDePasse, UTI_IdRole)
Ressource_RSC (RSC_Id, RSC_Nom, RSC_IdGestionnaire)

1- il y a une table "catégories":
ce que je veux c'est que chaque categorie puisse avoir des attributs.
sachant qu'une catégorie est du type (salle de cours, voiture, vidéo projecteur) .

2- ce qui peut être réservé est une ressource (salle, vidéo-projecteur, voiture).

Si je comprends bien, l'ensemble des catégories va comprendre les éléments Salle de cours, Video-projecteur, Voiture.
Dès lors, une ressource n'est pas Salle de cours ou Video-Projecteur ou Voiture mais la salle de cours n° 5, le vidéo-projecteur n° 2 ou la voiture n° 4 par exemple.

une notion d'attributs pour les catégories serait nécessaire (attribut salle d'enseignement pour les catégories salles de TP informatiques et salles de cours Multi-media
par exemple). une ressource a un id et des attributs (comme les
catégories), chaque attributs ayant un nom, une description, une
valeur texte et une valeur numérique (par exemple le nom de la salle
est un attribut avec une valeur texte, la valeur numérique étant
inutile, la capacité de la salle est un attribut avec une valeur
numerique).

Là vous mélangez plusieurs choses et il y a plusieurs manières de procéder.
Si vous n'avez pas beaucoup de catégories et si chaque catégorie de ressource a des attributs spécifiques (type cours, labo ou informatique pour une salle ; marque et numéro d'immatriculation pour une voiture ; marque et numéro de série pour un vidéo-projecteur...) et des attributs communs (numéro de référence, nom de la ressource...), vous pouvez utiliser le principe de l'héritage.
Si vous avez beaucoup de catégories et/ou presque que des attributs différents selon la catégorie de la ressource, vous pouvez, comme vous semblez penser faire, affecter un nombre d'attributs variable à chaque ressource, laquelle est affectée à une catégorie.

Restons sur cette seconde méthode...
Nous avons donc les règles de gestion suivantes :
1) Une catégorie regroupe plusieurs ressources et une ressource n'est affectée qu'à une seule catégorie.
2) Une catégorie de ressource peut être caractérisée par plusieurs attributs et un attribut peut caractériser plusieurs catégories de ressources
3) Une ressource peut être caractérisée par les valeurs de plusieurs attributs et une valeur d'attribut peut caractériser plusieurs ressources

De 1), il découle le MCD suivant :
Categorie -0,n----Regrouper----1,1- Ressource

De 2), il découle le MCD suivant :
Attribut -1,n----Caractériser----0,n- Categorie

De 3), il découle le MCD suivant :
Attribut -1,n----Caractériser(valeur)----0,n- Ressource

A noter que les attributs des ressources devront être ceux des catégories.

Il en découlera les tables suivantes :
Categorie_CAT (CAT_Id, CAT_Libelle)
Attribut_ATR (ATR_Id, ATR_Libelle)
Ressource_RSC (RSC_Id, RSC_Nom, RSC_IdGestionnaire)
Atr_Caracteriser_Cat_ACC (ACC_IdAttribut, ACC_IdCategorie)
Atr_Caracteriser_Rsc_ACR (ACR_IdAttribut, ACR_IdRessource, ACR_Valeur)

Terminons par la réservation des ressources...
Un utilisateur peut réserver des ressources et une ressource peut-être réservée par plusieurs personnes... mais pas en même temps !

MCD :
Utilisateur -0,n----Réserver(période)----0,n- Ressource

Mais d'après votre schéma, l'association Réserver est porteuse d'autres informations dont certaines dépendent d'autres entités (Enseignant, Groupe). On peut donc effectivement transformer l'association en entité et compléter le MCD :
Utilisateur -0,n----Emettre----1,1- Reservation -1,n----Comprendre----0,n- Ressource
|----0,n----Bénéficier--------------1,1------|
Groupe -0,n----Concerner----1,1--------|
Enseignant -0,n----Bénéficier----1,1---|

J'ai supposé ici qu'une réservation pouvait comprendre plusieurs ressources (je réserve la salle informatique n° 2 avec le vidéo-projecteur n° 1).

2 questions me viennent à l'esprit :
1) L'utilisateur bénéficiaire et l'enseignant ne sont-ils pas la même personne ? ==> Auquel cas il faut supprimer l'association avec l'enseignant.
2) L'enseignant n'est-il pas un utilisateur spécial ? ==> Auquel cas il faut utiliser l'héritage de Utilisateur vers Enseignant s'il a des attributs spéciaux par rapport aux autres utilisateurs.

Je vais supposer que la réponse à la question 1 est oui. Ce qui va donner les tables suivantes :
Groupe_GRP (GRP_Id, GRP_Nom)
Utilisateur_UTI (UTI_Id, UTI_Nom, UTI_Prenom, UTI_Login, UTI_MotDePasse, UTI_IdRole)
Ressource_RSC (RSC_Id, RSC_Nom, RSC_IdGestionnaire)
Reservation_RSV (RSV_ID, RSV_DateHeureDebut, RSV_DateHeureFin, RSV_IdEmetteur, RSV_IdBeneficiaire, RSV_IdGroupe)
Rsv_Comprendre_Rsc_RCR (RCR_IdRessource, RCR_IdReservation)

Il faudra en outre s'assurer qu'une ressource ne peut pas être réservée plusieurs fois à la même période.

Bon courage pour la suite.

[kitdjine]

voici mon mcd final!