Понятие реляционной базы данных

 

Датой рождения реляционной теории баз данных можно считать 6 июня 1970 г., когда сотрудник фирмы IBM доктор Э. Кодд, опубликовал статью «Реляционная модель данных для больших коллективных банков». Именно в этой статье был впервые использован термин «реляционная модель данных». Э.Кодд предложил использовать для обработки данных аппарат теории множеств и показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.).

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

Пример 3.1. На рис.3.1 показаны таблицы базы данных, построенные с помощью инфологической модели базы данных "Клиенты" рис.2.4.

Реляционная база данных обладает следующими основными свойствами:

1. Каждая таблица состоит из однотипных строк и имеет уникальное имя.

2. Строки имеют фиксированное число полей.

3. В каждой позиции таблицы на пересечении строки и столбца всегда имеется в точности одно значение или ничего.

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

5. Столбцам таблицы присваиваются имена, и в каждом из них размещаются однородные значения данных.

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

7. При выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию.

 

Цели проектирования

 

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

Предположим, что проектирование базы данных "Клиенты" (см.
рис. 2.4) начинается с выявления атрибутов и подбора данных, образец которых показан в табл. 3.1. Особо отметим, что для иллюстративности табл. 3.1 содержит не все данные, которые необходимо хранить в базе. Полный же перечень всех данных содержится в п.2.6.

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

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

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

1. Избыточность. Данные практически всех столбцов многократно повторяются.

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

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

4. Аномалии удаления. В нашем случае при удалении клиентов из БД может быть утеряна полезная информация о городах или регионах.

 

 

Вид деятельности № Наименование 1   Продукты питания 2   Упаковочные материалы 3   Безалкогольные напитки 4 Слабоалкогольные напитки

Тип региона № Наименование Обозначение 1 Область обл. 2 Край кр. 3 Республика респ. 4 Автономный округ АО

Тип населенного пункта № Наименование Обозначение 1 город г. 2 станица ст-ца 3 поселок город. типа пгт 4 село с.

Регион № Наименование №ТР 1 Адыгея 3 2 Краснодарский 2 3 Карачаево-Черкесская 3 4 Ростовская 1

Населенный пункт № Наименование №рег №ТНП 1 Ростов-на-Дону 4 1 2 Новочеркасск 4 1 3 Крыловская 2 2 4 Донской 4 3

Должность № Наименование 1   Директор 2   Менеджер 3   Заместитель директора 4 Старший менеджер

Субъект № ФИО 1   Иванов Александр Петрович 2   Петров Александр Иванович 3   Александров Иван Петрович 4 Сидорова Наталья Николаевна

Email №кл Наименование 1   [email protected] 1   [email protected] 3   info@bk_km.ru 3 [email protected]

Представитель №суб №кл №дол 1 1 1 2 1 2 3 2 1 4 2 4

Тип деятельности № Наименование 1   Производство 2   Посредничество 3   Оптовая торговля 4 Розничная торговля

Деятельность №ВД №ТД №кл 3 1 1 3 2 1 3 3 1 4 1 1

Клиенты № Наименование №НП Адрес Полное наименование Почтовый индекс Примечание 1 Молоко ООО 2 ул. Ленина, 4 ООО Молоко 223322   2 Рога и копыта ООО 1 пр. Мира, 2   221122 перезвонить директору 3 Звездочка 3 ул. Мира, 1   224422   4 1000 и 1 бутылка 4 пл. Лермонтова, 3/2 Алкомаркет «1000 и 1 бутылка» 122211

Рис. 3.1. Таблицы БД «Клиенты»

 

Таблица 3.1

Данные, хранящиеся в БД «Клиенты»

Наименование	Населенный пункт	Регион	Тип деятельности	Вид деятельности
Молоко ООО	Новочеркасск	Ростовская	Производство Посредничество Оптовая торговля	Безалкогольные напитки
Рога и Копыта ООО	Ростов-на-Дону	Ростовская	Посредничество Оптовая торговля Розничная торговля	Слабоалкогольные напитки
Звездочка	Крыловская	Краснодарский	Производство Оптовая торговля	Продукты питания
1000 и 1 бутылка	Донской	Ростовская	Оптовая торговля Розничная торговля	Слабоалкогольные напитки Безалкогольные напитки

 

Таблица 3.2

Универсальное отношение БД «Клиенты»

Наименование	Населенный пункт	Регион	Тип деятельности	Вид деятельности
Молоко ООО	Новочеркасск	Ростовская	Производство	Безалкогольные напитки
Молоко ООО	Новочеркасск	Ростовская	Посредничество	Безалкогольные напитки
Молоко ООО	Новочеркасск	Ростовская	Оптовая торговля	Безалкогольные напитки
Рога и Копыта ООО	Ростов-на-Дону	Ростовская	Посредничество	Слабоалкогольные напитки
Рога и Копыта ООО	Ростов-на-Дону	Ростовская	Оптовая торговля	Слабоалкогольные напитки
Рога и Копыта ООО	Ростов-на-Дону	Ростовская	Розничная торговля	Слабоалкогольные напитки
Звездочка	Крыловская	Краснодарский	Производство	Продукты питания
Звездочка	Крыловская	Краснодарский	Оптовая торговля	Продукты питания
1000 и 1 бутылка	Донской	Ростовская	Оптовая торговля	Слабоалкогольные напитки
1000 и 1 бутылка	Донской	Ростовская	Розничная торговля	Слабоалкогольные напитки
1000 и 1 бутылка	Донской	Ростовская	Оптовая торговля	Безалкогольные напитки
1000 и 1 бутылка	Донской	Ростовская	Розничная торговля	Безалкогольные напитки

 

 

Нормальные формы

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

Таблица, в которой на пересечении каждой строки и столбца всегда находится единственное атомарное значение или ничего, называется нормализованной.

Теория нормализации основывается на наличии той или иной зависимости между полями таблицы. Определены два вида таких зависимостей: функциональные и многозначные.

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

Пример 3.2. В таблице «Тип населенного пункта», представленной на рис. 3.1, поля «Наименование» и «Обозначение» функционально зависят от ключевого поля «№».

Полная функциональная зависимость. Поле В находится в полной функциональной зависимости от составного поля А, если оно функционально зависит от А и не зависит функционально от любого подмножества поля А.

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

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

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

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

Таблица находится в нормальной форме Бойса-Кодда, если и только если любая функциональная зависимость между его полями сводится к полной функциональной зависимости от возможного ключа.

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

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

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

 

Процесс нормализации

 

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

Процесс нормализации основан на том, что единственной функциональной зависимостью в любой таблице должна быть зависимость вида K-F, где K – первичный ключ, а F – некоторое другое поле.

При проведении нормализации таблиц, в которые введены цифровые (или другие) заменители составных и (или) текстовых первичных и внешних ключей, следует подменять их на исходные ключи, а после окончания нормализации снова восстанавливать. Если воспользоваться этой рекомендацией, то необходимо рассмотреть лишь два случая:

1. Таблица имеет составной первичный ключ, например, вида (К₁, К ₂), и включает также поле F, которое функционально зависит от части этого ключа, например, от К ₂, но не от полного ключа. В этом случае рекомендуется сформировать другую таблицу, содержащую К ₂ и F (первичный ключ – К₂), и удалить F из первоначальной таблицы.

2. Таблица имеет: первичный (возможный первичный) ключ К; не являющееся возможным ключом поле F1, которое функционально зависит от К, и другое неключевое поле F2, которое функционально зависит от F1. В этом случае формируется новая таблица, содержащая F1 и F2, с первичным ключом F1, и F2 удаляется из первоначальной таблицы.

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

Пример 3.4. Как отмечалось в п.2.4, желательно, чтобы в качестве первичного использовался несоставной целочисленный ключ. Для этого введем в таблице «Клиенты» (см. рис. 3.2) целочисленный кодификатор «№» и примем его за первичный ключ. В результате этого получим: поле «Наименование» зависит от «№», а поле «Населенный пункт» от поля «Наименование». Разобьем исходную таблицу на две обладающие лучшими свойствами таблицы – «Клиенты» и «Населенные пункты». Вводя в таблице «Населенный пункт» целочисленный кодификатор «№» и принимая его за первичный ключ, а в таблице «Клиенты» внешний ключ «№НП» для ассоциации с таблицей «Населенный пункт», получим таблицы, представленные на рис.3.3.

 

Клиенты Наименование Населенный пункт №рег Тип деятельности Вид деятельности Молоко ООО Новочеркасск 4 производство   безалкогольные напитки Рога и Копыта ООО Ростов-на-Дону 4 Посредничество   Слабоалкогольные напитки Звездочка Крыловская 2 Производство Продукты питания 1000 и 1 бутылка Донской 4 Оптовая торговля   Слабоалкогольные напитки

Регион № Наименование 1 Адыгея 2 Краснодарский 3 Карачаево-Черкесская 4 Ростовская

Рис. 3.2. Таблицы, получаемые после первого шага нормализации

 

Для любой заданной таблицы, повторяя применение двух рассмотренных правил, во всех практических ситуациях можно получить в итоге множество таблиц, которые находятся в нормальной форме Бойса-Кодда и не содержат каких-либо функциональных зависимостей вида, отличного от K->F.

 

 

Клиенты № Наименование №НП Тип деятельности Вид деятельности 1 Молоко ООО 2 производство безалкогольные напитки 2 Рога и Копыта ООО 1 Посредничество Слабоалкогольные напитки 3 Звездочка 3 Производство Продукты питания 4 1000 и 1 бутылка 4 Оптовая торговля   Слабоалкогольные напитки

Регион № Наименование 1 Адыгея 2 Краснодарский 3 Карачаево-Черкесская 4 Ростовская

Населенный пункт № Наименование №рег 1 Ростов-на-Дону 4 2 Новочеркасск 4 3 Крыловская 2 4 Донской 4

Рис. 3.3. Таблицы, получаемые после второго шага нормализации