Нормализация отношений

Под нормализацией отношений подразумевается процесс приведения отношения к одной из так называемых нормальных форм. Однако перед рассмотрением НФ следует сказать несколько слов, зачем нужна нормализация. Как уже отмечалось БД – это не просто хранилище фактов. При проектировании БД упор в первую очередь делается на достоверность и непротиворечивость хранимых данных, причем эти свойства не должны утрачиваться в процессе работы с данными.

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

Т.о. БД в процессе создания, независимо от ее наполнения данными, должна удовлетворять следующим ограничениям:

- обеспечивать быстрый доступ к данным

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

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

Приведение структуры БД в соответствие этим ограничениям – это и есть нормализация.

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

Перейдем к рассмотрению нормальных форм. Выделяют 3 формы нормальных отношений

Первая нормальная форма

Отношение называется нормализованным или приведенным к первой нормальной форме, если все его атрибуты простые (неделимы). Преобразование отношения к первой нормальной форме может привести к увеличению количества реквизитов (полей) отношения и изменению ключа.

Например, отношение Сотрудник = (Таб. номер, Фамилия, Имя, Отчество, Дата, Отдел) находится в первой нормальной форме.

Вторая нормальная форма

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

Пример:

Отношение Сотрудник = (Таб. номер, Фамилия, Имя, Отчество, Дата, Отдел) находится в первой и во второй нормальной форме одновременно, т.к. описательные реквизиты однозначно определены и функционально зависят от ключа Таб.номер.

Отношение Должность = (Таб.номер, Фамилия, Имя, Отчество, Вид работы, Объем, Заработная плата) находится в первой нормальной форме и имеет составной ключ Таб.Номер + Вид работы. Это отношение не находится во второй нормальной форме.

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

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

Функциональная зависимость реквизитов – зависимость, при которой в экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита.

Такое определение функциональной зависимости позволяет при анализе всех взаимосвязей реквизитов предметной области выделить самостоятельные информационные объекты.

Графическое изображение функциональной зависимости реквизитов

Если в информационном объекте присутствует составной ключ, вводится понятие полной функциональной зависимости.

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

Теперь вернемся к нашему примеру. В отношении Должность = (Таб.номер, Фамилия, Имя, Отчество, Вид работы, Объем, Заработная плата) атрибуты Фамилия, Имя и Отчество не находятся в полной функциональной зависимости с составным ключом отношения, поэтому данное отношение не находится во второй нормальной форме.

Третья нормальная форма

Понятие третьей нормальной формы основывается на понятии нетранзитивной зависимости.

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

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

Пример:

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

Для устранения транзитивной зависимости описательных реквизитов необходимо провести «расщепление» исходного информационного объекта.

Итак, у нас имеется информационный объект – Сотрудник отдела, обладающий реквизитами Таб.номер, Фамилия, Имя, Отчество, Дата, Отдел, которые находятся в функциональной зависимости от ключевого реквизита Таб.номер. Кроме того. в данном информационном объекте наблюдается транзитивная зависимость между описательными реквизитами Отдел и Начальник отдела

Для устранения транзитивной зависимости этих реквизитов необходимо провести «расщепление» исходного информационного объекта.

В результате расщепления часть описательных реквизитов удаляется из исходного информационного объекта.

Скажите, какие реквизиты необходимо удалить, чтобы избавиться от транзитивной зависимости?

Начальник отдела

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

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

Как вы думаете какой нужно создать объект, чтобы включить реквизит Начальник отдела?

Отдел

Какие реквизиты будет содержать этот объект?

Отдел и Начальник отдела

Какой реквизит является ключевым?

Отдел

Т.о. мы создали новый информационный объект Отдел, атрибуты это объекта Отдел и Нач. отдела тоже находятся в функциональной зависимости.

Пример «расщепления» структуры информационного объекта:

Как видно из рисунка, исходный информационный объект Сотрудник отдела представляется в виде совокупности правильно структурированных информационных объектов (Сотрудник и Отдел), реквизитный состав которых тождественен исходному объекту. Т.о. Отношение Сотрудник = (Таб.номер, Фамилия, Имя, Отчество, Дата, Отдел) находится одновременно в первой, второй и третьей нормальной форме. Объяснить

Все информационные объекты предметной области связаны между собой. Связи между объектами бывают трех типов:

- один к одному (1:1);

- один ко многим (1:М);

- многие ко многим (М:М).

Рассмотрим эти типы связей на примере:

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

Поставщик (Код поставщика, Название, Адрес, Вид деятельности)

Потребитель (Код потребителя, Название, Адрес)

Объем поставок (Код поставщика, Количество продукции 1-ого вида, Количество продукции 2-ого вида, Количество продукции 3-его вида)

Скидка (Объем товара, Процент)

Связь один к одному (1:1) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра объекта В и наоборот.

Графическое изображение реального отношения 1:1

Примером связи 1:1 может служить связь между информационными объектами Поставщик и Объем поставок.

Поставщик Объем поставок

Каждый поставщик имеет определенный объем поставок каждого вида продукции.

При связи один ко многим (1:М) одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с одним экземпляром объекта А.

Графическое изображение реального отношения 1:М

Примером связи 1:М служит связь между информационными объектами Скидка и Потребитель.

Скидка Потребитель

Установленный размер скидки по результатам объемов поставки (закупки) может повторяться многократно для различных потребителей.

Связь многие ко многим (М:М) предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует 0, 1 или более экземпляров объекта В и наоборот.

Графическое изображение реального отношения М:М

Примером данного отношения служит связь между информационными объектами Поставщик и Потребитель.

Поставщик Потребитель

Один поставщик может обслуживать многих потребителей и один потребитель может получать товар от многих поставщиков.

3.4. Построение инфологической модели

А теперь рассмотрим пример построения информационно-логической модели.

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

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

Инфологическая модель строится в первую очередь до создания СУБД.

Графически это выглядит следующим образом. Дана совокупность информационных объектов, отражающих торгово-закупочную деятельность предприятия. В инфологической модели необходимо отобразить информационные объекты и связи между ними.

Пример графического представления инфологической модели

Дата добавления: 2015-05-09