УДК 004.5
В.А. ЛИТВИНОВ, И.Н. ОКСАНИЧ, В.И. ХОДАК
ТЕХНОЛОГИЯ И ИНСТРУМЕНТАРИЙ РЕАЛИЗАЦИИ ГИПЕРПАРАМЕТРИЧЕСКИХ (КВАЗИПРОИЗВОЛЬНЫХ) ЗАПРОСОВ К ТЕМАТИЧЕСКОЙ БАЗЕ ДАННЫХ
Анотація. Розглядаються роль і місце гіперпараметричних (квазидовільних) запитів користувача до тематичних БД в інформаційно-аналітичних системах. Пропонуються технологія побудови таких запитів і відповідне інструментальне програмне забезпечення. Наводяться приклади побудови запитів і скріншоти інтерфейсу користувача.
Ключові слова: інтерфейс користувача, запити до тематичних баз даних, довільні запити, квази-довільні запити.
Аннотация. Рассматриваются роль и место гиперпараметрических (квазипроизвольных) запросов пользователя к тематическим БД в информационно-аналитических системах. Предлагаются технология построения таких запросов и соответствующее инструментальное программное обеспечение. Приводятся примеры построения запросов и скриншоты интерфейса пользователя. Ключевые слова: интерфейс пользователя, запросы к тематической базе данных, произвольные запросы, квазипроизвольные запросы.
Abstract. The role and the place of the hyperparametric (kvaziarbitrary) user queries to the thematic DB in the information-analytical systems are discussed. A technology for constructing such queries and the corresponding software tools are proposed. The examples of the user interface constructing queries and screenshots are given.
Keywords: user interface, queries to the thematic databases, spontaneous queries, kvaziarbitrary queries.
1. Введение
Архитектура современных информационно-аналитических систем (ИАС) различных уровней и назначений (корпоративные, ведомственно-отраслевые, государственные в системе «Электронного правительства» [1]) включает следующие 4 уровня [2]:
- транзакционные или операционные базы данных (БД), являющиеся составной частью OLTP-систем (On-line Transactional Processing). Содержат данные о результатах повседневной деятельности системы;
- ETL - инструменты (Exstraction, Transformation, Loading), предназначенные для извлечения данных из транзакционных БД, их «очистки», консолидации и последующей загрузки в целевые аналитические базы данных следующих уровней;
- хранилища данных (Data Warehouse), предназначенные для организованного хранения консолидированных данных, ориентированных на анализ информации;
- витрины данных (Data Marts), предназначенные для проведения целевого анализа. Строятся, как правило, на основе хранилища данных, а в случае его отсутствия (в простых ИАС) - непосредственно из БД OLTP-систем. В отличие от хранилища данных, витрины «обслуживают» уровень не выше отдельного подразделения ИАС, а иногда могут создаваться и для отдельного пользователя-аналитика (ПА) [2].
С точки зрения ПА, именно витрины являются непосредственным информационным ресурсом, используемым для анализа. В дальнейшем реляционные БД витринного уровня будем называть «тематическими» (ТБД).
В зависимости от сложности формулирования запроса к ТБД со стороны ПА возможны различные типы запросов: «кнопочные» (КЗ), «параметрические» (ПМЗ), «произвольные» (ПЗ). В [3] обосновывается практическая полезность и предлагаются формальные правила построения информационной модели так называемые “квазипроизвольных”
© Литвинов В.А., Оксанич И.Н., Ходак В.И., 2012 ISSN 1028-9763. Математичні машини і системи, 2012, № 1
запросов (КПЗ), занимающих промежуточное положение между ПМЗ и ПЗ в смысле функциональности (разнообразия возможных вариантов искомых наборов данных), с одной стороны, и оперативности доступа к данным, с другой. Технология КПЗ должна позволять формулировать и реализовывать оп-Ипе-запросы в терминах знакомой для ПА предметной области без привлечения специально подготовленных лиц. В сущности, речь идет о расширенном типе параметрических запросов, в которых пользователь специфицирует не только значения заранее заданных параметров и условий, но и сами параметры и условия. Поэтому такие запросы в дальнейшем будем называть «гиперпараметрическими» (ГПМЗ). Настоящая работа развивает основные положения [3] в направлении создания инструментария технологии формирования ГПМЗ.
2. Технология реализации ГПМЗ
Общая технология создания ГПМЗ базируется на последовательном синтезе информационной модели [3] с помощью БуЬаве PowerDesigner 9 - полнофункционального инструментария для создания бизнес-приложений, включающего средства моделирования бизнес-процессов, возможности концептуального и физического проектирования баз данных и предоставляющего централизованный репозиторий для хранения моделей и объектов.
Технология включает следующую последовательность этапов.
1. Анализ предметной области (ПрО) и построение фреймовой модели ПрО, предоставляемой пользователю в интерфейсе, - выделение фреймов (разделов ПрО) и слотов.
Фрейм имеет имя, служащее для идентификации описываемого им понятия; поименованные слоты содержат ЕЯ-значения структурных элементов (атрибутов) этого понятия. На верхнем уровне иерархии фреймовой модели находится корневой фрейм, содержащий информацию, общую для всех остальных фреймов.
Например, для некоторой ПрО, описывающей процесс ликвидации чрезвычайных ситуаций (ЧС), фрейм «Журнал ЧС» содержит атрибуты, представленные в табл 1.
Таблица 1. Атрибуты фрейма «Журнал ЧС»
Имя слота Значение слота Тип значения
Название события Падение спортивного самолета Строка символов
Начало ЧС 01.12.2000 Дата
Окончание ЧС 01.12.2000 Дата
Название ЧС Авиационнае катастрофы Строка символов
Код ЧС 10152 Строка символов
Масштаб ЧС Местный Строка символов
2. Определение главного, корневого фрейма (раздела) ПрО и его слотов в иерархической структуре фреймов ПрО.
В данном примере фрейм «Журнал ЧС» является корневым фреймом, так как он содержит слоты, составляющие первоначальное описание каждого чрезвычайного происшествия: название, начало, окончание, масштаб, название и код ЧС.
Фреймовая модель ПрО «Чрезвычайные ситуации» показана на рис. 1.
3. Определение бизнес-правил [3], которым подчиняются значения слотов фреймовой модели ПрО.
Бизнес-правило специфицирует операции, допустимые для ЕЯ-значений слотов. Пример, описывающий связь ЕЯ-значений бизнес-правил с соответствующими БОЬ-кодами, показан на рис. 2.
Рис. 1. Фреймовая модель ^O «Чрезвычайные ситуации»
4. Построение реляционной модели БД, соответствующей фреймовой модели ^O, с помощью Sybase PowerDesigner 9.
Пример результатной реляционной модели, соответствующей исходной фреймовой модели (рис. 1), показан на рис. З.
5. Создание тематических представлений (TemaView), соответствующих фреймам ^O на ЕЯ в БД и описание их в Sybase PowerDesigner 9.
TemaView является виртуальной таблицей (View), описывающей соответствующий фрейм фреймовой модели [3].
6. Создание бизнес-правил для атрибутов TemaView, соответствующих слотам ^O на ЕЯ, и описание их в Sybase PowerDesigner 9.
Мате т | Code
Больше ;>
Больше или равно :>=
Равно jin
Всего jSCQUnt
Количество count
Максимум Max
Меньше i<
Меньше или равно -=:=
Минимум і Min
Содержит Hike
Рис. 2. Пример бизнес-правил
Рис. 3. Реляционная модель БД «Чрезвычайные ситуации»
7. Добавление (или удаление) бизнес-правил (БП) в интерфейсе ГПМЗ, позволяющее создавать новые запросы или изменять критерии выбора в уже существующих запросах.
Таким, образом, технологию создания ГПМЗ можно условно разделить на две части. Результатом выполнения этапов первой части (пп. 1-4) являются фреймовая модель ПрО и созданная на ее основе реляционная модель ТБД. Вторая часть предлагаемой технологии (пп. 5-7) позволяет построить интерфейс пользователя для работы с ГПМЗ.
Пункты 1-3 выполняются администратором (разработчиком) совместно с экспер-том-аналитиком - будущим пользователем системы.
Пункты 4-6 выполняются администратором (разработчиком) с помощью CASE-средства.
Пункт 7 может выполняться как администратором, так и ПА.
Работая с интерфейсом ГПМЗ, ПА имеет возможность выполнять следующие функции:
1. Создавать запросы.
2. Редактировать созданные ранее запросы.
3. Выполнять запросы.
4. Сохранять запросы в БД в качестве кнопочных запросов.
5. Сохранять запросы в БД в качестве параметризованных запросов.
6. Осуществлять поиск сохраненного ранее запроса.
7. Отправлять результат запроса в редакторы Word, Excel.
3. Программное обеспечение системы ГПМЗ
Программное обеспечение (ПО) системы ГПМЗ состоит из следующих подсистем:
1. Подсистема хранения данных. Состоит из общей реляционной БД, включающей ТБД и репозиторий метаданных, созданный Sybase PowerDesigner 9. Предназначена для хранения оперативных и исторических данных.
2. Подсистема описания метаданных с помощью Sybase PowerDesigner 9.
3. Подсистема приложений (ПП «Запит»).
Подсистема приложений состоит из двух модулей:
- модуль интерфейса пользователя;
- модуль интерфейса администратора.
бизнес-правил слотам фреймовой модели ПрО;
- запуск БуЬаве PowerDesigner 9;
- запуск БОЬРЬШ.
Структура системы ГПМЗ и функции 1111 «Запит» показаны на рис. 4.
Модуль интерфейса пользователя реализует следующие функции:
- создание запросов;
- выполнение запросов;
- сохранение запроса в БД в качестве кнопочного;
- сохранение запроса в БД в качестве параметрического;
- создание выходных документов в редакторах Word и Excel.
Модуль интерфейса администратора реализует следующие функции:
- присвоение
4. Пример создания и интерфейс пользователя системы ГПМЗ
Создание системы ГПМЗ покажем на примере ПрО «Чрезвычайные ситуации» в СППР кризисного ситуационного центра.
В результате анализа ПрО, описывающей процесс ликвидации чрезвычайных ситуаций, построена фреймовая модель с главным корневым фреймом «Журнал НС» (рис. 1). Согласно фреймовой модели нужно составить семь TemaView:
1. «Журнал ЧС».
2. «Пострадавшие».
3. «Ущерб».
4. «Оперативные группы».
5. «Привлечено личного состава».
6. «Использовано техники».
7. «Выполненные работы».
Исходя из правил наименований и нумерации [3], предложена следующая структура кода названия:
- блок начальных символов состоит из символов «TV»;
- блок нумерации включает цифры 1, 2, 3, 4, 5, 6, 7;
- блок короткого имени содержит тематическое наименование, например, “ГОиЯ-МЛЬ_8ГГ^ІЕ’”, “РОБТКЛГО^ІЕ’^’.
Правило наименований позволяет идентифицировать TemaView на уровне объектов БД, на которых основывается программное приложение, правило нумерации дает возможность построить дерево важности разделов в интерфейсе пользователя.
В соответствии с правилом соединения по иерархической схеме общим ключом, по которому соединяются все TemaView, является первичный ключ ГО_18ГГ центральной таблицы «ЮиКМЛЬ_8ГГ» реляционной БД, входящий в качестве вторичного ключа в таблицы, на основании которых строятся TemaView №°2,...,7. ЕЯ-названия и идентификаторы TemaView представлены в табл. 2.
Таблица 2. Создание TemaView для БД «Чрезвычайные ситуации»
Название TemaView Нач. симв. № Короткое имя Название в БД (полное имя)
«Журнал ЧС» TV 1 “J OURN AL_SIT_VIEW” “TV 1JOURNAL_SIT_VIEW”
«Пострадав- шие» TV 2 “POSTRAJD_VIEW” “TV 2POSTRAJD_VIEW”
«Ущерб» TV 3 “ZB UTKI_VIEW” “TV 3 ZB UTKI_VIEW”
Оперативные группы» TV 4 “SKLAD_OG_VIEW” “TV4SKLAD_OG_VIEW”
«Привлечено личного состава» TV 5 “ZALU_KATOS_VIEW” “TV 5 ZALU_KATOS_VIEW”
«Использовано техники» TV 6 “ZALU_TEXN_VIEW” “TV 6ZALU_TEXN_VIEW”
«Выполненные роботы» TV 7 “VIK_ROB_VIEW” “TV7VIK_ROB_VIEW”
Пример метаописания в PowerDesigner 9 для TemaView TV1 (название в БД “TV1JOURNAL_SIT_VIEW”) показан на рис. 5, где свойство “Name” означает название на ЕЯ (предоставляется пользователю в интерфейсе), свойство “Code” - наименование (код) в БД, соответствующее правилу наименований.
Пример бизнес-правил для_атрибутов TV1 «Журнал НС» приведен в табл. 3.
аблица 3. Назначение бизнес-правил для атрибутов TemaView «Журнал НС»
Атрибут Название бизнес-правила Код бизнес-правила
«Название события», «Название ЧС», «Код ЧС», «Название ВЧ» «Равно», «Не равно», «Содержит» “in”, “not in”, “like”
«Начало ЧС», «Окончание ЧС» Равно», «Больше», «Меньше», «В интервале», «Вне интервала» “in”, “>”, “<”, “between”, “not between”
«Масштаб ЧС», «Место возникновения» «Равно», «Не равно» “in”, “not in”
Extended Attributes
General
Columns
Dependencies
Script
Extended Dependencies
S Q L Q uery
Preview
Permissions
Version Info Notes Rules
Vj V
Name D Expression A
1 ID_JSIT 9 JOURNAL_SIT .JSITJD
2 Название события 9 JOURNAL_SIT JNAME
3 Начало ЧС Ф JOURNAL_SIT .JSIT-DT
-► Окончание ЧС |J£ F JOURNAL_SIT ,JSIT_END
5 Название ЧС W SITUATIONS .SiTUATION_NAME
6 Код ЧС Р SITUATIONS ,SiTUATION_SHIFR
7 Масштаб НС F D_MASH.NAME_MASH
8 Название ВЧ Ф NAME_OBJ.OEIJ_REAL
9 Место возникновения F COATO.NU
Г
Г
Г
Г
Г
ї|*|- >
□ K Скасувати Застосувати
Рис. 5. Oписание TV1 на ЕЯ в Sybase PowerDesigner 9 Oкно интерфейса пользователя ГПМЗ приведено на рис. 6.
Рис. 6. Oxro интерфейса пользователя ГПМЗ
Фреймы и слоты фреймовой модели (которую видит пользователь в окне интерфейса) располагаются в порядке убывания их важности (приоритета). Полученная структура
образует дерево важности разделов ПрО и их терминов с главным разделом в корне, что дает возможность ПА видеть на экране структуру ПрО в привычном для него виде. Выбирая произвольное количество слотов фреймовой модели, предоставленной ГПМЗ, и накладывая определенные условия, ПА может создавать разнообразные, не предусмотренные заранее конкретные запросы.
Приведем пример создания конкретного запроса для БД «Чрезвычайные ситуации».
Требуется определить, сколько автомобилей типа «Камаз» использовалось для ликвидации чрезвычайной ситуации «Наводнение в г. Мукачево и Мукачевском районе».
Для создания этого запроса пользователь в интерфейсе (рис. 6) должен произвести следующие действия:
- выбрать слоты «Название события» из фрейма «Журнал ЧС», «Название вида техники», «Количество единиц» из фрейма «Использовано техники»;
- задать условия и критерий выбора в соответствии с табл. 4.
Таблица 4. Задание значений слотов для запроса ТБД «Чрезвычайные ситуации»
Слот Критерий Значение
«Название события» = «Наводнение в г. Мукачево и Мукачевском районе»
«Название вида техники» like «Камаз»
«Количество единиц» Sum
Пример БОЬ-запроса, автоматически генерируемого 1111 «Запит», приведен на рис. 7, а окно интерфейса с результатом его выполнения - на рис. 8.
Zapros
sail - Select TVlX)URNAL_SIT_VIEW."IDJSIT",TVnOURNAL_SIT_VIEW."Ha3Ba події”,TV6ZALU_TEXN_VIEW."Назва виду
техніки",sum(TV6ZALU_TEXN_VIEW."KinbKOAHHMttb") as "СумаКііїькОдиниць" From TVlJOURNAL_Slf_VIEW,TV6ZALU_TEXN_VIEW Where
mJOURNAL_SIT_VIEW.ID_JSIT = TV6ZAIU_TEXN_VIEW.ID_JSIT(+) and TVlX)URNAL_SIT_VIEW?Ha3ea події" in (Повінь ум. Мукачів
та Мукачівському районі') and TV6ZALU_TEXN_VIEW."Назва виду техніки" in ('KAMA3-5320') group by
TV1 JOURNAl_SIT_VIEW. "IDJSIT", TV1 JOURNAL_SIT_VIEW."Ha3Ba події", TV6ZALU_TEXN_VIEW. "Назва виду техніки” order by
"СумаКількОдиниць"
OK
Рис. 7. Пример автоматически генерируемого SQL-запроса 1.Назва події 2.Назва виду тенЗ.Сумаї
Рис. 8. Пример результата выполнения запроса
Если ПА сохранит этот запрос в БД с признаком «Кнопочный» (задание значений слотов соответствует табл. 4), то результатом его выполнения будет окно интерфейса с данными (рис. 8), а если запрос будет сохранен с признаком «Параметрический», то в результате его выполнения на экран будет выдано окно задания значений параметров, содержащее два параметра: «Название события», «Название вида техники», со значениями, введенными при сохранении запроса (табл. 5). ПА может задать другие значения предлагаемых параметров или оставить прежние, а затем дать команду на выполнение запроса. Если ПА оставляет прежние значения параметров, то результатом выполнения запроса будет прежнее окно (рис. 8).
Таблица 5. Задание значений слотов для параметрического запроса ТБД «Чрезвычайные ситуации»
Слот
Критерий
Значение
«Название
события»
«Наводнение в г. Мукачево и Мукачевском районе» Назва поди
Зсув грунту
Падіння спортивного літака
Наводнение в г. Мукачево и Мукачевском районе
__| Пожежа на складі
«Название вида техники»
like
«Камаз»
Назва виду техніки
БКТ
БУЛЬДОЗЕРИ ТАНКОВІ
ГАЗ-66, ГАЗ-66Б
ЗИЛ-131
ЗИЛ-157
ИМР-2
KAMA3-4310jKAMA3-43101
KAMA3-5320
КАМАЗ-53212
КРАНОВІ САМОНАВАНТАЖУВАЧІ
«Количество
единиц»
Sum
5. Заключение
Интерфейс пользователя, создаваемый на основе описанной технологии и инструментария, дает возможность эксперту-аналитику ИАС самостоятельно формировать запросы и получать требуемую информацию относительно ПрО, для которой предварительно построена соответствующая фреймовая модель. Создание такой модели, «накрывающей» наибольшее количество потенциальных запросов, является пока чисто творческим этапом, и его удачная реализация во многом зависит от квалификации, опыта и даже интуиции как администратора (разработчика), так и эксперта - аналитика, будущего пользователя системы. Задача формализации этого этапа является достаточно сложной и нуждается в отдельных исследованиях.
СПИСОК ЛИТЕРАТУРЫ
1. Юрасов В. А. Постановка проблемы разработки научно обоснованной концепции, алгоритмов работы и архитектуры инструментальных средств электронного правительства [Электронный ресурс] / В. А. Юрасов. - Режим доступа: Нііп://с-соііігпсгсс.^аіі.ги/сопіспі/оіНсг/?ІГ)=834.
2 Волков И. Архитектура современной информационно-аналитической системы [Электронный ресурс] / И. Волков, И. Галахов // Директор ИС. - 2002. - № 3. - Режим доступа: Ийр://сііїЬщт.щ/сощиМпа/БІ/іа8.
3. Оксанич И.Н. Квазипроизвольные запросы к базам данных и информационная модель их реализации / И.Н. Оксанич // Математичні машини і системи. - 2010. - № 3. - С. 45 - 52.
Стаття надійшла до редакції 31.10.2011