нормализация базы данных до 1nf, 2nf, 3nf, bcnf?

Question

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

Эта таблица используется для компании по найму автомобилей. Клиенты могут нанимать автомобили из разных точек, конкретный автомобиль доступен только для определенного выхода и может быть нанят только одному клиенту на определенную дату. Таблица 1nf имеет поля:

Carreg, HireDate, Марка, модель, CustNo, CustName, OutletNo, OutletLoc

Первичные ключи (Carreg, HireDate)

Может кто-то пожалуйста, поговорить со мной через преобразование это bcnf шаг за шагом? и результаты, полученные на каждом шагу? спасибо

Мои ответы:

2NF

Carreg, HireDate, CustNo, CustName (рк: Carreg, HireDate)

Carreg, Марка, модель, OutNo, outLoc (рк: Carreg)

3NF

Carreg, HireDate, CustNo (рк: Carreg, HireDate)

CustNo, Custname (рк: CustNo)

Carreg, модель, OutNo (рк: Carreg)

Модель, Марка (рк: модель)

OutNo, outLoc (рк: OutNo)

Отвечают ли мои ответы? и как мне преобразовать это в bcnf?

Answer 1

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

• 1NF: Проще говоря - мы не нужны многозначные или составные атрибуты на нашем столе вместе с другими. Поэтому мы разделяем их на новую таблицу, добавляя ключ для подключения исходной таблицы к новой.

• 2NF: Это немного сложно, но вот как вы можете это сделать: если какая-то зависимость от составного ключа, это должно быть во всей полноте ключа, а не только от его части. Это важно, только если у вас есть составной ключ в вашей таблице.

• 3NF: Это говорит о том, что мы не можем иметь транзитивность в наших атрибутах таблицы. Это означает следующее: могу ли я узнать из одного атрибута, всех других атрибутов, независимо от ключа? Пример. Предположим, у вас есть ресторан и стол для еды. У еды есть что в ней? Цена, имя и, допустим, идентификатор. Из названия еды, предполагая, что еда имеет уникальные имена, вы можете найти цену и удостоверение личности. Предполагается, что ID является ключом, поэтому в 3NF это запрещено. Но предположим, что теперь у вас есть таблица для ваших клиентов. Предположим, что у него есть уникальный номер, имя, адрес и контактный номер. Теперь, если мы предположим, что уникальный номер является ключом, можете ли вы найти его имя, другие атрибуты? Что делать, если они имеют одно и то же имя? Или даже тот же адрес? Ясно, что в этом случае они не являются транзитивными.

• BCNF: Короче говоря, это говорит о том, что для любой зависимости это должен быть только ключ и ключ. Пример. Предположим, у вас есть таблица для счетов в ресторане, которая имеет следующее: bill_number, customer_number, waiter_ID, meal_number и описание. Предположим, что все, кроме описания, является ключевым и уникальным. Посмотрите, что происходит сейчас: waiter_ID зависит от bill_number, поэтому мы можем найти его через это. Нам даже не нужно имя_домена или номер_объекта и наоборот. Дело в том, что здесь есть некоторые ненужные отношения, поэтому они должны быть отделены друг от друга, поскольку зависимость не от всего ключа. (Обратите внимание на то, что описание, однако, зависит от всех из них. Может быть, тот же официант взял счет одного и того же клиента одного и того же блюда. Посмотрите, что происходит в этом случае? Только bill_number может быть использован для идентификации)

Я m немного ржавые по этим темам, но это не должно быть слишком неправильно. В целом, если вы правильно понимаете определения, вы должны быть в состоянии делать все, что угодно. На youtube есть много хороших примеров из того, что я нашел.