CC BY
35
DOI: 10.18721/JCSTCS.10410 УДК 004.652.4
РЕДАКТОР ВИЗУАЛЬНОГО ПРОЕКТИРОВАНИЯ СХЕМ И ПРОЦЕДУР ЗАПОЛНЕНИЯ OLAP-КУБОВ МНОГОМЕРНЫХ БАЗ ДАННЫХ
С.Г. Попов, А.В. Коненков, Т.Н. Самочадина
Санкт-Петербургский политехнический университет Петра Великого,
Санкт-Петербург, Российская Федерация
Разработка OLAP-кубов для использования в системах бизнес-анализа требует согласованных действий администратора баз данных и аналитика. Их взаимодействие, являясь итеративным процессом, замедляет процесс проектирования компоненты хранения и обобщения данных. Описан новый специализированный графический редактор, который позволит аналитику самостоятельно выполнить большую часть операций по созданию логической и физической схемы подсистемы хранения, ускорит процесс разработки системы. Сформулированы требования к графическому представлению схем OLAP и цепочек загрузки, а также к функциям редактора. Приведены примеры реализации интерфейса прототипа.
Ключевые слова: база данных; система управления базами данных; BI; аналитик; системный администратор; OLAP; ETL; редактор схем; графическая нотация.
Ссылка при цитировании: Попов С.Г., Коненков А.В., Самочадина Т.Н. Редактор визуального проектирования схем и процедур заполнения OLAP-кубов многомерных баз данных // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2017. Т. 10. № 4. С. 107-117. DOI: 10.18721/JCSTCS.10410
VISUAL DESIGN EDITOR FOR SCHEMES AND PROCEDURES OF FILLING OLAP CUBES IN MULTIDIMENSIONAL DATABASES
S.G. Popov, A.V. Konenkov, T.N. Samochadina
Peter the Great St. Petersburg Polytechnic University, St. Petersburg, Russian Federation
The development of OLAP cubes for use in business analysis systems requires coordinated actions of the database administrator and analyst. Their interaction is an iterative process, and it slows down the design of the storage component and generalization of the data. We have developed a new analytic tool, which will allow to perform most of the operations to control a logical and physical scheme. It will speed up the process of storage subsystem development. This tool, described in this paper, is a specialized graphic editor,. The paper formulates the requirements for graphical representation of OLAP cubes and ETL, requirements for editor functions and implementing the interface examples.
Keywords: database; database management system; BI; analyst; system administrator; OLAP; ETL; schematic editor; graphical notation.
Citation: Popov S.G., Konenkov A.V., Samochadina T.N. Visual design editor for schemes and procedures of filling OLAP cubes in multidimensional databases. St. Petersburg State Polytechnical University Journal. Computer Science. Telecommunications and Control Systems, 2017, Vol. 10, No. 4, Pp. 107-117. DOI: 10.18721/JCSTCS.10410
Введение
Особенности функционирования классических технологий создания многомерных баз данных для использования в системах бизнес-анализа, основанных на OLAP-решениях, предполагают одновременное участие как администратора данных, так и аналитика на этапах создания схемы куба и заполнения его данными. Администратор баз данных обеспечивает технологическое управление источниками данных и созданием куба, а аналитик задаёт семантическое наполнение создаваемой OLAP-системы. Реализуемый в этом случае классический подход обладает существенным недостатком: взаимодействие аналитика с администратором в процессе разработки OLAP-системы происходит в форме сходящихся ручных или автоматических итераций («создание описания куба» — «загрузка данных в куб» — «анализ результата»). При этом на каждом шаге попеременно участвуют администратор и аналитик.
Анализ средств автоматизации создания OLAP-кубов показал, что сокращение числа итераций для достижения приемлемого результата может быть обеспечено двумя путями: обеспечением автоматического формирования OLAP-схем в условиях известной или неизвестной схемы исходных наборов данных [10] и применением интеллектуальных редакторов данных для интеграции исходных метаданных в многомерные кубы.
Несмотря на активное развитие первого способа, состоящего в интеграции технологий OLAP и средств Data Mining [4—6], систематизации схем на основе принципов иерархической кластеризации [1, 2] и автоматизации генерации схемы кубов OLAP на основе концептуальных, в том числе и графических моделей [3, 11], представленные методы являются «обратными» и строят схему кубов OLAP по уже существующим данным и метаданным. В этом случае аналитик — потребитель автоматически сгенерированной схемы OLAP, что может снизить эффективность его последующей работы.
Альтернативный подход к процессу соз-
дания кубов — применение графического представления схемы куба и цепочек загрузки данных непосредственно в процессе его разработки. Такой подход является «прямым», управляется и контролируется аналитиком и обеспечивает прозрачность представления схемы. Наиболее распространённый способ задания управления метаданными — извлечение метаданных из исходных, в том числе и реляционных, подсистем и сохранение их в централизованном репозитории [13—15] с их последующей визуализацией. Процесс визуализации обеспечивает как визуальное представление данных из кубов в разрезах и выборках, основанное на запросах на графическом языке с генерацией куба [7], средствах 2,5D и 3D отображения данных, основанных на упорядочивании ¿-деревьев [8], так и отображения схем OLAP-хранилищ с одновременной поддержкой методов демонстрации данных [9, 12].
Особенностью отображения схемы OLAP-кубов и цепочек загрузки в подсистеме заполнения OLAP-кубов является требование к прозрачности представления исходных метаданных: источники данных, образующие схему куба, могут являться реляционными схемами, плоскими файлами или другими кубами. В этом случае вопрос представления единой схемы становится задачей интеграции метаданных разнородных баз данных [15].
Многомерность кубов и гетерогенность источников данных для заполнения куба являются ключевой особенностью задачи построения схем и цепочек запросов к кубам OLAP, что предъявляет дополнительные требования к средствам графического представления. Многомерность куба предполагает большое число связей в схемах «звезда» или «снежинка», что требует точного визуального представления атрибутов, участвующих в связях, и сокращения числа соединений между таблицами, при условии сохранения логики связей по ключам. Гетерогенность источников данных требует унификации изображения основных объектов общей схемы: таблиц и связей, выражающихся в едином стиле изображения объектов как полученных из разных ис-
точников, так и добавленных в схему при её редактировании. Эти требования выражаются в формальных и изобразительных ограничениях, налагаемых как на графическое средство, так и на процесс формирования изображения аналитиком.
требования к графическому представлению
схем и цепочек загрузки OLAP-кубов многомерных баз данных
Современные визуальные редакторы схем могут быть ориентированы на конкретную РСУБД, поставляться её производителями или сообществом разработчиков, или одновременно поддерживать синтаксис языка манипулирования данными сразу нескольких СУБД и поставляться сторонними производителями.
К первому типу редакторов относятся Oracle Developer Data Modeler и Query Builder, MS SQL Visual Database Tools, IBM DB2 Control Center, PostgreSQL pgModeler. Их характеризует максимальное использование особенностей СУБД конкретного производителя, таких как максимальный учёт диалекта языка запросов, синтаксиса языка описания данных, поддержки языковых конструкций динамического SQL, прямого обращения к репозиторию метаданных. Такие редакторы не обеспечивают взаимодействие не только с несколькими СУБД различных производителей, но, нередко, и с несколькими базами данных, расположенными на одном или на нескольких серверах, что делает их применение невозможным для задачи построения объединённой схемы.
Второй тип редакторов представлен двумя подтипами продуктов, реализующими управление базами данных и выполняющими функции business intelligence. К первому подтипу относятся такие продукты, как DBeaver, MySQL Workbench, DbDesigner, DbSchema Diagram Designer. Их особенностью является возможность одновременного подключения к нескольким СУБД, однако создание общей схемы из нескольких источников в них невозможно. Вторым подтипом программных решений являются редакторы графических схем в BI продуктах, таких как Галактика BI, IBM Cognos
Analytics или Power BI Desktop. Эти редакторы схем обеспечивают интеграцию разнородных источников данных, однако являются готовыми коммерческими программными решениями с закрытым исходным кодом. Проведённый анализ решений показал, что коммерческие редакторы в полной мере не обеспечивают реализацию задачи комплексной интеграции схем баз данных при создании схем OLAP-кубов и цепочек загрузки.
Графические представления схем перечисленных программных продуктов основаны на вариациях представления графической нотации метамоделей IDEFlx*. Формальное описание нотации не предполагает фиксированного визуального представления схемы, поэтому каждый разработчик редактора реализует представление в соответствии с частными техническими требованиями, выдвинутыми на этапе проектирования продукта. Рассматриваемые решения имеют ограниченную функциональность в части редактирования связей: они обеспечивают соединение атрибутов в автоматическом режиме, при этом линии соединений перекрываются таблицами, пересекаются друг с другом под произвольными углами, что создаёт трудности чтения схемы при большом числе таблиц и соединений.
Анализируя существующие решения изображения схем и особенности изображения схем OLAP-кубов и цепочек загрузки, в качестве базовых, были выдвинуты следующие требования:
1) фиксированного положения первичного простого или составного ключа;
2) указания типа всех ключей;
3) ручного изменения порядка следования атрибутов в таблице;
4) отображения связи ключей в разных таблицах стрелкой;
5) фиксации места начала и окончания связи (связь начинается около атрибута и заканчивается около атрибута);
* IEEE. IEEE Standard for Conceptual Modeling Language Syntax and Semantics for IDEF1X: Std 1320.2-1998. IEEE, 1998. No. Std 1320.2-1998.
6) изображения ребра ломаной линией, состоящей из прямых частей;
7) исключения перекрытия изображения связи таблицей;
8) непревышения шириной имени атрибута ширины таблицы;
9) возможности редактирования каждой связи вручную.
Предъявляемые требования к внешнему виду и функциональному наполнению редактора носят декларативный характер и не определяют критериев формирования изображения схемы: одну и ту же схему можно отобразить многими способами, причём некоторые из них будут лучше других с точки зрения визуального восприятия аналитиком. В этом случае качество отображения схемы формализуется с помощью таких понятий, как формальные требования и изобразительное соглашение.
Критерии формирования графического
представления схем и цепочек загрузки
OLAP-кубов многомерных баз данных
Анализ текущей практики показал, что к графическому изображению схемы ОЬАР-кубов могут быть выдвинуты два типа требований: формальные и неформальные. Формальные требования основаны на математических правилах, а неформальные — на основе изобразительных соглашений.
Особенностью формальных требований является их локальность: они применяются
к отдельным объектам или к их группам, а не ко всему изображению в целом, и общего критерия, совмещающего требования ко всему изображению, сформулировать невозможно. Поэтому общие требования выражаются в форме неформальных, изобразительных требований, «отвечающих» за организацию изображения схемы в целом.
Формальные требования. Формальные требования описывают такие свойства изображений, которые можно формально специфицировать и затем вычислить, чтобы повысить наглядность изображения. Они предъявляются к каждому объекту изображения, к совокупности объектов одного или нескольких типов, или ко всему изображению в целом. В таблице приведён перечень объектов изображения и формальные требования к ним.
В результате автоматического применения формальных критериев может быть получен локальный минимум по одному из критериев, однако оптимизация на основе целевой функции, составленной из композиции критериев, не может быть сформулирована в явной форме ввиду противоречия между требованиями. Другим недостатком оптимизационных методов построения изображения является высокая вычислительная сложность. Даже в случае корректного решения оптимизационной задачи результат может не удовлетворять аналитика в силу формально верного, но сложно вос-
Формальные требования к изображению схемы Formal requirements for schematic representation
Объект(ы) Минимизируемые параметры
Связь Длина одной связи
Связи Суммарная длина всех связей, число пересечений, разность между самой длинной и самой короткой связью
Изгиб связи Числа изгибов каждой линии, разность между минимальным и максимальным числом изгибов
Изгибы связей Минимизация числа различных углов изгибов линий
Таблица Минимизация площади, занимаемой таблицей
Таблицы Минимизация разности площадей таблиц
Таблицы и связи Минимизация общей площади изображения, приведение отношений сторон к формату листа
принимаемого зрительно размещения.
Изобразительные соглашения. Графическое изображение схемы базы данных предназначено для использования аналитиками в повседневной практике. В этом случае требования к изображению могут формулироваться в виде требований к субъективным характеристикам, могут формулироваться на основе неформальных соглашений и являться общими правилами и критериями, сформулированными ко всему изображению схемы.
Изобразительные соглашения — это правила, определяющие общий стиль изображения элементов таблиц и связей между ними. Стиль формируется, исходя из требований к проектируемому редактору схем баз данных. Формулировка требований к изображению схем ОЬЛР-кубов содержит требования к изображению таблиц, атрибутов в них, ключей и соединений между ними в части ручного управления связями схемы.
Изображение таблиц. Таблицы должны изображаться прямоугольными областями. Каждая таблица в своей верхней части должна содержать название, ниже следуют атрибуты, составляющие первичный ключ этой таблицы. Далее могут следовать прочие атрибуты таблицы с указанием их типа.
Изображение атрибутов. Расположение первичного ключа фиксировано, расположение прочих атрибутов может изменяться пользователем. При перемещении атрибутов перемещаются и все связи, начинающиеся или заканчивающиеся у этих атрибутов. Ширина таблицы не может быть меньше максимальной ширины имени атрибута, а высота определяется числом атрибутов.
Изображение связей. Логическая связь атрибутов таблиц изображается рёбрами: каждое ребро начинается у названия атрибута одной таблицы и заканчивается у атрибута другой. Ребро начинается обычной линией, а заканчивается указателем — стрелкой, при этом для каждой связи фик-
1) к таблице
Формальные требования
2) к связи
Требования к графическому представлению схем
1.1. максимальная симметричность
1.2. минимизация коэффициентов сторон
1.3. минимизация области размещения
2.1.минимизация пересечений
2.2.минимизация сгибов
2.3. минимизация общей длины ребер
2.4. минимизация длины ребра
2.5. унификация длины ребер
2.6. унификация сгибов
3.1. изображаются прямоугольниками
3.2. свойства указываются в такой последовательности: название, список первичных и внешних ключей
3.3. для ключей указывается тип
3) к таблице
Изобразительные соглашения
4) к связи
3.4. высота таблицы зависит от кол-ва атрибутов и может меняться
3.5. для ширины таблицы должна быть задана точная нижняя грань
3.6. возможность изменения порядка следования атрибутов,влечет перерисовку всех связей начинающихся и заканчивающихся у этих атрибутов
4.1. связь изображается в виде ломаной линии, состоящей из чередующихся вертикальных и горизонтальных сегментов
4.2. связь устанавливается непосредственно между атрибутами таблиц
4.3. логическая связь - есть направленная стрелка
4.4. для каждой связи указан ее тип.
4.4. возможность ручного редактирования связи ( перемещение, объединение, разделение)
Рис. 1. Требования к графическому представлению схем Fig.l Schematic diagram representation requirements
сируется ее тип «один к одному» или «один ко многим». Атрибут, являющийся первичным ключом в связи «один ко многим», отмечается единицей. Атрибут, являющийся внешним ключом в связи «один ко многим», отмечается символом бесконечности.
Физически атрибут одной таблицы может одновременно быть связан сразу с несколькими атрибутами другой таблицы. В этом случае ребро разветвляется так, что связь имеет общую часть и точку разветвления.
Ребро может иметь неограниченное число изгибов, которые добавляются пользователем, в основном, для исключения пересечений с таблицами и другими рёбрами.
Предложенный набор требований приведён на рис. 1. Требования обеспечивают расширенный перечень функций ручного управления для непротиворечивого отображения схемы и цепочек загрузки OLAP-куба многомерной базы данных.
Модель представления логического и физического уровней схемы OLAP-куба
Для реализации представления схемы вводятся два уровня описания связи: логический, определяющий схему связи между таблицами по ключам, и физический — уровень отображения, который будет отражать внешний вид соединений на схеме.
Тогда логическая схема куба и цепочек загрузки задаётся графом G = (E, V), где вершинами являются структуры, описывающие таблицы схемы E = Dim(A,, Key,, Dim(B'A)), где A. — имена таблиц, Key. — ключевые атрибуты таблицы А,, ВА. — перечень внешних ключей таблицы, i = (1, 2, ..., n) — число таблиц в схеме, j = (1, 2, ..., к) — число внешних ключей каждой таблицы. Набор ребер V задаётся матрицей смежности на наборе первичных и внешних ключей Keyi и массиве Dim(BiAi)).
Логический уровень обеспечивает представление семантики схемы и напрямую отражается в схемы хранилища метаданных — репозитория или information_schema, а физический — задаёт визуальное представление отображения элементов и сохраняется в редакторе схем.
На логическом уровне каждому ребру у. множества рёбер V графа О ставится в соответствие граф физических связей Ь. = = ОД, ..., /т}, {/1, ..., /}, ..., {/, ..., /5}}, отображающий совокупность всех отрезков и всех связей одного атрибута таблицы.
Иллюстрация предложенного подхода приведена на рис. 2 и 3, где изображены примеры представления графов для логического и физического уровней соответственно. Для реализации логического уровня представления схемы куба применяется схематичное изображение связей. Физи-
Рис. 2. Пример графического представления логического уровня представления связи
Fig. 2. Example of graphical representation of logical level of communication representation
Рис. 3. Пример графического представления физического уровня представления связи
Fig. 3. Example of graphical representation of the physical level of communication representation
ческое представление позволяет изменять графическое представление связи независимо от семантики схемы.
Реализация предложенной двухуровневой модели обеспечивает независимость логической структуры схемы от физического представления и реализована в редакторе схем OLAP-кубов.
Реализация редактора графических представления схем OLAP-кубов
В результате анализа требований к графическому представлению и, основываясь на существующих средствах графического отображения, сформулированы функции графического редактора схем. В нём определены два типа сущностей: таблицы и связи. Для каждого из них выделены функции, позволяющие обеспечить ручное управление схемами.
управление таблицами. Функция обеспечивает формирование, изменение и удаление таблицы, редактирование заголовка таблицы, названий атрибутов и
их типов, удаление атрибутов, изменение порядка следования атрибутов с учётом перемещения связей. Реализация интерфейса управления таблицами обеспечивает функционально полное управление наполнением атрибутами схемы OLAP-куба, такими как размерности и словари. Пример интерфейса управления таблицей приведён на рис. 4.
управление связями. Обеспечивает управление изображением связей между таблицами в части создания, удаления и изменения типа связи. Управление связями осуществляется путём перемещения точек разветвления линий. В этом случае каждое ребро изображается в виде ломаной линии, состоящей из чередующихся вертикальных и горизонтальных сегментов. На первом этапе описание логической связи извлекается из репозитория метаданных и становится основой физической связи. Реализован и обратный процесс: графическое формирование связи обеспечивает её сохранение в репозитории метаданных.
Рис. 4. Пример графического представления управления таблицей Fig. 4. Example of graphical representation of table management
управление физическим отображением связей. Обеспечивается управлением частями существующей связи путём управления добавляемыми точками ветвления. На каждую часть связи можно добавить и удалить произвольное число точек ветвления. Каждую точку ветвления можно перемешать по части связи, что обеспечивает излом линии в произвольных местах. При необходимости редактирование точки обеспечивает объединение и разделение связей, что обеспечивает организацию физического представления соединения. Нотация обеспечивает визуальное представление связей между частями ОЬЛР-куба в вариантах изображения как «звезда» и «снежинка», так и схем произвольной формы. Внешний вид схемы ОЬЛР-куба в представленной нотации приведён на рис. 5.
Сформулированный набор операций над сущностями обеспечивает функцио-
нально полное управление объектами из пользовательского интерфейса.
Прототип редактора реализован в виде компилированного приложения на языке программирования C# на платформе .Net с использованием технологии Windows Forms для операционной системы Windows 7.0. Приложение содержит модули взаимодействия с репозиторием метаданных, управления сохранением схем кубов и графического интерфейса пользователя. Модуль взаимодействия с репозиторием метаданных обеспечивает считывание и запись унифицированных описаний таблиц и описаний логических связей между ними. Модуль управления схемами кубов обеспечивает сохранение данных об относительном расположении таблиц, частей связей на экране. Модуль графического интерфейса обеспечивает отрисовку элементов на экране и вызов экранных форм для управ-
Рис. 5. Пример графического представления схемы OLAP-куба Fig. 5. Example of graphical representation of the OLAP cube schema
ления изображением. Прототип редактора использовался в качестве средства редактирования схем OLAP-кубов на этапе эскизного проектирования программно-технологической платформы интерактивного стратегирования и бизнес-анализа с элементами прогнозирования для государственных и коммерческих организаций.
Заключение
Проанализированы способы визуального проектирования схем многомерных баз данных, выделены формальные и изобразительные требования к графическому редактору, сформулирован перечень функций программного обеспечения, спроектирован и реализован прототип графического редактора схем реляционных баз данных.
Для реализации редактора предложена адаптивная динамическая двухуровневая графовая модель представления связей схемы базы данных, обеспечивающая ручное управление изображением связей. На верхнем уровне граф описывает логические связи между таблицами, а на нижнем совокупность связей атрибута отдельной таблицы физически задаётся уточняющим графом.
На этапе эскизного проекта реализован прототип графического редактора схем
OLAP-кубов многомерной базы. Прототип обеспечивает загрузку схем данных из гетерогенных источников, обеспечивая унификацию графического представления таблиц, атрибутов и связей; реализует отображение многомерных кубов в форме реляционной схемы данных с возможностью ручного управления числом и положением соединений в схеме и размещением реляционных таблиц куба; конкретизацию соединений по ключам между таблицами до имени атрибута, что гарантирует тонкую ручную настройку внешнего вида изображения. Указанная совокупность особенностей отражает специфику построения схем OLAP-кубов и цепочек загрузки. Применение прототипа редактора показало реализуемость данного подхода для проектирования схем OLAP-кубов. Предложенные в редакторе решения могут использоваться на этапах технического проектирования программно-технологической платформы интерактивного стратегирования.
Работа подготовлена в ходе реализации комплексного проекта в рамках Постановления Правительства РФ от 09.04.2010 г. № 218 при финансовой поддержке Министерства образования и науки РФ. Договор № 03.G25.31.0259 от 28.04.2017 г.
СПИСОК ЛИТЕРАТУРЫ
1. Wang X., Yi B. The Application of Data Cubes in Business Data Visualization // Computing in Science & Engineering. 2012. Vol. 14. No. б. Pp. 44-50.
2. Макарова Е.С., Миронов В.В.
Проектирование концептуальной модели данных для задач Web-OLAP на основе ситуационно-ориентированной базы данных // Вестник УГАТУ. 2012. T. 1б. № б (51). С. 177-188.
3. Скворцова Д.А., Чмырь Д.А. Использование многомерных OLAP-кубов, как инструмента Business Intelligence, при стратегическом управлении бизнес-процессами компании // Экономика: теория и практика. 201б. № 3. С. 70-77.
4. Едуш М.В, Витиска н.И. Исследование проблемы поиска центральной таблицы для многомерного куба (или групп таблиц) в реляционной БД // Информатизация и связь. 2013. № 3. С. 158—1б1.
5. наумов В.н., Лычагина Е.Б., Шараба-
баева Л.Ю. Использование BI-систем для обеспечения информационно-аналитической деятельности органов государственной власти // Управленческое консультирование. 2016. № 3(87). С. 144-153.
6. Кобец Д.А., Балашов И.В., Данилов И.Д., Лупян Е.А., Сычугов И.г., толопин В.А. Использование BI-технологий для создания инструментов для анализа данных спутникового мониторинга // Современные проблемы дистанционного зондирования земли из космоса. 2015. № 4. С. 17-27.
7. Djiroun R., Boukhalfa K., Alimazighi Z., Atigui F., Bimonte S. A data cube design and construction methodology based on OLAP queries // IEEE/ ACS 13th Internat. Conf. of Computer Systems and Applications. Agadir, 2016. Pp. 1-8.
8. Lafon S., Bouali F., Guinot C., Venturini G. Hierarchical reorganization of dimensions in OLAP visualizations // IEEE Transactions on Visualiza-
tion and Computer Graphics. 2013. Vol. 19. No. 11. Pp. 1833-1845.
9. Bhowmik T., Sarkar A., Debnath N.C. OLAP umbrella: Visualization model for multidimensional databases // ACS/IEEE Internat. Conf. on Computer Systems and Applications. Hammamet, 2010. Pp. 1-8.
10. Usman M., Asghar S., Fong S. Data mining and automatic OLAP schema generation // 5th Internat. Conf. on Digital Information Management. Thunder Bay, ON, 2010. Pp. 35-43.
11. Nabli A., Feki J., Gargouri F. Automatic construction of multidimensional schema from OLAP requirements // The 3rd ACS/IEEE Internat. Conf. on Computer Systems and Applications. Cairo, 2005. Pp. 28-24.
12. Kovacevic I. Mekterovic I. Alternative business intelligence engines // 40th International Con-
Статья поступила в редакцию 14.09.2017.
vention on Information and Communication Technology, Electronics and Microelectronics. Opatija, 2017. Pp. 1385-1390.
13. Ristic S., Kordic S., Celikovic M., Dimitries-ki V., Lukovic I. A model-to-model transformation of a generic relational database schema into a form type data model // Federated Conf. on Computer Science and Information Systems. Gdansk, 2016. Pp. 1577-1580.
14. Malki M., Flory A., Rahmouni M.K. Extraction of object-oriented schemas from existing relational databases: А form-driven approach // Informatica. 2002. Vol. 13(1). Pp. 47-72.
15. Попов С.г. Методика построения оптимального репозитория схем реляционных баз данных // Научно-технические ведомости СПбГПУ. Информатика. Телекоммуникации. Управление. 2010. № 5 (108). С. 91-97.
REFERENCES
1. Wang X., Yi B. The Application of Data Cubes in Business Data Visualization. Computing in Science & Engineering, 2012, Vol. 14, No. 6, Pp. 44-50.
2. Makarova Ye.S., Mironov V.V. Designing a conceptual data model for Web-OLAP tasks based on a situationally-oriented database. Newsletter UGATU, 2012, Vol. 16, No. 6 (51), Pp. 177-188. (rus)
3. Skvortsova D.A., Chmyr D.A. Using multidimensional OLAP cubes as a tool of Business Intelligence, in the strategic management of the company's business processes. Economics: theory and practice, 2016, No. 3, Pp. 70-77. (rus)
4. Yedush M.V., Vitiska N.I. The research of the central table search problem for a multidimensional cube (or groups of tables) in a relational database. Informatization and communication, 2013, No. 3, Pp. 158-161. (rus)
5. Naumov V.N., Lychagina Ye.B., Sharababayeva L.Yu. Using BI-systems to provide information and analytical activities of public authorities. Management Consulting, 2016, No. 3(87), Pp. 144-153. (rus)
6. Kobets D.A., Balashov I.V., Danilov I.D., Lupyan Ye.A., Sychugov I.G., Tolopin V.A. Using BI-technologies to create tools for analyzing satellite monitoring data. Modern problems of remote sensing of earth from space, 2015, No. 4, Pp. 17-27. (rus)
7. Djiroun R., Boukhalfa K., Alimazighi Z., Atigui F., Bimonte S. A data cube design and construction methodology based on OLAP queries. 2016 IEEE/ ACS 13th International Conference of Computer Systems and Applications, Agadir, 2016, Pp. 1-8.
8. Lafon S., Bouali F., Guinot C., Venturini G.
Hierarchical reorganization of dimensions in OLAP visualizations. IEEE Transactions on Visualization and Computer Graphics, 2013, Vol. 19, No. 11, Pp. 1833-1845.
9. Bhowmik T., Sarkar A., Debnath N.C. OLAP umbrella: Visualization model for multidimensional databases. ACS/IEEE International Conference on Computer Systems and Applications, Hammamet, 2010, Pp. 1-8.
10. Usman M., Asghar S., Fong S. Data mining and automatic OLAP schema generation. 5th International Conference on Digital Information Management, Thunder Bay, ON, 2010, Pp. 35-43.
11. Nabli A., Feki J., Gargouri F. Automatic construction of multidimensional schema from OLAP requirements. The 3rd ACS/IEEE International Conference on Computer Systems and Applications, Cairo, 2005, Pp. 28-24.
12. Kovacevic I. Mekterovic I. Alternative business intelligence engines. 40th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), Opatija, 2017, Pp. 1385-1390.
13. Ristic S., Kordic S., Celikovic M., Dimitries-ki V., Lukovic I. A model-to-model transformation of a generic relational database schema into a form type data model. Federated Conference on Computer Science and Information Systems (FedCSIS), Gdansk, 2016, Pp. 1577-1580.
14. Malki M., Flory A., Rahmouni M.K.
Extraction of object-oriented schemas from existing relational databases: A form-driven approach. Informatica, 2002, Vol. 13(1), Pp. 47-72.
15. Popov S.G. Method of construction of
Received 14.09.2017.
optimal repository of relational schemas databases. St. Petersburg State Polytechnical University Journal. Computer Science. Telecommunication and Control Systems, 2010, No. 5 (108), Pp. 91-97. (rus)
СВЕДЕНИЯ ОБ АВТОРАХ / THE AUTHORS
ПОПОВ Сергей Геннадьевич POPOV Sergey G.
E-mail: popovserge@spbstu.ru
КОНЕНКОВ Андрей Викторович KONENKOV Andrey V.
E-mail: konenkoff@mail.ru
САМОЧАДИНА Татьяна Николаевна SAMOCHADINA Tatiana N.
E-mail: tatiana.samochadina@gmail.com
© Санкт-Петербургский политехнический университет Петра Великого, 2017
