Упражнения и вопросы для самоконтроля

1. Приведите пример таблиц, содержащих данные различного типа в одном столбце.

2. Опишите алгоритм приведения данных, содержащихся в столбце, к одному типу.

3. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?

4. Приведите примеры реальных таблиц, содержащих дублирование записей.

5. Опишите алгоритм исключения дублирования записей.

6. Как реализовать данный алгоритм на основе визуального анализа таблиц и существующих средств СУБД?

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 = {A₁, A₂, …, A_i …, A_j, …, A_k} – множество атрибутов (заголовков) таблицы (отношения).

a = ((a₁₁, a₁₂ , …, a_1i, …, a_1j, …, a_1k),

(a₂₁, a₂₂ , …, a_2i, …, a_2j, …, a_2k), …,

(a_n1, a_n2 , …, a_ni, …, a_nj, …, a_nk), …,

(a_m1, a_m2 , …, a_mi, …, a_mj, …, a_mk)) – множество кортежей значений атрибутов.

В данном представлении множество ”a” представляет собой множество записей таблицы.

Если это же множество представить следующим образом:

a = ((a₁₁, a₂₁ , …, a_n1, …, a_m1),

(a₁₂, a₂₂ , …, a_n2, …, a_m2), …,

(a_1i, a_2i , …, a_ni, …, a_mi), …,

(a_1j, a_2j , …, a_nj, …, a_mj), …,

(a_1k, a_2k, …, a_nk, …, a_mk)),

то в таком представлении множество “а” является множеством значений атрибутов А, где

k – степень отношения;

m – мощность отношения.

В качестве ограничений в данной таблице принимаются следующие требования:

1.  A_i (A_i  A)  (A_i ‘  A_i)

i = 1, k; A = {A₁, A₂, …, A_i, …, A_j, …, A_k}

Другими словами все атрибуты отношения должны быть неделимы (атомарны).

2. (a₁₁  a₂₁  … a_n1  … a_m1)  …

(a_1i  a_2i  … a_ni  … a_mi)  …

(a_1k  a_2k  … a_nk  … a_mk)),

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

Так как ключ может содержать в себе более одного атрибута, то к предыдущему выражению со связкой ”ИЛИ” можно приписать следующее выражение (для двух атрибутов):

concat (a_1i, a_1j)  concat (a_2i, a_2j)  …  concat (a_ni, a_nj)  …  concat (a_mi, a_mj)

i = 1, k; j = 1, k; i  j .

Здесь concat (a_1i, a_1j) - конкатанация (сцепление) значений атрибутов A_i и A_j.

Первичный ключ может включать в себя и три атрибута. Если это так, то к предыдущему выражению со связкой ”ИЛИ” добавится выражение, включающее конкатенации из 3-х значений атрибутов. На практике первичный ключ исключительно редко включает в себя более 3-х атрибутов – чаще всего он состоит из одного атрибута, реже из 2-х и очень редко из 3-х.

3.  A_i (A_i  A) (T(a_1i) = T(a_2i) = … = T(a_ni) = … = T(_ali)), n = 1, m

Здесь T(a_2i) – тип значения атрибута a_2i. Другими словами, типы значений атрибутов должны совпадать. Вопросы приведения значений одноименных атрибутов к одному типу рассмотрены в 3.1.

4. concat (a₁₁, a₁₂, …, a_1i, …, a_1j, …, a_1k)  …

• concat (a_n1, a_n2, …, a_ni, …, a_nj, …, a_nk )  …

• concat (a_m1, a_m2, …, a_mi, …, a_mj, …, a_mk)

Другими словами - все записи таблицы должны быть уникальны. Нетрудно доказать, что так оно и будет, если удовлетворяется условие (п.2). Действительно, в соответствии с ограничением (п.2) в отношении должен присутствовать хотя бы один столбец, для которого выполняется условие:

a_1i  …  a_ni  …  a_mi

Таким образом, во всех конкатенациях п.4 имеются значения атрибутов, которые не равны друг другу. А из этого следует, что не одно из значений конкатенации не равно другому значению конкатенации, что и требовалось доказать.

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

Часть вопросов реализации изложенных требований к заполненным таблицам изложены в работах [6], часть вопросов рассмотрены в предыдущей главе.

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

В связи с этим для дальнейших выкладок будет использоваться таблица вида табл. 4.1, удовлетворяющая требованиям к реляционным таблицам.

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

Как правило, в литературе рассматриваются 4-е нормальные формы [1]. В несколько упрощенном виде они звучат следующим образом.

1. Атрибуты должны быть атомарны.

2. Все неключевые атрибуты зависят от ключевого атрибута.

3. Неключевые атрибуты не должны зависеть друг от друга.

4. Между атрибутами не должно быть множественных зависимостей.

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

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