· категорийная целостность;
· ссылочная целостностью
Категорийная целостность связана с тем, что значения атрибутов, являющихся ключом отношения, должны быть уникальными и не могут быть неопределенными. Поэтому строка, являющаяся кортежем не может быть занесена в отношение до тех пор, пока не будут определены все атрибуты ее ключа. что касается ссылочной целостности, то если в одном отношении удаляется запись, то в отношениях, связанных с ним не должно быть кортежей, имеющих значение внешнего ключа удаляемой записи.
При использовании SQL Server 2000 для построения базы данных отношения трансформируются в таблицы, а при установлении связей с помощью схемы данных необходимо позаботиться об обеспечении целостности и каскадном обновлении и удалении данных.
Первая нормальная форма.
Таблица представлена в первой нормальной форме (1НФ) тогда и только тогда, когда все ее столбцы содержат только неделимые (в том смысле, что их дальнейшее разложение невозможно) значения и в ней отсутствуют повторяющиеся группы (столбцов) в пределах одной строки.
Первое правило реляционной модели состоит в том, что ни один столбец не должен содержать два или более значений, т.е. реляционная модель базы данных запрещает повторяющиеся поля.
Ни одну из реляционных СУБД не удовлетворяет только 1НФ, поскольку в этом случае требуется определять большое число полей, многие из которых остаются в основном пустыми. Альтернативный подход, при котором записи могут иметь переменную длину, практически не применяется из-за больших затрат ресурсов на реализацию алгоритма, определяющего, где кончается одна запись и начинается следующая.
Метод, который можно использовать для приведения таблицы к первой нормальной форме, состоит в том, чтобы разбить ее данные на две связанные таблицы
Если таблица находится в 1НФ, то отображение ее данных и построение к ней запросов не составляет никакой сложности. Однако это правило еще не препятствует дублированию данных в строках. Следствием будет ввод в таблицу большого количества данных, хранить которые нет никакой необходимости. Избыточные данные могут послужить причиной проблем целостности и снижения эффективности при внесении изменений, поэтому подобных решений при проектировании баз данных необходимо избегать.
Вторая нормальная форма.
Для определения второй нормальной формы необходимо ввести концепцию функциональной зависимости. Это зависимость, связывающая атрибуты в одной таблице с единственным значением в другой таблице. Функциональную зависимость для таблиц А и В принято обозначать как А--В. Это понятие подводит "на один шаг" к родственной концепции объединения таблиц в отношения типа 1:1 или 1:М.
Таблица представлена во второй нормальной форме (2НФ) тогда и только тогда, когда она представлена в 1НФ каждый не ключевой атрибут полностью определяется первичным ключом. Атрибут полностью определяется первичным ключом, если он находится в правой части выражения, описывающего функциональную зависимость, а левую часть этого выражения представляет первичный ключ или какое-либо выражение, которое может быть вычислено на его основе с использованием транзитивных свойств функциональной зависимости.
Избыточность 1НФ может послужить причиной возникновения проблем и при удалении или добавлении. Аномалия вставки может проявиться в том случае, когда при добавлении в таблицу с первичным ключом какой-либо записи вы вынуждены поместить в поле первичного ключа либо пустое, либо уже существующее значение. Подобное действие нарушает основные требования реляционной теории и потребует от вас (как минимум) заново сформировать поле первичного ключа этой таблицы и все связанные с ним ключевые поля в других таблицах, что вызовет значительные потери в производительности. Аналогично, аномалия удаления проявляется в тех случаях, когда у вас возникает необходимость удалить запись и провести реорганизацию ваших таблиц. Если впоследствии потребуется восстановить удаленную запись, то вы вынуждены будете вновь подвергнуть обработке весь набор таблиц. Цель разработки 2НФ состоит в устранении этих проблем.
Третья нормальная форма.
Если A является элементом кандидатного ключа, то будем называть A первичным атрибутом. Под тривиальной функциональной зависимостью здесь понимается зависимость типа xA -> A. Эта зависимость тривиальна, поскольку Х не принимает участия в идентификации первичного атрибута, лишь подразумевается в его определении.
Это определение - всего лишь оригинальный способ выразить необходимость представления системы связанных таблиц в таком виде, чтобы атрибуты каждой таблицы непосредственно определялись либо суперключом, либо кандидатным ключом этой таблицы. В предыдущем примере реализация определения ЗНФ состоит в выделении таблицы Контролирующие лица.
Для большинства существующих СУБД и инструментов CASE-технологии необходимо представить проект вашей базы данных в ЗНФ, так как этого вполне достаточно практически для всех обычных приложений. При разработке исключительно больших систем на сверхбыстродействующих компьютерах, когда необходимо обеспечить максимальное сокращение объемов хранимых данных, желательно провести дальнейшую нормализацию.
Таблица Х представлена в нормальной форме Бойса-Кодда (БКНФ), если в каждой нетривиальной функциональной зависимости В -> А, В является суперключом.
Уместно сделать несколько замечаний о недостатках, присущих даже таблицам, представленным в ЗНФ. Существуют варианты, когда имеет смысл разделить таблицу на более мелкие таблицы, если часть представленных в ней данных непостоянна и часто обновляется, а остальные данные пассивны и изменяются в редких случаях. Также есть смысл объединить таблицы, когда необходимо обеспечить высокую скорость реакции на запрос. Можно даже пойти на дублирование данных в таблицах, если это позволит снизить затраты на обработку запросов, хотя формально не следовало бы этого делать. Иногда приходится отступить от принципа полной нормализации данных проекта. Это может быть вызвано следующими причинами:
· временем выполнения запросов;
· временем проведения обновлений;
· общим необходимым объемом хранилища данных;
· аномалиями удаления, которые могут вызвать потерю целостности данных.
И ЗНФ и БКНФ являются теоретическими конструкциями, в то время как большинство разработчиков баз данных работают в реальном мире.
Четвертая и пятая нормальные формы.
Прежде чем закончить рассмотрение правил Кодда, вам будет предложен краткий обзор двух последних правил реляционных баз данных. Эти два правила предназначены для устранения еще двух аномалий, называемых многозначная зависимость и объединяющая зависимость.
Многозначная зависимость определяется следующим образом.
В таблице Х существует многозначная зависимость А -> В, если в этой таблице можно обнаружить ситуации, в которых пара строк содержит дублирующееся значение А и одновременно существуют другие пары строк, полученные путем перестановки значений В, присутствующих в первой паре.
Прежде всего, для существования многозначной зависимости требуется существование пар строк. А и В могут быть как отдельными атрибутами, так и объединением некоторого набора атрибутов. Тривиальная многозначная зависимость для А -> В существует в случае, когда В является подмножеством А или А объединяет B = xS (более крупная таблица содержит исходную таблицу). Существование многозначной зависимости порождает аномалию обновления. Четвертая нормальная форма устраняет нетривиальную многозначную зависимость в таблице посредством создания меньших таблиц. Процесс нормализации представляет собой создание как можно большего числа все более мелких таблиц в целях сокращения избыточности данных.
Определим четвертую нормальную форму.
Таблица Х представлена в 4НФ тогда и только тогда, когда она представлена в БКНФ и для любой многозначной зависимости А -> В в этой таблице можно сказать, что эта зависимость либо является тривиальной, либо А является суперключом таблицы X.
И последнее. Рассмотрим пятую нормальную форму.
Пятая нормальная форма достигается в том случае, когда таблица не может далее разбиваться на более мелкие таблицы посредством операции проектирования.
Под операцией проектирования понимается не вызывающая потерь данных декомпозиция, при которой таблица разбивается на части таким образом, что остается возможность объединения полученных меньших таблиц для получения в результате исходной таблицы.
I. Факты
· При создании трубопровода создается участок трубопровода.
II. Ограничения
· Пользователь не может удалить участок трубопровода, если их количество не превышает одного.
· Пользователь не может сохранить изменения в базе пока не введет все необходимые данные.
III. Активаторы
· Если срок эксплуатации участка трубопровода истек, то необходимо уведомить пользователя об этом.
· Если в базе хранятся не все необходимы данные о трубопроводе, то необходимо уведомить пользователя об этом.
IV. Вывод
· Если удаляется трубопровода, то удаляются все его участки, комментарии к нему и обследования с целью продления срока службы.
· Если удаляется участок трубопровода, то удаляются все его испытания, ревизии, отказы, ремонты, диагностики.
V. Вычисления
· Общая длина трубопровода вычисляется как сумма длин участков трубопровода.
· При вводе даты последнего обследования и выбора периодичности обследования, вычисляется дата следующего обследования.
· доступ через локальную вычислительную сеть;
· вся информация должна представляться в определенном виде в соответствии с разработанной структурой;
· в БД должен предусмотрен поиск;