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

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

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

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

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

Транзитивная зависимость выявляет дублирование данных в одном отношении. Если A, B и C -три атрибута одного отношения и C зависит от B, а B от A, то говорят, что C транзитивно зависит от A, как это схематично показано на рис. 2.14,а. Преобразование в третью нормальную форму происходит за счет разделения исходного отношения на два, как это показано на рис. 2.14,б.

Например, если все данные о моделях автомобилей и самих поступающих автомобилях хранятся в одном отношении, то для нескольких автомобилей одной модели пришлось бы

ПРОДАВЕЦ Уникальный ключ Уникальный ключ продавца продавца

Фамилия

Отчество

Этап 4. Приведение модели к требуемому уровню нормальной формы

Приведение модели к требуемому уровню нормальной формы является основой построения реляционной БД.

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

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

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

Давайте сформулируем основные правила, которым нужно следовать при проектировании базы данных:

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

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

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

С учетом выше изложенного в нашей модели необходимо видоизменить список атрибутов сущности МОДЕЛЬ и добавить такие новые сущности, как ТОПЛИВО, ШИНЫ, КУЗОВ, ФИРМА,

СТРАНА (рис. 2.15).

В основном изменения в модели связаны с введением искусственных атрибутов, которые в виде кодов участвуют в отношениях вместо естественных атрибутов (вид топлива, марка шин и т. п.). К необходимости введения в модель искусственных атрибутов мы пришли в процессе нормализации. В общем случае мы рекомендуем использовать вместо естественных атрибутов коды в следующих случаях:

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

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

Если естественный атрибут может изменяться во времени (например, фамилия), то это может вызвать очень большие сложности при эксплуатации системы. Представьте, что ваш лучший продавец, очаровательная девушка Карина, вышла замуж. Что будет с данными, которые привязаны к ее девичьей фамилии? Использование неизменяемого кода (табельного номера) позволит избежать этих сложностей.

Атрибуты, включаемые в измененные или добавленные в модель сущности, приведены в табл.

2.2.

Таблица 2.2. Атрибуты и первичные ключи измененных или добавленных сущностей

информационной модели Сущность Первичный Атрибуты

ключ

МОДЕЛЬ Уникальный ключ Уникальный ключ модели модели

Наименование модели

Уникальный ключ фирмы

Наименование страны

Рабочий объем двигателя

Количество цилиндров Мощность

ТОПЛИВО Уникальный ключ топлива

ШИНЫ Уникальный ключ шин

КУЗОВ Уникальный ключ кузова

ФИРМА Уникальный ключ фирмы

СТРАНА Уникальный ключ страны

Крутящий момент

Уникальный ключ топлива

Максимальная скорость

Время разгона до 100

км/ч

Уникальный ключ шин

Уникальный ключ кузова

Количество дверей

Количество мест

Длина

Ширина

Высота

Расход топлива при 90

км/ч

Расход топлива при 120

км/ч

Расход топлива при городском цикле

Уникальный ключ топлива

Наименование топлива Уникальный ключ шин

Наименование шин

Уникальный ключ кузова

Наименование кузова

Уникальный ключ фирмы

Наименование фирмы

Уникальный ключ страны

Уникальный ключ страны

Наименование страны

Этап 5. Физическое описание модели

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

2.3.

Таблица 2.3. Проект таблиц для физической модели Model (Модель) № п/п

Наименование поля

Key model Name model Key firm Swept volume

Примечание

Уникальный ключ модели

Наименование модели

Уникальный ключ фирмы

Рабочий объем,