2.2.1Область неэффектиности реляционной модели данных.

В программе моделирования ординарных сетей Петри подмножество реляционных отношений {T, S, ST, TS} семантически «сильно связана» и даже выделется нами как статическая часть сети Петри (т.е. без меток и активных переходов). Смысл этой «сильной связанности» мы можем объяснить алгоритмом имитационного моделирования. Например, нам требуется пройти по всем входным ветвям пассивных мест-переходов T сети и определить новые места-переходы, которые станут активными в некоторый момент времени.

Алгоритм прохода по пассивным местам-переходам на «псевдокоде».

for(int i=0; i <|T|; i++) { // T[i] – текущий кортеж отношения test(T)

for(int j=0; j <|EC|; j++) // EC[j] – текущий кортеж отношения test(EC)

if(T[i].TN == EC[j].TN) goto A; // i–ый перехода активен

// это пассивный переход, нужна обработка “входов” i-ого пассивного перехода ...

А: continue; } // активный переход, исключается из обработки

Оценка вычислительных затрат в случае реляционной модели данных для данного алгоритма составит Const*|T|*|EC|/2 итераций.

Очевидно, что реляционные отношения test(T) и test(EC) связаны по одноименному атрибуту TN. Напомним, что T={TN,TD} и EC={TN,TK}. Нам ничто не помешает выполнить операцию их полусоединения

test(TN,TD,TK) = test(TN,TD)<test(TN,TK)

и последующую факторизацию (но это нереляционная операция!) на два отношения

test(TN,TD,INDX) и test(INDX,TK)

где INDX – атрибуты служебного индекса. Если каждое из построенных реляционных отношений хранится в памяти как контейнер кортежей, то поддержание индексной связи (а она по определению будет “один (не все) к одному (всем)”, не вызывает проблем. Но календарь событий изменяется динамически на каждом шаге по времени! Повторять указанные реляционные операции на каждом шаге было бы безумием. Но это не потребуется, если мы используем объектно-ориентированный подход.

2.2.2Идея преобразования реляционной модели данных в объектную.

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

Программные приложения жеско требуют, чтобы ИБД программного комплекса могла хранить исходные данные и результаты расчетов для каждого процесса вычислений. Но использование этих данных в каждом из приложений может быть очень различным и определяется особенностями алгоритма вычислений. Хотим мы того или нет, но во время работы алгоритма приложения мы всегда имеем базу данных времени его выполнения (БДВВ или RTDB – Run Time Data Base). Обычно она организуется программистами на языках уровня С++, что наиболее гибко позволяет учесть специфику реализуемого алгоритма. Объектно-ориентированная парадигма программирования использует это для создания БДВВ приложения в стиле объектно-ориентированных баз данных (ООБД).

Объектная база данных использует не реляционный, а иной (объектный) принцип для политики “Разделяй и властвуй” при создании сложных программных приложений, в которых требуется выполнение жеских условий на время выполнения операций с данными. В силу сложности ответа на общий вопрос: “Что такое объект?”, мы используем более простую (и математически не строгую) формулировку: “Все элементы данных и поддержания связей между ними, которые находятся в отношении эквивалентности – могут образовать объект”.

Основная идея объектного подхода состоит в построении системы классов объектов как системы локальных сущностей (т.е. класс становится аналогом некоторой алгебры над своими экземплярами). Это требует локализовать операции с экземплярами (что несколько усложняет программу), но обеспечивает более легкое понимание логики и облегчает развитие приложения. Особо следует отметить расширение технологических возможностей по поддержке связей. В реляционной модели мы имеем основную связь между кортежами (а это обычно контейнер), а остальные связи поддерживаются по совпадению значений в атрибутах кортежей (см. реляционную алгебру). Введение для последних индексов ускоряет процессы поиска, но слишком дорогой ценой.

Ниже мы рассмотрим возможные варианты организации поддержки связи между элементами сущностей «T» и «ЕС» как экземплярами реляционных отношений и объектное представление их соединения (а не только посредством значения индексного атрибута). Потом аналогичную процедуру мы сделаем для соединения с ними реляционного отношения «ST» в рамках примера сети Петри «test».