Discussion :

[insane_80]

Bonjour à tous,

J'ai une table "Phones". Et dans cette table je veux ajouter l'information du flash (au moment de prise des photos).
Pour un phone, cette information peut être l'un de ces cas :

1- Flash existe;
2- Flash n'existe pas;
3- L'information n'est pas connue.

Pour le 1er cas, il y a aussi deux cas :
a- Le type de flash est connu, dans ce cas on doit ajouter cette information (type flash).
b- il n'est pas connu.

Après une première réflexion, j'ai ajouté dans la table deux colonnes : La première "existFlash" est de type boolean & la deuxième "typeFlash" présente le type de flash.

1- Flash existe ==> existFlash = Oui & typeFlash = une_chaîne (ou la chaîne vide dans le cas où le type n'est pas connu)
2- Flash n'existe pas; ==> existFlash = Non & typeFlash = Null
3- L'information n'est pas connue. ==> existFlash = Null & typeFlash = Null

Est-ce que j'ai fait la bonne modélisation ou Non ?

Merci pour votre aide.

Cordialement.

[Richard_35]

Bonjour Insane_80,

1- Flash existe ==> existFlash = Oui & typeFlash = une_chaîne (ou la chaîne vide dans le cas où le type n'est pas connu)
2- Flash n'existe pas; ==> existFlash = Non & typeFlash = Null
3- L'information n'est pas connue. ==> existFlash = Null & typeFlash = Null

Est-ce que j'ai fait la bonne modélisation ou Non ?

==> eh bien, tu n'es pas dans la modélisation mais, déjà, dans l'applicatif. Et tu jongles avec la valeur NULL, ce qui t'obligera à jongler éternellement...

Je te suggère de lire cet excellent billet de CinePhil, ainsi que celui-ci qui donnera :



Tables :

• Phone(IdPhone, InfoFlashInconnue, ...) ;
• TypeFlash(IdTypeFlash, ...) ;
• Phone_TypeFlash(#IdPhone, #IdTypeFlash, ...).

La cohérence entre InfoFlashInconnue et la présence d'un couple dans Phone_TypeFlash devra être contrôlée par un trigger. Je n'aime pas trop la solution de créer un type de flash "inconnu"...

[insane_80]

Merci Richard_35.

D'après votre modélisation, je n'aurai que deux tables :

• Phone(IdPhone, InfoFlashInconnue, IdTypeFlash ...) ;
• TypeFlash(IdTypeFlash, ...) ;

Et j'aurai trois tables s'il y a plusieurs types de flash pour un phone.

Est-ce que c'est vrai ce que j'ai dit ?

Cordialement.

[insane_80]

Et comment faire pour modéliser l'information "Existence du flash" ? Est-ce qu'elle est l'attribut InfoFlashInconnue lui-même?

Cordialement.

[Richard_35]

Bonjour Insane_80,

D'après votre modélisation, je n'aurai que deux tables :
Phone(IdPhone, InfoFlashInconnue, IdTypeFlash ...) ;
TypeFlash(IdTypeFlash, ...) ;
Et j'aurai trois tables s'il y a plusieurs types de flash pour un phone.
Est-ce que c'est vrai ce que j'ai dit ?

==> non. Dans une base de données, il faut éviter les clés étrangères à valeur NULL (d'aucun applique cette règle plus largement...).

Donc, bien 3 tables :

• Phone(IdPhone, InfoFlashInconnue, ...) ==> InfoFlashInconnue : Booléen indiquant si l'information sur le flash est connue ;
• TypeFlash(IdTypeFlash, ...) ;
• Phone_TypeFlash(#IdPhone, #IdTypeFlash, ...) ==> la clé primaire est sur IdPhone, donc 1 seul type de flash. Le couple indique le type de flash d'un phone..

[insane_80]

Bonjour Richard_35;

Après avoir lu vos explications attentivement, il me semble que votre méthode est très logique.

Mais, pourquoi les ateliers de génie logiciel (comme PowerDesigner) ne donnent que deux tables après avoir généré le modèle physique à partir du MCD ? sachant que dans la cardinalité, il y a un 0 (dans 0,1) qui donne la possibilité d'avoir une clé étrangère à valeur NULL?

Cordialement.

[Richard_35]

Bonjour Insane_80,

Mais, pourquoi les ateliers de génie logiciel (comme PowerDesigner) ne donnent que deux tables après avoir généré le modèle physique à partir du MCD ?

==> excellente question !... personnellement, je préfère construire mes tables moi-même.

Comme je l'ai sous-entendu :

Dans une base de données, il faut éviter les clés étrangères à valeur NULL (d'aucun applique cette règle plus largement...).

la présence que l'on appelle le "bonhomme NULL" fait toujours couler beaucoup d'encre. Fais une recherche rapide sur ce forum... Personnellement, je mets la barre aux clés étrangères. Les champs de type "observation" ou "n° de rue" ne nécessite pas, pour moi, une table à part entière. Mais, ça se discute... toujours et encore.

Cet excellent billet de CinePhil balaye l'ensemble des cas possibles des cardinalités entre deux entités. A garder toujours sous la main !

[insane_80]

L'article que vous avez donné a été très important pour moi. Merci.

Il y a d'autres personnes qui proposent d'être pragmatique ! c-a-d, si nous avons très peu de ces valeurs nulles (de la clé étrangère) ET elles sont temporaires, alors dans ce cas, ils pensent qu'on doit sauter la table associative, car elle n'ajoute que la complexité au schéma.

[Richard_35]

Bonjour Insane_80,

Les bases de données gèrent mal les valeurs NULL, surtout quand il s'agit de clés étrangères. Parfois, les requêtes utilisant ces clés étrangères, parfois NULL, donnent des résultats surprenants...

La complexité du schéma ne doit pas rentrer en ligne de compte dans cette affaire : c'est l'intégrité de la base de données qu'il faut privilégier.

Donc, temporaires ou pas, ma préconisation est d'externaliser les entités concernées par les clés étrangères potentiellement NULL.

[insane_80]

Bonjour Richard_35,

Merci beaucoup pour toute information donnée. J'ai appris beaucoup des choses tout au long de cette discussion avec vous.

Donc, je vais essayer d'appliquer tout ce que vous avez dit dans vos conseils.

Cordialement.