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

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

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

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

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

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

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

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

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

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

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

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

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

2.2.

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

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

ключ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

км/ч

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

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

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

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

Длина

Ширина

Высота

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

км/ч

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

км/ч

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

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

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

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

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

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

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

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

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

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

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

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

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

2.3.

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

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

Key model Name model Key firm Swept volume

Примечание

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

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

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

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

Firm (Фирма) № п/п

Наименование Примечание поля

Key firm

Name firm

Key country

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

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

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

Country ( Страна)

№ п/п

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

Key country Name country

Примечание

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

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

Fuel oil ( Топливо)

№ п/п

Примечание

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

Key fuel oil Уникальный ключ

Name fuel oil

топлива

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