Основные функции систем управления базами данных

1. Управление данными во внешней памяти,

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

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

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

3. Управление транзакциями.

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

4. Журнализация и восстановление БД после сбоев. Одно из основных требований к СУБД - надежное хранение данных во внешней памяти. Под надежностью хранения понимает­ся: СУБД должна быть в состоянии восстановить последнее согласо­ванное состояние БД после аппаратного или программного сбоя. Поддержание надежного хранения данных в БД требует избыточно­сти хранения данных, причем та их часть, которая используется для восстановления должна храниться особо надежно. Наиболее распро­страненный метод поддержания такой избыточности — это ведение журнала изменений базы данных. Во всех случаях придерживаются «упреждающей» записи в журнал (так называемый протокол Write Ahead Log). Эта стратегия заключается в том, что запись об измене­нии любого объекта БД должна попасть во внешнюю память журна­ла раньше, чем она попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

5. Поддержание языков БД.

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

Архитектура СУБД

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

• физическом размещении в памяти данных и их описаний;

• механизмах поиска запрашиваемых данных;

• проблемах, возникающих при одновременном запросе одних и тех же данных многими пользователями (прикладными программами);

• способах обеспечения защиты данных от некорректных обновлений и (или) несанкционированного доступа;

• поддержании баз данных в актуальном состоянии

• и множестве других функций СУБД.

При выполнении основных из этих функций СУБД должна использовать различные описания данных. А как создавать эти описания?

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

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

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

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

Рис. 1. Архитектура СУБД (уровни моделей данных).

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