Пытаясь определить конкретный вопрос нормализации базы данных

Question

Коллега набросал значение новой таблицы, как:

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

только эти столбцы в таблице. Имена столбцов - Col1, Col2.

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

Конкретный аргумент, что он нарушает нормализацию, заключается в том, что удаление трех записей с помощью «Foo» в Col1 «Foo» больше не будет присутствовать в системе. Этот человек сказал, что должна быть таблица поиска, содержащая идентификатор и столбец Name. В приведенной выше таблице ссылка на 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. Это верно?

Answer 1

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

1. Это ЯСНО в 1NF, так как ни один из атрибутов не являются «многозначным»
2. Поскольку ни col1, ни col2 являются действительным кандидатом ключа, возможно, только и действительный первичный ключ в этой таблице (col1, col2)
3. 2NF предусматривает, что атрибут non-prime не должен быть функционально зависим от части ключа-кандидата. Поскольку существует только col1 и col2, которые являются частью единственно возможного ключа-кандидата, этот пункт является спорным - таблица IS в 2НФЕ
4. 3NF по EFCodd в основном говорит, что любой неключевой атрибут должен быть зависимым " на ключ, весь ключ и ничего, кроме ключа ». Поскольку мы ТОЛЬКО есть две колонки, которые составляют ключ, нет никаких других неключевых атрибутов, поэтому ни один из неключевых атрибутов не нарушает это правило -> таблица IS является 3NF

Я не знаю, если ваша работа приятель хочет, чтобы действительно получить в 4НФ, 5NF или Бойса-Кодда NF - Я очень сомневаюсь, что это ......

Marc

Answer 2

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

Answer 3

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

Answer 4

Есть несколько different levels of normalization.

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

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

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

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

Answer 5

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

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

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

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

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