82
Сущность описывается в диаграмме IDEF1X графическим объектом в виде
прямоугольника (рис. 2.9).
Рисунок 2.9 – Графическое отображение сущности.
Каждый прямоугольник, отображающий собой сущность, разделяется
горизонтальной линией на часть, в которой расположены ключевые поля и часть, где
расположены не ключевые поля. Верхняя часть называется ключевой областью, а
нижняя часть областью данных.
Ключевая область содержит первичный ключ для сущности. Первичный ключ
- это набор атрибутов, выбранных для идентификации уникальных экземпляров
сущности. Атрибуты первичного ключа располагаются над линией в ключевой
области. Как следует из названия, не ключевой атрибут - это атрибут, который не
был выбран ключевым. Не ключевые атрибуты располагаются под чертой, в области
данных.
При выборе первичного ключа для сущности, часто используют
дополнительный (суррогатный) ключ, т.е. произвольный номер, который
уникальным образом определяет запись в сущности. Суррогатный ключ лучше всего
подходит на роль первичного ключа потому, что является коротким и быстрее всего
идентифицирует экземпляры в объекте. К тому же суррогатные ключи могут
автоматически генерироваться системой так, чтобы нумерация была сплошной, т.е.
без пропусков. Потенциальные ключи, которые не выбраны первичными, могут
быть использованы в качестве вторичных или альтернативных ключей. С помощью
альтернативных ключей часто отображают различные индексы доступа к данным в
конечной реализации реляционной базы.
Если сущности в IDEF1X диаграмме связаны, связь передает ключ (или набор
ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними
Наименование сущности
Ключевое поле
Не ключевое поле 1
Не ключевое поле 2
…..
Не ключевое поле n
83
ключами. Внешние ключи определяются как атрибуты первичных ключей
родительского объекта, переданные дочернему объекту через их связь.
Передаваемые атрибуты называются мигрирующими.
Если требуется, чтобы внешний ключ передавался в дочернюю сущность, то
можно создать идентифицирующую связь между родительской и дочерней
сущностью.
Идентифицирующие связи обозначаются сплошной линией между
сущностями.
Не идентифицирующие связи, являются уникальными для IDEF1X, также
связывают родительскую сущность с дочерней. Не идентифицирующие связи
используются для отображения другого типа передачи атрибутов внешних ключей
– передача в область данных дочерней сущности.
Не идентифицирующие связи обозначаются пунктирной линией между
сущностями[8].
В ООО «АРСЕНАЛЪ» было разработано программное обеспечение по учету
полисов страхования - Irvik, но по причинам, описанным ранее, оно перестало
удовлетворять предъявляемым требованиям. Для работы ПО Irvik, была разработана
база данных. База данных работает под управлением СУБД Interbase.
Структура БД приведена на рис. 2.10.
Как видно, структура БД является очень сложной и запутанной. Кроме того,
она не содержит в себе ряд сущностей ставших необходимыми после изменения
нормативной базы [7] и в связи с разработанными в компании новыми правилами
учета. В связи с этим, было принято решение модифицировать имеющуюся
структуру БД с целью ее упрощения и приведения в соответствие с требованиями.
Из-за недостатков прежней структуры БД было приято решение ее упростить,
при этом сохранить весь функции данной базы данных а так же сами данные
внесенные ранее.
При этом было решено кардинальным образом пересмотреть структуру БД и
сделать ее более масштабируемой. Таким образом, было достигнуто значительное
уменьшение числа таблиц в БД, и упрощена ее структура. Избавление структуры от
обилия связей так же позволит осуществить корректную синхронизацию данных
между базами данных. Необходимость синхронизации продиктована
экономическими причинами. Для организации работы в единой базе данных всем
филиалам ООО «АРСЕНАЛЪ» необходим скоростной безлимитный (желательно
128 Кбит/с или более) доступ в Интернет. Такой доступ за минимальную цену можно
получить далеко не в каждом районе Московской области, не говоря о других
регионах Российской Федерации. Поэтому с целью обеспечить централизованное
хранение данных необходим механизм синхронизации баз данных между
филиалами и центральной БД (рис. 2.11). Структуры баз данных филиалов и
центральной базы данных идентичны.
С этой целью была разработана инфологическая модель структуры БД (рис.
2.12).
86
Рисунок 2.11 – Синхронизация баз данных филиалов с центральной базой данных.
На основе инфологической модели БД создадим физическую структуру БД с
привязкой к СУБД Firebird (рис. 2.13).
Так как стоит задача преобразовать старую структуру к новой без потери
данных записанных в БД, то для этой цели был разработан SQL-сценарий (скрипт),
а так же сценарий пересоздания всех объектов метаданных (пример в Приложение
1). Данный SQL-сценарий приводит существующую БД в новый формат, с
попутным преобразованием данных к необходимому виду.
Как уже говорилось выше, с целью понижения сложности структуры БД было
решено отказаться от ряда связей, сущностей, атрибутов, а так же других объектов
метаданных. Так было решено отказаться от всех триггеров присутствовавших в БД,
и затрудняющих понимание процесса ее функционирования.
Триггер (trigger) – это объект метаданных выполнение которого происходит
при наступлении определенных событий в базе данных (добавление, обновление,
удаление записи из таблицы).
Рисунок 2.12 – Инфологическая модель БД «как надо»
Страны мира
ID
Код
Наименование
Полн. наим.
Базы данных
Код
Наименоване
Примечание
Признак синхронизации
Признак центр.базы
Подразделения УФМС
ID
Код
Наименование
ОКАТО
Нас.пункт
Сокр.нас.пункт а
Документы
Код
Наименование
Экспортный код
Маска серии
Маска номера
Персоны
ID
Фамилия
Имя
Отчеств о
Пол
Предыдущая фамилия
Дат а рождения
Нас. пункт
Улица
Дом
Корпус
Строение
Кв артира
Дат а добавления
Дат а изменения
Примечание
Код ОКАТО
СНИЛС
Уникальный код
Признак включения
Сокр.улицы
Сокр.нас.пункт а
Пользователь доб.запись
Пользователь изм.запись
Код БД
Документы персон
ID
ID персоны
Серия док-та
Номер док-т а
Дат а в ыдачи
Дат а ок.действ ия
Примечание
Признак актуальности
Дат а добавления
Дат а изменения
Тип док-т а
Признак включения
Тип владельца
ID Выдавшего подразделения
Пользователь доб.запись
Пользователь изм.запись
Код БД
Накладные на полисы
ID
Номер
Тип
Дат а в несения в БД
Отв етст веный
Количест во бланков
ID филиала СМО
Пачки полисов
ID
ID Серии полисов
Начальный номер
Конечный номер
ID прих.накладной
ID расх.накланой
Кол-в о полисов
Выданных полисов
Бракованных полисов
Отв етст венный
Признак актив ности
Прикрепленные ЛПУ
Код
Наименование
Сокр.наим.
Ж урналы выдачи
ID
Филиал СМО
Номер журнала
Дат а нач.в едения
Дат а окон.в едения
Кол-в о страниц
Отв етст венный
Статус
Дат а в несения в БД
Признак включения
Пользователь доб.запись
Код БД
Коды ОКАТО
ID
ID родительской записи
Уровень
Код территории
Код1
Код2
Код3
Раздел
Ннаименование
Центр
Наименование без сокр.
Статус
Дат а обновления
Признак
Тип нас.пункт а
Типы нас.пунктов
Тип
Наименовени
Сокр.
Закл. договора
ID
Сокр. наим. страхов ателя
Полное наим.
Тип организации
Номер договора
Тип договора
Дат а регист рации
Дат а плолонгации
Дат а окон.действ .
ID списка договоров
Номер в ТФОМС
ИНН
КПП
ОГРН
ОКПО
ОКОНХ
Должность рук-ля
Фамилия рук-ля
Имя рук-ля
Отчеств о рук-ля
Телефон рук-ля
Моб. телефон рук-ля
E-mail рук-ля
Телефон
Факс
E-mail
Сайт
ОКАТО
Регион регистрации
Регион ст рахования
Район
Сокр. района
Нас.пункт
Улица
Дом
Корпус
Кв артира
Почтовый индекс
Численность по договору
ID филиала СМО
ID филиала ТФОМС
Дат а в несения в БД
Дат а изменения
Дат а расторжения
Причина расторжения
Пользователь изм.запись
Пользователь доб.запись
Конт акт ное лицо
Примечание
Признак соотв етсвт ия
Признак включения записи
Описание ошибки
Сокр.улицы
Сокр.нас.пункт а
Регион регистрации
Регион ст рахования
Пользователь доб.запись
Пользователь изм.запись
Код БД
Серии полисов
ID
Серия полиса
Дат а начала
Примечание
Дат а добавления
Признак ативности
Длина номера
Маска номера
Тип бланка
Признак включения
Код БД
Регионы
Регион по ОКАТО
Регион для ЛПУ
Наименование
Признак
Выданные полисы
ID
ID серии полиса
Номер полиса
Уникальный номер полиса
Филиал СМО выд. полиса
Ж урнал выдачи
Номер записи по журналу
Дат а в ыдачи полиса
Филиал СМО рег-ии полиса
Дат а регист рации
Дат а окон.действ ия
ID персоны
Кат егория заст рахованного
ID договора
ID уч.зав едения
Причина погашения
Дат а погашения
Код окато
Регион прожив ания
Регион ст рахования
Район
Сокр. района
Нас.пункт
Улица
Дом
Корпус
Строения
Кв артира
Фамилия
Имя
Отчеств о
Пол
Дат а рождения
Серия док-та уд.личн.
Номер док-т а уд.личн
Тип док-т а уд.личн
Признак выдачи
Дат а в несения в БД
Дат а изменения
Примечание
Признак соотв етсвия
СНИЛС
Признак включения записи
Описание ошибки
ID Страны гражданст ва
Код поликлиники
Код ст ом.поликлиники
Код жен.консульт ации
Сокр.улицы
Сокр.нас.пункт а
Регион прожив ания
Регион ст рахования
Пользователь доб.запись
Пользователь изм.запись
Код БД
Филиалы ТФОМС
ID
ID ТФОМС
Наименование
Фамилия рук-ля
Должность рук-ля
Почтовый инддекс
Адрес
Телефон
Факс
E-mail
Сайт
Регион работы
Пизнак включения
Код БД
Филиалы СМО_ID
Учебные заведения
ID
Наименование
Адрес
Дат а добавления
Дат а изменения
Тип
Признак включения
Код БД
Базы данных_Код
СМО
ID
Наименование
Полное наим.
Код СМО
Почтовый индекс
Адрес
Должность рук-ля
ФИО рук-ля
Телефон
Факс
E-mail
Сайт
Дат а начала ф-ия
Дат а ок. ф-ия
Признак включения
Код БД
Филиалы СМО
ID
ID CMO
Наименование
Код
Почтовый индекс
Адрес
Руков одитель
Телефон
Факс
E-mail
ID филиала ТФОМС
Дат а начала ф-ия
Дат а ок.ф-ия
Примечание
Регион работы
Признак включения
Код БД
Списки договоров
ID
ID филиала СМО
Код списка
Наименование
Дат а начала
Номер полки
Дат а в несения в БД
Дат а изменения
Признак включения
Пользователь доб.запись
Пользователь изм.запись
Код БД
Хранилище
ID
Секция
Код
Наименование
Признак
Тип
Данные
Типы улиц
Код
Наименование
Сокр
История синхронизаций
ID
Тип
Наименование
Дат а
Пизнак
Признак выполнения
Код БД
Пользователи БД
Имя пользователя
Фамилия
Имя
Отчеств о
Признак включения
Вместо триггеров, там где это необходимо, стали вызываться специальные
специально разработанные, хранимые в БД, процедуры. Это позволило использовать
такие суррогатные «триггеры» только тогда когда это необходимо, что привело к
более прозрачному функционированию БД.
Ряд полей в таблицах был исключен и заменен на поля в представлениях.
Представление (view) – объект метаданных, который формируется путем
селективного запроса из одной или нескольких таблиц.
Поле представления может состоять из объединения полей нескольких
таблиц. Применение представлений дает возможность показывать пользователю
более информативные данные, при этом не загромождая таблицы БД лишними
полями. Кроме того представления по сути является селективным запросом, и как
таковых данных не хранит, а формирует набор данных по запросу пользователя. Тем
самым экономится место на жестких дисках компьютеров.
Были модифицированы все хранимые процедуры, используемые в БД, а так
же пересмотрена концепция их использования. Решено было отказаться от связей
представлений и процедур, с целью легкого дистанционного обновления БД.
90
Рисунок 2.13 – Физическая модель БД «как надо».
91
Наличие большого количества связей непременно приводит к тому, что при
написании сценариев обновления, разработчик должен всегда учитывать данные
связи. Это могло приводить к ошибкам, возникающим в процессе выполнения
SQL-сценария. В представлениях, так мге раньше использовались процедуры,
решено было использовать селективные запросы, которые формировали наборы
данных аналогичные процедурам.
Так же с целью легкого дистанционного обновления БД было решено
вместо ряда процедур использовать блоки.
Блок (block) – временный объект метаданных, который описывается по
стандартам процедуры (языка PSQL), но уничтожается сразу же после
выполнения.
Тем самым разрываются сложные связи которые могли возникать между
процедурами, что так же могло вызывать сложности при обновлении БД.
Для хранения блоков, а так же другой необходимой служебной
информации, была создана специальная таблица STORAGE. Тем самым принятые
меры позволили значительно упростить структуры БД, с сохранением всех
возложены на нее функций, внедрить систему синхронизации БД, внедрить
систему автоматического обновления БД.
Применение блоков дает ряд преимуществ по сравнению с применением
процедур:
отсутствие связей между блоками позволяет легко модифицировать базу
данных и сами блоки;
легкое обновление блоков опытным пользователем;
возможность хранения блоков во внешних источниках данных.
Таким образом можно добиться намного более гибкой работы всей
разрабатываемой системы.
2.3.3. Структурная схема пакета (дерево вызова программных
модулей)
Исходя из проведенного информационного обследования организации
ООО «АРСЕНАЛЪ», сформулируем функции программного обеспечения для
учета страховых медицинских полисов.
92
Условно разделим программное обеспечение на ряд модулей по
выполняемым функциям (рис. 2.14):
Рисунок 2. 14 – Модули программного обеспечения по учету полисов
страхования
Разработанные модели процессов в формате «как надо» дают возможность
определить следующий перечень функций для ядра программного обеспечения:
подключение к СУБД;
взаимодействие с СУБД;
аутентификация пользователя по имени пользователя и паролю;
разделение полномочий пользователей;
протоколирование изменений в базе данных;
администрирование списка пользователей;
смена пароля пользователем;
предоставление информации пользователю в удобном виде;
обеспечение целостности данных;
обеспечение корректности данных;
работа с хранилищем блоков в режиме администратора;
легкое и дистанционное обновление клиентской и серверной части ПО;
поддержка синхронизации баз данных между собой и центральной
базой данных;
поддержка работы ПО на нескольких территориях страхования с
различными требованиями;
легкое масштабирование имеющегося ПО под изменяющиеся
требования нормативных документов, в том числе на различных
территориях страхования;
работа с внешними источниками данных (экспорт и импорт).
СУБД
Ядро приложения
Модуль учета
договоров
Модуль учета
полисов
Модуль справочной
информации
Служебный
модуль