Создание автоматизированной системы создания и ведения адресных справочников и справочников объектов теплоснабжения

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

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

Нормативно-справочная информация (НСИ) - это условно-постоянная составляющая общей корпоративной информации. НСИ - это ядро единого информационного пространства организации. В состав НСИ входит набор справочников, словарей, классификаторов, стандартов, регламентов, используемых в деятельности предприятия. Управление нормативно-справочной информацией происходит с помощью системы управления НСИ или MDM-системы (Master Data Management).

Master Data Management - это набор процессов и инструментов для определения и управления нормативно-справочной информацией, её сбора из всех информационных систем, обеспечения её качества, поиска потенциальных дублей, консолидации, распространения по всей организации в рамках единой политики. Главной задачей MDM-системы является обеспечение максимально полной, достоверной, уникальной информации, используемой всеми автоматизированными системами и подразделениями компании. MDM-системы активно используются в распределённых информационных системах [32].

Распределённые информационные системы - это информационные системы, компоненты которой распределены по нескольким автоматизированным системам. По архитектуре распределённые информационные системы делятся на файл-серверные и клиент-серверные [21].

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

В двухзвенных информационных системах существует только два типа звеньев: рабочая станция, на которой располагается клиентское приложение и сервер, на котором хранятся СУБД и базы данных. В такой архитектуре приложения напрямую обращаются к СУБД. В многозвенных ИС существуют ещё промежуточные звенья - серверы приложений. Клиентские приложения в этом случае не обращаются напрямую к СУБД, а взаимодействуют только с промежуточными звеньями. При реализации такой архитектуры данные вводятся и редактируются децентрализовано, из-за чего возникает проблема репликации данных [16] - синхронизации нескольких копий содержимого баз данных. Из-за этого появляется главная проблема MDM-систем - контроль качества информации.

Под контролем качества информации подразумеваются меры, направленные на снижение вероятности ошибок при модификации информации, гарантируя тем самым работу с достоверной информацией [14].

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

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

Практическим примером, подчеркивающим актуальность создания и внедрение такого программного обеспечения, является автоматизированная система создания и ведения адресных справочников и справочников объектов теплоснабжения (далее - АСОТ), разработанная компанией «Маппл Групп», на которой мною была пройдена производственная практика, в интересах ОАО «Московская объединенная энергетическая компания» (ОАО «МОЭК»). АСОТ - корпоративная географическая информационная система ведения НСИ ОАО «МОЭК».

Географическая информационная система (ГИС) - это система, обеспечивающая сбор, хранение, обработку, отображение и распространение данных, а также получение на их основе новой информации о пространственно-ориентированных явлениях [15]. В более узком смысле географической информационной системой является программный продукт, позволяющий пользователям работать не только с графической информацией, но и редактировать другие атрибуты объектов, представленных визуально на цифровой карте, такие как адрес, тип здания, наименование улицы и так далее [4]. ГИС преимущественно хранят информацию в системах управления базами данных и обладают мощными инструментами работы с данными, например, редакторами растровой и векторной графики [29].

Исследование задачи обеспечения качества информации, разработка программного модуля маршрутизации запросов на изменение данных будет произведено в рамках внедрения в автоматизированную систему АСОТ.

1. Назначение и область применения

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

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

Разработать программный модуль, реализующий маршрутизацию запросов на изменение данных;

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

Разработать метаязык для описания условий;

Внедрить разработанный модуль в программный комплекс АСОТ:

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

Сформировать отчёт о проделанной работе.

3. Техническое задание на разработку программного модуля

3.1 Введение

Наименование

Программный модуль маршрутизации запросов на изменение данных в автоматизированной системе АСОТ.

Область применения

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

3.2 Основания для разработки

Документ, на основании которого ведется разработка:

Форма Запроса Изменений к договору № 1/11 на оказание услуг и выполнение работ по технической поддержке автоматизированной системы ведения адресных справочников и справочников объектов теплоснабжения ЕКС НСИ ОАО «МОЭК» и использованием технологий ГИС ОАО «МОЭК».

Документ утверждён ОАО «МОЭК» 01.09.2012.

Наименование и (или) условное обозначение темы разработки:

Разработка компонента распределения объектов мультизапроса по ролям в зависимости от типа объекта, значений его атрибутов и операции над ним в АС АСОТ ОАО «МОЭК».

3.3 Назначение разработки

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

Правильная адресация запросов пользователям в зависимости от роли пользователя в системе, а также содержимого запроса;

Динамическое изменение маршрута, при выполнении определённых условий;

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

Автоматическое отклонение запросов по времени;

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

3.4 Требования к программному продукту

3.4.1 Требования к функциональным характеристикам

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

Динамическое изменение настроенного маршрута подразумевает под собой автоматическое прохождение определённых состояний запросом при выполнении конкретного условия в зависимости от атрибута этого запроса. Для реализации этой функции необходимо разработать и внедрить метаязык, на котором будут описываться условия пропуска состояний, а также функции для преобразования описанного условия в логическое выражение и дальнейшее вычисление его значения. Входными данными этой функции будут являться значения атрибутов запроса, значения атрибутов объекта записанные в базе данных, а также условие, описанное на метаязыке. На выходе функции - булевское значение (true или false) однозначно определяющее необходимость пропуска или остановки в текущем состоянии маршрута.

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

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

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

3.4.2 Требования к надёжности

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

3.4.3 Требования к эксплуатации

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

3.4.4 Требование к составу и параметрам технических средств

Средства вычислительной техники должны иметь следующий минимальный состав:

ПК с Intel-совместимым процессором с тактовой частотой не ниже 1,7 ГГц;

объем ОЗУ - 256 МБ;

объём свободной памяти на жёстком диске - 500 МБ;

В состав программного обеспечения должны входить:

ОС семейства Windows (Windows 2000 и более поздних версий);

СУБД MySQL 5.0 и выше;

среда Borland Delphi 5.0 и выше.

3.4.5 Требование к информационной и программной совместимости

Разрабатываемый программный модуль является частью системы АСОТ, поэтому требования к информационной и программной совместимости будут аналогичными. Программа должна работать в операционной системе Windows XP или Windows 7, поэтому она должна иметь совместимость со стандартной библиотекой функций Win API. Все данные находятся на базах данных формата MySQL, поэтому в системе должен быть реализован интерфейс, позволяющий обращаться к СУБД. Программный модуль рекомендуется разрабатывать в среде Borland Delphi 7, на языке Delphi поскольку система, в которую модуль будет внедрён, была разработана именно на этом программном обеспечении. Это облегчит интеграцию разрабатываемого модуля.

3.4.6 Требования к маркировке и упаковке

Не предъявляются.

3.4.7 Требования к транспортированию и хранению

Не предъявляются.

3.5 Программная документация

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

3.6 Стадии разработки

3.7 Порядок контроля и приёмки

Система отслеживания ошибок - прикладная программа, разработанная с целью помочь разработчикам программного обеспечения (программистам, тестировщикам и др.) учитывать и контролировать ошибки, найденные в программах, пожелания пользователей, а также следить за процессом устранения этих ошибок и выполнения или невыполнения пожеланий. Принцип работы системы отслеживания ошибок рассмотрим на примере программного продукта австралийской компании Atlassian. Atlassian JIRA - это система, предназначенная для отслеживания ошибок в процессе разработки и сопровождения программного обеспечения [1]. Также данная программа иногда используется для ведения проектов. Задачи, которые решаются в процессе ведения проекта, реализованы в качестве запросов. Запрос представляет собой конкретную задачу, назначенную определённому пользователю. В зависимости от настроек системы пользователю может быть выделено определённое количество времени для решения задачи, если это необходимо. У запроса есть такой атрибут как статус, который определяет текущее состояние запроса. По этому статусу можно определить, на какой стадии находится решение поставленной задачи. Администратор системы может произвольно настроить состояния, которые может принимать запрос, а также маршрут, по которому запрос попадает из одного состояния в другое. Например: пусть решение задачи предполагает выполнение трёх этапов: подготовительный, основной и заключительный. Для обозначения начального и завершённого состояний запроса введём ещё 2 статуса. Тогда мы можем построить цепочку, по которой будет двигаться запрос в ходе решения поставленной задачи: начальное - подготовительный этап - основной этап - заключительный этап - завершён. В этом случае запрос не сможет пройти в заключительный этап, не остановившись в основном. В случае если необходимо добавить возможность возврата запроса по цепочке назад, этот переход добавляется администратором системы. Таким образом, реализована маршрутизация данных в программном продукте Atlassian JIRA.

Преимущества:

Удобный инструментарий для настройки маршрута;

Наглядное визуальное представление маршрута;

Возможность создать маршрут высокой сложности.

Недостатки:

Нет возможности динамически изменять маршрут при определённых условиях;

Отсутствие открытого кода лишает возможности использовать этот модуль в своих целях.

4.3.2 Система электронного документооборота

Система электронного документооборота (СЭД) - это автоматизированная система управления корпоративным документооборотом. Автоматизация позволяет сократить время на обработку документов, а также снижает риски случайной потери данных, кроме того, СЭД позволяет руководству контролировать выполнение управленческих решений и отслеживать все действия, производимые с зарегистрированными в системе документами [28]. Рассмотрим одну из наиболее известных систем электронного документооборота, разработанного российской компанией «ЛАНИТ» LanDocs.

Как специализированная для решения задач СЭД программная платформа, LanDocs позволяет строить полный спектр систем электронного документооборота - от самых простых до систем высокой сложности. Сочетание функциональности с открытостью, позволяет при внедрении настроить создаваемую систему в соответствии с нормативной базой и практикой работы с документами конкретного предприятия, ведомства или учреждения. LanDocs имеет высокий уровень масштабируемости решений: в контур документооборота могут быть включены как пользователи вычислительной сети главного офиса, так и сотрудники удаленных подразделений. Платформа включает в себя ПО высокой степени готовности - автоматизация стандартных широко распространенных бизнес-процессов сводится к настройкам платформы и, как правило, не требует программирования. Наряду с этим, LanDocs предоставляет развитые инструментальные средства, с помощью которых могут быть автоматизированы бизнес-процессы специфичные для данного предприятия или предметной области [12].

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

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

Преимущества:

Широкий спектр возможностей, позволяющий реализовать маршрутизацию запросов любой сложности;

Возможность динамически изменять маршрут, в зависимости от атрибутов конкретного запроса;

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

Недостатки:

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

4.4 Математическое и информационное обеспечение

4.4.1 Теория конечных автоматов

Конечным автоматом называется формальная система M = (Q, У, д, q0, F), где Q - конечное непустое множество состояний; У - конечный входной алфавит; д - отображение типа Q Ч У > Q; q0 ? Q - начальное состояние; F ? Q - множество конечных состояний [17].

Конечный автомат состоит из конечного управления и входной ленты, разбитой на ячейки. В каждой ячейке записан один символ из входного алфавита У, и все они образуют конечную входную цепочку. Конечное управление первоначально находится в состоянии q0 и сканирует крайнюю левую ячейку ленты. По мере чтения входной цепочки слева направо автомат переходит в другие состояния из множества Q. Если, прочитав входную цепочку, автомат оказывается в некотором конечном состоянии из множества F, то говорят, что он принял ее. Множество цепочек, принимаемых конечным автоматом, называется языком, распознаваемым данным конечным автоматом.

Конечные автоматы подразделяются на детерминированные и недетерминированные:

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

Конечные автоматы описывают с помощью двух способов [24]:

Таблица переходов

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

На рисунке 4.2 приведен пример описания конечного автомата с помощью таблицы переходов.

Рис. 4.2 Таблица переходов

Диаграмма состояний

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

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

Рис. 4.3 Диаграмма состояний

Для решения поставленной задачи систему маршрутизации запросов можно интерпретировать с помощью конечного автомата следующим образом [31]:

Конечное непустое множество состояний Q - состояния, которые может принимать запрос, проходя по схеме маршрутизации;

Конечный входной алфавит У - набор возможных пользователям действий для перемещения запроса из одного состояния в другое;

Функция переходов д - набор переходов, связывающих состояния межу собой;

Начальное состояние q0 - состояние, в котором пользователь создаёт запрос;

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

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

4.4.2 Метаязык

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

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

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

Необходимо также создать интерпретатор для разбора описанного условия на метаязыке [25]. В основе работы интерпретатора лежит теория конечных автоматов, о которой написано выше. Интерпретатор разбивает выражение на условия, соединенные друг с другом булевскими операторами «и», «или», «не», а также учитывает скобки для определения порядка вычисления логических действий.

4.4.3 Система управления базами данных

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

База данных - представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины [6].

Система управления базами данных (СУБД) - совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных [5].

СУБД выполняет следующие функции:

управление данными во внешней памяти;

управление данными в оперативной памяти;

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

поддержка языков БД.

По модели данных СУБД подразделяются на следующие виды:

Иерархические

Сетевые

Реляционные

Объектно-ориентированные

Объектно-реляционные

Транзакция - это последовательность операций над БД, рассматриваемых СУБД как единое целое. Либо транзакция успешно выполняется, и СУБД фиксирует изменения БД, произведенные этой транзакцией, во внешней памяти, либо ни одно из этих изменений никак не отражается на состоянии БД [3].

Одним из основных требований к СУБД является надежность хранения данных во внешней памяти. Под надежностью хранения понимается то, что СУБД должна быть в состоянии восстановить последнее согласованное состояние БД после любого аппаратного или программного сбоя. Обычно рассматриваются два возможных вида аппаратных сбоев: так называемые мягкие сбои, которые можно трактовать как внезапную остановку работы компьютера (например, аварийное выключение питания), и жесткие сбои, характеризуемые потерей информации на носителях внешней памяти. Примерами программных сбоев могут быть: аварийное завершение работы СУБД (по причине ошибки в программе или в результате некоторого аппаратного сбоя) или аварийное завершение пользовательской программы, в результате чего некоторая транзакция остается незавершенной [11]. Первую ситуацию можно рассматривать как особый вид мягкого аппаратного сбоя; при возникновении последней требуется ликвидировать последствия только одной транзакции. Понятно, что в любом случае для восстановления БД нужно располагать некоторой дополнительной информацией. Другими словами, поддержание надежности хранения данных в БД требует избыточности хранения данных, причем та часть данных, которая используется для восстановления, должна храниться особо надежно. Наиболее распространенным методом поддержания такой избыточной информации является ведение журнала изменений БД. Журнал - это особая часть БД, недоступная пользователям СУБД и поддерживаемая с особой тщательностью, в которую поступают записи обо всех изменениях основной части БД. Иногда поддерживаются две копии журнала, располагаемые на разных физических дисках для увеличения надёжности. В разных СУБД изменения БД журнализуются на разных уровнях: иногда запись в журнале соответствует некоторой логической операции изменения БД (например, операции удаления строки из таблицы реляционной БД), иногда - минимальной внутренней операции модификации страницы внешней памяти; в некоторых системах одновременно используются оба подхода [27]. Во всех случаях придерживаются стратегии "упреждающей" записи в журнал, так называемого протокола Write Ahead Log - WAL. Эта стратегия заключается в том, что запись об изменении любого объекта БД должна попасть во внешнюю память журнала раньше, чем измененный объект попадет во внешнюю память основной части БД. Известно, что если в СУБД корректно соблюдается протокол WAL, то с помощью журнала можно решить все проблемы восстановления БД после любого сбоя.

Для работы с базами данных используются специальные языки, называемые языками баз данных. В современных СУБД обычно поддерживается единый интегрированный язык, содержащий все необходимые средства для работы с БД, начиная от ее создания, и обеспечивающий базовый пользовательский интерфейс с базами данных. Стандартным языком наиболее распространенных в настоящее время реляционных СУБД является язык SQL (Structured Query Language). Прежде всего, язык SQL позволяет определять схему реляционной БД и манипулировать данными. При этом именование объектов БД (для реляционной БД - именование таблиц и их столбцов) поддерживается на языковом уровне в том смысле, что компилятор языка SQL производит преобразование имен объектов в их внутренние идентификаторы на основании специально поддерживаемых служебных таблиц-каталогов. Внутренняя часть СУБД (ядро) вообще не работает с именами таблиц и их столбцов. Наконец, авторизация доступа к объектам БД производится также на основе специального набора операторов SQL. Идея состоит в том, что для выполнения операторов SQL разного вида пользователь должен обладать различными полномочиями. Пользователь, создавший таблицу БД, обладает полным набором возможных действий для работы с этой таблицей. В число этих действий входит возможность передачи всех или части полномочий другим пользователям. Ограничение возможностей пользователей описываются в специальных таблицах-каталогах, а их контроль поддерживается на языковом уровне.

4.5 Структура модуля

4.5.1 Основные понятия

Пользователь - зарегистрированный в системе человек.

Физическая таблица - зарегистрированная в базе данных таблица для хранения информации об однотипных объектах. Таблица может содержать только часть информации об объекте, а также может являться таблицей связи для реализации N:N связей [20] между другими таблицами.

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

Объект - конкретная запись в справочнике.

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

Мультизапрос - это запрос, объединяющий в одну логическую группу несколько объектов для удобной обработки информации. Объекты мультизапроса могут являться как однотипными, так и разнотипными.

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

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

Тип роли - логическая группа ролей, объединенная определённым признаком для удобного разграничения полномочий между разнотипными ролями.

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

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

Смежные состояния - состояния схемы маршрутизации, соединённые переходом типа Forward, при этом исходящее состояние называется предыдущим, а входящее - следующим. Двум смежным состояниям не может соответствовать одна и та же роль.

Набор полей - перечень атрибутов объекта доступных на редактирование для роли.

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