Рассмотрим перспективные направления БД, возникшие после широкого распространения реляционных БД.
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. Второй подход к защите данных основан на использовании методов криптографии (методы с открытым ключом).
Д/З 10. Для примера из Д/З 4 для некоторого подмножества таблиц придумайте фрагментацию разного вида (фрагментация должна быть логически обоснована). Для какой-нибудь таблички создайте темпоральное расширение, приведите примеры двух запросов с временной информацией.
Вопросы для самопроверки:
1. Чем БД реального времени отличаются от темпоральных СУБД?
2. В чем различия между ООБД и ОРБД?
3. В чем различия между распределенными и пространственными БД?
4. Чем «мягкое время» отличается от «жесткого времени»?
5. В чем сходство и различие в подходе ко времени в темпоральных БД и хранилищах данных?
6. В чем проблема представления полного имени человека в РБД в первой нормальной форме?
