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 confirmé
    Conception, validation des migrations des clés étrangères (UML => model relationnel)
    Bonjour,
    Les tables suivantes : Appareille, Type consommation, Consommation

    Conception des cardinalité en UML:
    Type_consommation --1------------1.*-- Appareille ---1.*------------1-- Consommation

    Conception des cardinalité à la MCD:
    Type_consommation --1.*------------1-- Appareille --1-------------1.*-- Consommation



    Ce qui devrait donnés :
    Type consommation (id_ Type consommation, libeller_ Type consommation),
    Appareille (id_ Appareille, id_ Type consommation, libeller _ Appareille),
    Consommation (id_ Consommation, id_Appareille, Quantité_consomation, prix, DateTime).

    Merci d'avance de me dire s'il y a des anomalie (ces en ouvrant de débat que la lumière jaillit)

  2. #2
    Rédacteur

    pas tout à fait
    Quand en UML du a du 1--* (* ou qq chose > 1) tu as une foreign key du côté de la table qui stocke la classe côté *. Appareille dans ton cas doit donc avoir 2 clés, une vers Type_Consommation, une autre vers Consommation.

    NB : Tu ne veux pas plutôt dire Appareil ? (pas lle)

  3. #3
    Membre confirmé
    Citation Envoyé par ego Voir le message
    pas tout à fait
    Quand en UML du a du 1--* (* ou qq chose > 1) tu as une foreign key du côté de la table qui stocke la classe côté *. Appareille dans ton cas doit donc avoir 2 clés, une vers Type_Consommation, une autre vers Consommation.
    Ce qui normalement de vrais donnés :

    Type consommation (id_ Type consommation, id_Appareill*, libeller_ Type consommation),
    Appareille (id_ Appareill, libeller _ Appareille),
    Consommation (id_ Consommation, id_Appareill*, Quantité_consomation, prix, DateTime).

  4. #4
    Rédacteur

    Non c'est Appareille qui doit avoir 2 clés étrangères pointant l'une vers Type_Consommation et l'autre vers Consommation

    Appareille
    + id_Appareille
    + fk_Type_Consommation
    + fk_Consommation

    A moins que ton modèle UML soit faux

  5. #5
    Membre confirmé
    Citation Envoyé par ego Voir le message
    Non c'est Appareille qui doit avoir 2 clés étrangères pointant l'une vers Type_Consommation et l'autre vers Consommation

    Appareille
    + id_Appareille
    + fk_Type_Consommation
    + fk_Consommation

    A moins que ton modèle UML soit faux
    selon vous elle devrais être comment ma modélisation UML ? (pour que je puis me poser les bonne question)

  6. #6
    Expert éminent sénior
    Bonsoir,


    ego a raison de s’étonner et d’insister, en effet il y a une contradiction dans ce que vous présentez.


    Reprenons votre diagramme de classes :
    Type_consommation --1------------1.*-- Appareille ---1.*------------1-- Consommation
    Traduit en français (en remplaçant le mot « Appareille » par le mot « Appareil » qui est un nom de chose, alors que le premier représente le verbe « Appareiller »), on peut supposer que les règles de gestion des données sont à peu de choses près les suivantes :
    (R11) Un appareil fait référence à exactement un type de consommation,
    (R12) Un type de consommation est référencé par au moins un appareil,
    (R13) Un appareil fait référence à exactement une consommation,
    (R14) Une consommation est référencée par au moins un appareil.
    Par ailleurs, vous écrivez (cf. votre 1er message) :
    Type consommation (id_Type consommation, libeller_Type consommation)
    Appareille (id_ Appareille, id_Type consommation, libeller_ Appareille)
    Consommation (id_Consommation, id_Appareille, Quantité_consomation, prix, DateTime)
    Traduit en français, en faisant l’hypothèse que les noms d’attributs colorés (en marron ou apparenté) jouent le rôle de clés primaires SQL et que les noms d’attributs mis en italiques jouent le rôle de clés étrangères :
    (R21) Un appareil fait référence à exactement un type de consommation,
    (R22) Un type de consommation est référencé par au moins un appareil,
    (R23) Un appareil est référencé par au moins une consommation,
    (R24) Une consommation fait référence à exactement un appareil.
    La règle R13 est en contradiction avec la règle R23 et la règle R14 est en contradiction avec la règle R24.

    =>

    Veuillez formuler en français (correct tant qu’à faire) les règles de gestion à appliquer.

    Cela dit, le diagramme de classes correspondant aux règles R21-R24 est le suivant :
    Type_consommation --1..1------------1..*-- Appareil ---1..1------------1..*-- Consommation
    Et, sémantiquement parlant, plutôt le suivant :
    Type_consommation --1------------1..*-- Appareil ◀▶ --1..1------------1..*-- Consommation
    (où ◀▶ symbolise la composition.)
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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

  7. #7
    Membre confirmé
    Merci "fsmrel" pour ta réponse très instructive.


    Pour cette conception :
    du diagramme de classes correspondant aux règles R21-R24 est le suivant :
    Type_consommation --1..1------------1..*-- Appareil ---1..1------------1..*-- Consommation
    Et, sémantiquement parlant, plutôt le suivant :
    Type_consommation --1------------1..*-- Appareil ◀▶ --1..1------------1..*-- Consommation
    (où ◀▶ symbolise la composition.)
    Ce qui fait que le passage des clés étrangére ce fait comme suite :
    Type consommation (id_Type consommation, id_ Appareil*, libeller_Type consommation)
    Appareille (id_ Appareil, id_Consommation*, libeller_ Appareille)
    Consommation (id_Consommation, Quantité_consomation, prix, DateTime)

    Ps : merci de m’avoir donnés une méthodologie pour sortir ces règles est avoir les cardinalités de notre conception.
    Sa chant aussi que, Quand en UML on a du 1--* (* ou qq chose > 1) on a une foreign key du côté de la table qui stocke la classe côté *.

  8. #8
    Expert éminent sénior
    Bonsoir,


    Citation Envoyé par geforce Voir le message
    Ce qui fait que le passage des clés étrangères se fait comme suit :
    Type consommation (id_Type consommation, id_ Appareil*, libeller_Type consommation)
    Appareille (id_ Appareil, id_Consommation*, libeller_ Appareille)
    Consommation (id_Consommation, Quantité_consomation, prix, DateTime)
    Pas vraiment :

    Un appareil faisant référence à un type d’appareil et une consommation faisant référence à un appareil, la représentation au niveau tabulaire est plutôt la suivante (clés étrangères en italiques) :
    Type_consommation (id_Type consommation, libelle_Type_consommation)
    Appareil (id_Appareil, id_Type consommation, libelle_Appareil)
    Consommation (id_Consommation, id_Appareil, Quantite_consommation, prix, DateTime_consommation)

    Dans le cas de la composition, la structure de la table Consommation est la suivante :
    Consommation (id_Appareil, id_Consommation, Quantite_consommation, prix, DateTime_consommation)

    Autrement dit, il vous faut faire comme Dagobert et remettre les choses à l'endroit...
    Faites simple, mais pas plus simple ! (A. Einstein)
    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 »)

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