А. В. Брешенков Проектирование баз данных на основе информации табличного вида Допущено в качестве учебного пособия для студентов высших учебных заведений, обучающихся по направлению подготовки диплом
Вид материала | Диплом |
СодержаниеУпражнения и вопросы для самоконтроля 4. НОРМАЛИЗАЦИЯ ЗАПОЛНЕННЫХ РЕЛЯЦИОННЫХ ТАБЛИЦ. 4.1. Проблемы нормализации |
- Учебное пособие Допущено Министерством образования Российской Федерации в качестве, 2582.59kb.
- Д. В. Андреев Программирование микроконтроллеров mcs-51, 2064.3kb.
- И. В. Борискина, А. А. Плотников, А. В. Захаров проектирование современных оконных, 1699.55kb.
- «История нового времени», 4001.1kb.
- Учебное пособие. 3-е изд., испр и доп, 125.38kb.
- М. В. Ломоносова Хрестоматия по истории государства и права зарубежных стран, 11295.75kb.
- В. В. Крупица Личность Коллектив Стиль отношений (социально-психологический аспект), 4876.34kb.
- И. М. Синяева, В. М. Маслова, В. В. Синяев сфера, 5230.77kb.
- И. К. Корнеев информационная безопасность и защита информации учебное пособие, 7667.6kb.
- Курслекций допущено умо по образованию в области социальной работы в качестве учебного, 2178.14kb.
Упражнения и вопросы для самоконтроля
- Приведите пример таблиц, содержащих данные различного типа в одном столбце.
- Опишите алгоритм приведения данных, содержащихся в столбце, к одному типу.
- Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
- Приведите примеры реальных таблиц, содержащих дублирование записей.
- Опишите алгоритм исключения дублирования записей.
- Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?
4. НОРМАЛИЗАЦИЯ ЗАПОЛНЕННЫХ РЕЛЯЦИОННЫХ ТАБЛИЦ.
4.1. Проблемы нормализации
В табл. 4.1 представлен общий вид заполненной реляционной таблицы (общий вид отношения).
Т а б л и ц а 4.1
A1 | A2 | … | Ai | … | Aj | … | Ak |
a11 | a12 | … | a1i | … | a1j | … | a1k |
a21 | a22 | … | a2i | … | a2j | … | a2k |
… | … | … | … | … | … | … | … |
an1 | an2 | … | ani | … | ani | … | ank |
… | … | … | … | … | … | … | … |
am1 | am2 | … | ami | … | amj | … | amk |
Здесь A = {A1, A2, …, Ai …, Aj, …, Ak} – множество атрибутов (заголовков) таблицы (отношения).
a = ((a11, a12 , …, a1i, …, a1j, …, a1k),
(a21, a22 , …, a2i, …, a2j, …, a2k), …,
(an1, an2 , …, ani, …, anj, …, ank), …,
(am1, am2 , …, ami, …, amj, …, amk)) – множество кортежей значений атрибутов.
В данном представлении множество ”a” представляет собой множество записей таблицы.
Если это же множество представить следующим образом:
a = ((a11, a21 , …, an1, …, am1),
(a12, a22 , …, an2, …, am2), …,
(a1i, a2i , …, ani, …, ami), …,
(a1j, a2j , …, anj, …, amj), …,
(a1k, a2k, …, ank, …, amk)),
то в таком представлении множество “а” является множеством значений атрибутов А, где
k – степень отношения;
m – мощность отношения.
В качестве ограничений в данной таблице принимаются следующие требования:
1. Ai (Ai A) (Ai ‘ Ai)
i = 1, k; A = {A1, A2, …, Ai, …, Aj, …, Ak}
Другими словами все атрибуты отношения должны быть неделимы (атомарны).
2. (a11 a21 … an1 … am1) …
(a1i a2i … ani … ami) …
(a1k a2k … ank … amk)),
Т.е., все значения хотя бы одного из столбцов таблицы должны отличаться друг от друга. Это требование обеспечивает наличие первичного ключа. Вопросы, связанные с назначением первичного ключа рассматриваются в главе 5.
Так как ключ может содержать в себе более одного атрибута, то к предыдущему выражению со связкой ”ИЛИ” можно приписать следующее выражение (для двух атрибутов):
concat (a1i, a1j) concat (a2i, a2j) … concat (ani, anj) … concat (ami, amj)
i = 1, k; j = 1, k; i j .
Здесь concat (a1i, a1j) - конкатанация (сцепление) значений атрибутов Ai и Aj.
Первичный ключ может включать в себя и три атрибута. Если это так, то к предыдущему выражению со связкой ”ИЛИ” добавится выражение, включающее конкатенации из 3-х значений атрибутов. На практике первичный ключ исключительно редко включает в себя более 3-х атрибутов – чаще всего он состоит из одного атрибута, реже из 2-х и очень редко из 3-х.
3. Ai (Ai A) (T(a1i) = T(a2i) = … = T(ani) = … = T(ali)), n = 1, m
Здесь T(a2i) – тип значения атрибута a2i. Другими словами, типы значений атрибутов должны совпадать. Вопросы приведения значений одноименных атрибутов к одному типу рассмотрены в 3.1.
- concat (a11, a12, …, a1i, …, a1j, …, a1k) …
- concat (an1, an2, …, ani, …, anj, …, ank ) …
- concat (am1, am2, …, ami, …, amj, …, amk)
- concat (an1, an2, …, ani, …, anj, …, ank ) …
Другими словами - все записи таблицы должны быть уникальны. Нетрудно доказать, что так оно и будет, если удовлетворяется условие (п.2). Действительно, в соответствии с ограничением (п.2) в отношении должен присутствовать хотя бы один столбец, для которого выполняется условие:
a1i … ani … ami
Таким образом, во всех конкатенациях п.4 имеются значения атрибутов, которые не равны друг другу. А из этого следует, что не одно из значений конкатенации не равно другому значению конкатенации, что и требовалось доказать.
Однако не для всех таблиц задействуются ключевые поля. В связи с этим, необходимы средства для исключения дублирования в таблицах без ключевых атрибутов.
Часть вопросов реализации изложенных требований к заполненным таблицам изложены в работах [6], часть вопросов рассмотрены в предыдущей главе.
Таким образом, можно принять, что, используя предложенные методы и средства, можно привести заполненную нереляционную таблицу к виду табл. 4.1 и при этом удовлетворить перечисленным требованиям.
В связи с этим для дальнейших выкладок будет использоваться таблица вида табл. 4.1, удовлетворяющая требованиям к реляционным таблицам.
Несмотря на то, что таблица может быть реляционной и допустимой для использования в БД, ее структура не всегда оптимальна. Под оптимальностью в данном случае понимается непротиворечивость, отсутствие избыточности, отсутствие сложных зависимостей внутри таблицы. С целью улучшения названных свойств таблицы разработаны требования к структурам реляционных таблиц и механизмы их реализации, так называемые нормальные формы. Однако они хорошо работают на этапе проектирования таблиц. Для заполненных же реляционных таблиц существующие механизмы напрямую неприменимы. В связи с этим оправданно использование существующей теории (насколько это можно) для разработки средств нормализации заполненных реляционных таблиц.
Как правило, в литературе рассматриваются 4-е нормальные формы [1]. В несколько упрощенном виде они звучат следующим образом.
- Атрибуты должны быть атомарны.
- Все неключевые атрибуты зависят от ключевого атрибута.
- Неключевые атрибуты не должны зависеть друг от друга.
- Между атрибутами не должно быть множественных зависимостей.
Следует еще раз обратить внимание на то, что в рассматриваемом случае речь идет не о проектировании отношений, когда разработчик БД может создавать отношения, основываясь на сформулированные условия нормализации. Речь идет о заполненных реляционных таблицах, для которых в общем случае эти условия не выполнены.
В связи с этим возникает задача разработки модели информации табличного вида, модели реляционной таблицы, методов приведения заполненных реляционных таблиц к нормальной форме. Об этом и пойдет речь дальше.