Попытка определить конкретную проблему нормализации базы данных - PullRequest
Новая
       11

Попытка определить конкретную проблему нормализации базы данных

0 голосов
/ 05 июня 2009

Сотрудник набросал значения новой таблицы следующим образом: 

"Foo", "some value 1"
"Foo", "some value 2"
"Foo", "some value 3"
"Bar", "some value 3"

Это единственные столбцы в таблице. Имена столбцов: Кол1, Кол2.

Один человек сказал, что эта таблица не нормализована, другой сказал, что это так.

Конкретным аргументом в пользу того, что он нарушил нормализацию, является то, что удаление трех записей с "Foo" в Col1 "Foo" больше не будет присутствовать в системе. Этот человек сказал, что должна быть справочная таблица, содержащая столбец ID и имя. Таблица выше будет ссылаться на идентификатор этой таблицы как его FK.

Аргумент, что он не был нормализован, заключается в том, что в таблице не было третьего столбца, зависящего от первого (3-я нормализованная форма).

Я думаю, что путаница заключается в том, что она является 1NF и удовлетворяет этому примеру: 

Customer    Tr. ID  Date            Amount
Jones   12890   14-Oct-2003     -87
Jones   12904   15-Oct-2003     -50
Wilkins     12898   14-Oct-2003     -21
Stevens     12907   15-Oct-2003     -18
Stevens     14920   20-Nov-2003     -70
Stevens     15003   27-Nov-2003     -60

из http://en.wikipedia.org/wiki/Database_normalization.

Но звучит так, как будто это нарушает это правило: «Одна и та же информация может быть выражена в нескольких строках; поэтому обновления таблицы могут привести к логическим несоответствиям». Это относится к нормализации за пределами 1NF.

Таким образом, похоже, что исходная таблица будет нарушать 2NF и, следовательно, 3NF, но будет удовлетворять 1NF. Это правильно?

Ответы [ 5 ]

3 голосов
/ 06 июня 2009

Если эти два столбца действительно все есть, то я бы сказал, что эта таблица базы данных находится в третьей нормальной форме. Вот мои рассуждения:

  1. Это CLEARLY в 1NF, поскольку ни один из атрибутов не является "многозначным"
  2. Поскольку ни col1, ни col2 не являются действительными кандидатами в ключи (повторяющиеся значения!), Единственным возможным и допустимым первичным ключом в этой таблице является (col1, col2)
  3. 2NF предусматривает, что ни один непростой атрибут не должен функционально зависеть от части ключа-кандидата. Поскольку есть только col1 и col2, которые оба являются частью единственно возможного ключа-кандидата, этот вопрос является спорным - таблица IS в 2NF
  4. 3NF в соответствии с E.F.Codd в основном говорит, что любой неключевой атрибут должен зависеть «от ключа, всего ключа и только от ключа». Поскольку у нас ONLY есть два столбца, составляющих ключ, других неключевых атрибутов нет, поэтому ни один из неключевых атрибутов не нарушает это правило -> таблица IS это 3NF

Я не знаю, хочет ли ваш рабочий приятель действительно перейти в 4NF, 5NF или Boyce-Codd NF - я сильно сомневаюсь в этом ......

Марк

2 голосов
/ 05 июня 2009

Существуют разные уровни нормализации. Но без фактических имен полей вы не сможете точно узнать, нужно ли нормализовать.

1 голос
/ 05 июня 2009

Есть несколько различных уровней нормализации .

Если «Foo», «некоторое значение 1», «Foo», «некоторое значение 2», «Foo», «некоторое значение 3», «Bar», «некоторое значение 3» означает, что таблица будет выглядеть так: 

Col1| Col2
------------------
Foo | some value 1
Foo | some value 2
Foo | some value 3
Bar | some value 3

И есть первичный ключ на Col1 / Col2, тогда да, это «Нормализовано».
Если ключа вообще нет, то нет, он не нормализуется, так как вы можете вставить другой экземпляр «Bar», «некоторое значение 3».

Что касается нового вопроса, который вы добавили:
Если есть PK, охватывающий Col1 и Col2, то он все еще находится в 2NF и 3NF. Вам также нужно добавить столбец, который не является частью ключа, который вы хотите нарушить, и тогда он должен быть производным только от Col1 или только Col2.

1 голос
/ 05 июня 2009
0 голосов
/ 05 июня 2009

Я считаю, что список значений в таблице представляет четыре строки: 

col1 col2
Foo  some value 1
Foo  some value 2
Foo  some value 3 
Bar  some value 3

Исходя из моего понимания, эта таблица будет считаться нормализованной. Я ожидаю, что первичный ключ здесь будет составным ключом {col1, col2}.

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

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

...