Discussion :

[fredericbdr]

Bonjour,

N'étant pas développeur à la base, je dois faire une petite application en ligne pour permettre de voir en gros qui est dans quelle salle au sein d'une organisation.
J'ai effectué un schéma pour construire ma base de données mais je dois dire que je m'y perds un peu, il est à améliorer évidemment...

Voici mes tables:

Table Users:
Champs : id_user (clé primaire, nom, prénom, équipe, mail, numéro_bureau, date_entrée

Table Salles:
Champs : id (clé primaire), numéro_salle, étage

Table Occupation:
Champs : date (clé primaire), numéro_salle (clé étrangère en référence à la table salles), id_user (clé étrangère en référence à la table users), date_sortie

Est-ce qu'avec ceci je peux m'en sortir ?

Je vous remercie d'avance.

[al1_24]

Si Date (d'entrée ?) est la clé prmaire de la table Occupation, cela signifierait q'une salle peut être occupée pour un jour donné...
Il faudrait commencer par ajouter le numéro de salle dans cette clé primaire.

[escartefigue]

Bonsoir,

Pour bien modéliser une base de données, il faut connaitre les règles de gestion

Puisque vous ne les avez pas communiquées, admettons les règles de gestion suivantes

R001 : une salle, à une date donnée, ne peut être réservée que par un et un seul utilisateur
R002 : un utilisateur, à une date donnée, peut réserver plusieurs salles
R003 : à une date donnée plusieurs salles peuvent être réservées

Ces règles impliquent le modèle conceptuel suivant :

UTILISATEUR 0,n <-- reserver --- 0,n SALLE
.................................│
.Calendrier 0,n ---------┘

Notez que les noms des entités-type sont au singulier : "utilisateur" et "salle"
Point le plus important : la flèche en direction de la personne matérialise l'unicité de la personne pour un couple (date, salle)


de ce modèle conceptuel de données (MCD), on peut générer le modèle logique (MLD) suivant (les PK sont soulignées) :
Table UTILISATEUR (toujours au singulier) : UT_id, UT_nom, UT_prenom, UT_date_nais, etc...
Table SALLE SA_id, SA_numero, SA_superficie, etc...
Table RESERVER SA_id, CA_date, UT_id
la table CALENDRIER n'a pas besoin d'être générée, elle n'a d'intérêt que pour contribuer à alimenter la PK de la table "reserver" issue de la relation ternaire.
Point important : avec un outil de modélisation la génération du MLD à partir du MCD proposera, pour la table "reserver" issue de la relation, une PK composée des identifiants de chaque entité-type contribuant à la relation, soit : UT_id+SA_id+CA_id
Donc, pour satisfaire les règles de gestion proposées plus haut, il faudra supprimer la colonne UT_id de la PK de la table "reserver" : le couple identifiant_salle+date rend de ce fait l'utilisateur unique

[fredericbdr]

Bonjour,

Merci de votre réponse, oui évidemment j'avais oublié de donner les règles.
La seule importante est qu'un bureau ne peut contenir au plus 4 personnes max.
Est-ce que ça change quelque chose dans le schéma que vous proposez ?
Merci.

[escartefigue]

OK je pensais qu'il s'agissait de réserver des salles, en fait il s'agit de connaitre qui est dans quel bureau c'est bien ça ?

Dans tous les cas, la rédaction des règles de gestion est un point de passage obligé, par exemple

R001 : un utilisateur, à un instant "t" n'est présent que dans un et un seul bureau
R002 : un bureau peut accueillir de zéro à quatre utilisateurs
R003 : etc...

[fredericbdr]

Oui c'est bien ça, il s'agit d'avoir une vue d'ensemble de qui est dans quel bureau et lorsqu'un nouveau entrant arrive, qu'on lui attribue facilement un bureau et que l'on sache où il est.

[escartefigue]

En général on affecte une personne à un emplacement de bureau qui n'est pas déjà affecté à une autre personne pour la période considérée.
On en revient à une solution similaire à ce que j'avais proposé plus haut, à savoir modéliser une relation ternaire entre PERSONNE, EMPLACEMENT et DATE au niveau conceptuel.
Puis, au niveau du modèle logique, on supprime l'identifiant personne de la PK de la table issue de cette relation ternaire, de sorte à ce que pour un couple {emplacement;date} il y ait une et une seule personne affectée.

Conceptuellement, cela donne

BUREAU_BU (BU_id, BU_capacite, BU_long, BU_larg...) 1,n --- disposer --- (1,1) EMPLACEMENT_EM(EM_id, EM_num...) 0,n --- affecter_af (datfin) --- 0,n PERSONNE_PE(PE_id, Pe_nom, PE_prenom, PE_matricule...)
.................................................................................................................................................................................................│
................................................................................................................................................................................................0,n
...................................................................................................................................................................................CALENDRIER_CA(CA_datdeb, CA_joursem...)


Ce qui donne les tables :

BUREAU_BU (BU_id, BU_capacite, BU_long, BU_larg...)
EMPLACEMENT_EM(BU_id, EM_id, EM_num...) <- emplacement identifié relativement au bureau, d'où la PK composite
PERSONNE_PE(PE_id, Pe_nom, PE_prenom, PE_matricule...)
AFFECTER(BU_id, EM_id, CA_datdeb, PE_id, AF_datfin)

Il suffira dans votre cas, de vérifier qu'il existe au moins un emplacement disponible pour la période dans le bureau.

[fredericbdr]

D'accord, je vois, merci bien pour vos explications, désormais je comprends mieux le principe.
Bonne journée.