и связи более высоких степеней
Реляционная модель данных
– Непосредственно поддерживает бинарные связи и связи более высоких степеней типа 1:1 и 1:М, а также рекурсивные связи типа 1:1 и 1:М.
– Бинарные связи более высоких степеней типа М:N поддерживаются с помощью декомпозиции.
– Рекурсивные связи типа М:N поддерживаются с помощью декомпозиции и Типы записей связанны друг с другом символически с помощью конструкции «первичный/внешний ключ».
– В реляционной модели поддерживается целостность на уровне ссылок.
– Обладает гибкостью по отношению к изменению требований к данным и методам доступа
– Доступ к типам записей осуществляется с помощью команд реляционной алгебры или реляционного исчисления. Эти команды могут быть вложенными, что позволяет создавать сложные запросы.
Сводная характеристика систем баз данных
|
Критерий |
CODASYL (сетевая система) |
IMS (иерархическая система) |
Реляционная система |
|
Период создания |
1960-1970 годы |
1960-1970 годы |
1960-настоящее время |
|
Над чем ведется работа сейчас |
Разделение физических и логических концепций |
Обеспечение взаимодействия с другими системами и типами СУБД |
Повышение производительности, обеспечение совместимости с SQL2, а также добавление объектно-ориентированных компонентов |
|
Реализация |
Записи и указатели |
Обычно записи и указатели, но могут быть и просто физически смежные записи |
Записи со значениями, которые могут использоваться как логические указатели |
|
Базовая физическая структура данных |
Сеть, в которой записи связаны друг с другом в один набор с помощью указателей. Могут содержать встроенные в них указатели |
Обобщенная древовидная структура, в которой один тип записи образует корень, а все другие типы записей - зависимые от корня узлы |
Двумерная таблица |
|
Общая структура файлов и методы доступа к ним |
Прямые методы доступа и индексно-последовательные методы доступа (включая метод VSAM) |
Методы доступа HIDAM, HDAM, HISAM, HSA М. Варианты прямого доступа и индексно-последователь-ных методов доступа (включая метод VSAM) |
Разные методы доступа от последовательных файлов с индексами и методов прямого доступа вплоть до сложных древовидных поисковых структур |
|
Логическая структура данных |
Набор, в котором один тип записи-владельца может быть связан со многими типами записей-членов. Сложные сети создаются с помощью типов наборов |
Обобщенная древовидная структура |
Набор двумерных таблиц |
|
Поддерживаемые типы связей |
Связи типа 1:1 и 1:М.Связи типа M:N и рекурсивные связи поддерживаются с помощью декомпозиции. С ними проще всего работать в иерархической системе |
Связи типа 1:1и 1:М. Связи типа M:N обычно поддерживаются с помощью логических указателей, которые связывают разные физические структуры данных. Рекурсивные связи поддерживаются с помощью декомпозиции и дублирования |
Связи типа 1:1 и 1:М.Связи типа M:N и рекурсивные поддерживаются с помощью декомпозиции |
|
Поддержка целостности на уровне ссылок для связей типа «родитель-потомок» |
Обеспечивается средствами СУБД с использованием правил вставки и сохранения для структуры наборов. Если записи-члены закреплены за записью-владельцем, то удаление записи-владельца приводит к каскадному удалению записей-членов. Если записи-члены не обязательно являются частью набора, то удаление записи-владельца эквивалентно заданию неопределенной связи (NULL). Можно запрограммировать и другие варианты действий. Обычно внешние ключи в типах записей не требуются |
Обеспечивается средствами СУБД с использованием зависимостей в древовидной структуре. То есть при удалении корня дерева (или поддерева)будут удалены все зависящие от него узлы, что эквивалентно каскадному удалению. Обычно в типах записей внешние ключи не нужны. Сложности могут возникнуть в случаях,когда связи M:N представляются с помощью логических указателей |
Поддержка варьируется от разработки процедур, правил или триггеров, используемых непосредственно средствами СУБД, вплоть до процедур, реализуемых в прикладных программах. Стандарт SQL92 требует реализации этой функции механизмами самой СУБД |
|
Логическая независимость от данных |
Концептуальная схема моет быть расширена без изменения подсхем. При перестройке или удалении из концептуальной схемы типов записи, поля набора потребуется ввести поправки только в те представления, в которых они используются |
Полностью аналогична CODASYL-системам |
Полностью аналогична CODASYL-системам |
|
Физическая независимость от данных |
Концептуальная схема должна быть изменена в соответствии с изменениями структуры хранения в тех местах схемы, в которых описаны детали физического хранения. Это может вызвать необходимость изменения прикладных программ. Следовательно, реализация макета базы данных может значительно усложниться |
При изменении структуры хранения может потребоваться изменить концептуальную схему (ОБД) и внести поправку в логику обработки данных в приложениях. Для упрощения процесса изменения структур хранения предусмотрены специальные утилиты |
В тех случаях когда не допускается выбор из нескольких возможных физических структур данных, некоторые СУБД при необходимости позволяют определять различные структуры файлов и вторичных индексов |
|
Гибкость при изменении приложений |
Новые или изменённые приложения могут не обладать достаточной производительностью, потому что база данных структурирована для существовавших ранее приложений. Поэтому может оказаться не возможным эффектно поддерживать все требуемые приложения |
Новые или изменённые приложения могут быть неэффективны, потому что базовые структуры подогнаны под исходные приложения. Изменить базовую структуру так, чтобы обеспечить удовлетворительную работу базы данных со всеми требуемыми приложениями,достаточно сложно или даже вообще не возможно. Вероятно, для этого потребуется создать дополнительные структуры |
Настройка для работы с новыми или изменёнными приложениями может быть выполнена без особых затруднений. В СУБД, "" поддерживающей выбор структуры файлов,для разных таблиц могут быть выбраны самые подходящие структуры данных |
|
Простота проектирования |
Вероятно, потребуется квалифицированная помощь, особенно при определении необходимых структур данных и при разработке связанных с ними прикладных программ |
Проектирование могут выполнить только опытные специалисты-эксперты |
Большинство пользователей (включая конечных пользователей) легко поймут логическую структуру данных,а потому смогут спроектировать базу данных и отобразить её на физические структуры. К сожалению, недостаточное знание методов проектирования баз данных может привести к созданию слабых, неэффективных и негибких макетов |
|
Доступ к базе данных |
Стандартные методы доступа посредством API: приложение содержит встроенные вызовы процедур для работы с СУБД, команды обрабатывают записи последовательно, по одной, хотя потенциально они могут оказывать влияние и на другие записи. Дополнительные программные конструкции необходимы для навигации по базе данных и обработки наборов записей |
Здесь также доступ осуществляется исключительно посредством API. Команды обрабатывают записи по одной, но при этом они могут влиять и на зависимые записи. Благодаря использованию специальных команд навигации по базе данных пользователь может перемещаться к разным местам иерархической структуры. Для обработки наборов записей могут потребоваться специальные программные конструкции |
Доступ может варьироваться от использования API до таких интерактивных языков, как SQL или QBE. Языки запросов позволяют конечным пользователям опрашивать базу данных в произвольной манере. Кроме того, SQL-команды могут внедряться в прикладные программы |
|
Стандарты |
Для CODASYL-совместимой модели данных существует набор стандартных концепций,хотя между разными реализациями есть некоторые различия |
Для иерархической модели данных не существует строгого набора стандартных концепций, а реализации этой модели не соответствуют какому-либо особому стандарту |
Для реляционных моделей данных существует набор стандартных концепций, хотя между разными реализациями есть некоторые различия |
