Система управления базой данных

Назначение и функции СУБД

Как уже было отмечено, традиционных возможностей файловых систем оказывается недостаточно для построения даже простых информационных систем (см. п.1.2.). Было выявлено несколько потребностей, которые не покрываются возможностями систем управления файлами:

· поддержание логически согласованного набора файлов;

· обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев;

· реально параллельная работа нескольких пользователей.

Можно считать, что система управления данными, обладающая перечисленными свойствами, является системой управления базами данных (СУБД).

Таким образом, СУБД играет центральную роль в функционировании автоматизированного банка данных. В общем случае СУБД – это набор программных средств, выполняющих следующие основные функции:

1. Обеспечение пользователей языковыми средствами определения и манипулирования данными.

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

3. Обеспечение защиты данных.

4. Обеспечение целостности данных. Вопрос о сохранении целостности данных имеет несколько аспектов, например:

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

· неправильное управление общими данными при коллективном доступе.

5. Управление транзакциями. Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, произведенные искомой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается в состоянии БД.

6. Непосредственное управление данными во внешней памяти.

7. Управление буферами оперативной памяти.

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

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

10. Обеспечение совместимости и развития. СУБД должна сохранять работоспособность при развитии программного и аппаратного обеспечения.

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

12. Поддержка как централизованных, так и распределенных по информационно-вычислительной сети БД.

Рассмотрим некоторые функции СУБД и соответствующие ее компоненты несколько подробнее.

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

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

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

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

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

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

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

Защита данных может рассматриваться с нескольких точек зрения, например:

· защита для обеспечения секретности связана с разрешением использования тех или иных данных, хранящихся в системе, только пользователям, имеющим на это право,

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

· защита от разрушения БД при сбоях оборудования предполагает наличие процедур копирования и восстановления (функция журнализации).

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

Обычно рассматриваются два возможных вида аппаратных сбоев:

· так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания),

· и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти.

Примерами программных сбоев могут быть:

· аварийное завершение работы СУБД (из-за ошибки в программе или некоторого аппаратного сбоя),

· аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной.

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

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

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

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

Самая простая ситуация восстановления - индивидуальный откат транзакции.

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

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

Управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти (индексов) как для хранения непосредственных данных, входящих в БД, так и для служебных целей, например, для убыстрения доступа к данным (см. пп. 7.2.3. - 7.2.7.).

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

Независимость данных. Важнейшими аспектами независимости данных являются:

· Логическая независимость данных. Способность механизмов СУБД поддерживать изменения логического представления данных таким образом, чтобы при этом было возможно сохранить неизменными пользовательские представления данных. В терминологии архитектурной модели ANSI/X3/SPARC это означает возможность вариации концептуальной схемы базы данных без необходимости изменений внешних схем.

· Физическая независимость данных. Способность механизмов СУБД поддерживать изменения физического представления данных таким образом, чтобы при этом было возможно сохранить неизменным логическое их представление. В терминологии архитектурной модели ANSI/X3/SPARC это означает возможность вариации внутренней схемы базы данных без необходимости изменений концептуальной схемы.