4. Физическое моделирование аспу

Физическое моделирование АСПУ является переходом от ее логической модели к непосредственной реализации программного комплекса и базы данных системы.

Мы не будем останавливаться подробно на архитектурных особенностях АСПУ и описании процесса реализации ее программного обеспечения.

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

Однако наиболее важным является этап разработки модели данных АСПУ.

И это вполне объяснимо: база данных является ключевым компонентом OLTP-систем, а все известные методологии их проектирования основаны на приоритетности разработки устойчивой реляционной модели данных.

2.4.1. Разработка модели данных аспу

Цель моделирования данных АСПУ состоит в обеспечении разработчика концептуальной моделью данных, которая в дальнейшем преобразуется в реляционную модель базы данных системы.

К. Дейтом дано определение реляционной модели данных, как формальной теории данных, основанной на некоторых положениях математики (в основном, теории множеств и логики предикатов) и положенной в основу реляционных систем [13].

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

В реляционной модели данных рассматриваются три принципиальных аспекта данных – структура данных, сохранение их целостности и манипулирование данными.

Структурный аспект касается собственно отношений, аспект целостности имеет отношение (помимо всего прочего) к первичным и внешним ключам базы данных, а аспект манипулирования данными связан с операторами языка структурированных запросов SQL (Structured Query Language).

Высокий уровень нормализации базы данных ²⁰ в OLTP–системах необходим для обеспечения оптимальной производительности базы данных и приложения [69].

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

Следует отметить, что в АСПУ с интегрированными элементами моделирования база данных помимо хранения учетных данных обеспечивает хранение шаблонов и отдельных элементов моделей производственного учета.

В бизнес-моделировании для разработки модели данных АИС рекомендуется использовать методологию IDEF1Х, входящую в семейство стандартов IDEF и используемую в популярном CASE-средстве моделирования данных ERWin [30,67].

Отметим, что методология IDEF1X относится к типу методологий «сущность - связь» и специально разработана для построения реляционных баз данных. В этой связи целесообразность ее использования при проектировании АСПУ не вызывает сомнения.

Методология IDEFIX подразделяется на логический и физический уровни, соответствующие проектируемой модели данных системы.

Логический уровень моделирования данных позволяет создавать концептуальную модель данных, базирующиеся на понятии ER- диаграммы (Entity Relationship Diagram, диаграммы «сущность-связь»), представляющей модель данных в виде сущностей, их атрибутов и отношений между ними.

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

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

Во многих современных работах в качестве основы для построения физической модели данных рекомендуется использовать объектную логическую модель АИС на языке UML, а для перевода классов логической модели в реляционную модель IDEF1X - встроенный инструментарий известных CASE-средств (Rational Rose Data Modeler, ERwin Translation Wizard) [16,30].

Так, в программном продукте Rational Rose Data Modeler в основе взаимной трансформации физической модели данных и объектной модели АИС лежит метод, устанавливающий соответствие между элементами указанных моделей (табл. 2.2)

Таблица 2.2