база данных ---- нормализация базы данных

Question

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

+------------+-----------+-------------------+ 
    pk    pk    row 
    +------------+-----------+-------------------+ 
     A     B     C 
    +------------+-----------+-------------------+ 
     A     D     C 
+------------+-----------+-------------------+ 
      A     E     C 
    +------------+-----------+-------------------+ 

Answer 1

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

No non-prime attribute in the table is functionally dependent on a 

собственное подмножество кандидата ключа (Wikipedia)

Так что С зависит от «А», который является подмножеством первичного ключа. Первичным ключом является специальный ключ. (dportas указывают на то, что его нельзя назвать ключом кандидата, поскольку он не минимальный).

Предположим, что речь идет о второй форме нормализации. Измените свой пример немного для легкого понимания, предположите, что есть таблица CUSTOMER(customer_id, customer_name, address). Супер ключ - это подмножество ваших свойств, которые однозначно определяют трубку. В этом случае есть 3 супер ключа: (customer_id); (customer_id, customer_name); (customer_id, имя_пользователя, адрес). (Имя клиента может быть одинаковым для 2 человек)

В вашем случае вы определили (customer_id, customer_name) Первичный ключ. Он нарушил правила второй формы; так как для определения уникальной трубки в вашей базе данных требуется только customer_id. Для упрощения теории проблема здесь связана с выбором первичного ключа (это не ключ-кандидат), хотя тот же аргумент может быть применен для отображения избыточности. Вы можете найти полезный пример here.

Третья нормальная форма гласит, что:

Каждый не-премьер атрибут , не транзитивно зависит от каждого ключа кандидата в таблице

Пусть дать ему пример. Изменив предыдущую таблицу, чтобы она соответствовала второй форме, теперь у нас есть таблица CUSTOMER(customer_id,customer_name, city, postal_code), а client_id - первичный ключ.

Очевидно, что «postal_code» зависит от «города» клиента. Здесь он нарушил третье правило: postal_code зависит от города, города зависит от customer_id. Это означает, что postal_code транзитивно зависит от customer_id, так что таблица не соответствует третьей нормальной форме.

Чтобы исправить это, нам необходимо устранить переходную зависимость. Итак, мы разделили таблицу на 2 таблицы: CUSTOMER(customer_id, customer_name, city) и CITY(city, postal_code). Это предотвращает избыточное количество слишком большого количества трубок с одним и тем же городом & postal_code.

Answer 2

На ваш вопрос нельзя ответить должным образом, если вы не заявите, какие зависимости должны быть удовлетворены здесь. Кажется, у вас есть два атрибута с одним и тем же именем (pk), и в этом случае эта таблица даже не удовлетворяет 1NF, потому что она не квалифицируется как отношение.

Answer 3

Вы можете просто следовать моим заметкам.Каждый шаг подробно описывается множеством примеров: Normalization. Найдите термин «нормализация» на сайте.