Discussion :

[yozart]

Bonjour,

je fais actuellement face a une situation un peu difficile (pour moi en tout cas ^^). Je cherche a fusionner deux tables.

Voici déjà mon MCD:



J'aimerais donc n'avoir plus qu'une seule entité "Zone price". Mon soucis principal est que, malheureusement, le pricing subZone peut être null dans un certain nombre de cas.

[fsmrel]

Quelles sont les deux tables (ou plutôt les deux entités-types) à "fusionner" ?

[yozart]

Price per zone et Price per subzone

Elles possèdent exactement les même champs.

[fsmrel]

Les cardinalités 1,1 sont mises entre parenthèses, ce qui signifie que vous utilisez l’identification relative : est-ce un choix délibéré ?

Cela dit, vous pouvez procéder à la généralisation des entités-types PRICE_PER_ZONE et PRICE_PER_SUBZONE.

[yozart]

Merci pour votre réponse,

Les identifiants relatifs sont effectivement la pour une bonne raison:
le prix obtenu dépend de la zone (voire de la sous zone)

Dans votre schéma, il semble donc que je ne puisse avoir qu'un prix par "from_weight" là où il me faut une clé du genre "Zone" + (éventuelle) "Sous Zone" + "from weight" => me donne le prix

D'ailleurs, j'ai mis que le from_weight en clé mais faut'il que je rajoute le to_weight dedans? Je pense que ca n'apportera rien vu que le from_weight est forcément different pour une même zone / sous-zone

Donc mon soucis se pose au niveau du "éventuelle".

(j'suis pas sur que ça soit très clair mon truc lol)

[fsmrel]

Bonsoir,

Les identifiants relatifs sont effectivement la pour une bonne raison:
le prix obtenu dépend de la zone (voire de la sous zone)

En fait, l’identification relative est justifiée du fait de la règle selon laquelle pour une valeur de la paire {PzId, ppsz_from_weight} on ne peut avoir qu’une valeur pour les autres attributs de l’entité-type PRICE_PER.

Dans votre schéma, il semble donc que je ne puisse avoir qu'un prix par "from_weight" là où il me faut une clé du genre "Zone" + (éventuelle) "Sous Zone" + "from weight" => me donne le prix.

Non. Considérez MLD dérivé du MCD que je vous ai proposé :



Parce que {PriceId} est clé de la table PRICE_PER, alors pour une valeur de l’attribut PriceId on ne peut avoir une seule valeur de prix (attributs pp_price_fixe, pp_price_var, ...). Pour une valeur de l’attribut pp_from_weight on peut avoir un nombre quelconque de valeurs de prix.

Mais vous avez défini les règles suivantes :

• Dans le cas des prix par zones, pour une paire {PzId, pp_from_weight} on ne peut pas avoir plus d’un prix,
• Dans le cas des prix par sous-zones, pour un triplet {PzId, PszId, pp_from_weight} on ne peut pas avoir plus d’un prix.

Pour que ces règles soient respectées, on doit mettre en œuvre des contraintes (assertions) qui peuvent être rédigées ainsi selon la norme SQL :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
CREATE ASSERTION ASSERT01 CHECK 
    (NOT EXISTS 
        (
         SELECT y.PzId, x.pp_from_weight
         FROM   PRICE_PER AS x JOIN PRICE_PER_ZONE AS y
                  ON x.PriceId = y.PriceId
         GROUP BY y.PzId, x.pp_from_weight
         HAVING COUNT(*) > 1
        )) ; 
 
CREATE ASSERTION ASSERT02 CHECK 
    (NOT EXISTS 
        (
         SELECT y.PzId, y.PszId, x.pp_from_weight
         FROM   PRICE_PER AS x JOIN PRICE_PER_SUBZONE AS y
                  ON x.PriceId = y.PriceId
         GROUP BY y.PzId, y.PszId, x.pp_from_weight
         HAVING COUNT(*) > 1
        )) ;

Si votre SGBD n’est pas à niveau par rapport à la norme, ces contraintes sont à programmer par le truchement de triggers.

Il existe aussi une solution alternative, avec laquelle assertion et triggers ne s’imposent pas. Considérons le MCD suivant, dans lequel l’attribut pp_from_weight a été sorti de l’entité-type PRICE_PER et incorporé dans les entités-types PRICE_PER_ZONE et PRICE_PER_SUBZONE :




Le MLD correspondant est le suivant, dans lequel on définit (manuellement) une clé alternative {PzId, pp_from_weight} pour la table PRICE_PER_ZONE, et une clé alternative {PzId, PszId, pp_from_weight} pour la table PRICE_PER_SUBZONE :



La table PRICE_PER_ZONE est dotée des deux clé candidates {PriceId} et {PzId, pp_from_weight}, donc pour une valeur de {PriceId} on a exactement une valeur de {PzId, pp_from_weight} et réciproquement. La table PRICE_PER est dotée de la clé candidate {PriceId} et par transitivité, pour une valeur de {PzId, pp_from_weight} on a exactement une valeur de {pp_to_weight}, {pp_price_fixe}, etc. Même principe pour les sous-zones.

Maintenant, si ce qui vaut pp_from_weight vaut aussi pour pp_to_weight (voire d’autres attributs de la table PRICE_PER), c'est-à-dire si {PzId, pp_to_weight} est aussi clé candidate, il faudra faire migrer cet attribut lui aussi...

A vous de voir si après tout votre MCD initial convient. Je lui fais quand même un reproche :

Quand un MCD est prêt à être traduit en MLD, si un attribut dont l’utilisateur peut changer la valeur participe à un identifiant, alors ce dernier doit être seulement alternatif. Voyez à ce sujet les observations que j’ai faites ici à GuiDjad à propos de l’attribution des numéros Siren par l’INSEE.

L’entité-type PRICE_PER_ZONE qui figure dans votre MCD doit devenir la suivante :



L’attribut PriceId est valorisé seulement par l’application (auto-incrément par exemple), il est invariant et invisible pour l’utilisateur puisque celui-ci n’en a pas l’usage.


Bon, maintenant je vais aller chanter sous la neige qui tombe, qui tombe alors que nous ne sommes encore qu’en automne (heureux encore qu'il y aurait paraît-il comme un réchauffement climatique...)

[yozart]

Bonjour, merci pour cette réponse on ne peut plus détaillée... J'ai bien saisi votre système et il semble effectivement répondre entièrement a mes attentes.

Je vous remercie donc vraiment pour tout ce temps que vous avez passé a m'expliquer si clairement les choses!


(HS: Réchauffement climatique oui, le petit bémol est que nous somme dans une période glaciaire. => D'où la grande gravité de ce réchauffement

CF mon ancienne prof de Bio ^^)