функции СУБД

Плеханова» Экономический факультет
Кафедра вычислительной техники и информационных технологий

данными во внешней памяти
Эта функция включает обеспечение необходимых структур внешней

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

буферами оперативной памяти
СУБД обычно работают с БД значительного размера; этот

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

транзакциями
Транзакция - это последовательность операций над БД, рассматриваемых СУБД как

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

из основных требований к СУБД является надежность хранения данных во

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

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

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

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

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

восстановления после мягкого сбоя является состояние внешней памяти основной части

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

языков БД
Для работы с базами данных используются специальные языки, в

целом называемые языками баз данных.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). В качестве языка DML используется также язык создания запросов по образцу (QBE - Query by Example). Например, СУБД Access поддерживает SQL и QBE – создание запросов на выборку данных, изменение, удаление с помощью конструктора.
Язык SQL позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных системных таблиц-каталогов.

- это набор таблиц, в которых содержится информация, необходимая для

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

называют Data Base Engine), которое отвечает за управление данными во

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

компилятора языка БД является компиляция операторов языка БД в некоторую

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

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

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

обязанности АБД входит выполнение следующих функций:
1. Анализ предметной области, ее

описание, формулировка ограничений целостности, определение потребностей и статуса пользователей.
2. Проектирование структуры БД: определение состава и структуры информационных единиц БД, связей между ними.
3. Задание ограничений целостности при описании структуры БД и процедур обработки данных.
4. Первоначальная загрузка и ведение БД: разработка технологии загрузки и ведения БД, проектирование форм ввода, создание программных модулей.
5. Защита данных:
обеспечение парольного входа в систему;
определение прав доступа пользователей к данным;
выбор и создание программно-технических средств защиты данных;
тестирование средств защиты данных;
сбор статистики об использовании данных;
исследование случаев нарушения защиты данных;
обеспечение восстановления БД, ведение системных журналов.
6. Анализ обращений пользователей к БД.
7. Работа с конечными пользователями.
8. Работа над совершенствованием и динамическим развитием БД

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

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

называемых OLTP-приложений (On-Line Transaction Processing - оперативная обработка транзакций).
Типичными

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

много;
выполняются они одновременно (к системе может быть подключено несколько тысяч

одновременно работающих пользователей);
при возникновении ошибки, транзакция должна целиком откатиться и вернуть систему к состоянию, которое было до начала транзакции (не должно быть ситуации, когда деньги сняты со счета А, но не поступили на счет В).
Практически все запросы к базе данных в OLTP-приложениях состоят из команд вставки, обновления, удаления.
Запросы на выборку в основном предназначены для предоставления пользователям возможности выбора из различных справочников. Большая часть запросов, таким образом, известна заранее еще на этапе проектирования системы. Пример запроса: «есть ли свободные места в купе поезда Москва-Сочи, отправляющегося 20 августа в 23:15».
Критическим для OLTP-приложений является скорость и надежность выполнения коротких операций обновления данных. Чем выше уровень нормализации данных в OLTP-приложении, тем оно, как правило, быстрее и надежнее.
OLTP-системы требуют защиты от несанкционированного доступа, от нарушения целостности, аппаратных и программных сбоев

Analitical Processing - оперативная аналитическая обработка данных). Это обобщенный термин,

характеризующий принципы построения систем поддержки принятия решений (СППР) (Decision Support System - DSS), хранилищ данных (Data Warehouse), систем интеллектуального анализа данных (Data Mining). Такие системы предназначены для нахождения зависимостей между различными данными.
Приведем примеры запросов:
«как связан объем продаж товаров с характеристиками потенциальных покупателей»;
«каким будет объем продаж железнодорожных билетов в следующие 3 месяца с учетом сезонных колебаний»),
для проведения анализа "что если…".

OLAP-приложения оперируют с большими массивами данных, уже накопленными в OLTP-приложениях, взятыми из электронных таблиц или из других источников данных.

году «12 законов аналитической обработки в реальном времени»:
многомерность,
прозрачность,
доступность,

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

в систему новых данных происходит относительно редко крупными блоками (например,

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

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

а в ячейках самого гиперкуба хранятся собственно данные. Например, можно построить гиперкуб, измерениями которого являются: время (в кварталах, годах), тип товара и отделения компании, а в ячейках хранятся объемы продаж. Такой гиперкуб будет содержать данных о продажах различных типов товаров по кварталам и подразделениям. Основываясь на этих данных, можно отвечать на вопросы типа "у какого подразделения самые лучшие объемы продаж в текущем году?", или
"каковы тенденции продаж отделений Юго-Западного региона в текущем году по сравнению с предыдущим годом?"
Физически гиперкуб может быть построен на основе специальной многомерной модели данных (MOLAP - Multidimensional OLAP) или построен средствами реляционной модели данных (ROLAP - Relational OLAP).

системах OLAP достигается за счет применения мощной многопроцессорной ВТ, сложных

методов анализа и специальных хранилищ данных, накапливающих информацию из разных источников за большой период времени и обеспечивающих быстрый доступ к ней (Data Warehouse ).
В большинстве случаев сложный аналитический запрос невозможно сформулировать в терминах языка SQL, поэтому приходится применять специализированные языки, ориентированные на аналитическую обработку данных. К их числу можно отнести, например, язык Express 4GL (язык четвертого поколения - 4 Generation Language фирмы Oracle).

возникают проблемы эффективного использования их ресурсов. Для решения этих проблем

в состав распределенных OLTP-систем вводят дополнительный компонент – монитор транзакций (TPM – Transaction Processing Monitor).
Мониторы транзакций выполняют две основные функции:
динамическое распределение запросов в системе (выравнивание нагрузки);
оптимизация числа выполняемых серверных приложений.

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

удаленность серверов, их готовность, содержимое запроса. Реализуется функция выравнивания нагрузки

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

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

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

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

приложений.
Если это отношение превышает максимальное пороговое значение, то запускается дополнительная копия серверного приложения. Если это отношение падает ниже минимального порогового значения, то одна из копий завершается.
На рынке мониторов транзакций доступно довольно много программных продуктов:
CICS фирмы IBM;
TUXEDO фирмы USL;
ACSMS фирмы DEC;
TOP END фирмы NCR.