ПОДСИСТЕМА ОПОВЕЩЕНИЯ ДЛЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ УЧЕТА ЭЛЕКТРОПОГРУЖНОГО ОБОРУДОВАНИЯ СКВАЖИН НЕФТЯНОЙ КОМПАНИИ «РОСНЕФТЬ» (КОМПАНИИ).

В данной дипломной работе проведено исследование процесса работы пользователей с информационной системы учета электропогружного оборудования скважин (ИС «ЭПОС»). Целью работы является повышение эффективности работы пользователей ИС «ЭПОС».
В результате данной работы было спроектирована, разработана и внедрена подсистема оповещения в ИС «ЭПОС», устраняющая недостатки в работе ИС «ЭПОС». Разработаны и реализованы спецификации требований на внесение изменений в ИС «ЭПОС».
Подсистема оповещения разработана в среде программирования Microsoft Visual Studio и внедрена с применением системы управления версиями SourceGear Vaul.
Подсистема оповещения разработана, внедрена и находится на стадии тестирования жизненного цикла ИС «ЭПОС».
...

РЕФЕРАТ 2
СОДЕРЖАНИЕ 3
ПЕРЕЧЕНЬ ПОНЯТИЙ И СОКРАЩЕНИЙ 5
ВВЕДЕНИЕ 6
1. ОПИСАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ 9
1.1. Модель бизнес-процессов 10
1.2. Обзор ИС «ЭПОС» 14
2. ОБЗОР АНАЛОГОВ 19
2.1. Подсистема оповещений и уведомлений системы «Дело» 19
2.2. Програм Лайн: Уведомления о событиях 22
2.3. Подсистема «Выписка Онлайн» в ДБО BS-Client x64 25
2.4. Вывод 28
3. ПОСТАНОВКА ЗАДАЧИ 30
4. КОНТУР ПОДСИСТЕМЫ 32
5. ИНФОЛОГИЧЕСКАЯ МОДЕЛЬ ПРЕДМЕТНОЙ ОБЛАСТИ 37
6. ВИДЫ ОБЕСПЕЧЕНИЯ 39
6.1. Информационное обеспечение 39
6.2. Математическое обеспечение 47
6.3. Программное обеспечение 50
6.3.1. Подсистема связи с СУБД 51
6.3.2. API СУБД 52
6.3.3. Модуль опроса базы данных 58
6.3.4. Модуль оперативного оповещения 58
6.3.5. Модуль формирования заявок 60
6.3.6. Модуль формирования подписок 61
6.4. Техническое обеспечение 61
7. ОПИСАНИЕ ИНТЕРФЕЙСА 62
7.1. Оповещение по событиям 62
7.2. Оповещение о запросах 66
7.3. Контроль ввода данных 69
8. ТЕХНИКО-ЭКСПЛУТАЦИОННЫЕ ХАРАКТЕРИСТИКИ 71
ЗАКЛЮЧЕНИЕ 73
СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ 75
ПРИЛОЖЕНИЕ 1 77
ПРИЛОЖЕНИЕ 2 79

Компания является крупнейшей нефтедобывающей компанией в Российской Федерации (РФ). Непосредственно добычу углеводородного сырья осуществляется дочерними добывающими обществами (ДО) компании «Роснефть». Каждая ДО может владеть десятками тысяч скважин, за состояниями которых необходимо постоянно наблюдать и которых необходимо обслуживать. Для обслуживания скважин в состав ДО входят сервисные предприятия (СП) осуществляющие непосредственно техническое обслуживание оборудования на месторождениях.
При таких больших масштабах невозможно обойтись без современных информационных системы и компьютерных технологий. С целью оперативного учета и анализа параметров эксплуатации и ремонта электропогружного оборудования скважин в Компании используют собственную разработку – «ЭПОС».
Для обеспечения и пов ышения качества работ сервисных подразделений, на уровне ДО активно работает отдел качества (ОК). отдел качества занимается расследованием случаев остановки, демонтажа и отказов скважин (События). При этом отдел качества активно использует «ЭПОС» для сбора данных по расследуемым Событиям. В результате расследования делается заключение и на основании этого заключения руководителям предлагают внести ряд изменений в деятельность СП для исключения таких причин. От эффективности работы отдел качества во многом зависит качество работы всей Компании, однако в работе отдел качества возникают задержки и простои из-за недостаточных или некорректных данных полученных от СП через «ЭПОС». Т.к. территориально отдел качества и СП находятся на больших расстояниях, и часто неизвестно какой оператор ответственен за данные, возникают сложности в создании запроса на дополнение и коррекцию данных. Не смотря на это, даже своевременное дополнение или корректирование данных не исключает задержек в работе отдела качества, т.к. сотрудник отдела качества не оповещается об этом.
В данной работе было исследован процесс работы пользователей ЭПОСа в результате чего были выявлены недостатки ЭПОСа, устранив которые можно было значительно повысить эффективность работы отдела качества. Было предложено разработать подсистему оповещения (Подсистема) для устранения таких недостатков ЭПОСа, как:
• недостаточный контроль за своевременный ввод данных;
• отсутствие возможности создания запросов на коррекцию и дополнение данных;
• отсутствие оповещения о вводе данных по Событиям.
Для разработки Подсистемы была использована среда разработки Microsoft Visual Studio. Разработанная подсистема способна расширить «ЭПОС» функциями:
• оповещение пользователя о несвоевременном вводе данных;
• оповещение пользователя о Событиях;
• формирование запросов на коррекцию и дополнение данных;
• оповещение пользователя о некорректных и неполных данных.
Благодаря спиральной модели жизненного цикла ЭПОСа, автор воспользовался возможностью внедрить Подсистему в «ЭПОС» и устранил тем самым выявленные недостатки в работе ИС «ЭПОС». Для качественного внедрения были использована система управления версиями SourceGear Vault.
В процессе внедрения были внесены изменений в компоненты ЭПОСа для обеспечения взаимодействия Подсистемы с ИС «ЭПОС».

12.На этапе проектирования заказчик потребовал следующие функции:оповещение пользователя о Событиях;оповещение пользователя о запросах на коррекцию и дополнение данных;возможность оформлять и отправлять запросы на коррекцию и дополнение данных;возможность оформлять подписки на оповещения;оповещение пользователя о задержках ввода данных.Рис. 12. Подсистема оповещения в ИС «ЭПОС»Для обеспечения вышеперечисленных функций в составе Подсистемы предусмотрены следующие модули: модуль формирования подписки – оформляет подписки на события по выбранному перечню оборудования;модуль формирования заявок пользователю СП – оформляет заявки на дополнение и коррекцию данных, необходимых для расследования отказов оборудования. Заявки отправляются на хранение в базу данных до востребования модулем опроса базы данных со стороны пользователя сервисного предприятия;модуль опроса базы данных – с определенным промежутком времени обращается к базе данных за данными для оповещений пользователя;модуль оперативного оповещения – активирует графические средства оповещения в пользовательском интерфейсе.Модули формирования подписки и заявок отправляют параметры для опроса в модуль опроса БД, который в соответствии с этими параметрами периодически опрашивает сервер и возвращает в модуль оперативного оповещения сигналы о необходимости оповестить пользователя по тому или иному виду оповещения.Контур Подсистемы представлен на рис. 13.Рис. 13. Контур подсистемы оповещенияПодсистема взаимодействует с подсистемой связи с СУБД и с пользовательским интерфейсом ИС «ЭПОС». Для внедрения необходимо внести изменения в:пользовательский интерфейс – добавить формы для формирования подписок и заявок, графические элементы сигнализирования и графические окна просмотра оповещений;подсистему связи с СУБД – добавить дополнительные модули для связи подсистемы оповещения и СУБД;API СУБД – добавить дополнительные функции внесения данных по оповещения их извлечения и модификации;базу данных – дополнить таблицами для сущностей связанных с оповещением.Изменения в БД, подсистему связи с СУБД и API СУБД подробно описаны в настоящей работе в пункте 6.1, 6.3.1 и 6.3.2 соответственно. Изменения в графическом интерфейсе подробнее описаны в разделе 7.Данные изменения необходимы для успешной интеграции Подсистемы с ИС «ЭПОС».Таким образом, подсистема оповещения обладает требуемым функционалом и имеет не сложную структуру, что упростит ее дальнейшее развитие.Инфологическая модель предметной областиПользователь может формировать несколько запросов по разным протоколам ДК. Для формирования запросов на дополнение или коррекцию данных необходима информация о протоколе по ДК, для оформления которого необходимы запрашиваемые данные. Каждый протокол по ДК оформляется на одно конкретное событие конкретной скважины. В каждом событие может фигурировать только одна скважина. Запрос может адресоваться только одному СП.Скважины могут объединяться в группы для подписок по Событиям. Одна скважина может входить в несколько групп. Пользователь может подписываться на несколько групп скважин. Так как одно оповещение по Событиям может адресоваться нескольким пользователям, то статус оповещения устанавливается относительно каждого адресата.В результате обследования предметной области можно выделить следующие сущности:скважина;пользователь;сервисное предприятие;события;группа скважин;протокол ДК;запросы.Инфологическая модель предметной области представлена на рис. 14. Рис. 14. Инфологическая модель предметной областиПредставленная модель оформлена с помощью языка ER-диаграмм (от англ. Entity-Relationship, т.е. сущность-связь). Где стержневые сущности изображены прямоугольниками, ассоциативные – шестиугольниками, характеристические – трапециями, а атрибуты – овалами[4].Виды обеспеченияВ данном подразделе представлены изменения в ИС «ЭПОС» необходимые для функционирования Подсистемы и разработанные модули Подсистемы.Информационное обеспечениеПосле нормализации инфологической модели предметной области была получена логическая инфологическая модель Подсистемы. Логическая инфологическая модель представлена на рис. 15.Рис. 15. Логическая инфологическая модель базы данных Логическая модель разработана с помощью CASE-средства AllFusion ERwin Data Modeler 7 в нотации IDEF1X. IDEF1X является методом для разработки реляционных баз данных и использует условный синтаксис, специально разработанный для построения концептуальной схемы структуры данных предприятия, независимой от конечной реализации базы данных и аппаратной платформы[5]. С помощью CASE-средство AllFusion ERwin переход от логической модели к физической происходит достаточно легко[6]. Благодаря данной возможности задача модификации существующей базы данных ИС «ЭПОС» не вызвала затруднений. Физическая инфологическая модель Подсистемы представлена на рис. 16. В качестве СУБД было использовано MS SQL Server 2008 R2, которое обеспечивает управление данными ИС «ЭПОС» на сервисных предприятиях ООО «Юганскнефтегаз». Так как в базе данных ИС «ЭПОС» информация о пользователях уже имеется, то таблицу USERS создавать нет необходимости.Для рассылки по электронной почте используется компонент СУБД – Database Mail. Компонент Database Mail — это решение уровня предприятия для отправки сообщений электронной почты от компонента SQL Server Database Engine. Используя компонент Database Mail, приложения базы данных могут отправлять почтовые сообщения пользователям. Сообщения могут содержать результаты запроса, а также могут включать файлы из любого сетевого ресурса. Компонент Database Mail спроектирован для надежности, масштабируемости, безопасности и простой поддержки[14].Рис. 16. Инфологическая модель ПодсистемыФизическая инфологическая модель Подсистемы содержит в себе таблицы:NOTIFY_LIST_WELLS – таблица групп со скважинами для подписок. Она необходима для хранения информации о группах скважин для подписки. Список атрибутов таблицы NOTIFY_LIST_WELLS описан в табл. 2. Менять значения параметров подписки может только автор. Группы с указанным параметром «Общая группа», доступны для подписки всем пользователей, иначе оповещение будет приходить только автору группы. Таблица 2Описание атрибутов таблицы NOTIFY_LIST_WELLSАтрибутТип данныхОписаниеFKPKОграничение целостностиLIST_IDсчетчикИдентификатор перечняНетДаNOT NULL (уникальное значение)LIST_NAMEтекстовыйНаименование перечня скважинНетНетNOT NULL (<255 символов)OWNERтекстовыйАвтор перечняДаНетNOT NULL (<255 символов)CDS_STOPлогическийПотери и остановкиНетНетNOT NULLEPOS_DEMOUNTлогическийДемонтажНетНетNOT NULLEPOS_DISASMлогическийРазборНетНетNOT NULLSUBS_DATEдатаДата подпискиНетНетNOT NULL (<Текущей даты)SHAREDлогическийОбщая группаНетНетNULLQUALITY_DAY_REC – таблица протоколов дня качества, она необходима для хранения данных о протоколах дня качества. Список атрибутов таблицы QUALITY_DAY_REC описан в табл. 3. Таблица связана с таблицами NOTIFY_EVENTS и NOTIFY_REQUEST_DATAТаблица 3Описание атрибутов таблицы QUALITY_DAY_RECАтрибутТип данныхОписаниеFKPKОграничение целостностиQUALITY_DAY_REC_IDСчетчикИдентификатор протоколаНетДаNOT NULL (уникальное значение)QUALITY_DAY_REC_DATEдатаДата создания протоколаНетНетNOT NULL (<Текущей дату)EVENT_IDчисловойИдентификатор СобытияДаНетNOT NULLSTOP_YMDдатаДата отказа скважиныНетНетNOT NULL (<Текущей даты)WELL – таблица сущности «скважина», она необходима для хранения данных о скважинах. В таблице хранятся данные о местонахождении скважины. Список атрибутов таблицы WELL описан в табл. 4. Таблица 4Описание атрибутов таблицы WELLАтрибутТип данныхОписаниеFKPKОграничение целостностиWELL_IDчисловойИдентификатор скважиныНетДаNOT NULL (уникальное значение)OILWELLтекстовыйИмя скважиныНетНетNOT NULL (<30 символов)REGIONтекстовыйРегионНетНетNOT NULL (<30 символов)OIL_FIELDтекстовыйМесторождениеНетНетNOT NULL (<30 символов)WELL_CLUSTERтекстовыйКустНетНетNOT NULL (<30 символов)SHOPтекстовыйЦехНетНетNOT NULL (<30 символов)NOTEтекстовыйПримечаниеНетНетNULL (<255 символов)KIT_PO_NUMBERтекстовыйНомер комплекта ПОНетНетNULL (<30 символов)Информация о скважинах будет использоваться при оповещении по Событиям, создании заявки на дополнение и коррекцию данных и в оповещении по заявкам.NOTIFY_EVENTS – таблица событий, связанных со скважинами. Список атрибутов таблицы NOTIFY_EVENTS описан в табл. 5. Информация данной таблицы используется при оповещении по Событиям.Таблица 5Описание атрибутов таблицы NOTIFY_EVENTSАтрибутТип данныхОписаниеFKPKОграничение целостностиEVENT_IDчисловойИдентификатор событияНетДаNOT NULL (уникальное значение)WELL_IDчисловойИдентификатор скважиныДаНетNOT NULLEVENT_DATEдатаДата событияНетНетNOT NULL (<текущей даты)STOP_REASON_TYPEтекстовыйПричина остановкиНетНетNULL (<150 символов)OPERATION_IDчисловойОперация в ЭПОСНетНетNULLMPRчисловойМежремонтный периодНетНетNULL (>0)MODUFY_DATEдатаДата модификации записи в ЭПОСНетНетNULL (<текущей даты и >EVENT_DATE)EVENT_TYPE_IDчисловойИдентификатор типа событияДаНетNULLNOTIFY_ACTIVE_EVENTS – таблица, хранящая информацию об оповещении пользователя о событии. Список атрибутов таблицы NOTIFY_ACTIVE_EVENTS описан в табл. 6. Оповещение о Событие может приходить нескольким пользователям и в разное время. После получения оповещения пользователь может сменить статус События относительно себя. В зависимости от статуса оповещения могут приходить повторно или приходить только при изменении информации о Событии. Хранить время изменения статуса События нет необходимости.Таблица 6Описание атрибутов таблицы NOTIFY_ACTIVE_EVENTSАтрибутТип данныхОписаниеFKPKОграничение целостностиEVENT_IDчисловойИдентификатор событияДаДаNOT NULL (>0)STATUS_IDчисловойИдентификатор статусаДаНетNOT NULL (>0)USER_NAMEтекстовыйИмя пользователяНетДаNOT NULL (<30 символов)NOTIFY_REQUEST_DATA – таблица запросов на дополнение или коррекцию данных. Запись имеет ссылку на протокол Дня качества, откуда можно получить информацию о Событии и скважине, по которым необходимо дополнить или скорректировать данные. Сотрудники отдела качества должны иметь возможности отслеживать изменения статуса запроса, для этого необходимо хранить информацию об авторе запроса и дату выполнения запроса. Список атрибутов таблицы NOTIFY_REQUEST_DATA описан в табл. 7.Таблица 7Описание атрибутов таблицы NOTIFY_REQUEST_DATAАтрибутТип данныхОписаниеFKPKОграничение целостностиREQUEST_IDчисловойИдентификатор запросаНетДаNOT NULL (уникальный)QUALITY_DAY_REC_IDчисловойИдентификатор протокола Дня КачестваДаНетNOT NULLREQUEST_STATE_IDчисловойСтатус запросаДаНетNOT NULLNOTIFY_REQUEST_TYPE_IDчисловойТип запросаДаНетNOT NULLREQUEST_DATEдатаДата запросаНетНетNOT NULL (<текущей даты)REQUEST_AUTHOTтекстовыйАвтор запросаДаНетNOT NULL (<30 символов)SERVICE_ENTERPRISE_IDчисловойСервисное предприятиеДаНетNOT NULLREQUEST_COMMENTтекстовыйКомментарийНетНетNULL (<4000 символов)REQUEST_COMPLETE_DATEдатаДата выполнения запросаНетНетNULL (<текущей даты)А так же используется ряд справочников:DIC_SERVICE_ENTERPRISE – таблица сервисных предприятий;NOTIFY_INPUT_OPR_PREFS – таблица, хранящая информацию о том, что нужно ли оповещать пользователя о несвоевременном вводе данных;NOTIFY_LIST_WELL_SET – таблица отношения скважин к группе;DIC_NOTIFY_STATUS – справочник статусов оповещения;DIC_NOTIFY_EVENT_TYPE – справочник типов события;DIC_NOTIFY_REQUEST_TYPE – справочник типов запроса;DIC_NOTIFY_REQUEST_STATE – справочник статусов запроса;NOTYFY_INPUT_OPR_TYPES – таблица максимально допустимых задержек ввода данных;DIC_OPERATION_TYPE – справочник типов операций;NOTIFY_REQUEST_DATA_FILTERS – таблица, хранящая информацию о фильтрации запросов.Каждый сотрудник отдела качества может отвечать за несколько групп скважин сформированным его руководителем. Для каждой группы индивидуально определяется перечень событий, о которых необходимо сообщать пользователю. Каждая скважина может относиться к нескольким группам. Каждое событие должно храниться в базе данных. Каждое событие может отправляться нескольким пользователем. Данные для заявки на дополнение и коррекцию данных хранятся в таблице NOTIFY_REQUEST_DATA. По этим данным пользователь со стороны сервисного предприятия получает оповещение, в котором указан номер скважины, ее местоположение (месторождение, куст, цех), дата расследуемого события, автор запроса, тип заявки (на коррекцию или дополнение данных) и дату создания заявки. После отработки заявки пользователь самостоятельно меняет статус заявки, чтобы пользователь со стороны отдела качества мог об этом узнать и проверить исполнение заявки. Математическое обеспечениеВ Подсистеме используется формула для расчета времени задержки ввода данных:Т=tвремя ввода данных-tвремя событияОповещение о несвоевременности ввода данных формируется по правилу:T<Zгде Z – допустимая задержка ввода данных, определяемая каждым пользователем индивидуально.Алгоритм Подсистемы работает в зависимости от категории пользователя. Для сотрудников сервисных предприятий выводятся оповещения по заявкам на дополнение или коррекцию данных для отдела качества добывающей организации. При наличии необработанных заявок пользователь ответственный за данные получает оповещение о том, что нужно внести требуемые данные или скорректировать их. Если данные по заявке не были внесены или скорректированы, то оповещение повторно приходит пользователю с определенной периодичностью пока данные не будут внесены или скорректированы. Блок-схема алгоритма работы подсистемы оповещения изображена на рис. 17.Рис. 17. Алгоритм работы ПодсистемыЛица, контролирующие работу ответственных за ввод данных со стороны сервисных предприятий, получают персональные оповещения о задержках ввода данных по электронной почте. При работе сотрудников сервисных предприятий отслеживается время ввода данных пользователей. По итогам каждого дня формируется и отправляется электронное письмо заинтересованным лицам.В ходе работы пользователи могут регистрировать события, связанные с оборудованием (остановка, демонтаж и разбор). При регистрации в системе события связанного с оборудованием, которое может входить в подписку какого-либо сотрудника отдела качества, формируются оповещения для подписчиков на данные события.Сотрудники отдела качества в процессе работы формируют подписки на события связанные с определенным перечнем оборудования. При регистрации в системе «ЭПОС» таких событий, сотрудники отдела качества получают оповещения об этом по их подписке. Кроме подписок пользователи формируют заявки для сотрудников сервисных предприятий на коррекцию или дополнение данных.Программное обеспечениеВ данном подразделе описаны изменения, которые необходимо внести в подсистему связи с СУБД и API СУБД, а также описаны модули Подсистемы.Изменения и модули Подсистемы разработаны с помощью среды разработки Microsoft Visual Studio 2008. Внесения изменений и интеграция Подсистемы с ИС «ЭПОС» были проведены на одном из этапов развития целевой системы.Программа работает на Framework 3.5, поддерживающий операционную систему Windows XP[13]. При внесении изменений в графический интерфейс были использованы пакеты графических компонентов DevExpress. Легкая интеграция Подсистемы с ИС «ЭПОС» была достигнута благодаря системе управления версиями SourceGear Vualt версии 5.1.2. Для тиражирования Подсистемы на рабочие места использовалась ClickOne. СУБД было использовано Microsoft SQL Server 2008 R2. Изменения в базу данных ИС «ЭПОС» были внесены с помощью среды SQL Server Management Studio.Подсистема связи с СУБДДля взаимодействия Подсистемы с СУБД были разработаны и внесены модули:DataSet_DelayNotifications – оповещение по задержкам ввода данных;DataSet_EventNotifications – оповещение по событиям;DataSet_EventNotifications_Lists – список личных групп подконтрольных скважин;DataSet_EventNotifications_SharedLists – список общих групп скважин;DataSet_RequestResponce_List – оповещение о запросах на коррекцию и дополнение данных;DataSet_OPR_Stop – создание запроса на коррекцию и дополнение данных.Каждый модуль подсистемы связи с СУБД взаимодействует с несколькими процедурами из API СУБД согласно таблице 8Таблица 8Описание модулей подсистемы связи с СУБДИмя модуляСвязанные процедуры в API СУБДDataSet_DelayNotifications get_input_monitoring_prefs, set_input_monitoring_prefsDataSet_OPR_Stopadd_data_request, get_request_receivers, get_data_request_attrDataSet_RequestResponce_Listadd_data_request, update_data_requests_state, rem_data_request, get_request_receiversDataSet_EventNotifications_SharedListsget_lists_wells, get_lists_wells_setDataSet_EventNotificationsget_active_lists_wells, get_events, upd_active_events_statusDataSet_EventNotifications_Listsget_lists_wells, del_lists_wells, add_lists_wells, upd_lists_wells, upd_lists_wells_set_note, add_lists_wells_set, del_lists_wells_set, get_lists_wells_setРазработанные модули обеспечивают обмен данными между Подсистемой и API СУБД. Помимо взаимодействия с API СУБД модули обеспечивают контроль данных для снижения количества ошибок пользователя.API СУБДДля доступа к данным были разработаны и внесены в ИС «ЭПОС» хранимые процедуры:get_input_monitoring_prefs – вызов параметров для контроля за задержкой ввода данных;get_active_lists_wells – запрос данных для оповещения по Событиям;get_events – запрос данных по событию, выбранной скважины;get_data_request_attr – получение данных по запросу;del_lists_wells – удаление группы из подписки;del_lists_wells_set – удаление скважины из группы подписки;upd_lists_wells – обновление значений параметров подписки на События;get_data_request – формирование заявок на коррекцию и дополнение данных;add_data_request – добавление заявок на коррекцию и дополнение данных;add_lists_wells – добавление группы скважин;add_lists_wells_set – добавление скважины в группу подписок;update_data_requests_state – обновление статуса запроса;upd_lists_wells_set_note – обновление параметров скважин в подписке;upd_active_events_status – обновление статуса оповещения по Событиям;get_request_receivers – получение списка запросов;rem_data_request – удаление запроса;get_lists_wells – запрос данных по подписке;copy_lists_wells – копирование общую группу в список личных групп;set_input_monitoring_prefs – обновление параметров для настройки подписки на оповещение по задержкам ввода данных;get_data_requests_count – возвращает количество необработанных запросов;get_lists_wells_set – управление общими группами подписок.Разработанные хранимые процедуры обеспечивают операции над данными, хранящимися на сервере СУБД. Подробно хранимые процедуры описаны в таблице 9.Таблица 9Описание хранимых процедурИмя процедурыПараметрОписаниеset_input_monitoring_prefsIS_MONITORING_ENABLE (входной параметр)Включение оповещения о задержках ввода данныхCRITICAL_DELAY_PERIOD (входной параметр)Допустимая задержка ввода данныхMONITOR_OPERATION_TYPE_IDS (входной параметр)Электронная почта пользователяget_data_requests_countCNT (выходной параметр)Количество необработанных запросовget_new_events_countCNT (выходной параметр)Количество новых СобытийПродолжение табл.