CC BY
562
МАТЕМАТИЧЕСКОЕ И ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ ВЫЧИСЛИТЕЛЬНЫХ МАШИН...
УДК 004.65:378.2
Е. С. Макарова, В. В. Миронов
ПРОЕКТИРОВАНИЕ КОНЦЕПТУАЛЬНОЙ МОДЕЛИ ДАННЫХ ДЛЯ ЗАДАЧ WEB-OLAP НА ОСНОВЕ СИТУАЦИОННО-ОРИЕНТИРОВАННОЙ БАЗЫ ДАННЫХ
Обсуждается реализация Web-OLAP, предусматривающего формирование гиперкубов «на лету» из ситуационно-ориентированной базы данных (СОБД). Рассматривается архитектура OLAP-приложения на основе СОБД. Используется ER-модель базы данных в качестве основы концептуальной многомерной модели, задающей множество потенциальных гиперкубов. Обсуждаются вопросы проектирования измерений и мер гиперкубов. Подход иллюстрируется на примере построения многомерной модели деятельности диссертационных советов вуза. Web-OLAP^, многомерная модель данных; многокубовая модель данных; ER-модель; ситуационно-ориентированная база данных; диссертационные советы вуза
Традиционно оперативная аналитическая обработка данных (On-Line Analytical Processing - OLAP) предполагает проведение сложного анализа больших объемов данных с высокой производительностью. Понятие OLAP введено как противоположность оперативной обработки транзакций (On-Line Transaction Processing -OLTP) [1]. Базы данных, ориентированные на OLAP, основаны на многомерной (гиперкубовой) модели; для повышения производительности в них сознательно вводится избыточность в виде предварительной агрегации данных.
В настоящее время с появлением достаточно универсальных OLAP-клиентов возможности оперативной аналитической обработки стали доступны и для мало- и среднемасштабных баз данных OLTP. В связи с этим появились новые термины: «настольный OLAP», «Web OLAP» и т. п. [2]. Настольный OLAP предполагает построение и хранение гиперкуба на компьютере пользователя, позволяя проводить анализ данных в однопользовательском режиме. Web-OLAP предполагает выполнение аналитических функций в многопользовательском режиме через Веб. В обоих случаях формирование гиперкубов, как правило, происходит «на лету» («on the fly»), из базы данных OLTP, без предварительной агрегации.
Другой современной тенденцией является поиск новых подходов к организации баз данных, более эффективных при обработке данных в Веб. Хотя реляционные и объектно-реляционные базы данных сохраняют лидирующие позиции, развиваются альтернативные подходы, например, в рамках движения NoSQL [3].
Контактная информация: 8(347)273-78-23.
Работа поддержана грантом РФФИ 10-07-00167-а.
К этому направлению относятся и ситуационноориентированные базы данных (СОБД) [4-9]. СОБД хранит XML-данные, ассоциированные с состояниями встроенной динамической модели (модели развития ситуаций). Для динамической модели отслеживаются текущие состояния и предоставляется доступ к данным в контексте текущих ситуаций. Это удобно, например, при создании веб-приложений с динамическим формированием контента. Архитектура СОБД включает библиотеку динамических моделей (HSML), хранилище - память ассоциированных данных (ADM), память текущего состояния (CSM), библиотеку ассоциированных функций (AFL), интерпретатор динамической модели (HSMI). В ответ на внешний запрос интерпретатор формирует ответ путем обработки определенной динамической модели HSM из HSML на основе отслеживания ее текущих состояний, сохраняемых в CSM, обработки ассоциированных данных из ADM и выполнения ассоциированных функций из AFL.
В этой статье СОБД рассматриваются в плане реализации на их основе возможностей OLAP для анализа данных в контексте текущих ситуаций.
АРХИТЕКТУРА ВЕБ-ПРИЛОЖЕНИЯ C OLAP-ВОЗМОЖНОСТЯМИ НА ОСНОВЕ СОБД
Архитектура веб-приложения на основе СОБД, предоставляющая возможности OLAP, показана на рис. 1. Веб-приложение выполняется на сервере (Web server), для доступа к которому через Интернет на клиентской машине используется веб-браузер (Web browser), выполняющий роль «тонкого клиента».
Web
Server
Relational
Database
Рис. 1. Архитектура веб-приложения с OLAP-возможностями, основанная на СОБД
В ответ на клиентский запрос веб-сервер генерирует и отправляет в браузер клиентскую страницу (Client Page), сформированную на основе данных из СОБД (SODB) в соответствии с текущим состоянием.
Для поддержания OLAP-функциональности на клиентской стороне необходим OLAP-клиент (роль которого в нашем случае исполняет плагин Flash Player). Это версия «тонкого» клиента, означающая, что все данные хранятся и обрабатываются на сервере, а на клиентской стороне происходит воспроизведение результатов и прием команд пользователя.
Браузер получает страницу, содержащую OLAP-компонент (OLAP Component), который в процессе воспроизведения в OLAP-клиенте запрашивает из СОБД нужную информацию для отображения многомерных данных в виде сводных таблиц. Для этого СОБД должна «на лету» формировать наборы данных по запросам OLAP-компонента.
Возникает задача проектирования моделей и алгоритмов извлечения данных и формирования наборов данных для гиперкубов в формате используемого OLAP-компонента. Эту задачу предполагается решать в три этапа (рис. 2):
• построить концептуальную модель множества гиперкубов, которое, в принципе, можно получить, базируясь на концептуальной модели предметной области, лежащие в основе модели хранилища данных (ADM), и выбрать те (акту-
альные) гиперкубы, которые интересны пользователям в плане анализа данных;
• построить модель отображения актуальных гиперкубов на логическую модель хранилища ADM, задающую организацию XML-данных СОБД;
• построить модели извлечения данных из ADM, ассоциированных с состояниями имеющейся динамической модели (или построить нужную динамическую модель «с нуля»), после чего разработка алгоритмического и программного обеспечения становится достаточно ясной технической задачей.
В этой статье рассматривается первый этап - разработка концептуальной модели гиперкубов.
ER-МОДЕЛЬ как основа ПОСТРОЕНИЯ МОДЕЛИ ГИПЕРКУБОВ
Концептуальная модель предметной области, задающая сущности и связи внешнего мира, отражаемые в базе данных OLTP, традиционно представляется в виде ER-модели (Entity-Re-lation model, модель «сущность-связь»). В случае OLAP распространено мнение, что этап проектирования ER-модели, предусматривающий нормализацию сущностей, здесь не нужен и только мешает.
Рис. 2. Этапы построения моделей извлечения данных для формирования ОЬАР-кубов «на лету»
В данном случае, однако, стоит задача проектирования многомерной модели (МБ-модели) хранилища данных не «с нуля», а на основе уже имеющейся базы данных ОЬТР. Поэтому БЯ-модель предметной области, соответствующая имеющейся базе данных, может оказаться весьма полезной. Когда данные не удается удовлетворительно представить в виде единственного куба, и они распадаются на несколько взаимосвязанных кубов, когда данные из нескольких кубов связаны друг с другом, проектирование МБ-модели становится непростой задачей. Использование БЯ-модели как основы для построения кубов помогает понять особенности данных, которые важны при построении МБ-моделей. Она позволяет узнать, какие именно гиперкубы можно, в принципе, построить на основе имеющейся базы данных, и далее, исходя из потребностей аналитики, можно выбрать те гиперкубы, которые действительно актуальны в данной системе, и приступить к разработке алгоритмов их формирования «на лету».
Графическая нотация ЕИ-модели
БЯ-модель будем задавать с помощью графической нотации [10] (рис. 3).
Связь 1:М
б
Сущность —ф>—^Связь М:М^—«ф— Сущность
Сущность
—Связь
Сущность
Сущность, представляющая собой некоторый тип объектов реального мира и подразумевающая множество экземпляров, изображается на диаграмме в виде прямоугольника (рис. 3, а). Атрибуты сущности отображаются с помощью выносных линий. Атрибуты-идентификаторы помечаются темным квадратом (символ ключа), а остальные атрибуты - кружком (символ однозначности). Темный кружок - обязательный атрибут, светлый - необязательный.
Связь типа 1:М («один-ко-многим», «родитель-ребенок») изображается с помощью специальной стрелки в виде сцепленных треугольника и квадрата (рис. 3, б), направленной от сущности-родителя к сущности-ребенку. Идентифицирующая связь обозначается темным квадратом, а неидентифицирующая - светлым; обязательная связь обозначается темным треугольником, а необязательная - светлым.
Связь типа М:М («многие-ко-многим») изображается с помощью овала с присоединенными к нему 1: М-связями, идущими от связываемых сущностей (рис. 3, в). М:М-связь может иметь атрибуты (идентификаторы, обязательные, необязательные). Экземпляры М:М-связи идентифицируются совокупностью своих атрибутов-идентификаторов и тех связываемых сущностей, которые присоединены через идентифицирующие 1:М-связи.
Специальные связи изображаются с помощью модифицированных символов (рис. 3, г). Светлый кружок внутри треугольника обозначает связь, необязательную со стороны ребенка (допустимость «сирот»), а темный кружок -обязательную (запрет «сирот»); по умолчанию подразумевается темный кружок.
Случай, когда множество экземпляров некоторой сущности разбито на непересекающиеся подмножества (категории), изображается с помощью пятиугольного символа подсущности (рис. 3, д), связывающего обобщающую сущность с сущностями-категориями. Темный символ подсущности означает полную категоризацию (каждый экземпляр обобщающей сущности соответствует одной из категорий), а светлый -частичную (допустимы экземпляры обобщающей сущности, не соответствующие ни одной из категорий). Атрибуты, заданные в обобщающей сущности, наследуются всеми категориями, а атрибуты, заданные в категориях, являются специфическими для экземпляров, относящихся к соответствующей категории.
в
г
Графическая нотация МБ-модели
Средства графического задания МБ-модели несколько беднее, чем в случае БЯ-модели. МБ-модель задается с помощью нотации (рис. 4), предложенной в работе [11].
У Измерение ^
У Измерение р 1—^ Измерение ^
(Иерархия) (Иерархия) jУровень \ jУровень \
«многие-ко-многим» (М:М-связь) следует рассматривать как потенциальную факт-сущность MD -модели. На рис. 5 поясняется это соответствие. Известно, что гиперкубу данных с его измерениями и мерами (рис. 5, а, иерархии в измерениях не показаны) в реляционном представлении (Relational OLAP) соответствует так называемая схема «звезда» (рис. 5, б). Здесь кубу соответствует таблица фактов, а измерениям куба - таблицы измерений. Таблица фактов содержит показатели, соответствующие мерам куба, а также ссылки на таблицы измерений (внешние ключи). В ER-модели (рис. 5, в) схеме «звезда» соответствует связь типа «многие-ко-многим» вместе со связываемыми сущностями (измерениями), при этом показателям таблицы фактов соответствуют атрибуты связи.
Измерение' б Мера
Мера
в
Рис. 4. Элементы ЫБ-модели
Гиперкуб на ЫБ-диаграмме изображается символом куба, с которым соединены символы измерений (рис. 4, а). Атрибуты измерений показываются на выносных линиях, исходящих из символов измерений, а меры (показатели) - на выносных линиях, исходящих из символа куба.
Если на измерениях куба заданы иерархии (рис. 4, б), то самый верхний уровень иерархии изображается в виде овала, промежуточные уровни - в виде трапеций, а нижний уровень -символом измерения. Иерархии одного измерения могут иметь общие нижние уровни.
В многокубовой ЫБ-модели кубы могут быть взаимосвязаны так, что один куб наследует у другого куба измерения, а также меры в форме измерений. Такая взаимосвязь изображается на диаграмме стрелкой в направлении наследника (рис. 4, в).
Переход от ЕЯ- к МБ-модели
Идея преобразования БЯ-модели в ЫБ-мо-дель заключается в том, что каждую связь типа
Т
Меры
Атрибуты связи
в
Рис. 5. Соответствие гиперкубов и связей «многие-ко-многим»
Таким образом, каждая М:М-связь БЯ-моде-ли задает потенциальный гиперкуб, который можно построить в рамках исходной БЯ-моде-ли. Это обстоятельство служит отправной точкой проектирования МБ-модели.
а
б
ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ МБ-МОДЕЛИ
Реализация ключевой идеи преобразования М:М-связей в гиперкубы требует проработки ряда вопросов и разрешения ряда затруднений, обсуждаемых ниже.
Многокубовая модель
Если в исходной БЯ-модели имеется несколько связей типа «многие-ко-многим» (как обычно и бывает в нетривиальных случаях), то в результате замены их гиперкубами получается многокубовая МБ-модель, в которой отдельные кубы взаимосвязаны (рис. 6).
МА1
0А1 -Ф~С А 0А2
РВ1 -ф-( В У<Е- РВ2
т
МВ1
а
£МВ1
Рис. 6. Взаимосвязь кубов в МБ-модели
Исходная БЯ-модель (рис. 6, а) содержит две М:М-связи: А и В, причем А является родителем для В. При переходе к МБ-модели (рис. 6, б) связи превращаются в кубы А и В, связываемые сущности - в измерения соответствующих кубов, а связь типа «родитель-ребе-
нок» между связями А и В - в указатель наследования (стрелка А ^ В).
В результате дочерний куб В наследует измерения родительского куба А, а также меры родительского куба - тоже в форме измерений (рис. 6, в). То есть доступ к показателям (мерам) куба В возможен и по измерениям и мерам родительского куба А.
Кроме того, куб А, имеющий в качестве наследника куб В, может использовать его сводные показатели в качестве своих мер (рис. 6, г). Здесь куб А помимо своей «родной» меры МА1 использует меру МВ1 в сводном виде - например, в виде суммы ^МВ1.
Иерархии в измерениях
Если М:М-связи порождают в МБ-модели кубы, то 1:М-связи («один-ко-многим») задают иерархии в измерениях кубов (рис. 7).
Здесь сущности-измерения БА1 и БА2 имеют родителей - сущности С1 и С2 соответственно, которые, в свою очередь, имеют родителей Б1 и Б2. При переходе к МБ-модели родительские сущности становятся частью измерений БА1 и БА2 в виде уровней Б1 и С1, Б2 и С2 иерархий Н1 и Н2 соответственно.
01
I
02
С1
Ї
і
С2
МА1
і
РАЇ -ф-( А )-Ф~ 0А2
01
С1
А
б
Рис. 7. Иерархии в измерениях МБ-модели
«Аппендиксы» в ЕЯ-модели
В БЯ-модели возможны фрагменты, в которых сущности связаны в цепочки «родитель-ребенок», но при этом не участвуют в М:М-свя-зях (рис. 8). Такие фрагменты будем называть «аппендиксами».
б
а
Рис. 8. Аппендикс в ER-модели
Аппендиксы обычно можно игнорировать в ER-модели, поскольку из них нет доступа к М:М-связям (потенциальным кубам) или к сущностям измерений в направлении от родителя к ребенку и поэтому они не участвуют в формировании кубов, измерений кубов или иерархий измерений. Особый случай рассматривается ниже.
Вырожденные измерения
Как сущности, так и связи в ER-модели могут иметь свой набор атрибутов. В MD-модели атрибуты сущностей переходят в измерения, а атрибуты М:М-связей - в меры (показатели), по которым проводится анализ.
Предполагается, что ER-модель построена «грамотно», и все ее сущности нормализованы (декомпозированы до пятой нормальной формы). Поэтому все атрибуты функционально зависят только от идентификаторов соответствующей сущности или связи и нет формальных оснований для вычленения их в самостоятельные сущности.
Однако встречаются случаи, когда тот или иной атрибут М: М-связи представляет интерес в плане использования его в процессе OLAP в качестве измерения гиперкуба. В таком случае целесообразно выделить эти атрибуту в самостоятельные сущности, позволяя проводить по ним многомерный анализ данных. В результате получаются так называемые вырожденные измерения (Degenerate dimensions) [7], содержащие единственный атрибут.
Появление вырожденного измерения в аппендиксе приводит к появлению в нем М: М-связи, что может сопровождаться исчезновением аппендикса (рис. 9).
Пусть у аппендикса на рис. 9, а сущность D2 имеется атрибут Q, который представляет интерес в плане OLAP (остальные атрибуты не показаны). В результате его вычленения в самостоятельную сущность Q (рис. 9, б) сущность D2 превращается в М: М-связь D2, что приводит к исчезновению аппендикса. Результирующая MD-модель (рис. 9, в) содержит два куба - A и D2, куб D2 имеет вырожденное измерение Q, а DA2 является измерением для куба A и одно-
временно - уровнем иерархии измерения С2 для куба Б2. Заметим, что если бы атрибут 0 был вычленен из сущности С2, то в М:М-связь превратилась бы сущность С2 и аппендикс сохранился бы в укороченном виде (в виде Б2).
DA2
D2
) DA1 Н$К DA2 (
Рис. 9. Эффект исчезновения аппендикса при появлении вырожденного измерения
Обобщение кубов
Исходная БЯ-модель может содержать несколько М:М-связей, которые связывают между собой одни и те же сущности, отражая различные аспекты взаимодействия связываемых сущностей. Подобное дробление сущностей и связей обычно является следствием нормализации модели данных, ориентированной на ОЬТР. При переходе к ЫБ-модели более удобно иметь укрупненные кубы, позволяющие выполнять анализ по различным аспектам. Возможно, целесообразно обобщить кубы, базирующиеся на общих измерениях, сделав из них один укрупненный куб и добавив при необходимости новое измерение, позволяющее селектировать срезы исходных кубов. На рис. 10 поясняется процедура обобщения кубов.
Исходная БЯ-модель (рис. 10, а) содержит две М:М-связи - А и В, первая связывает сущности Б1, Б2 и БА и содержит атрибут МА, а вторая - сущности Б1 и Б2 и содержит атрибут МВ. Сущности Б1 и Б2 являются идентифицирующими как для А, так и для В (т. е. однозначно определяют экземпляры связей), а сущность БА - не идентифицирующей для А.
В результате обобщения (рис. 10, б) вместо связей А и В появилась связь АВ, связывающая
а
б
в
сущности Б1, Б2, БА, а также введенную сущность-селектор Б8. Вырожденная сущность-селектор Б8 сдержит два экземпляра, соответствующих аспектам «А» и «В»; она является идентифицирующей для связи АВ и отличает экземпляры АВ, унаследованные от А, от экземпляров, унаследованных от В. Обобщенная связь АВ содержит обобщенный атрибут М, который в зависимости от экземпляра сущности-селектора интерпретируется как МА или как МВ. Связь АВ является необязательной со стороны сущности БА, поскольку экземпляры этой связи, унаследованные от связи В, не имеют соединения с экземплярами сущности БА.
-Ф~Са>-Ф-
МА
-^>-С~в~У<Е-
мв
02
ЭБ г-ф-
й1 Ж АВ Ж! 02 -М
б
Рис. 10. Обобщение кубов
На рис. 10, б показана результирующая МБ -модель.
Хронологические данные
В отличие от ОЬТР-систем, где данные регулярно добавляются, удаляются и редактируются, в ОЬЛР-хранилищах однажды загруженные данные соответствуют актуальному состоянию на момент загрузки и теоретически в дальнейшем не меняются. Хранилище данных, как правило, содержат измерение-календарь (измерение времени), позволяющее анализировать данные по временным интервалам.
В базах данных, ориентированных на ОЬТР, данные, актуальные на момент выборки, в следующий момент могут измениться в результате очередной транзакции. Возникает проблема
анализа по измерению времени, поскольку в базе хранятся версии данных, соответствующие текущему состоянию. Поэтому для обеспечения возможности анализа по измерению времени в базе данных необходимо предусмотреть:
• накопление необходимых для анализа версий хронологических данных вместе с информацией о времени;
• возможность селекции нужных версий хронологических данных при построении кубов «на лету».
ПРИМЕР ПОСТРОЕНИЯ MD-МОДЕЛИ
Процедура построения ЫБ-модели на основе БЯ-модели иллюстрируется на примере базы данных, отражающей деятельность комплекса диссертационных советов вуза в сфере подготовки научных кадров высшей квалификации.
Исходная ER-модель (рис. 12) разработана при участии авторов для базы данных ОЬТР информационной системы диссертационного процесса. Для компактности в модели отражены только сущности и связи; атрибуты и имевшиеся в модели аппендиксы, не показаны. Назначение многих сущностей и связей понятно из их имен, пояснения представлены в табл. 1.
Таблица 1 Основные элементы исходной ER-модели
Элемент Назначение
Совет Список диссоветов
Версия Список приказов ВАК об открытии или реорганизации диссовета
Отрасль Справочник отраслей науки
Специаль- Справочник специальностей
ность
Профиль Список специальностей / отраслей науки диссовета
Сертификат Список дипломов, удостоверений и других документов, подтверждающих статус персоны
Специалист Категория персоны - список участников диссертационных процессов, не являющихся диссертантами
Член Список специалистов, входящих в состав версии диссовета
Заседание Список заседаний диссоветов
Эксперт Специалист, назначенный для предварительной экспертизы диссертации
Кооптант Специалист, дополнительно введенный в диссовет на разовую защиту
а
Окончание табл. 1
Оппонент-п Специалист, предложенный экспертами в качестве оппонента
Внедрение Список актов о внедрении результатов диссертации в организациях
Рассылка Список рассылки автореферата
Замечание-о, Список замечаний, содержащихся
-в, -а в отзывах оппонента, ведущей организации, на автореферат
Активность Сведения об активности специалиста на заседании диссовета (вопросы, выступления и др.)
ВАК Переписка с ВАК по диссертации
Вид Справочник видов информации
Преобразование ER-модели
Исходная БЯ-модель была преобразована с учетом последующего перехода к ЫБ-модели.
Обобщение М:М-связей. С учетом того, что некоторые из потенциальных кубов тематически схожи и позволяют проводить одинаковый по смыслу анализ данных, было выполнено обобщение М: М-связей. В результате 12 исходных связей заменены на 3 обобщенных с селектирующими сущностями (табл. 2).
Вычленение атрибута в самостоятельную сущность. Во многих М:М-связях исходной модели присутствует атрибут «Вид», который определяет, к какому виду относится экземпляр связи. Этот атрибут представляет интерес в плане анализа, поэтому он был выделен в отдельную сущность «Вид».
Страна
Звание
Город
Степень
-сОгОз—
-ф—ф—
Титул
Подразделение
Должность
Организация
<>
С
Работа
Персона
-------------Ф-
Вид
Совет
-^Сертификат\-
—V—-
Специалист
Член
Отрасль
( Версия ф*
Л" Профил
І
Диссертант
(Присутствие-п)
---- ' { —(Присутствие-з) [
Принятие ) ^-------Д-----\
' ( / ^
^^ Защита
Специальность
И
Стык/
ВАК
т
Отправка Л
Активность
Подача
-фг
Вед-п
Ф
Ф
I
ф
Вед
г*К:
Оппонент-
п
Научрук
Научконс
—Ф
Подписал-в
Утвердил-в
Рассылка
Отзыв-а
-Ф—(З
Замечание-в
Эксперт
Замечание-а
-а
Кооптант
Оппонент
-Ф-(З
Замечание-о
Т аблица 2
Обобщенные М:М-связи
Элемент (селектор) Назначение Исходные элементы
Фигурант Список специали- Член, Г ость,
(Катего- стов, связанных с Эксперт, Кооп-
рия) диссертационным тант, Специалист
процессом
Ход (Этап) Сведения о текущем Подача, Приня-
состоянии процесса тие, Защита, От-
правка
Замечание Сведения о замеча- Замечание-о,
(Вид) ниях Замечание-в,
Замечание-а
Хронологические данные. Для обеспечения возможности анализа по измерению времени в исходной БЯ-модели атрибуты времени вычленены в самостоятельную сущность «Календарь», фиксирующую даты тех или иных событий. Результирующая БЯ-модель, полученная в результате преобразования исходной, приведена на рис. 13.
MD-модель
Результирующая МБ-модель, полученная из преобразованной БЯ-модели, представлена на рис. 14 (для компактности атрибуты мер и измерений не показаны). Модель содержит 15 кубов и 15 измерений. Модель сильно связанная: 12 кубов наследуют другие кубы с их мерами и измерениями, 6 измерений непосредственно используются несколькими кубами. Назначение кубов в плане ОЬЛР поясняется в табл. 3.
Страна
Звание
Город
Степень
ф
Титул
Подразделение
Ф
Должность
Организация
Календарь
-Ф-
Вид
Совет
Отрасль
Категория
^Сертификату—
Ф
Специальность
“С
Принятие
------
Защита
------
^Присутствие) Заседание у
Отзыв у-------------—/
Замечание
Этап
Диссертант
-ЧИ
ф
ф
Вед-п
Ход
О-
-*к
Рассылка
ф
Вед
Отправка
нф----------------------------/ч
ф
Ф
Ф
Ф
Научрук
Ж
Научконс
Подписал-в
Утвердил-в
-ф>---Ґ ВАК
Ф----
Активность
(^Внедрение у—
Таблица 3
Г иперкубы MD-модели
Г иперкуб Назначение
Версия Анализ истории открытия и реоргани-
зации диссоветов
Профиль Анализ специальностей / отраслей
науки, по которым диссоветы могут
проводить защиты
Заседание Анализ заседаний диссоветов
Работа Анализ трудовой деятельности персон
Рассылка Анализ рассылки авторефератов
Сертификат Анализ документов, подтверждающих
статус персон
Ход Анализ прохождения диссертаций
в совете
Публикация Анализ публикаций по диссертациям
Внедрение Анализ внедрений по диссертациям
Фигурант Анализ состава участников диссерта-
ционного процесса
Присутствие Анализ посещаемости заседаний
Окончание табл. 3
Активность Анализ активности участников дис-
сертационного процесса
Отзыв Анализ отзывов, поступивших на дис-
сертации и авторефераты
Замечание Анализ замечаний, содержащихся
в отзывах
ВАК Анализ решений ВАК
по диссертациям
Вычленение отдельных кубов
Построенная МБ-модель содержит несколько взаимодействующих кубов. Для выполнения ОЬАР-анализа отдельные кубы вычленяются из многокубовой модели, при этом «родные» измерения могут дополняться унаследованными измерениями и мерами (в качестве измерений) родительских кубов, а «родные» меры - сводными мерами кубов-наследников.
) Вид (
( Страны ) ) Степень ^
/ Страна \
/ Город \
^ Звание
^------7 ^ Титул
> Организация ^--------------------*
^ Должность , ^Подразделение
^Профиль. Отрасль^ ^Специальность^
^>Профиль. Специальность^
) Диссертант <( р
Календарь
)>Фигурант.Вид^
Фигурант. Категория
Рис. 15. Модель гиперкуба «Ход» Основные показатели куба «Ход» Т аблица 4
Имя Содержание Исходный куб
Публ-всего* Кол-во опубликованных работ по теме Публикация
Публ-ВАК* Кол-во статей в журналах из перечня ВАК Публикация
Публ-един* Кол-во публикаций без соавторов Публикация
Патентов* Кол-во патентов Публикация
Программ* Кол-во зарегистрированных программ для ЭВМ Публикация
Внедрений* Кол-во актов внедрения Внедрение
Аспирант Кол-во диссертаций, подготовленных через аспирантуру (докторантуру) —
Внешних Кол-во диссертаций из других организаций —
Отз-всего* Кол-во отзывов на а/реф. Отзыв
Отз-отриц* Кол-во отрицательных отзывов оппонентов, ведущей и на а/реф. Отзыв
Кооптантов* Кол-во кооптированных в совет членов на разовую защиту Фигурант
Чл-совета* Кол-во присутствовавших членов совета Присутствие
Чл-профилю* Кол-во присутствовавших членов по профилю Присутствие
Опп-отсут* Кол-во отсутствовавших оппонентов Присутствие
Задавали-дисс* Кол-во задававших вопросы диссертанту Активность
Выступлений* Кол-во выступлений Активность
Роздано Кол-во розданных бюллетеней —
В-урне Кол-во бюллетеней, оказавшихся в урне —
За Кол-во бюллетеней за —
Против Кол-во против —
Недействит Кол-во недействительных —
Присудить Кол-во успешных защит —
Отказать Кол-во защит с отрицательным решением —
Отозвано Кол-во отозванных диссертаций —
ВАК-запрос Кол-во запросов из ВАК по диссертациям —
ВАК-утв Кол-во утвержденных ВАКом диссертаций —
ВАК-отказ Кол-во неутвержденных ВАКом диссертаций —
Этот процесс иллюстрируется на рис. 15 на примере одного куба «Ход» - ключевого куба, отражающего состояния прохождения диссертаций через диссертационный совет. Здесь не показаны измерения, полученные из мер унаследованных кубов, поскольку не выявлена их полезность для анализа. Имена 5 унаследованных измерений в качестве префикса содержат имена «родных кубов, а 27 показателей мер поясняются в табл. 4.
ЗАКЛЮЧЕНИЕ
В данной работе на концептуальном уровне (без учета особенностей и возможностей среды реализации) предложен подход к проектированию многомерной модели данных концептуального уровня для решаемых «на лету» задач Web-OLAP.
Подход отличается тем, что за основу берется БЯ-модель базы данных OLTP и в ней дополнительно вычленяются в отдельные сущности атрибуты, существенные в плане анализа, после чего связи типа «многие-ко-многим» рассматриваются как потенциальные гиперкубы (атрибуты связей - как меры гиперкуба, а связываемые сущности - как измерения гиперкуба).
Рассмотренный содержательный пример построения многомерной модели деятельности диссертационных советов вуза показал работоспособность предложенного подхода.
Предложенный подход, вообще говоря, не ограничивается рамками ситуационно-ориентированных баз данных, а может использоваться в случае баз данных с иной организацией, например, реляционной.
Полученные результаты предоставляют разработчикам возможность проанализировать структуру имеющейся базы данных OLTP и построить на ее основе модель OLAP, потенциально возможную для реализации «на лету», после чего выбрать для построения те гиперкубы, которые актуальны в плане задач анализа.
Дальнейшие исследования в этом направлении связаны с построением отображения многомерной модели на XML-модель хранилища ситуационно-ориентированной базы данных, а также на создание алгоритмического и программного обеспечения, формирующего гиперкубы «на лету» в формате используемого OLAP-клиента.
СПИСОК ЛИТЕРАТУРЫ
1. Codd E. F. Providing OLAP for end-user analysis: An IT mandate ll ComputerWorld, 1993.
2. Olap.ru [Электронный ресурс]
(http:llolap.rul).
3. Strauch C., Kriha W. NoSQL databases. URL: http:llwww.christof-strauch.delnosqldbs.pdf (дата обращения 07.11.2012).
4. Миронов В. В., Юсупова Н. И., Шакирова Г. Р. Ситуационно-ориентированные базы данных: концепция, архитектура, XML-реализация ll Вестник УГАТУ. 2011. Т. 14, № 2 (37). С. 233-244.
5. Миронов В. В., Юсупова Н. И., Шакирова Г. Р. Ситуационно-ориентированные базы данных: внешние представления на основе XSL ll Там же. 2011. Т. 14, № 4 (39). С. 200-209.
6. Миронов В. В., Маликова К. Э. Интернет-приложения на основе встроенных динамических моделей: идея, концепция, безопасность ll Там же. 2009 Т. 13, № 2 (35). С. 1б7-179.
7. Миронов В. В., Маликова К. Э. Интернет-приложения на основе встроенных динамических моделей: архитектура, структура данных, интерпретация ll Там же. 2010. Т. 14, № 1 (Зб). С. 154-1бЗ.
S. Миронов В. В., Маликова К. Э. Интернет-приложения на основе встроенных динамических моделей: элементы управления пользовательского интерфейса ll Там же. 2011. Т. 14, № 5 (40). С. 170175.
9. Миронов В. В., Гусаренко А. С. Ситуационно-ориентированные базы данных: концепция
управления XML-данными на основе динамических DOM-объектов ll Там же. 2012. Т. 1б, № 3 (4S). С. 159-173.
10. Миронов В. В., Юсупова Н. И., Шакирова Г. Р. Иерархические модели данных: концепции и реализация на основе XML. М.: Машиностроение, 2011. 453 с.
11. Миронов В. В., Юсупова Н. И. Конценту-альные модели баз данных. Многомерные модели. Уфа: УГАТУ, 2010. S3 с.
ОБ АВТОРАХ
Миронов Валерий Викторович, Уфимск. гос. авиац. техн. ун-т, проф. каф. АСУ. Дипл. радиофизик (Воронежск. гос. ун-т, 1975). Д-р техн. наук но унр. в техн. системах (УГАТУ, 1995). Иссл. в обл. иерар-хич. моделей и ситуац. управления.
Макарова Екатерина Сергеевна, Уфимск. гос. авиац. техн. ун-т, аспирантка каф. АСУ. Дипл. магистр техн. и технол. в обл. информатики и выч. техники (УГАТУ, 2010). Готовит дисс. о технологиях Web-OLAP.
