CC BY
22
(BecmHu-KjBcpyWïït, №3, 2013
УДК 681.514.015
Профессор С.Т. Антипов, доцент А.Н. Рязанов
(Воронеж: гос. ун-т. инж технш.) кафедрамашин а и аппаратовпищевых производств, тег. (473) 255-38-96 доцент А.Л. Ивашин
(Воронеж. гос. ун-т. ннж. технш.) кафедра информационных технологий моделирования и управле-ниятсл. (473) 255-25-50 аспирант Д.Ю. Уразов
(Воронеж. гос. ун-т. инж. технш.) кафедра промышленной энергетики, тел. (473) 255-44-66
Проектирование физической и логической моделей универсальной системы тепловизионной диагностики
Разработка физической и логической моделей универсальной системы тепловизион-ной диагностики. Описание сущностей и конкретных требований, предъявляемых к системе управления базами данных со стороны программного комплекса.
Development of physical and logical models of the universal system of thermal imaging. Description of the entities and specific requirements to the database management system by the software complex.
Ключевые слова: тепловизионная диагностика, база данных, архитектура программной системы.
Назначением разрабатываемой системы тепловизионной диагностики является осуществление процесса для удаленного сбора данных о температурном режиме энергетического оборудования пищевых предприятий, сохранения полученной статистической информации и оповещения пользователей в случаях выхода температуры объекта за рамки допустимых значений.
Целью системы является обеспечение выполнения функций работы с тепловизион-ным устройством и сохранения статистической информации в автоматическом режиме.
Среди всего спектра задач, решаемых системами управления современными базами данных, применительно к рассматриваемому процессу тепловизионной диагностики необходимо отметить следующие:
- обеспечение хранения в базе данных всей необходимой информации в наиболее компактном виде;
- обеспечение возможности получения данных по всем необходимым запросам;
- сокращение избыточности, дублирования и обеспечение целостности данных.
В процессе проектирования моделей хранения данных производится построение информационной модели наиболее высокого уровня абстракции. Данная модель не ориентирована на
© Антипов С.Т., Рязанов А.Н. Ивашин А. Л., Уразов Д.Ю., 2013
конкретную систему управления базами данных. Конкретный вид и содержание модели базы данных определяется выбранным для этого формальным аппаратом. В данной работе будет использована табличная нотация, которая включает в себя:
- описание информационных объектов или понятий предметной области и связей между ними;
- описание ограничений целостности, требований к допустимым значениям данных и к связям между ними.
В качестве основной схемы используется реляционная модель данных - набор схем отношений, обычно с указанием первичных ключей и связей между отношениями, представляющих собой внешние ключи. На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной системы управления.
Физическое проектирование - создание схемы базы данных для конкретной системы управления базами данных. Специфика конкретной системы может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и другие ограничения.
Ниже представлены основные сущности, используемые для долговременного хранения информации.
<becmHUKjBTyWïïï, №3, 2013
Сущность системных пользователей используется для обеспечения безопасности и осуществления процесса разграничения прав. Заполнение таблицы производится на этапе начального запуска системы и в дальнейшем при функционировании. Добавление новых сущностей не должно приводить к непредвиденному поведению. Изменение существующих сущностей не допускается. Процесс удаление заменяется затенением, для этого дезактивируется поле видимости.
Каждый пользователь принадлежит к некоторой группе (таблица 1), которая показы -
Сущность
вает ряд допустимых для него действий и вводит ограничения. Хеш-код пароля используется для хранения md5-cyммы введенного пароля. Не допускается пустое поле. Поле видимости указывает, является ли данный пользователь действующим, если флаг деактивирован, то экземпляр не используется системой, однако могу существовать другие сущности, которые ссылаются на данного пользователя. Для предотвращения каскадного удаления сущностей, среди которых могут быть актуальные, используется затенение.
Таблица 1
Поле Тип Комментарий
id long PRIMARY KEY Уникальный идентификатор системного пользователя
system_ users_ group id long REFERENCES system_ users group NOTNULL Ссылка на сущность группы пользователей, к которой принадле-
жит пользователь
login text NOT EMPTY Имя пользователя для входа в систему
hashpass text NOT EMPTY Хеш-сумма пароля (md5-cyммa)
email text NOT EMPTY Электронный адрес пользователя для осуществления алгоритма оповещения
visibility boolean DAFAULT TRUE Флаг видимости
description text Описание
Подсистема хранения данных, которая предназначена для оперативного и долговременного хранения в структурах, нацеленных на принятие решений и формирование отчетности, должна обеспечивать выполнение следующих функций: хранение в течение заданного периода актуальных данных и помещение в архив данных, потерявших свою актуальность.
С точки зрения эффективности работы системы следует разбиение хранилища на два непересекающихся подмножества: основное или оперативное хранилище - для показаний, используемых часто в текущих расчетах; архивное хранилище или история - для показаний, используемых крайне редко.
Сущность показаний источника данных (таблица 2) позволяет задать карту соответствия
Сущность I
времени снятия показаний и самих термографических изображений. Для данной цели используется кортеж полей даты и времени получения данных и ссылки на полученные показания.
Принимаемые данные от источника после проверки изначально попадают в оперативное хранилище. Спустя период времени, после которого они теряют свою актуальность для процесса управления, данные автоматически переносятся в архивное хранилище. При переносе в архивное хранилище производится процесс прореживания, в результате которого можно сократить информационный объем без существенной потери в качестве. Процесс переноса данных в архивное хранилище инициируется системой самостоятельно на основе факта утери актуальности данных.
Таблица 2
жа данных
Поле Тип Комментарий
id long PRIMARY KEY Уникальный идентификатор показаний источника данных
value date date Дата и время получения показаний
binary_ data id long REFERENCES binary data NOTNULL Ссылка на термограмму
visibility boolean DAFAULT TRUE Флаг видимости/архивно сти
<becmHUKjBTyWïïï, №3, 2013L
Регионы слежения - статические прямоугольные области термографического изображения, которые подвергаются анализу (табли-
ца 3). Регион однозначно задается указанием прямоугольной области, системного пользователя и границ выхода за критическую область.
Таблица 3
Сущность регионов
Поле Тип Комментарий
id long PRIMARY KEY Уникальный идентификатор региона слежения
system_user_id long REFERENCES system user NOTNULL Ссылка на сущность пользователя добавившего или изменившего регион слежения
polygon coord box Координаты прямоугольного региона слежения
normal value range Границы показателе данного региона
description text Описание региона слежения
Сущность системных настроек (таблица 4) описывает глобальные настройки системы, необходимые для обеспечения основного режима работы. Экземпляров данной сущности может быть несколько, действующим является тот, у которого установлен соответствующий флаг, единовременно только у одного из экземпляров настроек может быть установлен данный флаг.
С точки зрения информационного обмена между компонентами рассматриваемой системы предъявляются следующие требования. В качестве протокола взаимодействия между блоками хранения информации и принятия решения на
Сущность
транспортно-сетевом уровне необходимо использовать протокол TCP/IP. Ввиду особенностей технической реализации источника данных работа с ним должна осуществляться по протоколу UDP. Для организации информационного обмена между компонентами и доступа пользователей к отчетности должны использоваться протоколы прикладного уровня HTTP и HTTPS. Исходя из требований, предъявляемых к связям между компонентами, требований надежности и условий лицензирования, необходимо выбрать физическую реализацию системы управления базой данных.
Таблица 4
мных настроек
Поле Тип Комментарий
id long PRIMARY KEY Уникальный идентификатор версии системных настроек
is current boolean DAFAULT FALSE Флаг, показывающий актуальность данного набора настроек
sensor address inet Адрес источника данных
database adress inet Адрес сервера базы данных
frame frequency numeric Частота анализа данных
valid time date Время хранения бинарных данных
visibility boolean DAFAULT TRUE Флаг видимости
Системой, удовлетворяющей всем требованиям является PostgreSQL - свободная объектно-реляционная система управления базами данных, которая существует в реализациях для множества UNIX-подобных платформ, включая используемую Debian GNU/Linux. Используемыми особенностями в данном проекте являются :
- поддержка базы данных размера, ограниченного физическим размером хранилища;
- надежные механизмы транзакций и репликации;
- поддержка возможностей наследования и процессов сравнительно простой расширяемости.
В данной работе были разработаны физическая и логическая модели, которые ис-
пользуются при разработке системы тепловизионной диагностики.
Статья подготовлена по результатам работ, выполненных на оборудовании ЦКП «КУ-ЭП» ФГБОУ ВПО «ВГУИТ».
ЛИТЕРАТУРА
1 Энсор, Д. Проектирование баз данных [Текст] / Д. Энсор, И. Стивенсон. - СПб.: БХВ-Петербург, 1999. - 503 с.
REFERENCES
1 Ensor, D. Database design [Text] / D. En-sor, Y. Stevenson. - SPb.: БХВ-Петербург, 2003. - 503 p.
