Статьи Королевства Дельфи


Моделирование данных - часть 2


Товар (ключ) Склад (ключ) Количество Адрес склада
Т001 Склад 1 15 Вокзальная ул. д.2
Т002 Склад 2 20 Ленинский тупик д.1
Т003 Склад 2 34 Ленинский тупик д.1
Т004 Склад 3 22 Придорожный пер. д.3

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

  • Третья нормальная форма.
    Значение каждого неключевого поля таблицы в третьей нормальной форме должно представлять собой факт, не зависящий от значений никаких других неключевых полей. Кроме того, таблица должна соответствовать правилу второй нормальной формы. Пример таблицы, не отвечающей критерию третьей нормальной формы:

    Табельный № (ключ) Имя Фамилия Отдел Название отдела
    1001 Василий Чапаев Н-11 Продажи
    1002 Павел Морозов Н-23 Маркетинг
    1003 Иван Гадюкин Н-11 Продажи

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

  • Четвертая нормальная форма.
    Например, в базе данных потребовалось хранить информацию о сотрудниках, в том числе о том, на каких музыкальных инструментах он умеет играть, и какие имеет увлечения (хобби). Эти данные можно расположить в одной таблице:

    Сотрудник (ключ) Муз. инструмент (ключ) Хобби (ключ)
    Иванов Гитара Горные лыжи
    Петров Рояль Подводное плавание
    Сидоров Волынка Компьютерные игры

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

  • * * * Общее неформальное правило, касающееся нормализации, таково: полученная в результате анализа задачи модель данных нормализуется насколько это возможно, затем, если SQL-запросы для отчетов получаются чересчур сложными и/или слишком низка производительность их обработки, приходится "сдавать позиции" и денормализовывать модель.

    Продолжение следует…
    В следующей серии: отдельные рецепты денормализации, автоинкремент.

    Сергей Королев,

    Продолжение

    Часть II:





    Начало  Назад  Вперед