5. Темпоральная модель данных, разработанная Дж. Бен-Зви.

В битемпоральном отношении R содержится набор следующих атрибутов (A1,…, An, T), где Т - определенный на множестве битемпоральных элементов атрибут. Данная модель представляет отношение R таким образом: R = (A1,…, An, Tes, Trs, Tee, Tre, Td). Остановимся на значении каждого атрибута подробнее. Атрибут Tes (effective start) содержит время начала актуальности значения атрибута кортежа. Атрибут Trs - это момент занесения Tes в БД. По аналогии: Tee (effective end) содержит информацию, о времени, когда факт становится не актуальным, а Tre - момент фиксации Tee в БД. В последнем атрибуте Td указывается момент времени, когда запись была удалена из базы данных.

Существуют еще критерии отличия темпоральных баз данных, например, способность работать с некорректно введенными данными. Российские авторы предложили свой взгляд на эту проблему, суть их методов заключается в расширении традиционной модели до темпоральной с помощью добавочных таблиц-связей [12]. Работоспособность данных методов доказана на многочисленных примерах, но нельзя утверждать, что они полностью покрывают все темпоральные возможности с точки зрения определения ТМД.

При работе с темпоральными данными методы индексации, эффективно применяемые в реляционных СУБД, становятся не столь результативными. В исследовании [13] выявляются основные сложности работы с темпоральными базами данных, и одной из них является организация поддержки временных меток, конкретно: поддержание темпоральных отношений в склеенном виде.

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

- не пересекаться, иначе они заменяются одним интервалом, представляющим собой объединение

- не быть смежными, иначе они должны быть заменены на один интервал, являющийся так же объединением

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



3. Разработка концепции базы данных на основе реляционной СУБД

3.1 Темпоральная надстройка над реляционными СУБД

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

Самые распространенные и широко используемые СУБД, такие как Oracle, MySQL Server, PostgreSQL, автоматически поддерживают ограничения первичного и внешнего ключей. Значение первичного ключа априори должно являться уникальным, поэтому атрибуты, на которые ссылается внешний ключ будут уникальными.

Сейчас крупные реляционные СУБД обрабатывают данные из БД с помощью языка запросов SQL. Темпоральные данные могут быть обработаны на его основе, но этот метод будет иметь ряд минусов, например:

- в каждом конкретном приложении нужно выполнять независимую темпоральную поддержку

- скорее всего в временном SQL-запросе появится множество ошибок в связи с его громоздкостью.

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

Время в темпоральных БД воспринимается как целое измерение, притом абсолютно независимое, управляемое самой СУБД и не представляющееся в виде атрибутов сущностей. Кроме того оперирование временем происходит в виде интервалов или наборов интервалов, что сильно отличается от моментального представления. Следовательно, можно сделать вывод, что временные СУБД и языки запросов значительно разнятся с реляционными.

Как уже упоминалось в данной работе, еще не создана СУБД широкого пользования, осуществляющая поддержку временных данных в полном объеме. В связи с этим программисты решают данную проблему при помощи темпоральных надстроек над реляционными СУБД [15]. Приложение клиента посылает запрос не напрямую к СУБД, а к реализованной надстройке, которая изменяет темпоральный клиентский запрос и посылает преобразованный запрос в СУБД на понятном ей языке (Рис. 2). Такая схема обладает большим преимуществом, так как надстройка никак не изменяет реализацию реляционной СУБД. Это позволяет нам использовать всю существующую функциональность классических СУБД. Однако у этого метода есть и недостатки: при его применении использование техники оптимизации, основанной на таких механизмах, как темпоральная структура хранения, темпоральные индексы и темпоральные соединения, представляется невозможным.

Рис. 2. Схема расширения реляционной СУБД до темпоральной



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

3.2 Темпоральная надстройка над SQL

Для решения задачи создания темпоральной надстройки над СУБД в 1994 году было разработано расширение SQL/Temporal.

В стандарте SQL-92 временные аспекты данных можно поддерживать с помощью лишь трех типов данных: TIME, DATE, TIMESTAMP. Что касается стандарта SQL/Temporal, здесь возможности хранения подобных данных были расширены, и была осуществлена почти полноценная обработка темпоральности. Язык дополнен типом данных PERIOD и связанными с ним предикатами и функциями. Атрибуты такого типа выражают интервалы транзакционного или действительного времени.

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

При необходимости добавления в таблицу временной поддержки данных, либо создания новой темпоральной таблицы используются следующие конструкции: ALTER TABLE… ADD VALIDTIME или CREATE TABLE… AS VALIDTIME. В случае если темпоральная поддержка добавляется в обычную реляционную таблицу, в нее добавляются новые атрибуты, обозначающие интервал от времени модификации таблицы и до следующего ее изменения.

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

Серийными являются запросы, представляющие собой как бы логическое обобщение для классического SQL-запроса. При использовании темпорального SQL-3 серийные запросы по написанию очень похожи на свою подобную нетемпоральную модель. Отличие их состоит в записанном впереди главного слова: VALIDTIME[15].

Наглядная модель серийного запроса q' изображена на Рис. 3.1. Он представляет собой логическое расширение классического запроса q. В результате выполнения классического запроса q получается реляционная таблица, так как обращается он к последнему действительному на данный момент состоянию таблицы, которая поддерживает временные атрибуты. Серийный же темпоральный запрос выполняет данный запрос q над всеми состояниями исходной таблицы (на картинке верхний ряд) и записывает новое состояние в итоговую таблицу. Как результат он имеет поддерживающую пользовательское время темпоральную таблицу.



Рис. 3.1. Серийный темпоральный запрос

Серийные операции модификации выполняются подобно случаю с запросами. Здесь серийная операция обновления является расширением классической операции u. В результате выполнения операции модификации u' получаем ряд состояний, содержащий преобразованные с помощью операции u соответствующие состояния первоначальной таблицы (Рис. 3.2).

Рис. 3.2. Серийная темпоральная операция модификации

При выполнении серийного запроса, в итоговой таблице с темпоральной поддержкой оказываются состояния, полученные каждый из одного конкретного состояния в определенный момент времени одной или нескольких первоначальных таблиц. Несерийные же темпоральные запросы для получения конечных состояний используют абсолютно все имеющиеся состояния в первоначальной таблице (Рис. 3.3). Здесь вверху и внизу изображены таблицы с темпоральной поддержкой и их состояния в разные моменты времени. Первоначальная таблица находится вверху, итоговая, полученная при выполнении запроса q над состояниями верхней таблицы - внизу. Следовательно, несерийный запрос можно определить, как запрос, который для вычисления результирующих состояний использует состояния исходной таблицы не только в данный момент времени, но и в другие. Записан такой запрос может быть с использованием следующей добавки: NONSEQUENCED VALIDTIME.

Рис. 3.3. Несерийный темпоральный запрос

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

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



Рис. 3.4. Несерийная темпоральная операция модификации

3.3 Реализация надстройки для поддержки временных данных

В связи отсутствием СУБД, поддерживающих временные данные, выделим три основных подхода к работе с темпоральностью:

· Первый из них - темпоральная поддержка СУБД, предоставляет абсолютную поддержку временных данных, но для него необходимо преобразование ядра СУБД с изменением структур данных. Этот метод довольно трудоемкий и ресурсозатратный, поэтому нами он не рассматривается. Остальные два метода позволяют не вмешиваться в структуру существующей СУБД и задействовать всю ее мощность (индексация, транзакции, восстановление данных).

· Второй подход подразумевает поддержку темпоральных данных через создание библиотеки, транслирующей темпоральные запросы, например, на на языке SQL/Temporal в запросы SQL. Эта реализация является довольно сложной, так как необходимо реализовать транслятор, который будет обращаться к базе данных и парсер языка темпоральной алгебры.

· И последний метод основывается на том, что в каждом конкретном приложении осуществляется своя работа с темпоральными данными. Этот метод мы и рассмотрим дальше в данной работе на примере БД для консалтинговой компании. Чтобы при изменении структуры БД не пришлось переписывать все темпоральные методы, необходимо в приложении реализовать универсальные методы трансляции темпоральной алгебры на SQL.

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

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

Для удобства подключения к базе данных MySQL и ускорения разработки прикладной программы нами был использован фреймворк Hibernate. Он позволяет обращаться с реляционной БД с помощью запросов «Criteria» как с обычными объектами ООП.

3.4 Темпоральная алгебра

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

Далее подробно рассматривается семантика каждой из операций и правила ее трансляции в SQL-выражения. Для обозначения строк в таблицах, поддерживающих пользовательское время, используется t||VT. t обозначает атрибуты, a VT - временную метку. Начало и конец временной метки обозначаются, как VT^- и VT⁺, соответственно. Кроме того, используется операция склейки coal(r), семантика которой описана ниже.

Табл. 6. Операции темпоральной алгебры

1. Темпоральная выборка

Темпоральная выборка вычисляется по следующей формуле:

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

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

Таким образом, операция темпоральной селекции может быть записана как простая селекция на языке запросов SQL:



SELECT * FROM table WHERE condition

2. Темпоральная проекция

Темпоральная проекция задается формулой:

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

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

SELECT a1,…, an, valid_begin, valid_end FROM r;

Предполагается, что проекция таблицы r производится по пользовательским атрибутам a1,…, an.

3. Темпоральное объединение

Темпоральное объединение вычисляется по формуле:

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

Параметр операции coal может быть вычислен достаточно просто:

SELECT * FROM r1 UNION SELECT * FROM r2

При этом необходимо гарантировать, что типы атрибутов на соответствующих местах совпадают.

4. Темпоральное пересечение

Темпоральное пересечения вычисляется по формуле: intersect

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

5. Темпоральная разность

Разность двух темпоральных отношений вычисляется по следующей формуле:



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

6. Темпоральное произведение

Операция темпорального произведения задается следующей формулой:

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

7. Темпоральная агрегация

Результат темпоральной агрегации задается следующей формулой:



Здесь agg - это функция-агрегат (например, COUNT, AVG, MAX и т.п.). Значение такой функции для каждого момента времени вычисляется на наборе всех кортежей, временная метка которых содержит данный момент и пользовательские атрибуты, заданные функцией f(), совпадают.

8. Склейка

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

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

Операция склейки может быть вычислена следующим образом:



4. Разработка концепции базы данных в сфере консалтинга

4.1 Основные требования к разрабатываемому программному продукту

1. База данных разрабатывается с использованием инструментальных средств СУБД MYSQL с использованием удобного инструмента для визуального проектирования БД - MySQL Workbench. Данный программный продукт предоставляет возможность наглядно изобразить модель базы данных в графическом виде, создать необходимые таблицы и установить связи между ними и т.п.

2. Для реализации методов темпоральной логики был использован язык Java с фреймворком Hibernate для удобной синхронизации и работы с базой данных. Это обусловлено современностью и удобством применения данных программных продуктов с точки зрения разработчика.

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

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

4.2 Реализация темпоральной модели в терминах СУБД MYSQL

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

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

Первая стадия процедуры моделирования (начало работы с проектом) состоит в определении цели моделирования и выделении основных сущностей, находящихся в пределах моделируемой проблемной области.

В нашем случае основной целью моделирования является разработка схемы базы данных консалтинга. Основными информационными единицами являются Компания (Company), Сотрудник (Employee), Проект (Project), Должность (Position) и Прибыль (Profit). Каждая выделенная сущность характеризуется своим именем и определением (назначением).

На второй стадии происходит определение связей между сущностями и атрибутов сущностей.

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

Сompany_id - первичный ключ (PK) данной таблицы,

Сompany_name - название компании,

Сompany_establish - дата основания компании,

Сompany_adress - адрес компании,

Employee_Employee_director - директор организации (внешний ключ - FK).

· Таблица Profit - в ней хранится подробная информация о ежемесячной выручке, затратах и прибыли организаций. Таблица содержит следующие атрибуты:

Profit_id - первичный ключ (PK) таблицы,

Profit_month - месяц, за который вносятся данные,

Profit_year - год за который вносятся данные,

Profit_income - доход за указанный месяц,

Profit_spend - расходы за указанный месяц,

Profit_profit - прибыль за месяц,

Profit_transact_time - дата занесения информации в БД,

Company_Company_id - id компании (FK).

· Таблица Employee - данная таблица хранит в себе информацию о всех сотрудниках, трудящихся в компаниях - клиентах. Набор атрибутов таблицы:

Employee_id - PK таблицы,

Employee_name - имя сотрудника,

Employee_surname - фамилия сотрудника,

Employee_patronymic - отчество сотрудника,

Employee_civility - пол сотрудника,

Employee_adress - адрес сотрудника,

Compamy_company_id - id компании (FK).

· Таблица Project - темпоральная таблица, содержит информацию о всех прошлых, текущих и будущих проектах компаний. Атрибуты:

Project_id - РК таблицы,

Project_name - название проекта,

Project_start - дата начала проекта,

Project_end - реальная или планируемая дата завершения проекта,

Project_cost - стоимость проекта в рублях,

Project_transact_time - дата внесения информации по проекту в БД.

· Таблица Position - хранит все активные и неактивные должности в компании. Атрибуты таблицы:

Position_id - РК таблицы,

Position_name - название должности.

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

Temp_position_id - РК таблицы,

Temp_position_start - дата начала работы в данной должности,

Temp_position_end - дата, с которой сотрудник больше не выступает в данной должности,

Temp_position_transact_time - дата занесения информации в БД,

Employee_Employee_id - id сотрудника (FK), занимающего должность,

Position_Position_id - id должности (FK).

· Таблица Temp_Selary - темпоральная таблица, предоставляющая исторические данных о всех зарплатах и их изменениях за различные периоды. В таблице содержатся следующие атрибуты:

Temp_Salary_id - первичный ключ таблицы,

Temp_Salary_amount - заработная плата сотрудника в рублях,

Temp_Salary_start - дата, начиная с которой сотрудник получает указанную заработную плату,

Temp_Salary_end - дата, начиная с которой сотрудник не получает указанную заработную плату,

Temp_Salary_transact_time - дата занесения информации в БД,

Employee_Employee_id - id сотрудника (FK).

На данном этапе следует определить связи между сущностями. С помощью программного обеспечения MySQL с использованием удобного инструмента для визуального проектирования БД - MySQL Workbench нами была построена диаграмма сущностей и построены отношения между ними (Рис. 4).

В основном между объектами устанавливается «неидентифицирующая связь» - такая связь, при которой экземпляр дочерней сущности не идентифицируется через свою связь с родительской сущностью. Таким образом, создается обыкновенный внешний ключ, причем в дочернюю таблицу добавляется столбец - первичный ключ родительской таблицы. Например, неидентифицирующей является связь «Работает» между Сотрудниками (дочерняя таблица) и Компанией (родительская таблица), связь один-ко-многим; или связь «Руководит» между этими таблицами, связь один-к-одному.

Между таблицами «Сотрудник» и «Проект» устанавливается связь многие-ко-многим, так как один сотрудник может быть задействован в нескольких проектах, и один проект ведут несколько сотрудников. Так как связь многие-ко-многим возможна только в логической модели данных, на физическом уровне связь многие-ко-многим преобразуется в две новые связи один-ко-многим от старых сущностей к новой добавленной ассоциативной сущности, в нашем случае к Employee_has_Project (Рис. 4).

· Таблица Employee_has_Project - информирует о том, в каких проектах задействован каждый из сотрудников. В таблице 2 атрибута:

Employee_Employee_id - id сотрудника, участвующего в проекте,

Project_Project_id - id проекта.

Рис. 4. Диаграмма сущностей БД консалтинга

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

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

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

И последняя связь один-ко-многим между сущностями Позиция и Темпоральная позиция трактуется следующим образом: одна и та же позиция в компании в разное время занята разными людьми. Следовательно одной должности в таблице Темпоральная позиция будут ставиться в соответствие разные сотрудники с указанием времени их работы на данной должности.

4.2 Темпоральная надстройка

На данном этапе перед ними стоит цель создания темпоральной надстройки. В качестве языка программирования был выбран объектно-ориентированный язык Java.

Для доступа к данным из БД используется фреймворк Hibernate, который подключается к нашей БД MySQL с помощью стандартного драйвера JDBC. Для настройки подключения Hibernate к БД используется файл конфигураций hibernate.cfg.xml, в котором необходимо указать данные соединения, некоторую служебную информацию и указать ресурсы, которые будут использоваться из БД (Рис. 5).

Рис. 5. Файл конфигураций Hibernate

После подключения Hibernate необходимо создать классы сущностей, которые будут соответствовать таблицам из БД. Кроме того, все связи указываются в отдельных xml файлах. Один из примеров таких файлов для таблицы Temp_position:

<? xml version='1.0' encoding='utf-8'?>

<! DOCTYPE hibernate-mapping PUBLIC

«- //Hibernate/Hibernate Mapping DTD 3.0 //EN»

«http://www.hibernate.org/dtd/hibernate-mapping-3.0.dtd»>

<hibernate-mapping>

<class name= «vera.db.methods.entities. TempPosition» table= «Temp_position» schema= «mydb»>

<id name= «tempPositionId»>

<column name= «Temp_position_id» sql-type= «int(11)»/>

</id>

<property name= «tempPositionStart»>

<column name= «Temp_position_start» sql-type= «date»/>

</property>

<property name= «tempPositionEnd»>

<column name= «Temp_position_end» sql-type= «date» not-null= «true»/>

</property>

<many-to-one name= «employeeEmployeeId» column= «Employee_Employee_id» class= «vera.db.methods.entities. Employee»

lazy= «false» fetch= «join» not-null= «true» />

<many-to-one name= «positionPositionId» column= «Position_Position_id» class= «vera.db.methods.entities. Position»

lazy= «false» fetch= «join» not-null= «true» />

<property name= «tempPositionTransactTime»>

<column name= «Temp_position_transact_time» sql-type= «date»/>

</property>

</class>

</hibernate-mapping>

В первую очередь необходимо реализовать темпоральную алгебру из предыдущей главы. Нужно реализовать обработчик, который будет преобразовывать входные данные в SQL-запрос.

Интерфейс темпоральной алгебры будет состоять из следующих 7-ми методов:



public interface TempAlgebraDao {

List<Object> selection (Object table, String condition);

List<Object> projection (Object table, Date valid_begin, Date valid_end);

List<Object> union (Object r1, Object r2);

List<Object> intersection (Object r1, Object r2);

List<Object> difference (Object r1, Object r2);

List<Object> composition (Object r1, Object r2);

List<Object> aggregation (Object r, String agg);

},

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

Чтобы реализовать этот интерфейс мы будем использовать класс org.hibernate.criterion. Criterion для обработки и трансляции входных данных и данных из БД в SQL-запрос. Результаты работы методов должны формировать SQL-запросы для каждой операции темпоральной алгебры.

· Так, для операции темпоральной выборки получаем на выходе SQL-запрос к реляционной БД (Рис. 6):

Рис. 6. Темпоральная выборка

· При выполнении метода, отвечающего за темпоральную проекцию, имеем следующий SQL-запрос (Рис. 7):

Рис. 7. Темпоральная проекция



Где r - таблица, а a1,…, an - атрибуты.

· Темпоральное объединение выполняется следующим запросом (Рис. 8):

Рис. 8. Темпоральное объединение

· Результат пересечения двух таблиц r1 и r2 c пользовательскими атрибутами а1,…, аn и b1,…, bn соответственно, можно вычислить с помощью SQL-выражения (Рис. 9):

Рис. 9. Темпоральное пересечение

· Темпоральную разность таблиц l и r можно найти с помощью следующего SQL-запроса (таблицы имеют наборы пользовательских атрибутов а1,…, аn и b1,…, bn, соответственно) (Рис. 10):



Рис. 10. Темпоральная разность

· Темпоральное произведение паблицы l с пользовательскими атрибутами а1,…, аk, c1,…, cn и r с пользовательскими атрибутами b1,…, bm, c1,…, cn можно вычислить с помощью следующего SQL-запроса (Рис. 11):

Рис. 11. Темпоральное произведение

· Темпоральную агрегацию в несклеенном виде (до применения операции coal) для отношения r с пользовательскими атрибутами a1,…, am, g1,…, gn, агрегирующей функции f и набором атрибутов, по которым производится группировка записей для агрегирующей функции g1,…, gn, можно вычислить с помощью следующей полседовательности SQL-выражений (Рис. 12):

Рис. 12. Темпоральная агрегация



· На SQL склейку таблицы r с пользовательскими атрибутами a1,…, an можно записать следующим образом (Рис. 13):

Рис. 13. Склейка

После реализации темпоральной алгебры любой темпоральнй запрос может быть транслирован в реляционный. Наконец, для дополнительной обработки темпоральной информации будем использовать дополнительные методы, результат которых так же будет SQL-запрос к нашей БД.

Например, для поиска максимального дохода за некоторый промежуток времени реализуем метод maxProfitIncome, в который передается интервал времени.

public List<Profit> maxProfitIncome (int startMonth, int endMonth) {

sf = HibernateUtil.getSessionFactory();

sf.getCurrentSession();

Session session = sf.openSession();

DetachedCriteria maxId = DetachedCriteria.forClass (Profit.class)

setProjection (Projections.max («profitIncome»));

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.between («profitMonth», startMonth, endMonth)).add (Property.forName («profitIncome»).eq(maxId));

return criteria.list();

}

Так же для определения зарплаты сотрудника метод getSalary, который принимает на вход сотрудника и интервал времени.

public List<TempSalary> getSalary (Employee employee, Date start, Date end) {

sf = HibernateUtil.getSessionFactory();

Session session = sf.openSession();

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.ge («Temp_Salary_Start», start)).add (Restrictions.lt («Temp_Salary_Start», end));

return criteria.list();

}



Заключение

В процессе выполнения выпускной квалификационной работы по теме «Исследование и разработка темпоральнои? базы данных» получены следующие результаты:

1. Исследованы и проанализированы основные модели представления временного фактора в теории интеллектуальных систем, а именно: темпоральные интервальная (представление времени с помощью временных интервалов) и точечная (использование в качестве базовых элементов временных точек) логики. Идея представления времени с использованием временных интервалов проиллюстрирована на примере темпоральной логики Allen [7], а точечный подход проиллюстрирован на примере темпоральной логики McDermott [8].

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

3. Разработана основная концепция (базовые элементы и связи) ТМД, построена ER-диаграмма для обеспечения области консалтинга

4. Средствами СУБД MySQL была спроектирована и создана БД для консалтинга. С помощью объектно-ориентированного языка программирования Java с фреймворком Hibernate была разработана темпоральная надстройка над реляционной БД, опирающаяся на основные принципы темпоральной алгебры и транслирующая темпоральные запросы в запросы SQL.

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



Список использованных источников

1. Yoav Shoham. Reasoning about Change. - The MIT Press Series in Artificial Intelligence, 1988.

2. Е.Ю. Кандрашина, Л.В. Литвинцева, Д.А. Поспелов. - Представление знаний о времени и пространстве в интеллектуальных системах. - М.: Наука, 1989.

3. A. Pnueli. A temporal logic of programs. - Proceedings of 18^th FOCS, October 1977.

4. V.R. Pratt. Semantical Considerations on floyd-hoare logic. - Proceedings of 17^th FOCS, IEEE, October 1976.

5. H. Nishimura. Descriptevely complete process logic. - Acta Informatica, 1980.

6. J.F. Allen and P.J. Hayes. A common-sense theory of time. - Proceedings of 9^th IJCAI, Los Angeles, 1985.

7. J.F. Allen. Towards a general theory of action and time. - Artificial Intelligence, 23 (2), 1984.

8. D. McDermott. A temporal logic for reasoning about processes and plans. - Cognitive science, 1982.

9. А. Тейз, П. Грибомон. Логический подход к искусственном интеллекту: От модальной логики к логике баз данных: Пер. с франц. - М.: Мир, 1998.

10. Snodgrass R. Developing Time-Oriented Database Applications in SQL - Morgan Kaufmann Publishers, 1999.

11. Jensen C.S., Soo M.D., Snodgrass R.T. Unifying Temporal Data Models Via a Conceptual Model, Information Systems Vol. 19, No. 7, 1994.

12. Пораи? Д.С., Соловьев А.В., Корольков Г.В. Реализация концепции темпоральнои? базы данных средствами реляционнои? СУБД // Документооборот. Концепции и инструментарии?: сб. науч. тр. / Ин-т системного анализа РАН; под ред. В.Л. Арлазарова, Н.Е. Емельянова. М.: Едиториал УРСС, 2004.

13. К.Дж. Дейт. Введение в системы баз данных, 7-е издание. Вильямс, 2002.

14. А.Н. Базаркин. Разработка темпоральнои? модели данных в медицинскои? информационнои? системе. тр. Междунар. конф.: ИПС РАН, Переславль-Залесскии?, 2006.

15. Нгуен Доан Куонг. Организация доступа, хранения и извлечения знаний в темпоральных базах данных. Санкт-Петербург, 2006.

16. Б.Б. Костенко, С.Д. Кузнецов. История и актуальные проблемы темпоральных баз данных, МГУ, 2007, Эл. ресурс: http://www.citforum.ru/

database/articles/temporal

17. McKenzie E., Snodgrass R. Supporting Valid Time in an Historical Relational Algebra: Proofs and Extensions: Technical Report Department of Computer Science, University of Arizona. Tucson, AZ, 1991.



Приложение

Интерфейсы:

package impl;

import vera.db.methods.entities. Profit;

import java.util. List;

public interface ProfitDao {

List<Profit> getProfit();

List<Profit> getProfit (int month, int year);

List<Profit> maxProfitIncome (int startMonth, int endMonth);

List<Profit> minProfitIncome (int startMonth, int endMonth);

List<Profit> maxProfitConsumption (int startMonth, int endMonth);

List<Profit> minProfitConsumption (int startMonth, int endMonth);

}

package impl;

import java.util. Date;

import java.util. List;

public interface TempAlgebraDao {

List<Object> selection (Object table, String condition);

List<Object> projection (Object table, Date valid_begin, Date valid_end);

List<Object> union (Object r1, Object r2);

List<Object> intersection (Object r1, Object r2);

List<Object> difference (Object r1, Object r2);

List<Object> composition (Object r1, Object r2);

List<Object> aggregation (Object r, String agg);

}



Реализация:

package dao;

import impl. ProfitDao;

import org.hibernate. Criteria;

import org.hibernate. Session;

import org.hibernate. SessionFactory;

import org.hibernate.criterion.*;

import utils. HibernateUtil;

import vera.db.methods.entities. Profit;

import java.util. List;

public class ProfitDaoImpl implements ProfitDao {

private SessionFactory sf;

public List<Profit> getProfit() {

sf = HibernateUtil.getSessionFactory();

Session session = sf.openSession();

List profits = session.createQuery («from Profit»).list();

session.close();

return profits;

}

public List<Profit> getProfit (int month, int year) {

sf = HibernateUtil.getSessionFactory();

Session session = sf.openSession();



List profits = session.createQuery («from Profit where profitMonth =» + month + «and profitYear =» + year).list();

session.close();

return profits;

}

public List<Profit> maxProfitIncome (int startMonth, int endMonth) {

sf = HibernateUtil.getSessionFactory();

sf.getCurrentSession();

Session session = sf.openSession();

DetachedCriteria maxId = DetachedCriteria.forClass (Profit.class)

setProjection (Projections.max («profitIncome»));

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.between («profitMonth», startMonth, endMonth)).add (Property.forName («profitIncome»).eq(maxId));

return criteria.list();

}

public List<Profit> minProfitIncome (int startMonth, int endMonth) {

sf = HibernateUtil.getSessionFactory();

sf.getCurrentSession();

Session session = sf.openSession();

DetachedCriteria maxId = DetachedCriteria.forClass (Profit.class)

setProjection (Projections.min («profitIncome»));

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.between («profitMonth», startMonth, endMonth)).add (Property.forName («profitIncome»).eq(maxId));

return criteria.list();

}

public List<Profit> maxProfitConsumption (int startMonth, int endMonth) {

sf = HibernateUtil.getSessionFactory();

sf.getCurrentSession();

Session session = sf.openSession();

DetachedCriteria maxId = DetachedCriteria.forClass (Profit.class)

setProjection (Projections.max («profitSpend»));

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.between («profitMonth», startMonth, endMonth)).add (Property.forName («profitIncome»).eq(maxId));

return criteria.list();

}

public List<Profit> minProfitConsumption (int startMonth, int endMonth) {

sf = HibernateUtil.getSessionFactory();

sf.getCurrentSession();

Session session = sf.openSession();

DetachedCriteria maxId = DetachedCriteria.forClass (Profit.class)

setProjection (Projections.min («profitSpend»));

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.between («profitMonth», startMonth, endMonth)).add (Property.forName («profitIncome»).eq(maxId));

return criteria.list();

}

}

package dao;

import impl. Temp_SalaryDao;

import org.hibernate. Criteria;

import org.hibernate. Session;

import org.hibernate. SessionFactory;

import org.hibernate.criterion. DetachedCriteria;

import org.hibernate.criterion. Projections;

import org.hibernate.criterion. Property;

import org.hibernate.criterion. Restrictions;

import utils. HibernateUtil;

import vera.db.methods.entities. Employee;

import vera.db.methods.entities. Profit;

import vera.db.methods.entities. TempSalary;

import java.util. Date;

import java.util. List;

public class Temp_SalaryDaoImpl implements Temp_SalaryDao {

private SessionFactory sf;

public List<TempSalary> getSalary() {

sf = HibernateUtil.getSessionFactory();

Session session = sf.openSession();

List tempSalary = session.createQuery («from TempSalary»).list();

session.close();

return tempSalary;

}

public List<TempSalary> getSalary (Employee employee, Date start, Date end) {

sf = HibernateUtil.getSessionFactory();

Session session = sf.openSession();



 // DetachedCriteria maxId = DetachedCriteria.forClass (TempSalary.class)

 // .setProjection (Projections.max («profitIncome»));

Criteria criteria = session.createCriteria (Profit.class)

add (Restrictions.ge («Temp_Salary_Start», start)).add (Restrictions.lt («Temp_Salary_Start», end));

return criteria.list();

}

}

Размещено на Allbest.ru