Discussion :

[JeePI196]

Bonjour,

Je suis entrain de créer une base de données pour une application qui supportera plusieurs langues. Pour ce faire j'ai créer une table "LANGUES" et une table "TRADUCTIONS".

--LANGUES--
LangueID (nvarchar(10), clé unique ie : culture fr-FR, en-US, etc...)
LangueNom (nvarchar(50), seulement pour savoir directement le nom de la langue pour les développeurs)

--TRADUCTIONS--
TraductionID (nvarchar(50), ie : TitrePrincipal, un label qui sera appellé dans le code de l'application pour retourner le texte lié)
LangueID (nvarchar(10), ie : en-US)
TraductionContent (text, ie : Blablalblalblalbla)

--Fruits--
FruitID (int, clé unique)
FruitCommentaire :TraductionID (nvarchar(50))

À l'ouverture de l'application, le dictionnaire de mots (singleton) est créé selon la langue.

Les autres tables qui contiennent le texte n'auront qu'à pointer vers la table TRADUCTIONS en spécifiant le TraductionID.

--Ex de TRADUCTIONS--
Banane | en-US | Bananas are yellow.
Banane | fr-FR | Les bananes sont jaunes.
Pomme | en-US | Apples are red and green.
Pomme | fr-FR | Les pommes sont rouges et vertes.

Ma question est... Comment dois-je créer les clés pour ma table TRADUCTIONS? J'ai essayé de faire une clé primaire double sur TraductionID et LangueID puisque seulement le couple est unique mais lorsque je veux lier le champs TraductionID d'une autre table, j'ai l'erreur :

"Les colonnes de la table "Traductions" ne correspondent pas à une clé primaire existante ou à une contrainte UNIQUE."

Si je retire la clé priaire double et la remplace par une clé unique, j'obtiens la même erreur.

Que me conseillez-vous? Avez-vous besoin de plus de détails?

Merci d'avance!

[SQLpro]

Visiblement vous ne maîtrisez aucun des concepts de base du monde des bases de données relationnelle. Il serait sans doute temps de vous former.

1) la notion de "clef unique" n'existe pas.

Il existe la notion de clef d'une table et la notion de contrainte d'unicité qui sont deux choses différentes.
La clef d'une relation est choisie parmi les différentes clefs candidate au moment de la modélisation conceptuelle. Une fois la clef choisie, les anciennes clefs candidates deviennent des clefs subrogées.
Cela se traduit au niveau du modèle physique (c'est à dire dans les tables) par :
clef de relation = contrainte PRIMARY KEY de la table
clef subrogées de la relations = contraintes UNIQUE de la table.
A noter qu'une clef peut être constituée de plusieurs attributs (dans le modèle conceptuel), c'est à dire de plusieurs colonnes (dans le modèle physique).

Lisez les articles que j'ai écrit afin de voir quelle est la syntaxe SQL de déclaration d'une contrainte PRIMARY KEY :
http://sqlpro.developpez.com/cours/s...partie2#L7.1.4
http://sqlpro.developpez.com/cours/s...partie2#L7.2.1


2) la notion de lien n'existe que dans le modèle conceptuel.

Ce que vous appelez "lien" n'existe pas dans une base de données.
En revanche la notion de lien existe dans le modèle conceptuel et se trouve la plupart du temps représenté par une patte qui part de l'entité pour aller à l'association (mais il existe un autre lien découlant de la modélisation des héritages).

Je suppose donc que vous voulez parler de contrainte d'intégrité qui représente la notion de clef étrangère découlant du modèle relationnel, clefs étrangères auxquelles vous voulez que les valeurs correspondent avec celles de la tables fille. Cela s'appelle la DRI pour "Declarative Referential Integrity" (en français Intégrité Référentielle Déclarative) et cela consiste à associer par la contrainte FOREIGN KEY une correspondance entre les colonnes de la clef étrangères et les colonnes d'une des contraintes soit de PRIMARY KEY soit UNIQUE de la table mère.

Lisez les articles que j'ai écrit afin de voir quelle est la syntaxe SQL de déclaration d'une contrainte FOREIGN KEY :
http://sqlpro.developpez.com/cours/s...partie2#L7.1.7
http://sqlpro.developpez.com/cours/s...partie2#L7.2.4

Enfin, une contrainte de clef étrangère possède différentes clauses de gestion que j'ai décrit ici :
http://sqlpro.developpez.com/cours/s...e=partie2#L7.3

Pour compléter, j'attire votre attention sur le fait des types de données. Une colonne qui sert de clef à une table doit être la plus concise possible et si possible de taille fixe. Il est aussi préfarable qu'elle soit dénuée de sémantique. En utilisant un NVARCHAR(10), vous faites tout le contraire...

Pour ma part, je modéliserait votre base ainsi :

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE T_LANGUES_LNG
(LNG_ID        INT NOT NULL CONSTRAINT PK_LNG PRIMARY KEY,
 LNG_LIBELLE   NVARCHAR(50) NOT NULL)
 
CREATE TABLE T_TRADUCTION_TRD
(TRD_ID        INT NOT NULL,
 LNG_ID        INT NOT NULL FOREIGN KEY REFERENCES T_LANGUES_LNG (LNG_ID),
 TRD_TEXTE     NVARCHAR(1000),
 CONSTRAINT PK_TRD PRIMARY KEY (TRD_ID, LNG_ID))

Moralité : je vous conseille fortement d'apprendre le langage SQL et les bases de données relationnelles. Mon livre, comme mon site web peuvent vous y aider !

A +

[JeePI196]

Bonjour SQLpro,

Merci pour l'attention que vous avez porté à mon sujet. Suite à vos observations et aux lectures que vous m'avez suggéré, j'ai littéralement reconstruit la structure de ma base de données. Ci-joint une vue d'ensemble qui représente l'ébauche de la structure actuelle.

Vous pouvez remarquer qu'il n'y a pas de clé étrangère entre les tables T_LNG_TRL, T_LANGUAGES_LNG et T_TRANSLATIONS_TRL parce que MSSQL ne m'y autorise pas. Je comprends que le problème provient de la clé primaire double de la table T_LNG_TRL mais je ne comprends toujours pas comment je peux spécifier que le couple TRL_ID et LNG_ID doit être unique.

De plus, j'aimerais que la colonne TRL_LABEL de la table T_TRANSLATIONS_TRL soit elle aussi unique.

Dans l'application, je n'aurai qu'à faire "Dico.getLabel('Banane')" qui me retournera une seule valeur de TRL_LNG_CONTENT selon la langue avec laquelle le Dico aura été initialisé préalablement.

En ce qui a trait à la syntaxe, comment dois-je nommer les colonnes dans les tables qui pointent vers la colonne TRL_ID? Dois-je les nommer TRL_ID ou puis-je écrire FEA_NAME (ie : le nom de la feature sera traduite en plusieurs langues). En ce moment, j'ai mis les 2 colonnes. FEA_NAME ne sert qu'à la personne qui visualise la base de données pour reconnaître rapidement une feature tandis que TRL_ID serait utilisée dans l'application pour la traduction.

Merci encore une fois pour le temps que vous m'accorder.

Sincèrement,

[SQLpro]

je suis incapable de raisonner modèle de données sur un modèle physique de données car il n'y a pas de sémantique sur un tel modèle. Tant que vous ne modéliserez pas au niveau conceptuel vous ne comprendrez pas ce qui vous pose problème, et faire comprendre aux autres votre problème sera encore plus ardu.

En général lorsque j'audite judiciairement une base de données et qu'il n'y a pas de modèle conceptuel de données, je propose à mon client d'engager la responsabilité du faiseur pour défaut de conseil et manque aux règles de l'art.
Ce sont deux fautes professionnelles condamnable au point de vu judicaire...

A +

[JeePI196]

J'ai continué mes lectures au sujet de SQL pour apprendre d'avantage sur le fonctionnement de ce langage.

Toutefois, j'ai été en mesure de solutionner mon problème. En effet, je n'avais pas remarqué qu'un coéquipier avait populer certaines tables de la base de données avant même qu'elle ne soit terminée. Ainsi, il était impossible de créer les clés étrangères parce qu'il y avait des conflits d'identifiants entre les tables.

Merci pour le temps consacré à mon sujet et de m'avoir donné quelques ressources pour approfondir mes connaissances dans le domaines des bases de données.