Логическая модель базы данных. Нормализация

Логическая структура реляционной базы данных определяется совокупностью логически связанных реляционных таблиц.

Логические связи соответствуют структурным связям между объектами в концептуальной модели, каждый объект в логической модели отображается соответствующей реляционной таблицей.

Связи между таблицами осуществляются посредством общих атрибутов.

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

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

Нормализация является основой для удаления из сущностей нежелательных функциональных зависимостей (ФЗ). ФЗ подразумевается, если мы можем определить значение атрибута, просто зная значение некоторого другого атрибута. Например, если мы знаем название страны, то можем определить название ее столицы. Следовательно, между страной и ее столицей имеется функциональная зависимость.

Существует еще один вариант зависимости, известный как многозначная зависимость (МЗЗ). Она означает, что если мы знаем значение одного атрибута, то можем определить набор значений другого атрибута. Например, зная название страны, можно определить названия всех ее аэропортов; следовательно, между страной и аэропортами существует многозначная зависимость. ФЗ и МЗЗ иногда обозначаются следующим образом:

ФЗ: А • В (А определяет В)

МЗЗ: А • • В (А определяет набор В)

Почему нормализованная информационная модель так важна в реляционном проектировании? Многочисленные испытания доказали, что процесс нормализации дает наилучший результат при моделировании мира с использованием двумерных объектов (таблиц) без установления слишком большого числа ограничений или искажения фактов (данных), для сбора которых мы пользуемся базой данных. С практической точки зрения, нормальные формы помогают проектировать базы данных, в которых нет ненужных избыточных данных и противоречий, которые могут повлечь за собой проблемы производительности или потерю информации при последующем выполнении операций вставки, обновления и удаления. Чтобы подытожить сказанное, отметим, что нормальные формы позволяют избежать искажения данных путем создания ложных данных или разрушения истинных.

Первая нормальная форма (1НФ). Сущность находится в первой нормальной форме, если значения всех ее атрибутов атомарные. Все повторяющиеся группы должны быть удалены и помещены в новую (связанную) сущность.

Вторая нормальная форма (2НФ). Сущность находится во второй нормальной форме, если она находится в первой нормальной форме, а каждый ее неключевой атрибут функционально полно зависит ключа (или от каждого компонента первичного ключа — для сущностей с составными ключами, состоящими из двух и более атрибутов). Вторая нормальная форма требует, чтобы не было неключевых атрибутов, которые зависят только от части первичного ключа.

Третья нормальная форма (ЗНФ). Сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и все ее неключевые атрибуты зависят только от первичного ключа. То есть при этом они не должны зависеть и от других неключевых атрибутов.

Преобразование в 3НФ. Чтобы преобразовать информационную модель в третью нормальную форму, нужно помнить: «Все атрибуты сущности должны зависеть от ключа, только от ключа и ни от чего, кроме ключа».

Пример нормализации

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

Следует прибегнуть к нормализации, т.е. к разбиению большого отношения на несколько маленьких с целью устранения аномалий модификации.

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

Таблица «Поставщики» будет состоять из Кода, Наименования поставщика и Города его регистрации. Все данные, указанные здесь, относятся только к поставщику. Их (кроме кода) нет смысла упоминать в последующих таблицах, иначе мы столкнемся с избыточностью данных.

Таблица «Ценности» будет также включать Код и Наименование, а также ряд специфических атрибутов — «Единицы измерения», «Цена» и «Срок службы». Поле «Единицы измерения» - чисто символическое, поскольку наша база не содержит никаких «весовых» ценностей, в основном всё будет исчисляться «штуками». Но есть случаи, когда разумней упомянуть в качестве единиц «Комплекты». Поле «Цена» носит информационный характер. Что касается «Срока службы», то будет правильным исчислять его в месяцах. На основании этого поля товар может подлежать списанию по причине «Окончания срока службы». Однако за владельцем остается право не списывать ценность - все зависит только от его желания.

В таблицу «Материально-ответственные лица» в качестве информации введем Код, ФИО, Должность и Место работы.

Теперь необходимо создать таблицу, которая будет содержать информацию о поставках ценностей - что поставлено, кем, когда и в каком количестве. Так как уже есть информация о ценностях и поставщиках, то вместо их названий будем использовать их коды. Поле «количество» будет числовым. Здесь в качестве ключа одним полем уже не обойтись - в каждом столбце могут повторяться как Код поставщика, так и Код ценности. Наверное, следовало бы сделать ключом эти два поля... Но разумней будет создать дополнительный атрибут с типом «счетчик», и сделать его ключевым. Таким образом, избежим необходимости назначения составного (композитного) ключа.

Следующая таблица будет рассказывать о том, за кем из материальных лиц закреплена определенная ценность. Аналогично будем вводить код М-0 лица, ценности и «дату закрепления» (тип поля - «Дата/время»). Здесь тоже применим суррогатный ключ - добавим поле «Номер ответственности» с типом «Счетчик».

Причины списания могли вписывать в структуру таблицы «Списание», не используя отдельной таблицы. Однако это связано с определенной трудностью – тогда невозможно ввести информацию о какой-либо причине списания, пока не появится списанная по этой причине вещь.

Таблица «Списание» будет состоять из 4 атрибутов - Код ценности, Код причины списания, Количество и Даты списания. В качестве ключа добавим поле «Номер списания» с типом данных «Счетчик».

Теперь по возможности избавились от аномалий вставки и удаления.

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

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