Нормализация базы данных с «цепочками» записей - PullRequest
1 голос
/ 23 августа 2010

Я новичок в разработке баз данных, и я не нашел определенного способа структурировать свою словарную базу данных. За исключением ненужных полей, данные, которые я хочу сохранить, концептуально выглядят примерно так:

Слово 1

  • Значение 1 (1-н из них)
  • Пример 1 (0-н из них)
  • Пример 2
  • ...
Значение 2 ...

Слово 2

...

Теперь Слово идентифицируется по трем атрибутам: Имя слова, Язык и POS (часть речи). Я настроил это как составной ключ. Из того, что я прочитал, я понял, что значения и примеры должны быть в отдельных таблицах, возможно, что-то вроде этого:

Таблица слов

  • ключ
  • Wordname
  • Язык
  • POS
...

Таблица значений

  • Key
  • Wordname
  • Язык
  • POS
Значение (1-n строк на ключ)

Пример таблицы

  • Key
  • Wordname
  • Язык
  • POS
  • Значение
Пример (0-n строк на ключ)

Но это поражает меня как ужасное количество дублирования данных. Было бы лучше абстрагировать ключ wordname-language-POS в отдельную таблицу и дать каждой строке один уникальный ключ? Есть какой-то подход, который в целом лучше?

Большое спасибо.

Ответы [ 3 ]

1 голос
/ 23 августа 2010

Вы на правильном пути, но имейте в виду, что есть предел столбца.

  1. В вашей таблице MEANING key будет внешним ключом к значению WORD.key - это позволяет вам связываться со значениями в таблице WORD, не дублируя их в таблице MEANING .
  2. Если вы сделаете так, чтобы MEANING.key не был уникальным, вы можете поддерживать бесконечные MEANING.meaning значения

Пример

WORD

  • ключ (первичный ключ)
  • wordname
  • язык
  • POS

Пример:

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

СМЫСЛ

  • ключ
  • смысл
  • уникальное ограничение на оба столбца для остановки дубликатов
* * Пример 1 042:
key    meaning
----------------
1      'a'
1      'b'

Если вы хотите порядок значений значений, вам нужно определить столбец, чтобы как-то указать порядок - IE: meaning_id

1 голос
/ 23 августа 2010

Я бы тоже защищал ключ, который является целым числом. Ваши таблицы станут очень простыми:

Слово
KeyTable
WordName
Язык
PartOfSpeach

Значение
KeyTable
KeyWord
Описание

Пример
KeyTable
KeyMeaning Описание

Учитывая слово, вы можете относительно легко получить все значения для данного слова:

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

Примеры для данного слова также довольно просты:

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'
1 голос
/ 23 августа 2010

В общем, вы можете избавить себя от головной боли, генерируя уникальный ключ для каждой строки каждой таблицы, где ключ представляет собой простое целое число, а не фактические данные.Ссылки на внешние ключи проще, и вам не нужно иметь дело с такими проблемами, как «упс, кто-то написал слово с ошибкой, но это слово теперь является частью внешнего ключа в другой таблице!»Базы данных, которые обеспечивают целостность внешнего ключа, могут действительно усложнить жизнь при изменении значений ключа.

И, как вы заметили, использование слов и другой информации в качестве внешних ключей является большим дублированием.Весь смысл нормализации (ну, в любом случае, один из них) заключается в устранении дублирования.

Большинство механизмов баз данных генерируют эти ключи для вас, обычно со свойством, называемым «личность».Эти базы данных, как правило, имеют простой способ получить эти ключи программно, когда вставляются новые данные.Однако, это больше касается кода и реализации.

...