Р исунок 7 – Фрагмент реляционной бд

Реляционными СУБД являются DB2, Oracle, Paradox, Access, MySQL и др.

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

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

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

Правила Кодда, которые необходимо использовать при создании реляционной БД:

• реляционная СУБД должна управлять БД, используя связи между данными;

• вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться на основе выбранных правил именования;

• любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичного ключа и имени столбца;

• СУБД должна уметь работать с пустыми значениями (пустое значение - это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений);

• описание БД и каталог содержимого БД должны быть определены на логическом уровне через таблицы, к которым можно применять запросы, используя язык манипулирования данными;

• язык манипулирования данными должен поддерживать определение данных и манипулирование ими, правила целостности, авторизацию и транзакции;

• все представления, теоретически обновляемые, могут быть обновлены через систему;

• СУБД поддерживает не только запрос на данные, но и вставку, обновление и удаление;

• физическая независимость данных - логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения;

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

• язык БД должен быть способен определять ограничения целостности, ограничения должны быть доступны из оперативного каталога и не должно быть способа их обойти;

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

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

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

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

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

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

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

Пример нормализации в 1НФ. Перечень возможных атрибутов, характеризующих заказ, включает дату заказа, ФИО клиента, телефон клиента, номер счета, название товара, цена, производитель, индекс фирмы производителя, адрес, количество товара, оплата. Поскольку один клиент может в течение одного дня сделать несколько заказов, таблица может содержать одинаковые строки. На один и тот же товар может поступить несколько заказов, и, наконец, фирма производитель может поставлять несколько товаров. Таблицы могут содержать следующие данные, табл.2, 3:

Таблица 2 - Описание заказа

Дата заказа	ФИО	Телефон	Счет	Наименование товара
01-08-2009	Иванов И.И.	1234567	1234567890123456789	Часы
01-08-2009	Сидоров И.И.	7654321	2345678901234567890	Ручки
02-08-2009	Петров П.П.	2345678	3456789012345678901	Карандаши
03-08-2009	Владимиров В.В.	3456789	4567890123456789012	Тетрадки

Таблица 3 - Описание товара

Цена	Производитель	Почтовый индекс	Адрес	Количество	Оплата
350.00	«Восток»	123456	Королева, 6	85	Да
15.00	«Канцтовары»	234567	Гагарина, 24	74
5.00	«Канцтовары»	234567	Гагарина, 24	25
25.00	«Канцтовары»	234567	Гагарина, 24	36	Да

Приведем таблицу к 1НФ. Выделим следующие сущности: заказы, клиенты, товары, производители. Добавим в таблицу «Заказ» поле «Номер заказа», что позволит однозначно идентифицировать каждый из заказов. Таблица содержит три группы повторяющихся атрибутов. Атрибуты, характеризующие клиента «ФИО», «Телефон», «Счет», вынесем в таблицу «Клиенты». Атрибуты, характеризующие товар «Наименование товара» и «Цена», вынесем в таблицу «Товары». Атрибуты, характеризующие производителя «Производитель», «Почтовый индекс», «Адрес» вынесем в таблицу «Производители».

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

Для организации связи между таблицами по совпадающим атрибутам, добавим в таблицу «Заказы» поля «Номер клиента» и «Номер товара», а в таблицу «Товары» - «Номер производителя» для организации связи.

Таким образом, данные из таблиц 2 и 3 примут следующий вид - таблицы 4-7.

Таблица 4 – Описание заказа

Заказ	Дата	Идентификатор клиента	Идентификатор товара	Идентификатор производителя	Количество товаров	Оплата
1	01-08-2009	1	1	1	85	Да
2	01-08-2009	1	2	2	74
3	02-08-2009	2	3	2	25
4	03-08-2009	3	4	2	36	Да

Таблица 5 – Описание клиентов

Идентификатор клиента	ФИО	Телефон	Счет
1	Иванов И.И.	1234567	1234567890123456789
2	Сидоров И.И.	7654321	2345678901234567890
3	Петров П.П.	2345678	3456789012345678901
4	Владимиров В.В.	3456789	4567890123456789012

Таблица 6 – Описание товара

Идентификатор товара	Наименование товара	Цена	Идентификатор производителя
1	Часы	350.00	1
2	Ручки	15.00	2
3	Карандаши	5.00	2
4	Тетрадки	25.00	2

Таблица 7 – Описание производителей

Идентификатор производителя	Производитель	Почтовый индекс	Адрес
1	«Восток»	123456	Королева, 6
2	«Канцтовары»	234567	Гагарина, 24

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

Пример нормализации во 2НФ. Перечень возможных атрибутов, характеризующих проекты, включает название и код проекта, цель проекта, дата начала и окончания проекта, руководитель, телефон. Пусть таблица имеет составной ключ, который формируется по двум атрибутам: «Код проекта», «Код руководителя проекта». Атрибуты «Название», «Цель», «Дата начала, окончания», «Руководитель», «Телефон» являются частично зависимыми. Атрибуты «Название», «Цель», «Дата начала и окончания» зависят только от «Проекта», но не зависят от «Руководителя», т.е. однозначно идентифицируется частью ключа, а не полным набором ключевых полей. Аналогично поля «Руководитель» и «Телефон» зависят только от «Руководителя». Для приведения к 2НФ необходимо вынести все частично зависимые поля в отдельную таблицу; определить ключевые поля; установить отношения между таблицами 8 и 9.

Таблица 8 – Сведения о проектах

Код проекта	Название	Цель	Дата начала	Дата окончания	Руководитель
1	Балтика	Исследование климата	01-01-1990	31-12-1995	1
2	Баренц	Проводка судов	01-01-1996	31-12-1999	2

Таблица 9 – Сведения о руководителях проектов

Код руководителя	ФИО	Телефон
1	Иванов И.И.	1234567
2	Петров П.П.	2345678

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

Таблица 10 – Сведения о заказах

Код заказа	Покупатель	Дата продажи	Менеджер	Код менеджера
1	Иванов И.И.	01-11-2007	Сидоров С.С,	1
2	Петров П.П.	01-11-2007	Михайлов М.М.	2

Таблица не находится в 3НФ, т.к. не ключевое поле «Менеджер» зависит от другого не ключевого поля «Код менеджера». Для приведения к 3НФ необходимо поле «Менеджер» вынести в отдельную таблицу. Таким образом, в результате создается две таблицы 11 и 12.

Таблица 11 – Сведения о заказах

Код заказа	Покупатель	Дата продажи	Код Менеджера
1	Иванов И.И.	01-11-2007	1
2	Петров П.П.	01-11-2007	2

Таблица 12 – Сведения о менеджерах

Код Менеджера	Менеджер
1	Сидоров С.С,
2	Михайлов М.М.