7.5. Метод временных меток
Альтернативный метод сериализации транзакций, хорошо работающий в условиях редких конфликтов транзакций и не требующий построения графа ожидания транзакций, основан на использовании временных меток.
Основная идея метода (у которого существует множество разновидностей) состоит в следующем: если транзакция T1 началась раньше транзакции T2, то система обеспечивает такой режим выполнения, как если бы T1 была целиком выполнена до начала T2. Для этого каждой транзакции T предписывается временная метка t, соответствующая времени начала T. При выполнении операции над объектом r транзакция T помечает его своей временной меткой и типом операции (чтение или изменение).
Перед выполнением операции над объектом r транзакция T2 выполняет следующие действия (алгоритм см. на Рис. 29):
Проверяет, не закончилась ли транзакция T1, пометившая этот объект. Если T1 закончилась, T2 помечает объект r и выполняет свою операцию.
Если транзакция T1 не завершилась, то T2 проверяет конфликтность операций. Если операции неконфликтны, при объекте r остается или проставляется временная метка с меньшим значением, и транзакция T2 выполняет свою операцию.
Если операции T2 и T1 конфликтуют, то если t(T1) > t(T2) (т.е. транзакция T1 является более "молодой", чем T2), производится откат T1 и T2 продолжает работу.
Если же t(T1) < t(T2) (T1 "старше" T2), то T2 получает новую временную метку и начинается заново.
Рис. 29. Алгоритм метода временных меток
К недостаткам метода временных меток относятся потенциально более частые откаты транзакций, чем в случае использования синхронизационных захватов. Это связано с тем, что конфликтность транзакций определяется более грубо. Кроме того, в распределенных системах не очень просто вырабатывать глобальные временные метки (это отдельная большая наука). Но в распределенных системах эти недостатки окупаются тем, что не нужно распознавать тупики, а построение графа ожидания в распределенных системах стоит очень дорого.
Д/З . Для примера из Д/З придумайте транзакцию с немедленно проверяемой целостностью и отложенной проверкой. Для транзакции из Д/З с конфликтом пользователей проанализируйте 1,2,3 уровень изолированности пользователей (то есть более подробно распишите, какие возникают проблемы) и последствия появления кортежей-фантомов.
Подробнее о транзакциях см. [1].
Вопросы для самопроверки:
1. Чем различаются второй и третий уровни изолированности транзакций?
2. В каком из методов сериализации возможны тупики?
3. Какой из методов сериализации более выгоден в условиях редких конфликтов?
8. Обзор перспективных направлений баз данных
Рассмотрим перспективные направления БД, возникшие после широкого распространения реляционных БД.
1. Базы сложно структурированных объектов. Реляционная модель с отказом от первой нормальной формы. Например, первая нормальная форма требует, чтобы Фамилия, Имя, Отчество были тремя разными атрибутами. Если предположить, что БД относится к международной корпорации, то у сотрудников могут быть системы имен, отличные от русской. Таким образом, требуется один атрибут «Полное имя».
2. СУБД третьего поколения. Термин “Бд следующего (или третьего) поколения” вошел в жизнь после опубликования группой известных специалистов в области БД “Манифеста систем БД третьего поколения”. Сторонники этого направления придерживаются принципа эволюционного развития возможностей СУБД без коренного изменения предыдущих подходов и с сохранением совместимости с системами предыдущего поколения. Частично требования к системам следующего поколения означают просто необходимость реализации или усиления давно известных свойств, отсутствующих в большинстве реляционных СУБД (ограничения целостности, триггеры, модификация БД через VIEW и т.д.). В число новых требований входит полнота системы типов, поддерживаемых в СУБД; поддержка иерархии и наследования типов; возможность управления сложными объектами и т.д.
Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только условно, можно выделить три направления в области СУБД следующего поколения. Будем обозначать их именами наиболее характерных СУБД.
2.1. Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам организации СУБД.
2.2. Направление Exodus/Genesis. Основная характеристика: создание не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется вплоть до самых базисных слоев системы.
2.3. Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. Система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.
В целом СУБД следующего поколения - это прямые наследники реляционных систем.
3. Объектно-ориентированные и объектно-реляционные СУБД
Объектно-реляционные СУБД являются развитием реляционных СУБД с отказом от первой нормальной формы. Вместо доменов атрибутов используются классы, то есть возможны сложные атрибуты. Кортежи также представляют собой экземпляры классов, поэтому у кортежей можно вызывать методы – хранимые процедуры, которые могут обращаться к атрибутам кортежа без явной передачи этих атрибутов в качестве параметров. Возможно иерархическое наследование между классами.
Объектно-ориентированные СУБД – это развитие объектно-ориентированных языков, в которые добавляется перманентность (персистентность) объектов – способность объектов сохранять свое состояние во время выключения программы. Программирование работы с временными и перманентными объектами строится по одинаковым принципам.
Очень часто существуют гибридные системы. На верхнем уровне – уровне проектирования присутствует объектная модель, которая затем отображается в реляционную. Часто на сервере бизнес-логики присутствуют механизмы для работы с объектными структурами, то есть пользователь работает со сложными объектами, которые физически хранятся в реляционной схеме.
Языки запросов (SQL) становятся объектно-ориентированными. Разработан язык OQL – object query language. В них существует возможность обращения к связанным таблицам через (.) или (->).
Пример объектно-ориентированного запроса приведен на Лист. 53, схема БД – на Рис. 30 .
Рис. 30. Диаграмма классов "отделы-служащие"
Лист. 53. Пример объектного запроса
SELECT DISTINCT Emp.works_for.managed_by.empName
FROM Emp
WHERE Emp.empSalary > 20000.00
ООБД и ОРБД сближаются друг с другом. Например, в ООБД в последнее время добавляются все больше возможностей БД, например – триггеры.
4. Активные БД. СУБД по отношению к БД выполняет не только те действия, которые явно указывает пользователь, но и дополнительные действия в соответствии с правилами, заложенными в саму БД. В РБД существует механизм триггеров, но он не реализован полностью. Например, если у нас три таблицы связаны по циклу друг с другом, то триггеры на модификацию могут вызвать каскадное нарастающее изменение записей по циклу, при этом БД может и не прийти в состояние равновесия. Полноценная активная БД должна содержать продукционную систему (набор правил «если…то…»).
5. Дедуктивные и интеллектуальные БД. состоят из двух частей: экстенсиональной, содержащей факты, и интенсиональной, содержащей правила для логического вывода новых фактов на основе экстенсиональной части и запроса пользователя. Основным признаком дедуктивной БД можно считать рекурсию. Как правило, языки запросов дедуктивных БД являются логическими (например, Datalog). Язык PostQuel является синтезом SQL и Prolog. Часто факты дедуктивной БД хранятся в реляционной СУБД. В этом случае дедуктивный запрос трансформируется в ряд SQL-запросов. Возникает задача совместного выполнения и оптимизации запросов.
6. Темпоральные БД предназначены для хранения исторической информации. БД сохраняет не только текущее состояние объекта, но и все его предыдущие состояния, т.е. сохраняет всю эволюцию состояний объекта с течением времени. Объект определяется ключом и временным интервалом, в котором следует узнать его состояние. Актуальное состояние объекта - [Tstart, Tend]. Возможны запросы не только по ключу, но и по времени. Примеры запросов:
Определить, как менялись состояния объекта в интервале времени [T1, T2].
Определить, какие объекты были актуальны в момент времени T.
Определить предыдущее состояние объекта.
Определить интервалы времени, в которых объект принимал заданное состояние
Определить среднее время существования объекта без изменений.
Пример: Таблица количества товара на складе. Для анализа OLAP мы ввели загрузку в хранилище данных исторической информации для хранения кол-ва товара на складе по дням (временной измерение), с агрегацией по месяцам и годам. Но это не решает всех проблем, так как в условиях динамичности продаж можно проводить анализ по часам и минутам. Выходом из ситуации может быть следующее решение: для каждого изменения товара на складе создавать новую запись с временной меткой. Но в реляционных БД записи хранятся независимо друг от друга, что осложняет временные запросы, т.е. требуются дополнительные механизмы для навигации по записям по времени.
Соответствующие возможности работы с историческими данными заложены в язык Postquel. Возможна выборка информации, хранившейся в БД в указанное время, в указанном временном интервале и т.д. Кроме того, имеется возможность создавать версии отношений, и допускается их последующая модификация с учетом изменений основных вариантов.
7. БД реального времени используются в промышленных системах. Существует стандарт – промышленный SQL. Различают два вида реального времени:
«Жесткое время» фиксированное гарантированное время отклика на любой запрос.
«Мягкое время» - для конкретных запросов рассчитывается разное гарантированное время отклика.
8. Пространственные БД используются в геоинформационных системах (ГИС) и системах автоматизированного проектирования (САПР), поддерживают специальные типы данных для хранения пространственной информации и способы обработки, связанные с задачами на графах, пространственной ориентацией и топологией объектов. Графовые БД являются отдельным направлением. Простейшие задачи над графами: поиск области достижимости и поиск кратчайшего пути затруднительно решать на языке SQL (требуются рекурсивные запросы, которые не всегда есть в используемом диалекте SQL). Разработаны декларативные языки для задач над графами.
9. Интегрированные неоднородные БД и мультибазы появились в связи с необходимостью комплексирования систем БД, основанных на разных моделях данных и управляемых разными СУБД. Основной задачей интеграции неоднородных БД является предоставление пользователям интегрированной системы глобальной схемы БД, представленной в некоторой модели данных, и автоматическое преобразование операторов манипулирования БД глобального уровня в операторы, понятные соответствующим локальным СУБД. Обычно в качестве глобальной схемы применяется реляционная модель. В интегрированных БД вся работа пользователей осуществляется через глобальную систему. В мультибазах сохраняется автономность входящих в систему баз и специфические способы работы.
10. Распределенные БД исторически появились как объединение разнородных БД в глобальные БД при создании международных корпораций. В настоящее время существуют как альтернатива трехуровневой архитектуре СУБД (принцип: данные хранятся там, где они чаще всего используются). Существует логическая база данных, разделенная на несколько физических СУБД, приложения могут быть локальные и глобальные. Распределение БД не должно быть заметно для пользователя. Близкими являются СУБД с параллельной обработкой (распараллеливаются вычисления и запросы). СУБД бывают однородные (например, во всех узлах – реляционная модель) и разнородные.
Фрагментация:
На уровне схемы БД (таблицы в разные узлы),
Горизонтальная (кортежи разных отношений в разных узлах),
Вертикальная (атрибуты одного отношения разделены по разным БД),
Смешанная.
В распределенных СУБД усиливается проблема обеспечения целостности данных в условиях распределенного хранения и обработки данных и глобальных запросов. Применяются двухфазные и трехфазные транзакции.
Пример. Таблица «Сделки» фрагментируется по отделам продаж (горизонтальная фрагментация). Пусть таблица «Товар» содержит не только информацию о текущем кол-ве на складе, но и производственные атрибуты, например, дату изготовления. Можно разделить производственную и торговую информацию на две БД (вертикальная фрагментация).
11. БД со слабоструктурированными данными бывают следующих видов:
Хранят текстовую и гипертекстовую информацию. Запросы как в поисковых Интернет-системах. XML – документы содержат более строгую, чем в HTML, разметку благодаря пользовательским тегам. Запросы на языке XQuery.
БД с графическими и сигнальными типами данных. Запросы в виде первичной обработки (фильтрация), выделения границ и объектов, распознавания образов.
12. Системы БД с многоуровневой защитой
Существенной особенностью языка SQL, появившейся в нем с самого начала, является обеспечение защиты доступа к данным средствами самого языка. По отношению к любому отношению БД и любому столбцу отношения вводится предопределенный набор привилегий. С каждой транзакцией неявно связывается идентификатор пользователя, от имени которого она выполняется. После создания нового отношения все привилегии, связанные с этим отношением и всеми его столбцами, принадлежат только пользователю-создателю отношения. В число привилегий входит привилегия передачи всех или части привилегий другому пользователю, включая привилегию на передачу привилегий. Наделение полномочиями осуществляется через оператор grant, изъятие полномочий – revoke.
Известно два подхода к реализации многоуровневой защиты:
1. Первый подход состоит в связывании с каждым защищаемым объектом БД набора допустимых привилегий и связывании с каждым пользователем некоторого набора прав доступа.
2. Второй подход к защите данных основан на использовании методов криптографии (методы с открытым ключом).
Д/З . Для примера из Д/З для некоторого подмножества таблиц придумайте фрагментацию разного вида (фрагментация должна быть логически обоснована). Для какой-нибудь таблички создайте темпоральное расширение, приведите примеры двух запросов с временной информацией.
Вопросы для самопроверки:
Чем БД реального времени отличаются от темпоральных СУБД?
В чем различия между ООБД и ОРБД?
В чем различия между распределенными и пространственными БД?
Чем «мягкое время» отличается от «жесткого времени»?
В чем сходство и различие в подходе ко времени в темпоральных БД и хранилищах данных?
В чем проблема представления полного имени человека в РБД в первой нормальной форме?