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

Содержание к диссертации

Введение

Глава 1. Анализ подходов представления структур данных информационной системы. постановка задачи исследования 11

1.1. Проектирование информационной системы 11

1.1.1. Понятие и классификация информационных систем 11

1.1.2. Основные методологии проектирования информационных систем 13

1.1.3. Методология анализа информационных систем на основе бизнес-процессов 18

1.2. Модели данных информационной системы 20

1.2.1. Модели представления данных 20

1.2.2. Объектно-ориентированная парадигма и ее реализация в объектных системах управления базами данных 26

1.2.3. Семантическое представление данных 30

1.2.4. Роль метаданных при описании модели данных информационной системы 36

1.3. Модели метаданных информационной системы 39

1.3.1. Использование метамодели при проектировании данных информационной системы 39

1.3.2. Концепция метадизайна и метамоделирования информационных систем 44

1.4. Приложение математической логики к моделированию данных 49

1.4.1. Математическая модель описания объектно-ориентированных данных 49

1.4.2. Использование логики предикатов для представления структур данных информационной системы. Постановка задачи исследования 52

Выводы по первой главе

Глава 2. Модель организации структур данных информационной системы при процессном подходе проектирования 59

2.1. Концептуальное описание структуры бизнес-процессов при процессном подходе проектирования информационной системы 59

2.2. Объектная модель описания структур данных информационной системы при процессном подходе проектирования на концептуальном уровне 68

2.3. Логико-алгебраическое представление структур данных и этапов бизнес-процессов на логическом уровне 74

Выводы по второй главе 94

Глава 3. Анализ объектной модели данных информационной системы при расширении функционала информационной системы на уровне предметной области 96

3.1. Общие критерии анализа объектной модели данных информационной системы на уровне предметной области 96

3.2. Логико-алгебраическое представление запросов для анализа структур данных информационной системы при расширении функционала информационной системы на уровне предметной области 99

Выводы по третьей главе 111

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

4.1. Методика проектирования структур данных для реализации сущностей предметной области информационной системы 112

4.2. Реализация модели организации структур данных на базе предприятия «Dancemaster» .

4.3. Сравнительный анализ модели организации структур данных информационной системы на уровне логического проектирования 128

Выводы по четвёртой главе 142

Заключение 143

Библиографический список

• Основные методологии проектирования информационных систем
• Объектная модель описания структур данных информационной системы при процессном подходе проектирования на концептуальном уровне
• Логико-алгебраическое представление запросов для анализа структур данных информационной системы при расширении функционала информационной системы на уровне предметной области
• Реализация модели организации структур данных на базе предприятия «Dancemaster»

Введение к работе

Актуальность темы диссертационного исследования.

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

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

В классической трёхуровневой модели ИС (уровень данных, логический уровень, интерфейсный уровень) переход от частной к абстрактной модели ведёт к потере специфики предметной области, так как все сущности метамодели находятся на одном абстрактном уровне, т.е. являются однородными. Известные подходы к представлению метаданных, такие как UML, MOF, XML и др., придерживаются именно такой логики. Однако на уровне предметной области сущности процесса управления выполняют разные функции и поэтому не могут находиться на одном уровне абстракции. Появляется потребность в определение групп сущностей процессов ИС.

Важная роль метаданных в современных информационных системах отмечена в работах М.Р. Когаловского, Ю.Е. Хохлова, С.Д. Кузнецова, Х. Шмидта и Й. Свенсона, У. Кента, Б. Лангефорса, Д. Маклеода и др. Вместе с тем указанными авторами недостаточно изучен вопрос организации метаданных для описания процессов информационной системы.

Предметная область представляет собой некоторую базу знаний (БЗ), описанную в форме конкретных фактов и правил логического вывода над базами данных (БД) и процедурами обработки информации. Одним из способов работы с БЗ является система запросов, написанная на языке предикатов первого порядка. Объектно-ориентированные языки программирования (С++, C#, Java, Delphi и др.) также могут выступать инструментом создания подобных моде-

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

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

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

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

анализ подходов представления структур данных ИС;

исследование особенностей моделирования предметной области ИС при процессном подходе проектирования;

разработка структуры этапов процессов ИС на уровне метаданных;

- определение групп объектов для описания структур данных ИС при
процессном подходе проектирования;

- создание объектной модели организации структур данных ИС;

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

разработка схемы анализа функционала ИС с помощью системы запросов к объектной модели данных;

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

Объект исследования – информационная система, ориентированная на процессное управление.

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

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

Область исследования. Работа выполнена в соответствии с пунктами 1 и 3 Паспорта специальности 05.25.05 – Информационные системы и процессы.

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

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

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

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

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

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

5. представлено логико-алгебраическое описание запросов для анализа модели в виде композиций мультиотображений.

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

6. разработана объектная модель метаданных для представления сущностей ИС; модель применима для проектирования объектов в структурно-независимых БД;

7. разработана методика проектирования структур данных для реализации сущностей предметной области ИС различного назначения средствами структурно-независимых БД;

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

Апробация результатов работы.

Работа выполнена в рамках проекта «Сколково» (проект 10 № 0000090/06.07.2011 «Научная разработка СУБД по технологии «Cobra++», реализующей принципы объектно-ориентированной СУБД третьего поколения и создание на ее основе объектно-функциональных систем и приложений».

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

9. ООО «Регул+» (г. Санкт-Петербург);

10. ООО «Древремстрой» (г. Кострома).

Основные положения диссертационной работы изложены в докладах на 4 научно-практических конференциях:

11. Х-ой Международной научно-практической конференции «Новости научного прогресса» (г. София, 17-25 августа 2014 г.);

12. X-ой Международной научно-практической конференции «Передовые научные разработки» (г. Прага, 27 августа – 5 сентября 2014 г.);

3. VIII-ой Международной научно-практической конференции «Научное обозрение физико-математических и технических наук в XXI веке» (г. Москва, 29-30 августа 2014 г.);

4. XLVIII-XLIX-ой Международной научно-практической конференции «Технические науки – от теории к практике» (г. Новосибирск, 26 августа 2015 г.).

Публикации. По теме диссертации опубликованы 13 печатных работ авторским объемом около 2,4 п.л. (из них шесть – в соавторстве), в т.ч. 3 статьи (авторский объем – 1,6 п.л.) в изданиях, рекомендованных ВАК Минобрнауки РФ для опубликования основных научных результатов диссертаций на соискание ученых степеней доктора и кандидата наук.

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

Основные методологии проектирования информационных систем

Объектно-ориентированный подход включает в себя анализ, направленный на проектирование моделей, более близких к реальности. В этой методологии требования к системе задаются на основе понятий классов и объектов, определяемых предметной областью. По сравнению со структурным подходом объектно-ориентированный подход имеет ряд преимуществ: - представление системы в виде объектов более соответствует понятийному смыслу предметной области. Например, при использовании структурного подхода база данных обязана удовлетворять требованиям некоторой формы нормализации, в соответствии с которой данные по одной и той же сущности реального мира могут содержаться в нескольких таблицах, что противоречит естественной природе сущностей; - инкапсуляция объектов, а также объединения атрибутов и методов в объекте позволяют создать более сильную внутреннюю связность и более слабую внешнюю связность между элементами информационной системы; - поведение объектов реального мира при объектно-ориентированном проектировании системы отображается с помощью задания методов класса, тогда как в структурном подходе данные и схемы поведения существуют раздельно друг от друга; - наличие множества Case-средств проектирования, позволяющих достичь значительной степени автоматизации генерации кода. Различные Case-средства, основанные на структурном подходе, достаточно хорошо справляются с проектированием структур баз данных, удовлетворяющих требованиям нормализации, что, естественно, накладывает существенные ограничения. Поэтому автоматическая генерация, например, функций обработки и анализа данных практически невозможна. Описанные преимущества объектно-ориентированного подхода позволяют легче справляться со следующими задачами проектирования ИС: 1) постоянная адаптация системы к изменению существующих или появлению новых требований и условий; 2) многократное использование уже созданных компонентов; 3) поддержка и сопровождение ИС на разных стадиях жизненного цикла; 4) поддержка организации параллельных вычислений за счёт того, что каждый объект обладает своими собственными значениями атрибутов и методами поведения, независящими от других объектов.

Целью начальных этапов создания ИС является формирование требований к ИС, правильно и точно отражающих цели и задачи организации. Для описания процесса создания ИС, отвечающей целям и задачам предприятия, необходимо определить, в чём заключаются эти цели и задачи. Необходимо выяснить требования заказчиков к информационной системе и записать их на языке моделей в требования к разработке проекта ИС таким образом, чтобы соблюсти соответствие целям и задачам предприятия [78].

Современные программные средства (Case-средства) позволяют достаточно быстро проектировать и создавать ИС по готовым требованиям. Практически всегда оказывается, что эти системы частично или даже полностью не удовлетворяют заказчиков. Системы приходится постоянно подвергать доработке, что приводит к резкому повышению реальной стоимости ИС предприятия. Неточное или неполное определение требований к ИС является главной и основной причиной такого положения. Зачастую заказчики не могут точно и правильно сформулировать и определить требования к разрабатываемой ИС. К тому же во многих случаях они не способны точно определить основные цели и задачи своей организации. На разработчиков ложится задача по получению подобной информации от заказчиков. В настоящее время одной из наиболее трудных для формализации и наиболее дорогих в исправлении в случае возникновения ошибки является проблема формирования требований к разрабатываемой ИС. Именно поэтому момент формирования, выявления и последующей формализации на начальной стадии жизненного цикла проектирования и разработки ИС является важнейшим этапом для успешного получения конечного результата.

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

Объектная модель описания структур данных информационной системы при процессном подходе проектирования на концептуальном уровне

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

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

Помимо групп сущностей, полезно определить и группы атрибутов сущностей – «группировки атрибутов». Это позволит ввести смысловые блоки, связанные семантически и относящиеся к разным сторонам моделирования сущностей. Например, удобно сгруппировать поля, относящиеся к данным о человеке (ФИО, возраст, пол и т.д.).

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

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

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

Концепция метадизайна и метапроектирования рассмотрена в работах многих отечественных и зарубежных авторов. Большую роль описания метаданных на всех стадиях жизненного цикла ИС, а особенно на стадии проектирования, отмечают Ю.И. Рогозов, А.С. Свиридов [82]. Так как разработка информационных систем в большей степени относится к задачам человеческой деятельности, которая сопровождается сложным взаимодействиям участников и выполняемых процессов, то значительный вклад в результат разработки привносят фиксация и учет требований заказчика. Недостаточно полное и четкое описание требований ведет к значительному увеличению бюджета проекта, сроков его выполнения и трудностям при переносе этих требований в готовую систему. Решить проблему можно разными путями. Например, на стадии создания и проектирования информационной системы основной акцент сделать на развитии методов обследования и управления требованиями с целью более четкой и грамотной фиксации требований заказчика [83]. С другой стороны, максимальное вовлечение заказчика как в процесс создания ИС, так и в процесс устранения разногласий также поможет сократить возможные несоответствия. Основой второго подхода является парадигма метадизайна [116]. Такой подход позволяет вовлечь пользователя в процесс разработки конечного продукта, отвечающего его требованиям.

Концепция метадизайна предусматривает создание специального комплекса методов, моделей и инструментов, а также пользователей, разработчиков и проектировщиков. Такой комплекс взаимосвязанных элементов функционирует не только на стадии разработки, то и фактически является конечным продуктом, т.е. системой, эксплуатируемой пользователем. При этом основная задача смещается с создания прикладной информационной системы на создание и проектирование инструмента, с помощью которого пользователь реализует необходимую ему информационную систему. Процесс формирования такой подходящей среды будет проходить в несколько этапов [82]: - на первом этапе формируются сведения о предметной области и объекте разработки. На этом этапе привлекаются как разработчики, так и конечные пользователи; - на втором этапе происходит проектирование готовой системы самими пользователями с помощью предоставленных инструментов; - третий этап характеризует состояние среды, пригодной для использования в прикладных целях. Имеются данные и правила бизнес процессов. При этом следует помнить, что для успешного применения метамодели важно не только участие конечного пользователя, но и технические составляющие среды. Классически информационная система является моделью объекта, которая используется для частичного выполнения процессов предметной области в автоматизированном режиме. Весь процесс разработки представляет собой последовательность построения и модификации моделей, описывающих один исходный объект. Поэтому информационная система является очень ограниченной к применению других объектов и с трудом приспосабливается к изменениям. Если использовать метамодель в качестве основной модели, то при заполнении ее данными она будет давать представление не одного объекта, а информационной системы в целом. Более легкая модификация информационной системы будет достигаться путем изменений значений. При этом говорить о том, что можно создать универсальную модель для любой предметной области, было бы неверно. Поэтому чаще всего приходится иметь дело с метамоделью, описывающей информационные системы, основанные на одной технологии или построенные на предметной области конкретного типа.

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

В работе Л.Н. Лядовой [70] рассмотрен пример классического метамоделирования при создании информационной системы в виде четырехуровневой иерархии моделей (рис. 1.7). При этом каждый вышестоящий уровень в иерархии задает язык описания для следующего за ним уровня.

Логико-алгебраическое представление запросов для анализа структур данных информационной системы при расширении функционала информационной системы на уровне предметной области

Описание представленных множеств и констант происходит в соответствии с объявленными объектами и процессами предметной области.

Множества О, Н, А, В, ВР изменяют свою мощность в зависимости от составляющих модели. При этом указанные множества должны быть конечны или счетны. В нашем случае данное правило выполняется - число объектов, свойств, имен и бизнес-процессов моделируемых данных конечно или, по крайней мере, счетно. Многоосновная алгебраическая система А = (&, Ґ) представляет модель метаданных информационной системы с основным множеством @ = OVJHVJAVJBVJBPи сигнатурой . Используя элементы базовых множеств, определим отношения объектов, свойств и типов. Как было отмечено выше, описывая предикат, задающий отношение переменных, введем соответствующее множество истинности.

Согласно введенным обозначениям, опишем предикат, назначающий некоторому объекту из множества О тип из множества К obj_type((9,if). Множество, на котором определен данный предикат, имеет следующий вид: Mot =ОхК {(0і,кр)\\/0ієСВ.крєК} - множество пар, первый элемент принадлежит множеству О, для которого существует единственный элемент множества К - второй элемент пары. Таким образом, данный предикат устанавливает однозначность соответствия объекта и его типа. В конкретном варианте предикат будет иметь в качестве аргументов элементы заданных множеств - obj_type(oy, ). Благодаря введенному предикату, можно классифицировать все объекты, согласно поддерживаемому типу: SD={ot objtypeK 1)} - множество объектов - простых справочников; CD={ot obj_type(o,-, 2)} - множество объектов - сложных справочников; F={ Oi I obj_type(o,-, 3)} - множество объектов - показателей; ОС={ Oi obj_type(o,-, 4)} - множество объектов контроля; ОМ={ Oi obj_type(o,-, 5)} - множество объектов управления. Таким образом, все множество объектов определяется как объединение указанных непересекающихся множеств (несвязное объединение): О = SD+CD+F+OC+OM Аналогичным образом описываются предикаты, задающие тип элементарных свойств, имена свойств и объектов: prop_type(#,7) - предикат, назначающий некоторому свойству из множества Н тип из множества Т. Предикат определен на множестве Mpt =HxT= {(hj,tu)\Vhj єН,3\їи є Г} Предикат с заданными константами имеет вид: prop_type(hj, tu). ргор_пате(Я, ) - предикат, назначающий некоторому свойству из множества Н имя из множества А. Предикат определен на множестве Mpn=HxA {{hj,aj)\yhj H\3.aj A/\3tu T\prop_type{hj,tu)} prop_name(/z/, а/) - подстановка предикатных констант. obj_name(a) - предикат, назначающий некоторому объекту из множества О имя из множества В. Предикат определен на множестве Моп =ОхВ {{оі,Ьі)\\/оієО\З.ЬієВ A k&K.obj _type{ok,kp)} Для каждого объекта из множества О существует единственный объект из множества В при наличии существования типа объекта множества О. obj_name(o,, Ы) - подстановка предикатных констант. С введением предикатов, описывающих свойства объекта, возникает необходимость введения понятия версионности, уникального идентификатора информационного объекта и фиксации объекта.

Уникальный идентификатор информационного объекта (УИИО) - это набор реквизитов информационного объекта, позволяющий однозначно идентифицировать экземпляр объекта системы составного типа [36]. Состав УИИО предполагает наличие не только собственных реквизитов объекта, но и возможность включения свойств вложенных объектов, находящихся в одной зоне видимости. Структура объекта с выделенным УИИО может быть зафиксирована и определяет конкретную версию объекта. Не требует УИИО лишь объект типа показатель. Дальнейшие модификации структуры влекут за собой создание новых версий. Для нумерации версий объектов воспользуемся множеством натуральных чисел - N, п - номер версии объекта.

Введем предикат версионности: version(0,#) - предикат, устанавливающий соответствие между объектом и его версией. Предикат определен на множестве Mv = О х N и {(о,, п) ог є О, п є Щ version ,-, п) - версия конкретного объекта. Введем предикат, описывающий элементарное свойство объекта, и соответствующее множество истинности имеет вид: 8_ргор"(адя) M sp =Ох N х Н {(onn,hj)\oi єО:(ЗЬ1 еВ оЦпатф Ь Хпе Ы, version(o,,n),/7/. єН:(За: єА,ргор_пате(/г,аЛ)} Множество истинности предполагает, что объекту может быть назначено свойство, если для объекта задано имя, версия структуры, имя свойства.

В данном случае следует отметить, что некоторые свойства будут входить в состав УИИО, т.е. имеет место конструкция uiio{pi,n,hpoi,y ), которая логически будет раскрыта позже, в виду того, что в УИИО могут входить не только собственные элементарные свойства объекта, но и свойства одной зоны видимости. Опишем лишь значение предикатных переменных без обоснования множества истинности: uiio(ot,n,hj,ot,yM) - объект о, версии п имеет свойство hj - свойство объекта Of в качестве УИИО под номером у . В данном случае происходит повторное упоминание объекта ot , т.к. на предмет принадлежности УИИО рассматриваются именно элементарные свойства самого объекта. В общем случае, свойство hj может принадлежать объекту о зоны видимости исходного объекта.

Исходя из введенных понятий, множество истинности предиката s_prop ((9,7V,//) позволяет соблюсти следующие условия: элементарное свойство hj может входить в состав объекта о, если для объекта и свойства определены имена. Дополнительно указывается номер версии объекта, которому принадлежит данное свойство. Предложенных предикатов достаточно для моделирования справочной информации системы, то есть для определения структур объектов-справочников. Множество всех зафиксированных версий объектов определим как О = {о [о,. є О \ F,3hj eH,neN: uuoip h o yм)] v v[o,. eF:3A7. є#,иє#]}

В это множество включены объекты всех типов (за исключением показателей), обладающих УИИО, а также объекты-показатели, имеющие в структуре хотя бы одно элементарное свойство. Первоначально это множество формируется из объектов-справочников и показателей, образуя тем самым базовую справочную систему предметной области и систему показателей. По мере создания объектов множество O расширяется.

Реализация модели организации структур данных на базе предприятия «Dancemaster»

Для финансового обслуживания клиентов открываются лицевые счета (account). Каждый лицевой счет связан с некоторым контрактом, и для одного контракта может быть открыто несколько лицевых счетов. Еще одним понятием процесса оказания услуг является учетная запись (ip_user), используемая при авторизации на сетевом оборудовании. В учетной записи хранятся логин и пароль для подключения. Каждая учетная запись связана с некоторым лицевым счетом и для одного лицевого счета может быть создано несколько учетных записей. Таким образом, имеется иерархическая структура «клиент – контракт – лицевой счет – потребитель услуг», все элементы которой связаны отношениями «один ко многим».

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

Спроектируем модель реляционной базы данных, исходя из принципов объектного похода. Названиями таблиц являются наименования классов объектов на английском языке в единственном числе. Перечисленные при описании предметной области контракты, лицевые счета и т.п. хранятся в таблицах contract, account и т. д., каждая из которых имеет в качестве первичного ключа столбец n, в котором хранятся системные номера.

В формулировке задачи далее будут встречаться выражения вида «номер контракта», «номер лицевого счета» и т.п. для всех объектов их номерами являются системные номера, то есть значения столбца n соответствующей таблицы. Некоторые столбцы таблиц являются кодируемыми (словарными). Кодируемый столбец принимает значения из фиксированного списка. Например, тип платежа может быть только элементом следующего списка значений: - наличными; - кредитной картой; - банковским переводом. Каждому такому термину присваивается уникальный для этого списка код. Пары «код-термин» вида (1; наличными), (2; кредитной картой) и т. д. называются словарным статьями, а их совокупность образует словарь, который в данном случае называется «Тип платежа». Для экономии места и обеспечения однообразия представления информации для наличных платежей в таблице payment в столбце typе не заносится слово «наличными», а проставляется код 1. Для платежей кредитными картами проставляется код 2 и т.д.

Обычно для каждого словаря в базе данных создают отдельную таблицу с двумя столбцами – один столбец для кодов, второй столбец для терминов. В нашем случае все словари будем хранить в одной таблице dic_data, в которой к столбцам code и term для кодов и терминов дополнительно добавлен еще один столбец r$dic. В этом столбце проставляется номер словаря, к которому относится запись в таблице dic_data.

Связи «один ко многим» реализуются через механизм внешних ключей, при этом название каждого столбца внешнего ключа сформировано как название таблицы, на которую он ссылается с префиксом r$ (r – reference). Например, столбец r$person таблицы passport ссылается на таблицу person, то есть он содержит значения идентификаторов (системных номеров из столбца n таблицы person) лиц, которым принадлежат паспорта. Таким образом, чтобы «связать» людей и их паспорта, необходимо выполнить запрос с соединением таблиц person и passport по условию person.n = passport.r$person. Аналогично платежи и лицевые счета, на которые они поступили, «вяжутся» соединением с условием payment.r$account = account.n. А наличие столбца r$dic в таблице dic_data говорит о том, что есть таблица dic, в которой хранится описание всех словарей, и словарные статьи в dic_data «висят» каждая под записью о своем словаре в таблице dic.

Связи «многие ко многим» традиционно принято хранить в таблице с двумя столбцами, которые содержат пары идентификаторов связанных объектов. Принято связи каждого вида хранить в отдельной таблице, но, так же как и со словарями, связи «многие-ко-многим» всех видов будут храниться в одной таблице links. В таблице links помимо пары столбцов с идентификаторами есть столбец r$link, в котором проставляются номера видов связей. На рисунке 4.9 показана связь «многие-ко-многим». Общая схема реляционных таблиц показана на рисунке 4.10.