Discussion :

[Drag]

Voici un exemple. Imaginons 2 tables, une avec des chiens, l'autre avec des chats. Chacun de ces animaux appartient obligatoirement à un (et un seul) regroupement existant d'animaux. Ensuite, imaginons que les femmes et les hommes peuvent posséder un (et un seul) regroupement d'animaux.

On pourrait imaginer, si on n'a pas peur de faire cliché:
Chat (id, nom, typeMoustache, idGroupeAnimal)
Chien (id, nom, typeOreille, idGroupeAnimal)
GroupeAnimal (id)
Femme (id, nom, clubFoot, idGroupeAnimal)
Homme (id, nom, clubFitness, idGroupeAnimal)

Si le groupeAnimal en tant que tel ne possède pas de nom, qu'il n'existe aucune information particulière liée, est-ce acceptable d'avoir une table qui ne contient qu'un id? Est-ce que ça implique forcément qu'il y a une erreur dans le raisonnement? Et si c'est le cas, est-il possible de dire où se trouve l'(horriblissime) erreur dans le schema?

Merci d'avance!

[SQLpro]

Pas du tout, c'est parfaitement normal. Il arrive souvent que l'on ait pas exemple une table de date ou de nombre dans une base du fait du modèle.

A +

[CinePhil]

Dans ton cas, tu as deux manières de faire :
1) La contrainte CHECK ou le type ENUM s'il existe dans ton SGBD.
Tu contrains la colonne idGroupeAnimal à certaines valeurs prédéfinies.

2) La table mono-colonne comme tu l'as définie avec une clé étrangère faisant référence à cette table.

[Drag]

Ok, merci pour vos réponses.

Ici, la table GroupeAnimal sert uniquement à créer un groupe hétéroclyte.
- La foreign key vers GroupeAnimal dans Chien ou Chat signifie "fait partie de ce groupe". (Ils ne peuvent faire partie que d'un et un seul groupe.)
- La foreign Key vers GroupeAnimal dans Homme ou Femme signifie "possède ce groupe". (Ils ne peuvent posséder qu'un et un seul groupe.)
Si vous me dites que c'est cohérent d'avoir une table pour représenter les groupes qui ne contient que l'id de ces groupe, et bien pourquoi pas! J'avoue que ça me semblait étrange de premier abord.

[sevyc64]

Mais rien ne t'empêche de rajouter ne serait-ce qu'une colonne Nom pour dire à quoi correspond ton ID, même si tu ne l'utilise pas dans le reste des données.

NE serait-ce que lorsque tu inspecte ta base lors de recherche de problème, tu n'aurait pas à te poser la question "A quoi correspond cet ID"

[Drag]

Effectivement... mais quoi comme nom?

Parfois, on aura un groupe de chiens et de chat, qu'on voudra assigner à un homme ou une femme.
On va donc créer le groupe, créer les chiens et les chats en leur assignant leur groupe, puis filer ce groupe à un homme ou une femme.
Mais au moment de créer le groupe, que pourrais-je lui donner comme nom? Si je me retrouve avec (id:1, name:'GroupeAnimal1'), je serai bien avancé.
Ce groupe est un concept assez abstrait, qui permet simplement aux hommes et aus femmes de pouvoir le posséder.

Je pourrais mettre le nom de l'homme ou de la femme qui possède le groupe pour info (ou le nom des animaux), mais ce serait une mauvaise idée: le lien homme/femme vers le groupe existe déjà, inutile de créer un lien bidirectionnel qui ne serait de toute façon pas "officiel".
A la limite, la date de création... mais ce sera la même que celle des chiens et des chats, vu que les groupes ne seront pas modifiés...
Bref, je ne vois pas...