IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
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

Merise Discussion :

[MCD] Gestion de materiel


Sujet :

Merise

  1. #1
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut [MCD] Gestion de materiel
    Salut !

    Je fais actuellement un MCD pour la gestion des biens de mon entreprise. Je devrais gérer l'ensemble des machines et des biens mobiliers (03 grandes familles : matériel de bureau ; mobilier de bureau et matériels informatique) ; chaque bien est identifié par un code à barres (unique) et chaque famille possède un identifiant et des caractéristiques. Après acquisition un matériel doit être affecté à un utilisateur qui occupe un bureau et une structure bien déterminé
    Il s'agit en fait de:
     gérer les entrées et les sorties de matériels.
     Gérer les affectations et les états des matériels.
     Connaitre le fournisseur et le livreur et la date d’acquisition.
     Connaitre l'agent à qui on a affecté le matériel et la date à laquelle l'affectation a eu lieu.
     Le matériel peut être réaffecté une autre fois à un autre utilisateur
     connaitre les dates de début et de fin auxquelles on a donné un matériel qui a un état défectueux à un Réparateur.
     savoir l'état (en réparation, affecté, défectueux) du matériel
     le matériel peut être proposé à la reforme s’il est irréparable.

    Je mets mon MCD en pièce jointe
    Pouvez-vous me donner votre avis et vos conseils afin de savoir en quoi je peux l'optimiser svp ?


    En plus je ne sais pas comment fait un MCD en tenant compte de l'historisation et l’opération d’inventaire.

    Merci de votre aide par avance
    Nom : test.jpg
Affichages : 14560
Taille : 201,0 Ko

  2. #2
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut Observations
    Bonsoir djamel_c,


    Le MCD est pas mal. Quelques points :

    (1) Ce qui vaut pour les tables de la base de données vaut évidemment pour les entités-types qui en sont la source : utiliser des identifiants non significatifs ; dans ce sens et à titre d’exemple, un code-barres ne peut pas être identifiant « principal », mais seulement alternatif.

    (2) A priori, un matériel ne devrait être proposé au plus qu’une seule fois à la réforme.

    (3) A cause de SQL qui attend son heure, éviter les espaces dans le nom d’une entité-type (MATERIEL_BUREAU plutôt que Materiel de bureau). Mettre le nom des entités-types au singulier : ORDINATEUR, IMPRIMANTE, EQUIPEMENT_RESEAU.

    (4) Puisque tous les sous-types ont une marque et un modèle, factoriser les attributs marque et modele dans le surtype MATERIEL.

    (5) Les sous-types héritent de l’identifiant de leur surtype : l’attribut code_famille ne peut être qu’identifiant alternatif (et à factoriser...)

    (6) En l’état, à une date donnée, un matériel peut être affecté à plus d’un utilisateur :

    
    UTILISATEUR 
    
    utilisateur_id    utilisateur_nom
    1                 Fernand
    2                 Raoul
    
    MATERIEL
    
    materiel_id    date_acquisition    valeur_acquisition
    1              d1                  v1
    
    AFFECTATION
    
    affectation_id    materiel_id    periode_affectation    utilisateur_id
    
    1                 1              p1                     1
    2                 1              p1                     2
    
    

    Pour garantir la contrainte comme quoi à une date donnée un matériel ne peut être affecté qu’à un seul utilisateur, la paire {materiel_id, periode_affectation} doit faire l’objet d’un identifiant alternatif. Si JMerise ne permet pas de déclarer cet identifiant, il faudra le faire au niveau SQL, ou passer à DB-MAIN :






    (6) Concernant l’inventaire : il s’agit en principe de voir où sont les matériels, depuis quand et dans quel état. Vérifiez si sont présents dans le MCD les éléments à cet effet. Quant à l’historisation, que voulez-vous historiser ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  3. #3
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Décembre 2013
    Messages
    147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Décembre 2013
    Messages : 147
    Points : 82
    Points
    82
    Par défaut Proposition d'idée sur le MCD
    Bonjour!
    D'après votre schéma, je voudrais vous demander d'abord si les matériels sont affectés aux bureaux ou aux utilisateurs?
    Puis que chaque utilisateur appartient à un bureau et peut être affecté à un autre bureau, je pense que le matériel devait être orienté aux bureaux et son utilisateur serait aussi connu car il appartient forcément à un bureau. Sinon si l'utilisateur se déplace avec le matériel quand il est affecté à un autre bureau ou quand il est en mission, je pense en ce moment que c'est correct. Ensuite la question c'est de savoir si tous les travailleurs utilisent des matériels?
    Aussi au niveau Etat_materiel, que voulez vous dire ici? si le matériel est en bon, mauvais, défectueux? Si c'est cela, il faut revoir la cardinalité entre matériel et avoir qui est (1,1), ne serait elle pas (1,N) car un matériel peut être bon à une date donnée et ensuite peut être en mauvais état à une autre date.
    Entre Panne et Subir, est ce que la panne est toujours unique ou peut être plusieurs? si oui pourquoi ne pas mettre (1,N)?
    Peut être je ne comprend pas, je voudrais une bonne explication pour pouvoir continuer sur les autres parties.
    Merci pour une meilleur explication.
    Une fois de plus merci par avance.

  4. #4
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 134
    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 : 10 134
    Points : 38 557
    Points
    38 557
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Quelques commentaires :
    - n'utilisez pas du varchar partout, ce format est efficient pour des données dont la taille du contenu peut varier de façon importante, et dont la taille maximale est significative, disons plus de 30 caractères. En deçà d'une taille maxi de 20 ou 30 cars, il vaut mieux utiliser du char.

    - identiiants : n'utilisez jamais de varchar pour vos identifiants . Privilégiez plutôt des formats smallint, integer ou bigint selon.

    - code barre est un format de présentation d'un identifiant, c'est donc restrictif d'utilser "code barre" comme nom d'attribut pour un identifiant.


    - adresses : il est souvent préférable de les sortir des entités type de façon à pouvoir multiplier les occurrences, vos tiers peuvent avoir chacun plusieurs adresses (de livraison, de facturation, de siège....), une entité-type dédiée avec un typage des adresse est donc plus souple. Vous devriez utiliser la norme de la poste pour coder vos adresses.

    - vous distinguez fournisseur et sous-traitant, sont-ce vraiment deux acteurs différents ? Certains de vos founisseurs ne font ils pas aussi de la maintenance ?

    - si tel_frn est un numéro de téléphone, alors il est préférable d'utiliser un format alpha plutôt que numérique, de plus, les téléphones, courriels et autres médias doivent être externalisés pour la même raison que les adresses.

  5. #5
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut
    Bonjour fsmrel
    je vous remercie monsieur pour les conseils d'or que vous m'avez donné
    pour l'inventaire je veux faire de sorte de créer une table qui prend comme entrée la liste des Equipements disponible physiquement et la faire comparée avec ce qui est dans l'application . es que c'est faisable ?
    concernant l'historique je veux dire es que mon MCD contient les éléments qui me permettent d'afficher le cycle de vie de l’équipement dés l'acquisition jusqu’à la réforme avec touts les interventions .

  6. #6
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut
    Bonjour Mr escartefigue

    je vous remercie pour les commentaires et pour votre attention je vais refaire mon MCD en prenant en compte tes conseils .
    par rapport aux cardinalités Que pensez-vous?

  7. #7
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut
    bonjour Mr zizoua
    je vous remercie pour votre attention
    par rapport aux affectation vous avez raison en réalité un matériel est affecté à une structure (un service qui est responsable sur le matériel) mais au moment de l'affectation le numéro de bureau et l'utilisateur doivent être connus , un matériel est forcément utilisé par un employé(utilisateur) mais pas le contraire (à un seul utilisateur on peut affecté plusieurs matériels)
    concernant l'état j'ai pensé que à un moment donné un matériel possède un et un seul état et un état concerne plusieurs matériels d'ou la les cardinalités
    1-1===0-n
    panne et subir: ce n'est pas la même panne un matériel va subir 0 à n pannes et une panne concerne un et un seul matériel
    en faites je ne sais pas que c'est juste ou pas ; j'attend votre réponse et merci en core une autre fois

  8. #8
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 134
    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 : 10 134
    Points : 38 557
    Points
    38 557
    Billets dans le blog
    9
    Par défaut
    Pour les cardinalités et les contraintes fonctionnelles, vous devriez les formaliser sous formes de règles de gestion. C'est la meilleure façon de procéder pour permettre de vérifier que le modèle correspond au besoin.

    Exemple, d'après vos cardinalité, je peux écrire la règle suivante :
    R01 : un fournisseur fournit 1 à plusieurs matériels
    Question : dois-je pouvoir référencer un fournisseur, même si je ne lui ai jamais commandé de matériel ? si la réponse est oui, alors la règle devient
    R01 : un fournisseur fournit de zéro à plusieurs matériels

    Pour ce qui concerne l'état du matériel, soit c'est l'état actuel qui vous intéresse, auquel cas l'attribut doit être rapatrié dans l'entité-type matériel, soit vous voulez gérer l'historique à date, auquel cas il faut ajouter l'entité-type date dans la relation "avoir". L'entité-type date prendra tout son sens au moment de générer le MLD, car elle permettra d'ajouter la date comme identifiant de la table issue de la relation "avoir", date indispensable pour gérer un historique.

  9. #9
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut Demande d'aide
    bonsoir
    j'ai refait le schéma,voila le MCD avec les règles de gestion ;merci de le vérifier avec moi et de m'aider avec d'autres propositions si c'est possible (j'ai pas encore crée l'entité type adresse pour les tiers ). la contrainte d'unicité {materiel_id, periode_affectation} je vais la faire avec SQL

     Les règles de gestion :

     Un matériel appartient à une et une seule famille et une famille contient un ou plusieurs matériels.
     Au moment de l’acquisition un matériel est identifié par un code à barres (unique pour chaque occurrence).
     L’origine d’un matériel fait référence à un seul fournisseur.
     Un matériel doit obligatoirement être affecté après l’acquisition.
     A une date donnée après acquisition un matériel est affecté à une structure(le numéro de bureau et l’utilisateur doivent être connus).
     Un matériel peut être réaffecté à une autre structure à une date différente.
     Un matériel peut subir plusieurs pannes à des dates différentes.
     Une panne donne lieu à une opération de maintenance.
     Une opération de maintenance est effectuée par un sous-traitant.
     Un matériel, et à une date donnée possède un et un seul état.
     Selon l’état on peut déclarer la cession du matériel (destruction, vente, reforme).

    Nom : mcd.jpeg
Affichages : 11077
Taille : 192,3 Ko

  10. #10
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir djamel_c,


    Une panne est une propriété multivaluée de l’entité-type MATERIEL, ce qui fait que PANNE est une entité-type faible (weak entity-type) : une panne n’a pas d’existence propre, et si on supprime un matériel, les pannes qu’il a pu avoir n’ont plus de raison d’être, elles disparaissent forcément avec lui. Voyez l’article de Chen The Entity-Relationship Model—Toward a Unified View of Data.

    Pour faire symboliquement de PANNE une entité-type faible, avec JMerise, vous rendez relatif le lien connectant PANNE et SUBIR :





    Concernant l’entité-type AFFECTATION :

    Vous affectez un matériel à une structure, mais la phrase suivante est ambiguë : « le numéro de bureau et l’utilisateur doivent être connus » ; est-ce à dire qu’on ne cherche pas à savoir à quel utilisateur le matériel est affecté ? La connaissance de la structure suffit ?

    Quoi qu’il en soit, selon votre diagramme, à une date donnée, un matériel donné peut être affecté à plusieurs structures. La présence de l’attribut periode_affectation ne suffit pas, encore faut-il que cet attribut participe à l’identification de l’entité-type AFFECTATION : pour s’assurer qu’à une date donnée une affectation concerne une seule structure, il faudrait commencer par utiliser l’identification relative (à l’instar de PANNE).

    A noter que l’attribut date_affectation est inclus dans l’attribut periode_affectation :vous éliminez soit l’un, soit l’autre. Si votre SGBD propose le type PERIODE (ou équivalent, cas par exemple de PostgreSQL) utilisez-le, sinon conservez l’attribut date_affectation et supprimez l’attribut periode_affectation. Dans ce dernier cas, vous devrez gérez vous-même le non recouvrement des périodes d’affectation pour un matériel donné (en général ça se fait à coups de triggers...)


    La ternaire AVOIR doit être porteuse d’une CIF (contrainte d’intégrité fonctionnelle), pour signifier qu’à une date donnée, un matériel est dans un seul état donné.

    Il n’y a aucune dépendance entre l’état d’un matériel et le fait qu’il soit en panne ?
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  11. #11
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 134
    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 : 10 134
    Points : 38 557
    Points
    38 557
    Billets dans le blog
    9
    Par défaut
    Bonjour,

    Je me permets de m'auto-citer, tant pis pour le diamètre de mes chevilles

    Citation Envoyé par escartefigue Voir le message
    Bonjour,
    - identiiants : n'utilisez jamais de varchar pour vos identifiants . Privilégiez plutôt des formats smallint, integer ou bigint selon.
    Vous avez remplacé varchar par char, c'est mieux, mais les CPU sont optimisées pour traiter des nombres, et par exemple un char(4) permet beaucoup moins de valeurs possibles qu'un integer d'encombrement identique.
    Ce type de préoccupation qui concerne les performances de votre SGBD futur est l'une des très rares entorses à la règle selon laquelle le MCD ne se préoccupe que du fonctionnel

  12. #12
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut
    bonsoir monsieur fsmrel

    par rapport à l'entité faible PANNE j'ai bien compris le principe .

    Concernant l’entité-type AFFECTATION :
    je veux dire par la phrase « le numéro de bureau et l’utilisateur doivent être connus » q'au moment d'affectation du matériel à la structure concerné le service qui pend en charge l'établissement de la décision d’affectation doit connaitre le numéro de bureau et l'utilisateur , la connaissance de la structure seule ne suffit pas .

    pour assurer la contrainte comme quoi à un moment donné un matériel peut être affecté q'à une seule structure je doit mettre code_affectation+période_affectation comme une clé primaire de l'entité type AFFECTATION avec l'utilisation d'une identification relative entre AFFECTATION et STRUCTURE c'est ça?

    "La ternaire AVOIR doit être porteuse d’une CIF (contrainte d’intégrité fonctionnelle) "
    es que je peu l'assurer avec les cardinalités 1-1 ____0-n entre MATERIEL et ETAT_MATERIEL? sinon comment je doit procéder?


    "Il n’y a aucune dépendance entre l’état d’un matériel et le fait qu’il soit en panne ?"
    comment créer cette dépendance?
    je veux dire par ETAT: excellent-bon-mauvais-en panne-en maintenance-en service.

    à titre d'information le SGBD que je vais l’utiliser c'est INGRES 2010
    Merci

  13. #13
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut
    bonsoir escartefigue

    il y'a quelques identifiants que je doit les déclarer de type char par exemple pour les structures l'entreprise utilise une codification avec des lettres(SAG -DGSI-...) et la même chose pour les bureaux (y1.05; t2.04 ....) comment je doit faire dans ce cas.

  14. #14
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir djamel_c,


    Citation Envoyé par djamel_c
    il y'a quelques identifiants que je doit les déclarer de type char par exemple pour les structures l'entreprise utilise une codification avec des lettres(SAG -DGSI-...) et la même chose pour les bureaux (y1.05; t2.04 ....) comment je doit faire dans ce cas ?
    Il faut déclarer ces identifiants en tant qu’identifiants alternatifs. Prenons l’exemple de l’entité-type BUREAU, vous commencez par déclarer un identifiant artificiel {id_bureau} (en notant que JMerise confond identifiant et clé primaire...) :




    Puis vous déclarez l’identifiant alternatif {code_bureau} (choix : UNIQUE) :






    Citation Envoyé par djamel_c
    Concernant l’entité-type AFFECTATION :
    je veux dire par la phrase « le numéro de bureau et l’utilisateur doivent être connus » qu'au moment d'affectation du matériel à la structure concerné le service qui pend en charge l'établissement de la décision d’affectation doit connaître le numéro de bureau et l'utilisateur , la connaissance de la structure seule ne suffit pas .
    Soit. Mais une fois l’affectation faite, se contente-t-on de savoir que le matériel en cause détermine une structure, sans avoir à savoir quel utilisateur s’en sert ? En tout cas c’est ce que laisse entendre votre MCD : tel matériel est affecté à telle structure, peu importe le bureau où il se trouve et qui s’en sert, une fois affecté. C’est ça ?



    Citation Envoyé par djamel_c
    pour assurer la contrainte comme quoi à un moment donné un matériel ne peut être affecté qu'à une seule structure je dois mettre code_affectation + periode_affectation comme une clé primaire de l'entité type AFFECTATION avec l'utilisation d'une identification relative entre AFFECTATION et STRUCTURE c'est ça?
    Pas vraiment... Si vous identifiez relativement AFFECTATION à STRUCTURE, cela voudrait dire qu’à une date donnée, une structure a un seul matériel ! L’entité-type AFFECTATION est identifiée relativement à MATERIEL, et c’est seulement dans ce cas-là qu’à une date donnée un matériel est affecté à une seule structure.

    Supposons maintenant que l’utilisateur (bien qu’admin) ne puisse pas modifier la période d’affectation : dans ces conditions, en théorie l’attribut periode_affectation fait partie de l’identifiant de l’entité-type AFFECTATION. Les choses étant plus simples à appréhender au stade SQL, passons-y, mais en remplaçant l’attribut periode_affectation par la paire d’attributs debut_affectation, fin_affectation (en effet, je n’ai pas trouvé de type intervalle dans la doc d’INGRES 10.2, mais peut-être ai-je mal cherché ? Vous me direz...)


    
    CREATE TABLE MATERIEL
    (
            id_materiel            INT             NOT NULL
          , code_barres            CHAR(13)        NOT NULL
          , libelle_mat            VARCHAR(32)     NOT NULL
        , CONSTRAINT MATERIEL_PK PRIMARY KEY (id_materiel)
        , CONSTRAINT MATERIEL_AK UNIQUE (code_barres)     
    ) ;
    
    CREATE TABLE STRUCTURE
    (
            id_structure           INT             NOT NULL
          , code_structure         VARCHAR(16)     NOT NULL
          , libelle_struct         CHAR(13)        NOT NULL
        , CONSTRAINT STRUCTURE_PK PRIMARY KEY (id_structure)
        , CONSTRAINT STRUCTURE_AK UNIQUE (code_structure)     
    ) ;
    
    CREATE TABLE AFFECTATION
    (
            id_materiel            INT             NOT NULL
          , debut_affectation      DATE            NOT NULL
          , fin_affectation        DATE            NOT NULL
          , libelle_mat            VARCHAR(32)     NOT NULL
          , id_structure           INT             NOT NULL
        , CONSTRAINT AFFECTATION_PK PRIMARY KEY (id_materiel, debut_affectation)
        , CONSTRAINT AFFECTATION_MATERIEL_FK FOREIGN KEY (id_materiel)
            REFERENCES MATERIEL (id_materiel)    
        , CONSTRAINT AFFECTATION_STRUCTURE_FK FOREIGN KEY (id_structure)
            REFERENCES STRUCTURE (id_structure)    
    ) ;
    
    

    A moins qu’il existe en fait un type intervalle pour les dates, je rappelle que ce sera à vous de garantir le non recouvrement des périodes d’affectation d’un matériel, en principe au moyen d’un trigger (instruction CREATE RULE).

    Je n’ai pas fait figurer l’attribut code_affectation. S’il a un sens pour l’utilisateur, il faudra l’ajouter en tant que clé alternative de la table AFFECTATION :

    
         , CONSTRAINT AFFECTATION_UK UNIQUE (code_affectation) 
    
    

    Supposons maintenant que l’utilisateur puisse modifier la période d’affectation : par prudence, la clé primaire qui a été définie dans le code SQL précédent devrait devenir clé alternative, et la clé primaire être composée de la paire {id_materiel, id_affectation}, où id_affectation est un attribut invariant et non significatif :


    
    CREATE TABLE MATERIEL
    (
            id_materiel            INT             NOT NULL
          , code_barres            CHAR(13)        NOT NULL
          , libelle_mat            VARCHAR(32)     NOT NULL
        , CONSTRAINT MATERIEL_PK PRIMARY KEY (id_materiel)
        , CONSTRAINT MATERIEL_AK UNIQUE (code_barres)     
    ) ;
    
    CREATE TABLE STRUCTURE
    (
            id_structure           INT             NOT NULL
          , code_structure         VARCHAR(16)     NOT NULL
          , libelle_struct         CHAR(13)        NOT NULL
        , CONSTRAINT STRUCTURE_PK PRIMARY KEY (id_structure)
        , CONSTRAINT STRUCTURE_AK UNIQUE (code_structure)     
    ) ;
    
    CREATE TABLE AFFECTATION
    (
            id_materiel            INT             NOT NULL
          , id_affectation         INT             NOT NULL
          , debut_affectation      DATE            NOT NULL
          , fin_affectation        DATE            NOT NULL
          , libelle_mat            VARCHAR(32)     NOT NULL
          , id_structure           INT             NOT NULL
        , CONSTRAINT AFFECTATION_PK PRIMARY KEY (id_materiel, id_affectation)
        , CONSTRAINT AFFECTATION_AK UNIQUE (id_materiel, debut_affectation)
        , CONSTRAINT AFFECTATION_MATERIEL_FK FOREIGN KEY (id_materiel)
            REFERENCES MATERIEL (id_materiel)    
        , CONSTRAINT AFFECTATION_STRUCTURE_FK FOREIGN KEY (id_structure)
            REFERENCES STRUCTURE (id_structure)    
    ) ;
    
    


    Citation Envoyé par djamel_c
    "La ternaire AVOIR doit être porteuse d’une CIF (contrainte d’intégrité fonctionnelle) "
    est-ce que je peux l’assurer avec les cardinalités 1-1 ____0-n entre MATERIEL et ETAT_MATERIEL? sinon comment je doit procéder?
    Vous ne pouvez pas procéder avec les cardinalités 1-1 ____0-n entre MATERIEL et ETAT_MATERIEL. En effet, cela voudrait dire qu’un matériel M est dans un état E, mais indépendamment du temps.

    Vous avez dans la FAQ Merise, ici, un couplet sur les CIF concernant les associations ternaires. Mais je ne sais pas si JMerise permet de les modéliser. Sinon, ça se réglera au niveau SQL...

    Si JMerise sait faire, alors on devrait avoir un diagramme dans le style de celui qui est présenté dans la FAQ, mais simplifiable comme ci-dessous, où la CIF est symbolisée par une pointe de flèche (dessinée avec PAINT...) :





    Au niveau SQL, on complète le script ci-dessus (il n’y a évidemment pas de table DATE) :


    
    CREATE TABLE ETAT_MATERIEL
    (
            id_etat                INT             NOT NULL
          , libelle_etat           VARCHAR(32)     NOT NULL
        , CONSTRAINT ETAT_MATERIEL_PK PRIMARY KEY (id_etat)
    ) ;
    
    CREATE TABLE AVOIR
    (
            id_materiel            INT             NOT NULL
          , id_etat                INT             NOT NULL
          , debut_etat             DATE            NOT NULL
          , fin_etat               DATE            NOT NULL
        , CONSTRAINT AVOIR_PK PRIMARY KEY (id_materiel, debut_etat)
        , CONSTRAINT AVOIR_MATERIEL_FK FOREIGN KEY (id_materiel)
            REFERENCES MATERIEL (id_materiel)    
        , CONSTRAINT AVOIR_ETAT_MATERIEL_FK FOREIGN KEY (id_etat)
            REFERENCES ETAT_MATERIEL (id_etat)    
    ) ;
    
    
    Noter qu’à l’instar des affectations, les états des matériels (table AVOIR) sont caractérisés par une période...



    Citation Envoyé par djamel_c
    "Il n’y a aucune dépendance entre l’état d’un matériel et le fait qu’il soit en panne ?"
    comment créer cette dépendance?
    je veux dire par ETAT: excellent-bon-mauvais-en panne-en maintenance-en service.
    Il faudra contrôler par trigger que, si le matériel M est dans l’état E à la date D, et si cet état est différent de « en panne » (table AVOIR), alors à la date D il n’y a pas de ligne dans la table PANNE telle que l’état y soit « en panne » pour le matériel M, à la date D (par contre, si une telle ligne existe, alors dans la table AVOIR, à la date D, le matériel M doit être dans l’état « en panne »).
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  15. #15
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 134
    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 : 10 134
    Points : 38 557
    Points
    38 557
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par fsmrel Voir le message
    Il faut déclarer ces identifiants en tant qu’identifiants alternatifs.
    Tout à fait : il est très dangereux de choisir des identifiants soumis à des nomenclatures internes ou externes comme identifiants primaires, car ces nomenclatures sont sujettes à modification. Or un idenfiant primaire doit avant tout être stable, et, dans la mesure du possible, concis. C'est la raison pour laquelle on utilise souvent des identifiants primaires attribués par le SGBD qui répondent à ces 2 critères.

  16. #16
    Membre à l'essai
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Février 2013
    Messages
    15
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Algérie

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie

    Informations forums :
    Inscription : Février 2013
    Messages : 15
    Points : 21
    Points
    21
    Par défaut
    Bonsoir fsmrel
    bonsoir escartfigue

    Citation Envoyé par fsmrel Voir le message

    Il faut déclarer ces identifiants en tant qu’identifiants alternatifs.
    ok c'est reglé je vous remercie


    Citation Envoyé par fsmrel Voir le message

    Soit. Mais une fois l’affectation faite, se contente-t-on de savoir que le matériel en cause détermine une structure, sans avoir à savoir quel utilisateur s’en sert ? En tout cas c’est ce que laisse entendre votre MCD : tel matériel est affecté à telle structure, peu importe le bureau où il se trouve et qui s’en sert, une fois affecté. C’est ça ?
    Ah d’accords donc pour assurer la règle : un matériel M est affecté à une structure S et un bureau B sous la responsabilité de l’utilisateur U je dois créer deux autres relations [AFFECTATION_BUREAU et AFFECTATION_UTILISATEUR] avec des cardinalités 1-1,0-n ?

    Citation Envoyé par fsmrel Voir le message
    L’entité-type AFFECTATION est identifiée relativement à MATERIEL, et c’est seulement dans ce cas-là qu’à une date donnée un matériel est affecté à une seule structure.
    oui c'est fait.

    Citation Envoyé par fsmrel Voir le message

    (en effet, je n’ai pas trouvé de type intervalle dans la doc d’INGRES 10.2, mais peut-être ai-je mal cherché ? Vous me direz...)
    d'accord je vais faire une petite recherche.

    Citation Envoyé par fsmrel Voir le message

    Vous avez dans la FAQ Merise, ici, un couplet sur les CIF concernant les associations ternaires. Mais je ne sais pas si JMerise permet de les modéliser. Sinon, ça se réglera au niveau SQL...
    j'ai lu le cours et j'ai bien compris merci beaucoup

    Citation Envoyé par fsmrel Voir le message

    Il faudra contrôler par trigger que, si le matériel M est dans l’état E à la date D, et si cet état est différent de « en panne » (table AVOIR), alors à la date D il n’y a pas de ligne dans la table PANNE telle que l’état y soit « en panne » pour le matériel M, à la date D (par contre, si une telle ligne existe, alors dans la table AVOIR, à la date D, le matériel M doit être dans l’état « en panne »).
    pour les triggers je les maîtrise pas encore si vous avez un lien de cours simple pour débuter

    sinon par rapport au reste du MCD et aux entités types CESSION , MAINTENANCE tout est bon?y'a pas de problèmes?

  17. #17
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut
    Bonsoir djamel_c,


    Citation Envoyé par djamel_c
    Pour assurer la règle : un matériel M est affecté à une structure S et un bureau B sous la responsabilité de l’utilisateur U je dois créer deux autres relations [AFFECTATION_BUREAU et AFFECTATION_UTILISATEUR] avec des cardinalités 1-1,0-n ?
    Non. Une seule association suffit : AFFECTATION_UTILISATEUR (comme dans votre 1er MCD). En l’occurrence :

    — Du fait de la cardinalité 1,1 portée par la patte connectant AFFECTATION et AFFECTATION_UTILISATEUR, une affectation de matériel détermine un utilisateur ;

    — Du fait de la cardinalité 1,1 portée par la patte connectant UTILISATEUR et OCCUPE, un utilisateur détermine un bureau, donc par transitivité une affectation de matériel détermine un bureau ;

    — Du fait de la cardinalité 1,1 portée par la patte connectant BUREAU et EST DANS, un BUREAU détermine une structure, donc par transitivité une affectation de matériel détermine une structure.

    En conséquence, si dans la base de données on sait à quel utilisateur U a été affecté le matériel M, transitivement on sait dans quel bureau B et dans quelle structure S se trouve M.

    La seule association AFFECTATION_UTILISATEUR suffit, l’association AFFECTATION_BUREAU est inutile (et provoquerait un viol de BCNF), et en plus, au même motif, il faut supprimer l’association CONCERNE connectant AFFECTATION et STRUCTURE.


    Concernant l’entité-type CESSION, la cardinalité 0,N pourrait être remplacée par 1,N (une cession concerne au moins un matériel). Il faudra prévoir une contrainte (donc un trigger) interdisant qu’un matériel soir au même moment cédé et affecté.

    Pour l’entité-type MAINTENANCE, ça devrait aller.


    Pour des exemples de triggers, reportez-vous à la documentation « Ingres 10.2, SQL Reference Guide ». Le style ressemble plus à celui de PostgreSQL qu’à celui des autres SGBD (ce qui n'est pas très étonnant...)
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

  18. #18
    Membre régulier
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Décembre 2013
    Messages
    147
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Guinée

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Associations - ONG

    Informations forums :
    Inscription : Décembre 2013
    Messages : 147
    Points : 82
    Points
    82
    Par défaut Remarque sur votre MCD
    Bonjour!
    Je reviens en vous posant cette question: Un utilisateur occupe un bureau et pour toujours? ou il peut changer de bureau? si tel n'est pas le cas regardez au niveau de votre schéma pour la cardinalité (1,1), ne serait elle pas (1,N) et à une date donnée? entre utilisateur et occupe.
    Ensuite que voulez vous dire par
    CESSION
    ? Par exemple: cession 2012 2013 ou 2015 2016 etc...? Donnez des éclaircissements pour nous permettre de comprendre.
    Au niveau de la maintenance: est ce que la maintenance concerne une seule panne? si le matériel a maintenant plusieurs pannes, que faites vous?
    Autre remarque: Un matériel est affecté à une structure une fois pour toute ou le matériel peut être affecté à d'autres structures?
    La partie Etat_materiel et matériel est expliqué par mes prédécesseurs.
    Peut être je ne vous ai pas compris mais j'aimerais une meilleure explication.
    Merci par avance.

  19. #19
    Modérateur
    Avatar de escartefigue
    Homme Profil pro
    bourreau
    Inscrit en
    Mars 2010
    Messages
    10 134
    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 : 10 134
    Points : 38 557
    Points
    38 557
    Billets dans le blog
    9
    Par défaut
    Citation Envoyé par Zizoua Voir le message
    Je reviens en vous posant cette question: Un utilisateur occupe un bureau et pour toujours? ou il peut changer de bureau? si tel n'est pas le cas regardez au niveau de votre schéma pour la cardinalité (1,1), ne serait elle pas (1,N) et à une date donnée? entre utilisateur et occupe.
    J'aurais tendance à dire que si l'occupation est à date, elle est probablement avec un maxi 1, sauf si un utilisateur peut avoir 2 bureaux simultanément

    Citation Envoyé par Zizoua Voir le message
    Ensuite que voulez vous dire par ? Par exemple: cession 2012 2013 ou 2015 2016 etc...? Donnez des éclaircissements pour nous permettre de comprendre.
    Ne pas confondre Cession commençant par "C" comme le verbe Céder de la même famille, avec Session commençant par "S" comme saison (qui n'a aucun rapport étymologique, mais c'est un moyen de s'en souvenir)
    Ici il me semble qu'il s'agit de cession de matériel (vente, don, échange...)

  20. #20
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 001
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 001
    Points : 30 905
    Points
    30 905
    Billets dans le blog
    16
    Par défaut L'utilisateur change de bureau
    Bonsoir,


    Citation Envoyé par Zizoua
    Un utilisateur occupe un bureau et pour toujours? ou il peut changer de bureau? si tel n'est pas le cas regardez au niveau de votre schéma pour la cardinalité (1,1), ne serait elle pas (1,N) et à une date donnée? entre utilisateur et occupe.
    Supposons que djamel_c réponde ainsi : « Un utilisateur peut changer de bureau, mais on ne suit pas ses changements successifs ». Dans ces conditions, la cardinalité 1,1 reste valable.

    Mais un problème intéressant se pose : qu’advient-il de l’affectation au bureau B1 du matériel M1 affecté par ailleurs à l’utilisateur U1 ?

    Ou bien la règle est la suivante :

    (R1) Le matériel M1 reste affecté à l’utilisateur U1 et le suit dans son nouveau bureau B2 quand il déménage ;

    Ou bien la règle est la suivante :

    (R2) Le matériel M1 reste affecté au bureau B1 et n’est donc plus affecté à l’utilisateur U1, lequel devra être doté d’un matériel M2 lors de son arrivée dans le bureau B2.

    Exemple de script SQL au cas où appliquerait la règle R1 :

    
    CREATE TABLE MATERIEL
    (
            id_materiel            INT             NOT NULL
          , code_barres            CHAR(13)        NOT NULL
          , libelle_mat            VARCHAR(32)     NOT NULL
        , CONSTRAINT MATERIEL_PK PRIMARY KEY (id_materiel)
        , CONSTRAINT MATERIEL_AK UNIQUE (code_barres)     
    ) ;
    
    CREATE TABLE STRUCTURE
    (
            id_structure           INT             NOT NULL
          , code_structure         VARCHAR(8)      NOT NULL
          , libelle_structure      CHAR(32)        NOT NULL
        , CONSTRAINT STRUCTURE_PK PRIMARY KEY (id_structure)
        , CONSTRAINT STRUCTURE_AK UNIQUE (code_structure)     
    ) ;
    
    CREATE TABLE BUREAU
    (
            id_structure           INT             NOT NULL
          , id_bureau              INT             NOT NULL
          , code_bureau            VARCHAR(8)      NOT NULL
        , CONSTRAINT BUREAU_PK PRIMARY KEY (id_structure, id_bureau)
        , CONSTRAINT BUREAU_AK UNIQUE (code_bureau)  
        , CONSTRAINT BUREAU_STRUCTURE_FK FOREIGN KEY (id_structure)
            REFERENCES STRUCTURE (id_structure)    
    ) ;
    
    CREATE TABLE UTILISATEUR
    (
            id_utilisateur         INT             NOT NULL
          , code_utilisateur       VARCHAR(8)      NOT NULL
          , nom_utilisateur        VARCHAR(32)     NOT NULL
        , CONSTRAINT UTILISATEUR_PK PRIMARY KEY (id_utilisateur)
        , CONSTRAINT UTILISATEUR_AK UNIQUE (code_utilisateur)  
    ) ;
    
    CREATE TABLE UTILISATEUR_BUREAU
    (
            id_utilisateur         INT             NOT NULL
          , id_structure           INT             NOT NULL
          , id_bureau              INT             NOT NULL
        , CONSTRAINT UTILISATEUR_BUREAU_PK PRIMARY KEY (id_utilisateur)
        , CONSTRAINT UTILISATEUR_BUREAU_SK UNIQUE (id_utilisateur, id_structure, id_bureau) 
        , CONSTRAINT UTILISATEUR_BUREAU_UTILISATEUR_FK FOREIGN KEY (id_utilisateur)
            REFERENCES UTILISATEUR (id_utilisateur)    
        , CONSTRAINT UTILISATEUR_BUREAU_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
            REFERENCES BUREAU (id_structure, id_bureau)    
    ) ;
    
    CREATE TABLE AFFECTATION
    (
            id_materiel            INT             NOT NULL
          , id_affectation         INT             NOT NULL
          , debut_affectation      DATE            NOT NULL
          , fin_affectation        DATE            NOT NULL
          , libelle_mat            VARCHAR(32)     NOT NULL
          , id_structure           INT             NOT NULL
          , id_bureau              INT             NOT NULL
          , id_utilisateur         INT             NOT NULL
        , CONSTRAINT AFFECTATION_PK PRIMARY KEY (id_materiel, id_affectation)
        , CONSTRAINT AFFECTATION_AK UNIQUE (id_materiel, debut_affectation)
        , CONSTRAINT AFFECTATION_MATERIEL_FK FOREIGN KEY (id_materiel)
            REFERENCES MATERIEL (id_materiel)    
        , CONSTRAINT AFFECTATION_BUREAU_FK FOREIGN KEY (id_structure, id_bureau)
            REFERENCES BUREAU (id_structure, id_bureau)    
        , CONSTRAINT AFFECTATION_UTILISATEUR_FK FOREIGN KEY (id_utilisateur, id_structure, id_bureau)
            REFERENCES UTILISATEUR_BUREAU (id_utilisateur, id_structure, id_bureau) ON UPDATE CASCADE   
    ) ;
    
    
    La clé primaire UTILISATEUR_BUREAU_PK de la table UTILISATEUR_BUREAU est le singleton {id_utilisateur}, mais pour éviter d’avoir à mettre en œuvre des triggers pour contrôler les déménagements des utilisateurs et de leurs matériels, on utilise les services d’une surclé UTILISATEUR_BUREAU_SK {id_utilisateur, id_structure, id_bureau}.

    Pour garantir la cohérence des affectations des matériels aux bureaux lors des déménagements, on CASCADE sur la table AFFECTATION les mises à jour de la table UTILISATEUR_BUREAU.

    Exemple d’affectation :


    
    INSERT INTO MATERIEL (id_materiel, code_barres, libelle_mat) VALUES (1, '1234567890123', 'matos 1') ;
    INSERT INTO MATERIEL (id_materiel, code_barres, libelle_mat) VALUES (2, '1234567890124', 'matos 2') ;
    
    INSERT INTO STRUCTURE (id_structure, code_structure, libelle_structure) VALUES (1, 's1', 'structure 1') ;
    INSERT INTO STRUCTURE (id_structure, code_structure, libelle_structure) VALUES (2, 's2', 'structure 2') ;
    
    INSERT INTO BUREAU (id_structure, id_bureau, code_bureau) VALUES (1, 1, 'b10') ;
    INSERT INTO BUREAU (id_structure, id_bureau, code_bureau) VALUES (1, 2, 'b12') ;
    INSERT INTO BUREAU (id_structure, id_bureau, code_bureau) VALUES (2, 1, 'b27') ;
    
    INSERT INTO UTILISATEUR (id_utilisateur, code_utilisateur, nom_utilisateur) VALUES (1, 'u1', 'Raoul') ;
    
    INSERT INTO UTILISATEUR_BUREAU (id_utilisateur, id_structure, id_bureau) VALUES (1, 1, 1) ;
    
    INSERT INTO AFFECTATION (id_materiel, id_affectation, debut_affectation, fin_affectation, libelle_mat, id_structure, id_bureau, id_utilisateur) VALUES (1, 1, '2016-04-19', '9999-12-31', 'm1', 1, 1, 1) ;
    
    
    =>

    
    AFFECTATION
    
    id_materiel  id_affectation  debut_affectation  fin_affectation  libelle_mat  id_structure  id_bureau  id_utilisateur
    1            1               2016-04-19         9999-12-31        m1          1             1          1
    
    

    L’utilisateur u1 déménage dans un bureau d’une autre structure :


    
    UPDATE UTILISATEUR_BUREAU SET id_structure = 2, id_bureau = 1 WHERE id_utilisateur = 1 ;
    
    
    =>

    
    AFFECTATION
    
    id_materiel  id_affectation  debut_affectation  fin_affectation  libelle_mat  id_structure  id_bureau  id_utilisateur
    1            1               2016-04-19         9999-12-31        m1          2             1          1
    
    
    (a) Faites simple, mais pas plus simple ! (A. Einstein)
    (b) Certes, E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)

    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale
    Modéliser les données avec MySQL Workbench
    Je ne réponds pas aux questions techniques par MP. Les forums sont là pour ça.

+ Répondre à la discussion
Cette discussion est résolue.
Page 1 sur 2 12 DernièreDernière

Discussions similaires

  1. mcd en uml de gestion du materiel informatique
    Par juniorus dans le forum UML
    Réponses: 1
    Dernier message: 18/08/2008, 09h53
  2. [MCD] Gestion d'acces a des applications
    Par Tibler dans le forum Schéma
    Réponses: 12
    Dernier message: 25/04/2006, 18h10
  3. [MCD] [MCD] Gestion des dates
    Par brionne dans le forum Schéma
    Réponses: 3
    Dernier message: 30/05/2003, 13h01
  4. [BEST_PRACTICE][Merise] MCD & gestion de date
    Par Seb7 dans le forum Schéma
    Réponses: 4
    Dernier message: 16/04/2003, 17h07

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