Выбор СУБД для построения информационных систем

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

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

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

3.3.2. Типовая организация современной  СУБД

Естественно, организация типичной СУБД и состав ее компонентов  соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД [3]:

• управление данными во внешней памяти;
• управление буферами оперативной памяти;
• управление транзакциями;
• журнализация и восстановление БД после сбоев;
• поддержание языков БД.

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

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

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

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

 

3.4. Ранние подходы к организации  БД.

 

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

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

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

Начнем с некоторых наиболее общих характеристик ранних систем:

1. Эти системы активно использовались в течение многих лет, дольше, чем используется какая-либо из реляционных СУБД. На самом деле некоторые из ранних систем используются даже в наше время, накоплены громадные базы данных, и одной из актуальных проблем информационных систем является их использование совместно с современными системами.
2. Все ранние системы не основывались на каких-либо абстрактных моделях. Как мы упоминали, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
3. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
4. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
5. После появления реляционных систем большинство ранних систем было оснащено "реляционными" интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.

3.4.1. Иерархические системы

Типичным представителем (наиболее известным и распространенным) является Information Management System (IMS) фирмы IBM. Первая версия появилась в 1968 г. До сих пор поддерживается много баз данных, что создает существенные проблемы с переходом как на новую технологию БД, так и на новую технику.

1. Иерархические структуры  данных. Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева.

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

Рис. 3.1 Пример типа дерева (схемы иерархической  БД) [3]:

 

Здесь “Отдел” является предком  для “Начальник” и “Сотрудники”, а “Начальник” и “Сотрудники” - потомки “Отдел”. Между типами записи поддерживаются связи.

База  данных с такой схемой могла бы выглядеть следующим образом (мы показываем один экземпляр дерева):

Рис. 3.2. Пример схемы базы данных [3]

 

Все экземпляры данного типа потомка с общим экземпляром типа предка называются близнецами. Для БД определен полный порядок обхода - сверху вниз, слева направо.

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

• Найти указанное дерево БД (например, отдел 310);
• Перейти от одного дерева к другому;
• Перейти от одной записи к другой внутри дерева (например, от отдела - к первому сотруднику);
• Перейти от одной записи к другой в порядке обхода иерархии;
• Вставить новую запись в указанную позицию;
• Удалить текущую запись.

3. Ограничения целостности. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя. Заметим, что аналогичное поддержание целостности по ссылкам между записями, не входящими в одну иерархию, не поддерживается (примером такой "внешней" ссылки может быть содержимое поля “Каф_Номер” в экземпляре типа записи “Куратор”).

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

 

 

Рис. 3.3. Примером представления БД [3]

3.4.2. Сетевые системы

Типичным представителем является Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования  на машинах основного класса фирмы IBM под управлением большинства операционных систем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL), организации, ответственной за определение языка программирования Кобол. Отчет DBTG был опубликован в 1971 г., а в 70-х годах появилось несколько систем, среди которых IDMS.

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

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

Тип связи определяется для двух типов записи: предка и потомка. Экземпляр  типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка. Для данного типа связи L с типом записи предка P и типом записи потомка C должны выполняться следующие два условия:

• Каждый экземпляр типа P является предком только в одном экземпляре L;
• Каждый экземпляр C является потомком не более, чем в одном экземпляре L.

На формирование типов связи  не накладываются особые ограничения; возможны, например, следующие ситуации:

1. Тип записи потомка в одном типе связи L1 может быть типом записи предка в другом типе связи L2 (как в иерархии).
2. Данный тип записи P может быть типом записи предка в любом числе типов связи.
3. Данный тип записи P может быть типом записи потомка в любом числе типов связи.
4. Может существовать любое число типов связи с одним и тем же типом записи предка и одним и тем же типом записи потомка. Если L1 и L2 - два типа связи с одним и тем же типом записи предка P и одним и тем же типом записи потомка C, то правила, по которым образуется родство, в разных связях могут различаться.
5. Типы записи X и Y могут быть предком и потомком в одной связи и потомком и предком - в другой.
6. Предок и потомок могут быть одного типа записи.

 

Рис. 3.4. Простой пример сетевой схемы БД [3].

 

2. Манипулирование данными. Примерный набор операций может быть следующим:

Найти конкретную запись в наборе однотипных записей (инженера Сидорова);

• Перейти от предка к первому потомку по некоторой связи (к первому сотруднику отдела 310);
• Перейти к следующему потомку в некоторой связи (от Сидорова к Иванову);
• Перейти от потомка к предку по некоторой связи (найти отдел Сидорова);
• Создать новую запись;
• Уничтожить запись;
• Модифицировать запись;
• Включить в связь;
• Исключить из связи;
• Переставить в другую связь и т.д.

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

3.4.3.  Достоинства и недостатки  ранних СУБД

Сильные места ранних СУБД: