Нормализованная реляционная модель

Обычно исходная реляционная модель формируется из ER-модели путем преобразования полных объектов и процессов в самостоятельные отношения.

Каждому полному объекту ставится в соответствие реляционное отношение. Все свойства объекта образуют атрибуты отношения. Название отношения – название объекта, ключ отношения – ключ (идентификатор) объекта. Под полным объектом понимается объект, который, кроме ключевых свойств, имеет еще и неключевые свойства.

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

Правило невключения в реляционную модель неполных объектов является не абсолютным. Часто наличие в модели неполных объектов означает недостаточное изучение их свойств, которые в случае более детального изучения предметной области могут представляться весьма существенными для контроля целостности базы данных или для целей дальнейшего развития системы. Например, объект ТИПЫ ПЛАТЕЖА может иметь свойства, которые интегрируют разрабатываемую систему в общую систему учета и управления банком через дебетуемые и кредитуемые счета (дополнительные свойства) и т.п. Кроме того, при ведении отдельного отношения ТИПЫ ПЛАТЕЖА можно обеспечить логический (на уровне данных, а не программ) контроль правильности значений платежей по данному свойству. Ясно, что дополнительные отношения всегда усложняют систему, и следует избегать дополнительных отношений, если только на это нет веских оснований.

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

Рис. 3. Исходная реляционная модель

В дальнейшем модель нормализуется. При этом анализируются и уточняются функциональные связи между реквизитами отношений, состав ключей, которые существенным образом зависят от специфики предметной области. Эта специфика последовательно отражается студентом в разделе «Ограничения». Детально алгоритм нормализации реляционной модели описан в [3].

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

1. Все неключевые реквизиты должны полностью зависеть от всего ключа отношения.

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

3. В отношении не должно быть транзитивных зависимостей.

4. Отношения с одинаковыми ключами объединяются.

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

Первая и вторая теоремы применимы к отношениям, имеющим многоатрибутный ключ. Проверяем отношения ПЛАТЕЖИ КЛИЕНТОВ и ПЛАТЕЖИ БАНКА.

Третья теорема применима к отношениям, имеющим одноатрибутный ключ. Проверяем отношения КЛИЕНТ и ДОГОВОР.

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

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

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

1) Согласно ограничению 4 из списка ограничений (см. п.1.5) платеж банка одного типа выполняется только один раз:

ПЛАТЕЖИ БАНКА (Признак типа, N договора) ->

                                           ЧМГ, N поручения, дата поручения, сумма

2) Согласно ограничению 3 из списка ограничений платеж клиента одного типа выполняется только один раз:

ПЛАТЕЖИ КЛИЕНТОВ (Признак типа, N договора) ->

                                        ЧМГ, N поручения, дата поручения, сумма

3) В отличие от клиентов, номера платежных поручений которых на перечисление средств банку могут совпадать, номера платежных поручений самого банка уникальны. Это ограничение должно быть добавлено в список сформированных ограничений. Таким образом, номер платежного поручения банка определяет все остальные свойства платежа в отношении ПЛАТЕЖИ БАНКА:

ПЛАТЕЖИ БАНКА (N поручения) ->

                               Признак типа, N договора, ЧМГ, дата поручения, сумма

В результате исходная РМ преобразовывается в третью нормальную форму с учетом принятых в п.1.5 ограничений (рис. 4).

В случае изменения и уточнения ограничений реляционная модель в 3НФ может принять иной вид.

Рис. 4. Реляционная модель в 3 нормальной форме

Для конкретных условий предметной области часто бывает целесообразным проведение денормализации – модификации реляционной модели, представленной в третьей нормальной форме. Например, в случаях изменения реквизитов клиентов от договора к договору или наличия незначительного числа клиентов, имеющих много договоров, возможно является целесообразным слияние таблиц КЛИЕНТ и ДОГОВОР в одну таблицу ДОГОВОР c ключом Номер Договора или объединения таблиц ПЛАТЕЖИ КЛИЕНТОВ и ПЛАТЕЖИ БАНКА в одну таблицу ПЛАТЕЖИ с использованием общего ключевого поля N договора+Признак типа.

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

Приводится один из вариантов датологической модели «Учет депозитных договоров в коммерческом банке» в среде выбранной СУБД, например, MS Access.

а) состав таблиц:

КЛИЕНТ,

ДОГОВОРА,                               

ПЛАТЕЖИ КЛИЕНТОВ,

ПЛАТЕЖИ БАНКА

б) структура таблиц

Приводятся описания полей всех таблиц, согласно требованиям конкретной СУБД, включая определение ключей и индексов.

в) схема данных

Приводится экранная форма схемы данных в МS Access.