1.5. Нормализация

Казалось бы, таблица готова: название объекта - имя таблицы, элементы данных – имена полей в таблице. Но не тут-то было! Согласно принципам проектирования базы данных для таблиц должны выполняться правила нормализации.

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

Правила нормализации, основанные на теории множеств, были предложены доктором Е.Ф. Коддом (E.F. Codd). Главная цель процесса нормализации – обеспечение эффективной работы приложения и сведение к минимуму операций с данными и объема кодирования.

Перечислим семь базовых правил нормализации:

1) Поля должны быть атомарными. Это означает, что данные должны быть разбиты на как можно меньшие порции. Например, вместо поля «Фамилия Имя» следует создавать два поля: «Фамилия» и «Имя». Тогда с данными будет намного легче работать. Например, могут быть созданы два поля, то эту задачу Вы решите мгновенно. В противном случае Вас ожидают серьезные проблемы.

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

Среди элементов данных объекта «Клиент» (см. рисунок 39) нет того, который бы отвечал этому требованию. В связи с этим добавим к существующему списку элементов данных еще один – «Код сотрудника» (порядковый номер сотрудника в общем списке).

3) Первичный ключ должен быть коротким, стабильным и простым. «Короткий» означает, что длина поля ключа должна быть небольшой. Хорошо подходят числа длиной 4 байта. «Стабильный» означает, что сам ключ и содержимое поля ключа должны изменяться как можно реже, весьма желательно – никогда. Например, номер клиента более стабилен чем название его компании, потому что последнее может измениться, в то

время как номер присваивается в БД и менять его нет причин. «Простой» означает, что ключ должен быть наглядным и легким в использовании.

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

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

6) Пользователь должен иметь возможность изменять значения любого поля, не входящего в ключ, без воздействия на данные других полей. Это требование, очевидно, тоже выполняется.

7) Одна и та же информация не должна появляться в нескольких местах базы данных. Например, фамилия сотрудника должна быть только в одной записи, посвященной только ему.

2. ЛОГИЧЕСКОЕ ПРОЕКТИРОВАНИЕ

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

Основной задачей логического проектирования является разработка логической схемы (модели), ориентированной на выбранную систему управления базами данных (СУБД). На этом этапе часто моделируют базы данных применительно к различным СУБД и проводят сравнительный анализ моделей.