Организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций (п.5.1).
Логически в современной реляционной СУБД можно выделить:
1. Внутреннюю часть - ядро СУБД (часто его называют Data Base Engine);
2. Компилятор языка БД (обычно SQL);
3. Подсистему поддержки времени выполнения;
4. Набор утилит.
В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, недоступным для пользователя напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения , представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
В отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
С точки разделения функций между различными компонентами можно выделить два альтернативных подхода к организации реляционной СУБД:
1. Наличие интегрированной подсистемы управления данными, транзакциями и журнализацией (System R),
2. Управление данными отделено от управления транзакциями и журнализацией (Ingres).
У обоих этих подходов имеются свои преимущества и недостатки.
Первый подход позволяет использовать более эффективные методы за счет совместного решения проблем физической и логической синхронизации, использовании общих протоколов при управлении буферами и журнализации и т.д. Но при этом в некотором смысле подсистема нижнего уровня становится монолитом; при самой удачной ее структуризации компоненты остаются связанными общими протоколами взаимодействия. Непродуманные локальные изменения одного компонента могут привести к фатальным последствиям для всей системы.
Второй подход позволяет упростить структуру системы и сделать ее более гибкой, но это возможно только за счет огрубления алгоритмов: применения более грубых методов управления транзакциями; жестких протоколов журнализации и т.д.
Вопросы к зачету
Файл, файловая система. Классификация файловых систем. Основные подходы к защите файловых систем.
С точки зрения прикладной программы файл - это именованная область внешней памяти, в которую можно записывать и из которой можно считывать данные. Система управления файлами берет на себя распределение внешней памяти, отображение имен файлов в соответствующие адреса внешней памяти и обеспечение доступа к данным.
Термин файловая система (file system) используется для обозначения программной системы, управляющей файлами, и архива файлов, хранящегося во внешней памяти.
Изолированные файловые системы - каждый архив файлов (полное дерево каталогов) целиком располагался на одном дисковом пакете или логическом диске (как на винде), полное имя файла начинается с имени дискового устройства.
Централизованная (как в Multics) - обеспечивалась возможность представлять всю совокупность каталогов и файлов в виде единого дерева. Полное имя файла начиналось с имени корневого каталога, и пользователь не обязан был заботиться об установке на дисковое устройство каких-либо конкретных дисков (то есть один файл мог быть разнесен на диск, дискету и два винта).
Смешанная (*nix) - создается файловая система, а потом еще используется mount для подсоединения других устройств со своими файловыми каталогами.
Защита при многопользовательском режиме: мандатный и дискреционный подходы. Мандатный : каждый пользователь имеет отдельный мандат для работы с каждым файлом или не имеет его, много дополнительной информации.
Дискреционный - каждому зарегистрированному пользователю соответствует пара целочисленных идентификаторов: идентификатор группы, к которой относится пользователь, и его собственный идентификатор. Соответственно, при каждом файле хранится полный идентификатор пользователя (собственный идентификатор плюс идентификатор группы), который создал этот файл, и помечается, какие действия с файлом может производить он сам, какие действия с файлом доступны для остальных пользователей той же группы и что могут делать с файлом пользователи других групп. Для каждого файла контролируется возможность выполнения трех действий: чтение, запись и выполнение. Собственно, так в *nix.
СУБД. Основные функции СУБД. Типовая организация современной СУБД.
СУБД (система управления базами данных) - информационная система, которая обеспечивает сторонним программам доступ к структурированным данным, обеспечивая при этом некоторые функции:
- управление логической согласованностью и целостностью данных во внешней памяти;
- управление буферами оперативной памяти (работать напрямую с внешним дисковым устройством долго);
- управление транзакциями (с определенными свойствами, вопрос 3);
- журнализация и восстановление БД после сбоев;
- поддержание языков БД (универсальныйязыкзапросов, который может быть использован из внешней программы и позволит не углубляться во внутреннюю структуру хранения данных, например SQL).
Типовая организация современной СУБД. Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения , набор утилит . В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию.
Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения , представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
В отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д.
Естественно, организация типичной СУБД и состав ее компонентов соответствует рассмотренному нами набору функций. Напомним, что мы выделили следующие основные функции СУБД:
· управление данными во внешней памяти;
· управление буферами оперативной памяти;
· управление транзакциями;
· журнализация и восстановление БД после сбоев;
· поддержание языков БД.
Логически в современной реляционной СУБД можно выделить наиболее внутреннюю часть - ядро СУБД (часто его называют Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит. В некоторых системах эти части выделяются явно, в других - нет, но логически такое разделение можно провести во всех СУБД.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить такие компоненты ядра (по крайней мере, логически, хотя в некоторых системах эти компоненты выделяются явно), как менеджер данных, менеджер буферов, менеджер транзакций и менеджер журнала. Как можно было понять из первой части этой лекции, функции этих компонентов взаимосвязаны, и для обеспечения корректной работы СУБД все эти компоненты должны взаимодействовать по тщательно продуманным и проверенным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователям напрямую и используемым в программах, производимых компилятором SQL (или в подсистеме поддержки выполнения таких программ) и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры "клиент-сервер" ядро является основной составляющей серверной части системы.
Основной функцией компилятора языка БД является компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является то, что языки этих систем (а это, как правило, SQL) являются непроцедурными, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не является процедурой, а лишь описывает в некоторой форме условия совершения желаемого действия (вспомните примеры из первой лекции). Поэтому компилятор должен решить, каким образом выполнять оператор языка прежде, чем произвести программу. Применяются достаточно сложные методы оптимизации операторов, которые мы подробно рассмотрим в следующих лекциях. Результатом компиляции является выполняемая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути дела, интерпретатор этого внутреннего языка.
Наконец, в отдельные утилиты БД обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например, загрузка и выгрузка БД, сбор статистики, глобальная проверка целостности БД и т.д. Утилиты программируются с использованием интерфейса ядра СУБД, а иногда даже с проникновением внутрь ядра.
2.3. Пример: System R
Основными целями разработчиков System R являлись следующие:
· обеспечить ненавигационный интерфейс высокого уровня пользователя с системой, позволяющий достичь независимости данных и дать возможность пользователям работать максимально эффективно;
· обеспечить многообразие допустимых способов использования СУБД, включая программируемые транзакции, диалоговые транзакции и генерацию отчетов;
· поддерживать динамически изменяемую среду баз данных, в которой отношения, индексы, представления, транзакции и другие объекты могут легко добавляться и уничтожаться без приостановки нормального функционирования системы;
· обеспечить возможность параллельной работы с одной базой данных многих пользователей с допущением параллельной модификации объектов базы данных при наличии необходимых средств защиты целостности базы данных;
· обеспечить средства восстановления согласованного состояния баз данных после разного рода сбоев аппаратуры или программного обеспечения;
· обеспечить гибкий механизм, позволяющий определять различные представления хранимых данных, и ограничивать этими представлениями доступ пользователей к базе данных по выборке и модификации на основе механизма авторизации;
· обеспечить производительность системы при выполнении упомянутых функций, сопоставимую с производительностью существующих СУБД низкого уровня.
Структурная организация System R вполне согласуется с поставленными при ее разработке целями. Основными структурными компонентами System R являются система управления реляционной памятью (Relational Storage System - RSS) и компилятор запросов языка SQL. RSS обеспечивает интерфейс довольно низкого, но достаточного для реализации SQL уровня для доступа к хранимым в базе данным. Синхронизация транзакций, журнализация изменений и восстановление баз данных после сбоев также относятся к числу функций RSS. Компилятор запросов использует интерфейс RSS для доступа к разнообразной справочной информации (каталогам отношений, индексов, прав доступа, условий целостности, условных воздействий и т.д.) и производит рабочие программы, выполняемые в дальнейшем также с использованием интерфейса RSS. Таким образом, система естественно разделяется на два уровня - уровень управления памятью и синхронизацией, фактически, не зависящий от базового языка запросов системы, и языковой уровень (уровень SQL), на котором решается большинство проблем System R. Заметим, что эта независимость скорее условная, чем абсолютная: язык SQL можно заменить на другой язык, но он должен обладать примерно такой же семантикой.
Организация типичной СУБД и состав ее компонентов соответствует набору функций. Логически в современной СУБД можно выделить внутреннюю часть - ядро СУБД (Data Base Engine), компилятор языка БД (обычно SQL), подсистему поддержки времени выполнения, набор утилит.
Ядро СУБД отвечает за управление данными во внешней памяти, управление буферами оперативной памяти, управление транзакциями и журнализацию. Соответственно, можно выделить и такие компоненты ядра (по крайней мере, логически, хотя во многих СУБД они существуют явно), как менеджер данных, менеджер буферов, менеджер транзакций, менеджер журнала.
Все функции взаимосвязаны, поэтому компоненты должны взаимодействовать по продуманным и спланированным протоколам. Ядро СУБД обладает собственным интерфейсом, не доступным пользователю напрямую и используемым в программах, производимых компилятором SQL, и утилитах БД. Ядро СУБД является основной резидентной частью СУБД. При использовании архитектуры «клиент-сервер» ядро является основным составляющим элементом серверной части системы.
Основная функция компилятора языка БД - компиляция операторов языка БД в некоторую выполняемую программу. Основной проблемой реляционных СУБД является наличие непроцедурного языка, т.е. в операторе такого языка специфицируется некоторое действие над БД, но эта спецификация не процедура, она лишь описывает в некоторой форме условия совершения желаемого действия. Поэтому компилятор должен сначала решить, каким образом выполнить оператор языка, прежде чем произвести программу. Результатом компиляции является выполнимая программа, представляемая в некоторых системах в машинных кодах, но более часто в выполняемом внутреннем машинно-независимом коде. В последнем случае реальное выполнение оператора производится с привлечением подсистемы поддержки времени выполнения, представляющей собой, по сути, интерпретатор этого внутреннего кода.
В отдельные утилиты обычно выделяют такие процедуры, которые слишком накладно выполнять с использованием языка БД, например загрузка БД, сбор статистики, глобальная проверка целостности. Утилиты программируются с использованием ядра СУБД, а иногда с проникновением внутрь ядра.
Языковые средства систем управления
Базами данных
Функциональные возможности моделей данных становятся доступными пользователям СУБД благодаря ее языковым средствам. В данном случае речь идет о пользователях СУБД, к числу которых можно отнести: персонал администрирования данными, разработчиков прикладных программ на основе СУБД и конечных пользователей системы. Пользователи каждой их этих категорий могут иметь специально предназначенные для них интерфейсы на том или ином уровне архитектуры системы.
Реализация языковых средств интерфейсов может быть осуществлена различными способами:
для высококвалифицированных пользователей языковые средства представляются в их явной синтаксической форме;
в других случаях функции языков могут быть доступны косвенным образом, когда они реализуются в форме различного рода меню, диалоговых сценариев или заполняемых пользователем таблиц. По таким входным данным интерфейсные средства формируют адекватные синтаксические конструкции языка интерфейса и передают их на исполнение или включают в генерируемый код языка приложения. Интерфейсы с неявным использованием языка широко используются в СУБД для персональных ЭВМ. В этом случае используется (для реляционных СУБД), например, табличный язык Query-By-Example (QBE), разработанный М.Злуфом.
Языковые средства используются для выполнения двух основных функций:
для описания представления базы данных на управляемых уровнях архитектуры системы;
для инициирования выполнения операций манипулирования данными.
Первая из этих функций обеспечивается языком описания данных (ЯОД, Shema Definision Language), Его часто называют языком определения данных. Описание данных средствами ЯОД называют схемой базы данных. Оно включает описание логической структуры данных и налагаемых на нее ограничений целостности в рамках тех правил, которые регламентированы моделью данных используемой СУБД. Помимо указанных функций, ЯОД некоторых СУБД обеспечивает возможности задания ограничения доступа к данным или полномочий пользователей.
Кроме того, многие системы не имеют своих самостоятельных языков для спецификации многоуровневых отображений данных. В таких случаях определение способов отображения также описывается средствами ЯОД одного из смежных архитектурных уровней. Они при этом включаются в схему базы данных.
Стоит заметить, что при проектировании архитектуры системы часто не уделяют внимания обеспечению естественного разделения функций архитектурных уровней. В результате в значительной мере утрачивается возможность достижения той степени независимости данных, которая потенциально способна обеспечить «чисто» реализованная многоуровневая архитектура. Наиболее часто встречающийся дефекты архитектуры заключаются в том, что спецификации некоторых характеристик организации хранимых данных, законное место которых в схеме внутреннего представления, попадают в схему концептуального уровня.
ЯОД не всегда синтаксически оформляется в виде самостоятельного языка. Он может быть составной частью языка данных, сочетающего возможности определения данных и манипулирования ими.
Язык манипулирования данными (ЯМД, Shema Manipulation Language) позволяет запрашивать предусмотренные в системе операции над данными из базы данных, т.е. содержит набор операторов манипулирования данными, позволяющий заносить данные, удалять, модифицировать или выбирать их. Аналогично ЯОД, ЯМД не обязательно выступает в качестве синтаксически самостоятельного языка СУБД.
В настоящее время имеются многочисленные примеры языков СУБД, объединяющих возможности описания данных и манипулирования данными в единых синтаксических рамках. Более того, в современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с базой данных, начиная от"ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Наиболее популярным и стандартным для реляционных СУБД является язык SQL (Structured Query Language), разработанный фирмой IBM и реализованный в реляционной СУБД System R, а впоследствии и в коммерческой системе DB2. Другим примером языков этого класса могут служить: язык Quel системы Ingres, созданный Калифорнийским университетом, языковые средства большинства СУБД для персональных ЭВМ, например язык dBase семейства СУБД фирмы Asthon-Tate и многочисленных совместимых с ним систем, язык СУБД: R:Base фирмы Microrim.
Некоторые СУБД располагают такими языками, которые не только реализуют функции определения и манипулирования данными, но и обладают управляющими структурами и другими средствами, свойственными традиционным языкам программирования. Благодаря этому они могут использоваться как функционально полное средство для создания прикладных программ и для.формулировки запросов пользователей к БД. Такие языки называют автономными (язык запросов). В качестве примера приведем ранее упоминавшийся язык dBase, построенный в стиле структурного программирования.
Хотя автономные языки современных СУБД и обладают развитыми функциональными возможностями, существует много приложений, для реализации которых этих возможностей оказывается недостаточно. Наиболее распространены случаи, когда поддерживаемая модель данных оказывается слишком бедна средствами моделирования семантики ПО.
Как уже отмечалось, конечные пользователи информационной системы разделяются на две категории - прямые и косвенные. Те, кто относится к группе прямых пользователей, в отличие от косвенных, самостоятельно без посредников общается с ЭВМ. Они способны разрабатывать новые приложения.
В настоящее время акцент разработки приложений все более переносится с профессиональных программистов на конечных пользователей. Эта тенденция имеет очевидные достоинства: приложения разрабатываются быстрее; реализуются именно те алгоритмы, которые необходимы пользователю в момент разработки приложений; снижается себестоимость программной реализации системы и упрощается весь процесс ее разработки. Все это становится возможным, если в состав СУБД входят языки конечных пользователей, которые относят к классу автономных непроцедурных языков высокого уровня. Сегодня почти для всех промышленных систем такие языковые средства разработаны.
Языки конечных пользователей позволяют осуществлять выборку данных, формировать отчеты, разрабатывать новые приложения и запрашивать выполнение уже разработанных. В некоторых языках такого типа обеспечены также возможности обновления БД и реализация достаточно сложных обработок данных.
Изучение простейших возможностей языков конечных пользователей не требует больших затрат времени. Такой уровень подготовки (обычно 1-3 дня) позволит пользователю разрабатывать несложные приложения.
Использование всего арсенала языков, необходимого для создания сложных процедур обработки данных, требует профессиональной подготовки.
Процедурный язык, при помощи которого осуществляется управление базой данных, называют языком управления данными.
Язык QBE
Это язык, относящийся к классу высокоуровневых языков управления базами данных и представляющий пользователю удобный и унифицированный интерфейс для осуществления операций по ведению базы данных.
Для пользователя решение основных задач производится через таблицу-шаблон, связанную с реальной БД.
Важно, что для выполнения действий над базой пользователю достаточно обладать элементарным запасом языковых средств, чтобы понимать и использовать возможности всего языка. Синтаксис языка прост, тем не менее охватывает широкий спектр сложных операций. Это достигается за счет использования одинаковых операций для извлечения, манипулирования, определения и контроля данных. Операции языка «подражают» ручному манипулированию таблицами, сохраняя при этом все требования реляционной модели. Формирование операций должно следовать процессу рассуждений пользователя, предоставляя тем самым свободу при их построении. Архитектура языка QBE направлена на удовлетворение сформулированных требований.
Язык SQL
Сами по себе данные в компьютерной форме не представляют интерес для пользователя, если отсутствуют средства доступа к ним. Доступ осуществляется в виде запросов, которые формулируются на стандартном языке запросов. Сегодня для большинства СУБД таким языком является SQL.
Его появление и развитие как средства описания доступа к БД связано с созданием теории реляционных БД. Прообраз языка возник в 1970 г. в лаборатории Санта-Тереза фирмы IBM в рамках научно-исследовательского проекта System/R. Сегодня - это фактический стандарт интерфейса с современными СУБД. Популярность его настолько велика, что разработчики нереляционных СУБД (например, ADABAS), снабжают свои системы SQL-интерфейсом.
Язык SQL имеет официальный стандарт - ANSI/ISO. Большинство разработчиков придерживаются этого стандарта, однако часто расширяют его для реализации новых возможностей обработки данных.
SQL не является языком программирования в традиционном представлении. На нем пишутся не программы, а запросы к базе данных. Поэтому это язык декларативный. Это означает, что с его помощью можно сформулировать, что необходимо получить, однако нельзя указать, как это следует сделать. В частности, в отличие от процедурных языков программирования (Си, Паскаль), в языке SQL отсутствуют такие операторы, как if/then/else.
Запрос в языке SQL состоит из одного или нескольких операторов, следующих один за другим и разделенных точкой с запятой. Наиболее важные выделены в стандарте ANSI/ISO SQL.
Для пользователя представляют интерес не сами операторы языка, а их последовательность, оформленная как единое целое и имеющая смысл с его точки зрения. Каждая такая последовательность операторов языка SQL реализует определенное действие над БД. Оно осуществляется за несколько шагов, на каждом из которых над таблицами выполняются определенные действия.
Повторяем, что SQL - это язык запросов, поэтому на нем невозможно написать достаточно сложные прикладные программы, которые работают с базой данных. Для этой цели в современных СУБД используют язык четвертого поколения (FGL - Forth Generation Language), обладающий основными возможностями процедурных языков третьего поколения (Си, Паскаль), возможностью встроить текст программы оператора SQL, и средствами управления интерфейсом пользователя (формами, меню, вводом пользователя и т.д.). Сегодня - FGL - это один из фактических стандартов разработки приложений, работающих с БД.
Первый стандарт этого языка появился в 1989 г. - SQL-89 - и поддерживался практически всеми коммерческими реляционными СУБД. Он имел весьма общий характер и допускал широкое толкование. Достоинствами SQL-89 можно считать стандартизацию синтаксиса и семантики операторов выборки и манипулирования данными, а также фиксацию средств ограничения целостности базы данных. Однако в нем отсутствовали такие важные разделы, как манипулирование схемой БД и динамический SQL.
Неполнота стандарта SQL-89 привела к появлению в 1992 г. следующей версии языка SQL. SQL-92 охватывает практически все необходимые проблемы: манипулирование схемой базы данных, управление транзакциями и сессиями, динамический SQL. В стандарте существуют три уровня: базовый, промежуточный и полный. Только в. последнее" время СУБД ведущих производителей обеспечивается совместимость с полным вариантом языка.
Появление новых требований пользователей к СУБД и обрабатываемым данным привели к тому, что в настоящее время ведется работа по разработке SQL 3. Эта версия языка, видимо, будет иметь в своем составе механизм триггеров, определение произвольного типа данных, серьезные объекты расширения. Пока же крупнейшие производители СУБД затягивают разработку этого стандарта, совершенствуя и расширяя собственные версии языка SQL.
Функции СУБД. Типовая организация СУБД.
| Наименование параметра | Значение |
| Тема статьи: | Функции СУБД. Типовая организация СУБД. |
| Рубрика (тематическая категория) | Связь |
ПОНЯТИЕ СУБД. ФУНКЦИИ. ВНУТРЕННЯЯ АРХИТЕКТУРА.
Развитие информационных систем с течением времени привело к появлению ряда задач и требований, разрешить которые, файловые системы были уже не в состоянии. На смену файловым системам пришли первые, так называемые системы управления базами данных (СУБД). На сегодняшний день, СУБД принято называть прикладную информационную систему (комплекс программных средств), опирающуюся на некоторую систему управления данными, и обладающую следующим минимальным набором функций:
1. управление данными во внешней памяти;
2. управление буферами оперативной памяти;
3. управление транзакциями;
4. журнализация;
5. поддержка языков БД.
Непосредственное управление данными во внешней памяти. Эта функция включает обеспечение необходимых структур внешней памяти как для хранения данных, непосредственно входящих в БД, так и для служебных целей, к примеру, для ускорения доступа к данным (обычно для этого используются индексы).
В некоторых реализациях СУБД активно используются возможности существующих файловых систем, в других же задачи решаются даже на уровне устройств внешней памяти. В любом случае в хорошо развитых СУБД пользователи не обязаны знать, использует ли СУБД файловую систему, и если использует, то каким образом в ней организованы файлы.
Управление буферами оперативной памяти. СУБД обычно работают с БД значительного размера; по крайней мере, данный размер существенно больше доступного объёма оперативной памяти. Понятно, что если при обращении к любому элементу данных будет производиться обмен с внешней памятью, то вся система будет работать со скоростью устройства внешней памяти. Практически единственным способом реального увеличения этой скорости является буферизация данных в оперативной памяти. При этом даже если операционная система производит общесистемную буферизацию (как в случае ОС UNIX), этого недостаточно для целей СУБД, которая располагает гораздо большей информацией о полезности буферизации какой-либо части БД. По этой причине в развитых СУБД поддерживается собственный набор буферов оперативной памяти с собственной дисциплиной замены буферов.
Отметим, что существует отдельное направление СУБД, ĸᴏᴛᴏᴩᴏᴇ ориентировано на постоянное присутствие в оперативной памяти всей БД. Это направление основывается на предположении, что в будущем объём оперативной памяти компьютеров будет настолько велик, что позволит не беспокоиться о буферизации.
Управление транзакциями. Транзакция - ϶ᴛᴏ последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется и СУБД фиксирует (COMMIT) изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД. Понятие транзакции крайне важно для поддержания логической целостности БД. В случае если вспомнить наш пример информационной системы с файлами СОТРУДНИКИ и ОТДЕЛЫ , то единственным способом не нарушить целостность БД при выполнении операции приема на работу нового сотрудника является объединение элементарных операций над файлами СОТРУДНИКИ и ОТДЕЛЫ в одну транзакцию. Τᴀᴋᴎᴍ ᴏϬᴩᴀᴈᴏᴍ, поддержание механизма транзакций является обязательным условием даже однопользовательских СУБД (если, конечно, такая система заслуживает названия СУБД). В общем же понятие транзакции наиболее применимо к многопользовательским СУБД.
Каждая транзакция начинается при целостном состоянии БД и оставляет это состояние целостным после своего завершения. Это свойство, делает очень удобным использование понятия транзакции как единицы активности пользователя по отношению к БД. При соответствующем управлении параллельно выполняющимися транзакциями со стороны СУБД каждый из пользователей может в принципе ощущать себя единственным пользователем СУБД
С управлением транзакциями в многопользовательской СУБД так же связаны важные понятия сериализации транзакций и сериального плана выполнения смеси транзакций.
Под сериализаций параллельно выполняющихся транзакций принято понимать такой порядок планирования их работы, при котором суммарный эффект смеси транзакций эквивалентен эффекту их некоторого последовательного выполнения. Сериальный план выполнения смеси транзакций - ϶ᴛᴏ такой план, который приводит к сериализации транзакций. Понятно, что если удается добиться действительно сериального выполнения смеси транзакций, то для каждого пользователя, по инициативе которого образована транзакция, присутствие других транзакций будет незаметно (если не считать некоторого замедления работы по сравнению с однопользовательским режимом).
Существует несколько базовых алгоритмов сериализации транзакций. В централизованных СУБД наиболее распространены алгоритмы, основанные на синхронизационных захватах объектов БД. При использовании любого алгоритма сериализации возможны ситуации конфликтов между двумя или более транзакциями по доступу к объектам БД. В этом случае для поддержания сериализации крайне важно выполнить откат (ликвидировать все изменения, произведенные в БД) одной или более транзакций. Это один из случаев, когда пользователь многопользовательской СУБД может реально (и достаточно неприятно) ощутить присутствие в системе транзакций других пользователей.
Журнализация. Одним из базовых требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения принято понимать то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (к примеру, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев бывают: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, благодаря чему некоторая транзакция остается незавершенной. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции.
Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД.
Журнал - ϶ᴛᴏ особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью (иногда поддерживаются две копии журнала, располагаемые на разных физических дисках), в которую поступают записи обо всех изменениях основной части БД. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (к примеру, операции удаления строки из таблицы реляционной БД), иногда – минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал (так называемого протокола Write Ahead Log – WAL). Эта стратегия состоит по сути в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.
Самая простая ситуация восстановления – индивидуальный откат транзакции. Для этого не требуется общесистемный журнал изменений БД. Достаточно для каждой транзакции поддерживать локальный журнал операций модификации БД, выполненных в этой транзакции, и производить откат транзакции путем выполнения обратных операций, следуя от конца локального журнала. В некоторых СУБД так и делают, но в большинстве систем локальные журналы не поддерживают, а индивидуальный откат транзакции выполняют по общесистемному журналу, для чего все записи от одной транзакции связывают обратным списком (от конца к началу).
При мягком сбое во внешней памяти в основной части БД могут находиться объекты, модифицированные транзакциями, не закончившимися к моменту сбоя, и могут отсутствовать объекты, модифицированные транзакциями, которые к моменту сбоя успешно завершились (по причине использования буферов оперативной памяти, содержимое которых при мягком сбое пропадает). При соблюдении протокола WAL во внешней памяти журнала должны гарантированно находиться записи, относящиеся к операциям модификации обоих видов объектов. Целью процесса восстановления после мягкого сбоя является состояние внешней памяти основной части БД, ĸᴏᴛᴏᴩᴏᴇ возникло бы при фиксации во внешней памяти изменений всех завершившихся транзакций и ĸᴏᴛᴏᴩᴏᴇ не содержало бы никаких следов незаконченных транзакций. Для того, чтобы этого добиться, сначала производят откат незавершенных транзакций (undo), а потом повторно воспроизводят (redo) те операции завершенных транзакций, результаты которых не отображены во внешней памяти. Этот процесс содержит много тонкостей, связанных с общей организацией управления буферами и журналом. Более подробно остановимся на этом при рассмотрении внутренней огранизации баз данных.
Для восстановления БД после жесткого сбоя используют журнал и архивную копию БД. Архивная копия - ϶ᴛᴏ полная копия БД к моменту начала заполнения журнала (имеется много вариантов и более гибкой трактовки смысла архивной копии). Конечно, для нормального восстановления БД после жесткого сбоя крайне важно, чтобы журнал не пропал. Как уже отмечалось, к сохранности журнала во внешней памяти в СУБД предъявляются особо повышенные требования. Тогда восстановление БД состоит в том, что исходя из архивной копии по журналу воспроизводится работа всех транзакций, которые закончились к моменту сбоя. В принципе, можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. При этом в реальных системах это обычно не делается, поскольку процесс восстановления после жесткого сбоя является достаточно длительным.
Поддержка языков БД . Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддерживалось несколько специализированных по своим функциям языков. Можно особо выделить два языка – язык определения схемы БД (SDL –Schema Definition Language) и язык манипулирования данными (DML – Data Manipulation Language). SDL служил главным образом для определения логической структуры БД, ᴛ.ᴇ. той структуры БД, какой она представляется пользователям. DML содержал набор операторов манипулирования данными, ᴛ.ᴇ. операторов, позволяющих заносить данные в БД, удалять, модифицировать или выбирать существующие данные. Рассмотрим более подробно языки ранних СУБД в последующих лекциях.
В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language), который более подробно будет рассмотрен в 5 главе. Перечислим пока только основные функции реляционной СУБД, поддерживаемые на "языковом" уровне (ᴛ.ᴇ. функции, поддерживаемые при реализации интерфейса SQL).
Прежде всего, язык SQL сочетает средства SDL и DML, ᴛ.ᴇ. позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД – именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов.
Язык SQL содержит специальные средства определения ограничений целостности БД. Опять же, ограничения целостности хранятся в специальных таблицах-каталогах, и обеспечение контроля целостности БД производится на языковом уровне, ᴛ.ᴇ. при компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений целостности генерирует соответствующий программный код.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Наконец, авторизация доступа к объектам БД производится также на базе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором полномочий для работы с этой таблицей. В число этих полномочий входит полномочие на передачу всех или части полномочий другим пользователям, включая полномочие на передачу полномочий. Полномочия пользователей описываются в специальных таблицах-каталогах, контроль полномочий поддерживается на языковом уровне.
Функции СУБД. Типовая организация СУБД. - понятие и виды. Классификация и особенности категории "Функции СУБД. Типовая организация СУБД." 2017, 2018.