Normalisation d'une base de données avec des entrées "chaînées".

Question

Je suis novice en matière de conception de bases de données et je n'ai pas trouvé de méthode définitive pour structurer ma base de données de vocabulaire. Les champs non pertinents mis à part, les données que je veux stocker sont conceptuellement quelque chose comme ceci :

Mot 1

• Signification 1 (1-n de ceux-ci)

• Exemple 1 (0-n de ceux-ci)

• Exemple 2

• ...

• Signification 2

• ...

Mot 2

...

Or, un mot est identifié par trois attributs : Nom du mot, Langue, et POS (part of speech). J'ai configuré cela comme une clé composée. D'après ce que j'ai lu, j'ai compris que les significations et les exemples devraient être dans des tables séparées, peut-être quelque chose comme ceci :

Tableau des mots

• Clé

• Nom de mot

• Langue

• POS

• ...

Table de signification

• Clé

• Nom de mot

• Langue

• POS

• Signification (1-n lignes par clé)

Exemple de tableau

• Clé

• Nom de mot

• Langue

• POS

• Signification

• Exemple (0-n lignes par clé)

Mais cela me semble être une quantité horrible de données dupliquées. Serait-il préférable d'extraire la clé nom du mot-langue-POS dans une table séparée et de donner à chaque ligne une clé unique ? Existe-t-il une approche plus efficace ?

Merci beaucoup.

Answer 1

En général, vous pouvez vous épargner quelques maux de tête en générant une clé unique pour chaque ligne de chaque table, où la clé est un simple entier, plutôt que des données réelles. Les références aux clés étrangères sont plus faciles, et vous n'avez pas à faire face à des problèmes tels que "oups, quelqu'un a mal orthographié un mot, mais ce mot fait maintenant partie d'une clé étrangère dans une autre table !". Les bases de données qui appliquent l'intégrité des clés étrangères peuvent vraiment rendre la vie difficile lorsque les valeurs des clés changent.

Et, comme vous le faites remarquer, l'utilisation de mots et d'autres informations comme clés étrangères entraîne beaucoup de duplications. L'objectif de la normalisation (enfin, l'un d'entre eux, en tout cas) est d'éliminer la duplication.

La plupart des moteurs de base de données génèrent ces clés pour vous, généralement avec une propriété appelée "identité". Ces bases de données disposent généralement d'un moyen facile de récupérer ces clés par programme, lorsque de nouvelles données sont insérées. Mais cela relève davantage du code et de l'implémentation.

Answer 2

Vous êtes sur la bonne voie, mais n'oubliez pas qu'il y a une limite de colonnes.

1. Dans votre MEANING la table, le key serait une clé étrangère à la WORD.key valeur - cela vous permet d'établir un lien avec les valeurs de l'ensemble de l'UE. WORD sans avoir besoin de les dupliquer dans la table MEANING table.
2. Si vous faites en sorte MEANING.key n'est pas unique, vous pouvez supporter une infinité de MEANING.meaning valeurs

Exemple

MOTS

• clé (clé primaire)
• nom de mot
• langue
• POS

Exemple :

key   wordname    language   POS
----------------------------------
1     'foobar'    'English'  idk

SIGNIFICATION

• clé
• signification
• contrainte unique sur les deux colonnes pour éviter les doublons

Exemple :

key    meaning
----------------
1      'a'
1      'b'

Si vous voulez un ordre des valeurs de signification, vous devrez définir une colonne pour indiquer l'ordre d'une manière ou d'une autre - IE : meaning_id

Answer 3

Moi aussi, je préconiserais une clé qui soit un nombre entier. Vos tableaux deviennent alors très simples :

Word
KeyTable
Nom du mot
Langue
PartOfSpeach

Signification
KeyTable
Mot clé
Description

Exemple
KeyTable
Signification des clés Description

On pouvait alors obtenir assez facilement toutes les significations d'un mot donné :

SELECT m.Description
FROM Word w, Meaning m
WHERE w.KeyTable = m.KeyWord
AND w.WordName = 'Example'

Les exemples pour un mot donné sont également assez simples :

SELECT m.Description, e.Description
FROM Word w, Meaning m, Example e
WHERE w.KeyTable = m.KeyWord
AND m.KeyTable = e.KeyMeaning
AND w.WordName = 'Example'