Архитектура субд. Реляционная модель данных

Пусть   – схема отношения  .   – схема отношения   после упорядочения имен атрибутов. Тогда

~             

Таким образом, для эквивалентных отношений  выполняются следующие условия:

·   Таблицы имеют одинаковое количество столбцов.

·   Таблицы содержат столбцы с одинаковыми наименованиями.

·   Столбцы с одинаковыми наименованиями содержат данные из одних и тех же доменов.

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

Все такие  таблицы есть различные изображения одного и того же отношения.            

Свойства  отношений. Свойства отношений непосредственно следуют из приведенного выше определения отношения. В этих свойствах в основном и состоят различия между отношениями и таблицами.

·   В отношении нет одинаковых кортежей.

·   Кортежи не упорядочены (сверху вниз).

·   Атрибуты не упорядочены (слева направо).

·   Все значения атрибутов атомарны.  

  

Рис. Схематическое изображение  отношения              

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

6. Проектирование реляционных баз данных.

     При проектирование реляционной БД должны быть решены следующие проблемы:

1) С учетом  семантики предметной области  необходимо наилучшим способом  представить объекты предметной  области в виде абстрактной  модели данных (даталогическое проектирование). Т.е. - определиться со схемой БД: из каких отношений должны состоять БД, какие атрибуты должны быть у этих отношений, каковы связи между отношениями.

2) Обеспечить  эффективность выполнения запросов  к базе данных (физическое проектирование  БД).            

После проведения этапа даталогического проектирования должны быть получены следующие результирующие документы:

·   Построение корректной схемы данных ориентируясь на реляционную модель данных.

·   Описание схемы БД в терминах выбранной СУБД.

·   Описание внешних моделей в терминах выбранной СУБД.

·   Описание декларативных правил поддержки целостности БД.

·   Разработка процедур поддержки семантической целостности БД.            

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

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

Проектирование  схемы БД можно выполнить двумя  методами:

·   Метод декомпозиции (разбиения) – исходное множество отношений, входящих в схему БД заменяется другим множеством отношений, являющихся проекциями исходных отношений! При этом число отношений возрастает.

·   Метод синтеза – компоновка схемы БД из заданных исходных элементарных зависимостей между объектами предметной области.            

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

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

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

В теории реляционных  БД обычно выделяют следующие нормальные формы:

первая нормальная форма (1NF);

·   вторая нормальная форма (2NF);

·   третья нормальная форма (3NF);

·   нормальная форма Байса-Кодда (BCNF);

·   четвертая нормальная форма (4NF);

·   пятая нормальная форма или форма проекции - соединения (5NF или PYNF).            

Основные  свойства нормальных форм:

·   каждая следующая нормальная форма в некотором смысле лучше предыдущей;

·   при переходе к следующей нормальной форме свойства предыдущих нормальных свойств сохраняются.             

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

7. Нормальные формы  отношений.            

В основе процесса нормализации лежит адекватное отражение  предметной области в виде таблиц, содержащих данные о моделируемом объекте, и возможность изменения состояния  базы данных с течением времени. Как  правило, из-за несоответствия модели данных предметной области могут  возникнуть аномалии, которые проявляются  при выполнении соответствующих  операций:

·   Аномалии вставки (INSERT) – хранение в одном отношении разнородной информации.

·   Аномалии обновления (UPDATE) –избыточность данных отношения из-за хранения разнородной.

·   Аномалии удаления (DELETE) – хранение разнородной информации в одном отношении.            

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

Нормализация – разбиение таблицы на несколько, которые обладают лучшими свойствами при обновлении, вставке и удалении данных. Т.е. нормализация представляет собой процесс последовательной замены таблицы ее полными декомпозициями до тех пор, пока все они не будут находиться в 5НФ, однако, на практике достаточно привести таблицы к НФБК.            

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

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

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

Заменить  , первичный ключ  , ФЗ 

на  , первичный ключ 

и  , первичный ключ  .            

2. Таблица  имеет первичный (возможный) ключ  , поле  , которое не является возможным ключом, но функционально зависит от  , а также – другое неключевое поле  , функционально зависящее от  :  . Рекомендуется сформировать таблицу содержащую   и   (  - первичный ключ), и   – удалить из первоначальной таблицы:

Заменить  , первичный ключ  ,

ФЗ 

на  , первичный ключ  ,

и  , первичный ключ  .            

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

Следует заметить, что для проведения таких операций первоначально следует иметь, в  качестве входных данных некоторые  «большие» (универсальные) отношения.            

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

По опр.1, любое отношение будет находиться в 1НФ, т.е. отношение, удовлетворяющее  свойствам отношений: в отношении  нет одинаковых кортежей; кортежи  не упорядочены; атрибуты не упорядочены  и различаются по наименованию; все  значения атрибутов атомарны.            

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

Если потенциальный  ключ является простым, то отношение  автоматически находится в 2НФ.            

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

Атрибуты  отношения называются взаимно-независимыми, если ни один из них не является функционально зависимым от другого.            

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

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

При приведении отношений при помощи алгоритма  нормализации к отношениям в 3НФ предполагается, что все отношения содержат один потенциальный ключ. Это не всегда верно. Бывают случаи, когда отношение  может содержать несколько ключей.             

Опр.4. Отношение   находится в нормальной форме Байса-Кодда (НФБК) тогда и только тогда, когда детерминанты всех функциональных зависимостей являются потенциальными ключами (либо - если любая функциональная зависимость между его палями сводится к полной функциональной зависимости от возможного ключа).