CC BY
35АНАЛИЗ ПРОБЛЕМ ПРИ ПРОЕКТИРОВАНИИ ХРОНОЛОГИЧЕСКИХ
БАЗ ДАННЫХ Королев М. Е.1, Лапина Н. А.2
'КоролевМихаил Евгеньевич /KorolevMihail Evgenyevich — студент;
2Лапина Надежда Андреевна / Lapina Nadezhda Andreevna - студент, кафедра компьютерных систем и сетей, факультет информатики и систем управления, Московский государственный технический университет им. Н. Э. Баумана, г. Москва
Аннотация: в данной статье рассмотрена возможность построения хронологических баз данных на основе существующих моделей данных, описан процесс хронологизации данных, рассмотрены основные проблемы при проектировании хронологических баз данных, приведены примеры ограничений на интервалы времени, объяснена необходимость проведения горизонтальной и вертикальной декомпозиции базы данных, а также создания ограничения на значение первичного ключа и ограничений целостности для решения проблем избыточности, многословия и противоречия.
Ключевые слова: хронологическая база данных, кортеж, шестая нормальная форма, реляционная модель, ограничение целостности.
В настоящее время все большее распространение получают хранилища данных (ХД). ХД -это предметно-ориентированная, содержащая исторические данные, неразрушаемая совокупность данных, предназначенная для поддержки принятия управленческих решений [1]. ХД осуществляют сбор и хранение измерительной и отчетной информации, протоколов различных событий. Информация при этом хранится в виде хронологических последовательностей (ХП). Такие базы данных, содержащие исторические (хронологические) данные, называют хронологическими.
Сетевая и иерархическая модели почти потеряли свою актуальность на фоне реляционной модели, альтернативами являются объектно-реляционная и объектно-ориентированная модели [2]. Однако объектные модели данных, по сути, не являются моделями данных, а лишь способами разработки, т.к. они не предоставляют структуру информации и операции над ней, а описывают идеологию, по которой эти структуры данных и операции должны в дальнейшем разрабатываться. Кроме того, ХД свойственно объединение ХП и реляционных данных, при этом необходима возможность работы с данными обоих типов в рамках одного запроса, что невозможно в случае представления ХП в рамках объектной модели данных. В связи с этим реляционная модель является основой для построения хронологических БД. Однако эта модель обладает серьезным недостатком: её основной структурный элемент — неупорядоченное множество кортежей, поэтому запросы, учитывающие упорядоченность, невозможны в реляционной модели.
Хронологические данные могут рассматриваться как закодированное представление высказываний с временными отметками, сама временная шкала состоит из конечной последовательности дискретных, неделимых квантов времени. Высказывания могут содержать информацию о начальной позиции на временной шкале (для представления текущих данных) или же информацию об интервале времени (для представления исторических данных). В ХП имеется уникальная начальная и конечная позиции, которые соответствуют началу и концу отсчета времени. Интервал времени определяется как непустой отрезок временной шкалы, состоящий из всех временных позиций р, таких что b < р < е. Интервал времени трактуется как самостоятельное значение, а не в виде пар отдельных начальных и конечных значений, и обозначается с помощью сокращенного выражения [x: y], где x и y некоторые числа.
Приведение БД в хронологический вид происходит в два этапа. На первом осуществляется полухронологизация переменных отношений путем добавления атрибута с временной отметкой (о начальной позиции на временной шкале) к каждой из этих переменных отношения и переименования их соответствующим образом. В БД недостаточно иметь только переменные отношения «определяющие временную позицию», поскольку они не могут представлять историческую информацию. Поэтому на втором этапе временная отметка заменяется интервалом времени, в случае представления исторических данных.
При проектировании хронологической БД необходимо применять два вида декомпозиции. Горизонтальная декомпозиция разграничивает текущую информацию, которая хранится в «переменной отношения с атрибутами в виде позиции», и историческую информацию, хранящуюся во множестве «переменных отношения с
атрибутами в виде интервала», т. е. применяются разные предикаты. Целесообразность применения горизонтальной декомпозиции обусловлена тем, что она обеспечивает четкое логическое разделение исторической и текущей информации.
Если в кортеже есть несколько атрибутов, меняющихся во времени, и используется общий атрибут с временной отметкой, то может возникнуть ситуация, когда два или более кортежей имеют общие данные об атрибуте в некоторый момент времени, потому что временная отметка распространяется на комбинацию высказываний. Вертикальная декомпозиция состоит в том, что для каждого атрибута, не являющего отметкой времени, вводится собственная отметка времени. Совокупность вертикальной и горизонтальной декомпозиции позволяют привести БД в шестую нормальную форму (6НФ).
Переменная отношения находится 6НФ тогда и только тогда, когда она удовлетворяет всем нетривиальным зависимостям соединения. Из определения следует, что переменная находится в 6НФ тогда и только тогда, когда она неприводима, то есть не может быть подвергнута дальнейшей декомпозиции без потерь. Каждая переменная отношения, которая находится в 6НФ, также находится и в 5НФ [3].
Основные операции проводятся с интервалами времени, атрибуты в виде позиции не подходят для этой цели, поэтому возникает потребность создавать интервал с некоторым вымышленным конечным значением, отличным от реального. Чтобы избежать необходимости включать в БД такую ложную информацию, иногда используется маркер NOW для обозначения «движущейся по временной шкале позиции текущего времени». Однако такая временная отметка является переменной, что приводит к ряду неудобств. С течением времени выражение x=NOW имеет различный результат, а [x:NOW] может перекрываться с разными интервалами, заранее неизвестен результат распаковки картежа с интервалом [x:NOW] и т. д. Переменные отношения с такими интервалами могут применяться, но в БД будет содержаться ложная информация.
Еще одна проблема, с которой сталкивается разработчик, связана с тем, что размерности меток времени в пределах одной ХП могут быть специфичными («рабочая смена», «двухчасовка»), из-за чего возникают трудности при выполнении операций и при переходе от одной размерности к другой. Во-первых, должен быть реализован механизм корректного сдвига всех последующих меток времени размерности «А» при изменении числа меток времени размерности «В», являющихся их частью (например, размерность рабочего дня, может сокращаться на несколько часов в предпраздничные дни, не затрагивая при этом другие рабочие дни). Во-вторых, необходима поддержка добавления/удаления отдельных меток времени размерности.
Кроме того, существует ряд проблем целостности данных, для решения которых необходимо продумать ограничения. После хронологизации первичный ключ включает не только атрибуты, ранее образовавшие ключ, но и метку времени. Новый ключ не может при этом являться внешним ключом, связывающим эту переменную отношения с другой переменной отношения, так как может произойти склейка нескольких кортежей для устранения повторений при добавлении записей. Но если есть запись в последней, то эта запись должна быть найдена и в первой переменной отношения. Для поддержки данной возможности необходимо создать ограничение, оно является примером зависимости включения. Кроме того необходимо ограничение, устраняющее возможность появления бессмысленных пар временных отметок, в которых значение конца интервала меньше значения начала.
Возможна и другая проблемная ситуация: один кортеж отношения может содержать временной интервал [x: x+2] (где х - некоторая случайная величина), а другой [x+1: x+5], а значения атрибутов, к которым относится метка времени, в кортежах одинаковы. В данной ситуации есть повторения для интервала [x+1: x+2], хотя ключи и уникальны. Это, как и появление дубликатов (проблема многословия), приводит к избыточности информации. В указанных двух кортежах с данными интервалы времени перекрываются, а значит действительно «одно и то же повторяется дважды». Для решения этой проблемы необходимо следующее ограничение (S_FROM_TO некоторое отношение). CONSTRAINT XFT1 IS_EMPTY
( ( ( S_FROM_TO RENAME ( FROM AS Fl, TO AS Tl ) ) JOIN ( S_FROM_TO RENAME ( FROM AS F2, TO AS T2 ) ) ) WHERE ( Tl > F2 AND T2 > Fl ) ) OR ( F2 = Tl+1 OR Fl = T2+1 ) ) .
Следующей проблемой является то, что в хронологических БД должны быть определены ^операторы, аналогичные реляционным операторам, которые распаковывают отношения по указанным атрибутам (операция UNPACK), выполняют соответствующую операцию и упаковывают полученный результат (PACK). Пример для операции MINUS: PACK
( ( UNPACK S_DURING { S#, DURING } ON DURING ) MINUS
( UNPACK SP_DURING { S#, DURING } ON DURING ) ) ON DURING
Сами операции PACK и UNPACK с хронологическими данными можно выразить через обычные реляционные операции [2].
PACK r ON А = WITH ( r GROUP { А } AS X ) AS R1 , ( EXTEND Rl ADD COLLAPSE ( X ) AS Y ) { ALL BUT X } AS R2
: R2 UNGROUP Y, где r — реляционное выражение, а А — интервальный атрибут отношения, обозначенного этим выражением
Применение сокращенной формы записи необходимо для повышения производительности: выражения, содержащие длинные интервалы с большой степенью детализации после распаковки могут стать намного объемнее входных данных, если система действительно материализует результат такой распаковки, то с большой вероятностью запрос будет выполняться «бесконечно долго» или потребует большого объема памяти.
Если же все требования к обработке данных выражены в виде одной операции, то оптимизатор получает возможность выбрать наиболее эффективную реализацию, которая может и не требовать материализации распакованных промежуточных результатов.
Таким образом, во-первых, необходимо проводить горизонтальную декомпозицию для разделения текущей и исторической информации, во-вторых, вертикальную декомпозицию для разделения информации, касающейся различных «свойств» одной и той же «сущности». Тем самым БД приводится к 6НФ. Необходимо вводить ряд ограничений целостности для решения проблем избыточности, многословия и противоречия. Должно присутствовать ограничение на значения первичного ключа, получившее название ограничение ^ключа. Также необходимо продумать механизм обращения к данным, временные метки для которых отсутствуют, например вычисление значений при помощи интерполяции. Большинство исследований в области хронометрических БД ограничиваются разработкой ограничений и операций над историческими данными, основанных на операторах над интервалами и множествами интервалов времени, а также методов исполнения таких операций. При этом проблемы, связанные с данными, организованными в виде хронологических последовательностей (формулировка и исполнение запросов, учитывающих данные, восстановимые с помощью интерполяции, а также запросов, использующих специфические размерности времени и хронологическую упорядоченность данных) остаются плохо проработанными [4]. Следовательно, актуальной задачей является разработка модели данных, учитывающей специфику ХП, а также языков и методов эффективного манипулирования для хронологической информации.
Литература
1. Инмон У. Построение хранилищ данных. [Building the Data Warehouse] Лондон: QED Publishing Group, 1996. 576 с.
2. Дейт К Дж. Введение в системы баз данных, 7-е издание: Пер. с англ. М.: Издательский дом «Вильяме», 2001. 1072 с.
3. Нормализация отношений. Шесть нормальных форм. [Электронный ресурс]. Режим доступа: https://habrahabr.ru/post/254773/ (дата обращения: 08.01.2017).
4. Марков Б. Л. Организация данных в системах мониторинга // Высокопроизводительные вычислительные системы и микропроцессоры. Сборник научных трудов ИМВС РАН за 2000 г. М.: ИМВС РАН, 2000. С. 112-117.
