Каталог объектов

Таблица связей

Факты

Используемые классификаторы

Рисунок 1 – Схема четвертой нормально формы многомерных данных

В этой форме за атомарную единицу хранения принимается отдельное значение параметра, атрибуты метаданных выносятся в отдельную таблицу - каталог экземпляров объектов, а изменяющиеся значения в пространстве и во времени – в базу фактов. А хранение данных будет в структуре «идентификатор экземпляра объекта, имя свойства, значение свойства». Такая структура получается очень гибкой, позволяет добавить каждому экземпляру объекта новое, только ему принадлежащее свойство.

Каталоги могут включать справочные сведения о различных объектах. Так как каталоги конкретных объектов очень сильно отличаются по составу свойств, то для хранения таких каталогов эффективнее применять многомерную модель хранения данных.

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

Классификаторы оформляются в соответствии с первой нормальной формой для многомерных данных.

Такое представление данных по существу представляет универсальную модель хранения данных (УМД), т.к. структура данных для всех объектов мира одинаковая. Для работы с такой моделью необходимо все простые классификаторы (код, значение) хранить в одном классификаторе. Полные сведения о всех свойствах объектах – это отдельный объект, включающий уникальный идентификатор, код параметра, процесса (явления), имя статистической характеристики, временной, пространственный масштабы, полное и краткое наименование параметра на русском и английском языках, точность наблюдений или рекомендуемая точность расчета, единицы измерения, диапазон изменчивости (мин, мах значения), уравнение для вычисляемых значений, вертикальное разрешение (мин и макс высота/глубина), имя используемого классификатора для хранения отдельных свойств, метод определения свойства, международный код, описание свойства. Сведения о свойствах объекта являются отдельным объектом УМД.

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

При работе с УМД пользователь должен видеть только плоские таблицы, а соответствующий конвертор должен преобразовывать плоские таблицы в УМД и обратно.

Универсальная схема БД, предложенная для СУБД Oracle включает, следующие таблицы [16]:

- Схема (идентификатор схемы, имя схемы, комментарии);

- Таблица (идентификатор схемы, идентификатор таблицы, имя таблицы, комментарии);

- Столбец (идентификатор схемы, идентификатор таблицы, имя столбца, тип данных, значение по умолчанию, длина, точность, комментарии);

- Данные (идентификатор схемы, идентификатор таблицы, идентификатор столбца, номер строки, значение, комментарии).

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

Рисунок 2 - Универсальная схема [16]

При формировании запроса можно пользоваться только одной таблицей «Данные». Главный недостаток такой универсальной схемы - большое число соединений даже для выполнения тривиальных запросов. Еще одним недостатком является то, что такая схема привязана к одной СУБД Oracle. Хотя похожие схемы можно создать и для других СУБД.

В УМД фирмы Treelogy (http://www.treelogy.ru/cd/42) разработчик оперирует практически с единственной таблицей «Перемещение объектов». Навигация по этой таблице очень проста и понятна, так как она представлена в виде дерева (перемещения связаны между собой полями «Откуда» и «Куда» - узлами дерева), отражающего структуру предприятия и его окружения в виде банков, контрагентов, партнёров и т.д., которое строит сам пользователь. Выглядит это аналогично проводнику Windows, только справа не файлы, а таблица перемещений выбранного в дереве узла. Узлы дерева называются Объектами. Объектами могут быть фирмы, их подразделения, товары, деньги, сотрудники. Все объекты равноправны. Объекты имеют вложенную структуру, то есть одни объекты можно вмещать в другие (так и образуется дерево).

Деятельность предприятия рассматривается, как совокупность перемещений рассматриваемых объектов. Каждое перемещение сопровождается произвольным по количеству набором характеристик. По сути, перемещение - это "элементарный" бизнес-процесс. Объект может изменять свои координаты в пространстве, изменяться количественно и качественно.

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

• Дата/Время - фиксирует время произошедших изменений;

• Что, Откуда, Куда - фиксируют изменение положения в пространстве объектов (просто выбираем в дереве, что и откуда перемещается, а затем куда);

• Количество - количественные изменения;

• Дополнительные поля (качественные изменения) произвольные характеристики, создаваемые самим пользователем.

В Treelogy перемещения связаны в цепочки (с возможными ветвлениями). Это позволяет отслеживать всю историю перемещений любого объекта со всеми изменениями характеристик.

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

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

Язык JSON (JavaScript Object Notation) стал активно развиваться только в последние годы. Хотя еще в семидесятых годах подобный подход применялся для хранения документально-фактографической информации. Язык JSON основан на принципе хранения данных в форме «ключевое слово: значение». В работе [23] применена реляционная алгебра классической реляционной схемы к формату JSON и доказано, что этот формат описывается математически эквивалентным аппаратом. JSON предоставляет простой способ форматирования данных, например, описать контактную информацию можно следующим образом:

{

"contacts" : {

"contact" : {

"@attributes" : {

"id" : "1"

},

"name" : "Евгений Вязилов",

"phone" : "+7 48439 74676",

"address" : {

"street" : "6, Королева",

"city" : "Обнинск",

"state" : "Россия",

"zipCode" : "249035"

} } } }

На основе формата JSON и применения триплов выпускником кафедры КССТ ИАТЕ НИЯУ МИФИ М.Кабановым разработана универсальная модель представления данных, рис.3. Эта модель отталкивается от основных структурных единиц схемы БД: объект, экземпляр объекта, свойства объекта. Для каждой структурной единицы схемы БД предлагается создать свою таблицу, представленную в виде трипла. При этом главная структурная единица схемы – объект имеет ссылку на соответствующие экземпляры объекта. А каждый экземпляр объекта ссылается на таблицу, содержащую свойства конкретных экземпляров объекта. При этом каждая таблица имеет индекс, который хранится не в БД, а в системных файлах.

Объекты Экземпляры объекта Свойства объекта Индекс

ID_o	Name	Value		ID_экз	Name	Value		ID_св	Name	Value		rowID	rowID
1	#Class	1		1	E1	1		1	Atr1	a		1	1
2		3		1	E2	2		2	Atr2	b		2	2
…	…	…		1	E3	4		4	Atr3	c		3	4
N				3	E1	18		18	Atr1	d		4	18
				3	E2	23		23	Atr2	e		5	23
				3	E3	50		50	Atr3	f		6	50
				…	…	…		180	Atr1	g		7	180
				N				…	…	…		…	…
								N				N	N

Рисунок 3 – Схема УМД на основе отдельного хранения сведений о структурных единицах БД

Сенсорные сети

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

• мониторинг и управление работой всех сенсоров;

• анализа входной информации от сенсоров и поддержка решений;

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

• управление процессом измерений, обработки и передачи полученных данных в центр сбора;

• интеграция данных от различных сенсоров, выдающих разные показатели;

• поддержка метаданных о сенсорах и измеряемых ими параметрах;

• сбор и анализ информации, определяющий состояние сенсоров и условия их работы.

Требования к такой системе включают:

• использование единой схемы метаданных для описания приборов, датчиков и всей сенсорной сети;

• применение универсальной модели хранения данных, позволяющей усваивать данные от всех сенсоров в одной БД;

• автоматическая идентификация оборудования в системе;

• универсальный формат для передачи данных на базе языка XML по каналам связи;

• совместимость с существующим оборудованием;

• независимость от каналов, интерфейсов и открытых протоколов передачи данных;

• упрощение работ по изменению и перемещению датчиков;

• дистанционное управление сетью расположения датчиков без вмешательства эксплуатационного персонала.

Вся сенсорная сеть представляется как огромная распределенная БД, каждый узел которой (сенсор) хранит крохотный объем данных, который сенсор отдает в соответствии с регламентом передачи данных. При необходимости перейти на другой режим передачи данных посылается запрос в систему.

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

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

При создании крупных ИИС, включающих сотни, тысячи и более датчиков, сенсоров, измеряющих различные параметры среды, с разной дискретностью, возникает проблема хранения полученных данных в одной БД – либо создавать множество таблиц, либо терять пространство памяти на отсутствующие в данный момент измерения отдельных параметров. В настоящее время структуры данных разрабатываются для каждого прибора (измерительного комплекса) отдельно. Такой подход требует переработки программного обеспечения при удалении, добавлении нового датчика. Интеграция ИИС усложняется, потому что нет типовой структуры данных. Если данные хранить в универсальной модели данных (УМД), а все ИИС будут представлять информацию в этой модели данных, то интеграция таких систем существенно упростится. Структура данных в УМД для решения этой задачи будет выглядеть с.о.:

• таблица «Каталог» (сведения о датчиках, сенсорах, их производителях, др.);

• таблица «Факты», включающая идентификатор датчика, идентификатор экземпляра, дату и время измерения, координаты места для движущихся измерительных платформ (для стационарных платформ координаты могут храниться в таблице «Каталог»), идентификатор атрибута, значение атрибута;

• таблица «Классификаторы» (коды приборов, платформ, организаций, стран и т.п.);

• таблица связей (идентификаторы датчика, платформы и атрибутов таблиц «Факты», «Каталог» и классификаторы).

Технологией, обеспечивающей взаимодействие сенсоров с БД, является язык XML, который обеспечивает обмен данными вне зависимости от аппаратных и программных платформ. Внедрение стандартов на объединение, управление, взаимодействие и использование данных, собранных от различных датчиков, использование XML технологий позволит значительно увеличить как масштабируемость таких средств, так и упростить их настройку. Этому способствовало появление стандартов Sensor Model Language (SensorML, http://vast.uah.edu/SensorML/) и Transducer Markup Language (TML).

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

Технологии обслуживания нового поколения

Основными проблемами современных БД являются наличие неполной или противоречивой информации; отсутствие средств повышения достоверности информации; схем обработки информации и получения соответствующих целевых показателей. БД пока не всегда эффективны, уязвимы и слишком дороги. Автоматические системы сбора сведений требуют применения эффективных аналитических средств, консолидации данных.

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

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

Недостатками обслуживания пользователей являются:

• информация не обменивается в автоматическом режиме между ведомственными системами;

• системы выдают большой объем информации, из-за этого пользователи не в состоянии с достаточной быстротой реагировать на постоянные изменения свойств объектов;

• отсутствуют автоматизированные средства индикации отклонений показателей оценки состояния среды и бизнес-процессов;

• наблюдается несоответствие состава ресурсов и возможностей характеру и масштабам решаемых задач, а также информационным потребностям пользователей;

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

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

Интегрированные информационные ресурсы

Метаданные

Наблюдения

Диагноз

Прогноз

Обобщения

Данные

Знания

, ppt

html, ppt

Формы представления

html, ppt

html, ppt

АРМы

Агенты

Мобильные средства

ЛПР

Ученые, эксперты

ЛПР

Рисунок 4 - Схема развития информационного обслуживания

Технология информационного обслуживания включает:

• автоматизированные рабочие места пользователей, настраивающиеся по составу компонент в зависимости от потребностей пользователей;

• мобильные Интернет-средства с использованием беспроводных каналов – ноутбуки, нетбуки, коммуникаторы, смартфоны;

• программные агенты на компьютере пользователя, которые автоматически запускаются при выявлении аномалий состояния среды;

• интерактивные киоски с сенсорным экраном, работающие постоянно и в любой момент готовые к выдаче информации (например, аудиовоспроизведение прогноза погоды);

• различные средства коммуникаций (ICQ, SMS, MMS, e-mail, Skype).

Состав сервисов должен включать:

• интерактивную карту о географическом положении объекта и его состоянии;

• таблицы, отражающие состояния объектов;

• бегущую строку с новостями;

• доступ к метаданным;

• доступ к данным;

• доступ к классификаторам;

• доступ к сопутствующей информации (документам);

• визуализацию таблиц, графиков;

• сервисы прикладной обработки;

• мониторинг измерительных сетей.

Информация пользователям представляется в виде метаданных, данных и знаний. Каждый тип информации требует разработки дополнительных функций. Основными функциями для работы с метаданными являются:

• получение сведений о данных по различным объектам метаданных (сведения о технологиях; массивах и БД; информационных ресурсах, источниках информации, логических единицах данных);

• агрегация сведений о метаданных по различным атрибутам (географическим районам, платформам, проектам, др.);

• навигация по метаданным (по различным объектам метаданных) с целью выхода на конкретный экземпляр данных;

• проведение мониторинга новостных сайтов;

• генерирование новостных и аналитических дайджестов, формализованных отчетов;

• подписка на получение готовой информации в виде стандартных форм представления результатов обработки данных (таблицы, графики, карты, анализы, прогнозы, др.) на основе синдикации за счет использования протокола RSS.

Для работы с данными используются следующие функции:

• визуализация информации в виде таблиц, документов, объектов или событий и их привязка к карте;

• вычисление производных характеристик;

• вычисление статистических (агрегированных) характеристик;

• поиск данных в информационных ресурсах по форме и образцу (последние данные и т.п.);

• динамическая генерация пользователем новых нерегламентированных форм;

• полнотекстовый и параметрический поиск в информационных ресурсах;

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

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

• получить сведения о воздействиях среды на объекты и рекомендации для принятия решений при различных значениях состояния объекта и среды или неблагоприятных прогнозов тенденций развития природных процессов;

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

Выводы

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

Тенденции развития БД сводятся к интеграции данных и приложений, работающих с этими данными, широкому использованию этих данных для поддержки решений в различных областях экономической деятельности. Новая волна развития в использовании БД связана с применением современных технологий - web–сервисов, программного обеспечения как сервис - SaaS, унифицированных коммуникаций, защиты данных, контроля доступа к сетям, виртуализации, облачных технологий. Будущие изменения будут вызваны подключением к БД многочисленных физических объектов (различных сенсоров, датчиков, ИИС и т.п.), которые будут иметь IP-адрес.

СУБД третьего поколения должны:

• обеспечить поддержку многомерных структур данных и включать правила, как часть БД;

• быть открытыми для интеграции с другими системами;

• работать с языками четвертого поколения, разнообразными инструментами поддержки принятия решений, дружественным доступом из многих языков программирования, с графическими картографическими интерфейсами;

• позволять запускать приложения с других машин, в т.ч. в распределенной среде;

• эффективно функционировать на разнообразных аппаратных платформах с различными ОС;

• включать возможности обработки различных типов данных (массив, список, последовательность – временной ряд, траектория, точка, профиль, сетка, временной ряд профилей, временной ряд в узле сетки).

Реализацию этих тенденций стимулируют технологические инновации, в числе которых появление многоядерных архитектур, резкое снижение стоимости дисковой и оперативной памяти, широкое распространение твердотельных (SSD) и флэш-накопителей, увеличение пропускной способности сетевых соединений (в том числе беспроводных), рост популярности мобильных устройств и т.д. Сегодня данные находятся в географически распределенных системах, а требования к скорости доступа к ним постоянно ужесточаются. Аналитическая обработка все чаще выполняется в реальном времени. Появляется потребность в высокоскоростной потоковой обработке данных, которые загружаются в БД. Такие задачи возникают при мониторинге инфраструктуры системы, управлении сенсорами и т.д. Все это позволяет виртуализировать ресурсы БД и гибко маневрировать ими как с целью повышения отказоустойчивости, так и для балансировки нагрузки.

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

Для крупных БД необходимо создавать подсистемы:

• каталогизации, позволяющие получать достоверные непротиворечивые и исчерпывающие сведения о наличии данных, установленном программном обеспечении;

• мониторинга, непрерывно отслеживающие инфраструктуру БД (аппаратуру, каналы связи, работу ОС, прикладного программного обеспечения, параметры производительности);

• управления ИТ-услугами, обеспечивающие автоматизацию при приеме заявок на обслуживание; создание и дальнейшее развитие каталога сервисов и соглашений об уровнях обслуживания; управление сервисной деятельностью, включая управления активами, контрактами, персоналом и работами; настройку бизнес-процессов обслуживания; предоставление механизмов контроля.

Рекомендации, которые помогут повысить уровень эффективности БД:

• определите ключевые показатели эффективности использования БД (метрики), измеряйте их и используйте их для достижения целей компании;

• создайте группу содействия развертыванию БД, которая поможет интеграторам и консультантам лучше понять потребности заказчика и развернуть БД быстрее и согласованней;

• проведите мониторинг используемой функциональности (набор имеющихся возможностей БД для компаний обычно избыточен, нужно знать, как часто применяются пользователями различные функции);

• проводите тренинги для пользователей и поставщиков информации;

• постоянно изучайте информационные потребности пользователей;

• пересматривайте стоимость лицензий на программное обеспечение БД;

• создавайте базы метаданных и средства работы с ними;

• виртуализируйте сервера, диски, приложения и данные;

• более широко используйте облачные технологии;

• формируйте стратегии по обработке, интеграции и анализу больших объемов данных;

• внедряйте новые средства хранения и сопровождения данных.

Список литературы