1.3База данных распределенной адаптивной системы административного мониторинга
Учитывая сложность системы административного мониторинга и наличие достаточно обособленных подсистем, рассмотрим базовые составные блоки базы данных в отдельности.
1.3.1Ядро базы данных экспериментального образца системы
Логическая модель ядра базы данных экспериментального образца системы административного мониторинга представлена на рисунке 1.9.
Ядро базы данных хранит следующую информацию:
– типы объектов учета, объекты учета, показатели, значения показателей и их ассоциативные и иерархические связи;
– данные о статических и генерируемых интерфейсах системы мониторинга;
– данные о пользователях системы, их правах доступа к интерфейсам, объектам учета, показателям.
Рассмотрим более детально назначение и состав основных таблиц ядра базы данных.
Таблица object_type.
Обеспечивает хранение перечня типов объектов учета.
Поля:
id – первичный ключ;
title – название типа объекта учета;
hierarchy_number – зарезервированное поле, обеспечивает возможность хранения в базе данных нескольких иерархий (сетей) типов объектов учета для одновременной поддержки различных задач административного мониторинга.
Рисунок 1.9 – Логическая модель ядра базы данных системы мониторинга
Таблица type_hierarchy.
Хранит иерархию типов объектов учета.
Поля:
id_type – часть составного первичного ключа, тип-родитель;
id_child_type – часть составного первичного ключа, тип-потомок.
Таблица stock_object
Обеспечивает низкоуровневое хранилище экземпляров объектов учета всех возможных типов.
Поля:
id – первичный ключ;
title – название экземпляра;
id_type – внешний ключ типа экземпляра, связь с таблицей object_type.
Таблица рroperties.
Обеспечивает хранение показателей объектов учета. Объекты учета обладают свойствами – показателями. Показатели классифицируются на мониторинговые – показатели, значения которых вводятся и хранятся в ходе проведения административного мониторинга, и служебные – служащие для организации структур верхнего уровня системы хранения – хранения логической модели данных поверх инвариантной физической. Для их хранения используется унифицированная структура таблицы properties.
Поля:
id – первичный ключ;
title – название показателя;
data_type – тип данных значения показателя, например: строковый, числовой, множество;
common_property – признак, говорящий о том, что показатель не изменяется периодически или не требует мониторинга изменений;
active_counting – признак, определяющий нужно ли проводить мониторинг по данному показателю или временно его не проводить;
edit_size – размер поля редактирования показателя на интерфейсе, в символах;
form_element – элемент формы на интерфейсе, предназначенной для ввода данного показателя, например: input, area, select;
unit_of_measure – единица измерения показателя;
duration – длительность периода учета (количество единиц периода учета);
duration_unit – единица измерения периода учета, например: день, месяц, год.
Таблица property_value.
Хранит значения показателей. Значения показателей классифицируются на атомарные (способные быть выраженными простым типом данных) и составные (выражающиеся набором атомарных значений (кортежем)). Хранение значений показателей двух этих видов отличается. Атомарное значение показателя храниться в единственном поле value таблицы property_value. Составное свойство храниться в кортеже некоторой таблицы. Ссылка на эту таблицу храниться в таблице object_link.
Поля:
id – первичный ключ;
id_property – внешний ключ показателя, связь с таблицей рroperties;
id_object – внешний ключ экземпляра объекта учета, связь с таблицей stock_object;
value – значение показателя (в случае атомарного показателя), либо значение ключа, определяющего кортеж составного значения показателя; таблицу, значение ключа которой находится в поле value, можно определить по соответствующей записи таблицы object_link;
start_date – дата начала мониторинга для циклических показателей. Начиная с этой даты отсчитываются периоды учета, указанные в duration и duration_unit таблицы рroperties. Например, может быть сохранена следующая информация: «мониторинг данного показателя ведется каждые 5 (duration) дней (duration_unit), начиная с 15.03.2012 (start_date)»
Таблица object_link.
Определяет связь с таблицей, хранящей значение составного показателя. Составное значение показателей представляет собой набор полей атомарного типа данных. Для его хранения рационально использовать отдельную таблицу.
Поля:
id – первичный ключ
id_type – внешний ключ типа объекта учета, ассоциированного с данным показателем, связь с таблицей object_type;
id_property – внешний ключ показателя, связь с таблицей рroperties
table_name – имя таблицы, в которой хранится кортеж с составным значением показателя
field_name – имя поля таблицы в которой хранится кортеж с составным значением показателя.
Значение ключа, указанного в field_name в таблице table_name храниться в таблице property_value.
Рассмотрим пример хранения составного значения показателя. При проведении мониторинга НИОКР университета одним из объектов учета является монография, которая имеет составной показатель «издательство». Запись издательства может иметь множество полей: название, город, префикс ISBN, и др. Мониторинг деятельности издательств не ведется, поэтому нецелесообразно включать издательство в иерархию объектов учета. Поэтому данные издательства хранятся в отдельной таблице «издательство».
Таблица stock_object содержит запись:
id =1;
title = монография №1;
id_type = id типа «монография».
Таблица property_value содержит запись:
id =2;
id_property = id показателя «издательство»;
id_object = 1;
value = «ABBY Press».
…
Таблица object_link содержит запись:
id =3;
id_type = id типа «монография»;
id_property = id показателя «издательство»;
table_name = «издательство»;
field_name = «название».
Таблица издательство содержит запись:
название = «ABBY Press»;
город = «Москва»;
префикс = 5-91103.
Таблица stock_object.
Для хранения иерархии экземпляров объектов учета можно воспользоваться предложенной выше технологией хранения составного значения показателя. Экземпляр объекта учета имеет показатель «предок в иерархии», значение которого представляет собой кортеж данных предка. Данный кортеж храниться в таблице stock_object, поэтому необходимо указать его местоположение через таблицу object_link.
Пример хранения предка экземпляра объекта учета:
Таблица stock_object содержит 2 записи:
id =1;
title = монография №1;
id_type = id типа «монография»;
id =2;
title = Иванов;
id_type = id типа «сотрудник».
Таблица property_value содержит запись:
id =3;
id_property = id показателя «предок в иерархии»;
id_object = 1;
value = 2.
Таблица object_link содержит запись:
id =4;
id_type = id типа «монография»;
id_property = id показателя «предок в иерархии»;
table_name = object_link;
field_name = id;
Таблица possible_property_value.
Данная таблица предназначена для хранения возможных значений атомарных показателей, заполняющихся из определенного списка, то есть заранее определенного множества значения.
Поля:
id – первичный ключ;
id_property – внешний ключ показателя, связь с таблицей рroperties;
title – название возможного значения показателя.
1.3.2Блок хранения данных подсистемы импорта
Для импорта данных в систему административного мониторинга из внешней системы ей сначала необходимо указать, какие именно данные требуется импортировать. Для этого в подсистеме импорта данных формируется шаблон импортируемых данных. Он содержит информацию о типах объектов и показателях, которые необходимо импортировать. Для периодических показателей задаётся дата, с которой начинает учитываться данный показатель. Кроме того в шаблоне импортируемых данных указывается период за который осуществляется импорт. Также в шаблоне указывается информация для подключения к внешней системе. В общем случае это web-адрес модуля, который отвечает за приём передаваемого шаблона импорта, его обработку и передачу необходимой информации.
Для хранения шаблона импорта и связанных с ним данных будут использоваться три таблицы. Для хранения самого шаблона – таблица Import_template.
Поля:
id – первичный ключ;
name – наименование шаблона импорта;
last_date – дата проведения последней процедуры импорта с использованием этого шаблона;
duration – период импорта;
dur_unit – единица измерения периода;
url – адрес, по которому будет осуществляться подключение к внешней системе;
active – флаг, показывающий активность задачи.
Данная таблица на логическом уровне будет связана с таблицами object_type и property с помощью связи многие ко многим. На физическом уровне эти связи реализуются с помощью введения двух ассоциативных таблиц: Import_property и Import_type.
Таблица Import_type связывает между собой таблицы Import_template и Object_type.
Поля:
id_template – идентификатор шаблона импорта;
id_type – идентификатор типа объекта.
Таблица Import_property связывает между собой таблицы Import_template и Property.
Поля:
id_template – идентификатор шаблона импорта;
id_property – идентификатор показателя;
start_date – дата, на которую вводится первое значение показателя, если до этого не было значений данного показателя.
Графическое представление перечисленных выше таблиц и их связей приведено на рисунке 1.10.
Рисунок 1.10 – Группа таблиц базы данных, отвечающих за хранение данных подсистемы импорта
1.3.1Блок хранения данных подсистемы генерации выходных отчетных форм
По результатам исследований четвертого этапа НИР было заключено, что шаблоны отчетов должны храниться в виде структурированных текстовых файлов в файловом хранилище. Настройки стилей визуализации для структур шаблонов отчетов в таблице rendering_styles, в которой присутствует ссылка на файл с шаблоном отчета. Поля таблицы:
id – первичный ключ, номер шаблона отчетной формы;
report_template – ссылка на файл шаблона отчета;
output_properties – индикатор необходимости вывода показателей экземпляра объекта учета;
rule_hierarchy – правило визуализации иерархии экземпляров объектов учета (будет заполнено в том случае, если не выводятся показатели экземпляра объекта учета);
rule_conversion – правило преобразования данных экземпляра объекта учета (будет заполнено в том случае, если выводятся показатели экземпляра объекта учета);
rule_combine – объединения представлений данных экземпляров объектов учета (будет заполнено в том случае, если выводятся показатели экземпляра объекта учета);
rule_processing – правила визуализации результатов функций обработки данных (будет заполнено в том случае, если выводятся показатели экземпляра объекта учета).
Связи шаблонов отчетных форм с результатами генерации осуществляется с помощью таблицы results_generated, в которой также будет храниться период выборки данных для каждого отчета. Поля таблицы:
id – первичный ключ, номер выходного отчета;
rendering_styles_id – внешний ключ, номер шаблона отчетной формы, связь с таблицей rendering_styles;
output_report – ссылка на файл выходного отчета;
sample_period – период выборки данных отчета.
Логическая модель фрагмента базы данных подсистемы генерации выходных отчетных форм представлена на рисунке 1.11.
Рисунок 1.11 – Группа таблицы базы данных, обеспечивающая хранение данных подсистемы генерации выходных отчетных форм
1.3.2Блок хранения данных подсистемы анализа и контроля данных
В базе данных необходимо хранить правила и критерии анализа и контроля данных, настройки общей модели задач анализа и контроля данных, а так же результаты решения задач анализа и контроля данных. Хранение результатов имеет смысл ввиду возможной высокой временной сложности процедуры обработки данных и высокой вероятности реализации сценария работы с системой, при котором аналитик получив некоторый результат анализа или контроля данных, исследует другие параметры объекта мониторинга, а затем возвращается к первому результату. Для минимизации избыточности по данным результаты необходимо хранить лишь определенное время, задаваемое при настройке системы, например, до наступления следующего периода учета по рассматриваемому показателю.
Каждая задача анализа и контроля данных может иметь лишь одно правило или критерий анализа или контроля данных. Для каждого правила или критерия анализа и контроля данных может храниться несколько результатов решения задачи анализа и/или контроля данных.
Для хранения настроек общей задачи анализа и контроля данных используются две таблицы. Одной из них является таблица task. Ее поля:
id – первичный ключ;
rules_criteria_id – внешний ключ для выбора правила анализа или критерия контроля данных, связь с таблицей rules_criteria;
title – название задачи, отражающее цель ее создания;
run_mode – признак, определяющий режим запуска задачи (по расписанию или вручную);
data_request – признак, отражающий способ получения исходных данных для анализа и/или контроля: выборка из базы данных, данные отчетов, данные анализа данных;
period_of_data – период выборки данных (используется по умолчанию в случае запуска по расписанию; при запуске вручную может быть изменен);
output_interface – связь с выходным интерфейсом (идентификатор диалогового интерфейса вывода данных, при обращении к которому осуществляется решение задачи (при ручном режиме) и/или отображение результатов).
Если задача запускается по расписанию, то время ее запуска хранится в таблице schedule. Поля таблицы:
id – первичный ключ;
task_id – внешний ключ, связь с таблицей task;
time – время запуска задачи.
Для хранения правил и критериев анализа и контроля данных используются пять таблиц. Таблица rules_criteria хранит номера всех правил и критериев анализа и контроля данных. Используется для того, чтобы обеспечить возможность настройки правил анализа и критериев контроля данных независимо от настройки общей задачи анализа и контроля данных. И через нее происходит связь таблицы task с оставшимися четырьмя таблицами, которые хранят сами правила анализа и критерии контроля данных.
Поля таблицы rules_criteria:
id – первичный ключ;
title – название правила анализа или критерия контроля данных;
type – признак, показывающий к какой аналитической задачи относится правило анализа данных или какой критерий контроля используется (четкий или нечеткий, контроль выбросов или среднего арифметического и т.д.).
Для хранения правил анализа для задачи классификации используется таблица classification. Ее поля:
id_rules_criteria – первичный ключ, также является первичным ключом таблицы rules_criteria (создание правила анализа для задачи классификации возможно только после создания записи в таблице rules_criteria);
object_type_id – внешний ключ, тип объектов учета среди которых идет классификация, связь с таблицей object_type;
set_of_properties – набор независимых показателей, на основании которых будет определяться класс объекта учета;
class – множество значений зависимого показателя (классов объектов учета);
training_set – обучающая выборка, представляющая собой матрицу, в строках которой находятся значения независимых показателей и соответствующее значение зависимого показателя (класса).
Для хранения правил двух других задач анализа данных – прогнозирования и кластеризации используются таблица clastering и таблица prediction соответственно.
Поля таблицы clastering:
id_rules_criteria – первичный ключ, также является первичным ключом таблицы rules_criteria (создание правила анализа для задачи кластеризации возможно только после создания записи в таблице rules_criteria).
object_type_id – внешний ключ, тип объектов учета, которые разбиваются на кластеры, связь с таблицей object_type;
set_of_properties – набор независимых показателей, на основании которых будет осуществляться разбиение;
objects – входное множество объектов учета;
metric – метрика расстояний.
Поля таблицы prediction:
id_rules_criteria – первичный ключ, также является первичным ключом таблицы rules_criteria (создание правила анализа для задачи прогнозирования возможно только после создания записи в таблице rules_criteria).
stock_object_id – внешний ключ, экземпляр объекта учета, имеющий показатель для которого будут определяться прогнозные значения, связь с таблицей stock_object;
property_id – показатель для которого будут определяться прогнозные значения, связь с таблицей property;
properties_values – множество значений периодического показателя, на основании которых рассчитывается прогноз;
number – количество периодов, на которое необходимо сделать прогноз.
Для хранения критериев контроля данных используется таблица control. Тип критерия контроля хранится в таблице rules_criteria.
Поля:
id_rules_criteria – первичный ключ, также является первичным ключом таблицы rules_criteria (создание критерия контроля возможно только после создания записи в таблице rules_criteria);
object_type_id – внешний ключ, тип объектов учета, среди которых будет происходить контроль, связь с таблицей object_type;
property_id – показатель, принадлежащий типу object_type_id, по которому будет происходить контроль, связь с таблицей property;
allowable_values – допустимые значения для показателя property_id в зависимости от типа критерия контроля;
membership_function – функция принадлежности (хранится только для нечетких критериев контроля).
Для хранения результатов решения задач анализа и контроля данных используются четыре таблицы. Таблица result_classification используется для хранения результатов решения задачи классификации.
Поля таблицы result_classification:
id – первичный ключ;
classification_id_rules_criteria – внешний ключ, идентифицирующий правило анализа, для которого храниться решение задачи классификации, связь с таблицей classification;
vector – множество (вектор) весов независимых показателей;
object_class – множество классифицированных объектов учета;
date – дата и время решения задачи классификации.
Таблица result_clustering используется для хранения результатов решения задачи кластеризации. Поля таблицы:
id – первичный ключ;
clustering _id_rules_criteria – внешний ключ, показывающий, для какого правила анализа хранится решение задачи кластеризации, связь с таблицей clustering;
center_cluster – множество центров кластеров;
matrix – матрица разбиения по кластерам;
date – дата и время решения задачи кластеризации.
Таблица result_prediction используется для хранения результатов решения задачи кластеризации. Поля таблицы:
id – первичный ключ;
prediction_id_rules_criteria – внешний ключ, показывающий для какого правила анализа хранится решение задачи прогнозирования, связь с таблицей prediction;
future_values – множество прогнозируемых значений;
date – дата и время решения задачи прогнозирования.
Таблица result_control используется для хранения результатов решения задачи контроля данных. Поля таблицы:
id – первичный ключ;
control_id_rules_criteria – внешний ключ, показывающий для какого критерия контроля хранится решение задачи контроля данных, связь с таблицей control;
sets_of_objects – множество, состоящее из подмножеств, соответствующих выделенным в функции принадлежности поддиапазонам, и одного или более подмножеств, соответствующих значениям, не вошедшим в диапазон;
date – дата и время решения задачи прогнозирования.
Логическая модель фрагмента базы данных подсистемы анализа и контроля данных представлена на рисунке 1.12. Незавершенные связи направлены к соответствующим (упомянутым выше) таблицам ядра базы данных, модель которой была представлена на рисунке 1.9.
|
