Третья нормальная форма (3НФ)

Отношения во второй нормальной форме также могут иметь аномалии.

Рассмотрим отношение ПРОЖИВАНИЕ с ключом НомерСтудента:

НомерСтудента	Общежитие	Плата

Здесь имеются функциональные зависимости: НомерСтудента -> Общежитие и Общежитие -> Плата. Эти зависимости возникают потому, что каждый студент живет только в одном общежитии, и каждое общежитие взимает со всех проживающих в нем студентов одинаковую плату.

Поскольку НомерСтудента определяет атрибут Общежитие, а Общежитие определяет атрибут Плата, то косвенным образом НомерСтудента -> Плата. Такая структура функциональных зависимостей называется транзитивной зависимостью.

Ключом отношения ПРОЖИВАНИЕ является НомерСтудента, который является одиночным атрибутом, и, следовательно, отношение находится во второй нормальной форме. Несмотря на это отношение ПРОЖИВАНИЕ имеет аномалии, обусловленные транзитивной зависимостью.

Если удалить вторую строку отношения, то мы потеряем не только тот факт, что студент №150 живет в общежитии №2, но и тот факт, что плата за проживание в общежитии №2 стоит 310р. Это аномалия удаления. Кроме того, мы не можем записать тот факт, что плата за проживание в общежитии №2 составляет 310р. Это аномалия вставки.

Чтобы удалить аномалии из отношения во второй нормальной форме, необходимо устранить транзитивную зависимость.

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и не имеет транзитивных зависимостей.

Отношение ПРОЖИВАНИЕ можно разделить на два отношения в третьей нормальной форме.

 

СТУДЕНТ-ПРОЖИВАНИЕ		ОБЩЕЖИТИЕ-ПЛАТА
* НомерСтудента	Общежитие		* Общежитие	Плата

 

Рассмотренное ранее отношение СЕКЦИЯ также содержит транзитивную зависимость. Разбиение данного отношения на два устраняет аномалии.

Отношения во второй нормальной форме без транзитивных зависимостей автоматически переводятся в разряд отношений 3НФ.

 

Использование на стадии логического проектирования модели “сущность-связь” позволяет сразу создавать отношения в 3НФ. Однако знание теории нормальных форм важно по двум причинам:

1. Оно помогает понять проблемы, возникающие при разработке слабо нормализован­ных отношений.

2. Модель предметной области никогда не бывает правильно разработана с первого шага (эксперты предметной области могут забыть о чем-либо упомянуть, разработчик может неправильно понять эксперта, во время разработки могут измениться правила, принятые в предметной области, и т.д.), поэтому могут появиться новые зависимостей, которые отсутствовали в первоначальной модели предметной области. В этом случае необходимо использовать теорию нормальных форм, чтобы убедиться, что отношения остались в 3НФ и физическая модель данных не ухудшилась.

В большинстве случаев первых трех нормальных форм вполне достаточно, чтобы разрабатывать вполне работоспособные базы данных, однако в теории нормальных форм дополнительно рассматриваются следующие нормальные формы: нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ) и доменно-ключевая нормальная форма (ДКНФ).

 

 

20. Даталогическое проектирование. CASE – средства в разработке баз данных.

одна его часть в самом начале БД про даталогическое проектирование. а вторая часть в проектировании есть.

Даталогическое проектирование - описание БД в терминах выбранной модели данных (обычно реляционной).

Даталогическое проектирование является проектированием логической структуры БД, что означает определение всех информационных единиц и связей между ними, задание их имен и типов, а также некоторых количественных характеристик (например, длины поля).

 

При проектировании логической структуры БД, осуществляется преобразование исходной инфологической модели в модель данных, поддерживаемую конкретной СУБД, и проверка адекватности полученной даталогической модели отображаемой предметной области.

 

Системы CASE поддерживают автоматизированное проектирование реляционных баз данных. В системе CASE применяется одна из наиболее развитых среди множества разновидностей ER-моделей.

CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

 

CASE-средства поддерживают концептуальное проектирование, позволяют осуществить логическое и физическое проектирование путем автоматической генерации БД для целевой СУБД. Но следует обратить внимание на различия в терминологии. Во многих CASE-системах ER-модель называется логической моделью, а представление логической структуры целевой БД – физической моделью.