2 Отсутствие упорядоченности кортежей

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

3 Отсутствие упорядоченности атрибутов

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

4 Атомарность значений атрибутов

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

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

В реляционной БД существуют следующие типы отношений:

- Один ко многим. Различают 2 разновидности таких отношений: с жестким требованием и где жесткое требование отсутствует. Жесткое требование – когда всякой записи в родительской таблице должна соответствовать запись в дочерней.

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

- Один к одному. Имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице. Это отношение используется, чтобы не загромождать таблицы БД второстепенной информацией.

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

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

1НФ: Требует, чтобы каждое поле таблицы БД было неделимым и не содержало повторяющихся групп. Неделимость поля означает, что содержащиеся в нем данные не должны делиться на более мелкие (например, ФИО). Повторяющиеся поля – это поля, содержащие одинаковые по смыслу значения (товар1, товар2).

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

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

Так же к реляционным БД применяется требование целостности.

Целостность сущностей – каждая запись каждой таблицы д.б. отличимой от каждой записи этой же таблицы.

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

Для обеспечения целостности по ссылкам существует три подхода:

- Запрещается производить удаление записи, на которую существует ссылка. Сначала нужно удалить ссылающиеся записи или изменить значение внешнего ключа.

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

- Каскадное удаление – при удалении записи из таблицы, на которую ведется ссылка, автоматически удаляются все ссылающие записи.

Достоинства:

Широкое распространение РМД объясняется в первую очередь простотой представления и формирования БД, универсальностью и удобством обработки данных, которая осуществляется с помощью декларативного языка запросов SQL (Structured Query Language).

• Структурная независимость – изменения в структуре БД не влияют на доступ к данным;

• Концептуальная простота – возможность целиком сосредоточиться на логическом представлении данных;

• Простота проектирования, реализации, управления и использования – стало проще проектировать БД и управлять ее содержимым;

• Нерегламентированные запросы – SQL- стандартный язык запросов ,язык четвертого поколения, дает возможность пользователям определить что необходимо сделать без указания того как надо сделать;

• Мощная система управления БД – решает сложные задачи.

• Обработка данных в отношениях осуществляется с помощью операций реляционной алгебры.

Недостатки:

Моделирование ПО в рамках РМД создаёт некоторые сложности, т.к. в РМД нет специальных средств для отображения различных типов связей. Отсутствие множественных связей, например, "многие ко многим", вызывает увеличение объёма хранимой (дублируемой) информации. Отсутствие возможности указания типов связей (например, "работает" или "имеет"), приводит к тому, что семантика связей в принципе не может быть отражена в РМД и зависит от того, как связь интерпретируется приложениями.

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

В РМД нет понятий режима включения и класс членства, поэтому набор средств описания ограничений целостности очень мал.

• Существенные требования к оборудованию и системному программному обеспечению – РСУБД скрывает от пользователя всю сложность системы и требует значительных системных и программных ресурсов

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

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

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