Relation à l'envers : c'est moi qui suis limité, ou l'auteur qui est cinglé ?

Version imprimable

Bonjour,

Je viens vers vous, car je travaille sur un outil qui me laisse de plus en plus perplexe.

Il s'agit d'un logiciel éditeur. J'essaie de mettre en place certaines fonctionnalités, non sans mal, et j'ai vraiment du mal avec certains choix des développeurs.

Vu que je ne peux me résoudre à admettre qu'ils sont complètement 3 lettres (enfin, 4 au pluriel) je me dis que c'est peut-être moi qui ai raté un wagon... Dénormalisation ?

Voici l'exemple qui m'afflige le plus.

J'ai une entité "produit".
Une autre entité "texte".

Bon, déjà, c'est un peu bancal, car "texte" contient des traduction d'un peu tout et n'importe quoi, avec différentes méthodes pour faire les relations... selon les entités avec lesquelles elle est liée.

Au niveau table, voici les colonnes :

PRODUIT
----------
ID (PK)
NOM (langue de base)
TEXTE_ID => FK vers TEXTE (ID2)

TEXTE
-------
ID (PK)
LANGUE_ID (PK)
ID2 FK vers TEXTE (ID)
TRADUCTION

Evidement, les FK sont purement logiques, niveau base de données, elles n'existent pas (et ne pourraient de toute façon pas, puisque ni TEXTE.ID ni TEXTE.ID2 ne sont uniques et encore moins PK).

Et niveau données ce que ça donne, par exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Produit : ID NOM TEXTE_ID 1 Voiture 1 2 Bateau 3 3 Avion 4 Texte : ID LANGUE_ID ID2 TRADUCTION 1 1 1 Voiture 2 2 1 Car 3 2 3 Boat 4 1 4 Avion 5 1 3 Navire 6 2 4 Avion
Explication.

Lorsqu'on crée un produit, aucune traduction n'est créée. Le "TEXTE_ID" reste à NULL. (déjà, nawak niveau 1FN)
Ensuite, lorsqu'on crée la première traduction, QUELLE QUE SOIT LA LANGUE, TEXTE.ID prend la prochaine valeur du compteur de la table, et TEXTE.ID2 prend la même valeur. PRODUIT.TEXTE_ID prend alors la même valeur que TEXTE.ID2

Ensuite, lors des traductions suivantes, pour le même article, TEXTE.ID prend les valeurs suivantes du compteur de la table, et TEXTE.ID2 prend comme valeur PRODUIT.TEXTE_ID

D'un point de vue performance (index) j'imagine comprendre, partiellement, le voeux du développeur... Un index sur TEXTE.ID2 permet de retrouver les textes associés à un produit en une simple lecture d'index.

Ok...

Mais pourquoi ne pas avoir fait :

PRODUIT
----------
ID (PK)
NOM (langue de base)

TEXTE
-------
ID (PK)
LANGUE_ID (PK)
ENTITE_NOM
ENTITE_ID (FK logique)
TRADUCTION

Ainsi :
ENTITE_NOM contiendrait "PRODUIT" pour les traductions d'articles.
Et ENTITE_ID contiendrait l'ID du produit traduit.
Et un bête index unique sur ENTITE_NOM, ENTITE_ID, LANGUE_ID permettait de faire la même chose, avec un modèle, à défaut d'être parfaitement 1FN, non seulement plus lisible (pas de recopie d'ID dans tous les sens, d'auto-jointures, etc.) mais surtout plus intuitif, et très certainement plus performant.

Ou si j'ai raté un truc ?

07/01/2015, 09h54
CinePhil

Citation:

Mais pourquoi ne pas avoir fait :

PRODUIT
----------
ID (PK)
NOM (langue de base)

TEXTE
-------
ID (PK)
LANGUE_ID (PK)
ENTITE_NOM
ENTITE_ID (FK logique)
TRADUCTION

Ça voudrait dire que l'entité-type TEXTE pourrait être associée pour certaines lignes à PRODUIT, pour d'autres à une autre entité-type... Ce qui n'est pas du tout bon puisque, alors, la clé étrangère ENTITE_ID ne pourrait pas en être une puisqu'elle référencerait plusieurs tables.

Citation:

Au niveau table, voici les colonnes :

PRODUIT
----------
ID (PK)
NOM (langue de base)
TEXTE_ID => FK vers TEXTE (ID2)

TEXTE
-------
ID (PK)
LANGUE_ID (PK)
ID2 FK vers TEXTE (ID)
TRADUCTION

J'en déduis donc le MCD suivant :

LANGUE -0,n----concerner----1,1----|
traduire----------------------------1,n- TEXTE -1,n----associer----1,1- PRODUIT
|--------------------------------------1,1-------|

C'est effectivement biscornu !
Il eut été plus simple de faire ce MCD :
LANGUE -0,n----concerner----1,1- TEXTE -1,1----traduire----0,n- PRODUIT
07/01/2015, 10h24
StringBuilder

Pour le premier point, c'est effectivement pour ça que je parle de "FK logique", c'est à dire impossible à modéliser côté SQL, mais éventuellement des contraintes par trigger, ou dans le code de l'application.

Disons que ma suggestion n'est pas de réécrire toute l'application, mais la solution qui m'aurait paru évidente avec leur modèle actuel (la table TEXTE est bien "liée" potentiellement à toutes les tables, parfois sous cette forme, parfois avec d'autres méthodes encore plus biscornues, que je n'ai toujours pas réussi à comprendre (opération du saint d'esprit ?).

Et pour le second point, c'est effectivement à cette conclusion que j'arrive. Du coup, je me demande s'il y a une raison technique/sémantique/logique/jenesaisquoiique à la solution qu'ils ont adopté, ou s'ils ont simplement laissé un stagiaire autiste trisomique faire le MCD ?
07/01/2015, 10h40
CinePhil

Citation:

Du coup, je me demande s'il y a une raison technique/sémantique/logique/jenesaisquoiique à la solution qu'ils ont adopté, ou s'ils ont simplement laissé un stagiaire autiste trisomique faire le MCD ?

Je pencherais pour le stagiaire trisomique ! :aie:

Je n'ai pas encore trouvé une seule application, parmi celles que j'utilise professionnellement, qui ait un modèle de données normalisé. La plupart ont même des modèles de données pourris. Il nous faut malheureusement souvent faire avec.

Mais reconnaissons aussi que ce n'est pas toujours évident, surtout quand une application évolue et qu'on ne peut pas remettre en cause tout le modèle de données existant.
Même pour une application nouvelle, il faut parfois avoir un degré d'abstraction supplémentaire. J'ai développé une application de paiement en ligne qui utilise Paybox. La première utilisation est pour un domaine précis - le paiement des frais de scolarité - mais mon chef m'a demandé d'imaginer qu'on pourrait aussi utiliser la partie paiement en ligne pour d'autres choses dans le futur, telle qu'une inscription à un colloque organisé par l'école par exemple. J'ai donc modélisé séparément la partie transaction financière Paybox et la partie échéance de paiement des frais de scolarité avec une association (et donc une table associative) entre les deux parties du modèle. Lorsque nous développerons l'application des colloques, il suffira de modéliser seulement la partie colloque et de l'associer à la partie transaction financière qui n'aura pas besoin de modification.
Et même là, si j'avais voulu être vraiment clean, j'aurais fait un schéma de BDD pour les transactions et un autre pour les frais de scolarité alors que pour gagner du temps j'ai tout mis dans le même.