Conception, validation des migrations des clés étrangères (UML => model relationnel) [Résolu]

[geforce]

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)

[ego]

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)

[geforce]

Envoyé par ego

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

[ego]

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

[geforce]

Envoyé par ego

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)

[fsmrel]

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

[geforce]

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

[fsmrel]

Bonsoir,

Envoyé par geforce

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