Инфологическая модель предметной области

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

Скважины могут объединяться в группы для подписок по Событиям. Одна скважина может входить в несколько групп. Пользователь может подписываться на несколько групп скважин. Так как одно оповещение по Событиям может адресоваться нескольким пользователям, то статус оповещения устанавливается относительно каждого адресата.

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

· скважина;

· пользователь;

· сервисное предприятие;

· события;

· группа скважин;

· протокол ДК;

· запросы.

Инфологическая модель предметной области представлена на рис. 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. Инфологическая модель Подсистемы

Физическая инфологическая модель Подсистемы содержит в себе таблицы:

1. NOTIFY_LIST_WELLS – таблица групп со скважинами для подписок. Она необходима для хранения информации о группах скважин для подписки. Список атрибутов таблицы NOTIFY_LIST_WELLS описан в табл. 2. Менять значения параметров подписки может только автор. Группы с указанным параметром «Общая группа», доступны для подписки всем пользователей, иначе оповещение будет приходить только автору группы.

Таблица 2

Описание атрибутов таблицы NOTIFY_LIST_WELLS

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
LIST_ID	счетчик	Идентификатор перечня	Нет	Да	NOT NULL (уникальное значение)
LIST_NAME	текстовый	Наименование перечня скважин	Нет	Нет	NOT NULL (<255 символов)
OWNER	текстовый	Автор перечня	Да	Нет	NOT NULL (<255 символов)
CDS_STOP	логический	Потери и остановки	Нет	Нет	NOT NULL
EPOS_DEMOUNT	логический	Демонтаж	Нет	Нет	NOT NULL
EPOS_DISASM	логический	Разбор	Нет	Нет	NOT NULL
SUBS_DATE	дата	Дата подписки	Нет	Нет	NOT NULL (<Текущей даты)
SHARED	логический	Общая группа	Нет	Нет	NULL

 

2. QUALITY_DAY_REC – таблица протоколов дня качества, она необходима для хранения данных о протоколах дня качества. Список атрибутов таблицы QUALITY_DAY_REC описан в табл. 3. Таблица связана с таблицами NOTIFY_EVENTS и NOTIFY_REQUEST_DATA

Таблица 3

Описание атрибутов таблицы QUALITY_DAY_REC

Атрибут	Тип данных	Описание	FK	PK	Ограничение целостности
QUALITY_DAY_REC_ID	Счетчик	Идентификатор протокола	Нет	Да	NOT NULL (уникальное значение)
QUALITY_DAY_REC_DATE	дата	Дата создания протокола	Нет	Нет	NOT NULL (<Текущей дату)
EVENT_ID	числовой	Идентификатор События	Да	Нет	NOT NULL
STOP_YMD	дата	Дата отказа скважины	Нет	Нет	NOT NULL (<Текущей даты)

 

3. WELL – таблица сущности «скважина», она необходима для хранения данных о скважинах. В таблице хранятся данные о местонахождении скважины. Список атрибутов таблицы WELL описан в табл. 4.

Таблица 4