Бази данни - анализ


Категория на документа: Информатика


Познали сте ако се отговорили, че само OrderID/LineItemNumber и OrderID/ProductID са кандидат ключове. Въпреки, че ProductID не е кандидат ключ, то определя стойността на полетата Продукт и Цена. Както сигурно вече сте се досетили, това означава, че полетата Продукт и Цена са замесени в транзитивни зависимости и с двата кандидат ключа. Затова ще трябва да изтриете тези две полета от таблицата. Ще трябва да премахнете и полето Total, защото нито един от кандидат ключовете не определя неговата стойност. Вместо това, тя се определя от полетата Количество и Цена. След като премахнете тези три полета, таблицата ще е в БКНФ. Фигура 13-б показва резултата от тези промени.

Фигура 13-б. Таблицата OrderDetails в БКНФ.

Повечето таблици в БКНФ не биха изисквали по-нататъшна Нормализация. Ще се наложи обаче да преминете през Четвърта Нормална Форма, ако таблицата ви съдържа многозначни зависимости.

Четвърта Нормална Форма (4НФ)

Една релационна променлива е в 4НФ тогава и само тогава когато, съществува подмножество А и Б на атрибутите на релационната променлива, такова че (нетривиална) многозначната зависимост А  Б е удовлетворена. Тогава всички атрибути на релационната променлива също са зависими от А.

Предназначението на 4НФ е да осигури отсъствието на каквито и да било многозначни зависимости в таблицата и описването само на една същност. (Забелязахте ли, че последното присъства за всички по-висши Нормални Форми?) По рано научихте, че една таблица съдържаща многозначни зависимости описва две или повече същности, в зависимост от броя на присъстващите многозначни зависимости. Научихте също така, че трябва да премахнете всички многозначни зависимости от таблицата. Ще го постигнете, ако подложите таблицата на 4НФ.

Фигура 14-а показва таблица EmployeeCommittees, която съдържа една многозначна зависимост. Първата версия има многозначна зависимост на ниво поле, а втората съдържа многозначна зависимост на ниво запис. Начинът, по който прилагате 4НФ за всяка таблица, е абсолютно един и същ и води до един и същ резултат.

Фигура 14-а. Две версии на таблицата EmployeeCommittees.

При прилагането на 4НФ върху таблица, съдържаща единична многозначна зависимост, построявате нова таблица с помощта на копие на първичния ключ и полето с многото значения. Употребата на първичния ключ като част от структурата на новата таблица е важно, защото така тя се свързва с първоначалната таблица. (Постарайте се да дадете на новата таблица подходящо име.) После раздробявате началната таблица като премахвате многозначното поле. И готово! И променената и новосъздадената таблица са в 4НФ.

Фигура 14-б показва резултата от тези стъпки приложени върху таблицата EmployeeCommittees.

Фигура 14-б. Таблиците Служители и EmployeeCommittees в 4НФ.

Ако се сблъскате с таблица с две или повече многозначни зависимости, просто повтаряте същите стъпки за всяка зависимост. Например, Фигура 14-в показва таблицата Служители с две независими многозначни зависимости.

Фигура 14-в. Таблицата Служители с две независими многозначни зависимости.

Ще направите за всяка многозначна зависимост същото, което направихте в предишния пример.
1. Създавате нова таблица с помощта на първичния ключ (EmployeeID) и първото многозначно поле (Languages). Давате име на новата таблица.
2. Създавате друга нова таблица с помощта на първичния ключ (EmployeeID) и второто многозначно поле (DeveloperCertification). Давате име на новата таблица.
3. Премахвате двете многозначни полета от началната таблица.

Променената начална таблица (EmployeeInformation) и двете нови таблици са в 4НФ. Фигура 14-г показва резултата от прилагането на 4НФ върху таблицата EmployeeInformation.

Фигура 14-г. Таблиците EmployeeInformation, EmployeeLanguages и EmployeeCertifications са в 4НФ.

Пета Нормална Форма (5НФ)

Една релационна променлива е в 5НФ, тогава и само тогава, когато всяка нетривиална зависимост от свързването, в която участва променливата, се осъществява чрез кандидат ключовете на променливата.

По-рано в този материал научихте, че зависимост от свързването съществува за някоя таблица, когато тя и всичките й първоначални записи могат да се реконструират с помощта на SQL JOIN операция, която обединява всички таблици създадени при декомпозицията й. Можете да проверите за този тип зависимост с помощта на 5НФ.

В момента, в който една таблица е в 4НФ, тя не би трябвало да съдържа транзитивни и многозначни зависимости. В повечето случаи, не бихте имали нужда да декомпозирате таблицата повече. Ако прецените, обаче, че трябва да я раздробите още веднъж, трябва да проверите дали има валидна зависимост на свързаността в таблицата. Има три ключови въпроса, на които трябва да отговорите преди да декомпозирате таблицата допълнително:
1. Мога ли да създам новата (новите) таблици с помощта на първичния ключ или кандидат ключ като част от структурата й? (Помнете, че това е изискване, за да няма транзитивни и многозначни зависимости.)
2. Мога ли да пресъздам първоначалната таблица с помощта н SQL JOIN операция, която обединява всички таблици създадени при декомпозицията?
3. Ще загубя ли записи по време на този процес на декомпозиция?

Ако отговорът на всеки въпрос е "да", тогава таблицата е в 5НФ и уверено можете да направите декомпозицията. Това, че можете да раздробявате таблицата допълнително, не е задължително да означава, че трябва да го правите.

Фигура 15-а показва таблицата Служители, която би могла да се раздроби на по-малки таблици. Дали е в 5НФ? Погледнете таблицата за момент и използвайте трите въпроса поставени по-горе, за да вземете решение.

Фигура 15-а. Дали таблицата е в 5НФ?



Сподели линка с приятел:





Яндекс.Метрика
Бази данни - анализ 9 out of 10 based on 2 ratings. 2 user reviews.