Правила нормализации логической модели

Проектирование БД.

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

Проектирование БД можно разбить на следующие этапы:

1. проектирование концептуальной модели на основе результатов анализа поставленной заказчиком задачи и обработки требований конечных пользователей;

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

3. проектирование физической модели БД.

4. оценка физической модели БД.

5. реализация БД.

Первый этап включает в себя:

· анализ данных: сбор основных данных о предметной области, то есть ее структуризация, определение основных объектов и связей между ними;

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

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

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

Затем для каждого объекта определяются атрибуты, которые будут храниться в БД. Выбор таких атрибутов сложен и неоднозначен.

Процедуры хранения данных в БД должны подчиняться следующим основным принципам:

Ø целостность и непротиворечивость данных, под которыми понимаются:

· физическая сохранность данных;

· предотвращение неверного использования данных;

· поддержка допустимых сочетаний их значений;

· защита от структурных искажений и несанкционированного доступа;

Ø минимальная избыточность данных. Это значит, что любой элемент данных должен храниться в БД в единственном виде, что позволяет избежать необходимости дублирования операций, производимых с элементом данных.

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

Следующий этап, нормализация модели, является основой построения оптимальной реляционной БД.

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

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

Введение нормализации таблиц при разработке информационной модели обеспечивает минимальный объем физической БД (записанной на каком-либо носителе) и ее максимальное быстродействие. Нормализация модели выполняется в несколько этапов.

Этапы нормализации:

1. Если данные о предметной области занести в одну двумерную таблицу, в которой все поля являются простыми, то такая таблица будетпредставлять собой первую нормальную форму (1НФ) реляционной модели данных (РМД).

Пример. Возьмем предметную область "Поставка товара". Пусть таблица (отношение C), соответствующая первой нормальной форме РМД, содержит следующие атрибуты (Поставщик, Товар, Город, Факс, Телефон, Стоимость транспортировки, Объем поставки). Составной ключ <Поставщик+Товар> однозначно идентифицирует строки таблицы (записи). Имеется зависимость атрибутов < Город, Факс, Телефон, Стоимость транспортировки > от части ключа <Поставщик>. Это ведет к дублированию данных, если Поставщик поставляет не один Товар. В этом случае возникает проблема контроля избыточных данных, так как изменение любого из указанных атрибутов придется производить во всех кортежах для данного Поставщика.

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

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

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

Пример. Исключив зависимые атрибуты из отношения С, получим отношение D (Поставщик, Товар, Объем поставки). Отношение Е (Поставщик, Город, Факс, Телефон, Стоимость транспортировки) получим, объединив часть ключа и зависимые от него атрибуты.

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

Пример. В отношении Е атрибут<Стоимость транспортировки> зависит от ключа не прямо, так как зависит от атрибута <Город>. Эта зависимость транзитивная. Выделив эти атрибуты в отдельное отношение из отношения Е, получим два новых отношения F (Город, Стоимость транспортировки) и G (Поставщик, Город, Факс Телефон) вместо отношения Е. Заменив Е отношениями F и G, совершили приведение отношения, находящегося в 2НФ в третью нормальную форму (3НФ).

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

Существуют и более высокие формы нормализации, но они используются редко.

Правила нормализации логической модели

Для построения оптимальной (нормализованной) модели:

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

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

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

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

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

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

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

3. Естественный атрибут может изменяться во времени. Использование в этом случае неизменного кода позволит избежать сложностей при эксплуатации системы.

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

Основы проектирования БД

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

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

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

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

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

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