Содержание к диссертации
Введение
Глава 1. Битовая многомерная модель представления данных 12
1.1 Особенности битовой гиперкубической модели представления данных 12
1.2 Недостатки гиперкубической модели и методы их преодоления 22
1.3 Определение символики описания компонентов битовой многомерной модели 35
1.4 Конвертирование классической многомерной модели данных в битовую 44
1.5 Выводы по первой главе 50
Глава 2. Алгебра операций над информационными объектами многомерного гиперкуба и его окружением 52
2.1 Элементарные операции над атомарными информационными объектами многомерного гиперкуба 52
2.1.1 Удаление 53
2.1.2 Изменение 55
2.1.3 Добавление 56
2.1.4 Реляционная аналогия 57
2.2 Основные операции над информационными объектами гиперкуба 58
2.2.1 Операции над многомерными множествами 60
2.2.2 Дискретные операции многомерной алгебры 68
2.2.3 Специальные операции многомерной алгебры 69
2.3 Операции над множествами размерностей 73
2.4 Операции над разнотипными информационными объектами 78
2.5 Выводы по второй главе 82
Глава 3. Разработка программного обеспечения, реализующего предложенную модель хранения данных и оценка практического эффекта 84
3.1 Уровни абстракции информационной системы контроля и учета сетевого трафика 85
3.2 Схема данных информационной системы контроля и учета сетевого трафика 89
3.3 Оценка эффективности предложенных методов в сфере контроля и учета сетевого трафика 95
3.4 Выводы по третьей главе 103
Заключение 106
Список литературы 108
Приложение1
- Недостатки гиперкубической модели и методы их преодоления
- Основные операции над информационными объектами гиперкуба
- Схема данных информационной системы контроля и учета сетевого трафика
- Оценка эффективности предложенных методов в сфере контроля и учета сетевого трафика
Введение к работе
Актуальность темы
Системы хранения и обработки информации, или, по-другому, системы управления базами данных (СУБД) в настоящее время являются одним из самых важных компонентов информационных систем. Во многих сферах жизнедеятельности человека специфика предметной области предъявляет к хранению и обработке данных очень жесткие требования. Это обусловлено необходимостью производить сложный анализ большого количества информации. К таким предметным областям можно отнести, например сбор статистических данных с многочисленных объектов нефтедобычи, экологический мониторинг какого-либо региона, дистанционное образование и т.д.
Предметной областью данной работы является контроль и учет сетевого трафика на уровне крупных интернет-провайдеров. Выбор данной сферы обусловлен тем, системы связи сегодня используются повсеместно. С совершенствованием интернет-технологий к системам контроля сетевого трафика предъявляются все более высокие требования, касающиеся в первую очередь их производительности. Это обусловлено тем, что таким системам приходится оперировать большими потоками самой разнообразной информации. Это могут быть данные о клиентах, о состоянии их счета, о запрашиваемых ими ресурсах, о времени и скорости соединения и т.д. [70, 80].
Одним из ключевых понятий любой СУБД является структура хранимых данных. Под структурой данных обычно понимают совокупность связей и ограничений между различными частями данных, которая образовалась при конкретном способе декомпозиции [2, 4, 13, 18, 54]. С этим понятием тесно связано понятие модели данных. Модель данных - это структура данных вместе с множеством операций над элементами этой структуры [61, 64, 94]. Модель данных предоставляет пользователям СУБД средства описания данных и средства манипулирования ими [15, 26].
В современных СУБД можно выделить два основных класса моделей данных - это логическая и физическая модели [4, 58, 116]. Логическая модель представления данных отвечает за диалог СУБД с конечным пользователем, позволяет ему описывать данные, строить запросы и оценивать их результаты. Эта модель является безотносительной к конкретной реализации на ЭВМ. Физическая модель описывает структуру хранения данных на устройствах памяти ЭВМ и отвечает за быстрое реагирование на команды логической модели и оптимальное размещение данных на физических носителях [58, 83, 84, 116, 132].
В настоящей работе будут рассматриваться логические модели представления данных, поскольку именно они являются инструментами конечных пользователей, предназначенными для реализации сложной аналитической обработки данных.
Для сравнения характеристик логических моделей представления данных обычно используют следующие критерии [22, 50, 100]:
используемый подход к хранению и обработке информации;
максимально возможный объем хранимых данных;
средняя и максимальная скорость выполнения запросов;
наличие средств хранения и работы с «хронологическими» данными
степень развития аппарата математической формализации данных и операций для этой модели.
Среди известных подходов к хранению и обработке информации можно выделить два основных типа: OLTP и OLAP. Термин OLTP (OnLine Transaction Processing) в разных источниках [5, 8, 13, 24] переводится как транзакционная обработка данных или интерактивная диалоговая обработка запросов. Системы, построенные на концепции OLTP (оперативные системы) обеспечивают регистрацию некоторых фактов, их непродолжительное хранение и сохранение в архивах. OLTP-приложения обычно автоматизируют офисные задачи по обработке данных типа входных ордеров, банковских транзакций и т.п. Эти
задачи - структурируемы, повторяемы и состоят из коротких, изолированных транзакций. Операционные базы данных являются, как правило, реляционными и имеют размеры от сотен мегабайт до гигабайтов. Термином OLAP (OnLine Analytical Processing) обозначают принцип многомерного представления данных [9, 23, 25, 52, 82, 91]. Известно, что реляционные системы управления базами данных и OLTP-подход не способны объединять, просматривать и анализировать данные с точки зрения множественности измерений (то есть самым понятным для аналитиков способом) [46, 58, 62]. Таким образом, в системах, где требуются продвинутые средства анализа данных, применяется именно OLAP-подход. Базы данных, построенные на основе этого подхода называются аналитическими и имеют значительно большие по сравнению с оперативными БД размеры.
Актуальность проблемы манипуляции большими объемами данных объясняется тем, что рост этих объемов напрямую связан со снижением быстродействия системы, что может пагубно отразиться на быстроте принятия того или иного важного решения. В системах контроля сетевого трафика это может привести к запоздалой реакции на вирусные атаки, появлению слабых мест в защите серверов, выполняющих важные функции, и к общему снижению информационной безопасности. Данную проблему можно решать на физическом уровне (распределение системы и совершенствование ее аппаратных характеристик) и на логическом уровне (совершенствование структуры представления данных). Решение проблемы на физическом уровне приносит весьма хорошие результаты, но они сопровождаются ростом стоимости аппаратных компонентов системы, что является неприемлемым в условиях дефицита денежных средств. Существующие же на сегодняшний момент решения на логическом уровне представлены такими подходами как «Хранилища данных» (DataWarehouses), «Витрины данных» (DataMarts) и, соответственно, присущими им логическими моделями представления данных.
Термин DataWarehousing в переводе означает «создание, поддержку,
управление и использование хранилища данных» [101, 105, 117, 120]. Общая архитектура этих концепций выглядит следующим, показанным на рисунке 1 образом.
Оперативные базы данных
Оперативные данные (то есть
текущая информация) собираются из
различных источников, очищаются,
интегрируются и складываются в
реляционное хранилище. При этом
они уже доступны для анализа на
уровне построения отчетов.
Перенос и
трансформация
данных
OLAP хранилище
Реляционное хранилище
Полноценные же возможности для анализа данных появляются лишь после загрузки (полной или частичной) их в специальное, многомерное OLAP-хранилище.
Построение отчетов
OLAP-клиент
Как видно из приведенной на рисунке 1 схемы большая часть одних и тех же данных хранится в двух, или даже в трех, различных местах.
Рис. 1 Архитектура Data Warehouse
Однако этот подход к хранению данных вызывает такие негативные последствия, как: а) необходимость
применения средств переноса и трансформации данных, на функционирование которых приходится отводить большое количество времени; б) сильная избыточность данных и, как следствие, резкое увеличение размеров БД [45].
Кроме того, OLAP-хранилище подразумевает необходимость хранения предвычисленных агрегатных значений (то есть суммарных, усредненных, статистических показателей, вычисленных на основе имеющихся данных), что еще больше усугубляет проблему избыточности данных.
Проблема обеспечения приемлемой скорости выполнения любых запросов, как простых, так и сложных, комплексных является особенно актуальной в тех сферах, где требуются средства анализа для принятия решений. В рассматриваемой предметной области, например, заранее предугадать, какие виды анализа и формы отчетности могут потребоваться пользователям системы при работе с ней, как правило, невозможно. Это исключает возможность подстройки системы «под конкретные нужды», которая смогла бы повысить скорость выполнения некоторых запросов ценой снижения скорости выполнения остальных. При решении данной проблемы, разработчики останавливают свой выбор либо на OLTP, либо на OLAP технологиях.
В OLTP-системах используются широко известные реляционные базы данных. Реализация систем принятия решений на OLTP системах, как правило, приводит к неудаче [14, 49, 59, 108, 132], так как, во-первых, аналитические запросы конкурируют с оперативными транзакциями, блокируя данные и вызывая нехватку ресурсов сервера БД, во-вторых, структура оперативных данных (обычно это 3-я нормальная форма) состоит из множества сложным образом связанных таблиц и поэтому конечному пользователю понять ее слишком сложно. И, в-третьих, такая структура не обеспечивает должной скорости выполнения сложных аналитических запросов, так как в одном запросе связывается большое количество таблиц.
Построение же таких систем на основе технологии OLAP также имеет отрицательные стороны. Слабое место многомерной OLAP - плохая масштабируемость (с увеличением объема данных производительность может непропорционально падать) [62, 97], реляционная же OLAP со схемой звезды или снежинки проигрывает в том, что из-за ограничений реляционной схемы продолжительность выполнения запроса зависит от того, по какому измерению производится срез куба или построение агрегата. В этом случае максимальная скорость выполнения запросов может очень сильно отличаться от средней.
Наличие средств хранения и работы с «хронологическими» данными актуально тем, что именно они зачастую и составляют основу для принятия того или иного решения, для формирования подавляющего большинства отчетов и для функционирования алгоритмов, направленных на самообучение и развитие системы [56, 84]. Существующие подходы к проблеме хронологических данных сегодня, как правило, основываются на технологиях Data Warehousing и Write-back. Основным положением первой является наличие большого хранилища неизменяемых исторических данных (то есть OLAP-хранилища). Недостатки такого подхода очевидны - ограниченность набора запросов к такой базе только запросами на выборку данных и невозможность моделирования различных ситуаций типа «что если?», так как это предполагает изменение (пусть и кратковременное) исторических данных [83, 84, 95]. Вторая же позволяет обойти принцип неизменяемости, но делает это за счет образования дополнительных структур хранения измененных данных, что обуславливает рост размеров такой базы [82, 90, 133].
Из вышеприведенного анализа можно сделать вывод о том, что для вышеупомянутых предметных областей, и, в частности, для контроля и учета сетевого трафика, информационную систему реального времени с поддержкой средств анализа данных для принятия решений следует основывать на СУБД, использующей многомерные технологии представления информации. Однако следует заметить, что существующие на сегодняшний день многомерные модели данных имеют ряд недостатков, из которых, кроме описанных выше, можно выделить отсутствие математически формализованного описания данных в составе модели данных и операций по манипулированию этими данными.
Таким образом, актуальным представляется дальнейшее
совершенствование характеристик СУБД, с целью повышения их производительности, для чего целесообразно использовать качественно новую многомерную логическую модель представления данных и аппарата
10 математической формализации данных и операций для этой модели.
Цель работы и задачи исследования
Разработка многомерной логической модели представления данных, способной к выполнению сложных аналитических запросов и обладающей простотой масштабирования.
Для достижения поставленной цели в работе решаются следующие задачи:
Разработка битовой модели многомерного представления данных, базирующейся на гиперкубической многомерной технологии с выделением временного параметра в отдельную размерность.
Определение архитектуры баз данных, основанных на предлагаемой модели их логического представления, а также, алгоритмов и методов конвертирования данных из наиболее известных моделей в предлагаемую.
Разработка для предлагаемой модели собственного математического аппарата, формализующего ее данные и операции над ними.
На защиту выносится
Битовая многомерная модель хранения данных, основанная на гиперкубической технологии.
Аппарат математической формализации данных предлагаемой модели, ее компонентов и операций над ними.
Алгоритмы конвертирования реляционных и классических многомерных баз данных (МВД) в битовую МБД.
Научная новизна
1. Предложена логическая модель битовой МБД, устойчивая к запросам по любым атрибутам, легко масштабируемая, позволяющая перейти от сложного базиса запросов к поликубам, к простому базису многоиндексных переменных (бинарных многомерных матриц), повышая этим скорость
обработки сложных запросов и целостность (а, следовательно, и надежность) хранения и представления данных.
Выработан ряд алгоритмов, направленных на конвертирование данных, что существенно упрощает перенос информации между различными программными и аппаратными платформами. Тем самым достигается одно из основных требований открытых систем — переносимость.
В качестве математически формализованного описания данных в составе предложенной модели и ее компонентов, а также, операций над ними определена алгебра операций над многомерными объектами, содержащая в себе базис операций, необходимый для формирования на его основе системы управления базами данных и языка запросов любой степени сложности.
Недостатки гиперкубической модели и методы их преодоления
Второе значительное отличие предлагаемой логической модели представления данных от классической модели состоит в том, что данные хранятся при помощи одного единственного гиперкуба, то есть база данных имеет гиперкубическую архитектуру. Это стало возможным благодаря тому, что информационное наполнение БД является нетипизированным, а, следовательно, позволяющим внести в один и тот же гиперкуб данные любых типов, так как внесение этих данных затрагивает только размерности битового гиперкуба и не касается его информационного содержимого. В классической же модели внесение данных других типов, как правило, влечет за собой появление нового гиперкуба, информационным наполнением которого и являются эти данные, вследствие чего такая база данных становится поликубической [135].
Основное преимущество гиперкубической модели данных состоит в том, что она позволяет представить данные в виде единой, целостной структуры. Это значительно облегчает решение такого важного вопроса как централизованность информации. Кроме того, в классической поликубической модели гиперкубы соединяются между собой неким подобием реляционных отношений, что отрицательно сказывается на надежности системы [60]. В гиперкубической модели такой проблемы не возникает ввиду отсутствия подобных связей.
Основной недостаток гиперкубической модели представления данных состоит в сложности работы с так называемыми «независимыми» данными. Суть этой проблемы, предлагаемый метод ее преодоления, называемый синтезом гиперкуба, а также принцип деления данных на «зависимые» и «независимые», рассмотрим на следующем примере.
Для начала представим себе набор связанных и зависимых данных, исходя из которых, будет сформирована многомерная битовая БД, построенная по гиперкубическому принципу. Пусть это будет информация о динамическом распределении IP-адресов между клиентами провайдера интернет-услуг и о соединениях этих клиентов с необходимыми им ресурсами. Как известно, при соединении по коммутируемой линии связи каждый клиент получает от интернет-провайдера определенный IP-адрес из диапазона адресов, принадлежащих этому провайдеру. На весь сеанс связи этот выделенный ІР-адрес ставится в соответствие с данными о клиенте (в данном примере, для наглядности, — с его фамилией). Соответственно, все соединения клиента в рамках данного сеанса связи рассматриваются как соединения выделенного клиенту ІР-адреса с другими ресурсами сети (также имеющими свои ІР-адреса). Таким образом, мы получим трехмерный гиперкуб с размерностями «Фамилии клиентов», «ІР-адреса, выделяемые клиентам» и «Запрашиваемые ресурсы». Связность и взаимозависимость этих данных определяется тем фактом, что срезы по любой из этих размерностей не являются бессмысленными.
Теперь заполним этот гиперкуб данными, и результат представим в виде плоской двумерной развертки.
Основные операции над информационными объектами гиперкуба
Для простейшего случая, рассмотренного выше, когда все наборы данных связаны одним определяющим атрибутом, иллюстрацией является одна первая группа. Общий же случай предполагает наличие нескольких групп со своими определяющими атрибутами. Какую бы группу мы ни взяли — для нее обязательно найдется парная группа. Например, пара 1-2 связана через определяющий атрибут первой группы, пара 2-3 - через определяющий атрибут второй группы, а пара 3—4 - через атрибут, не являющийся определяющим ни в третьей, ни в четвертой группах, но присутствующий в них обеих.
Наборы данных имеющие атрибуты, через которые производится связь групп между собой, условимся называть «связующими». Синтез гиперкуба в этом случае выполняется за несколько шагов (транзакций), то есть является многотранзактным. Количество транзакций синтеза равняется числу вышеупомянутых групп. Многотранзактный синтез гиперкуба происходит рекурсивно. Каждая транзакция оперирует двумя аргументами и возвращает в качестве результата два параметра, являющихся аргументами для следующей транзакции. Первым аргументом транзакции является одна из вышеупомянутых групп данных, вторым ее аргументом служит дополнительный набор данных, как правило, представляющий собой результат выполнения предыдущей транзакции. В процессе выполнения транзакции можно выделить две подзадачи: нахождение группы наборов данных, парной первому аргументу текущей транзакции. Поиск такой парной группы производится среди тех групп, которые еще не являлись аргументами транзакции. Найденная таким образом группа передается в следующую транзакцию в качестве ее первого аргумента; синтез набора данных на основе обоих аргументов текущей транзакции. Исключение составляет первая транзакция, для которой синтез происходит только по первому аргументу в силу того, что второй ее аргумент еще не определен. Результат такого синтеза передается в следующую транзакцию в качестве ее второго аргумента.
Таким образом, результатом первой транзакции является набор данных, представляющий собой гиперкуб. Следующие же транзакции добавляют в этот гиперкуб новые размерности и соответственно изменяют его информационное наполнение в соответствии с выражением (1.1).
Вышеприведенная методика синтеза многомерного гиперкуба имеет один значительный недостаток - она применима лишь для того случая, когда определяющий атрибут, по которому связаны наборы данных, содержит одинаковое число одинаковых элементов для каждого из наборов данных. Так, если в приведенном в таблице 5 примере первый набор данных в качестве общего атрибута использует множество {Иванов, Петров, Сидоров, Васильев}, а второй - множество {Сергеев, Иванов, Петров, Сидоров}, то синтез гиперкуба становится невозможным.
Для решения этой проблемы применяется так называемый «расширенный» синтез гиперкуба. Для этого размерности, не являющиеся определяющим атрибутом, дополняются при необходимости «пустым» элементом (nil-элементом), а формирование общего определяющего атрибута, происходит посредством выборки из всех наборов данных неповторяющихся значений определяющих атрибутов этих наборов. Для вышеприведенного примера такими «пустыми» элементами послужат - элементы «Никакой», добавленные к множеству ресурсов и к множеству выделявшихся ІР-адресов.
Схема данных информационной системы контроля и учета сетевого трафика
На основании вышеприведенных доводов сформулируем утверждение. Утверждение 1. Для любого произвольно взятого і-го поликуба классической многомерной модели данных справедливо следующее высказывание - для любого к є [1,1 , существует хотя бы одно множество R[l... W;], для которого выполняются следующие условия: Здесь, в отличие от выражения (1.14) вертикальная черта разделяет множество множеств и обычное множество. Это также обозначает адресацию левой части правой частью. Например, запись AJR; будет подразумевать фиксацию на каждой размерности из множества А; элемента, номер которого задан соответствующим элементом множества R,.. Запись А; [з] R; [з] будет означать фиксацию на третьей размерности элемента с номером R, [з]. Вертикальная черта, разделяющая упорядоченное множество и число і, адресует i-ый элемент упорядоченного множества. Итак, набор множеств R, удовлетворяющий условиям утверждения 1 будем обозначать Rjk , таким образом, выражение Rjk = /(Е(, В; [k]) означает неоднозначную функциональную зависимость наборов R от номера поликуба -і, и показателя - В;[к]. И наоборот, любое, удовлетворяющее первому условию, множество R однозначно адресует какой либо элемент множества показателей Смысл утверждения 1 заключается в том, что в любом поликубе классической многомерной модели любой произвольно взятый элемент множества «показателей» может быть адресован хотя бы одной комбинацией фиксированных значений каждой размерности этого поликуба. Также примем во внимание тот факт, что фиксирование элемента размерности приводит к получению среза данных по этому элементу.
Так как срез представляет собой ЙОГ, то имеет смысл говорить о размерности его базиса. Размерность базиса полученного среза будет на единицу меньше размерности базиса исходного гиперкуба, следовательно, фиксация элемента в нескольких размерностях приведет к получению среза данных, с размерностью базиса а-Ь, где а размерность базиса исходного гиперкуба, a b - число фиксируемых размерностей. Таким образом, при фиксации всех размерностей гиперкуба мы получаем срез данных размерностью 0 (так как в этом случае а=Ь) являющийся отдельным элементом гиперкуба (см. рис. 2), а, следовательно, и элементом множества его «показателей». Результат фиксации элементов размерностей будем называть пересечением срезов и обозначать символом X (необходимо сразу отметить, что пересечение срезов ни в коем случае не аналогично пересечению множеств, обозначаемому символом П)- Пользуясь вышеприведенными положениями условие 2 утверждения 1 можно представить как функцию адресации элемента В,[к] множеством R[l...Wj], содержащим в себе индексы фиксируемых элементов для каждой размерности. Условие 1 служит для соблюдения границ размерностей и не позволяет элементам множества R[l.. .Wj] выходить за пределы соответствующих им размерностей. Из формулировки утверждения легко заметить то, что некоторые элементы В; [к] могут быть адресованы неоднозначно, то есть одному В, [к] могут соответствовать несколько различных R[l...Wj].
Этот факт объясняется самим принципом формирования множества B L.-fJ, исключающим в нем повторяющиеся элементы, в то время как процент повторения «показателей» (степень избыточности) исходного поликуба может быть достаточно высок. Следовательно, любому элементу множества В; [1...1 ] могут соответствовать одна или несколько ячеек поликуба. По отношению к утверждению 1 важно сделать еще одно важное замечание. Не следует забывать, что данное утверждение сформулировано лишь для классической многомерной модели. Для описания предлагаемой модели данных мы будем использовать модифицированный ее вариант, учитывающий битовую специфику. Обозначим через D[1...M + NJ множество размерностей гиперкуба предлагаемой битовой модели: Число элементов в каждом D[i] обозначим g,-. Используя определение (1.21) сформулируем утверждение 2. Утверждение 2. Для гиперкуба битовой многомерной модели данных справедливо следующее высказывание - для любого S є {О, l}, существует хотя бы одно множество R[1...M+N], для которого выполняются следующие условия: Теперь, обозначив Л,. - множество, содержащее в себе порядковые номера вхождений элементов множества размерностей і-го поликуба Et во множество всех размерностей А, сформируем шаблон матрицы перехода W, размером MxN, при этом будем полагать, что он изначально заполнен нулями. Правило формирования такого шаблона выглядит следующим образом: Заметим, что чтобы не выйти за пределы шаблона матрицы перехода, необходимо соблюдение условия W; М; і = 1, N. Это условие выполняется автоматически, так как М - это суммарное количество уникальных размерностей всех поликубов, a Wf — количество размерностей і-го множества, которое является выборкой из всех размерностей. Далее происходит перебор по всем значениям множеств АЬ...,АМ
Из значений индексов перебора на каждой его стадии формируется вспомогательное множество Z[1...M], включающее в себя текущие значения шага итерации для каждого Aj по порядку, то есть Z[i] может принимать значения от 1 до tj. Формирование матрицы перехода VF на каждой итерации этого перебора выполняется по следующему правилу: Теперь для заполнения гиперкуба битовой многомерной базы данных достаточно на основе набора Z, сформированного для каждой итерации перебора, определить множество R , задающее координаты элемента в битовом многомерном гиперкубе и присвоить этому элементу единицу. Такое множество условимся называть индексирующим. Первые М элементов множества R/ определяются набором Z, следующие же N элементов вычисляются исходя из того, что /(Ri) =В;[к] (см. выше). Множества Rj также вычисляются для каждой итерации по формуле
Оценка эффективности предложенных методов в сфере контроля и учета сетевого трафика
Элементарные операции, производимые над атомарными информационными объектами битовой многомерной модели данных, являются базисными составляющими всех операций над объектами многомерного гиперкуба и его окружением. Элементарными они называются потому, что они обусловливают изменения состояний атомарных информационных объектов, то есть процессы перехода из одного состояния в другое. Так как атомарный объект может принимать только значения из множества {0,1}, то смена его состояния также может быть описана только двумя переходами - из нуля в единицу и обратно. Первый переход назовем «вскидыванием» атомарного объекта, второй - «сбрасыванием».
Такими операциями являются удаление, изменение и добавление. Именно равноправие этих операций позволяет реализовать мощные, гибкие системы, применимые в широком диапазоне проектов, в отличии от известных концепций хранилищ и витрин данных.
Принимая во внимание сильное сходство атомарных информационных объектов битового многомерного гиперкуба с переменными Булевой алгебры, условимся о возможности применения к ним логических операций (таких как инверсия, конъюнкция, дизъюнкция и т.п.) как к обычным логическим переменным.
Элементарные операции над атомарными информационными объектами многомерного гиперкуба включают в себя удаление, изменение и добавление. Рассмотрим подробнее.
Элементарная операция удаления имеет смысл только для таких составляющих битового многомерного гиперкуба как размерность и элемент размерности. Говорить об удалении самого атомарного объекта было бы ошибочно, так как это означало бы исключение отдельной ячейки из гиперкуба и привело бы к нарушению однородности его структуры и, как следствие, значительному затруднению дальнейшей работы с ним, не говоря уже о нарушении целостности данных.
Напротив, операции удаления размерностей и/или их элементов не привносят неоднородности в структуру многомерного гиперкуба, хотя и изменяют ее.
Удаление элемента размерности подразумевает исключение из гиперкуба всех атомарных объектов, принадлежащих срезу по этому элементу, а поскольку такой «единичный» срез является однородным, (см. 1.1) следовательно, неоднородность гиперкуба, появившаяся после операции удаления элемента размерности легко устраняется простой склейкой двух образовавшихся гиперкубов.
Значительно сложнее обстоит ситуация с удалением самой размерности. Связано это с тем, что операция удаления размерности вызывает реструктуризацию самого базиса гиперкуба, что связано с перераспределением атомарных объектов в гиперкубе по принципу проецирования его самого на его информационный объект (ЙОГ), размерностью N-l.
Теперь опишем математический аппарат элементарной операции удаления. Аргументами данной операции являются: сам битовый гиперкуб - Т", одна из его размерностей - К и номер удаляемого элемента в этой размерности - ф. Сам исходный гиперкуб удобнее будет представить в виде {Т "1}; К = [l,t].
Процедуру удаления ф-ого элемента размерности, соответствующую исключению ф-ого члена множества К обозначим так: Следовательно, сам процесс удаления можно описать следующей формулой:
Последнее выражение наглядно демонстрирует склейку двух гиперкубов, образовавшихся из исходного в результате удаления элемента его размерности.
Рассматривая крайние случаи удаления первого или последнего элементов размерности (ф=1 или ф=і) формулу (2.2) можно упростить. Примем во внимание тот факт, что при данных значениях ф выражения [1,ф-1] и [ф+1 ,t] противоречат определению целочисленного интервала, а следовательно, не заключают в себе элементов и являются пустыми множествами. Для Ф=1: Delete(Tn, К, ф) = {т }; (КЛр = 0и[ ф+l.t]) =
Теперь рассмотрим случай удаления целой размерности. Аргументами этой операции являются: сам битовый гиперкуб - Тп, и удаляемая размерность — К. Битовый гиперкуб представим в виде {Т }, так как множество D является набором всех размерностей битового гиперкуба (см. (1.17)). Результатом данной операции является битовый многомерный гиперкуб, полученный из следующего соотношения:
В заключении отметим, что элементарная операция удаления в любом случае привносит изменения в структуру многомерного гиперкуба, и, следовательно, является операцией реструктуризации.
По сути своей элементарная операция изменения атомарного объекта сводится к его вскидыванию или сбрасыванию. Необходимо сразу же заметить, что добавление/удаление и вскидывание/сбрасывание атомарного объекта являются разными понятиями. Добавление или удаление атомарного объекта рассматривается как операция физического уровня, влекущая за собой изменение структуры битового гиперкуба, поскольку ни добавление, ни удаление одного атомарного объекта невозможно без удаления или добавления элементов размерностей или даже самих размерностей. Операция вскидывания или сбрасывания атомарных объектов производится над самим содержимым ячейки гиперкуба и не воздействует на структуру МБД прямым образом. Тем не менее, косвенное ее воздействие возможно в случаях, если этой операцией привносится избыточность. Так, например, при сбрасывании последнего атомарного объекта в сечении по какому-либо элементу какой-либо размерности, это сечение становится неинформативным, а, значит, подлежащим удалению. Это производится путем удаления элемента размерности. Более того, если при этом удаляется последний элемент размерности, то вслед за ним удаляется сама размерность.
