Анализ пригодности существующих способов создания динамических баз данных к задачам моделирования

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

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

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

Другой пример касается не линейного упорядочения состояний системы во времени, а иерархического упорядочения состояний её частей. Многие БД объединяют относительно статичные, редко изменяемые данные (качественные, более-менее надёжные) и динамичные, часто изменяемые (количественные, неточно известные). При физическом разделении версий БД, соответствующих различным значениям часто изменяемых данных, возникают описанные выше проблемы дублирования данных и повторения однообразных действий над версиями при изменении статичных данных. Однако в данном случае дело осложняется тем, что изменение статичных данных желательно сопровождать удвоением числа существующих версий: половина версий будет соответствовать их старым значениям, а половина – новым. Расположение версий в их временной последовательности в этом случае абсолютно не соответствует смыслу их отличий друг от друга, который требует представления версий в виде иерархической структуры. Сравнение же версий (проясняющее смысл их различия) обычно проводится полным сравнением всех данных, что также неприемлемо, так как версии заведомо отличаются не сильно. Иерархия версий встречается в существующих средствах разработки программных продуктов, однако эта иерархия жёстко привязана к структуре данных, в частности, имеет фиксированное число уровней (например, нижний уровень – версии файлов модулей (классов), средний уровень – версии директорий групп модулей (пакетов, компонентов), верхний уровень – версии проекта в целом).

Наконец, ещё одно неприятное следствие представления экземпляра БД как единого целого проявляется при попытке повторного использования накопленных данных в близких задачах. Очевидно, некоторая часть БД (статичные данные, в терминологии предыдущего примера) является достаточно универсальной, чтобы быть полезной в других сходных БД. Но чтобы её использовать, нужно создать копию существующей БД, и «вручную» удалить из неё всё, что не имеет отношения к новой задаче, оставив только универсальную часть. При этом не может быть и речи о том, чтобы параллельно производить корректировку этой части в «старой» и «новой» БД.