автореферат диссертации по информатике, вычислительной технике и управлению, 05.13.13, диссертация на тему:Методы снижения сетевой нагрузки в OLAP системах

2 ВВЕДЕНИЕ.

3 ОБЗОР СОВРЕМЕННОГО СОСТОЯНИЯ СИСТЕМ МНОГОМЕРНОГО АНАЛИЗА ДАННЫХ.

3.1 Общая архитектура систем поддержки принятия решений.

3.2 Особенности систем многомерного анализа данных.

3.3 Передача данных по сети в OLAP системах.

3.4 Обзор литературы.

3.5 Структура диссертационной работы.

3.6 Выводы.

4 ОБЩИЕ ВОПРОСЫ СИСТЕМ МНОГОМЕРНОГО АНАЛИЗА.

4.1 Размеры реляционного и многомерного хранилищ данных.

4.2 Модель агрегации данных.

4.3 Особенности учета передачи данных по сети.

4.4 Производительность систем многомерного анализа данных.

4.5 Выводы.

5 ЗАГРУЗКА ДАННЫХ.

5.1 Способы извлечения данных.

5.2 Основные способы загрузки данных.

5.3 Скорость изменения данных.

5.4 Определение частоты обновления данных.

5.5 Эффективная загрузка данных.

5.6 Выводы.

6 ОБРАБОТКА ПОЛЬЗОВАТЕЛЬСКИХ ЗАПРОСОВ.

6.1 Модель обращения к реляционным данным.

6.2 Модель расчетов на стороне клиента.

6.3 Выводы.

7 ЭКСПЕРИМЕНТАЛЬНАЯ ЧАСТЬ.

7.1 Условия проведения эксперимента и исходные данные.

7.2 Проверка адекватности модели предварительного расчета количества ячеек агрегированных данных.

7.3 Эксперименты по загрузке данных.

7.3.1 Извлечение данных из источников.

7.3.2 Определение эффективной частоты обновления данных.

7.4 Эксперименты по обработке пользовательских запросов.

7.4.1 Простое извлечение данных из многомерной базы данных.

7.4.2 Проверка модели гибридного OLAP.

7.5 Имитационное моделирование.

7.5.1 Простая модель гибридной OLAP системы.

7.5.2 Модель многопользовательского режима при децентрализованных вычислениях.

7.5.3 Полная модель системы многомерного анализа данных.

7.6 Выводы.

^ В последнее время на рынке систем, позволяющих осуществлять анализданных, все большую популярность приобретают системы многомерного анализа известные также как On-Line Analytical Processing (OLAP) системы. Популярность этих систем заключается в том, что они позволяют пользователю, являющемуся специалистом в конкретной бизнес области, самостоятельно формировать различные запросы к базе данных, для выполнения анализа имеющихся данных. Эта легкость получения данных и обусловлена так называемой многомерностью, которая заключается в разделении данных на показатели, содержащие данные о различных событиях, анализируемой предметной области, и измерения, формирующие контекст рассматриваемых событий. Вторым и, пожалуй, наиболее важным моментом, делающим этот инструмент анализа данных столь эффективным, является наличие предварительно рассчитанных обобщенных или, как их еще принято ф называть, агрегированных данных, с которыми, в конечном итоге, в основномработает аналитик. Использование агрегированных показателей позволяет более наглядно отображать информацию о различных процессах, что значительно упрощает процесс принятия решения руководителем.

Передача данных по сети в системах многомерного анализа происходит при загрузке данных из внешних источников в многомерную базу данных и при обработке пользовательских запросов. Эти два процесса характеризуются различными свойствами. Так, загрузка данных осуществляется в определенные моменты времени, обычно по ночам, и характеризуется относительно большими объемами данных, передаваемых по сети, по сравнению с результатами пользовательских запросов. Источники данных по отношению к системе многомерного анализа являются внешними и в большинстве случаев не подлежат, каким либо существенным изменениям. Уменьшить сетевую ^ нагрузку при загрузке данных можно с помощью рациональной организациипроцесса обновления и в первую очередь изменяя частоту обновления данных.

Работа пользователей с системой характеризуется высокой интенсивностью запросов, адресуемых в непредсказуемые моменты времени, но при этом относительно малыми объемами данных, передаваемых по сети. Многомерные базы данных хранят не все значения, необходимые для выполнения анализа, поэтому часть показателей рассчитывается оперативно при обработке пользовательского запроса. Некоторые продукты позволяют частично разгрузить сервер многомерной базы данных, перенеся вычисление некоторых показателей на рабочие станции пользователей. Что при определенных условиях приводит к увеличению трафика между сервером многомерной базы данных и пользователем, так как обычно для вычисления агрегированных показателей, требуется обращение к детальным данным, которые скорей всего не содержались в запросе. Другим аспектом обработки пользовательских запросов, приводящем к значительным нагрузкам на сеть, является обращение к реляционным данным, которое проявляется при использовании гибридной (HOLAP) или реляционной (ROLAP) архитектур системы многомерного анализа.

Подробнее эти, а также некоторые другие вопросы, связанные с уменьшением сетевой нагрузки в системах многомерного анализа, рассматриваются в соответствующих разделах данной работы.

Актуальность темы диссертационного исследования. Активное развитие средств многомерного анализа данных, привело к созданию целого ряда работ, имеющих отношение к описанию принципов организации и построению моделей систем многомерного анализа. Данные работы хоть и упоминают, что OLAP системы обрабатывают, а значит, и пересылают по сети, большие объемы данных, и что сеть является важным компонентом таких систем, но при этом не уделяют должного внимания подробному рассмотрению вопросов, связанных с сетевой нагрузкой, создаваемой в процессе функционирования OLAP систем, не говоря уже о снижении данной нагрузки. Это обусловлено в первую очередь относительной молодостью даннойтехнологии. И действительно, популярность многомерных баз данных насчитывает чуть больше 10 лет, в то время как реляционный подход успешно существует десятки лет. Поэтому основная масса работ, посвященных исследованию многомерного анализа данных, в первую очередь посвящена проектированию подобных систем. Приведенная в данной работе модель функционирования систем многомерного анализа данных с точки зрения сетевой нагрузки и созданные на ее основе методы снижения сетевой нагрузки должны восполнить этот пробел.

Помимо этого, созданные на основе разработанной модели методы снижения сетевой нагрузки, за счет применения рационального выбора параметров функционирования системы, позволяют не только уменьшить сетевую нагрузку, не прибегая к увеличению вычислительных ресурсов, но и обеспечивают повышение эффективности работы пользователей данной системы за счет более рациональной организации таких процессов, как загрузка данных, управление обращением к реляционным данным и распределением оперативных вычислений. Уменьшение сетевой нагрузки, не прибегая к увеличению вычислительных ресурсов, достигается за счет того, что источники данных и пользовательские приложения, в созданной модели рассматриваются, как внешние по отношению к системе многомерного анализа данных, а значит, не подлежат модификациям. При этом уменьшение сетевой нагрузки осуществляется без ущерба для процесса анализа данных. То есть сохраняется требуемая актуальность и полнота хранимых данных. Кроме этого, освобождение общего ресурса снижает задержки в работе пользователей других приложений, функционирующих в данной сети.

Состояние изученности проблемы. Актуальные вопросы, связанные с изучением отдельных сторон исследуемой области, нашли свое отражение в основном в трудах зарубежных авторов, таких как Эдгар Кодд, Билл Инмон, Ральф Кимбалл, Эрик Томенсен и многих других. Однако в последнее время все больше отечественных авторов обращают свое внимание на вопросы, такили иначе связанные с анализом данных. Среди них стоит выделить Куприянова М.С., Архипенкова С.Я., Лисянского К.Б., Хрусталева Е.М. Но подавляющее большинство работ, так или иначе, лишь немного касаются темы сетевой нагрузки в системах анализа данных, концентрируясь, в основном, либо на общих принципах организации подобных систем, либо рассматривая крайне специфические вопросы, не охватывающие различные аспекты функционирования OLAP систем. Однако рассмотрение вопроса функционирования систем многомерного анализа данных с точки зрения сетевой нагрузки необходимо осуществлять комплексно, так как данный процесс неразрывно связан со всеми этапами функционирования системы. На данный момент хорошо изучены вопросы, связанные с извлечением данных из реляционных источником и передачей их по сети, а также различные вопросы агрегации данных. Эти процессы являются важными в рамках загрузки данных и обработки пользовательских запросов, но далеко не единственными.

Цель и задачи исследования. Основной задачей данной работы является создание методов, позволяющих снизить сетевую нагрузку в системах многомерного анализа данных. Для достижения этой цели были решены следующие задачи:1. Построена аналитическая модель, описывающая функционирование систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки.

2. С помощью ряда экспериментов доказана адекватность построенной модели. Эксперименты проводились как на реальных OLAP серверах, так и с помощью имитационного моделирования.

3. На основании аналитической модели создан ряд методов, позволяющих снизить сетевую нагрузку, за счет изменения параметров функционирования системы.

Объектом исследования данной работы является система многомерного анализа данных, а также сеть передачи данных, в которой она функционирует.

Предметом исследования, соответственно, является сетевая нагрузка, создаваемая системой многомерного анализа данных, и влияние различных параметров системы на нее.

Рабочей гипотезой было принято положение о том, можно разработать, описать и обосновать модель, охватывающую все аспекты функционирования систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки и с помощью этой модели создать методы, позволяющие снизить сетевую нагрузку без ущерба для процесса анализа данных.

Методология и методы проведенного исследования. Для достижения поставленных в работе целей использовались следующие методы исследования: методы, теоретического исследования (абстрагирование, анализ, моделирование), методы эмпирического исследования (наблюдение, сравнение, измерение, эксперимент), методы, основанные на положениях теории вычислительных систем и технологии имитационного моделирования. Методология исследования заключается в последовательном создании аналитической модели, позволяющей вычислять те или иные характеристики системы многомерного анализа данных, связанные с сетевой нагрузкой, проверка модели путем проведения различных экспериментов как на реальных OLAP серверах, так и с помощью имитационного моделирования, и разработка методов снижения сетевой нагрузки, на основании созданной модели, с последующим подтверждением полученных закономерностей на практике.

Научная новизна исследования. В диссертации получены следующие научные результаты, характеризующиеся научной новизной. Разработана и обоснована аналитическая модель, всесторонне описывающая функционирование систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки. Создан ряд методов, позволяющих снизить сетевую нагрузку OLAP систем за счет изменения параметров функционирования. В первую очередь это метод определения эффективной частоты обновления данных, обеспечивающей требуемую степень актуальностиданных и при этом не приводящей к перегрузке системы. Метод рационального распределения оперативных вычислений, выполняемых при обработке запросов щ пользователей, между сервером многомерной базы данных и рабочей станциейпользователя. И, наконец, метод оценки и управления избыточной сетевой нагрузкой при обращении к реляционным данным. Новизна данной работы обусловлена именно всесторонним рассмотрением вопросов, связанных с функционированием систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки, на предмет его уменьшения.

Практическая и экономическая значимость полученных результатов. В ходе работы создана и описана модель функционирования систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки. Созданные на основании модели методы снижения сетевой нагрузки позволяют эффективно организовать процессы загрузки данных из внешних источников и обработки пользовательских запросов. Повышение эффективности использования вычислительных ресурсов в существующих системах ^ многомерного анализа данных, за счет рационального выбора параметровфункционирования, позволят избежать увеличения вычислительных ресурсов, что не может не давать экономического эффекта. Приведенные в рамках описания экспериментов примеры выполнения расчетов с помощью созданной аналитической модели, наглядно демонстрирующие применение результатов работы к реальным условиям, являются ценными с практической точки зрения.f3 Обзор современного состояния систем многомерного ^ анализа данныхВ данном разделе рассматриваются основные вопросы, связанные с построением систем многомерного анализа данных, определена терминология, используемая в данной работе, проведен обзор содержимого имеющихся на данный момент работ в исследуемой области, а также описаны аспекты, оказывающие влияние на сетевую нагрузку в системах многомерного анализа данных.

3.1 Общая архитектура систем поддержки принятия решенийТехнология многомерного анализа данных получила название OLAP (Оп-Line Analytical Processing) в 1993, когда вышла в печать статья известного исследователя в области баз данных Эдгара Кодда «Providing OLAP (On-Line Analytical Processing) to User-Analysts» [44], в которой он определил основные ^ концепции многомерного анализа данных и сформулировал 12 правил, ставшихв последствии определением OLAP. В достаточно короткие сроки, после выхода указанной статьи технология многомерного анализа данных стала очень популярной. Сейчас все производители, лидеры на рынке реляционных баз данных, такие как IBM, Microsoft, Oracle и другие имеют в перечне своих продуктов и сервера многомерных баз данных. Некоторые производители реляционных баз данных, такие как Microsoft поставляют средства многомерного анализа данных вместе со своими СУБД, другие (Oracle Corp.) пошли еще дальше совершили объединение реляционного и многомерного ядра в одном продукте. В данной работе приведено исследование вопросов связанных с функционированием систем многомерного анализа, построенных с помощью различных вариантов существующих на данный момент архитектур. Так, «классической» архитектурой системы поддержки принятия решений (далее СППР) является так называемая трехуровневая архитектура, представленная на рисунке 1:Витрина данныхВитрина данныхВитрина данныхOLTP □бумажныеносители @Магнитные носителиИТелефонСредства извлечения, очистки и загрузки данных (ETL)Централизованное хранилище данныхOLAPПользователиOLAPРис. 1 Архитектура системы поддержки принятия решений на основе OLAPЦентральным элементом данной архитектуры является хранилище данных (ХД), в которое поступают данные из различных источников, таких как существующие информационные системы или OLTP системы, данные из различных архивов, а так же другие самые разнообразные источники. Задача центрального ХД заключается в том, что бы собрать в едином месте всю имеющуюся в организации информацию и поддерживать ее согласованность и правильность. Автор концепции хранилищ данных, Билл Инмон, определил хранилища данных, как [49]: "предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные для целей поддержки управления", призванные выступать в роли "единого и единственного источника истины" обеспечивающего менеджеров и аналитиков достоверной информацией необходимой для оперативного анализа и принятия решений.

Наиболее сложный для формализации этап организации хранилища данных заключается в создании процедур загрузки данных, так как на этом этапе необходимо собрать информацию из разнородных, а значит несогласованных источников данных, привести к единому формату не толькоструктуры, но и непосредственно сами данные, то есть произвести их очистку. Второй основатель концепции хранилищ данных — Ральф Кимбалл — в своей работе «The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses» [50] исходит из принципа, что структура ХД должна быть максимально простой, чтобы обеспечивать эффективное выполнение анализа данных. Стандартные схемы таблиц хранилищ данных — «звезда» и «снежинка» — имеют структуру наиболее оптимальную для проведения анализа, так как минимизируют число соединений между таблицами.

Так как хранилище данных зачастую бывает достаточно объемным (некоторые хранилища данных достигают объемов в терабайты), то для нужд отдельных подразделений строятся так называемые витрины данных (data mart), содержащие только подмножество данных из центрального ХД. При этом проблем с организацией витрин данных нет, так как они строятся на основе единого источника данных, а значит, уже являются согласованными. Использование витрин данных позволяет уменьшить нагрузку на центральное хранилище данных, при этом для поддержки витрины данных требуется не такое мощное аппаратное обеспечение, как для хранилища данных, в виду значительно меньших объемов хранимых данных. Совсем не обязательно, что витрины данных строятся с помощью механизмов реляционных баз данных, например, Бил Инмон к термину витрины данных относит и многомерные базы данных, так как они по своей сути также содержат подмножество данных из центрального ХД.

На основе существующих хранилища данных или витрин данных строятся аналитические приложения различной природы. Это могут быть и простые средства построения статических отчетов, которые широко распространены в OLTP системах. Однако на основе ХД и витрин данных используют более сложные средства анализа данных, такие как системы создания нерегламентированных отчетов (ad hoc query), средства добычиданных (data mining) и средства многомерного анализа (OLAP). Так как в данной работе делается акцент именно на последних средствах анализа данных, то на рисунке 1 в качестве клиентских приложений изображены именно OLAP сервера.

Как уже было отмечено ранее, в хранилищах данных в основном используются две стандартные схемы данных — это «звезда» и «снежинка». Данные схемы представлены на рисунке 2:«Снежинка»Рис. 2 Схемы хранилищ данныхВ данных схемах существует два вида таблиц — таблицы измерений, описывающие объекты предметной области, и таблицы фактов, содержащие информацию о событиях, связанных с объектами. Как видно из рисунка 2 таблица фактов находится в центре каждой разновидности схемы данных. Именно она содержит сведения необходимые для проведения анализа данных— показатели, которые в основном представляют собой численное описание различных событий внешнего мира.

Данные, содержащиеся в таблицах измерений, используются для создания выборки из таблицы фактов, на основании определенных, зачастуюдостаточно сложных условий, а также содержат текстовое описание предметной области.fc В отличие от схемы «звезда» схема «снежинка» является болеенормализованной и используется при наличии сложных иерархических отношений между членами измерений или большого числа различных атрибутов. Обе этих схемы хорошо подходят для выполнения многомерного анализа данных, так как разделяют данные на показатели и измерения. При этом следует различать такие понятия как многомерное хранение данных и многомерное представление. Приведенные выше схемы позволяют получить многомерное представление данных, оставаясь при этом в сфере реляционного хранения данных.

3.2 Особенности систем многомерного анализа данныхОсновой многомерного представления является многомерных куб данных, который, как не трудно догадаться, состоит из измерений и ^ показателей. Измерения образуют ребра куба, а показатели — его ячейки.

Значения, откладываемые вдоль измерений, называются метки или члены измерения. При этом для каждого члена может быть определен ряд атрибутов, таких как длинная и короткая метка, ссылка на родителя и другая информация, определяемая в зависимости от конкретной реализации OLAP сервера. В зависимости от степени детализации данных члены измерения объединяются в уровни, а уровни в иерархии. Чем выше уровень в рамках конкретной иерархии измерения, тем более обобщенные данные он представляет. Обычно каждое измерение содержит одну иерархию уровней, однако это не является общим правилом, и измерения могут содержать несколько иерархий. Примером измерения с несколькими измерениями является измерение времени, так как помимо календарного года может понадобиться группировать имеющиеся данные в рамках финансового или учебного года, который имеет смещение, % относительно начала календарного.

Что касается показателей в многомерном представлении данных, то они могут быть представлены, если пользоваться терминологий Oracle Express, как £ переменные, которые загружаются из внешних источников данных, так ивычисляемые значения, которые хранятся только как определение выражения. На уровне пользователя (отображение данных) различия между переменными и вычисляемыми значениями не существует.

Наиболее эффективное манипулирование данными при многомерном анализе обеспечивают средства, изначально хранящие данные в многомерных структурах, так как при этом не требуется преобразования из одной формы представления в другую. Такие средства получили название сервера многомерных баз данных, а сами наборы данных, изначально организованные с точки зрения многомерного представления данных — многомерные базы данных (МБД). Но такой способ хранения данных имеет и свои недостатки. Так, чем больше размерность многомерного куба и чем детальней в нем представлены данные, тем больше эти данные разрежены. А специфика ^ многомерной формы хранения данных такова, что разреженные данные в ней хранятся не эффективно.

Все системы многомерного анализа данных, исходя из способа хранения детальных и агрегированных данных в рамках архитектуры, представленной на рисунке 1, принято разделять на три класса:• Многомерный OLAP — MOLAP• Реляционный OLAP — ROLAP• Гибридный OLAP —HOLAPВ случае использования MOLAP архитектуры все типы данных хранятся в многомерной базе данных. При этом достигается максимальная производительность системы, так как соответствие между многомерным представлением данных и их хранением является прямым в виду специализации OLAP серверов. Однако на данных момент практически всесервера МБД обладают достаточно плохой масштабируемостью и не могут эффективно поддерживать базы данных более 10-20 Гбайт.

Многомерное хранение данных накладывает определенные ограничения на операции изменения данных, содержащихся в МБД. Все MOLAP сервера поддерживают операции загрузки данных, но далеко не все из них позволяют модифицировать или удалять данные. Зачастую для выполнения этих операций требуется полная перезагрузка всей МБД из внешнего источника данных.ROLAP архитектура, хранящая как детальные, так и агрегированные данные в реляционном ХД, использует все достижения современных РСУБД и прекрасно справляется с большими объемами данных, поддерживает масштабируемость системы, но однако в виду необходимости трансформации реляционного представления данных в многомерное с помощью промежуточного слоя метаданных на этапе ответа на запросы пользователей, значительно уступает в производительности MOLAP системам в области аналитических приложений.

Попытка взять все преимущества от двух вышеперечисленных архитектур систем многомерного анализа данных реализуется в так называемой гибридной OLAP системе (HOLAP). При таком построении системы многомерного анализа данных детальные данные остаются там где и были, то есть в реляционном хранилище данных, в то время как агрегированные данные располагаются в многомерной базе данных. Данный подход исходит из трех предпосылок. Во-первых, детальные данные всегда значительно разреженней, чем агрегированные, таки образом, сервера МБД будут эффективней справляться с более плотными агрегированными данными, хранящимися в МБД. Во-вторых, так как детальные данные хранятся в реляционной ХД, то итоговый объем МБД оказывается меньше, чем при MOLAP архитектуре, а значит, большее количество фактов можно поместить в МБД для анализа. И, наконец, третья предпосылка для организации систем многомерного анализа на подобной архитектуре заключается в том, что пользователь работает восновном с агрегированными данными, поэтому обращения к более медленному реляционному хранилищу данных будут не сильно сказываться на общей производительности системы.

Однако и данный подход не лишен недостатков. Так, в данном случае используется промежуточное звено при организации сети, в которой функционирует система многомерного анализа, а значит, влечет за собой потерю производительности не только за счет обращения к более медленному реляционному хранилищу данных, но и за счет передачи данных по дополнительному участку сети, который не всегда можно сделать выделенным и свободным от данных других приложений. Третий недостаток подобной архитектуры заключается в том, что для выполнения предварительной агрегации необходимо передавать по сети все детальные данные, имеющиеся в системе, что может привести к значительному увеличению времени выполнения предварительной агрегации на этапе периодической загрузки данных.

Как уже было отмечено ранее, один из аспектов высокой производительности систем многомерного анализа является наличие предварительно рассчитанных обобщенных значений, хранимых в МБД наряду с детальными данными, загруженными из внешнего источника данных. При этом рассчитываются как агрегированные показатели, так и различные вычисляемые значения. Однако предварительно рассчитать все возможные значения, необходимые пользователю невозможно по двум причинам. Во-первых, если число уровней агрегации данных известно и определяется если не при проектировании МБД, то, по крайней мере, при загрузке данных, то предугадать, какие вычисляемые значения потребуются пользователю, невозможно, так как многие средства, обеспечивающие доступ пользователя к МБД позволяют создавать свои собственные вычисляемые показатели, которые могут вычисляться как на стороне сервера, так и на рабочей станции пользователя. Во-вторых, полный предварительных расчет всех уровнейагрегации, а также даже части вычисляемых выражений, которые могут оказаться полезными для пользователя, приведет к такому увеличению размера МБД, то большая часть производительности будет тратиться на поиск необходимых записей в файлах МБД.

Подобный феномен называется «взрыв базы данных» [57] и заключается в том, что, загрузив 10-50 Мбайт данных, результирующий объем всей многомерной базы данных окажется порядка одного гигабайта. Во избежание «взрыва» многомерной базы данных предварительно рассчитываются не все возможные обобщенные показатели, а только наиболее затребованные, а остальные рассчитываются только в момент обращения пользователя к необходимому уровню детализации и не сохраняются в МБД после ответа на запрос. Данный процесс называется оперативная агрегация или более обобщенно — оперативные вычисления.

3.3 Передача данных по сети в OLAP системахРассмотрев основные аспекты организации систем многомерного анализа данных можно перейти к вопросам, непосредственно рассматриваемым в данной работе, а именно к описанию процессов, приводящих к передаче данных по сети в системах многомерного анализа и возможным путям снижения сетевой нагрузки.

В системах многомерного анализа данных, передача данных по сети происходит при загрузке данных в МБД и обработке запросов пользователей. Для начала рассмотрим основные аспекты загрузки данных. Эти процессы характеризуются различными свойствами, однако включают в себя этапы трех видов: извлечение данных из реляционного или многомерного источника, передача данных по сети, расчет агрегированных показателей.

Загрузка данных, предназначена для согласования МБД с внешним миром или другими словами для поддержания актуальности хранимых данных.% Данный процесс состоит из извлечения данных из внешних источников, передачи их по сети и выполнению предварительного расчета показателей.

Загрузка данных бывает как первоначальная, когда в МВД загружаются все имеющиеся в ХД данные, и инкрементальная, когда происходит добавление только новых данных. На первый взгляд может показаться, что первоначальная загрузка, согласно своему названию производиться один раз, при создании МВД. Однако это не совсем так. Данная процедура выполняется всегда при изменении размерности многомерного куба, так как практически все механизмы управления многомерными данными не могут поддерживать добавление, удаление и даже переупорядочивание измерений многомерного куба без потери данных. Другим случаем применения первоначальной загрузки является необходимость в увеличении эффективности хранения данных. В процессе добавления данных в многомерных куб данные слабо упорядочены, а так как многомерное хранение данных в первую очередь направлено на эффективное извлечение данных, а не изменение данных, то добавление данных приводит значительному росту общего объема МВД и уменьшению эффективности использования дискового пространства.

Наибольший интерес для данной работы представляет именно инкрементальная загрузка данных, так как этот процесс выполняется намного чаще и является более существенным для поддержания актуальности хранимых данных. В зависимости от способа инициализации процесса загрузки данных инкрементальная загрузка подразделяется на периодическую и загрузку по требованию. Периодическая инкрементальная загрузка выполняется строго по заранее составленному расписанию, а инкрементальная загрузка данных по требованию осуществляется в непредсказуемые моменты и инициализируется внешним источником данных. Данный тип загрузки данных используется для организации так называемого OLAP реального времени или real-time OLAP.

Использование загрузки данных по требованию позволяет достичь наиболее актуальное отображения данных из ХД в средствах многомерного анализа, однако, данный подход имеет существенный недостаток, который заключается в том, что для поддержания актуальности данных в МВД послекаждой загрузки детальных данных необходимо заново рассчитать все агрегированные значения, что приводит к значительной нагрузке на сервер (щ МБД. Поэтому при достаточно высокой частоте обновления данных можетсложиться такая ситуация, что сервер МБД не будет успевать рассчитывать агрегированные показатели между двумя последовательными процедурами загрузки данных.

Для оценки целесообразности применения данного способа загрузки данных необходимо иметь средства, позволяющие рассчитать суммарное время выполнения одного цикла загрузки данных, выключающего в себя извлечение данных из ХД, передачу их по сети и выполнение агрегации, а затем сравнить это время со средним значение периода инициализации процесса загрузки данных внешним приложением. Очевидно, что период обновления данных должен быть меньше суммарного времени выполнения одного цикла загрузки.

При описании процесса загрузки, источники данных являются внешними по отношению к системе многомерного анализа данных и зачастую не ^ подлежат модификациям, и именно от типа источника определяется,извлекаются ли только новые данные или все имеющиеся. С другой стороны, предварительный расчет агрегированных показателей, также может затрагивать либо только новые данные, как это реализовано в Microsoft Analysis Services, либо все имеющиеся в многомерном кубе данные (Oracle Express). Таким образом, получается, что единственный параметр, позволяющий управлять актуальностью хранимых данных и нагрузкой на сеть при периодической инкрементальной загрузке данных, является частота обновления. И чем выше частота обновления, тем выше актуальность данных и, соответственно, нагрузка на сеть.

Второй процесс, при котором происходит передача данных по сети в системах многомерного анализа данных — обработка пользовательских запросов — является более сложным и зависит от различных аспектов * организации МБД, которые можно разделить на два основных класса: этообращение к реляционным данным, которое имеет место при обработке пользовательских запросов в HOLAP и ROLAP архитектурах, а также выполнение оперативных вычислений и распределение их между сервером МБД и рабочей станцией пользователя.

Для начала кратко охарактеризуем вопросы, связанные с обработкой пользовательских запросов в HOLAP и ROLAP архитектурах. Дальнейшее рассмотрение вопросов обращения к реляционным данным будет осуществляться только на примере HOLAP архитектуры, так как ROLAP и MOLAP являются частными случаями HOLAP архитектуры. Как было сказано ранее в данном разделе, при описании различных архитектур систем многомерного анализа данных, в HOLAP архитектуре появляется дополнительное звено при обработке пользовательского запроса, в виде сервера реляционного хранилища данных и соответственно участка сети между серверами МБД и ХД. При этом любое обращение к детальным данным вызывает генерацию SQL запроса сервером МБД, который передается для дальнейшей обработки на сервер ХД. После того, как SQL запрос обработан, данные их ХД передаются по сети обратно серверу МБД, где формируется окончательный ответ пользователю. Следует учитывать, что обращение к детальным данным происходит не только при непосредственном запросе детальных данных пользователем (явное обращение к реляционным данным), работающим с системой, но и при выполнении оперативной агрегации, а также при выполнении оперативных расчетов, которые требуют для своего вычисления либо непосредственно детальных данных, либо значения агрегированных показателей, вычисляемые оперативно (неявное обращение к реляционным данным).

Использование HOLAP архитектуры позволяет уменьшить избыточность хранения данных, так как детальные данных хранятся только в реляционном ХД, а агрегированные — в МБД. Однако при этом увеличивается нагрузка на сеть, в которой функционирует вся система, так как данные необходимосначала передать от сервера ХД к серверу МБД, а уж затем только возвратить их пользователю. Это в значительной мере сказывается на общей £ производительности системы.

Оперативные расчеты, могут выполняться как на стороне сервера МБД, так и на стороне клиента. В свою очередь выражения могут разделяться согласно [2] на простые выражения и агрегирующие. Для вычисления одной ячейки простого выражения требуется не более одной ячейки от каждой переменной, хранящейся в МБД. Для вычисления одной ячейки, на основе агрегирующих выражений требуется, соответственно, несколько ячеек данных, хотя бы для одной переменной МБД.

По аналогии с случаем обращения к реляционным данным, вычисление на стороне клиента, может вызвать необходимость пересылки дополнительных наборов данных, не запрошенных непосредственно пользователем, то есть прямо не указанным в многомерном запросе, однако необходимым для выполнения оперативных вычислений. Значительная нагрузка на сеть ^ приходиться при использовании агрегирующих выражений. Ситуация усугубляется еще больше, при использовании HOLAP архитектуры, когда наличие агрегирующих выражений в запросе приводят к дополнительной нагрузке на сеть, даже в случае вычислений на стороне сервера, не говоря уже про вычисления на стороне клиента. С другой стороны выполнение оперативных вычислений на рабочей станции пользователя позволит частично разгрузить сервер МБД для обработки запросов других пользователей, что при определенных условиях значительно повышает производительность всей системы.

3.4 Обзор литературыВ данном разделе были рассмотрены основные аспекты организации систем многомерного анализа, а также очерчены более специфические 4 вопросы, связанные с сетевой нагрузкой создаваемой в процессе функционирования OLAP систем. Теперь кратко опишем результаты основныхисследований в области многомерного анализа данных имеющихся на момент написания работы.

В начале данного раздела уже было упомянуто о статье Эдгара Кодда [44], являющегося основателем теории многомерного анализа данных, и послужившей основой создания технологии OLAP. Теперь следует упомянуть двух основоположников теории хранилищ данных, так как ХД является одним из наиболее важных атрибутов систем поддержки принятия решений, частью которых являются и системы многомерного анализа данных.

Два отца-основателя идеи хранилищ данных — Билл Инмон и Ральф Кимбалл акцентируют внимания на различных подходах при организации ХД, соответственно современные подходы к моделированию хранилищ данных делятся на два основных класса. Это традиционное ER-моделирование, приверженцами которого являются последователи Билла Инмона и многомерное моделирование — сторонники Ральфа Кимбалла. Использование первого подхода позволяет наиболее полно описать предметные области бизнеса организации и организовать хранение исторической информации. Второй подход позволяет достаточно быстро построить модель для анализа различных показателей.

Билл Инмон является автором почти 40 книг и 250 статей в различных журналах, посвященных различным аспектам организации и моделирования хранилищ данных. В своей основной работе «Building The Data Warehouse» он рассматривает целый ряд вопросов, связанных с построением хранилища данных, начиная от истории возникновения систем поддержки принятия решения и сравнения систем анализа данных с система оперативной обработки транзакций, до вопросов организации метаданных, для эффективного управления хранилищем данных и использования различных технологических аспектов, таких как взаимодействие с различными носителями данных, параллельное хранение и управление данными и т.д. Так же в данной работе онпредлагает читателям детальную методологию создания хранилища данных на основе существующих систем обработки транзакций.

К наиболее важным аспектам организации ХД Билл Инмон относит выбор степени детальности данных (granularity) и разделение данных (partitioning). Со степенью детальности непосредственно связывается так называемый дуализм детальности (dual level of granularity), который имеет место не только для хранилищ данных в частности, но и для всех систем анализа данных в общем. Дуализм заключается в том, что высокая степень детальности данных приводит к значительным объемам данных, что уменьшает производительность системы анализа данных, в то время как низкая детализация данных уменьшает информационную ценность, так как обобщенные данные не могут дать ответа на все вопросы, возникающие у аналитика во время работы с системой. Автор предлагает организовывать многоуровневое хранилище данных, в котором каждый уровень хранит данные определенной степени детализации и предназначенные для различных типов ^ запросов.

Билл Инмон делает акцент и на объединение средств многомерного анализа данных с ХД, определяя МБД, как один из видов специализированных витрин данных. При этом разделяет ХД и МБД по своему предназначению. ХД в первую очередь предназначены для хранения огромных объемов данных за значительный промежутки времени, предоставляя при этом доступ для ограниченного количества пользователей, в то время как МБД содержат относительно небольшие объемы данных для меньших временных отрезков, но оптимизированы на извлечение больших объемов данных и выполнения задач анализа.

Несколько иной взгляд на построение ХД изложен работе другого известного теоретика в области хранилищ данных Ральфа Кимбалла «The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data ^ Warehouses» [50]. Если Билл Инмон в своей работе излагает болеетеоретические основы организации ХД, то Ральф Кимбалл приводит различные примеры использования технологии хранилищ данных в конкретных областях $ деятельности, таких как, управление заказами и человеческими ресурсами,телекоммуникации, транспорт и т.д., при этом переходя от самых простых вопросов организации хранилища данных к более сложным. В своей работе автор делает акцент на многомерное моделирование хранилища данных, которое заключается в разделении данных на измерения и факты. За счет ухода от третьей нормальной формы несколько увеличивается избыточность, зато увеличивается и эффективность проведения анализа в виду отсутствия необходимости в соединении большого числа таблиц.

Представленный в [50] многомерный подход к моделированию хранилищ данных в значительной степени сближает OLAP средства с ХД, что подчеркивает сам автор, говоря о различных стратегиях организации агрегированных данных.

Оба автора сходятся в двух вопросах: в том, что наиболее сложный этап ^ создания ХД является организация процесса загрузки данных из различныхисточников, который обычно занимает порядка 80% трудозатрат всего проекта. А так же то, что процесс создания хранилища данных является итеративным и заключается в последовательном увеличении области охвата анализируемых процессов в рамках конкретной организации.

Так как данная работа все-таки ориентирована на многомерный анализ данных, то основная масса использованной литературы посвящена именно OLAP технологиям. В первую очередь следует выделить работу Эрика Томсена «Solutions: Building Multidimensional Information Systems» [67], которая по своему масштабу и фундаментальности является аналогом трудов Инмона и Кимбалла, только в области OLAP технологий. Причем сам Билл Инмон рекомендует данную книгу для детального изучения вопросов многомерного анализа данных.

Эрик Томсен вводит аббревиатуру ABDOP для основанной на аналитике, ориентированной на принятие решений обработки информации (Analysis-Based it Decision-Oriented informational Processing) под которой он понимает ихранилища данных, и системы поддержки принятия решений, и OLAP, и все то, что понимается под термином интеллектуальный бизнес (Business Intelligence). Другое основополагающее понятие, который вводит автор — это «размещенное содержание» (Located Contents) или сокращено LC модель. Данная модель описывает основные аспекты организации OLAP, такие как иерархические измерения, разреженные и плотные измерения, вычисляемые показатели и т.д. безотносительно к конкретному производителю OLAP сервера. Данная работа в основном исходит именно из LC модели, при рассмотрении тех или иных аспектов организации систем многомерного анализа данных. Однако LC модель больше ориентирована на поликубическую модель данных, так как не производит различий между измерениями и показателями (набор всех показателей куба фактически является п+1 измерением), в то время как в данная работа больше ориентирована на гиперкубическую модель данных, так как она является более обобщающей и может быть легко сведена к поликубической.LC модель использует ряд терминов, которые в различных реализациях OLAP систем обозначают в принципе одно и тоже:• Измерение (dimension), фактор (factor), переменная (variable) — для определения многомерного пространства анализа• Элемент (Element), позиция (Position), экземпляр (instance), член (member) — для определения минимальной единицы данных, содержащихся в измерении.• Мера (Measure), факт (fact), метрика (metric), переменная (variable), формула (formula), ячейка (cell) — для определения содержимого многомерного куба• Атрибут (Attribute), свойство (Property), характеристика (Characteristic) — дополнительные данные, содержащиеся в членах измерений помимо их значений, такие как короткая и длинная метка, ссылка на родителя и т.д.• Уровень (Level), поколение (Generation), предки (Ancestors), потомки (Descendents), родитель/ребенок (Parent/child), иерархия (Hierarchy) — для логического объединения различных членов измерений в зависимости от степени детализации данных.

В данной работе в основном используются термины измерение, член измерения, показатель (переменная или формула), атрибут, уровень и иерархия, соответственно.

Достаточно важным вопросом в [67] является рассмотрение несбалансированных иерархий, то есть иерархий, в которых расстояние от корня до листьев имеет различное число уровней. Разделение иерархий на сбалансированные и несбалансированные значительно усложняет процесс описания процессов, в первую очередь связанных с агрегацией данных. Поэтому во всех литературных источниках, используемых в данной работе, и посвященных моделированию многомерных структур данных, [40], [43], [46], [47], [48], [51], [53], [55], [60], [64], [68], [70], при описании процесса агрегации пользуются сбалансированными иерархиями. Однако это не значит, что указанные работы не полностью рассматривают данный вопрос. На самом деле в месте с постановкой проблемы в [67] присутствует и различные решения, позволяющие достаточно просто описывать сбалансированные и несбалансированные иерархии единым образом. Это:• использование псевдо уровней, то есть добавление при описании иерархии обобщающих членов, для основных уровней. Однако данный подход не позволяет учитывать уровни, не вписывающиеся в «основную» иерархию измерения, что не совсем подходит для точного моделирования процесса агрегации данных.• использование фиктивных членов измерений. Данный подход заключаются в том, что все ветки иерархии при описании дополняются фиктивными членами, так чтобы организовать единую сбалансированную иерархию.

Эрик Томсен в [67] всесторонне рассматривает различные аспекты организации OLAP систем, такие как иерархические измерения, управление разреженными данными, различные типы многомерных формул, задание соответствия между источниками данных и многомерными структурами, а также приводит ряд примеров построения OLAP систем для различных предметных областей в терминах LC модели. Автор не обходит вниманием и рассматриваемые в данной работе вопросы функционирования систем многомерного анализа с точки зрения создаваемой сетевой нагрузки в зависимости от распределения данных в рамках различных архитектур.

Что касается остальной литературы, использованной при написании данной работы, то она носит менее фундаментальный характер и рассматривает различные специфические области многомерного анализа. Поэтому дадим краткую характеристику содержащегося в них материала. Практически всю использованную литературу можно разделить на несколько основных областей:1. Рассмотренные ранее работы, описывающие общие вопросы построения систем многомерного анализа данных2. Работы, посвященные моделированию многомерных баз данных3. Работы, связанные с различными аспектами агрегации4. Специфическая литератураПомимо описанных ранее [50], [49], [67], относящихся к первой области, хотелось бы отметить еще работу Архипенкова С.Я [2]. Это одна из немногих книг на русском языке посвященных системам поддержки принятия решений. И, несмотря на то, что автор ориентируется на Oracle Express в книге можно найти не мало общих принципов построения СППР.

Что касается второй области — моделирования многомерных баз данных — то на настоящий момент существует множество работ, посвященных данным щ вопросам. Более полный обзор существующих моделей многомерногопредставления данных приведен в [61] и [69]. Здесь же стоит упомянуть [43],[53],[68],[60].

В [43] дано формальное описание многомерной базы данных в терминах измерений и f-таблицы. По своей сути данной описание находится в рамках «классического» представления многомерной базы данных, представленного еще в [44]. Однако наиболее интересный аспект данной статьи заключается в формализации трансляции реляционной структуры данных (ER-модели) в многомерную схему с помощью графа измерений. Более интересная концепция модели многомерного куба предложена в [68], где построена модели многомерного куба агрегации (MAC). При этом данная модель пытается описать все многообразие реальных OLAP кубов минимальным набором понятий, таких как уровни измерения (dimensional level), отношения переходов (drilling relationships), пути измерения (dimension paths), измерения, кубы и атрибуты. Авторы концепции многомерного куба агрегации утверждают, что их модель в отличие от других моделей многомерных баз данных удовлетворяет 10 основным свойствам многомерного представления данных. Однако модель, представленная в [68] совсем не затрагивает различные операции, применяемы к многомерным кубам. В [53] авторы предлагают помимо формального описания модели многомерного куба, формальное описание части стандартных операций, присущих многомерному представлению данных, а также расширяют данный набор операциями разделения (split) и слияния (merge), на основании значений атрибутов. К стандартным операциям в [53] относятся срез, агрегация, перемещение по иерархии. Так же формальную модель операций с многомерными структурами данных можно найти в [70], в которой помимо формального описания модели * МБД и операций многомерного анализа данных предпринята попытка созданияформального соответствия между многомерным и реляционным представлением данных, а так же описаны основные операции с многомерными структурами в терминах реляционной алгебры.

Что касается вопросов взаимодействия пользователя с OLAP системой, то работ посвященных данному вопросу значительно меньше, чем моделей многомерных структур данных. Формальное описание поведения пользователя системы многомерного анализа представлено в [60]. В данной работе последовательность запросов пользователя, связанных с получением ответа на один вопрос называется сессией. В рамках сессии пользователь последовательно перемещается по многомерному пространству, начиная с определенной точки входа. Набор схожих шаблонов поведения пользователь называется профиль пользователя. Для отнесения запроса к тому или иному шаблону в [60] предлагается вычислять расстояние между запросами, соответственно и прототипами, на основании количества операций манипулирования многомерными данными, такими как поворот, переход к ^ деталям и ограничение выборки, необходимыми для того, чтобы перейти отрезультата одного запроса к результату другого запроса. При этом у различных приложений для каждого типа операций предлагается использовать свои собственные весовые коэффициенты.

Третья область — агрегация — не спроста выделена отдельно от всех аспектов многомерных баз данных, так как агрегация является одним из основных аспектов, сильно влияющих на производительность системы многомерного анализа в целом и итоговый объем МБД, а значит на объем данных передаваемых по сети, в частности. Но при этом вопросы агрегации имеют значительный элемент неопределенности связанный с характеристиками, содержащихся в МБД данных, их распределению по основным группам агрегации, количеством уровней в различных иерархиях и т.д. Именно из-за этой неопределенности существует множество различныхметодов оценки результирующего объема многомерного куба, а также различные алгоритмы выполнения расчета агрегатов, ф При этом агрегация может выполняться как в многомерной базе данных,так и в реляционном ХД. Общее описание процесса агрегации на основании реляционного представления данных дано в [47]. В [48], [55] и [41] приведены алгоритмы определения числа и содержимого материализованных представлений для обеспечения эффективного выполнения запросов в аналитических приложениях. Если проводить аналогию, то материализованное представление в рамках реляционного ХД является аналогом кубоида в МБД, так как содержит значения показателей для определенных уровней агрегации всех измерений многомерного куба.

Основным, помимо многомерного куба агрегации, представленного в [68], для описания процесса агрегации иногда используют так называемый куб диапазонов (range cube) [46], в котором в отличие от «обычного» многомерного куба последовательности ячеек заменены на диапазоны. Щ В [64] можно найти другие способы оценки объемов многомерных кубовпосле выполнения агрегации. Среди них, так называемый аналитический алгоритм, построенный на стандартном аппарате теории вероятности и позволяющий определить верхнюю границу объема агрегированного куба. Второй алгоритм, представленный в упомянутой работе, позволяет определить результирующий объем агрегированного куба на основании аппроксимации результата небольшой выборки данных. Однако предпочтение в [64] отдается методу, основанному на подсчете вероятностей нахождения уникальных значений в рамках группы значений.

Достаточно интересный подход расчета объема агрегированных данных предложен в [63], где впервые введено понятие функции плотности данных, а для расчета числа агрегированных показателей используется соответственно интегрирование данной функции по необходимым измерениям. Предложенный * метод носит несколько абстрактный характер, так как определениеаналитической функции плотности данных, для выполнения интегрирования на основании заполненности ячеек является задачей не тривиальной. Однако сам ^ подход в использовании такого понятия, как плотность данных являетсяважным для данной работы.

При рассмотрении real-time OLAP или выполнения обновление данных по требованию, было упомянуто, что интенсивность загрузки данных должна быть такой, чтобы успевал произойти процесс вычисления агрегатов. В [51] предложена методика отложенных расчетов (lazy aggregation) в многомерных базах данных, позволяющая организовать обновление по требованию в условиях, когда время, необходимое на выполнение процедуры обновления данных больше, чем период обновления.

Но, не смотря на такое обилие статей, по вопросам, связанным с агрегацией данных, наиболее интересующий нас вопрос — зависимость числа заполненных ячеек агрегированных данных, от числа заполненных ячеек детальных данных — окончательно так и не решен в имеющихся на данный момент публикациях.

Что касается освещения вопросов агрегации данных в русскоязычной литературе, то стоит выделить работу Хрусталева [35], в которой дано формальное описание механизма агрегации данных в многомерных кубах. А также, выведены формулы числа агрегатов при полной и частичной агрегации, представлена математическую модель агрегации данных в виде сетевой модели и описаны варианты процедур предварительного и оперативного формирования агрегатов на основании полученной модели.

Последний раздел литературы, использованной в данной работе, относиться к специфическим вопросам организации многомерного анализа конкретных продуктов и технологий. Так как данная работа связана с сетевым аспектом функционирования систем многомерного анализа данных, то в первую очередь в качестве основного источника сведений о сетях служили ^ работы Олиферовых [20], в которой представлены общие вопросы, так илииначе связанные с сетями, а также [21] посвященная исключительно вопросам анализа и оптимизации локальных сетей. Вопросы рассмотрения передачи # реляционных данных в сетях на примере протокола фирмы Oracle SQL*Netизложены в [42], а специфические особенности сжатия данных, передаваемых по сети, в частности для Oracle 9i, описаны в [58] и [24]. Более подробно, вопросы, изложенные в указанных публикациях, рассмотрены в соответствующих разделах данной работы.

3.5 Структура диссертационной работыВ заключение данного раздела хотелось бы сказать пару слов о структуре данной работы. Работа состоит из 5 основных разделов. В данном разделе (раздел 3) рассмотрены основы организации систем многомерного анализа данных, определена с используемой в данной работе терминология, проведен обзор литературы, относящейся к области исследования, а также упомянуты нерешенные, но актуальные на сегодняшний день проблемы. ^ Разделы 4, 5 и 6 посвящены непосредственно разработке аналитическоймодели. Так раздел 4 посвящен основным вопросам многомерного анализа данных, необходимым для построения аналитической модели, но напрямую не относящимся к исследуемой области. Общие вопросы это: определение размеров хранилища данных и многомерной базы данных, вопросы агрегации данных и трафика. При этом в данном разделе рассматриваются как имеющиеся наработки специалистов в данной области, так и создаются собственные аналитические зависимости.

Раздел 5 посвящен различным вопросам загрузки данных. Помимо создания метод определения эффективного периода обновления данных на основании параметров системы и предъявляемых требований к актуальности данных и использования вычислительных ресурсов, в данном разделе приведено описания процессов загрузки данных, определения скоростей роста щ тех или иных объектов системы. Кроме того, в разделе 5 приведена собственнаяклассификация методов загрузки данных, а так же способов извлечения данныхих реляционных источников применяемых для пополнения многомерных баз данных.

Раздел 6 посвящен описанию методов сетевой нагрузки при обработке запросов пользователя, а так же рассмотрены различные аспекты обработки пользовательских запросов. В разделе рассмотрены методы снижения сетевой нагрузки при обращении к реляционным данным и эффективного распределения оперативных вычислений между сервером многомерной базы данных и рабочей станцией пользователя.

Раздел 7 целиком посвящен экспериментальной части данной работы. В нем помимо описания условий проведения и рассмотрения результатов различных экспериментов, имеющих отношения к тем или иным вопросам, рассматриваемым в данной работе, приведен ряд результатов имитационного моделирования. При этом для каждого эксперимента проводится сопоставление результатов с разработанной аналитической моделью.

3.6 ВыводыВ данном разделе:• были рассмотрены основные аспекты организации систем поддержки принятия решений, в общем, и систем многомерного анализа данных, в частности.• сделан обзор современного состояния рассматриваемой проблемы• приведено описание основных литературных источников, имеющихся на сегодняшний день• приведено краткое описание всей структуры диссертационной работы.

4 Общие вопросы систем многомерного анализаПрежде чем начать обсуждением вопросов, связанных построением модели функционирования систем многомерного анализа в с точки зрения создаваемой сетевой нагрузки необходимо определиться с рядом основных характеристик и их взаимосвязи. В первую очередь это размеры данных, как при реляционном хранении данных, так и при многомерном. Особое внимание в данном разделе уделено вопросам агрегации данных, так как в данной работе нам необходима однозначная аналитическая зависимость размера агрегированных данных, от размера детальных данных. И, конечно же, уделено внимание базовым аспектам передачи данных по сети. Все эти вопросы являются базовыми и необходимы для получения основных выводов данной работы.

Выражение (4.2) носит несколько абстрактный характер, так как на практике производители программных продуктов используют различные механизмы оптимизации, которые зачастую являются коммерческой тайной.

Однако в рамках данной работы нас больше интересует функционирование системы многомерного анализа данных в рамках сетевого окружения, а значит с точки зрения передачи данных по сети. В этих условиях, во-первых, нет необходимости учета метаданных и зарезервированного пространства, а во-вторых, в этом случае имеет место другой способ формирования результирующих наборов данных. Поэтому дальше в данной работе вместо термина объем будем использовать понятие размера данных.

Чтобы различать эти понятия, определим объем (V), как физически занимаемое пространство на жестком диске или любом другом носители тем или иным объектом. А под размером (С) будем пониматьt тVrel = H+Z hj+Zrjt i-i\(4.2)значение, вычисляемое на основе логических параметров объекта, таких как, количество записей таблице, количество измерений куба, размер поля данных и т.д. Другими словами под размером в данной работе будем понимать в некотором смысле «количество» данных.

Исходя из вышесказанного вместо выражения (4.2), определяющего объем реляционной таблицы в данной работе будет оперировать понятием размер реляционной таблицы, которое можно записать как:t т у=1 *=1Размеры данных, занимаемый многомерным представлением данных, в общем виде можно оценить как общее количество ячеек куба (произведение длин его ребер) умноженное на размер типа данных, так как все ячейки многомерного куба имеют один тип данных (для одного показателея). При этом не стоит забывать также про размеры самих измерений:" (п< max 1 " ( П' П, ^С cube %Jlik cubei 1 = 11 Hhlk+t*Tld,j(4.4)где v — количество показателей в многомерном кубе, п, - количество измерений, по которым индексируется i-ый показатель, djj - количество различных значений в j-ом измерении, tj- размер типа данных показателя, Hi — размер метаданных i-oro показателя, hy — размер метаданных j-oro измерения i-oro показателя. В данном случае рассматривается поликубическая модель данных, где каждый показатель индексируется своим собственным набором измерений. В случае гиперкубической модели данных наборы измерений будут совпадать и значения П| будут равны для всех показателей.

При этом не следует забывать и про размеры измерений. Конечно, в рамках всей многомерной базы данных размеры измерений являются незначительными, но, например, в рамках одной выборки отсутствие учета размера измерений может привести модель к неадекватному отображению действительности. Поэтому в выражении (4.4) hjk отображает метаданные посоответствующему измерению. А к метаданным для измерений в первую очередь относятся значения атрибутов членов измерения.

Как видно из выражения (4.4) основным фактором, влияющим на размер многомерной базы данных, является количество различных значений в измерении. Однако это выражение является несколько абстрактным, так как на практике переменные индексируются далеко не по всем существующим значениям измерений, поэтому для эффективного управлением памятью используют измерения двух типов: разреженные (sparse) и плотные (dense). Использование того или иного типа измерения непосредственно влияет на выражение в скобках. Различные производители серверов многомерных баз данных реализуют управление разреженными измерениями по-разному, однако принципы, заложенные в основу данного подхода, одни для всех. В [66] описан механизм формирования многомерной базы данных на основе понятия блока данных. Под блоком данных в Hyperion Essbase, понимают произведение числа членов плотных измерений. А размер базы данных в этом случае определяется, как произведение числа комбинаций элементов разреженных измерений на размер блока данных, то есть:(-sEssbase ^-JЫ\Г \п, nrs,E/k+zi/Ш,Ш*чU (4-5)где Sj — число разреженных измерений куба для i-oro показателя, Js>— число пересечении изYld ik элементов (максимально возможное числоэлементов разреженных измерений для i-oro показателя) для которых существуют данные, то есть значение показателя для комбинации из Sj имеет не пустое значение.

В данном случае используется подход, принятых в Hyperion Essbase, потому что данный продукт считается одном из первых коммерчески успешных реализаций OLAP серверов и он включает в себя все основные моменты организации многомерных баз данных.PC ссимпк-чяГОСУ, Г i / г; ми.ог -ivj\Аналогично определяется размер данных и в Oracle Express, но различие заключается в физическом представлении данных. Все разреженные измерения ф объединятся в одно единственное композитное (composite) измерение,содержащее комбинации членов разреженных измерений, для которых существуют данные. В Express вместо понятия блок существует понятие страница (page). Страницы заполняются последовательно на основании сначала значений плотных измерений, а потом разреженных. Поэтому важным является очередность измерений при определении показателей (более подробно см. в [73]). В дальнейшем, упоминая многомерный куб, будем иметь в виду описанные выше модели управления разреженными данными.

Учет влияния плотных и разреженных измерений на размер многомерной базы данных, в данной работе в первую очередь необходим для оценки роста многомерного куба при загрузке в него новых данных. Что же касается уровней иерархии, по которым агрегируются данные и количеству иерархий для отдельных измерений, то они никак не влияют на размер и, соответственно, • объем многомерного куба, так как представляют лишь логическоеобъединением членов измерений в уровни и уровней — в иерархии.

4.2 Модель агрегации данныхАгрегатами называют агрегированные по определенным условиям исходные значения показателей [35]. Обычно под агрегацией понимается любая процедура формирования меньшего количества значений (агрегатов) на основании большего количества исходных значений, однако, в системах многомерного анализа под агрегированием данных в подавляющем большинстве случаев подразумевается только суммирование значений показателей. Агрегирование является одним из основополагающих принципов положенных в основу минимизации времени отклика системы, являющегося ключевым требованием для систем многомерного анализа данных.

Очевидно, что максимальное число агрегатов определяется как разность между максимально возможным числом ячеек куба и максимально возможным числом ячеек детальных данных:a'-tldrtld,,, (4-8)/=1 1=1Следует отметить, что последний уровень иерархии всегда хранит детальные данные, а значит, не подлежит операции агрегирования.

Объединив (4.6), (4.7) и (4.8) получим общее значение степени агрегации:Фп п 1,-1ГШгП ЕЛ,,/=1 /=i /=1/=1(4.9)or =ппYldrllduiПод вычислительными затратами на выполнение агрегации некоторого множества значений показателей (агрегированных или исходных) до определенного результирующего множества агрегатов понимается количество элементарных операций суммирования, которые необходимо осуществить для получения результирующего множества [35]. Для суммирования множеств агрегатов по i-му измерению с j-ro на j-1 уровень необходимо для каждой комбинации из членов текущих уровней всех остальных п-1 измерений провести djj элементарных операций суммирования. В данной работе, чем меньше индекс измерения, тем более обобщенные данные он представляет. Таким образом, вычислительные затраты на выполнение агрегации вдоль одного измерения можно выразить следующим выражением:где laj — количество агрегированных уровней в i-ом измерении, dy — количество членов в i-ом измерении на j-ом уровне.

Оперативное агрегирование имеет место быть в случаях, когда а<1, то есть, когда предварительно рассчитаны не все агрегаты. В этом случае при обращении пользователя к не рассчитанному уровню агрегации, происходит оперативное вычисление агрегатов, которое вносит некоторую задержку в процесс отображения результатов. Значение задержки, вносимой оперативным расчетом агрегатов, можно рассчитать исходя из выражения вычислительных затрат на агрегацию вдоль одного измерения (Oaggi), а так же времени выполнения одной элементарной операции (tei):/,-/;[ пOaggi= Е dij* Y\dk j=1 ^ k=\\k*i(4.10)(4.11)В случае если имел место предварительный расчет агрегатов, то задержка будет равна нулю. Для того, чтобы вывести зависимость вычислительных затрат на агрегацию от степени агрегации, несколько модифицируем выражение (4.10). Согласно этому выражению процесс агрегации вдоль одного измерения графически можно представить следующим образом:Рис. 3 Агрегация вдоль одного измеренияТо есть в выражении (4.10) можно поменять местами знаки произведения и суммы:/апOaggi =Tidi,j* Y[dkj—\ k=\\k*J(4.12)А для всех измерений вычислительные затраты на агрегацию можно записать как разность объема всего многомерного куба и подмножества значений не затрагиваемых операцией агрегации:oagg=Y\drY\' г, >di ^Lj dij(4.13)i=i /=1Для того, чтобы получить зависимость вычислительных затрат от количества ячеек, подлежащих оперативной агрегации рассмотрим вариант, для перехода с одного уровня на другой. В этом случае вычислительные затраты будут определяться как произведение числа ячеек, подлежащих агрегации на отношение количества членов соответствующих уровней:1-fly djj-lО aeei. i Non(4.14)aggi,j J- у aggij jU ijВ общем же случае, для всего многомерного куба, выражение (4.14)можно записать как:п Г, J.

Указанные выше выражения правомерны только для случая, когда многомерный куба заполнен детальными данными на столько, чтобы все ячейки на верхних уровнях иерархий были заполнены. В противном случае тенденции роста агрегированных данных на основе детальных сильно зависят от характера распределения детальных данных по измерениям, количеству потомков в каждом узле и числу уровней иерархий. В [64] описаны и протестированы различные алгоритмы оценки объема многомерных кубов, однако они связаны либо с подсчетом вероятностей, либо с оценкой объема многомерного куба на основе выборки, что не совсем подходит для данной работы, так как нам необходима наглядная аналитическая зависимость.

Целью данной работы не является детальное изучение вопросов, связанных агрегацией кубов, поэтому постараемся выделить только общие тенденции данного процесса. Для этого будем использовать два понятия — кубоид, введенное в [46], и плотность данных [63].

В [46] под кубоидом, понимается подмножество членов измерений куба, содержащее агрегированные значения. В данной работе под кубоидом будем понимать набор ячеек, принадлежащих определенному набору {Ic1,lc2,.,lcn} уровней всех измерений, то есть и детальные данные тоже. Легко понять, что количество кубоидов многомерного куба равно произведению числа уровней всех измерений:А плотность данных кубоида соответственно определяется, как отношение числа заполненных ячеек, к максимально возможному числу ячеек кубоида:пN cuboid -п/, /=1cuboid(4.18)(4.19)Данное понятие, будет ключевым для наших рассуждений, так как постараемся вывести закономерность количества агрегатов, в зависимости от плотности детальных данных.

В общем случае количество агрегированных данных можно рассчитать как произведение плотности данных в каждом кубоиде на его «геометрический объем» (количество ячеек):Ncuholf^Nagg= Е p;s, (4.20)где значение -1 отвечает за исключение детальных данных из списка кубоидов, так как они не являются агрегированными данными, ру плотность данных в i-ом кубоиде, Si — количество ячеек в i-ом кубоиде (или его «геометрический объем»), которое определяется как:> je{Ic\Jc2,.Jcn)(4.21)/=1Выражение (4.21) определяет количество ячеек, принадлежащих кубоиду, лежащему на пересечении 1с1,1с2,.,1сп уровней многомерного куба.

Для окончательного вывода зависимости между плотностью детальных данных и количеством агрегатов необходимо вывести закономерность между pj и р. Как известно ([57]) агрегированные данные значительно плотнее, чем детальные, поэтому в качестве оператора перехода от pj к р можно использовать отношение количества ячеек кубоидов:В---SlclJc2,.Jcn (4.22)Р lcUcl,.Jcn ^detгде Pici,ic2,.,icn — плотность кубоида, определенная 1с1,1с2,.,1сп уровнямисоответствующих измерений, a Sid,^.icn — количество ячеек данного кубоида.

4.3 Особенности учета передачи данных по сетиСетевая нагрузка или трафик определяется как объем данных, передаваемый по сети в единицу времени:VT = f (4.25)Единица измерения трафика, используемая в данной работе, — байты в секунду. Исходя из [21] нас интересует полный трафик (УТ) передаваемый посети, а не только объемы данных возвращаемые серверами баз данных и другими источниками информации (С). Поэтому выражение (4.25) можно расширить, добавив в него не только размер непосредственно данных, но и размеры заголовков пакетов различных протоколов, участвующих при передаче данных. Так как данные, передаваемые по сети достаточно часто не помещаются в один пакет, то их приходится разбивать на несколько пакетов. Частный случай, при использовании одного протокола выглядит следующим образом:сСетевой протоколПакет №1Рис. 4 Разбиение данных по пакетамИсходя из рисунка 4 частный случай размера данных, передаваемых по сети, с учетом разбиения на пакеты, для одного прокола, можно представить как количество пакетов, помноженное на размер пакета:где V — объем «полезных данных», D —размер поля данных в данном протоколе, Н — размер заголовка пакета данного протокола, Р —размер пакета в данном протоколе (P=H+D). Однако на практике при передаче данных по сети используется не один протокол, а стек протоколов, поэтому выражение (4.26) в общем виде определяющее размер данных, передаваемых по сети, можно записать как:Где п — количество протоколов в стеке, а Р; и Н, — размер пакета и заголовка i-oro протокола соответственно.

Из выражения (4.27) общее выражение трафика можно определить как(4.26)(4.27)(4.28)Выражение (4.28) дает нам описание трафика, создаваемого данными,и ризвлекаемыми из источников информации. Произведение Вдальнейшем будем называть коэффициент сетевой избыточности (knet). Определить параметр t — время, затрачиваемое на передачу «полезных» данных (С) по сети, можно используя значения пропускной способности сети (р) как:/ = (4.29)Р-Те*Где тех — среднее значение трафика, существующего в сети в момент передачи необходимых данных. Так как значение существующего трафика в реальных системах непостоянно и непрерывно, то среднее значение за определенный период времени можно выразить как:■"о 1Рис. 5 Полезные данные в условиях загруженной сетиГде Т — время передачи данных, т(Т) — количество других данных переданных по сети за время Т. Таким образом, заменяя значение Т в (4.30) на искомое t из (4.29) можем определить значение необходимой пропускной способности сети с учетом ограничения на время передачи «полезных» данныхпо сети и существующего трафика: /=———=>t*р-т(1) = ут. В результатеполучаем:Р =(4.31)В выражении (4.31), значение t обусловлено ограничениями, накладываемыми на время ответа в конкретных системах. Так, для рассматриваемых в данной работе систем многомерного анализа данных, общее время ответа на запрос пользователя ограниченно 5 секундами. Имея сведения о времени выполнения других операций (извлечение данных из многомерной базы данных и реляционных источников, выполнение оперативных расчетов и т.д.) можно определить требуемую пропускную способность сети для запроса, возвращающего средний размер данных.

4.4 Производительность систем многомерного анализа данныхРассматривая различные вопросы, связанные с функционированием систем многомерного анализа данных никак нельзя обойти такое понятие, как производительность. Под производительностью в данном случае будем понимать размер данных, возвращаемый пользователю в единицу времени.

На самом деле, производительность любой системы является комплексным показателем, так как зависит и от пропускной способности сети, мощности сервера, выполняющего оперативную агрегацию, и от типа хранения данных (MOLAP, ROLAP, HOLAP). Оставив пока в стороне технологию HOLAP, выразим производительность через основные показатели, такие как степень агрегации и пропускная способность сети. Для этого необходимо получить зависимость производительности системы многомерного анализа, через общее время извлечения данных, которое определяется как время(4.32)tпередачи данных по сети (4.31), время, затраченное на оперативную агрегацию (4.11) и время извлечения данных из базы данных.

4.5 ВыводыВ данном разделе описаны основные вопросы систем многомерного анализа данных, которые необходимы для создания методов снижения сетевой нагрузки в OLAP системах. Среди этих вопросов:Определение размеров данных при реляционном и многомерном храненииПостроение модели агрегации данных, подходящей для способа описания многомерного анализа данных, используемого в данной работеРассмотрены особенности учета передачи данных по сетиДано описание понятия производительности систем многомерногоанализа данных5 Загрузка данныхС данного раздела начинается непосредственное рассмотрение вопросов, связанных с созданием методов снижения сетевой нагрузки в OLAP системах. В данном разделе будут рассмотрены различные способы извлечения и загрузки данных, применяемые в системах многомерного анализа данных, определены понятия скорость изменения данных и скорость роста многомерного куба, определено понятие и приведен критерий эффективной загрузки данных, а также построена методика определения эффективной частоты обновления данных.

5.1 Способы извлечения данныхКак уже было отмечено ранее, существует два основных типа загрузки данных — это первоначальная и инкрементальная. При этом, существенных различий между загрузкой данных в ХД или МБД не существует. Поэтому для общего случая загрузки данных в ХД или МБД в данной работе понимается загрузка данных в ХД, не уточняя способа хранения данных. Помимо этого, существует два основных класса различных способов извлечения данных из источников: полное и дифференцированное извлечение.

Полное извлечение происходит извлечении всех записей из источника данных и сопоставление их с имеющимися в хранилище данных. Согласно концепции ХД, описанной в [50], данные в ХД не подвергаются модификации, а только добавляются. Поэтому применение данного способа достаточно эффективно позволяет обнаружить изменившиеся данные и добавить их в ХД. Для этого достаточно хранить моментальный снимок состояния каждого источника данных на момент последней загрузки и сравнивать текущее состояние источника данных с этим моментальным снимком для выявления изменений.ф Полное извлечение является достаточно простым с точки зренияорганизации процедуры загрузки данных и не требует никаких внесенийизменений в исходный код существующих информационных систем. Однако данный способ имеет два недостатка. Во-первых, необходимо загрузить все данные из таблицы, находящейся в исходной OLTP системе, в область подготовки данных, что предполагает достаточно большую нагрузку на сеть. Во-вторых, достаточно большая вычислительная нагрузка ложиться на сервер баз данных, на котором функционирует ХД, так как необходимо выполнять запросы вида:SELECT списокполей FROM исходнаятаблща MINUSSELECT списокполей FROM целеваятаблицаЧто требует значительных затрат памяти и вычислительных мощностей. Несмотря на указанные недостатки данный подход, зачастую применяется при формировании таблиц размерности, так как размеры данных в этих таблицах несопоставимо малы, по сравнению с размерами, хранящимися в таблицах фактов или в тех случаях, когда нет другой возможности выделить* изменившиеся данные или изменить существующие OLTP системы.

Дифференцированное извлечение заключается в извлечении только записей изменившихся с момента последней загрузки данных. Подобные операции осуществляются на основе метки, показывающей, что данная запись претерпела изменения. Это может быть поле, содержащее не пустое значение для обновленных записей, или временную метку. Так или иначе, данная метка обновляется, например, с помощью специальных триггеров OLTP системы, при каждом обращении к записи с целью ее изменения. Соответственно, при извлечении необходимых данных в запрос добавляется условие WHERE, говорящее о том, что необходимо извлекать данные, для которых значение метки имеет соответствующее значение.

Подобное обнаружение новых данных довольно часто имеет место при загрузке таблиц фактов по двум причинам. Так как объем данных,* используемых для формирования показателей, зачастую на столько велик, посравнению с данными, используемыми для формирования измерений, что при инкрементальной загрузке извлечение всех записей, имеющих отношение к формированию таблицы фактов, скорей всего приведет к неработоспособности системы из-за перегрузки сети. Недостатком же данного метода является необходимость в поддержке формирования метки в OLTP системах, что не всегда возможно.

Учитывая указанные выше два подхода к извлечению записей из источниках данных, значение размера обновленных данных можно определить как:Г =Yrfull+Yrmod С5.ПV-- inc v-' reli ^ reli v ' '/=1 /=1Где f — количество таблиц в источнике данных, используемых, для обновления полным извлечением, m — количество таблиц в источнике данных, используемых для обновления дифференциальным способом. A и (J™^размер данных в i-ой таблице используемой для обновления полным и дифференциальным способами соответственно. Их значения определяются исходя из выражения (4.3).

Первоначальная загрузка осуществляется только с помощью полного извлечения данных, так как в ХД или МБД на момент загрузки нет никаких записей, в то время как при инкрементальной загрузке используются как дифференцированное извлечение, так и полное, в случаях, когда дифференцированное извлечение невозможно из-за особенностей источника данных (например, текстовые файлы).

5.2 Основные способы загрузки данныхТак как в подавляющем большинстве систем многомерного анализа основным источником данных является реляционная база данных, то в данной работе далее рассматривается только данный тип источников. На этапе загрузки данных в МБД или ХД наибольшее влияние на размер данных, передаваемых по сети, оказывает SQL запрос, созданный разработчикомсистемы, а также выбранный тип извлечения данных (см. раздел 5.1). Как ужебыло отмечено ранее, таблица фактов обычно загружается с помощьюдифференцированного извлечения данных, когда из таблицы фактовизвлекаются только новые данные, а измерения — с помощью полного.

Существует несколько типов загрузки данных в измерение, которые побольшому счету отличаются только количеством извлекаемых полей и записей.

Из теории реляционных баз данных известно, что результат любого SQLзапроса, по своей сути является точно такой реляционной таблицей и,соответственно, ее размер определяется согласно выражению (4.3), как сумма,размеров, занимаемых, каждым полем таблицы, для каждой записи. И так, типызапросов, для загрузки измерений:Первый тип, когда все данные, необходимые для формированияизмерения извлекаются единым запросом, который содержит число записейравное числу членов измерения на последнем уровне иерархии (уровеньдетальных данных). Каждая запись при этом содержит число полей равноепроизведению числа уровней всех измерений на число атрибутов плюс однополе для идентификатора члена измерения. Обычно атрибутом является меткачлена измерения. Такой способ извлечения присущ измерениям сосбалансированной иерархией. Схематично данный вид загрузки представлен нарисунке 7:поля в рамках одного уровня id метка2311199 23 ноября 111999 ноябрь 1999 1999 год2511199 25 ноября 111999 ноябрь 1999 1999 год1512199 15 декабря 121999 декабрь 1999 1999 год2012199 20 декабря 121999 декабрь 1999 1999 год0601200 06 января 012000 январь 2000 2000 год2401200 23 января 012000 январь 2000 2000 год3(del)2уровниРис. 7 Загрузка первым способомРазмер данных, передаваемых по сети при извлечении данного типа, можно рассчитать по формуле:Пи I(аCextl fid+ Иги,*а+к)i=\j=l\ к=1(5.2)где пц — число членов измерения на последнем уровне иерархий (случае нескольких иерархий первый и последний уровни совпадают для всех иерархий), 1 — число уровней измерения, а — число атрибутов члена измерения, г^а+к) — размер типа данных поля i-ой записи поля с индексом j*a+k, r;d — размер типа данных идентификатора члена измерения. В общем случае каждый уровень измерения может содержат различное число атрибутов, однако зачастую набор атрибутов в рамках одного измерения одинаков для всех членов. Поэтому выражение (5.2) можно записать в более упрощенной формеCa,rnMc+1) (5-3)где ? средний размер поля таблицы.

Данный способ передачи данных является избыточным, так как для каждого члена уровня детальных данных передается все иерархии измерений со всеми атрибутами. Размер избыточных данных в этом случае зависит от распределения членов измерений по уровням иерархий.

Третий тип загрузки данных используется в случае необходимости заполнения так называемых parent-child измерений известных также как несбалансированные иерархий (ragged hierarchy) [35]. Суть несбалансированных иерархий заключается в том, что количество уровней в различных ветках дерева заранее не определено, и зависит целиком от характера исходных данных. Подобные измерения загружаются одним SQL запросом для каждой иерархии измерения (рисунок 9), в остальном данный тип загрузки аналогичен второму типу загрузки.idметкассылка на родителя1999 1999 год null2000 2000 год null111999 ноябрь 1999121999 декабрь 1999012000 январь 20002311199 23 ноября 1119992511199 25 ноября 1119991512199 15 декабря 1219992012199 20 декабря 1219990601200 06 января 0120002401200 23 января 0120003 (det)Рис. 9 Загрузка третьим способомРазмер данных, передаваемый при данном типе загрузки, определяется так же как и для второго типа загрузки данных выражением (5.4).

5.3 Скорость изменения данныхПомимо способа обновления данных при инкрементальной загрузке другим немаловажным параметром данного процесса является частота обновления данных в ХД (v). Именно изменение данного параметра определяет как актуальность хранимых данных, так и сетевую нагрузку.

Как видно из выражения (5.12) характер размера данных, передаваемых по сети, зависит от двух параметров — частоты обновления и времени, прошедшего с момента Ю, причем от частоты обновления зависимостьллинейная, а от времени — t. Для наглядности изобразим такую зависимость в трехмерном пространстве:*(байт/сек.)СРис. 10 Зависимость объема загружаемых данных от частоты обновления и времениЕсли аналогичным образом проинтегрировать выражение (5.10), что бы получить значение объема данных, передаваемого по сети за определенный период времени при дифференциальном способе извлечении данных, то получим:Как видно из выражения (5.15), размер данных при дифференциальном извлечении не зависит от частоты обновления куба. Однако это не значит, что частота обновления никак не сказывается на всем процессе обновления данных, так как помимо извлечения и передачи данных по сети немаловажную роль в данном процессе играет агрегация данные в процессе загрузки, особенно в случае использования полной агрегации данных. Прежде чем окончательно получить выражения определяющие зависимость времени обновления куба от частоты загрузки и наоборот, необходимо определиться со скоростью роста многомерного куба.

Несколько другой характер носит взаимосвязь скорости изменения данных в источниках информации с увеличением размера многомерного хранилища данных. Здесь надо учитывать характер использования плотных и разреженных измерений. Этот механизм упоминался, при выводе выражения (4.5), так что не будем заострять на нем внимание. В данном случае нас(5.15)интересует скорость роста многомерного куба, которую, учитывая двойственный характер его измерений, можно разделить на две части. Первая часть это рост так называемых блоков данных, которые определяются исходя из числа членов плотных измерений и, соответственно, из количества пересечений разреженных измерений, для которых существуют данные, то есть не пустые ячейки.

Также в отличие от реляционного представления, для которого в данной работе скорость роста измеряется в количестве записей, модифицированных в единицу времени, для многомерного представления будем измерять в увеличении количества ячеек в единицу времени. При известном размере типа данных показателя многомерного куба, осуществить переход от ячейки к байтам элементарно.

Для наглядности изобразим процесс роста многомерного куба для случая двух плотных измерений и одного показателя, а количество сочетаний разреженных измерений представим на рисунке, как третье измерение:На рисунке 11 заштрихованная область отображает блок данных или объединение всех плотных измерений. Vdense — скорость роста по плотным измерениям, a Vcomp — соответственно, скорость роста по разреженным измерениям. Очевидно, что скорость роста многомерного куба для одного показателя является многомерным вектором, который можно описать как:где vi.vns — скорость роста таблиц размерностей (появление новых членов), соответствующих плотным измерениям, vcomp — скорость роста пересечений разреженных измерений, соответствующая росту таблицы фактовРис. 11 Скорость роста многомерного куба— , сотр.(5.16)в плане появления пересечений по новым комбинациям разреженных измерений, s — число разреженных измерений.

Однако вектор не дает нам главного — числа ячеек, на которое увеличивается куб. Хотя этот показатель достаточно легко рассчитать. Для наглядности изобразим рассмотренную выше модель трехмерного куба с двумя плотными измерениями.

Рис. 12 Рост многомерного кубаКак видно из рисунка 12 при увеличении одного измерения на v, членов,n-s,sparseразмер куба увеличивается на X\djячеек данных. С другой стороныМ ;j*iколичество новых ячеек можно определить как разницу между новым размером куба и старым. Таким образом, общее значение скорости роста многомерного куба можно определить как:vfflfe= ГШу + vJ- Yldj (5.17)Как видно, скорость роста многомерного куба напрямую зависит от его размеров, точнее, от количества членов плотных измерений. Поэтому рекомендуется в первую очередь выбирать для плотных измерений медленно меняющиеся измерения [18].

Отмеченная выше скорость роста многомерного куба относилась только к детальным данным. Однако для случая разреженных измерений для определения значения vcomp необходимо еще учитывать и скорость роста за счет агрегации. Как определено в выражении (4.24) вычисление точного числа ячеек агрегации определяется как:/ » Nп\+1N agg'/=1Ud,Mе s,Icl,lc2,.jcn/(5.18)Для получения числа ячеек относящихся только к разреженным измерениям (так как плотные измерения уже включены в куб) из Nagg необходимо вычесть кубоиды, относящиеся к плотным измерениям.yidena Т1 sparse^NZT-Tldu,' I S,'/=1 /'=1П d,S П d,\-гр(5.19)б S lc\Jci.Jcnгде ndense — число плотных измерений куба, nsparse — число разреженных измерений куба. Полученное значение необходимо прибавить к составляющей усотр вект0ра скорости роста многомерного куба.

5.4 Определение частоты обновления данныхТак как данная работа больше ориентирована на системы многомерного анализа данных, то ХД рассматривается, как некоторый промежуточный элемент между множеством источников данных и OLAP сервером, который хранит только детальные данные. При этом вопросы консолидации данных от различных источников выходят за рамки данной работы. Поэтому рассмотрение вопросов определения частоты обновления относится в первую очередь к серверу МБД.

Наиболее длительная фаза обновления данных заключатся выполнении предварительного расчета обобщенных показателей. Поэтому в первую очередь необходимо рассчитать время выполнения операции агрегирования. Слишком маленький интервал обновления может иметь свои негативные последствия, так как необходимо помнить, что после того, как данные загружены, необходимо пересчитать хранимые значения агрегатов, что обычно является достаточно длительной операцией, обычно затрагивающей сканирование всех детальных данных, хранимых в МБД. Разумеется, интервал обновления не должен быть меньше или равен времени, необходимому для выполнения агрегации. Впротивном случае север МБД будет занят только тем, что будет обновлять данные.

В случае инкрементальной агрегации, частота обновления данных не зависит от скорости изменения данных и единственное условие, необходимое, для выполнения процесса обновления данных, чтобы скорость изменения данных не превышала «производительность» процесса загрузки:1 1V <=> V <v*p v * JV ext V*Wagg1 1 1■ +-+ ■p wext waggV <1 1 1- +-+ (5.28)P W^ Wagg5.5 Эффективная загрузка данныхВыражения (5.26) и (5.27) позволяют определить максимально возможную частоту обновления данных, для случая полной агрегации, то есть частоту данных, при которой система многомерного анализа данных только и занимается тем, что обновляет свои данные. Для случая инкрементальнойагрегации такой подход вообще не позволяет определить максимальную частоту агрегации, потому что ее просто нет.

Очевидно, что такой подход не всегда является эффективным. Возникает вопрос, как определить эффективность процесса загрузки данных. Ответ на этот вопрос заключается в самом предназначении процесса загрузки данных — обновление данных, то есть согласование внутренних данных системы многомерного анализа, с внешними данными из источников. При этом источники данных, всегда содержат актуальные данные, относительно системы многомерного анализа (относительно реального мира эти данные тоже могут быть устаревшими, но данный вопрос выходит за рамки данной работы). Таким образом, эффективным, является процесс загрузки, обеспечивающий определенную степень актуальности внутренних данных системы многомерного анализа.

Наиболее сложный вопрос заключается в определении именно количественного выражения степени актуальности данных. Так как в системе многомерного анализа данных широко используется предварительных расчет агрегатов, то изменение значения одной ячейки детальных данных влияет на множество ячеек многомерного куба, стоящих выше по иерархии во всех измерениях, по которым агрегируется данная ячейка. Поэтому простое сравнение количества загруженных ячеек с общим количеством ячеек многомерного куба не подходит, так как каждая загруженная ячейка детальныхданных меняет ^ilrl ) ячеек> гДе п — количество измерений многомерного/=1куба данных, a lj — количество уровней i-oro измерения подлежащих предварительной агрегации.

В данной работе необходимо выразить значение степени актуальности через такую характеристику источника данных, как скорость изменения (v). Так как каждая новая ячейка изменяет значения всех вышестоящих ячеек на некоторую величину, то, при загрузки двух и более ячеек многомерного кубаимеющих одного предка, необходимо учитывать влияние каждой новой ячейки данных на все вышестоящие. Исходя из этого, значение степени актуальности данных многомерного куба можно определить как отношение всех измененных ячеек, к общему числу ячеек многомерного куба:1+£ЫV =/. *Сcube Ф^ cubeгде с — размер типа данных ячейки, a N|0ad — суммарное количество ячеек детальных данных, загруженных из ХД, которое, исходя из выражения (5.9), определяется какОтсюда, эффективная частота обновления исходя из требуемой степени актуальности данных, определяется как:l + tf/r1)] (5-31)ч /=1 )Следует отметить, что степень актуальности является единственной характеристикой, позволяющей определить эффективную частоту обновления данных для случая инкрементальной агрегации. Для всех остальных условий частота обновления данных при инкрементальной агрегации не зависит от скорости изменения данных.

В случае, когда v((3)>v(cp), при v(P)<vmax и v(cp)<vmax, эффективное обновление невозможно, так как в этом случае возможно только либо избыточное, либо неэффективное обновление. Подобный случай изображен на рисунке 14Рис. 14 Отсутствие эффективного обновленияВ этом случае требуется увеличение вычислительных ресурсов. Так, для условий, представленных на рисунке 14, требуется увеличение производительности сервера многомерной базы данных, потому что увеличение пропускной способности сети привет к уменьшению значения v(P). Так как влияние пропускной способности сети, на процесс обновления данных носит следующий характер. Пропускная способность сети влияет на максимально возможную частоту обновления (vmax) и на частоту обновления, зависящую от степени полезной нагрузки v(P). Зависимости этих частот обновления от пропускной способности сети приведены на рисунке 15:Рис. 15 Частота обновления от скорости изменения данных и пропускной способности сетиКак видно из рисунка 15 с ростом пропускной способности сети увеличивается частота полезной нагрузки, так как время передачи данных по сети уменьшается, а значит, увеличивается и соотношение времени выполнения агрегации данных и передачи их по сети, что в свою очередь ведет к уменьшению частоты обновления данных. Максимальная частота обновления наоборот увеличивается, вследствие уменьшения времени передачи данных по сети.

При определении частоты обновления многомерного куба необходимо еще учитывать, что в процессе загрузки новых данных увеличивает размер куба, а значит и время необходимое на выполнение агрегации (Определение скорости роста многомерного куба было рассмотрено в разделе 5.3 данной работы). Поэтому частоту обновления данных необходимо выбирать с некоторым запасом, используя в качестве параметров прогнозируемый размер многомерного куба. При этом сам OLAP куб обычно не хранит в себе все имеющиеся в ХД детальные данные, а только данные, например за последние 5 лет. Таким образом, размер многомерного куба изменяется в определенных пределах, что позволяет достаточно точно определить эффективную частоту обновления.

5.6 ВыводыВ данном разделе были рассмотрены вопросы, касающиеся первой части исследуемой проблемы, а именно вопросы связанные, со снижением сетевой нагрузки при загрузке данных. В первую очередь это собственно метод определения эффективной частоты обновления данных, учитывающий различные характеристики, такие как степень актуальности данных, степень полезной нагрузки, скорость изменения данных, параметры многомерных структур данных. Помимо этого в данном разделе приведена классификация различных способов загрузки и извлечения данных. Рассмотрены преимущества и недостатки полного и дифференцированного извлечения данных. Для каждого способа загрузки данных получены аналитически зависимости, позволяющие определить размер данных, передаваемых по сети, в зависимости от количества источников данных их структуры, а также, получены выражения позволяющие определить избыточность того или иного способа загрузки. Введено такое понятие, как скорость измерения данных в источнике, а также определена зависимость размера передаваемых данных от скорости изменения источника и частоты обновления для различных способов загрузки данных. Помимо этого, раскрыто понятие скорости роста многомерного куба, которое в виду особенностей многомерного хранения данных зависит от большого числа параметров.

6 Обработка пользовательских запросовДанный раздел посвящен рассмотрению второй части исследуемой области, а именно анализу процессов приводящих к передаче данных по сети при обработке пользовательских запросов. Данный процесс помимо рассмотренных ранее вопросов агрегации данных, учета передачи данных по сети, извлечения данных из реляционный источников, предварительного расчета показателей и т.д. также зависит от способа хранения детальных данных, охватывает вопросы многопользовательского режима работы, а также вычислений на стороне клиента. Именно эти вопросы в первую очередь рассмотрены в данном разделе.

6.1 Модель обращения к реляционным даннымПосле того, как данные загружены в систему многомерного анализа данных, МБД становиться актуальной, и содержит все, необходимые для анализа данные. Однако в целях уменьшения общего объема МБД иногда часть или все данные, оставляют в реляционном ХД. Обращение к реляционному ХД, в случае запроса детальных данных, остается прозрачным для пользователя и полностью реализуется сервером МБД. Не вдаваясь в подробности реализации данного подхода и вопросов, связанных с производительностью такой архитектуры, отметим, что он имеет один недостаток, связанный с тем, что при обращении к детальным данным на сеть приходиться двойная нагрузка, так как сначала данные извлекаются сервером многомерной базы данных из ХД, а уже затем передаются пользователю. Поэтому в данном подходе к хранению многомерных данных можно говорить о таком понятии как степень избыточности сетевой нагрузки при работе пользователя, которую определим по аналогии с предыдущими степенями различных характеристик как отношение размера данных, передаваемых от одного источника данных к другому до момента передачи их пользовательскому приложению, к общему размеру данных, передаваемых по сети:D =-OAet--(6.1)-fVner v '^ det ^ aggДалее по тексту, используется термин степень избыточности сетевой нагрузки, как степень избыточности HOLAP, так как с точки зрения степени избыточности хранения HOLAP является оптимальным решением, обеспечивая при этом хранение, как детальных данных, так и агрегированных.

Другим аспектом функционирования HOLAP архитектуры является вероятность обращения к детальным данным (П), от которого напрямую зависит степень избыточности HOLAP. Следует отметить, что под обращением к детальным данным следует понимать не только непосредственное отображение детальных данных в клиентском приложении, но и обращение к детальным данным для оперативного расчета агрегированных значений. Чем меньше эта вероятность, тем меньше задержка на запрос пользователя. Для начала выведем общее выражение, показывающее время ответа на запрос пользователя. Данное время состоит из трех составляющих text — времени извлечения данных из источника (4.34), tagg — время выполнения оперативной агрегации (4.11), tnet — время передачи данных по сети (4.31), причем составляющие text и tnet в свою очередь состоят из двух частей, относящихся к реляционному и многомерному источникам:t =t +f +fЬ user * ext fr agg fr netf =[n *f + fdb + n f + fmdb )+ Г) *f +

7.6 Выводы

В данном разделе были описаны условия проведения и результаты экспериментов, проводимых с целью обоснования адекватности разработанной аналитической модели функционирования систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки. Эксперименты, проводимые на реальном оборудовании охватывают вопросы обработки пользовательских запросов и извлечение данных из гибридной архитектуры, оценку влияния плотных измерений на объем МБД, проверку модели предварительного расчета количества ячеек агрегированных данных, а также различные способы извлечения и загрузки данных.

Помимо этого в виду большой сложности часть экспериментов была проведена с помощью средств имитационного моделирования на языке GPSS. В рамках этих экспериментов была построена простая модель гибридной OLAP системы, модель HOLAP системы в многопользовательском режиме и модель многопользовательского режима при децентрализованных вычислениях.

Все эксперименты показали соответствие разработанной аналитической модели реальным и имитируемым системам.

8 Заключение

Представленная работа посвящена созданию методов снижения сетевой нагрузки в OLAP системах. Для разработки данных методов была создана аналитическая модель, описывающая процесс функционирования систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки.

В разделе, посвященном вопросам загрузки данных, рассматриваются различные типы загрузок данных, способы извлечения данных из источников, а так же влияние таких характеристик, как частота обновления и скорость изменения данных, на объемы, передаваемых по сети данных. Вопросы обработки пользовательских запросов, влияющие на объем передаваемых по сети данных, охватывают такие аспекты, как обращение к реляционным данным и распределение оперативных расчеты между OLAP сервером и рабочей станцией пользователя. В построенной модели, источники данных и пользовательские приложения, рассматриваются, как внешние по отношению к системе многомерного анализа, и уменьшение сетевой нагрузки достигается за счет изменения внутренних параметров системы.

Помимо основных вопросов, непосредственно относящихся к функционированию системы многомерного анализа данных с точки зрения создаваемой сетевой нагрузки, в разработанной модели описан ряд вопросов, относящихся к общим аспектам организации систем многомерного анализа данных. В первую очередь это вопросы, связанные с агрегацией данных, так как данный процесс является одним из ключевых аспектов многомерного анализа данных. Получены аналитические закономерности, позволяющие достаточно точно определить зависимость числа заполненных ячеек агрегированных данных от числа заполненных ячеек детальных данных.

Что же касается методов снижения сетевой нагрузи OLAP систем, то разработаны методы:

• определения эффективной частоты обновления данных,

• распределения оперативных вычислений

• оценки и управления избыточной сетевой нагрузкой при обращении к реляционным данным Метод определения эффективной частоты обновления данных, относится к процессу загрузки данных в МБД. Под эффективной частотой обновления данных понимается частота, позволяющая поддерживать необходимую степень актуальности данных, не приводить к перегрузке системы и обеспечивать равномерное распределение нагрузки по различным частям системы. Метод учитывает и случай, когда эффективная частота обновления данных отсутствует. При этом достижение эффективной частоты обновления данных возможно только за счет увеличения вычислительных ресурсов системы. Помимо этого, метод определения эффективной частоты обновления позволяет, оценить время простоя системы и, наоборот, определить необходимую частоту обновления для систем, работающих в режимах близких к 24Y7.

Последние два метода, представленные в работе относятся к процессу обработки запросов пользователя. Метод оценки и управления избыточной * сетевой нагрузкой при обращении к реляционным данным, базируется на гибридной архитектуре OLAP системы, так как данная архитектура является обобщающей для ROLAP и MOLAP архитектур, с точки зрения обращения к детальным данным. Несмотря на то, что любое обращение к реляционным данным является избыточным, используя полученные закономерности, можно снизить избыточную нагрузку на сеть и повысить общую производительность существующей HOLAP системы за счет изменения структуры данных.

Метод распределения оперативных вычислений, между сервером многомерной базы данных и рабочей станцией пользователя позволяет определить эффективную степень распределения оперативных вычислений и изменить структуру МБД в соответствии с полученным значением, для изменения степени децентрализованности вычислений. Также данный метод позволяет повысить эффективность использования вычислительных ресурсов за ф счет рационального распределения оперативных вычислений между сервером

МБД и рабочей станцией пользователя и уменьшить время ответа на запрос, в результате эффективного использования вычислительных ресурсов. Отдельно следует отметить, что объединение модели распределенных вычислений с моделью обращения к реляционным данным дает полную картину функционирования систем многомерного анализа данных при обработке пользовательских запросов.

Основные полученные аналитические зависимости проверены экспериментально либо с помощью реальных OLAP серверов, либо с помощью системы имитационного моделирования, в тех случаях, когда проведение эксперимента затруднено по тем или иным причинам.

Следует отметить, что область многомерного анализа данных является относительно молодой, по сравнению, например, с реляционными базами данных. Поэтому основная масса исследований в первую очередь касается вопросов связанных с проектированием многомерных баз данных и созданию формальных описаний процесса многомерного анализа данных. Значительно меньше работ посвящено вопросам агрегации данных, производительностью вычисления агрегатов и оценки объема многомерных баз данных. Что же касается вопросов сетевой нагрузки в системах анализа данных, то практически все авторы упоминаю о важности данного аспекта в общей картине анализа данных, но никаких конкретных зависимостей не приводят. Поэтому приведенная в данной работе модель функционирования систем многомерного анализа данных с точки зрения создаваемой сетевой нагрузки и разработанные на ее основе, методы снижения сетевой нагрузки должны восполнить этот пробел.

1. Андерсон К.,Минаси М., Локальные сети: Полное руководство / Пер. с англ. под ред. Д.М. Шевель, — СПб: ВЕК+, Энтроп, КОРОНА принт, 1999. — 624 с.

2. Архипенков С.Я., Голубев Д.В., Максименко О.Б., Хранилища данных. От концепции до внедрения / Под общ. ред. С.Я Архиипенкова, — М: Диалог МИФИ, 2002. — 528 с.

3. Барсегян А.А., Куприянов М.С., Степаненко В.В., Методы и модели анализа данных: OLAP и Data Mining, — СПб: BHV, 2004 . — 336 с.

4. Бертсекас Д.,Галлагер Р., Сети передачи данных / Пер. с англ. под ред.Б.С.Цыбанова, — М: Мир, 1989. — 544 с.

5. Блэк Ю., Сети ЭВМ: Протоколы, стандарты, интерфейсы, — М:Мир, 1990, — 506 с.

6. Боев В. Д., Моделирование систем. Инструментальные средства GPSS World, — СПб: BHV, 2004. — 368 с.

7. Веймаер Р., Сотелл Р., Освой самостоятельно Microsoft SQL Server 2000 за 21 день, — СПб: Вильяме, 2001. — 704 с.

8. Воеводин В.В., Воеводин Вл.В., Параллельные вычисления, — СПб: BHV, 2002. — 608 с.

9. Дейт К. Дж., Введение в системы баз данных, — СПб: Вильяме, 2005. — 1328 с.

10. Дэвис Д., Барбер Д., Прайс У., Вычислительные сети и сетевые протоколы, — М: Мир, 1982. — 562 с.

11. Золотов С., Протоколы Internet / Под ред. А. Кутузова, — СПб: BHV, 1998. —304 с.

12. Казаков С.И., Основы сетевых технологий, — М: Микроинформ,1995. — 160 с.

13. Кайт Т., Oracle для профессионалов. Кн. 1: Архитектура и основные особенности, — СПб: ДиаСофт, 2004. — 662 с.

14. Кайт Т., Oracle для профессионалов. Кн.2. Расширение возможностей и защита, —СПб: ДиаСофт, 2004. — 848 с. f 15] Кудрявцев Е. М., GPSS World. Основы имитационногомоделирования различных систем, — М: ДМК Пресс, 2003. — 320 с.

15. Лисянский К.Б., Архитектурные решения и моделирование данных для хранилищ и витрин данных, — М: Открытые системы, №3, 2002. — с. 5-14

16. Луни К., Терьо М., Oracle 9i. Настольная книга администратора, — М: Лори, 2004. — 766 с.

17. Людке Дж., Медленно меняющиеся размерности, — Loveland, СО: SQL Server Magazine, №2, 2000. — с. 26-30

18. Найк Д. Стандарты и протоколы Интернета, — М: Русская редакция; Channel Trading Ltd., 1999. — 384 с.

19. Олифер Н.А., Олифер В.Г., Компьютерные сети. Принципы, технологии, протоколы, — СПб: Питер, 2000. — 672 с.

20. Олифер Н.А., Олифер В.Г., Средства анализа и оптимизации # локальных сетей Электронный ресурс] — М: Центр информационныхтехнологий — Режим доступа http://www.citforum.ru — 1998.

21. Пятибратов А.П., Вычислительные системы, сети и телекоммуникации, — М:ФИС, 2004. — 512 с.

22. Советов Б. Я., Яковлев С. А., Моделирование систем, — М: Высшая школа, 2001. — 343 с.

23. Соколов А., Сусойкин В., Сжатие таблиц в СУБД Oracle9i Release 2: анализ эффективности, — NY: Oracle Magazine RE №2-3, 2004. — 21 с.

24. Спирли Э., Корпоративные хранилища данных. Планирование, разработка и реализация, — СПб: Вильяме, 2001. — 400 с.

25. Спортак М., Паппас Ф., Компьютерные сети и сетевые технологии, — Киев : ТИД ДС, 2002. — 736 с.

26. Столингс В., Современные компьютерные сети, — СПб: щ Издательство «Питер», 2003 г. — 784 с.

27. Таненбаум Э., Компьютерные сети, — СПб: Издательство «Питер», 2003. —992 с.

28. Тимоти П., Освой самостоятельно TCP/IP: Руководство для самостоятельного обучения, —М: БИНОМ, 1997. — 448 с.

29. Томашевский В., Жданова Е., Имитационное моделирование в среде GPSS, — М: Бестселлер, 2003. — 416 с.

30. Уинзор Дж., Solaris. Руководство системного администратора, — СПб: Питер, 2003. — 448 с.

31. Уоттерс П., Solaris 8. Руководство администратора, — М: Символ-Плюс, 2003. —336 с.

32. Хоббс JL, Oracle9iR2. Разработка и эксплуатация хранилищ баз данных, — Минск :Кудиц-Образ, 2004. — 592 с.

33. Хоторн Р., Разработка баз данных Microsoft SQL Server 2000 на примерах, — СПб: Вильяме, 2001. — 464 стр.

34. Хрусталёв Е.М., Агрегация данных в OLAP-кубах // по материалам магистерской диссертации «Адаптивная процедура оптимизации параметров хранения OLAP куба» Электронный ресурс] — М: Interface ldt. — Режим доступа http ://www. interface ,ru — 2000.

35. Шеннон P. Дж., Имитационное моделирование систем искусство и наука, — М: Мир, 1978 г. — 418 с.

36. Шпеник М., Следж О., Руководство администратора баз данных Microsoft SQL Server, — СПб: Вильяме, 2000. — 928 с.

37. Шрайбер Т. Дж., Моделирование на GPSS, — М: Машиностроение, 1980 г. —592 с.

38. Щербо В.К., Киреичев В.М., Самойленко С.И., Стандарты по локальным вычислительным сетям: Справочник, — М: Радио и связь 1990 — 304 с.

39. Agrawal R., Gupta A., Sarawagi S., Modeling multidimension database // Proceedings of the 13th International Conference on Data Engineering, — NY: IEEE1. Press, 1997. — c. 232-243

40. Baralis E., Paraboschi S., Teniente E., Materialized view selection in a multi-dimensional datacube // Proceedings of 23rd International Conference on Very Large Data Bases, — Athens: VLDB, 1997. — c. 156-165

41. Bulumulle G., SQL*Net Performance Tuning Using Underlying Network Protocols Электронный ресурс] — Orlando, FL: Oracle corp. — Режим доступа http://www.fors.com —2003.

42. Cabibbo L., Torlone R., A Logical Approach to Multidimensional Databases // Proceedings of the 6th International Conference on Extending Database Technology: Advances in Database Technology, — London, UK: Springer-Verlag, 1998. —c. 183-197

43. Codd E.F., Codd S.B., Salley C.T., Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate Электронный ресурс] — E.F.Coddф & Associates, — Режим доступа http://www.arborsoft.com — 1993.

44. Codd E.F., A relational model for large shared data banks // Communications of the ACM, — NY: ACM Press, т. 26, №1, 1983. —с. 64-69

45. Feng Y., Agrawal D., Range CUBE: Efficient Cube Computation by Exploiting Data Correlation // 20th International Conference on Data Engineering, — Boston: IEEE Computer Society, 2003. — c. 658-671

46. Gray J., Bosworth A., Layman A., Data Cube: A Relational Aggregation Operator. Generalizing Group-By, Cross-Tab, and Sub-Totals // Proceedings of 12th International Conference on Data Engineering, — New Orleans: IEEE Computer Societ, 1996. —c. 152-159

47. Harinarayan V., Rajaman A., Ullman J. D., Implementing Data Cubes Efficiently // Prodeedings of the 1996 ACM SIGMOD International Conference on Management of Data SIGMOD, — NY: ACM Press, т. 25, No. 2, 1996. — c. 205216.

48. Inmon W.H., Building The Data Warehouse, — NY: John Wiley & Sons,2002. — 426 c.

49. Kimball R., The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses, — NY: John Wiley & Sons, 2002. — 445 c.

50. Kiviniemi J., Wolski A., Lazy Aggregates for Real-Time OLAP // Proceedings of First International Conference on Data Warehousing and Knowledge Discovery, — Florence, Italy: Springer-Verlag, 1999. — c. 165-172

51. Lechtenborger J., Vossen G., Multidimensional normal forms for data warehouse design // Information Systems, — NY: Elsevier, т. 28, № 5, 2003. — с. 415-434

52. Lehner W., Modeling Large Scale OLAP Scenarios // Proceedings of the Sixth International Conference on Extending Database Technology, — Valencia, Spain: Springer-Verlag, 1998.-е. 153-167

53. Moss L., Atre S., Business Intelligence Roadmap: The Complete Project Lifecycle for Decision-Support Applications, — Boston: Addison-Wesley, 2003. — 576 c.

54. Mumick I. S., Quass D., Mumick B. S., Maintenance of Data Cubes and Summary Tables in a Warehouse // Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, — NY: ACM Press, 1997. — c. 100-111.

55. Niemi Т., Nummenmaa J., Thanisch P., Normalizing OLAP cubes for controlling sparsity // Data & Knowledge Engineering, — NY: Elsevier, т. 46, № 3,2003. —с. 317-343

56. Pendse N., Database explosion Электронный ресурс] — London: Optima Publishing, —Режим доступа http://www.olapreport.com — 2005.

57. Poess M., Potapov D., Data Compression in Oracle, — San Francisco, С A: Oracle World №11, 2004. — c. 10-14

58. Rafanelli M., Multidimensional Databases: Problems and Solutions, — Hershey, USA : Idea Group Pub, 2003. — 474 c.

59. Sapia С., On Modeling and Predicting Query Behavior in OLAP Systems // Proceedings of International Workshop on Design and Management of Data Warehouses, — Switzerland: Swiss Life, 1999. — c. 1-10

60. Sarvotham S., Riedi R., Baraniuk R.,Traffic characterization: Connection-level analysis and modeling of network traffic // Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, — NY: ACM Press, 2001. — c. 99103

61. Shukla A., Deshpande P. M., Naughton J. F., Ramasamy K., Storage estimation for multidimensional aggregates in the presence of hierarchies // Proceedings of 22nd Very Large Databases, — Bombay, India: Mumbai, 1996. — c. 522-531

62. Sommers J., Barford P., Traffic generation and analysis: Self-configuring network traffic generation // Proceedings of the 4th ACM SIGCOMM conference on Internet measurement, — NY: ACM Press, 2004. — c. 68-81

63. Stark D., Humphrey S., Data Blocks —The Key to Optimizing Hyperion Электронный ресурс] — Mountain View, CA: Analysis Team, Inc. — Режим доступа http://www.analysisteam.com — 2003.

64. Thomsen E., OLAP Solutions: Building Multidimensional Information Systems, — NY: John Wiley & Sons, 2002. — 686 c.

65. Tsois A., MAC: Conceptual data modeling for OLAP // Proceedings of Design and Management of Data Warehouses — Interlaken, Switzerland: Technical University of Aachen, т. 39, 2001. — с. 1-11

66. Vassiliadis P., Sellis Т., A Survey of Logical Models for OLAP Databases //SIGMOD, — NY: ACM Press, т. 27, №4, 1999. — с. 64-69

67. Vassiliadis P., Modeling Multidimensional Databases, Cubes and Cube Operations // Proceedings of the 10th International Conference on Scientific and Statistical Database Management, — Washington DC: IEEE Computer Society, 1998.— c. 53-62

68. Наставление no GPSS/PC. Minuteman Software /пер. с англ. под ред. Якимова И. М., — Казань, 1997 г. — 320 с.

69. Руководство по GPSS/PC. Minuteman Software /пер. с англ. под ред. Якимова И. М., — Казань, 1997 г. — 351 с.

70. Oracle Express: Database design and performance guide Электронный ресурс] — Oracle Corp. — Режим доступа http://otn.oracle.com — 2001.

71. Hyperion Essbase Optimization Techniques Электронный ресурс] — Режим доступа http://dev.hvperion.com/resource library — 2001.