Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 55
    Points : 24
    Points
    24

    Par défaut Schema base de données pour gestion d'occupation de salles dans une entreprise

    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.

  2. #2
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Ingénieur d'études décisionnel
    Inscrit en
    mai 2002
    Messages
    7 829
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 57
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur d'études décisionnel
    Secteur : Conseil

    Informations forums :
    Inscription : mai 2002
    Messages : 7 829
    Points : 24 603
    Points
    24 603

    Par défaut

    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.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  3. #3
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut Commençons par le commencement

    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

  4. #4
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 55
    Points : 24
    Points
    24

    Par défaut

    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.

  5. #5
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut

    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...

  6. #6
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 55
    Points : 24
    Points
    24

    Par défaut

    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.

  7. #7
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 910
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 910
    Points : 8 947
    Points
    8 947
    Billets dans le blog
    1

    Par défaut

    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.

  8. #8
    Membre à l'essai
    Profil pro
    Inscrit en
    juillet 2009
    Messages
    55
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2009
    Messages : 55
    Points : 24
    Points
    24

    Par défaut

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

Discussions similaires

  1. [AC-2007] Création d'une base de données pour Gestion des stocks
    Par manovo31 dans le forum Modélisation
    Réponses: 1
    Dernier message: 25/10/2012, 23h38
  2. Création d'une base de données pour gestion des stocks
    Par samaaantha dans le forum Modélisation
    Réponses: 8
    Dernier message: 08/05/2008, 22h13
  3. Base de données pour Gestion de stock
    Par Armagnak dans le forum Schéma
    Réponses: 1
    Dernier message: 08/06/2007, 10h47
  4. [Conception] base de données pour gestion de salles
    Par lydia99 dans le forum PHP & SGBD
    Réponses: 3
    Dernier message: 29/05/2007, 22h56

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo