CC BY
121
реализацию и интегрирование поисковых возможностей в информационную систему. При этом разработанное решение обладает:
• масштабируемостью — при расширении функционала поисковой подсистемы возможна модификация существующих и добавление новых классов (внесение изменений в программную архитектуру подсистемы), а также изменение числа информационных ресурсов, задействованных в информационной системе — добавление нового хранилища данных, распределение единой базы данных в кластер и т.д.. Таким образом, решение поддерживает как вертикальное, так и горизонтальное масштабирование;
• надежностью — в силу простоты программной архитектуры решения, реализованная при помощи разрабатываемого фреймворка поисковая система (подсистема) значительно легче отлаживается, что, в свою очередь, позволяет избежать множества ошибок;
• конфигурируемостью — параметры функционирования системы реализуются в общедоступных форматах (например, xml, json и т. д.), а также доступны для изменения при помощи модификации соответствующих конфигурационных параметров. Такой подход делает реализованную при помощи данного инструмента систему гибкой и конфигурируемой.
Литература
1. Д. Баженов. Архитектура поисковых систем // Блог Дениса Баженова [сайт]. URL: http://bazhenov.me/blog/2013/01/08/search-architecture.html (дата обращения 14.04.2013).
2. Разработка собственной поисковой системы с помощью PHP. URL:
http://www.ibm.com/developerworks/ru/library/os-php-sphinxsearch/ (дата обращения 14.04.2013)
3. Google AdSense [Материал из Википедии — свободной энциклопедии]. URL: http://ru.wikipedia.org/wiki/AdSense (дата обращения 14.04.2013).
4. Документальные информационные системы // ПИЭ/Wiki [сайт]. URL:
http://wiki.mvtom.ru/index.php/Документальные_информационные_системы (дата обращения 14.04.2013).
5. Сервис-ориентированная архитектура // CIT Forum [сайт]. URL: http://citforum.ru/internet/webservice/soa/ (дата обращения 14.04.2013).
6. Знакомьтесь, архитектура REST // Блог HTML-Templates.Info [сайт]. URL: http://html-templates.info/view blog.php?id=6 (дата обращения 14.04.2013).
УДК 004.652.5
МОДЕЛИ И МЕТОДЫ ПОСТРОЕНИЯ СИСТЕМЫ OLAP ДЛЯ ОБЪЕКТНООРИЕНТИРОВАННЫХ БАЗ ДАННЫХ1
Фисун Николай Тихонович, д.т.н., проф., зав. кафедры интеллектуальных информационных систем, ЧГУ им. П. Могилы, г. Николаев, Украина, mvkola.fisun@gmail.com. ntfis@kma.mk.ua Горбань Глеб Валентинович, асп. кафедры интеллектуальных информационных систем, ЧГУ им. П.
Могилы, г. Николаев, Украина, bobslev2006@ukr.net
Введение
В настоящее время в системах поддержки принятия решений (СППР) важное место занимают технологии оперативного (OLAP) и интеллектуального (Data Mining) анализа данных [1, 2]. Данные технологии уже реализованы в некоторых коммерческих системах управления базами данных (СУБД), таких как Microsoft SQL Server, Oracle и других, которые представляют собой реляционные СУБД.
Реляционные базы данных (БД) получили большой успех и на данный момент
1 Статья рекомендована к опубликованию в журнале "Информационные технологии"
65
являются самыми распространенными. Это обосновано тем, что данные в них сохраняются в табличном формате и доступны для каждого, кто знаком со структурированным языком запросов (SQL). Однако со временем информационные системы предъявляют такие требования к обработке данных, с которыми реляционные БД уже неспособны справиться. Примером этого может послужить хранение изображений, звуковых файлов и видеозаписей. Существенным недостатком реляционных БД является то, что хранение реальных структур данных в виде столбцов и строк таблиц является довольно непростой задачей, поскольку при декомпозиции данных может получиться довольно большое количество таблиц, отношения между которыми сложно использовать и запомнить.
Одним из альтернативных к реляционному подходу хранения данных является объектный подход. По сравнению с реляционным подходом данный подход появился несколько позже, первые публикации, касающиеся объектно-ориентированных БД, датируются примерно серединой 1980-х годов. Объектный подход позволяет наиболее естественным способом записать объекты в БД и обеспечить их хранение и действия с ними.
1. Аспекты построения системы OLAP в объектно-ориентированных базах данных
Основой любой OLAP-системы является куб, представляющий собой упорядоченный многомерный массив и строящийся на фактических данных, которые могут находиться в нескольких таблицах фактов и обычно имеют несколько измерений [2,3].
Основными реализациями систем OLAP являются MOLAP (многомерный OLAP), ROLAP (реляционный OLAP) и HOLAP (гибридный OLAP), использующий как многомерные, так и реляционные БД. В MOLAP таблица фактов содержит все комбинации значений всех измерений и соответствующие им значения мер. В отличие от MOLAP таблица фактов в ROLAP не содержит все возможные варианты комбинаций измерений; она содержит уникальный составной ключ, который объединяет первичный ключи таблиц измерений.
Типичными схемами связи таблицы фактов с таблицами измерений являются схемы «звезда» и «снежинка». В схеме «звезда» таблица фактов является денормализированной, поскольку данная схема не позволяет учесть возможные уровни иерархии измерений. Для этого применяется схема «снежинка», главной особенностью которой является хранение информации об одном измерении в нескольких связанных таблицах. Однако главным недостатком такой схемы является усложнение в структуре базы данных, которая в данном случае будет содержать достаточно много таблиц фактов.
При сравнении реляционной модели данных с объектной моделью между ними можно найти достаточно много аналогий. Так, реляционное понятие таблицы соответствует классу, строка таблицы - экземпляру класса, столбец - свойству класса, внешний ключ - ссылке на объект и т. д. [4]. Таким образом, можно сделать вывод, что таблица фактов в объектной модели данных представляет собой класс, свойствами которого являются меры и ссылки на таблицы измерений, которые в свою очередь также являются классами.
Структуру таблицы фактов и таблиц измерений для объектной модели данных можно показать на примере базы данных некоторой торговой сети, которая имеет магазины в различных регионах страны, в которые поставляются товары различных категорий.
Факты про продажу определенного товара в определенном магазине за определенный месяц фиксируются в таблице фактов, имеющей название «Продажи». Соответственно в данной системе будет 3 измерения: «Дата», «Магазины» и «Товары». Мерой в таблице фактов является доход за продажу.
При этом каждое из измерений имеет несколько уровней иерархии. Таким образом, нижним уровнем иерархии «Дата» является «Месяц», выше находятся уровни «Квартал» и «Год». В свою очередь, для иерархий «Магазины» и «Товары» нижними уровнями являются соответственно «Магазин» и «Товар», а верхними - «Регион» (каждый магазин находится в определенном регионе) и «Категория товара» (каждый товар можно отнести к определенной категории). На рисунке 1 показана схема вышеуказанной базы данных в нотации IDEF1 [5].
66
В проекте стандарте объектных БД определен язык ODL (Object Definition Language -язык определения объектов), синтаксис которого аналогичен синтаксису C++ и Java, однако точно с ними не совпадает [6].
Регнон-'З Магазин'1
Ш региона Ш магазина
Название решат. 1 Р * Название магазина
Магазины Ш региона (ЕК)
Продажи'8
Рис. 1 - Схема базы данных торговой сети
Месяц- 5
Описание класса «Продажи» на языке ODL будет выглядеть следующим образом:
class FactSales {
attribute Month factmonth; //ссылка на объект класса «Месяц» attribute Shop factshop; //ссылка на объект класса «Магазин» attribute Goods factgoods; //ссылка на объект класса «Товар» attribute float profit; //доход (мера таблицы фактов)
}
Таким образом, в таблице фактов содержатся ссылки на экземпляры классов измерений нижнего уровня иерархии. В свою очередь, классы измерений в своем описании содержат атрибуты связи с экземплярами классов более высоких уровней иерархии. Например для класса «Месяц»:
dass Month {
attribute string CodeMonth; //код месяца в БД (например, "01-2013") relationship Quarter quarter
inverse Quarter::months; //описание связи с классом "Квартал" (месяц
//всегда принадлежит к определенному //кварталу, квартал имеет 3 месяца)
}
В классе «Квартал» также имеется вышеуказанная связь с классом «Месяц», а также связь с классом «Год».
dass Quarter {
attribute string CodeQuarter; // код месяца в БД (например, "1 кв-2013) relationship set<Month> months
inverse Month::quarter; //описание связи с классом "Месяц", в данном
//случае атрибут представляет множество //экземпляров класса "Месяц", поскольку в //квартале более чем 1 месцяц
relationship Year year
67
}
inverse Year::quarters //описание связи с классом "Год", в котором
//также определена соответственная связь
dass Year
{
attribute integer CodeYear; relationship set<Quarter> quarters
inverse Quarter::year; //соответствующая связь с классом «Квартал»
}
Соответствующие связи между собой имеют классы и других измерений. В отличие от таблицы фактов, которая содержит ссылки на экземпляры классов измерений, классы измерений содержат атрибуты связи с классами измерений более высокого уровня для того, чтобы не нарушить целостность базы данных.
При агрегировании данных на более высоком уровне к измерениям можно обращаться с помощью точечного синтаксиса, применяемого в объектной модели данных, например:
Month.Quarter.CodeQuarter - код квартала, в который входит месяц;
Month.Quarter.Year.CodeYear - год, в который входит месяц (доступ через объект класса «Квартал»).
С помощью точечного синтаксиса можно также обратиться к значениям более высокого уровня иерархии к более низкому, например:
Year.Quarter[n].CodeQuarter - код n-го квартала года;
Year.Quarter[n].Month[m].CodeMonth - код m-го месяца n-го квартала года;
Таким образом, становится возможным агрегирование по измерениям с уровнями иерархий большого количества. При этом нет избыточности данных, которое возникает при ненормализированности таблицы фактов в MOLAP и схеме «звезда» в ROLAP. С другой стороны, агрегирование по более высоким уровням иерархии не будет таким затратным по времени, как при использовании схемы «снежинка» в ROLAP. Так объектная модель данных может решить две проблемы при проектировании OLAP, а именно, проблему избыточности данных, возникающую при использовании денормализированных таблицах, и проблему увеличения количества операций при нормализации базы данных, что приводит к снижению скорости работы системы в целом.
2. Использование метаданных при построении OLAP-системы в ООСУБД
Ниже рассматриваются вопросы проектирования и реализации системы OLAP для объектно-ориентированных СУБД. Данная задача является одной из задач научного исследования, касающегося интеграции информационных технологий баз данных, баз знаний и Data Mining. Так, с использованием объектной модели данных были разработаны OLAP-кубы для трёх различных баз данных: торговой компании, продажи автомобилей и компьютерной сети. Для построения кубов использовался алгоритм многопозиционного агрегирования многомерного массива [7]. Все три базы данных относятся к совершенно разным предметным областям. Поэтому возникла задача создания OLAP-системы, которую можно было бы использовать для произвольной объектной базы данных. При этом возникает одна острая проблема: OLAP-средство не может работать с произвольной объектной базой данных в связи со статическим встраиванием схемы базы данных в объектное приложение [8]. Поэтому можно сделать вывод, что для реализации технологий OLAP (а затем и Data Mining) необходимо использовать метаданные. В работе [9] предлагается описание следующих метаданных, представляющих собой метаклассы: объект, простой тип, сложный тип, атрибут, параметр, связь между классами. На их основе в данной работе предлагается добавить такие метаклассы: пакет, таблица фактов, измерение, мера, куб. Диаграмма данных метаклассов представлена на рис. 2.
Метакласс «Таблица фактов» вводится потому, что таблица фактов является специфической таблицей, в которой должны быть отображены измерения и меры для построения OLAP-куба.
68
Рис. 2 - Диаграмма метаклассов OLAP-системы в объектно-ориентированной СУБД
В данном метаклассе хранится информация про название соответствующей таблицы фактов, ее измерения, меры и кубы.
class FactTable
{
attribute string Name; //название таблицы фактов attribute date CreationDate; //дата создания relationship Package ParentPackage inverse Package::FactTables; //связь с метаклассом «Пакет», пакет
//(схема данных) может иметь //несколько таблиц фактов relationship set<Dimension> Dimensions inverse Dimension::facttable //связь с метаклассом «Измерение» relationship set<Measure> Measures inverse Measure::facttable // связь с метаклассом «Мера»
}
Метакласс «Измерение» хранит информацию о наборе доменов, по которым будет строиться многомерное пространство. Измерение относится к определенной таблице фактов, его типом будет некий предметный класс, определенный в системе. Также в данном метаклассе хранится количество значений измерения, список значений и специальный параметр шага, который используется при выполнении алгоритма многопозиционного агрегирования многомерного массива при построении OLAP-куба.
class Dimension
{
attribute string Name; //название измерения attribute Object Type; //тип измерения
attribute integer Number; //количество значений измерения (а именно
//количество экземпляров класса данного //измерения)
attribute set<String> Values; //список значения измерения relationship FactTable facttable inverse FactTable::Dimensions;
}
Метакласс «Мера» хранит информацию об атрибуте таблицы фактов, по которому будет происходить агрегирование. Таблица фактов может иметь несколько мер. Типом меры является некоторый простой тип (целое число, вещественное число и т. д.), определенный в
69
системе. Также существуют различные функции агрегирования: сумма, количество, среднее значение, минимум, максимум и т. д. Данный метакласс содержит информацию о названии меры, ее тип, функции агрегирования.
class Measure
{
attribute string Name; //название меры attribute SimpleType Type; //тип меры attribute string AggrFunc; //функция агрегирования relationship FactTable facttable inverse FactTable::Measures;
}
Последний из добавленных метаклассов «Куб» содержит информацию о названии OLAP-куба, дате его создания и таблице фактов, на основе которой построен данный куб.
class Cube
{
attribute string Name; //название куба attribute date CreationDate; //дата создания куба relationship FactTable facttable inverse FactTable::Cubes;
}
Выводы и дальнейшие направления исследований
На данный момент апробированы алгоритмы построения кубов OLAP для трёх баз данных с различными предметными областями [10], также реализована часть представленной на вышеуказанной диаграмме системы, представляющая подсистему проектирования базы данных посредством метаклассов и ведения данных путём создания, удаления и модификации экземпляров классов, спроектированных с помощью метаданных. Создание метаклассов позволит существенно упростить проектирование OLAP-приложений в среде объектных СКБД. Ведется также работа по реализации подсистемы OLAP в данной системе. В дальнейшем планируется проектирование подсистемы интеллектуального анализа данных (Data Mining), представляющей алгоритмы поиска ассоциативных правил в OLAP-кубах.
Литература
1. Барсегян А. А., Куприянов М. С., Степаненко В. В., Холод И. И. Методы и модели анализа данных: OLAP и Data Mining. - СПБ: БХВ-Петербург, 2004.
2. Паклин Н. Б., Орешков В. И. Бизнес-аналитика: от данных к знаниям: Учебное пособие. 2-е изд., перераб. и доп. - СПб.: Питер, 2010.
3. Харинатх С и др. Microsoft SQL Server Analysis Services 2008 и MDX для профессионалов. :Пер. с англ. - М.: ООО «И.Д. Вильямс», 2010.
4. Кирстен В., Ирингер М., Кюн М., Рериг Б. Постреляционная СУБД Cache 5. Объектноориентированная разработка приложений. - 3-е изд., перераб. и дополн. - М.: ООО “Бином-Пресс”, 2008.
5. Вендров А.М. CASE-технологии. Современные методы и средства проектирования информационных систем, www.citforum.ru
6. Харрингтон Д. Проектирование объектно-ориентированных баз данных: Пер. с англ. - М.: ДМК Пресс, 2001.
7. Кудрявцев Юрий, факультет ВМиК МГУ. Обзор алгоритмов MOLAP, 2008. - Режим доступа: http://www.citforum.ru/consulting/BI/molap overview/node2.shtml.
8. Коновалов А.В. Анализ данных в объектно-ориентированных СУБД //Искусственный интеллект (Донецк), 2000, № 2, c.74-81.
9. Труб И.И. СУБД Cache: работа с объектами. - М.: Издательство ДИАЛОГ-МИФИ, 2006.
10. Фюун М.Т., Горбань Г.В. Анатз особливостей об’ектно! та багатовимiрноi моделей даних в СКБД Cache //Вестник Херсонского национального технического университета. - 2011. -№2(41). -С. 116-124.
70
УДК 004.89
ИНТЕГРАЦИЯ МНОГОАГЕНТНЫХ БАНКОВ ЗНАНИЙ С ОТКРЫТЫМИ
ОБРАЗОВАТЕЛЬНЫМИ МОДУЛЬНЫМИ МУЛЬТИМЕДИА СИСТЕМАМИ
Зайцев Евгений Игоревич, к.т.н., доцент, Московский государственный университет приборостроения и информатики, Россия, Москва, zei@tsinet.ru
Для создания сетевых электронных образовательных ресурсов (ЭОР) с интерактивным мультимедиа-контентом была разработана единая программная среда функционирования -открытая образовательная модульная мультимедиа-система (ОМС) [1,2]. Интеграция сетевых ЭОР, разрабатываемых в среде ОМС, которые, благодаря своим преимуществам, получили наименование электронных образовательных ресурсов нового поколения (ЭОР НП), с многоагентными банками знаний обеспечивает дальнейшее развитие современных образовательных технологий. Благодаря этой интеграции ЭОР становятся полноценным инструментом образовательной деятельности, который может использоваться для распределения учебных заданий и мониторинга их выполнения, личностноориентированного обучения с выбором наиболее подходящих для пользователя учебных материалов и интерактивных образовательных модулей, а также для реализации вопросноответных отношений.
Совокупный контент OMC разделен на модули, соответствующие тематическим элементам и компонентам учебного процесса. При этом каждый модуль может иметь аналог-вариатив, отличающийся элементами содержания, методикой, технологией исполнения. Электронный учебный модуль (ЭУМ) является автономным, содержательно и функционально полным образовательным ресурсом, предназначенным для решения определенной учебной задачи.
Общая архитектура ОМС объединяет две составляющие: серверную, единую для множества пользователей, и клиентскую, расположенную на рабочем месте каждого пользователя.
На сервере хранится совокупный контент ЭОР, представляющий собой структурированное множество интерактивных образовательных модулей (ИОМ). Серверная часть ОМС объединяет средства хранения и поиска требуемых ИОМ, совокупность объектно-ориентированных пользовательских интерфейсов и интернет-сервисов, удовлетворяющих дополнительные запросы пользователей, связанные с данной предметной областью. Так как серверная часть электронных образовательных ресурсов представляет собой набор хорошо известных интернет-сервисов, то в качестве хранилища совокупного контента ЭОР может выступать любой интернет-сайт или портал.
Серверная часть обеспечивает выполнение следующих функций:
• централизованное хранение ЭОР по предметным областям в виде совокупности ИОМ;
• разграничение прав доступа при получении и публикации ИОМ;
• поиск, выбор и выдача ИОМ по запросу пользователя;
• выдача выборки из метаданных указанного пользователем ИОМ.
Клиентская часть обеспечивает выполнение следующих функций:
• получение информации о доступных ЭОР и составляющих их ИОМ;
• доставка избранных ИОМ на рабочее место пользователя;
• организация локального хранилища избранных ИОМ на рабочем месте пользователя;
• воспроизведение ИОМ.
У пользователя имеется два основных варианта доступа к интерактивным образовательным модулям: с помощью поисковых запросов и посредством объектноориентированных интерфейсов, обеспечивающих навигацию и предметный, интуитивно ясный выход на тот или иной ИОМ.
Совокупный контент ОМС состоит из предметных ЭОР, каждый из которых, в свою очередь, является совокупностью электронных учебных модулей. Электронные учебные
71
