Библиотека программиста

Все, что необходимо начинающему и опытному программисту

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

Первая нормальная форма
Первая нормальная форма требует, чтобы каждое поле таблицы базы данных было атомарным, то есть было неделимым и не содержало повторяющихся групп.
Неделимость поля означает, что содержащиеся в нем значения не должны
делиться па более мелкие. Для примера, поле «Ф.И.О.»- следует разделить на
поля «Фамилия*», «Имя*» и «Отчество*», тогда будет соблюдаться атомарность
значений.

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

Таблица «Список сотрудников»

Рис. 1.18, Пример дублирующихся полей

Каждый раз, когда штат расширяется или сокращается, придется перестраивать таблицу, добавляя отдельное поле. А если список сотрудников будет большим. То работать с ней будет просто неудобно. В этом случае таблицу следует преобразовать к виду, представленному на рис. 1.19.

Таблица «Список сотрудников»

Рис. 1.19. Преобразованная структура таблицы

В качестве примера можно принести некоторую ненормализованную таблицу, представленную на рис. 1,20, к первой нормальной форме. Предположим, руководству организации захочется получить список всех сотрудников, которые проживают в том пли ином городе. В приведенной таблице содержится поле «Домашний адрес». Из чего нужно вынести значение «Город* в отдельное поле. «Адрес и улицу» оставить в поле «Адрес*. Далее необходимо разделить поле «Ф.И.О.* на составляющие его поля «Фамилия*, «Имя», «Отчество*. Таким образом, будет получена нормализованная таблица, приведенная к первой нормальной форме.

Рис. 1.20. Ненормализованная таблица Полученная таблица представлена на рис 1.21.
Таблица «Список сотрудников»
Фамилия
Имя
Должность
Отдел
Рабочий телефон
Зарплата
Дата устройства на работу
Город
Адрес
Домашний телефон
Рис. 1.21. Таблица, приведенная к первой нормальной форме

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

Таблица «Список сотрудников»

Рис. 1.22. Таблица с первичным ключом
Таблица «Ставка»
Должность
Отдел
Рабочий телефон

Фамилия
Имя
Отчество
Должность
Дата устройства на работу
Город
Адрес
Домашний телефон
Рис. 1.23. Выделение таблицы «Ставка»

Поля «Отдел», «Рабочий телефон», «Зарплата» зависят от поля «Должность», входящего в первичный ключ, но не от всего ключа. Поэтому их нужно вынести в отдельную таблицу «Ставка», связанную с таблицей «Список сотрудников», отношением «один-к-одному». Полученный результат изображен на рис. 1.23.
Рассматривая структуру базы, можно увидеть, что поля «Город*, «Адрес», «Телефон» зависят только от полей «Фамилия», «Имя», «Отчество» первичного ключа, но не от всего ключа. Поэтому их нужно выделить в отдельную таблицу «Дом» и связать ее с основной таблицей в соотношении «один-к-одному». В результате будет получена структура базы данных во второй нормальной форме (рис. 1.24).

Таблица «Ставка»
I------------------------------------------------ Должность
Отдел
Рабочий телефон
Зарплата
Таблица «Список сотрудников»

Таблица «Дом» Город Адрес
Домашний телефон Город
Адрес___________________
Домашний телефон
Рис. 1.24. Таблица во второй нормальной форме

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

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

Системный каталог
Любая реляционная база данных, в которой поддерживаются такие объекты, как пользователи и роли, должна сохранят, их списки. Кроме того, обычно с базой данных хранятся системные таблицы, триггеры, транзакции, хранимые процедуры — соответствующая часть памяти СУБД называется системным каталогом.

<< Назад         В начало         Далее >>

Библиотека программиста. 2009.
Администратор: admin@programmer-lib.ru