Реализация абстрактной модели активных баз данных средствами современных СУБД Текст научной статьи по специальности «Компьютерные и информационные науки»
Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Шибанов С. В., Лысенко Э. В., Скоробогатько А. А., Зудов А. Б., Вишняков П. В.
Методика тестирования программных средств управления активными базами данных
Моделирование активных правил в нотации IDEF0
Формальное представление правил в активных базах данных как последовательных взаимодействующих процессов
Система тестирования серверного программного обеспечения активных баз данных
Обзор современных технологий и средств построения активных информационных систем
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.
Текст научной работы на тему «Реализация абстрактной модели активных баз данных средствами современных СУБД»
Шибанов С.В. , Лысенко Э.В., Скоробогатько А.А., Зудов А.Б. , Вишняков П.В.
РЕАЛИЗАЦИЯ АБСТРАКТНОЙ МОДЕЛИ АКТИВНЫХ БАЗ ДАННЫХ СРЕДСТВАМИ СОВРЕМЕННЫХ СУБД
1. Актуальность исследований и разработок активных баз данных. Традиционно базы данных (БД) рассматривались как репозитории, которые хранят необходимую для приложений информацию и доступны прикладным программам или пользователям через интерактивные интерфейсы. Традиционные системы управления базами данных (СУБД) пассивны в том смысле, что действия, выполняемые СУБД, инициируются пользователями или программными приложениями. Данный подход может оказаться весьма неэффективным в некоторых случаях.
Типичным примером подобного случая может быть информационная система железной дороги. В ней хранится информация о поездах, расписаниях, местах, имеется возможность покупать билеты через различные терминалы. Во время праздников и других важных событий может быть полезным добавить вагоны к некоторым поездам, если число свободных мест в поездах упало до определённого порога. При этом добавленные вагоны и имеющиеся в наличии места должны своевременно отображаться в терминалах и быть доступными для заказа и покупки билетов пользователями. Администратор базы данных может реализовать это двумя способами. С одной стороны, можно добавить соответствующую функциональность в каждую программу продажи билетов, чтобы контролируемая ситуация проверялась при каждой продаже. Но тогда семантика задачи становится распределённой по терминалам, скрытой и продублированной множество раз. Другая возможность — создать единый опрашивающий механизм, который должен периодически проверять число свободных мест. Но трудность состоит в частоте — слишком частый опрос приведёт к уменьшению производительности, а при слишком редком запросе реакция системы будет сильно запаздывать, и кому-то может быть отказано в продаже, пока вагон не добавится. Кроме того, могут возникнуть аналогичные ситуации, и для каждой из них придется создавать приложение, реализующее необходимую функциональность.
Приведенный пример не является единственным и узкоспециальным, как может показаться на первый взгляд. Множество разработчиков баз данных информационных систем, связанных с электронной коммерцией, сталкиваются с подобными проблемами. Особенно остро они ощущаются, когда БД становится распределённой, и взаимодействовать компоненты должны через Интернет. Клиентов несравнимо больше, чем в предыдущем примере, связь с ними хуже, значит и опрос — долгая, а иногда и требовательная по производительности процедура. С другой стороны, если функциональность содержится в клиентских приложениях, они не только становятся громоздкими, их как-то необходимо обновлять, следя за тем, чтобы у всех была последняя версия, обеспечивая при этом безопасность.
Те же проблемы распространяются и на системы мониторинга, контроля и планирования. Речь идёт о более узкоспециальных и разнотипных системах, таких как системы планирования и управления рабочим процессом [3], мониторинга физических процессов и так далее. Эти задачи требуют своевременного обнаружения критических ситуаций и ответа на них, а значит, необходима высокая адаптивность всей системы, что для базы данных значит автоматическую реакцию на определённые события, описанную в терминах триггеров.
Всё большее распространение получают базы данных движущихся объектов (Moving Objects Database -MODB). [4] Эти объекты изначально не статичны и обладают поведением, перемещаясь по локациям разных типов, меняя тем самым свои характеристики и влияя на характеристики локаций. Таким образом, ситуаций возникает много, а на них нужно реагировать всё так же быстро. Сейчас стали необходимы системы, позволяющие моделировать и прогнозировать пробки и аварии, проектировать транспортные пути и автоматизировать управление трафиком. Похожими на мониторинг трафика задачами являются моделирование сражений, контроль перемещения животных и птиц в экологии и, конечно же, средства мобильной коммуникации.
Для БД движущихся объектов, помимо вышеозначенных проблем, появляется проблема гибкости описания поведения объектов. В терминах традиционных СУБД некоторые аспекты поведения описать сложно или невозможно, например, не все источники событий могут быть описаны традиционными средствами.
Обширная область исследований — пиринговые (одноранговые, децентрализованные) сети, то есть сети, в которых каждый узел (пир) является одновременно клиентом и сервером. Сложность таких систем не только в том, что база данных оказывается распределённой, но и в том, что число источников событий постоянно изменяется [5]. Пирами могут быть не только стационарные машины, но и мобильные устройства. В этом случае БД будет объединять некоторые особенности баз данных движущихся объектов и систем на основе пиринговые сетей. [6] С такой задачей традиционные СУБД часто не справляются даже в аспекте производительности. Чтобы решить эту проблему, необходим подход, при котором неким образом упрощалась бы обработка запросов.
В настоящее время перед современными СУБД, обслуживающими различные информационные системы, все чаще и чаще ставятся задачи, требующие активно реагировать на события, происходящие как внутри информационной системы, так и за ее пределами. Приведенный здесь достаточно краткий обзор проблем традиционных систем управления базами данных показывает актуальность теоретических исследований и практических разработок активных баз данных и систем управления активными базами данных (СУАБД), которые могли бы успешно справляться с указанными проблемами. АБД и СУАБД интегрируют необходимую функциональность внутри самой системы управления базами данных, что обеспечивает создание баз данных с более обширными средствами моделирования как структурных, так и поведенческих аспектов приложения.
2. Модель знаний для АБД. Активная БД должна поддерживать модель знаний, например, механизм описания, и модель выполнения, например, стратегию времени выполнения, чтобы поддерживать реагирующее поведение.
2.1. Классическая модель знаний (модель ECA-правил). Классическая модель знаний АБД основывается на правилах, которые содержат три компонента: событие (event), условие (condition) и действие (ac-
tion). Такого рода правила называют ECA-правилами.
Часть события (event) правила описывает какое-либо событие, которое может произойти в системе или вне нее, и которое должна распознать активная база данных. Спецификация события, таким образом, включает поддержку описания чего-то происходящего, что должно контролироваться. Суть описания и способ, которым событие может быть обнаружено, в значительной степени зависят от источника, или генератора события. Как правило, выделяются следующие источники возникновения событий:
Структурная операция (structure operation) — событие порождается операцией над некоторой частью структуры данных, например, вставить кортеж, изменить атрибут, получить доступ к кортежу;
Вызов поведения (behavior invocation) — событие порождается выполнением некой операции, описанной пользователем, часто событие может порождаться до или после выполнения операции;
Транзакция (transaction) — событие порождается командами транзакций (например, begin transaction, commit, rollback);
Абстрактные (abstract) — описанные пользователем события, механизм программирования которых позволяет сигнализировать о возникновении события явно, например, в ответ на некоторую информацию, введённую пользователем;
Исключения (exeptions) — событие появляется в результате некоторого возникшего исключения, например, была сделана попытка получить доступ к данным без соответствующей авторизации;
Часы (clock) — событие возникает в некоторый момент времени — абсолютное, например, 1З Ноября 199B в 15:00, относительное, например, 10 дней после того, как акции проданы, и периодическое, например, в первый день каждого месяца временные события;
Внешние (external) — событие порождается чем-то извне, например, измеряемая датчиком температура выше 3 0 градусов.
Масштаб события (Event Granularity) указывает на то, что событие определено:
для каждого объекта в наборе (set) — например, каждого экземпляра класса;
для заданных поднаборов (subset) — например, все штатные сотрудники, кроме профессоров;
для некоторых членов (members) набора — например, чтобы предотвратить неавторизованный доступ к некоторым экземплярам, или чтобы сделать возможным обновление тех объектов, которые сейчас отображаются на экране.
Тип (Type)события может быть:
примитивным (primitive) — событие порождается одиночным низкоуровневым действием, что описанным как источник. Например, событие on insert to Owns контролирует вставку новых кортежей в отношение Owns;
сложным (composite) — событие порождается комбинацией примитивных или сложных событий, используя ряд операторов, которые составляют алгебру событий.
Роль события указывает, должно ли оно всегда задаваться для активных правил, или же явное обозначение не является необходимым. Если роль опциональна (optional), то речь идет о существовании правил условие-действие (помимо ECA), в которых событие опущено. Если роли нет (none), то события не могут быть определены, и все правила являются условиями-действиями. Если роль обязательная (mandatory), то поддерживаются только ECA-правила.
Часть условия (condition) правила проверяет контекст, при котором событие произошло. Роль условия показывает, должно ли оно обязательно присутствовать. В ECA-правилах роль условия обычно опциональны. Когда оно не задано, или когда роли нет (none), получается правило событие-действие. В системах, в которых и событие, и условие необязательны, должно присутствовать хотя бы одно.
Контекст указывает на окружение, в котором условие вычисляется. Различные компоненты правила не вычисляют изолированно друг от друга, и более того, они не могут быть вычислены моментально. Как результат, обработка одиночного правила может быть потенциально ассоциировано, как минимум, с четырьмя разными состояниями БД:
1) DBT — база данных в начале транзакции;
2) DBE — база данных в момент; когда событие появилось;
3) DBC — база данных в момент, когда вычислено условие;
4) DBa — база данных в момент, когда выполнено действие.
Системы активных правил должны поддерживать внутри условия возможность доступ к нулю или больше состояний DBt, DBe и DBc, и также обеспечить доступ к связкам с событием (BindE).
Действие (action) описывает задачу, которая должна быть выполнена правилом, если соответствующее событие произошло и условие оказалось истинным. Список задач, которые могут быть выполнены действием определяются как его Опции. Действия могут менять структуру (structure) базы данных или набора правил, выполнять некоторый вызов поведения (behavior invacation) внутри базы данных или внешний (external) вызов, информировать (inform) пользователя или системного администратора о какой-либо ситуации, прерывать (abort) транзакцию или принимать альтернативную линию поведения, используя do-instead.
В некоторых случаях в ECA-правиле событие или условие может быть пропущено или скрыто. Если нет события, то результирующее правило является условием-действием, или продукционным. Если нет условия, то это событие-действие.
2.2. Расширенная модель знаний (SECA-модель). Классическая ECA-модель не учитывает, что в реальных приложениях поведение объекта часто зависит от его состояния.
Например, учетная запись пользователя может быть «активна» или «заблокирована», и в зависимости от этого различной может быть реакция на попытку входа пользователя в систему.
В системе документооборота документ может находиться в состояниях «свободен» и «редактируется». Если документ свободен, то любой пользователь может начать его редактирование и документ переводится в состояние «редактируется». После этого остальные пользователи не имеют доступа к документу, пока не завершится его редактирование, и он не вернется в состояние «свободен».
Состояние — это абстракция значений и связей объекта. Множество значений и связей группируются в состояние в соответствии с массовым поведением объекта. При определении состояния не учитываются атрибуты, не оказывающие влияния на поведение объекта. В состояние объединяются все комбинации значений и связей, характеризующиеся одинаковым откликом на события. Остальные атрибуты можно рассматривать как значения параметров состояния. Объекты класса обладают конечным числом возможных состояний. В каждый момент времени объект может находиться только в одном состоянии. Объекты могут проходить через одно или несколько состояний в течение времени своего существования.
Состояние описывает отклик объекта на получаемые события: в конкретном состоянии игнорируются любые события, за исключением тех, поведение при получении которых описано явным образом. Это свойство состояний особенно важно — оно позволяет наделить объекты системы свойством изменчивости — способности изменять свое поведение в зависимости от возникающих событий.
Добавление в классическую ECA-модель понятия состояния сокращает количество необходимых правил и упрощает процесс разработки активной системы. Возможные типы поведения объекта группируются в соответствии с его состояниями, поведение объекта структурируется и становится доступнее для понимания. Модель ECA-правил, учитывающую состояние объекта называется расширенной моделью ECA-правил, или SECA-моделью (State-Event-Condition-Action).
Графической интерпретацией SECA-модели являются диаграммы состояний UML. Диаграмма состояний -это граф, узлами которого являются состояния, а направленными дугами — переходы между состояниями.
Понятие перехода (transition) от исходного к целевому состоянию в SECA-модели аналогично понятию ECA-правила в ECA-модели. С переходом связывается вызывающее его событие, сторожевое условие и выполняемое при переходе действие, а также два состояния — исходное и целевое. При возникновении события и выполнении сторожевого условия происходит не только выполнение действия, но и переход объекта из исходного состояния в целевое. Исходное и целевое состояния могут совпадать, что аналогично простому ECA-правилу.
Диаграммы состояний UML позволяют наглядно изобразить поведение объекта. В этом кроется еще одно преимущество SECA-модели перед классической ECA-моделью, которая представляется списком правил.
Диаграмма состояний может быть реализована непосредственным преобразование семантики в эквивалентный программный код. Однако, как правило, это процесс является трудоемким и получающийся программный код сложен для понимания и сопровождения. Этого можно избежать, разработав инструментальные средства, автоматизирующие построение кода по диаграмме состояний. В контексте активных баз данных эти средства должны включать:
1) Набор метаданных, содержащих информацию о возможных состояниях, событиях, условиях и действиях, а также о возможных переходах между состояниями;
2) Набор процедур, настраивающих СУБД на поведение в соответствии с диаграммой состояний;
Метаданные SECA-модели целесообразно разделить на две части:
1) Модель состояний с абстрактными событиями, условиями и действиями, не привязанными к конкретной модели данных и СУБД;
2) Реализация событий, состояний и условий в конкретной СУБД, например, абстрактное событие блокировки учетной записи пользователя может быть событием вызова операции UPDATE над таблицей учетных записей, модифицирующей атрибут «заблокирована». В ООБД это же событие может быть событием вызова соответствующего метода.
Такое разделение упрощает перенос модели между различными СУБД: для использования модели в новой
СУБД нужно только указать реализацию событий, условий и действий на языке конкретной СУБД — остальные действия будут выполнены автоматически. Кроме этого, упрощается модификация модели, т.к. изменение реализации не затрагивает абстрактную модель, и наоборот, изменение абстрактной модели не затрагивает реализацию, за исключением добавления новых событий, условий или действий — тогда нужно указать соответствующую реализацию.
3. Реализация абстрактной модели АБД средствами реляционных СУБД. Основными инструментами по реализации активности в реляционных СУБД являются триггеры, хранимые процедуры и мониторы событий.
Мониторы событий отвечают за распознавание возникновения событий и передачи сигнала о них в систему или пользователю. Хранимые процедуры представляют собой набор команд SQL, которые могут компилироваться и храниться на сервере. Таким образом, вместо того, чтобы хранить часто используемый запрос, клиенты могут ссылаться на соответствующую хранимую процедуру.
Триггеры реализуют реакции сервера данных на определенные события. По своей сути триггер — это особая разновидность хранимой процедуры, выполняемая автоматически при возникновении события на сервере базы данных. Триггеры языка обработки данных выполняются по событиям, вызванным попыткой пользователя изменить данные с помощью языка обработки данных. Событиями DML являются процедуры INSERT, UPDATE или DELETE, применяемые к таблице или представлению. Эти триггеры срабатывают при запуске любого допустимого события независимо от того, влияет ли оно на какие-либо строки таблицы.
По своей сути триггеры являются ECA-правила, для которых событиям возникновения являются операции NSERT, UPDATE или DELETE. В них также можно определить условие, для дальнейшего выполнения и действие, которое может быть отличным от первоначального события, которое инициировало триггер
Таблица 1 — Возможности СУБД Microsoft SQL Server 2008 по реализации основных особенностей АБД
Особенность СУАБД Microsoft SQL Server Оценка
І І СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере + + +
1.2 Поддержка модели ECA-правил Определение типов событий Определяет события «до» и «после» для некоторых событий. Определение сложных событий отсутствует. + — —
Определение условий Для представления условий возможно использование как языка SQL, представляющего собой язык 4-го уровня, так и .NET-совместимые языки (в частности — C# и C++.NET) + + +
Определение действия Для представления условий возможно использование как языка SQL, представляющего собой язык 4-го уровня, так и .NET-совместимые языки (в частности — C# и C++.NET). + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Ядро СУБД предопределяет список обнаруживаемых событий + — —
Поддержка эволюции базы правил Условие и действие могут быть изменены с помощью директив SQL, требуется повторная компиляция только измененных данных. + + —
Возможность активировать или деактивировать правила Присутствует возможность селективного управления активностью триггеров
1 2 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Сложные события не обнаруживаются + — —
Поддержка режима связывания Событие связывается с конкретным объектом + — —
Механизм проверки условий Условие имеет доступ как к текущему, так и к предыдущему (последующему) состояниям объекта, а также другим объектам БД + + +
Механизм выполнения действий Существуют ограничения, определяемые возникшим событием + + —
2.2 Методы сцепления транзакций Реализованы различные механизмы сцепления транзакций +++
2.3 Способы выявления сложных событий Механизм выявления сложных событий отсутствует
2 Управление историей событий Любые события записываются в системный журнал базы данных + + —
2.5 Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного способа блокировок, возможна дополнительная эскалация блокировок + + —
1 3 Поддержка программной окружающей среды Специализированные средства разработки правил отсутствуют. Наращивание возможностей по обработке возможно только в рамках существующей схемы событий.
3.2 Настройка СУАБД Проектирование может быть осуществлено с использованием двух- или трехуровневой модели. + + +
Таблица 2 — Возможности СУБД Oracle 11д по реализации основных особенностей АБД
№ Особенность СУАБД Характеристики СУБД Oracle Оценка
1.1 СУАБД есть просто СУБД В полной мере поддерживает возможности реляционных СУБД + + +
1.2 Поддержка модели ЕСА- правил Определение типов событий Простейшими событиями, которые можно обнаружить внутри базы данных, являются вставка, обновление и удаление, остальные же события должны быть реализованы как сложные. Сложных событий в Oracle нет, и их необходимо добавить разработчику СУАБД. На внешние события такое ограничение не распространяется + + —
Определение условий Условия можно задавать различными языками (PL/SQL, C++, Java) + + +
Определение действия Как и в случае условий, ограничений в определении действий нет + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Базу правил можно хранить как совокупность скриптов, хранимых процедур и триггеров + + +
Поддержка эволюции базы правил Если хранить скрипты в таблицах, то их можно изменять как обычные строковые данные. В зависимости от того, на каком языке написаны правила, их изменения может требовать (в случае PL/SQL) или не требовать перекомпиляции. Ограничений в модификации триггеров тоже нет. + + +
Возможность активировать или деактивировать правила Деактивация правил — это деактивация обнаружения событий. Так как оно реализуется через триггеры, которые в Oracle можно деактивировать, данный способ управления базой правил поддерживается полностью + + +
2.1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события Для обнаружения сложных событий должен быть реализован специальный детектор. Простые события могут обнаруживаться с помощью триггеров + + —
Поддержка режима связывания Любое событие может снабжаться информацией о связанных с событием данных без каких-либо ограничений, так как в случае простых событий для этой цели служат переменные new и old, а для сложных событий детектор может объединять значения этих переменных, пришедших от разных простых событий + + +
Механизм проверки условий Проверка условий может состоять в извлечении из запуске соответствующего скрипта. При этом условию доступно текущее и предыдущее состояние связанных с событием данных + + +
Механизм выполнения действий Так как в Oracle поддерживаются триггеры типов AFTER и BEFORE, правило может выполняться до и после события. Действию доступны те же данные, что и условию + + +
2.2 Методы сцепления транзакций По умолчанию используется немедленное сцепление транзакций, при использовании автономных транзакций возможна реализация расцепленного метода + + —
2.3 Способы выявления сложных событий Встроенные средства реализации обнаружения сложных событий отсутствуют + — —
2.4 Управление историей событий Не все структуры, подходящие для хранения истории событий, могут быть реализованы эффективно. + + —
2.5 Механизмы разрешения коллизий Oracle поддерживает гибкие возможности параллельного выполнения + + +
3.1 Поддержка программной окружающей среды Перечисленные средства отсутствуют. Кроме того, многое из перечисленного необходимо реализовывать с привлечением не входящих в СУБД средств + — —
3.2 Настройка СУАБД Ограничений в возможности реализации настройки СУАБД нет + + +
Таблица 3 — Возможности СУБД Progress по реализации основных особенностей АБД
№ Особенность СУАБД Характеристики СУБД Progress Оценка
\—і \—і СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере. + + +
2 \—і Поддержка модели ECA-правил Определение типов событий Определяет события CREATE, DELETE, WRITE, ASSIGN, FIND. Все события имеют тип «до». Определение сложных событий отсутствует. + — —
i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
Определение условий Для представления условий и действий используется язык Progress 4GL (ABL). С версии 10 в нем реализована полная поддержка + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Информация о триггерах хранится в системных таблицах и доступна пользователям посредством специального инструмента — Data Dictionary. Код триггеров хранится отдельно от базы данных в файлах процедур(p-модулях). + + +
Поддержка эволюции базы правил Событие, условие и действие могут быть изменены, но для этого необходима перекомпиляция соответствующего p-модуля. + + —
Возможность активировать или деактивировать правила Для активации и деактивации правил используется специальная утилита. + + +
2.1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Обнаруживаются только простые события + — —
Поддержка режима связывания CREATE, WRITE, DELETE и FIND связаны с отдельным картежом, ASSIGN — с отдельным полем. + + —
Механизм проверки условий Условие имеет доступ к старым и новым значениям полей, может обращаться к другим объектам БД. + + +
Механизм выполнения действий Действие может изменять результат выполнения операции над базой данных, выполнять запросы на вставку, удаление и модификацию данных. + + +
2 2 Методы сцепления транзакций Реализовано только немедленное сцепление транзакций. Триггер всегда выполняется внутри вызвавшей его транзакции. + — —
3 2 Способы выявления сложных событий Механизм выявления сложных событий отсутствует. — — —
2 Управление историей событий История событий отсутствует — — —
LO 2 Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного пользователем режима блокировок. По умолчанию используется разделяемая (shared) блокировка для чтения и эксклюзивная (exclusive) для записи. + — —
1 3 Поддержка программной окружающей среды Доступны средства разработки классов, которые позволяют добавить в класс обработку некоторых событий. Специализированные средства для разработки правил отсутствуют. + — —
2 3 Настройка СУАБД Проектирование можно осуществлять с использованием трехуровневой модели + + +
Тип триггера определяется тем, какое событие его активизирует — INSERT (вставка), UPDATE (изменение) или DELETE (удаление). Триггеры могут активизироваться до (BEFORE) или после (AFTER) наступления события, а также для строки таблицы (кортежа) или оператора, вызвавшего события в целом. Если триггер является строковым (кортежным), то он активизируется один раз для каждой из строк, на которые воздействует оператор, который вызвал срабатывание триггера. Если триггер является операторным, то он активизируется один раз до или после выполнения оператора. Строковые триггеры содержат фразу FOR EACH ROW в описании триггера.
В таблице 1 представлены основные возможности СУБД MS SQL Server 2008 для реализации абстрактной модели и построения АБД. В таблице 2 представлены основные возможности СУБД Oracle 11g для реализации абстрактной модели и построения АБД. В таблице 3 представлены основные возможности СУБД Progress для реализации абстрактной модели и построения АБД.
Подводя итог анализу возможности реализации абстрактной модели АБД в современных реляционных СУБД, можно сделать вывод о том, что разработчик применяют в предоставляют триггеры и хранимые процедуры, как основной инструмент по реализации активных компонентов. Но триггеры срабатывают на определенный тип событий, такие как операции над данными или структурой БД, что накладывает ограничения на проектирование и разработку соответствующих средств управления АБД.
4. Реализация абстрактной модели АБД средствами объектно-ориентированных СУБД. Объектноориентированные базы данных (ООБД), в отличие от реляционных, изначально поддерживают близкую связь данных и поведения. Это выражается в объединении данных и методов в одну сущность (класс). Пользовательские методы позволяют определить требуемую реакцию ООБД на внешние события, например, для изменения состояния объекта пользователь вызывает метод setValue, который помимо установки нового значения поля объекта может выполнить дополнительные действия.
В ООБД схема данных строится в соответствии с объектно-ориентированной концепцией. База данных представляется пользователю в виде набора классов, каждый из которых обладает индивидуальностью -набором атрибутов и поведением — набором методов. Работа с базой данных ведется не в терминах запросов, как в реляционных БД, а в терминах работы с объектами — чтение атрибутов объекта и вызов его методов. В связи с этим слой активности ООБД должен поддержать обнаружение другого набора событий, таких как извлечение объекта из БД, вызов метода объекта, сохранение объекта из БД и т.п.
Обнаружение событий создания объекта, извлечения объекта из базы данных и сохранения объекта возможно с помощью механизма функций обратного вызова (Callback Methods).
Функции обратного вызова запускаются СУБД при выполнении определенных действий с объектом. Они являются аналогией механизма триггеров в реляционных СУБД. ООБД Cache поддерживает следующие функции обратного вызова:
%OnNew — вызывается при создании нового объекта в оперативной памяти в тот момент, когда выделена память под объект и инициализированы его свойства.
%OnOpen — функция вызывается перед извлечением существующего объекта из базы данных.
%OnDelet — данная функция вызывается перед удалением объекта.
%OnBeforSave и %OnAfterSave -вызываются непосредственно перед и сразу после сохранения объекта в базу данных соответственно.
Для обнаружения вызова методов в ООБД используют механизм оберток (wrappers). В наблюдаемый метод класса добавляется дополнительный код, уведомляющий уровень активности о наступлении события. Как правило, код добавляется в самом начале метода (до выполнения методом каких-либо действий) и в самом конце метода (перед возвратом результата). Обертка должна передать в уровень активности ссылку на объект, которому принадлежит вызванный метод, и список значений параметров вызванного метода.
Автоматическое добавление оберток к наблюдаемому методу требует доступа к информации об атрибутах и методах классов. Другими словами, должна иметься возможность изменять определение класса во время выполнения. В Cache эту задачу решает механизм классов-определений (Class Definition Classes). Механизм реализован в виде отдельного пакета (%Dictionary, словарь определений классов) и позволяет просматривать определения существующих в базе данных классов и вносить в них изменения.
Классы пакета %Dictionary позволяют получить полный доступ к определениям классов, находящихся в базе данных. Они дают возможность просматривать списки методов и атрибутов класса, добавлять новые атрибуты и методы и изменять существующие. Cache позволяет работать с определениями классов как с обычными объектами базы данных. Например, для создания нового класса необходимо создать объект класса %Dictionary.ClassDefinition, добавить к объекту методы и свойства и сохранить его в базу данных.
Рассмотренные выше способы обнаружения событий позволяют обнаружить события одного типа источников — StructureOp, операции над структурой БД. Теперь рассмотрим способы обнаружения других типов событий:
1) Тип события UserDefined. Пользовательская операция позволяет клиентской программе запустить выполнение некоторой программы на сервере. Этот тип события отличается от простого вызова метода тем, что метод может быть вызван не только по запросу пользователя, но и самой СУБД. При обнаружении данного типа события следует удостоверится, что запуск активности был инициирован пользовательской программой. Это может быть реализовано созданием в базе данных отдельного класса для хранения пользовательских событий (UserAction). Объекты класса будет хранить описание события и дополнительную связанную с событием информацию (Например, событие «Пользователь входит в систему» может в качестве дополнительной информации хранить введенные пользователем логин и пароль). Активация события будет производиться вызовом специального метода объекта UserAction.FireAction().
2) Тип события Clock. Можно выделить два способа обнаружения событий наступления определенного
момента времени. Первый способ заключается в написании программы на Cache Object Script, выполняющейся на сервере и периодически проверяющей наступление события. Этот подход обладает более высокой производительностью (отсутствуют затраты на взаимодействие сервера Cache и клиента планировщика), но страдает недостаточной гибкостью. Второй способ заключается в использовании сторонних программ-планировщиков для запуска задач по расписанию (at, Cron, Anacron в Linux, TaskScheduler в Windows). В качестве задачи планировщику можно назначить выполнение автоматически генерируемого скрипта или запрос URL, содержащего CGI программу активации события. Преимущество этого способа заключается в возможности использования различных программ-планировщиков или даже написания своих для поддержания особой функциональности. На мой взгляд, при разработке уровня активности следует поддержать оба подхода: первый для обеспечения базовой функциональности и второй, в виде Web-интерфейса для внешних
программ-планировщиков, для обеспечения расширяемости.
3) Тип события External. Внешние события можно разделить на две категории: события периферийных
устройств и удаленные события. Для обнаружения событий периферийных устройств можно использовать библиотеку управления вводом/выводом (Cachte I/O Device). Данная библиотека позволяет работать с периферийными устройствами напрямую из методов объектов с использованием языка Cache Object Script. Cache поддерживает работу с разнообразным периферийным оборудованием, в том числе принтерами, жесткими дисками, магнитными лентами, терминалами и многими другими.
Если событие происходит на удаленном компьютере и обнаружить его напрямую невозможно, назовем его удаленным событием. Например, Cache может получать данные от внешних web-сервисов и при определенных сочетаниях полученных значений активировать ECA-правила. Для работы с web-сервисами по протоколу HTTP из Cache Object Script можно использовать библиотеку %Net и класс %Net.HttpRequest.
4) Тип события Exception. Для обнаружения возникновения ошибочных ситуации в СУБД используется механизм обработчика ошибок (Error handler). Cache позволяет при возникновении ошибки передать управление пользовательской функции-обработчику.Для этого устанавливается значение системной переменой $ETRAP.
SET $ETRAP=»GOTO LogErrorAErrRoutine»
Переменная $ETRAP содержит код на Cache Object Script, который выполняется при возникновении ошибки. В приведенном выше примере управление передается функции LogError (которая является частью функции ErrRoutine). Функции-обработчикудоступна следующая информация:
1) Тип контекста (DO, EXCUTE или функция пользователя);
2) Номер строки в исходном тексте, где произошла ошибка;
Таблица 4 — Возможности СУБД Cache по реализации основных особенностей АБД
№ Особенность СУАБД Характеристики СУБД Cache 2009.1 Оценка
І І СУАБД есть просто СУБД Функциональность пассивных СУБД присутствует в полной мере. + + +
2 І Поддержка модели ECA-правил Определение типов событий Определяет события «до» и «после» для некоторых событий. Определение сложных событий отсутствует. + — —
Определение условий Для представления условия используется язык Cache Object Script, являющийся полноценным объектноориентированным языком программирования. + + +
Определение действия Для представления действия используется язык Cache Object Script, являющийся полноценным объектно-ориентированным языком программирования. + + +
1.3 Средства для управления базами правил и их эволюции Управление базами правил Централизованное хранение правил отсутствует, но информацию о правилах можно получить из описания класса. + — —
Поддержка эволюции базы правил Событие, условие и действие могут быть изменены, но для этого необходима перекомпиляция класса. + + —
Возможность активировать или деактивировать правила Возможность активации и деактивации правил отсутствует.
\—1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. Обнаруживаются только простые события + — —
Поддержка режима связывания Событие связывается только с конкретным объектом + — —
Механизм проверки условий Условие имеет доступ только к текущему состоянию объекта, может обращаться к другим объектам БД. + + —
Механизм выполнения действий Возможно выполнение любого действия с базой данных (создание и удаление объектов, вызов методов и т.д.) + + +
Методы сцепления транзакций Реализовано только немедленное сцепление транзакций. + — —
ГО CN Способы выявления сложных событий Механизм выявления сложных событий отсутствует.
CN Управление историей событий История событий отсутствует
LO CN Механизмы разрешения коллизий Разрешение коллизий зависит от выбранного пользователем режима блокировок. По умолчанию блокировки не используются. + — —
\—1 ГО Поддержка программной окружающей среды Доступны средства разработки классов (Cache Studio), которые позволяют добавить в класс обработку некоторых событий. Специализированные средства для разработки правил отсутствуют. + — —
CN ГО Настройка СУАБД Проектирование можно осуществлять с использованием трехуровневой модели + + —
Таблица 5 — Обобщенные результаты анализа возможностей СУБД по реализации абстрактной модели и
№ Особенность СУАБД Cache Progress Oracle
\—і \—і СУАБД есть просто СУБД + + + +++ + + + + + +
\—1 Поддержка модели ЕСА-правил Определение типов событий + — — + — — + — — + + —
ГО \—1 Средства для управления базами правил и их эволюции Управление базами правил + — — + — — + + + + + +
Поддержка эволюции базы правил + + — ++- + + — + + +
Возможность активировать или деактивировать правила + + + + + +
\—1 СУАБД включает в себя исполняющий модуль Обнаружение возникновения события. + — — + — — + — — + + —
Поддержка режима связывания + — — + — — + + — + + +
Механизм проверки условий + + — +++ + + + + + +
Механизм выполнения действий + + + ++ — + + + + + +
Методы сцепления транзакций + — — +++ + — — + + —
ГО Способы выявления сложных событий — — — — — — + — —
Управление историей событий — — — ++ — — — — + + —
LO Механизмы разрешения коллизий + — — ++ — + — — + + +
\—1 ГО Поддержка программной окружающей среды + — — + — — + — —
ГО Настройка СУАБД + + — +++ + + + + + +
Таким образом, обнаружение событий типа Exception сводится к установке обработчика, который будет информировать слой активности о всех возникающих ошибках.
5) Тип события Transaction. Из событий управления транзакциями Cache поддерживает обнаружение только событие отката транзакции. Обнаружить событие можно с помощью функции обратного вызова %OnRollBack. Функция вызывается перед началом отката транзакции.
Откат транзакции может быть остановлен (для этого необходимо вернуть код ошибки, отличный от $$$OK). Начало транзакции может быть косвенно определено как вызов метода %Save объекта (вызов %Save автоматически начинает транзакцию). Однако этот метод не является надежным, т.к. Cache позволяет сохранить несколько объектов в одной транзакции с помощью специальных конструкций Cache Object Script (TSTART, TCOMMIT, TROLLBACK).
Основные возможности СУБД Cache для реализации абстрактной модели и построения АБД представлены в таблице 4. Выделенные особенности СУБД Cache показывают, что в данной системе реализован большой функционал по определению событий, которые является одним из основных компонентов активной базы данных. Данный функционал значительно шире, чем в традиционных реляционных базах данных, что является следствием объектно-ориентированной структуры данных. Таким образом, Cache находится ближе к понятию активных баз и предоставляет значительно шире набор инструментов по реализации абстрактной модели АБД для пользователя.
Обобщенные результаты сравнительного анализа возможностей СУБД по реализации абстрактной модели и разработке АБД сведены в таблицу 5. Они показывают, что современные коммерческие СУБД обладают средствами, позволяющие реализовывать в рамках той или иной модели данных активные базы данных и управление активностью. Однако применение данных средств требует разработки прикладного программного обеспечения и не позволяет реализовывать полномасштабные систему управления активными базами данных.
Выход ознакомительной версии 8.3 (8.3.1) платформы системы программ «1С:Предприятие»
Данная версия предназначена для ознакомления пользователей и партнеров фирмы «1С» с новыми возможностями платформы. Версия платформы 8.3.1 доступна без дополнительной оплаты зарегистрированным пользователям системы «1С:Предприятие 8», заключившим договор 1С:ИТС.
- получили развитие «облачные» технологии и технологии работы через Интернет; переработаны и расширены механизмы масштабируемости кластера серверов;
- расширены средства администрирования;
- реализованы клиентские приложения и инструменты администрирования для Linux;
- реализована выгрузка конфигурации в набор файлов и загрузка из него;
- доработан механизм внешних источников данных;
- реализованы новые возможности работы со сложными аналитическими отчетами;
- улучшено юзабилити;
- оптимизирована работа системы, в том числе с различными СУБД.
Помимо перечисленного, в новой версии реализовано множество других новых возможностей.
Уважаемые клиенты, знакомьтесь с изменениями, сообщайте о замеченных недостатках и проблемах ознакомительной версии. От полученной от пользователей и партнеров информации зависят планы выпуска финальной версии 8.3.
Что такое СУБД
Система управления базами данных (СУБД) – это комплекс программно-языковых средств, позволяющих создать базы данных и управлять данными. Иными словами, СУБД — это набор программ, позволяющий организовывать, контролировать и администрировать базы данных. Большинство сайтов не могут функционировать без базы данных, поэтому СУБД используется практически повсеместно.
- Подробнее о СУБД
- SQL и реляционные БД: почему в них важно разбираться
- Наиболее популярные СУБД
Подробнее о СУБД
Основные функции СУБД:
- управление данными во внешней памяти (на дисках);
- управление данными в оперативной памяти с использованием дискового кэша;
- журнализация изменений (сохранение истории), резервное копирование и восстановление базы данных после сбоев;
- поддержка языков БД (язык определения данных, язык манипулирования данными).
Каждая СУБД основывается на какой-либо модели данных, это является одним из признаков классификации. По модели данных СУБД бывают:
- Иерархические. В этой модели данных используется представление БД в виде древовидной структуры, состоящей из данных разных уровней.
- Сетевые. Данная модель является расширением иерархического подхода. Иерархическая модель подразумевает, что запись-потомок может иметь строго одного предка, в то время как в сетевой структуре потомок может иметь любое количество предков.
- Реляционные. СУБД, ориентированные на организацию данных как набор связанных записей и атрибутов в двумерной таблице.
- Объектно-ориентированные. Для управления БД, основанными на объектной модели данных. Как правило основываются на объектно-ориентированных языках программирования.
- Объектно-реляционные. Объединяет в себе концепции реляционной модели с дополнительными объектно-ориентированными возможностями.
SQL и реляционные БД: почему в них важно разбираться
Сегодня по-прежнему наиболее популярными при создании веб-приложений и сервисов остаются реляционные базы данных. Для управления реляционными базами данных используется язык SQL (Structured Query Language — структурированный язык запросов). Изначально SQL был инструментом работы пользователя с базой данных, однако со временем язык усложнился и стал скорее инструментом разработчика, чем конечного пользователя.
Наиболее популярные СУБД
Различные рейтинги самых популярных СУБД возглавляют Oracle, MySQL , Microsoft SQL Server, PostgreSQL.
MySQL
Считается одной из самых распространенных СУБД. MySQL — реляционная СУБД с открытым исходным кодом, главными плюсами которой являются ее скорость и гибкость, которая обеспечена поддержкой большого количества различных типов таблиц.
Кроме того, это надежная бесплатная система с простым интерфейсом и возможностью синхронизации с другими базами данных. В совокупности эти факторы позволяют использовать MySQL как крупным корпорациям, так и небольшим компаниям.
Microsoft SQL Server
Как следует из названия, фирменная СУБД, разработанная Microsoft. Оптимальная для использования в операционных системах семейства Windows, однако может работать и с Linux.
Система позволяет синхронизироваться с другими программными продуктами компании Microsoft, а также обеспечивает надежную защиту данных и простой интерфейс, однако отличается высокой стоимостью лицензии и повышенным потреблением ресурсов.
В целом, однако, сохраняет свою популярность, в немалой степени из-за того, что продукты корпорации Microsoft используются многими компаниями.
PostgreSQL
СУБД PostgreSQL — еще одна популярная и бесплатная система. Наибольшее применение нашла для управления БД веб-сайтов и различных сервисов. Она универсальна, то есть подойдет для работы с большинством популярных платформ.
При этом PostgreSQL — объектно-реляционная СУБД, что дает ей некоторые преимущества над другими бесплатными СУБД, в большинстве являющимися реляционными.
Oracle
Первая версия этой объектно-реляционной СУБД появилась в конце 70-х, и с тех пор зарекомендовала себя как надежная, функциональная и практичная. СУБД Oracle постоянно развивается и дорабатывается, упрощая установку и первоначальную настройку и расширяя функционал.
Однако существенным минусом данной СУБД является высокая стоимость лицензии, поэтому она используется в основном крупными компаниями и корпорациями, работающими с огромными объемами данных.
Мультимодельные СУБД — основа современных информационных систем?
Современные информационные системы достаточно сложны. Не в последнюю очередь их сложность обусловлена сложностью обрабатываемых в них данных. Сложность же данных зачастую заключается в многообразии используемых моделей данных. Так, например, когда данные становятся «большими», одной из доставляющих неудобства характеристик считается не только их объем («volume»), но и их разнообразие («variety»).
Если вы пока не находите изъяна в рассуждениях, то читайте дальше.
Содержание статьи
Polyglot persistence
Сказанное выше приводит к тому, что порою в рамках даже одной системы приходится для хранения данных и решения различных задач по их обработке использовать несколько различных СУБД, каждая из которых поддерживает свою модель данных. С легкой руки М. Фаулера, автора ряда известных книг и одного из соавторов Agile Manifesto, такая ситуация получила название многовариантного хранения («polyglot persistence»).
Фаулеру принадлежит и следующий пример организации хранения данных в полнофункциональном и высоконагруженном приложении в сфере электронной коммерции.
Пример этот, конечно, несколько утрированный, но некоторые соображения в пользу выбора той или иной СУБД для соответствующей цели можно найти, например, здесь.
Понятно, что быть служителем в таком зоопарке нелегко.
- Объем кода, выполняющего сохранение данных, растет пропорционально числу используемых СУБД; объем кода, синхронизирующего данные, — хорошо если не пропорционально квадрату этого числа.
- Кратно числу используемых СУБД возрастают затраты на обеспечение enterprise-характеристик (масштабируемости, отказоустойчивости, высокой доступности) каждой из используемых СУБД.
- Невозможно обеспечить enterprise-характеристики подсистемы хранения в целом — особенно транзакционность.
С точки зрения директора зоопарка все выглядит так:
- Кратное увеличение стоимости лицензий и техподдержки от производителя СУБД.
- Раздутие штата и увеличение сроков.
- Прямые финансовые потери или штрафные санкции из-за несогласованности данных.
Имеет место значительный рост совокупной стоимости владения системой (TCO). Есть ли из ситуации «многовариантного хранения» какой-то выход?
Мультимодельность
Термин «многовариантное хранение» вошел в обиход в 2011 году. Осознание проблем подхода и поиск решения заняли несколько лет, и к 2015 году устами аналитиков Gartner ответ был сформулирован:
Будущее СУБД, их архитектур и способов использования — мультимодельность.
Ведущие операционные СУБД будут предлагать несколько моделей — реляционную и нереляционные — в составе единой платформы.
Похоже, что в этот раз аналитики Gartner с прогнозом не ошиблись. Если зайти на страницу с основным рейтингом СУБД на DB-Engines, можно увидеть, что большая часть его лидеров позиционирует себя именно как мультимодельные СУБД. То же можно увидеть и на странице с любым частным рейтингом.
В таблице ниже приведены СУБД — лидеры в каждом из частных рейтингов, заявляющие о своей мультимодельности. Для каждой СУБД указаны первоначальная поддерживаемая модель (когда-то бывшая единственной) и наряду с ней модели, поддерживаемые сейчас. Также приведены СУБД, позиционирующие себя как «изначально мультимодельные», не имеющие по заявлениям создателей какой-либо первоначальной унаследованной модели.
СУБД | Изначальная модель | Дополнительные модели |
---|---|---|
Oracle | Реляционная | Графовая, документная |
MS SQL | Реляционная | Графовая, документная |
PostgreSQL | Реляционная | Графовая*, документная |
MarkLogic | Документная | Графовая, реляционная |
MongoDB | Документная | Ключ-значение, графовая* |
DataStax | Wide-column | Документная, графовая |
Redis | Ключ-значение | Документная, графовая* |
ArangoDB | — | Графовая, документная |
OrientDB | — | Графовая, документная |
Azure CosmosDB | — | Графовая, документная, реляционная |
Примечания к таблице
Звездочками в таблице помечены утверждения, требующие оговорок:
- СУБД PostgreSQL не поддерживает графовую модель данных, однако ее поддерживает такой продукт на ее основе, как, например, AgensGraph.
- Применительно к MongoDB правильнее говорить скорее о наличии графовых операторов в языке запросов ( $lookup , $graphLookup ), чем о поддержке графовой модели, хотя, конечно, их введение потребовало некоторых оптимизаций на уровне физического хранения в направлении поддержки графовой модели.
- Применительно к Redis имеется в виду расширение RedisGraph.
Далее для каждого из классов мы покажем, как реализуется поддержка нескольких моделей в СУБД из этого класса. Наиболее важными будем считать реляционную, документную и графовую модели и на примерах конкретных СУБД показывать, как реализуются «недостающие».
Мультимодельные СУБД на основе реляционной модели
Ведущими СУБД в настоящее время являются реляционные, прогноз Gartner нельзя было бы считать сбывшимся, если бы РСУБД не демонстрировали движения в направлении мультимодельности. И они демонстрируют. Теперь соображения о том, что мультимодельная СУБД подобна швейцарскому ножу, которым ничего нельзя сделать хорошо, можно направлять сразу Ларри Эллисону.
Автору, однако, больше нравится реализация мультимодельности в Microsoft SQL Server, на примере которого поддержка РСУБД документной и графовой моделей и будет описана.
Документная модель в MS SQL Server
О том, как в MS SQL Server реализована поддержка документной модели, на Хабре уже было две отличных статьи, ограничусь кратким пересказом и комментарием:
- Работаем с JSON в SQL Server 2016
- SQL Server 2017 JSON
Способ поддержки документной модели в MS SQL Server достаточно типичен для реляционных СУБД: JSON-документы предлагается хранить в обычных текстовых полях. Поддержка документной модели заключается в предоставлении специальных операторов для разбора этого JSON:
- JSON_VALUE для извлечения скалярных значений атрибутов,
- JSON_QUERY для извлечения поддокументов.
Вторым аргументом обоих операторов является выражение в JSONPath-подобном синтаксисе.
Абстрактно можно сказать, что хранимые таким образом документы не являются в реляционной СУБД «сущностями первого класса», в отличие от кортежей. Конкретно в MS SQL Server в настоящее время отсутствуют индексы по полям JSON-документов, что делает затруднительными операции соединения таблиц по значениям этих полей и даже выборку документов по этим значениям. Впрочем, возможно создать по такому полю вычислимый столбец и индекс по нему.
Дополнительно MS SQL Server предоставляет возможность удобно конструировать JSON-документ из содержимого таблиц с помощью оператора FOR JSON PATH — возможность, в известном смысле противоположную предыдущей, обычному хранению. Понятно, что какой бы быстрой ни была РСУБД, такой подход противоречит идеологии документных СУБД, по сути хранящих готовые ответы на популярные запросы, и может решать лишь проблемы удобства разработки, но не быстродействия.
Наконец, MS SQL Server позволяет решать задачу, обратную конструированию документа: можно разложить JSON по таблицам с помощью OPENJSON . Если документ не совсем плоский, потребуется использовать CROSS APPLY .
Графовая модель в MS SQL Server
Поддержка графовой ( LPG ) модели реализована в Microsoft SQL Server тоже вполне предсказуемо: предлагается использовать специальные таблицы для хранения узлов и для хранения ребер графа. Такие таблицы создаются с использованием выражений CREATE TABLE AS NODE и CREATE TABLE AS EDGE соответственно.
Таблицы первого вида сходны с обычными таблицами для хранения записей с тем лишь внешним отличием, что в таблице присутствует системное поле $node_id — уникальный в пределах базы данных идентификатор узла графа.
Аналогично, таблицы второго вида имеют системные поля $from_id и $to_id , записи в таких таблицах понятным образом задают связи между узлами. Для хранения связей каждого вида используется отдельная таблица.
Проиллюстрируем сказанное примером. Пусть графовые данные имеют схему как на приведенном рисунке. Тогда для создания соответствующей структуры в базе данных нужно выполнить следующие DDL-запросы:
CREATE TABLE Person ( ID INTEGER NOT NULL, name VARCHAR(100) ) AS NODE; CREATE TABLE Cafe ( ID INTEGER NOT NULL, name VARCHAR(100), ) AS NODE; CREATE TABLE likes ( rating INTEGER ) AS EDGE; CREATE TABLE friendOf AS EDGE; /* Возможно в SQL Server 2019: ALTER TABLE likes ADD CONSTRAINT EC_LIKES CONNECTION (Person TO Cafe); */
Основная специфика таких таблиц заключается в том, что в запросах к ним возможно использовать графовые паттерны с Cypher-подобным синтаксисом (впрочем, « * » и пр. пока не поддерживаются). Также на основе измерений производительности можно предположить, что способ хранения данных в этих таблицах отличен от механизма хранения данных в обычных таблицах и оптимизирован для выполнения подобных графовых запросов.
SELECT Cafe.name FROM Person, likes, Cafe WHERE MATCH (Person-(friendOf)-(likes)->Cafe) AND Person.name = 'John';
Более того, довольно трудно при работе с такими таблицами эти графовые паттерны не использовать, поскольку в обычных SQL-запросах для решения аналогичных задач потребуется предпринимать дополнительные усилия для получения системных «графовых» идентификаторов узлов ( $node_id , $from_id , $to_id ; по этой же причине запросы на вставку данных не приведены здесь как слишком громоздкие).
Подводя итог описанию реализаций документной и графовой моделей в MS SQL Server, я бы отметил, что подобные реализации одной модели поверх другой не кажутся удачными в первую очередь с точки зрения языкового дизайна. Требуется расширять один язык другим, языки не вполне «ортогональны», правила сочетаемости могут быть довольно причудливы.
Мультимодельные СУБД на основе документной модели
В этом разделе хочется проиллюстрировать реализацию мультимодельности в документных СУБД на примере не наиболее популярной из них MongoDB (как было сказано, в ней есть лишь условно графовые операторы $lookup и $graphLookup , не работающие на шардированных коллекциях), а на примере более зрелой и «энтерпрайзной» СУБД MarkLogic.
Итак, пусть коллекция содержит набор XML-документов следующего вида (хранить JSON-документы MarkLogic тоже позволяет):
John Smith
Реляционная модель в MarkLogic
Реляционное представление коллекции документов можно создать с помощью шаблона отображения (содержимым элементов value в примере ниже может быть произвольный XPath):
/Person Person SSN @SSN string name name surname surname
К созданному представлению можно адресовать SQL-запрос (например, через ODBC):
SELECT name, surname FROM Person WHERE name="John"
К сожалению, созданное с помощью шаблона отображения реляционное представление доступно только для чтения. При обработке запроса к нему MarkLogic попытается использовать документные индексы. Прежде в MarkLogic были и ограниченные реляционные представления, целиком основанные на индексах и доступные на запись, но сейчас они считаются deprecated.
Графовая модель в MarkLogic
С поддержкой графовой ( RDF ) модели все обстоит примерно так же. Опять-таки с помощью шаблона отображения можно создать RDF-представление коллекции документов из примера выше:
/Person PREFIX "http://example.org/example#" sem:iri( $PREFIX || @SSN ) sem:iri( $PREFIX || surname ) sem:iri( $PREFIX || @SSN ) sem:iri( $PREFIX || name )
К полученному RDF-графу можно адресовать SPARQL-запрос:
PREFIX : SELECT ?name ?surname
В отличие от реляционной, графовую модель MarkLogic поддерживает еще двумя другими способами:
- СУБД может быть полноценным отдельным хранилищем RDF-данных (триплеты в нем будут называться managed в противоположность описанным выше extracted).
- RDF в специальной сериализации может быть попросту вставлен в XML- или JSON-документы (и триплеты тогда будут называться unmanaged). Вероятно, это такая альтернатива механизмам idref и пр.
Хорошее представление о том, как «на самом деле» все устроено в MarkLogic, дает Optic API, в этом смысле оно низкоуровневое, хотя назначение его скорее обратное — попробовать абстрагироваться от используемой модели данных, обеспечить согласованную работу с данными в различных моделях, транзакционность и пр.
Мультимодельные СУБД «без основной модели»
На рынке также представлены СУБД, позиционирующие себя как изначально мультимодельные, не имеющие никакой унаследованной основной модели. К их числу относятся ArangoDB, OrientDB (c 2018 года компания-разработчик принадлежит SAP) и CosmosDB (сервис в составе облачной платформы Microsoft Azure).
На самом деле «основные» модели в ArangoDB и OrientDB есть. Это в том и в другом случае собственные модели данных, являющиеся обобщениями документной. Обобщения заключаются в основном в облегчении возможности производить запросы графового и реляционного характера.
Эти модели являются в указанных СУБД единственно доступными для использования, для работы с ними предназначены собственные языки запросов. Безусловно, такие модели и СУБД перспективны, однако отсутствие совместимости со стандартными моделями и языками делает невозможным использование этих СУБД в унаследованных системах — замену ими уже используемых там СУБД.
Про ArangoDB и OrientDB на Хабре уже была замечательная статья: JOIN в NoSQL базах данных.
ArangoDB
ArangoDB заявляет поддержку графовой модели данных.
Узлы графа в ArangoDB — это обычные документы, а ребра — документы специального вида, имеющие наряду с обычными системными полями ( _key , _id , _rev ) системные поля _from и _to . Документы в документных СУБД традиционно объединяются в коллекции. Коллекции документов, представляющих ребра, в ArangoDB называются edge-коллекциями. К слову, документы edge-коллекций — это тоже документы, поэтому ребра в ArangoDB могут выступать также и узлами.
Исходные данные
Пусть у нас есть коллекция persons , документы которой выглядят так:
Пусть также есть коллекция cafes :
Тогда коллекция likes может выглядеть следующим образом:
Запросы и результаты
Запрос в графовом стиле на используемом в ArangoDB языке AQL, возвращающий в человекочитаемом виде сведения о том, кому какое кафе нравится, выглядит так:
FOR p IN persons FOR c IN OUTBOUND p likes RETURN
В реляционном стиле, когда мы скорее «вычисляем» связи, а не храним их, этот запрос можно переписать так (к слову, без коллекции likes можно было бы обойтись):
FOR p IN persons FOR l IN likes FILTER p._key == l._from FOR c IN cafes FILTER l._to == c._key RETURN
Результат в обоих случаях будет один и тот же:
Еще запросы и результаты
Если кажется, что формат результата выше характерен больше для реляционной СУБД, чем для документной, можно попробовать такой запрос (либо можно воспользоваться COLLECT ):
FOR p IN persons RETURN
Результат будет иметь следующий вид:
OrientDB
В основе реализации графовой модели поверх документной в OrientDB лежит возможность полей документов иметь помимо более-менее стандартных скалярных значений еще и значения таких типов, как LINK , LINKLIST , LINKSET , LINKMAP и LINKBAG . Значения этих типов — ссылки или коллекции ссылок на системные идентификаторы документов.
Присваиваемый системой идентификатор документа имеет «физический смысл», указывая позицию записи в базе, и выглядит примерно так: @rid : #3:16 . Тем самым значения ссылочных свойств — действительно скорее указатели (как в графовой модели), а не условия отбора (как в реляционной).
Как и в ArangoDB, в OrientDB ребра представляются отдельными документами (хотя если у ребра нет своих свойств, его можно сделать легковесным, и ему не будет соответствовать отдельный документ).
Исходные данные
В формате, приближенном к формату дампа базы OrientDB, данные из предыдущего примера для ArangoDB выглядели бы примерно так:
Как мы видим, вершины тоже хранят сведения о входящих и исходящих ребрах. При использовании Document API за ссылочной целостностью приходится следить самому, а Graph API берет эту работу на себя. Но посмотрим, как выглядят обращение к OrientDB на «чистых», не интегрированных в языки программирования, языках запросов.
Запросы и результаты
Запрос, аналогичный по назначению запросу из примера для ArangoDB, в OrientDB выглядит так:
SELECT name AS person_name, OUT('likes').name AS cafe_name FROM Person UNWIND cafe_name
Результат будет получен в следующем виде:
Если формат результата опять кажется чересчур «реляционным», нужно убрать строку с UNWIND() :
Язык запросов OrientDB можно охарактеризовать как SQL c Gremlin-подобными вставками. В версии 2.2 появилась Cypher-подобная форма запроса, MATCH :
MATCH -likes-> RETURN person.name AS person_name, LIST(cafe.name) AS cafe_name GROUP BY person_name
Формат результата будет таким же, как в предыдущем запросе. Подумайте, что нужно убрать, чтобы сделать его более «реляционным», как в самом первом запросе.
Azure CosmosDB
В меньшей степени сказанное выше об ArangoDB и OrientDB относится к Azure CosmosDB. CosmosDB предоставляет следующие API доступа к данным: SQL, MongoDB, Gremlin и Cassandra.
SQL API и MongoDB API используются для доступа к данным в документной модели. Gremlin API и Cassandra API — для доступа к данным соответственно в графовой и колоночной. Данные во всех моделях сохраняются в формате внутренней модели CosmosDB: ARS («atom-record-sequence»), которая также близка к документной.
Но выбранная пользователем модель данных и используемый API фиксируются в момент создания аккаунта в сервисе. Невозможно получить доступ к данным, загруженным в одной модели, в формате другой модели, что иллюстрировалось бы примерно таким рисунком:
Тем самым мультимодельность в Azure CosmosDB на сегодняшний день представляет собой лишь возможность использовать несколько баз данных, поддерживающих различные модели, от одного производителя, что не решает всех проблем многовариантного хранения.
Мультимодельные СУБД на основе графовой модели?
Обращает на себя внимание тот факт, что на рынке пока нет мультимодельных СУБД, имеющих в основе графовую модель (если не считать мультимодельностью поддержку одновременно двух графовых моделей: RDF и LPG; см. об этом в предыдущей публикации). Наибольшие затруднений вызывает реализация поверх графовой модели документной, а не реляционной.
Вопрос о том, как реализовать поверх графовой модели реляционную, рассматривался еще во времена становления этой последней. Как говорил, например, Дэвид Макговерен:
There is nothing inherent in the graph approach that prevents creating a layer (e.g., by suitable indexing) on a graph database that enables a relational view with (1) recovery of tuples from the usual key value pairs and (2) grouping of tuples by relation type.
При реализации же документной модели поверх графовой нужно иметь в виду, например, следующее:
- Элементы JSON-массива считаются упорядоченными, исходящие из вершины ребра графа — нет;
- Данные в документной модели обычно денормализованы, хранить несколько копий одного и того же вложенного документа все же не хочется, а идентификаторов у поддокументов обычно нет;
- С другой стороны, идеология документных СУБД в том и заключается, что документы являются готовыми «агрегатами», которые не нужно каждый раз строить заново. Требуется обеспечить в графовой модели возможность быстро получить подграф, соответствующий готовому документу.
Немного рекламы
Автор статьи имеет отношение к разработке СУБД NitrosBase, внутренняя модель которой является графовой, а внешние модели — реляционная и документная — являются её представлениями. Все модели равноправны: практически любые данные доступны в любой из них с использованием естественного для неё языка запросов. Более того, в любом представлении данные могут быть изменены. Изменения отразятся во внутренней модели и, соответственно, в других представлениях.
Как выглядит соответствие моделей в NitrosBase — опишу, надеюсь, в одной из следующих статей.
Заключение
Надеюсь, что общие контуры того, что называется мультимодельностью, стали читателю более-менее ясны. Мультимодельными называются достаточно разные СУБД, и «поддержка нескольких моделей» может выглядеть по-разному. Для понимания того, что называют «мультимодельностью» в каждом конкретном случае, полезно ответить на следующие вопросы:
- Идет ли речь о поддержке традиционных моделей или же о некоей одной гибридной модели?
- «Равноправны» ли модели, или одна из них является подлежащей для других?
- «Безразличны» ли модели друг другу? Могут ли данные, записанные в одной модели, быть прочитанными в другой или даже перезаписаны?
Думаю, на вопрос об актуальности мультимодельных СУБД уже можно дать положительный ответ, но интересен вопрос о том, какие именно их разновидности будут более востребованы в ближайшее время. Похоже, более востребованы будут мультимодельные СУБД, поддерживающие традиционные модели, в первую очередь, реляционную; популярность же мультимодельных СУБД, предлагающих новые модели, сочетающие в себе достоинства различных традиционных, — дело более отдаленного будущего.