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

• Автор: Ивлев, Дмитрий Валерьевич
• Шифр специальности: 05.13.11
• Научная степень: Кандидатская
• Год защиты: 2003
• Место защиты: Уфа
• Количество страниц: 123 с. : ил.

Оглавление
Введение

Актуальность темы.

Цель работы и задачи исследования

На защиту выносится

Научная новизна

Глава 1. Битовая многомерная модель представления данных.

1.1 Особенности битовой гиперкубической модели представления

данных.

1.2 Недостатки гиперкубической модели и методы их преодоления.

1.3 Определение символики описания компонентов битовой

многомерной модели3
1.4 Конвертирование классической многомерной модели данных в
битовую
1.5 Выводы по первой главе
Глава 2. Алгебра операций над информационными объектами многомерного гиперкуба и его окружением
2.1 Элементарные операции над атомарными информационными
объектами многомерного гиперкуба.
2.1.1 Удаление.
2.1.2 Изменение
2.1.3 Добавление.
2.1.4 Реляционная аналогия.
2.2 Основные операции над информационными объектами гиперкуба.
2.2.1 Операции над многомерными множествами
Объединение.
Пересечение.
2.2.2 Дискретные операции многомерной алгебры
2.2.3 Специальные операции многомерной алгебры.
Надстройка
Усечение
Порождение
Проецирование.
2.3 Операции над множествами размерностей.
Пересечение.
Вычитание.
Объединение.
2.4 Операции над разнотипными информационными объектами.
Операции сравнения информационных объектов гиперкуба
Произведение
Деление.
2.5 Выводы по второй главе
Глава 3. Разработка программного обеспечения, реализующего предложенную модель хранения данных и оценка практического эффекта
3.1 Уровни абстракции информационной системы контроля и учета
сетевого трафика.
3.2 Схема данных информационной системы контроля и учета
сетевого трафика.
3.3 Оценка эффективности предложенных методов в сфере контроля и
учета сетевого трафика.
3.4 Выводы по третьей главе
Заключение
Список литературы


В рассматриваемой предметной области, например, заранее предугадать, какие виды анализа и формы отчетности могут потребоваться пользователям системы при работе с ней, как правило, невозможно. Это исключает возможность подстройки системы «под конкретные нужды», которая смогла бы повысить скорость выполнения некоторых запросов ценой снижения скорости выполнения остальных. При решении данной проблемы, разработчики останавливают свой выбор либо на OLTP, либо на OLAP технологиях. В OLTP-системах используются широко известные реляционные базы данных. Реализация систем принятия решений на OLTP системах, как правило, приводит к неудаче [, , , 8, 2], так как, во-первых, аналитические запросы конкурируют с оперативными транзакциями, блокируя данные и вызывая нехватку ресурсов сервера БД, во-вторых, структура оперативных данных (обычно эго 3-я нормальная форма) состоит из множества сложным образом связанных таблиц и поэтому конечному пользователю понять ее слишком сложно. И, в-третьих, такая структура не обеспечивает должной скорости выполнения сложных аналитических запросов, так как в одном запросе связывается большое количество таблиц. Построение же таких систем на основе технологии OLAP также имеет отрицательные стороны. Слабое место многомерной OLAP - плохая масштабируемость (с увеличением объема данных производительность может непропорционально падать) [, ], реляционная же OLAP со схемой звезды или снежинки проигрывает в том, что из-за ограничений реляционной схемы продолжительность выполнения запроса зависит от того, по какому измерению производится срез куба или построение агрегата. В этом случае максимальная скорость выполнения запросов может очень сильно отличаться от средней. Наличие средств хранения и работы с «хронологическими» данными актуально тем, что именно они зачастую и составляют основу для принятия того или иного решения, для формирования подавляющего большинства отчетов и для функционирования алгоритмов, направленных на самообучение и развитие системы [, J. DataWarehousing и Write-back. Основным положением первой является наличие большого хранилища неизменяемых исторических данных (то есть OLAP-хранилища). Недостатки такого подхода очевидны - ограниченность набора запросов к такой базе только запросами на выборку данных и невозможность моделирования различных ситуаций типа «что если? Вторая же позволяет обойти принцип неизменяемости, но делает это за счет образования дополнительных структур хранения измененных данных, что обуславливает рост размеров такой базы [, , 3]. Из вышеприведенного анализа можно сделать вывод о том, что для вышеупомянутых предметных областей, и, в частности, для контроля и учета сетевого трафика, информационную систему реального времени с поддержкой средств анализа данных для принятия решений следует основывать на СУБД, использующей многомерные технологии представления информации. Однако следует заметить, что существующие на сегодняшний день многомерные модели данных имеют ряд недостатков, из которых, кроме описанных выше, можно выделить отсутствие математически формализованного описания данных в составе модели данных и операций по манипулированию этими данными. Разработка многомерной логической модели представления данных, способной к выполнению сложных аналитических запросов и обладающей простотой масштабирования. Разработка битовой модели многомерного представления данных, базирующейся на гиперкубической многомерной технологии с выделением временного параметра в отдельную размерность. Определение архитектуры баз данных, основанных на предлагаемой модели их логического представления, а также, алгоритмов и методов конвертирования данных из наиболее известных моделей в предлагаемую. Разработка для предлагаемой модели собственного математического аппарата, формализующего ее данные и операции над ними. Битовая многомерная модель хранения данных, основанная на гиперкубической технологии. Аппарат математической формализации данных предлагаемой модели, ее компонентов и операций над ними. Алгоритмы конвертирования реляционных и классических многомерных баз данных (МБД) в битовую МБД.