Discussion :

[oneagaindoguys]

Bonjour, je suis en train de concevoir une base de données et je butte sur une dépendance fonctionnelle.

A l'utilisation, j'utilise des mots et expressions (stockés dans mes tables) qui ne sont pas exactement écrits de la même façon au masculin et au féminin. Je veux stocker les contenus de combobox dans des tables.

Prenons un cas concrèt, dans le formualire, j'ai une ligne "désir de travailler dans l'informatique". Dans la combobox si c'est un homme je vais avoir {Oui, Non, Indécis, Je n'y ai pas encore réfléchis} pour une femme {Oui, Non, IndécisE, Je n'y ai pas encore réfléchis}

Pour le moment mon schéma ressemble à ça :

Genre (id, libelle)
0, Homme
1, Femme

DésirInformatique (id, #genre, libelle) genre fait référence à Genre.id
0, 0, oui
1, 0, non
2, 0, indécis
3, 0, je n'y ai pas encore réfléchis
4, 1, oui
5, 1, non
6, 1, indécise
7, 1, je n'y ai pas encore réfléchis

j'ai une DF id->genre et naturellement id->libelle vu que id est CP

Ce qui ne me plait pas est que {oui, non, je n'y ai pas encore réfléchis revient 2 fois pour les 2} et je suis sur que je viole une règle de codd ou d'indépendance fonctionnelle

Comment puis-je adapter ma conception pour être plus cohérent ?

[fsmrel]

Bonjour,

je suis sur que je viole une règle de codd

Codd a fourni ses fameuses 12 règles (Twelve Rules) il y a 25 ans. Si vous êtes sûr d’en violer une c’est que vous les avez étudiées en profondeur, mais ces règles sont à destination des éditeurs de SGBD . Je vais donc supposer que vous avez plutôt en tête le thème de la normalisation.

Vous avez mis en évidence deux dépendances fonctionnelles non triviales (les accolades sont là pour mettre en évidence qu’une dépendance fonctionnelle met en jeu des ensembles et non pas des éléments d’ensembles) :

DF1 : {id} -> {genre}
DF2 : {id} -> {libelle}

Si vous savez montrer qu’il n’existe pas d’autres DF non triviales (ce qui n’est pas difficile), alors il vous reste à prouver que vous respectez la BCNF, voire la 5NF. En l’occurrence vous devriez y arriver sans problème.

[oneagaindoguys]

La table telle qu'elle est présentée semble assez peu cohérente.
Pour vérifier si elle est de 5NF il me faudrait un peu de temps pour me remémorer la chose. Je ne suis pas spécialiste base de données. Par contre, je ne vois pas trop en quoi cela réponds à ma question

Est-ce que cette solution est envisageable ? :

DésirInformatique (id, #genre, libelle) genre fait référence à Genre.id
0, null, oui
1, null, non
2, 0, indécis
3, null, je n'y ai pas encore réfléchis
4, 1, indécise

Ainsi, les valeurs qui s'adaptent aux hommes et aux femmes ne font pas référence à la table étrangère. Null sur un attribut étant clé étrangère est-il cohérent ?

[fsmrel]

De grâce, évitez le bonhomme Null...

Sinon, votre structure de la table DESIR est correcte et la table peut être produite ainsi :

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
 CREATE TABLE DESIR
(
        DESIR_ID INT          NOT NULL
      , GENRE    INT          NOT NULL
      , LIBELLE  VARCHAR(32)  NOT NULL
, CONSTRAINT DESIR_PK PRIMARY KEY (DESIR_ID)
, CONSTRAINT DESIR_AK UNIQUE (LIBELLE)
, CONSTRAINT DESIR_CHK1 CHECK (GENRE IN (1, 2, 3))
) ;
 
INSERT INTO DESIR VALUES (1, 3, 'oui') ;
INSERT INTO DESIR VALUES (2, 3, 'non') ;
INSERT INTO DESIR VALUES (3, 3, 'je n''y ai pas encore réfléchi') ;
INSERT INTO DESIR VALUES (4, 1, 'indécis') ;
INSERT INTO DESIR VALUES (5, 2, 'indécise') ;

Où GENRE est limité à prendre les valeurs 1 (masculin), 2 (féminin), 3 (indifférent).

{LIBELLE} est clé alternative.


Si à la place de la contrainte DESIR_CHK1 vous préférez faire référence à la table GENRE :

Code SQL :

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

1
2
3
4
5
6
7
8
9
 CREATE TABLE DESIR
(
        DESIR_ID INT          NOT NULL
      , GENRE    INT          NOT NULL
      , LIBELLE  VARCHAR(32)  NOT NULL
, CONSTRAINT DESIR_PK PRIMARY KEY (DESIR_ID)
, CONSTRAINT DESIR_AK UNIQUE (LIBELLE)
, CONSTRAINT DESIR_FK FOREIGN KEY (GENRE) REFERENCES GENRE (Id)
) ;

[oneagaindoguys]

Merci d'avoir répondu à mes questions.

Et c'est là que l'on arrive à une autre contrainte :

La table Genre est lue pour renseigner le contenu d'une autre combobox. Je devrai dans la requête spécifier que je ne veux pas mettre indiférent à la ligne "Vous êtes un(e) : "
De ce fait, je choisirai la seconde solution. De plus, MySQL ne connais pas la contrainte CHECK.

J'en profite pour vous poser une autre question :
Qu'en est-il sur les deux possibilités :

Code SQL :

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

1
2
3
4
5
6
7
 CREATE TABLE GENRE
(
        GENRE_ID INT          NOT NULL
      , LIBELLE  VARCHAR(32)  NOT NULL
, CONSTRAINT GENRE_PK PRIMARY KEY (GENRE_ID)
, CONSTRAINT GENRE_AK UNIQUE (LIBELLE)
) ;

et

Code sql :

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

1
2
3
4
5
 CREATE TABLE GENRE
(
      LIBELLE  VARCHAR(32) 
, CONSTRAINT GENRE_PK PRIMARY KEY (LIBELLE)
) ;

soit, faire une table avec une seule colonne clé primaire.
J'imagine que ça n'est pas correct mais faisable, tout comme la valeur NULL

[fsmrel]

Null n’est pas une valeur mais une marque. Null est hors-la-loi dans la théorie relationnelle (ou Modèle Relationnel de Données). Pour sa part, SQL n’est pas regardant mais a au moins la décence de vous interdire d’avoir des clés primaires dont les attributs sont marqués Null (Qu’est-ce qu’une clé non valorisée ?! Il y a là une contradiction au plan sémantique).

A propos de votre 2e solution :

Du point de vue de la théorie relationnelle cette solution est parfaitement légale et vous fait faire l’économie de l’attribut GENRE_ID. Mais, si la table GENRE est référencée par une autre table et si vous modifiez la teneur d’un libellé, vous devrez modifier toutes les références faites à ce libellé. Bref, la discipline, la contrainte habituelle est que les valeurs prises par les attributs composant les clés primaires doivent être invariantes et non significatives. Si vous ne respectez pas cette règle fort sage, CinePhil risque de venir vous tirer les oreilles.

Votre 1re solution est donc à privilégier (n’oubliez pas de prendre en compte la clé étrangère en relation avec la table GENRE).

En passant, ne pouvez-vous pas remplacer « indécis[e] » par quelque chose de neutre ? (« Je ne sais pas encore », « Peut-être », ...)

[oneagaindoguys]

Merci beaucoup fsmrel, vos réponses sont claires et précises. Merci de prendre votre temps pour me répondre.

Ces questions étaient par curiosité pour en savoir plus.

Pour ce qui est de changer le contenu de la donnée, ce n'était qu'un exemple parmi d'autre. Par exemple, j'ai la situation familiale (Séparé(e), divorcé(e), veuf(ve)). Et puis, j'ai soulevé un coté en base de données que je ne maitrisais pas. Je me coucherai moins bête ce soir

Merci encore

[fsmrel]

Bonne nuit !

[CinePhil]

Réflexion rapide sur le sujet car je vais bientôt partir pousser les billes sur 3 bandes...

Si vous tenez à stocker les libellés féminins, peut-être qu'une solution avec une table pour les libellés masculins (en fait masculins et unisexe) et une pour les libellés féminins pourrait convenir ?

Règle de gestion :
Un libellé peut avoir un féminin et un féminin est d'un seul libellé.

MCD :
libelle -0,1----avoir----(1,1)- feminin

Tables :
libelle (lbl_id, lbl_texte)
feminin (fmn_id_libelle, fmn_texte)

Quand vous avez un utilisateur féminin, vous récupérez les libellés féminins souhaités + les libellés unisexe qui ne sont pas associés à un libellé féminin.

[oneagaindoguys]

C'est la première idée qui m'est venue en tête, mais j'avais peur que ça devienne ingérable