Нормализация отношений

Рассмотренные ранее отношения можно демонстрировать не только в качестве объектных и связных отношений, но и как пример нормализованных отношений реляционной базы данных. Эти отношения получились не сразу. Сначала для решения задачи о хранении товаров на складах и магазинах должна была появиться, например, следующая таблица (Подразделение_товар):

В общем-то, в этой таблице нет ничего необычного, но она могла бы содержать строк 100 или 100000. Такую таблицу можно было бы записать, например в Excel и вести учет товаров на складах и в магазинах, разложив перед собой документы движения товаров (накладные). При этом анализировать данные такой «базы данных» в Excel не очень трудно — там имеются хорошие средства, в том числе сводные таблицы. Обновление же данных представляет определенные проблемы (хотя и разрешимые).

Хотя следовало бы показать «полную невозможность» размещения данных так, как это сделано в таблице Подразделение_товар, отметим, что в Excel для работы с такой таблицей имеется аппарат форм, которые позволяют находить и изменять данные способом, во многом похожим на работу с базой данных. Автоматически созданная для этой таблицы форма представлена на рис. 14.4. Обратите внимание на наименования кнопок этой формы. Не говоря уже о том, что данные можно редактировать (после нахождения при помощи кнопок Назад, Далее), их можно удалять и добавлять. Но самой, конечно, полезной кнопкой является кнопка Критерии. Именно при помощи этой кнопки можно найти в довольно большой таблице данные, имея о них некоторые сведения.

Рис. 14.4

Автоматически созданная форма для таблицы Подразделение_товар

Конечно, небольшие несвязанные между собой таблицы можно сопровождать таким способом. Однако, видимо, не очень удобно заносить новые сведения о товарах, если придется несколько раз набирать на клавиатуре сведения о магазине, куда поступает товар, о поставщике товара и д.т. Если при этом будут совершаться ошибки, то может получиться так, что товар будет «помещен» в новый ошибочный магазин или связан с несуществующим поставщиком. Многие другие ошибки при обслуживании таких таблиц могут возникать из-за неуверенной работы пользователя в Excel.

Этот пример предваряет введение в понятие нормализации отношений в реляционной базе данных, которые должны удовлетворять двум основным требованиям:

· между атрибутами не должно быть нежелательных функциональных зависимостей;

· группировка атрибутов должна обеспечивать минимальное дублирование данных.

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

Кодд выделил три нормальные формы[5] и предложил правила последовательного приведения отношений к нормализованному виду.

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

Рассмотрим, например, отношение Склад_товар (рис. 14.5), в котором сохраняются записи о складах и товарах поступающих на эти склады от некоторых поставщиков.

Рис. 14.5

Структура отношения Склад_товар

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

Рассмотрим зависимости атрибутов от первичного ключа, роль которого должны выполнять атрибуты Код_склада, Код_товара:

Рис. 14.6

Зависимости атрибутов от первичного ключа

Отметим, что указанные связи, вообще-то, могут определяться бизнес-правилами и быть отличными от представленных здесь.

Теперь — о типах зависимостей. На рис. 14.6 представлены три типа связей: слева — полные функциональные зависимости атрибутов от составного ключа (это «полезные» зависимости), справа — частичные (атрибут зависит от части составного ключа) и транзитивные зависимости (неключевые атрибуты зависят от неключевого атрибута).

Хотя иногда частичные зависимости используются для повышения производительности, следует учитывать, что отношения с такими зависимостями имеют недостаток — содержат избыточные данные и приводят к различным аномалиям. Например, если для одного и того же склада вводятся различные товары с одним поставщиком, то приходится для каждой записи повторять не только код склада, код товара, количество, цену и дату (что, вообще-то, необходимо в любом случае), но — наименование и телефон склада, наименование поставщика. Представьте себе такую ситуацию: на склад «Четвертого первомайского проезда» (клад имеет два телефонных номера) поступил всего один товар от поставщика «Волгоградский завод им. Куйбышева» (поставщик имеет два телефона); даже если поступивший товар уже ранее записывался в эту таблицу (возможно, для других складов), вам необходимо будет ввести примерно следующие записи:

3003; склад Четвертого первомайского проезда; [phone]; 112299993333; Мишка плюшевый, голубой, музыкальный; 300; 30.00; 20/08/2003; 4004; Волгоградский завод им. Куйбышева; (956) 777-88

3003; склад Четвертого первомайского проезда; [phone]; 112299993333; Мишка плюшевый, голубой, музыкальный; 300; 30.00; 20/08/2003; 4004; Волгоградский завод им. Куйбышева; (956) 777-88

3003; склад Четвертого первомайского проезда; [phone]; 112299993333; Мишка плюшевый, голубой, музыкальный; 300; 30.00; 20/08/2003; 4004; Волгоградский завод им. Куйбышева; (956) 777-86

3003; склад Четвертого первомайского проезда; [phone]; 112299993333; Мишка плюшевый, голубой, музыкальный; 300; 30.00; 20/08/2003; 4004; Волгоградский завод им. Куйбышева; (956) 777-86

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

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

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме и каждый неключевой атрибут функционально полно зависит от составного ключа. Таким образом, для приведения отношения к этой форме нужно поместить в отдельную таблицу данные, которые только частично зависят от первичного ключа. По Кодду следует построить проекцию[6] без атрибутов, которые находятся в частичной функциональной зависимости от составного ключа (рис. 14.7), а затем построить проекцию(и) на часть составного ключа и атрибуты, зависящие от этой части (рис.14.8).

Рис. 14.7

Проекция без атрибутов, которые находятся в частичной функциональной зависимости от составного ключа

Рис. 14.8

Проекции на часть составного ключа и атрибуты, зависящие от этой части ключа

В отношениях, представленных на рис. 14.8, определены первичные ключи, соответствующие отдельным элементам составного ключа исходного отношения.

Отношение находится в третьей нормальной форме, если оно находится во второй нормальной форме и в нем отсутствуют транзитивные зависимости неключевых атрибутов от ключа. Целью приведения отношения к третьей нормальной форме является удаление из него данных, не зависящих от первичного ключа (для устранения аномалий, связанных с транзитивными зависимостями).

В отношении Склад_товар имеются транзитивные зависимости (рис. 14.6). Для приведения отношения к третьей нормальной форме следует создать еще одно отношение, в которое войдут все неключевые атрибуты, связанные транзитивной зависимостью (рис. 14.9). При этом неключевой атрибут, от которого зависят остальные неключевые атрибуты, должен стать первичным ключом в новом отношении и внешним ключом в оригинальном отношении. Зависимые атрибуты из оригинального отношения удаляются (рис. 14.10).

Рис. 14.9

Отношение, в которое вошли неключевые атрибуты, связанные транзитивной зависимостью

Рис. 14.10

Зависимые атрибуты удаляются из оригинального отношения

Остается установить связи между полученными отношениями[7], как показано на рис. 14.11.

Рис. 14.11

Остается установить связи между полученными отношениями

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

Visual Basic (как и многие Visual-системы программирования) не является СУБД в том смысле, что его язык не содержит команд и функций обработки записей файлов данных. Однако Visual Basic для управления базами данных использует <$I[] процессор баз данных (database engine)> процессор баз данных (database engine), т.е. систему «отвечающую» за хранение и выборку данных[8]. Процессор баз данных для Visual Basic, называется Microsoft Jet и представляет собой систему, используемую несколькими программными продуктами фирмы Microsoft. Visual-системы программирования позволяют использовать при работе с базами данных язык SQL. Получается очень простая схема работы с базами данных: Visual Basic обеспечивает интерфейс, а SQL — работу с данными. Если же учесть, что Visual Basic — самая легкая в освоении система программирования, то можно сделать вывод, что самый простой способ быстро построить небольшое приложение для работы с базой данных — сделать это при помощи именно Visual Basic.

Дата добавления: 2015-08-26