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

Функции и структура СУБД

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

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

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

В общем плане можно выделить следующиефункции, реализуемыеСУБД:

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

– организация и поддержание физической структуры данных во внешней памяти;

– организация доступа к данным и их обработка в оперативной и внешней памяти.

Организация и поддержание логической структуры данных (схемы базы данных) обеспечивается средствами модели организации данных. Модель данных определяется способом организации данных, ограничениями целостности и множеством операций, допустимых над объектами организации дан­ных. Соответственно модель данных разделяют на три составляющие — структурную, целостную и манипуляционную.
Известны три основные модели организации данных:

– иерархическая;

– сетевая;

– реляционная.

Организация структуры БД формируется исходя из следующих соображений:

адекватность описываемому объекту/системе - на уровне концептуальной и логической моделей;

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

Виды концептуальных и логических моделей БД:

– сетевые;

– иерархические;

– реляционные.

Реляционная база данных - база данных, основанная на реляционной модели. Слово "реляционный" происходит от английского "relation" (отношение).

Теория реляционных баз данных была разработана доктором Эдгаром Коддом из компании IBM в 1970 году и регламентируется теорией реляционной алгебры. В реляционных базах данных все данные представлены в виде простых таблиц, разбитых на строки и столбцы, на пересечении которых расположены данные. Запросы к таким таблицам возвращают таблицы, которые сами могут становиться предметом дальнейших запросов. Каждая база данных может включать несколько таблиц. Кратко особенности реляционной базы данных можно сформулировать следующим образом:

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

на пересечении каждого столбца и строчки стоит в точности одно значение;

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

запросы к базе данных возвращают результат в виде таблиц, которые тоже могут выступать как объект запросов;

строки в реляционной базе данных неупорядочены.

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

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

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

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

Организация доступа к данным и их обработка в оперативной и внешней памяти осуществляется через реализацию процессов, получивших название транзакций.Транзакцией называют последовательную совокупность операций, имеющую отдельное смысловое значение по отношению к текущему состоянию базы данных. Так, например, транзакция по удалению отдельной записи в базе данных последовательно включает определение страницы файла данных, содержащей указанную запись, считывание и пересылку соответствующей страницы в буфер оперативной памяти, собственно удаление записи в буфере ОЗУ, проверку ограничений целостности по связям и другим параметрам после удаления и, наконец, «выталкивание» и фиксацию в файле базы данных нового состояния соответствующей страницы данных.

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

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

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

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

Таким образом, функция «Организация доступа к данным и их обработка в оперативной и внешней памяти»реализуется через следующие механизмы: монитор транзакций,управление буферами оперативной памяти, журнализация.

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

– процессор описания и поддержания структуры базы данных;

– процессор запросов к базе данных;

– монитор транзакций;

– интерфейс ввода данных;

– интерфейс запросов;

– интерфейс выдачи сведений;

– генератор отчетов.

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

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

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

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

Рис. 7. Структура и взаимодействие компонент СУБД

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

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

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

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

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

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

Структура файлов и их взаимодействие в процессе функционирования СУБД представлена на рис. 8.

Рис. 8. Информационное взаимодействие в СУБД

Внутренняя схема баз данных

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

В общем плане внутренняя схема базы данных включает три основных компонента, представленные на рис. 9.

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

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

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

Как уже отмечалось, в состав автоматизированного банка данных АИС помимо самой базы данных входит и прикладной компонент, образуемый совокупностью интерфейсных элементов представления, ввода и обработки данных, типовых запро­сов и процедур обработки данных, а также «событий» и «правил», отражающих правила и специфику предметной области АИС (так называемые «правила бизнеса»). Соответственно во внутренней схеме БД выделяется специальная область, в кото­рой размещается информация по прикладному компоненту АИС.

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

Рис. 9. Cocтав внутренней схемы базы данных

Физические структуры данных

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

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

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

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

Рис. 10. Общий принцип организации внутренней схемы базы данных

Классификация СУБД

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

По архитектуре организации хранения данных:

локальные СУБД (все части локальной СУБД размещаются на одном компьютере);

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

Классификация СУБД по способу доступа к БД:

файл-серверные;

клиент-серверные;

трехзвенные;

встраиваемые.

Файл-серверные СУБД. Архитектура "файл-сервер" не имеет сетевого разделения компонентов диалога и использует компьютер для функции отображения, что облегчает построение графического интерфейса. "Файл-сервер" только извлекает данные из файлов, так что дополнительные пользователи добавляют лишь незначительную нагрузку на центральный процессор, и каждый новый клиент добавляет вычислительную мощность сети. Минус - высокая загрузка сети. На данный момент файл-серверные СУБД считаются устаревшими. Примеры: Microsoft Access, MySQL (до версии 5.0).

Клиент-серверные СУБД. Такие СУБД состоят из клиентской части (которая входит в состав прикладной программы) и сервера. Клиент-серверные СУБД, в отличие от файл-серверных, обеспечивают разграничение доступа между пользователями и меньше загружают сеть и клиентские машины. Сервер является внешней по отношению к клиенту программой, и по мере надобности его можно заменить другим. Недостаток клиент-серверных СУБД - в самом факте существования сервера (что плохо для локальных программ - в них удобнее встраиваемые СУБД) и больших вычислительных ресурсах, потребляемых сервером. Примеры: Firebird, Interbase, MS SQL Server, Oracle, DB2, PostgreSQL, MySQL (старше версии 5.0).

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

Встраиваемая СУБД - это, как правило, "библиотека", которая позволяет унифицированным образом хранить большие объемы данных на локальной машине. Доступ к данным может происходить через SQL либо через особые функции СУБД. Встраиваемые СУБД быстрее обычных клиент-серверных и не требуют установки сервера, поэтому востребованы в локальном ПО, которое имеет дело с большими объемами данных - например, геоинформационные системы (Geographic Informational System - GIS). Примеры: SQLite, BerkeleyDB, один из вариантов Firebird, один из вариантов MySQL.

Общепринятым стандартом языка работы с реляционными базами данных в настоящее время является язык структурированных запросов (Structured Query Language - SQL). Это универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. Вопреки существующим заблуждениям, SQL является информационно-логическим языком, а не языком программирования.

SQL основывается на реляционной алгебре. Язык SQL делится на три части:

операторы определения данных;

операторы манипуляции данными (Insert, Select, Update, Delete);

операторы определения доступа к данным.

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

управление данными во внешней памяти (на различных носителях);

управление данными в оперативной памяти;

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

поддержка языков БД (язык определения данных, язык манипулирования данными, язык определения доступа к данным).

Хранилища данных

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

Идея хранилищ данных оказалось востребованной, так как во многих видах государственной, деловой, научной, социальной деятельности необходимы тематически объединенные и исторически очищенные совокупности данных, при этом постоянно возрастала потребность:

в более дешевых данных;

в точных и структурированных данных;

в большей оперативности получения и обработки данных;

в интегрированных данных.

К концу 1980-х годов, когда была в полной мере осознана необходимость интеграции корпоративной информации и надлежащего управления этой информацией, появились технические возможности для создания соответствующих систем, которые первоначально были названы "хранилищами информации" (Information Warehouse - IW). И лишь в 1990-е годы, с выходом книги Уильяма (Билла) Инмона, хранилища получили свое нынешнее наименование "хранилища данных" (Data Warehouse - DW) [Inmon W.H. Building the Data Warehouse, QED/Wiley, 1991, 312 р.].

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

В основе концепции хранилищ данных лежат следующие основополагающие идеи:

интеграция ранее разъединенных детализированных данных (исторические архивы, данные из традиционных систем обработки документов, разрозненных баз данных, данные из внешних источников) в едином хранилище данных;

тематическое и временное структурирование, согласование и агрегирование;

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

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

Таблица. Реализация требований к данным помещаемым в хранилище.

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

Хранилище данных выполняет множество функций, но его основное предназначение - предоставление точных данных и информации в кратчайшие сроки и с минимумом затрат.

Понятие хранилище данных в первоначальном понимании было основано на понятии распределенной витрины данных (Distributed Data Mart - DDM). Поэтому в классическом исполнении хранилище данных было прежде всего репозиторием (сквозной базой данных) данных и информации предприятия.

Рис. 11. Схема организации данных в хранилище

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

Достоинствами архитектуры классического хранилища данных являются:

общая семантика;

централизованная, управляемая среда;

согласованный набор процессов извлечения и бизнес-логики использования;

непротиворечивость содержащейся информации;

легко создаваемые по шаблонам и наполняемые витрины данных;

единый репозиторий метаданных;

многообразие механизмов обработки и представления данных.

К недостаткам можно отнести большие затраты по реализации, высокую ресурсоемкость в масштабе всего предприятия, потребность в сложных сервисных системах, рискованный сценарий развития, когда все данные и метаданные находятся в одном репозитории и в неблагоприятном случае могут быть потеряны. Кроме того, при фильтрации, агрегировании и рафинировании "сырых" данных для такого хранилища обычно теряется очень много информации, которая может быть чрезвычайно полезной при бизнес-анализе. В связи с этим возникло понимание того, что хранилище, помимо механизмов размещения и извлечения данных (On Line Transactional Processing - OLTP), репозитория и витрин, должно иметь соответствующее пространство для организации "сырых" данных и их многомерного анализа в режиме реального времени (On Line Analytical Processing - OLAP).

СЛОЖНЫЕ СИСТЕМЫ