Discussion :

[Drag]

Bonjour,

J'ai posé pas mal de questions ces derniers jours... et j'en ai une de plus! Ca devrait se calmer après ça...

Voici un exemple de table:
Chat(id, nom, typePelage, detailPelage)

Considérons que "typePelage" peut valoir soit "poil", soit "peau".
Si "typePelage" vaut "poil" -> "detailPelage" peut valoir soit "blanc", soit "noir".
Si "TypePelage" vaut "peau" -> "detailPelage" peut valoir soit "lisse", soit "frippé".

Je me demande comment gérer ça, et quelle serait la meilleure approche. Exemples:
1) Limiter simplement "typePelage" à "poil" ou "peau", et "detailPelage" à "blanc", noir", "frippé" ou "lisse". C'est donc le programme qui devra s'assurer que les données sont cohérentes, car rien n'empêche d'introduire dans la DB le couple erroné "peau / blanc".
2) Créer simplement un trigger pour insert et update, qui s'assure que les règles sont bien respectées entre "detailPelage" et "typePelage".
3) Remplacer "chat" par deux tables "chatPoilu" et "ChatChauve", pour lesquelles on pourra définir clairement les valeurs possibles pour "typePelage" et "detailPelage"...

Le problème avec la troisième solution, c'est qu'on en arriverait à faire deux SELECT pour pouvoir récupérer tous les chats (ou alors il y a une solution à laquelle je n'ai pas pensé), ce que je préfèrerais éviter.

Note: j'ai tout représenté ici dans une seule table pour faire simple. Il y aurait effectivement moyen de mettre en place une table "detailPelage" et "typePelage"... mais la problématique serait même: l'ai l'impression que si on ne met pas les détails du pelage dans la même table, on en arrive à dupliquer les select si on désire obtenir tous les chats avec le détail de leur pelage... Et si on met tous les chats dans une même table avec l'information concernant leur pelage, on prend le risque d'avoir des données incohérentes (à part avec un trigger qui vérifie les données, ce que j'aurais également préféré éviter).


Je suppose qu'il s'agit là d'un cas assez classique?

Merci d'avance!

[sevyc64]

Les solutions 1 et 2 pourquoi pas.

Peut-être aussi une autre solution

Créer une table TypePelage et une autre table DetailPelage. Celle-ci serait reliée par clé étrangère à TypePelage.

Dans ta table Chat tu aurais donc une clé étrangère sur TypePelage et une autre sur DetailPelage
Par contre, là, c'est un point que je ne maitrise pas, mais il est peut-être possible de dire que le détail pelage ne peut être que parmis ceux qui ont le type pelage déjà donné comme clé étrangère

Je suis pas sur d'être très clair

[f-leb]

bonsoir,

pourquoi pas la solution 3) avec un héritage:

Chat(idChat, NomChat)

ChatPoilu(#idChat, #idTypePoil) raccordée à TypePoil(idTypePoil, NomTypePoil)

ChatChauve(#idChat, #idTypePeau) raccordée à TypePeau(idTypePeau, NomTypePeau)

et une contrainte de partition a programmer (un chat est soit un chat poilu, soit un chat chauve)

sympa l'exemple avec ces chats

[Drag]

Merci à vous pour les idées, c'est toujours bienvenu. J'ai l'impression que tout cela pourrait fonctionner… mais j'ai du mal à effectuer et justifier un choix.

sevyc64> Effectivement, on peut créer des tables DetailPelage et TypePelage, mais ça ne nous permet pas de s'assurer facilement que le detail correspondra bien au type…

f-leb> En faisant une séparation comme proposé, il n'est pas possible (j'ai l'impression) de récupérer tous les chats et leur type de peau en un seul select, sauf en utilisant un UNION. (Mais bon, ce n'est pas bien grave…)
A noter que dans mon usine de manteau en peau de chat que je vais bientôt ouvrir, où je ne recevrai que des chats adultes, je pense que je ne prendrai même pas la peine d'enregistrer leu nom. Ce qui fait que la table "Chat" ne possèderait qu'un id, ce qui me est moyen…

Sinon, une autre possibilité en mixant un peu tout:

Chat (id, #typePelageId, #detailPelageId)
TypePelage (id, typePelageName, typeChat)
DetailPelage (id, detailPelageName, typeChat)

typeChat ne pouvant valoir que "ChatPoilu" ou "ChatChauve"

Ainsi, je peux faire directement un select de tous les chats et de leur type de peau sur ma table "Chat".
Et si on veut s'assurer que le couple "typePelage / detailPelage" est bien cohérent pour un chat, on peut mettre en place un trigger "générique" propre et simple sans aucune valeur hardcodée, qui vérifie simplement que "typeChat" est identique pour le couple typePelage et detailPelage utilisés dans Chat.

Mais bon, je ne suis pas sûr de la solution qui me plait le plus entre toutes.

[f-leb]

pourquoi pas la solution 3) avec un héritage:

Chat(idChat, NomChat)

ChatPoilu(#idChat, #idTypePoil) raccordée à TypePoil(idTypePoil, NomTypePoil)

ChatChauve(#idChat, #idTypePeau) raccordée à TypePeau(idTypePeau, NomTypePeau)

et une contrainte de partition a programmer (un chat est soit un chat poilu, soit un chat chauve)

s'il n'y a que deux types de chat, c'est probablement la solution que je conserverais (tu retires NomChat si tu veux et tu profites de cette merveilleuse possibilité offerte par ton SGBD de créer une "vue" (CREATE VIEW avec un UNION) qui te fera oublier que tout ce pt'it monde est dans deux tables différentes).

Sur un plan sémantique, cette modélisation permet d'appeler les choses par leurs vrais noms (on appelle un chat un chat) avec des ChatChauve qui ont des TypePeau et des ChatPoilu avec des TypePoil... C'est quand même plus parlant que des Chat avec des TypePelage et des détailPelage.

si tu veux tailler des manteaux de fourrure avec des chats, tu peux associer tes manteaux avec les chats poilus:

ChatPoilu---0,n---tailler---1,n----ManteauFourrure

avec ta solution, il va falloir encore vérifier que tu ne taille pas des manteaux de fourrure avec des chats chauves.

Je sens qu'on va avoir des ennuis avec cette histoire de manteaux en peau de chats

[Drag]

C'est fou, mais je n'avais pas encore pris en compte la possibilité d'utiliser des VIEW... J'aurais plutôt tendance à les mettre en place après avoir défini un schéma qui me plait en lui-même, lorsqu'il y a des besoins de sélection (ou de restriction) spécifiques.
Bon, ben je vais encore repenser à tout ça calmement... merci encore pour le coup de main!

PS: des vestes en cuir avec les chauves?

[vmolines]

Une dernière idée de modélisation :

Proposer des attributs typés et permettre de définir des compatibilités/incompatibilités entre ces types d'attributs. Pas très clair donc je donne une structure :

CHAT (IDCHAT, NOMCHAT)
TYPEATTRIBBUT (IDTYPEATTRIBBUT, DESIGNATION)
ATTRIBUT (IDATTRIBUT, #IDTYPEATTRIBBUT, DESIGNATION)
ATTRIBUTCHAT (#IDCHAT, #IDATTRIBUT

Et une table qui permettrait d'interdire (ou autoriser selon le sens le plus pratique pour vous) d'affecter un attribut d'un certain type si un attribut d'un autre type a été affecté pour un même chat. Un exemple :

J'ai :

- un type d'attribut "pelage" avec des attributs "poil", "peau"
- un type d'attribut "couleur poil" avec des attributs "blanc", "noir", ...
- un type d'attribut "type peau" avec des attributs ...
- une exlusion entre l'attribut "pelage:poil" et le type d'attribut "type peau"

C'est une proposition à affiner mais l'idée est quelquechose de souple pour "multi qualifier" le chat avec un ensemble d'attributs typés qui permettent de définir des règles pour ne pas faire cohabiter n'importe quels attributs ou types d'attributs.

Cela permet de ne pas toucher au modèle mais de pouvoir définir des règles de manière plus souple. Le requêtage est aussi simplifié.

[Drag]

Comme souvent, cette question revient: "Est-on sûr et certain qu'un modèle en particulier est complet, où est-ce que c'est amené à évoluer par la suite?"
D'un côté, on prend le risque de se retrouver coincé si le modèle doit évoluer dans une direction qu'on n'avait pas prévue. De l'autre, on risque de se retrouver à modéliser l'univers si on ne sait pas s'arrêter.


(J'avoue aussi que je réponds ça parce que je n'ai pas encore pris la peine de voir si ce dernier modèle conviendrait. J'avoue que de premier abord, devoir gérer les exclusions me dérange un peu. Si je dois le faire, je préfèrerais que toute l'info se trouve dans la DB, plutôt que de devoir "hardcoder" des valeurs...)

[vmolines]

On est tous d'accord en ce qui concerne l'équilibre de la juste modélisation.

Les éventuelles règles (exclusion ou autre système) sont bien sûr en BDD. Je n'ai pas mis la description volontairement car cette partie est à affiner.

Je vous laisse éprouver ce modèle mais il me semble que c'est assez approprié.

[f-leb]

en fait, la question est:

Comment exprimer que des caractéristiques ne puissent être pertinentes que pour certaines occurences d'une entité ?

il suffit d'adapter les solutions (solutions 2° et 3°) avec ces matériels et types de matériels, avec vos chats et types de chats...

[vmolines]

Ma solution reposait sur un méta modèle avec une notion de règles pour avoir plusieurs propriétés cohérentes entre elles (si besoin evidemment).