Discussion :

[new_wave]

Bonjour,

Dans le schéma suivant:
INGREDIENT(nom_ingrédient, lib_type_ingrédient)

TYPE INGREDIENT(lib_type_ingredient,unité_mesure_ingredient)
j'aimerais apporter une précision en transformant l'identifiant de chacune de ces entités en un numéro incrémenté, ce qui donnerait cela :

INGREDIENT( num_ingredient,nom_ingredient, num_type_ingredient)

TYPE_INGREDIENT(num_type_ingredient, lib_type_ingredient,unité_mesure_ingredient)

Le problème est que l'on peut dire qu'il existe un Df entre lib_type_ingredient et unité_mesure_ingredient dans l'entité TYPE_INGREDIENT, et donc que ce schéma n'est pas en 3 FN.
comment supprimer cette contradiction apparente?

sinon, pouvez vous me préciser si la normalisation du MCD doit se faire après le passage du MCD au MLD ou pas forcément.

Merci encore beaucoup de votre aide.
Cordialement.

Natahlie Harbonne

[hed62]

comment supprimer cette contradiction apparente?

En n'ajoutant pas les id, je dirais... A valider.

[JPhi33]

Bonjour Nathalie,

Selon l'hypothèse de départ :

• nom_ingrédient -> lib_type_ingrédient (1)
• lib_type_ingredient -> unité_mesure_ingredient (2)

L'ajout des numéros sous-entend les DF :

• num_ingredient -> nom_ingredient (3)
• num_ingredient -> num_type_ingredient (4)
• num_type_ingredient -> lib_type_ingredient (5)
• num_type_ingredient -> unité_mesure_ingredient (6)

Ce schéma n'est pas en 3FN car la DF (6) n'est pas directe, elle peut être obtenue par (5) + (2).
Le cas de lib_type_ingredient est un peu plus "bizarre" : cet attribut est déterminé par nom_ingredient (1) et par num_type_ingredient (5), mais pas par la concaténation des deux (sinon il aurait existé la DF {num_type_ingredient, nom_ingredient} -> lib_type_ingredient). Donc il dépend de l'identifiant de la table dans laquelle il se trouve, mais aussi d'un autre attribut extérieur à cette table.


Solution 1 :

Décomposition de TYPE_INGREDIENT :
T1(num_type_ingredient, lib_type_ingredient)
T2(lib_type_ingredient, unité_mesure_ingredient)

Création d'une nouvelle table :
T3(nom_ingrédient, lib_type_ingrédient)

INGREDIENT reste telle quelle :
INGREDIENT(num_ingredient, nom_ingredient, num_type_ingredient)

Toutes les tables sont en 3FN et toutes les DF existantes sont satisfaites (mais pas toi, j'imagine !)


Solution 2 :

Remettre en cause l'hypothèse de départ, c'est-à-dire l'existence des DF (1) et (2) après ta 2e modélisation.
Le fait de décider que les ingrédients doivent être identifiés par un numéro doit répondre à un besoin, sinon c'est inutile. Ce besoin est probablement que nom_ingrédient est un mauvais identifiant. Du coup, la DF (1) est caduque. De même pour num_type_ingrédient qui rend caduque la DF (2).
Et la contradiction est levée.


JPhi33