Discussion :

[fabrice91]

Bonjour,

J'ai un petit souci de conception et un avis à vous demander.
J'ai une table T1 qui contient divers champs dont l'un est "sens_id" et qui contient l'id d'une autre table T2 (clé étrangère)
Cette table T2 contient un champ "sens" qui peut prendre les valeurs droite, gauche, haut, bas et rien (pas de sens) !
C'est ce "rien" qui me pose problème car le sens_id de T1 DOIT contenir une valeur et je ne veux pas mettre de NULL pour modéliser le RIEN car je devrais mettre le champ sens à NULL.
Et cela permettrait la possibilité d'insérer plusieurs NULL dans la table T2 ce que je ne veux pas !
Est-ce que je dois à la place de NULL insérer une chaine vide comme valeur pour "rien" de la table T2 et la traiter ensuite côté script ?
Ou bien une valeur texte "NULL" et la traiter côté script également ?

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE `T1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  ...
  ...
  ...
  `sens_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT FOREIGN KEY (sens_id) REFERENCES T2(id)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8 ;
 
CREATE TABLE `T2` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `SENS` varchar(10) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8 ;

Merci de vos avis.

[CinePhil]

Puisque vous avez une colonne SENS de type VARCHAR dans T2, vous pouvez très bien y enregistrer la valeur 'Rien' et donc utiliser l'identifiant de cette valeur en clé étrangère.

[CinePhil]

C'est d'ailleurs une caractéristique pratique des tables de référence de pouvoir considérer des choses d'apparence à possibilités limitées en ajoutant simplement une nouvelle possibilité qui n'était pas prévue au départ.

Exemple avec le sexe d'une personne. Intuitivement, on se dit qu'une colonne booléenne suffirait pour désigner, par exemple, 0 pour un homme et 1 pour une femme... jusqu'au jour où on a besoin d'enregistrer Dominique Durand et qu'on ne sait pas si c'est un ou une Dominique. Il vaut donc mieux avoir une table de référence pour le sexe avec la troisième possibilité 'inconnu'.

Dans votre cas, vous aurez peut-être besoin d'un jour d'ajouter 'haut-bas', 'haut-gauche', 'bas-droit' et 'bas-gauche' pour enregistrer des sens en diagonale.

[SQLpro]

C'est stupide de stocker quelques chose qui n'a pas de sens. Il suffit tout simplement de ne pas le stocker !
Autrement dit dans T1 : sens_id int(11) NULL

A +

[SQLpro]

C'est ce "rien" qui me pose problème car le sens_id de T1 DOIT contenir une valeur et je ne veux pas mettre de NULL pour modéliser le RIEN car je devrais mettre le champ sens à NULL.

Pourquoi cette position inepte ?

Et cela permettrait la possibilité d'insérer plusieurs NULL dans la table T2 ce que je ne veux pas !

Et alors ????

Je ne voit pas l'intérêt d'interdire les NULLs dans les FK. Ce serait plutôt l'inverse qu'il faudrait faire : le tolérer s'il à un sens !

A +

[CinePhil]

Je ne voit pas l'intérêt d'interdire les NULLs dans les FK. Ce serait plutôt l'inverse qu'il faudrait faire : le tolérer s'il à un sens !

fsmrel (j'espère qu'il va bien ; on ne le voit plus sur les forums ) ne serait pas d'accord avec toi ; il tire sur le bonhomme NULL à la sulfateuse !

Pour revenir au cas posé par fabrice91 malgré la non connaissance de la signification exacte de ce "SENS", un NULL ne donne aucune information. Peut-être qu'il serait intéressant pour lui, aujourd'hui ou demain, de savoir si l'absence de sens est due :
- au fait que le sens n'est pas encore déterminé ;
- au fait que le sens est déterminé mais l'information est manquante et inconnue de celui qui enregistre la donnée ;
- au fait que le sens est, en quelque sorte, une immobilité (le "rien" évoqué par Fabrice)...

Il vaut donc mieux, selon moi, enregistrer les différents cas possibles dans la table de référence et avoir la valeur correspondante dans la clé étrangère.

[Artemus24]

Salut fabrice91.

Cette table T2 contient un champ "sens" qui peut prendre les valeurs droite, gauche, haut, bas et rien (pas de sens) !

Cela ressemble beaucoup à des déplacements sur une feuille de papier.
La signification de ce "rien" pour être "aucun déplacement".
Est-ce bien de cette signification dont vous parlez ?

C'est ce "rien" qui me pose problème car le sens_id de T1 DOIT contenir une valeur et je ne veux pas mettre de NULL pour modéliser le RIEN car je devrais mettre le champ sens à NULL.

Le marqueur "NULL" signifie "absence de valeur".
Or votre "rien" à une signification, enfin, c'est comme cela que je l'ai compris.

Le "NULL" est un mot clef qui a une signification particulière.
Vous ne pouvez pas l'utiliser en tant que porteur de signification.

Redéfinissez votre colonne "sens" en lui attribuant d'une part une valeur et d'autre une signification à cette valeur.
Prenez par exemple un carré 3x3 avec les nombres suivants :

Code :

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

1
2
3
4
5
6
7
+---+---+---+
| 6 | 2 | 7 |
+---+---+---+
| 5 | 1 | 3 |
+---+---+---+
| 9 | 4 | 8 |
+---+---+---+

La case centrale de ce carré est là où vous vous trouvez, disons au déplacement précédent, sur votre feuille de papier.
Si maintenant vous saisissez "1", cela signifie que vous faites du surplace.
Maintenant, vous pouvez vous déplacer selon les quatre points cardinaux : Nord "2", Est "3", Sub "4" et Ouest "5".
Ou en oblique Nord"Ouest "6", Nord-Est "7", Sud-Est "8" et Sud-Ouest 9".

A partir ce cette convention, chaque déplacement à une valeur et une signification.
Si vous faites encore usage du marqueur "NULL", cela aura la sigification que vous n'avez pas encore enregistré le mouvement.

J'ai une table T1 qui contient divers champs dont l'un est "sens_id" et qui contient l'id d'une autre table T2 (clé étrangère)

Un identifiant est une clef qui va rendre unique votre ligne dans une table.
Si vous avez besoin de mettre en relation deux lignes de deux tables différentes, vous utilisez l'identifiant de l'une, comme clef étrangère de l'autre.
Je le répète, un identifiant est une clef et non une information.

Et cela permettrait la possibilité d'insérer plusieurs NULL dans la table T2 ce que je ne veux pas !

Je pense que vous n'avez pas compris ce qu'est une clef étrangère.
Identifiant, clef primaire, pointeur, adresse, sont des synonymes.
La colonne "sens" n'est rien de cela car c'est une information.
Pour identifier votre information, vous devez lui attribuer un identifiant.
Et c'est cet identifiant que vous devez mettre dans votre colonne "sens_id".

Code :

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

1
2
3
4
5
6
+------------------------+         +--------------------------+
|        Table T1        |         |         Table T2         |
+------------------------+         +--------------------------+
|   id  : clef primaire  |  <-|    |            ...           |
|  sens : information    |    |--  | id-sens : clef etrangère |
+------------------------+         +--------------------------+

Ainsi la clef étrangère "id-sens" de la table T2, va pointer sur l'identifiant "id" de la table "T1" où vous trouverez la colonne "sens porteur de l'information du déplacement que vous désirez effectué.

@+

[SQLpro]

fsmrel (j'espère qu'il va bien ; on ne le voit plus sur les forums ) ne serait pas d'accord avec toi ; il tire sur le bonhomme NULL à la sulfateuse !

Dans le MCD, pas dans le MPD !!!! Relit le et nous somme en phase à 100 %
Rien n'interdit une cardinalité 0,1 ou 0,n sur une patte associative...

Pour revenir au cas posé par fabrice91 malgré la non connaissance de la signification exacte de ce "SENS", un NULL ne donne aucune information. Peut-être qu'il serait intéressant pour lui, aujourd'hui ou demain, de savoir si l'absence de sens est due :
- au fait que le sens n'est pas encore déterminé ;
- au fait que le sens est déterminé mais l'information est manquante et inconnue de celui qui enregistre la donnée ;
- au fait que le sens est, en quelque sorte, une immobilité (le "rien" évoqué par Fabrice)...

La c'est tout à fait autre chose, et dans ce cas il faut donc ajouter une table "technique" pour indentifier la cause du NULL qui n'intéresse pas la sémantique des requpêtes...

Il vaut donc mieux, selon moi, enregistrer les différents cas possibles dans la table de référence et avoir la valeur correspondante dans la clé étrangère.

Absolument pas d'accord !!!!

Imagine que tu fasse des stats et présente un camembert... Que voudra dire cette entrée ?

C'est come le vote blanc ou nul, c'est sympa de le savoir mais cela n'a aucun poids dans le vote... Sinon quel serait le président représentant le nul majoritaire (bon, d'accord, on a eu François Hollande !!!!)


A +

[Artemus24]

Salut à tous.

Puisque vous avez une colonne SENS de type VARCHAR dans T2, vous pouvez très bien y enregistrer la valeur 'Rien' et donc utiliser l'identifiant de cette valeur en clé étrangère.

Je rejoins SQLPRO car ce que vous dites est une inneptie.
On ne stocke pas dans une base de données une ligne qui n'est porteur d'aucune information.
Autrement dit, une ligne contenant des NULL. Dans ce cas là, on ne crée pas la ligne.

C'est d'ailleurs une caractéristique pratique des tables de référence de pouvoir considérer des choses d'apparence à possibilités limitées en ajoutant simplement une nouvelle possibilité qui n'était pas prévue au départ.

C'est l'idée même d'une mauvaise conception d'une base de données. J'appelle cela du bricolage et la modélisation ne vous sert à rien !

C'est stupide de stocker quelques chose qui n'a pas de sens. Il suffit tout simplement de ne pas le stocker !

Je suis d'accord avec vous !

Je ne voie pas l'intérêt d'interdire les NULLs dans les FK.

Pris au pied de la lettre, je suis d'accord avec vous.

Mais le but d'une clef étrangère est de mettre en relation deux tables.
Pourquoi utiliser une clef étrangère si c'est pour y mettre "NULL" ???

Ce serait plutôt l'inverse qu'il faudrait faire : le tolérer s'il a un sens !

Je ne comprends pas trop ce que vous dites.
Un NULL n'est porteur d'aucun sens, sauf celui de l'absence de valeur.

fsmrel (j'espère qu'il va bien ; on ne le voit plus sur les forums ) ne serait pas d'accord avec toi ; il tire sur le bonhomme NULL à la sulfateuse !

Il est vrai que dans la plupart des cas, le NULL ne sert à rien du point de vue de la modélisation. L'introduire serait donc une erreur de conception et démontre que la modélisation est foireuse.
Je ne suis pas aussi catégorique que FSMREL sur ce point de vue. Disons que si nous pouvons nous en passer, alors nous devons le faire.

Dans le cas de fabrice91, le NULL ne signifie pas "absence de valeur", mais plutôt ne "rien" faire et donc est porteur d'une information.
Cela doit se traduire par une valeur comme je l'ai indiqué dans mon message précédent (sous la forme d'un carré 3x3).

Il vaut donc mieux, selon moi, enregistrer les différents cas possibles dans la table de référence et avoir la valeur correspondante dans la clé étrangère.

Pour enregistrer les différents cas possibles, il faudrait encore toutes les connaitre.
Il s'agit de la définition du périmètre des valeurs possibles que la colonne "sens" doit prendre.

Je pense que le problème de fabrice91 est dans sa méconnaissance de ce que représente une clef étrangère et sa confusion entre l'information "sens" et l'identifiant "id".

@+

[CinePhil]

Eh les gars ! Soit vous n'avez pas compris la problématique de Fabrice, soit je me suis mal exprimé dans mes réponses !

Revenons à la problématique...
Fabrice nous présente une table de référence des sens (T2) composée d'un identifiant auto-incrémenté et d'une colonne de type VARCHAR qui contient le libellé des sens.
Il nous présente aussi une table T1 qui contient une clé étrangère faisant référence à la table des sens.
Ce qui le chagrine est qu'il a dans T2 uniquement les sens Droite, Gauche, Haut et Bas et qu'il lui arrive d'avoir des lignes dans T1 qui n'ont pas de sens et il ne veut pas mettre de NULL dans la clé étrangère, ce qui est très compréhensible.

Je lui ai donc simplement suggéré d'ajouter dans sa table des sens une ligne avec le libellé 'Rien' ou 'À déterminer' ou 'Inconnu'... voir les trois si ces trois cas sont réalistes dans son contexte qu'il ne nous a pas décrit.
C'est quand même mieux d'avoir une clé étrangère référençant un "rien" explicite plutôt que d'avoir un NULL qui ne veut rien dire.

Cela ressemble beaucoup à des déplacements sur une feuille de papier.
La signification de ce "rien" pour être "aucun déplacement".
Est-ce bien de cette signification dont vous parlez ?

Le marqueur "NULL" signifie "absence de valeur".
Or votre "rien" à une signification, enfin, c'est comme cela que je l'ai compris.

Le "NULL" est un mot clef qui a une signification particulière.
Vous ne pouvez pas l'utiliser en tant que porteur de signification.

Redéfinissez votre colonne "sens" en lui attribuant d'une part une valeur et d'autre une signification à cette valeur.
Prenez par exemple un carré 3x3 avec les nombres suivants...

La case centrale de ce carré est là où vous vous trouvez, disons au déplacement précédent, sur votre feuille de papier.

Oui, ta solution peut aussi être pertinente.

Si vous faites encore usage du marqueur "NULL", cela aura la sigification que vous n'avez pas encore enregistré le mouvement.

Ça par contre, je trouve que c'est dommage. Qu'est-ce qui empêche d'avoir une valeur 0 ou 10 ou d'autres nombres qui signifierait clairement quelque chose au lieu d'un NULL qui peut laisser supposer tout et n'importe quoi ?

Je pense que vous n'avez pas compris ce qu'est une clef étrangère.

Au contraire, Fabrice semble avoir parfaitemetn compris ce qu'est une clé étrangère. Mieux, il a compris qu'une table remplie d'un certain nombre de NULLs dasn une clé étrangère, ce n'est pas terrible et plutôt à éviter.

Dans le MCD, pas dans le MPD !!!! Relit le et nous somme en phase à 100 %

Un NULL dans le MCD ? !!! Euh... comment dire ?
C'est bel et bien dans le MPD qu'il ne veut pas voir de colonne nullable et, par voie de conséquence, pas de NULL dans les tables.

Rien n'interdit une cardinalité 0,1 ou 0,n sur une patte associative

Et en quoi une cardinalité minimale de 0 évoquerait un NULL ?
À toi de me lire, j'ai justement listé les différentes cardinalités d'une association binaire et ce qu'il faut en faire sur les tables de la BDD.

La c'est tout à fait autre chose, et dans ce cas il faut donc ajouter une table "technique" pour indentifier la cause du NULL

Et bien c'est justement ce qu'à fait Fabrice avec sa table de référence des sens.

Imagine que tu fasse des stats et présente un camembert... Que voudra dire cette entrée ?

Et bien elle voudra bel et dire sa signification réelle (rien, à déterminer, à traiter, inconnu, sans objet...).

C'est come le vote blanc ou nul, c'est sympa de le savoir mais cela n'a aucun poids dans le vote...

C'est encore plus intéressant avec l'abstention dans le camembert : on constate que les présidents sont élus par une franche minorité d'électeurs !

Je rejoins SQLPRO car ce que vous dites est une inneptie.
On ne stocke pas dans une base de données une ligne qui n'est porteur d'aucune information.
Autrement dit, une ligne contenant des NULL. Dans ce cas là, on ne crée pas la ligne.

Et bien justement, tu abondes dans mon sens et non pas dans le sens de SQLPro !
Ma solution supprime les NULLs !

C'est l'idée même d'une mauvaise conception d'une base de données. J'appelle cela du bricolage et la modélisation ne vous sert à rien !

Non ce n'est pas du bricolage ! C'est donner une signification à un manque d'information au moment où on enregistre la ligne contenant la clé étrangère.
Ou alors on se retrouve dans le cas A -0,1----associer----0,n- B et on crée une table associative dans laquelle on n'enregistrera le B associé à A que lorsqu'on le connaîtra mais j'ai l'impression que ce n'est pas ce que voulait dire Fabrice. Je pense comme toi que ce "rien" veut dire ni droite, ni gauche, ni haut, ni bas. Ça peut être l'immobilité ou une autre signification mais il me semble que ce rien est une information signifiante, pas un NULL.

Dans le cas de fabrice91, le NULL ne signifie pas "absence de valeur", mais plutôt ne "rien" faire et donc est porteur d'une information.
Cela doit se traduire par une valeur comme je l'ai indiqué dans mon message précédent (sous la forme d'un carré 3x3).

Voilà ! C'est précisément ce que je dis depuis le début et ma solution permet tout à fait de préciser ce que représente ce rien.

[Artemus24]

Salut Cinephil.

Soit vous n'avez pas compris la problématique de Fabrice, soit je me suis mal exprimé dans mes réponses !

Les problèmes de communications et d'interprétations sont fréquents quand on chercher à donner des explications.
Il vaut mieux un petit exemple, qu'un long discours !

C'est quand même mieux d'avoir une clé étrangère référençant un "rien" explicite plutôt que d'avoir un NULL qui ne veut rien dire.

Sur ce point, je suis d'accord. Pas de NULL !

Mais ce que nous ne savons pas, c'est la signification de ce "rien" dans sa problématique.
J'ai interprété la colonne "sens" comme un déplacement (gauche, droite, haut, bas) et ce "rien" signifie faire du surplace, ou autrement dit, ne pas se déplacer.

Qu'est-ce qui empêche d'avoir une valeur 0 ou 10 ou d'autres nombres qui signifierait clairement quelque chose au lieu d'un NULL qui peut laisser supposer tout et n'importe quoi ?

Ce dont vous soulevez comme question, se nomme un ensemble de définition ou un périmètre.
Si, comme dans mon exemple, les mouvements sont caractérisés par une valeur allant de 1 à 9, je ne peux rien mettre d'autre que ces valeurs.
Comment traduire l'absence de valeur ? Et bien par un "NULL" puisqu'il joue ce rôle là !

Au contraire, Fabrice semble avoir parfaitement compris ce qu'est une clé étrangère.

Pas du tout, en voilà la preuve :

J'ai une table T1 qui contient divers champs dont l'un est "sens_id" et qui contient l'id d'une autre table T2 (clé étrangère)

La table mère est la table T2 alors qu'il la désigne comme étant celle contenant la clef étrangère.
La clef étrangère se trouve dans la table fille et pointe toujours vers la table mère.

Un NULL dans le MCD ? !!! Euh... comment dire ?

La notion de NULL n'existe pas dans la modélisation selon Merise !!!
C'est une représentation physique de l'absence de valeur dans une base de données.

Ou bien SQLPRO dit n'importe quoi, ou bien je n'ai pas compris ce qu'il a voulu dire !

Et en quoi une cardinalité minimale de 0 évoquerait un NULL ?

Une cardinalité 0 va se traduire par l'absence de ligne. Quel est le rapport avec le NULL ?
Ce que nous raconte SQLPRO, c'est encore du grand n'importe quoi !

==> Quand faut-il une table associative ?
Quand une table fille va faire référence à plusieurs tables mère, et que les tables mères sont dépendantes entre elles, on utilise alors une table associative.
Autrement dit, quand la cardinalité est partielle.
Dans le cas contraire, on utilise la relation hiérarchique table fille vers table mère.

Et bien c'est justement ce qu'à fait Fabrice avec sa table de référence des sens.

Non, ce n'est pas nécessaire car c'est un problème de périmètre et non un problème de cardinalité.

Ma solution supprime les NULLs !

On ne sait pas bien compris sur ce point là.

Je résume l'opinion de Fabrice91 telle que je l'ai compris :

1) Fabrice91 ne veut pas créer une ligne dans la table mère pour représenter ce qu'il appelle "rien".
Dans ce cas là, la clef étrangère de la table fille devra contenir un NULL pour exprimer ce "rien".
Il n'y a rien d'illogique de procéder ainsi.

2) Fabrice veut créer une ligne dans la table mère dont elle sera porteur de ce qu'il appelle "rien".
Dans cet autre cas, la clef étrangère devra pointer sur la table mère sachant que la ligne en question est ce "rien".
La aussi, il n'y a rien d'illogique dans cette approche. Et l'on ne faut pas usage du NULL dans la clef étrangère.

Ou se trouve alors le problème ? Dans cette phrase :

C'est ce "rien" qui me pose problème car le sens_id de T1 DOIT contenir une valeur et je ne veux pas mettre de NULL

Je comprends que la colonne "sens_id" est aussi utilisé comme clef primaire, dont son impossibilité d'y mettre un NULL.

La solution est alors double :

a) il n'utilise plus la colonne "sens-id" comme clef primaire, mais met autre chose.

b) soit il utilise la solution 2).

Nous nous sommes focalisé sur le NULL et non sur la colonne "sens_id" qui était aussi utilisé comme clef primaire.

Est-ce un peu plus clair maintenant ?

@+

[SQLpro]

...
C'est bel et bien dans le MPD qu'il ne veut pas voir de colonne nullable et, par voie de conséquence, pas de NULL dans les tables.
....

Regarde ce MCD et tu verras que les associations "defaut" pour les tel (fixe et fax) et mail se traduiront en clef étrangères dans la table personne avec du NULL... !

A +

[CinePhil]

Ce dont vous soulevez comme question, se nomme un ensemble de définition ou un périmètre.
Si, comme dans mon exemple, les mouvements sont caractérisés par une valeur allant de 1 à 9, je ne peux rien mettre d'autre que ces valeurs.
Comment traduire l'absence de valeur ? Et bien par un "NULL" puisqu'il joue ce rôle là !

Sauf que le NULL peut vouloir dire n'importe quoi.
Pourquoi ne pas ajouter à la table des sens des valeurs qui signifient les différents "NULL" possibles pour les clés étrangères et donc se débarrasser de ces NULL embêtants ?

J'avais donné l'exemple des sexes plus haut : normalement, c'est Homme ou Femme. Sauf que dans certains cas, ça peut aussi être "inconnu". Donc il suffit d'ajouter une table de référence des sexes à trois valeurs : Homme, Femme et Inconnu.

On pourrait avoir aussi, dans une base de données scientifique : Végétal, Minéral, Animal, À déterminer, Inconnu.

J'ai une table T1 qui contient divers champs dont l'un est "sens_id" et qui contient l'id d'une autre table T2 (clé étrangère)

La table mère est la table T2 alors qu'il la désigne comme étant celle contenant la clef étrangère.
La clef étrangère se trouve dans la table fille et pointe toujours vers la table mère.

D'abord, ce ne sont pas des tables mère et fille ; nous ne sommes pas ici dans le cadre d'un héritage mais d'une simple association entre quelque chose (T1) et une table de référence (T2) qui stocke la valeur signifiante d'une propriété de T1 dans laquelle cette valeur est exprimée par l'identifiant de la valeur, sous-forme de clé étrangère référençant T2. Sa phrase est peut-être mal tournée en plaçant le terme clé étrangère à la fin mais il a très bien compris l'usage d'une clé étrangère puisqu'il l'a correctement mise en oeuvre.

Quand une table fille va faire référence à plusieurs tables mère, et que les tables mères sont dépendantes entre elles, on utilise alors une table associative.
Autrement dit, quand la cardinalité est partielle.
Dans le cas contraire, on utilise la relation hiérarchique table fille vers table mère.

Euh... pas compris là !
Tu mélanges des notions de table mère et fille que je n'utilise que pour les héritages de données avec de simples associations entre tables.
Je donnais juste le lien vers mon billet de blog "Quand faut-il une table associative ?"

e résume l'opinion de Fabrice91 telle que je l'ai compris :

1) Fabrice91 ne veut pas créer une ligne dans la table mère pour représenter ce qu'il appelle "rien".
Dans ce cas là, la clef étrangère de la table fille devra contenir un NULL pour exprimer ce "rien".
Il n'y a rien d'illogique de procéder ainsi.

Je n'ai pas compris ça. Il semble juste être embêté à l'idée de mettre un pointeur NULL dans la clé étrangère référençant la table des sens parce qu'il n'a pas eu l'idée que sa table des sens pouvait non seulement contenir tous les sens possibles mais aussi une ligne (donc un identifiant utilisé en valeur de clé étrangère) pour ce "rien".

La solution la plus simple est donc qu'il ajoute cette ligne dans la table de référence des sens.

Ou se trouve alors le problème ? Dans cette phrase :

C'est ce "rien" qui me pose problème car le sens_id de T1 DOIT contenir une valeur et je ne veux pas mettre de NULL

Je comprends que la colonne "sens_id" est aussi utilisé comme clef primaire

Où as-tu lu ça ?

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE `T1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  ...
  ...
  ...
  `sens_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT FOREIGN KEY (sens_id) REFERENCES T2(id)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8 ;

=> La clé primaire est id et id_sens est seulement une clé étrangère.

[CinePhil]

Regarde ce MCD et tu verras que les associations "defaut" pour les tel (fixe et fax) et mail se traduiront en clef étrangères dans la table personne avec du NULL... !

A +

Quel MCD ?

Si cela veut dire qu'il y a une entité-type T_E_PERSONNE_PRS avec une propriété PRS_TEL_FIXE et une autre PRS_FAX, je dirais que ce n'est peut-être pas très bien modélisé !

Il vaut mieux externaliser les différents numéros de téléphone.
Si c'est une personne physique, elle peut (ou pas) avoir un tel fixe, un tel mobile, tant privés que professionnels.
Si c'est une personne morale, elle peut avoir (ou pas) plusieurs tel fixes (accueil, service achats, service facturation, service livraison...), plusieurs fax (pour les mêmes services, pourquoi pas ?)...

Donc, par exemple, on peut faire le MCD suivant :
personne -0,n----avoir----1,1- telephone -1,1----typer----0,n- type_telephone

Et là il n'y aura pas de NULL en clé étrangère, seulement les lignes nécessaires selon les personnes.

[Artemus24]

Salut CinePhil.

Sauf que le NULL peut vouloir dire n'importe quoi.

Pas du tout ! Il a une et une seule signification, celle de l'absence de valeur.
Et comme beaucoup de débutants ne le comprennent pas, l'absence de valeur n'est pas une valeur !

Pourquoi ne pas ajouter à la table des sens des valeurs qui signifient les différents "NULL" possibles pour les clés étrangères et donc se débarrasser de ces NULL embêtants ?

Cela revient à changer l'ensemble de définition.

Soit deux choses l'une, ou bien l'ensemble de définition est incomplet ou bien il y a un problème dans sa modélisation. Je miserai plutôt sur un problème de modélisation.

J'avais donné l'exemple des sexes plus haut : normalement, c'est Homme ou Femme.

Et donc, quel est l'ensemble de définition de la colonne "sexe" ?
--> 'H' pour homme.
--> 'F' pour femme.
--> NULL quand on ne sait pas quoi mettre, en attente d'une réponse qui sera normalement soit 'H' ou soit 'F'.
Et c'est tout !

Sauf que dans certains cas, ça peut aussi être "inconnu".

Mais que signifie alors "inconnu" ?
--> en attente d'une réponse qui sera soit 'H' ou soit 'F'.
--> ou bien vous traitez un troisième cas qui est ni 'H' ni 'F'.

Donc il suffit d'ajouter une table de référence des sexes à trois valeurs : Homme, Femme et Inconnu.

Je ne savais pas que le genre avoit trois valeurs possibles ???

D'abord, ce ne sont pas des tables mère et fille ; nous ne sommes pas ici dans le cadre d'un héritage

Mais qui parle d'héritage ? Pas moi. Les termes mère et fille ne sont pas exclusivement réservés à l'héritage.

Je parle d'une relation de type hirarchique entre une table mère et une table fille, qui se fait par l'intermédiaire d'une clef étrangère présente dans la table fille et qui pointe sur une ligne de la table mère.

mais d'une simple association entre quelque chose (T1) et une table de référence (T2)

Ce n'est pas une association mais une relation avec deux contraintes, l'une étant une clef primaire, l'autre étant son unicité.
--> https://fr.wikipedia.org/wiki/Cl%C3%...9trang%C3%A8re

Euh... pas compris là !

Quand vous avez deux parents dont l'un est le père et l'autre la mère, d'un même enfant, il y dépendance entre les parents. Pourquoi ?
Parce que ce père et cette mère ne sont pas n'importe qui mais les géniteurs de cet enfant.
Dans ce cas là, on fait une table associative afin de répondre à cette dépendance.

Si maintenant vous vous dites que n'importe qui peut-être le père et n'importe qui peut être la mère, dans ce cas là, on utilise une relation hiérarchique par l'intermédiaire de la clef primaire.
Pourquoi ? Car il n'y a aucune dépendance entre n'importe quel père et n'importe quelle mère.

C'est pourtant simple à comprendre. La table associative concerne, entre autre, la dépendance !

Je n'ai pas compris ça.

Enfin de compte, vous n'avez pas compris le problème de Fabrice91.

Il semble juste être embêté à l'idée de mettre un pointeur NULL dans la clé étrangère

Pas du tout ! Son problème est qu'il ne peut pas mettre un NULL dans la clef étrangère car cette clef étrangère sert aussi de clef primaire !!!
Il ne s'agit pas d'une question de volonté mais une question d'impossibilité !

Où as-tu lu ça ?

Dans son premier message à la quatrième phrase. Je mets la phrase en entier :

C'est ce "rien" qui me pose problème car le sens_id de T1 DOIT contenir une valeur et je ne veux pas mettre de NULL pour modéliser le RIEN car je devrais mettre le champ sens à NULL.

Il précise bien qu'il ne peut pas mettre de NULL dans la colonne "sens_id". Pourquoi ? Parce qu'il l'utilise aussi comme clef primaire. C'est la seule explication possible à cette impossibilité.
Si vous en trouvé une autre, je suis preneur.

Et donc il se demande s'il ne doit pas créer une nouvelle ligne avec la colonne "sens " à NULL pour signifier ce "rien" dont-il parle.

Je réponds à cela en disant : Il ne peut pas mettre à la fois, un NULL dans la colonne "sens_id" pour signifier "rien" et utiliser cette colonne aussi en tant que clef primaire.
Il doit faire un choix !

1) soit il doit respecter son ensemble de définition, et dans ce cas là, il ne doit pas mettre la colonne "sens_id" en tant que clef primaire dans sa table.

2) soit il laisse la colonne "sens_id" en tant que clef primaire mais dans ce cas là, il doit modifier son ensemble de définition. Pourquoi ?
Afin de placer une valeur dans la colonne "sens_id" et cette valeur va pointer sur la colonne "id" qui aura "sens" = "rien".

Cette solution est aussi la votre CinePhil. Elle n'est en rien une erreur.
Mais quand on crée une base de donnée, on doit scupuleusement respecter la modélisation, et entre autre les ensembles de définition de chaque colonne, sinon c'est le bordel !

@+

[CinePhil]

Pas du tout ! Son problème est qu'il ne peut pas mettre un NULL dans la clef étrangère car cette clef étrangère sert aussi de clef primaire !!!
Il précise bien qu'il ne peut pas mettre de NULL dans la colonne "sens_id". Pourquoi ? Parce qu'il l'utilise aussi comme clef primaire. C'est la seule explication possible à cette impossibilité.
Si vous en trouvé une autre, je suis preneur.

FAUX !
Encore une fois : Relire la définition de sa table :

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE `T1` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  ...
  ...
  ...
  `sens_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  CONSTRAINT FOREIGN KEY (sens_id) REFERENCES T2(id)
) ENGINE=InnoDB DEFAULT CHARSET=UTF8 ;

=> PRIMARY KEY (`id`)C'est pourtant clair, non ?

J'arrête là cette discussion stérile ; on a perdu fabrice en route qui n'a pus répondu à nos tergiversations.

[escartefigue]

Bonjour,

Dans l'absolu il y a 5 types déplacements possibles: vers la droite, le haut, la gauche, le bas et enfin aucun déplacement
Aucun déplacement est une valeur : je sais et donc j'enregistre l'information selon laquelle il n'y a pas eu de déplacement

Ce n'est pas la même chose que de ne pas savoir si mon entité s'est déplacée

Ce qui est donc structurant ici, c'est d'avoir la règle de gestion précise : sait on toujours ou pas s'il y a eu déplacement ?
Si oui (cardinalité mini un), pas de FK nullable , si non (cardinalité mini zéro) la FK doit être nullable

@fabrice91 : quand vous dites "...et cela permettrait la possibilité d'insérer plusieurs NULL dans la table T2 ce que je ne veux pas ! ", vous vous trompez, la table où une colonne est PK n'a par définition jamais de PK nulle ! Qui dit PK dit "not null" C'est la FK dans la table issue de l'entité que j'ai appellée "ENTITE1" qui peut être nullable, ne surtout pas confondre