Bonsoir,
A la très grande louche, à 100 km d’altitude et d'un point de vue tabulaire :
Supposons que la table Produit "monolingue" ait la structure suivante, dans la quelle l’attribut ProdId représente la clé primaire du produit, l’attribut ProdLibelle la désignation du produit, ProdAtt1, ProdAtt2, etc. les autres attributs de Produit (clé primaire soulignée) :
Produit (ProdId, ProdLibelle, ProdAtt1, ProdAtt2, ProdAtta3, ProdAtt4, ProdAtta5, ..., ProdAttn)
Dans la mesure où l’attribut ProdLibelle ainsi par exemple que les attributs ProdAtt3 et ProdAtt4 deviennent multivalués du fait du passage à une version multilingue de la table Produit, pourquoi ne pas mettre en œuvre une table de référence Langue (évidemment unique pour la base de données) et éjecter vers une table ProduitLangue les attributs ProdLibelle, ProdAtt3 et ProdAtt4 ?
Produit (ProdId, ProdAtt1, ProdAtt2, ProdAtta5, ..., ProdAttn)
ProduitLangue (ProdId, LangueId, ProdLibelle, ProdAtta3, ProdAtt4)
Langue (LangueId, LangueAtt1, ..., LangueAttn)
Dans la table ProduitLangue, les attributs ProdId et LangueId composent la clé primaire, mais composent aussi respectivement les clés étrangères référençant les tables Produit et Langue.
Naïvement, je dirai que les valeurs prises par les attributs ProdLibelle, ProdAtta3, ProdAtt4 sont exprimées dans la langue qui va bien.
Quelque part, on retrouve ici les problèmes que l'on rencontre avec les propriétés multivaluées, cas par exemple des historiques.
Partager