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

Ручные картотеки позволяют  успешно справляться с поставленными  задачами, если количество хранимых объектов, которые нужно только хранить  и извлекать, невелико. Однако они  совершенно не подходят для тех случаев, где нужно выполнить перекрестные связи или выполнить обработку сведений. Файловые системы были разработаны в ответ на потребность в получении более эффективных способов доступа к данным. Однако, вместо организации централизованного хранилища всех данных предприятия, был использован децентрализованный подход, при котором сотрудники каждого отдела работают со своими собственными данными и хранят их в своем отделе.

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

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

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

3.2. Потребности информационных  систем

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

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

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

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

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

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

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

3.3. Функции СУБД. Типовая  организация СУБД.

Как было показано ранее, традиционных возможностей файловых систем оказывается  недостаточно для построения даже простых информационных систем. Мы выявили несколько потребностей, которые не покрываются возможностями систем управления файлами: поддержание логически согласованного набора файлов; обеспечение языка манипулирования данными; восстановление информации после разного рода сбоев; реально параллельная работа нескольких пользователей. Можно считать, что если прикладная информационная система опирается на некоторую систему управления данными, обладающую этими свойствами, то эта система управления данными является системой управления базами данных (СУБД) [3].

3.3.1. Основные функции СУБД

Более точно, к числу функций  СУБД принято относить следующие [3]:

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

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

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

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

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

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

Во всех случаях придерживаются стратегии "упреждающей" записи в  журнал (так называемого протокола Write Ahead Log - WAL). Грубо говоря, эта стратегия  заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

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

5. Поддержка языков  БД. Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка - язык определения схемы БД (SDL - Schema Definition Language) и язык манипулирования данными (DML - Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, т.е. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, т.е. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные.

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

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