Таблица 4.1
Классификация данных модели по их роли в процессе моделирования
| Компонент БД | Типы данных модели |
| Метаданные | данные о расчётных алгоритмах |
| Схема | качественные, структурные, точные (редко изменяемые) |
| Модель | количественные, функциональные, неточные (часто изменяемые) |
| Сценарий | входные, выходные, динамические |
Конечно, результаты моделирования далеко не сразу начинают соответствовать ожиданиям. Поэтому в процессе расчётов часто приходится возвращаться на этап идентификации констант модели, реже – на этап определения качественной схемы этой модели, а иногда даже на этап выбора вычислительных алгоритмов (см. рис. 4.2). Чтобы произвести изменение всего одного параметра (например, входного параметра сценария) и при этом не испортить уже имеющиеся наработки, обычно создают резервную копию всей базы данных. На самом деле достаточно создать версию только одного компонента базы данных – в данном случае, сценария. Если после этого потребуется подняться на уровень выше и изменить какую-либо константу модели, достаточно будет сделать это один раз, а не дважды, ведь это изменение автоматически отразится на обеих версиях сценария.
База данных (БД) в современном её понимании – это статическая совокупность данных, характеризующая состояние некоторой системы в определённый момент времени. Конечно, иногда требуется хранить и динамику развития системы. Обычно хранится лишь динамика изменения некоторых (заранее определённых) параметров системы, и для этого создаются специальные части БД (например, таблицы), в которых для каждого объекта (параметра) вводится специальный атрибут – время появления в БД. В принципе, этот стандартный подход можно применить и к системам с переменной структурой, характеризуя временем абсолютно все данные БД и создавая в ней каждый раз новые объекты вместо того, чтобы изменять старые. Однако такой подход весьма неэкономичен как в смысле объёма хранимой информации, так и в смысле скорости выполнения запросов на выборку данных (выборку всех данных в некоторый момент времени или, наоборот, выборку некоторых данных во все моменты времени). Отсутствие реально работающих динамических баз данных – лишнее доказательство неприемлемости описанного стандартного подхода к хранению истории развития систем. Современные СУБД поддерживают журнализацию вносимых в БД изменений (запоминание истории) только в целях отката и восстановления БД после сбоев.
Тем не менее, потребность одновременно хранить в БД некоторое число состояний рассматриваемой системы существует. Часто она формулируется как хранение версий БД, без привязки к динамике, то есть ко временной последовательности состояний. Наиболее распространена поддержка версий в средствах проектирования и разработки программных продуктов – в CASE-средствах. Однако такие системы версификации либо слишком зависят от структуры данных, либо являются внешними по отношению к БД. В последнем случае под версиями понимаются не зависящие друг от друга экземпляры БД, которые снабжаются некоторыми дополнительными атрибутами (в том числе временем создания, по которому происходит упорядочение версий). Поддержка версий была бы весьма полезна при создании не только программных продуктов, но и разнообразных моделей сложных систем, – хотя бы для того, чтобы в качестве версий хранить различные наборы входных данных модели с соответствующими им результатами моделирования. Однако в этой области универсальных средств версификации вообще не существует.
Проблемы, возникающие при работе с несколькими версиями, хранящимися как независимые экземпляры БД, можно проиллюстрировать на следующем примере. Пусть последовательные состояния системы отличаются лишь небольшим числом параметров, но имеют самостоятельное значение, то есть их имеет смысл хранить в качестве версий. Тогда соответствующие версиям экземпляры БД практически не будут содержать полезной информации, многократно дублируя подавляющее большинство данных. Хорошо, если версии считаются законченными, и в них не придётся впоследствии ничего изменять. Если же возможна корректировка исходных данных о системе (например, оказался неучтённым какой-либо фактор, действующий изначально или начиная с некоторого момента времени), стандартный подход к версификации приведёт не только к неоправданному расходованию ресурсов (постоянной памяти), но и к необходимости многократного повторения одной и той же работы над каждым экземпляром БД.
Другой пример касается не линейного упорядочения состояний системы во времени, а иерархического упорядочения состояний её частей. Многие БД объединяют относительно статичные, редко изменяемые данные (качественные, более-менее надёжные) и динамичные, часто изменяемые (количественные, неточно известные). При физическом разделении версий БД, соответствующих различным значениям часто изменяемых данных, возникают описанные выше проблемы дублирования данных и повторения однообразных действий над версиями при изменении статичных данных. Однако в данном случае дело осложняется тем, что изменение статичных данных желательно сопровождать удвоением числа существующих версий: половина версий будет соответствовать их старым значениям, а половина – новым. Расположение версий в их временной последовательности в этом случае абсолютно не соответствует смыслу их отличий друг от друга, который требует представления версий в виде иерархической структуры. Сравнение же версий (проясняющее смысл их различия) обычно проводится полным сравнением всех данных, что также неприемлемо, так как версии заведомо отличаются не сильно. Иерархия версий встречается в существующих средствах разработки программных продуктов, однако эта иерархия жёстко привязана к структуре данных, в частности, имеет фиксированное число уровней (например, нижний уровень – версии файлов модулей (классов), средний уровень – версии директорий групп модулей (пакетов, компонентов), верхний уровень – версии проекта в целом).
Наконец, ещё одно неприятное следствие представления экземпляра БД как единого целого проявляется при попытке повторного использования накопленных данных в близких задачах. Очевидно, некоторая часть БД (статичные данные, в терминологии предыдущего примера) является достаточно универсальной, чтобы быть полезной в других сходных БД. Но чтобы её использовать, нужно создать копию существующей БД, и «вручную» удалить из неё всё, что не имеет отношения к новой задаче, оставив только универсальную часть. При этом не может быть и речи о том, чтобы параллельно производить корректировку этой части в «старой» и «новой» БД.
Таким образом, в теории и реализации баз данных существуют следующие проблемы, особенно заметные в приложении к потребностям моделирования:
1) неэкономичность хранения (и сравнения) слабо различающихся состояний систем (версий БД), связанная с многократным дублированием данных;
2) многократное повторение одной и той же работы над версиями БД при их единообразной корректировке;
3) линейное (не иерархическое) упорядочение версий, не дающее представления о смысле различий между версиями;
4) невозможность повторного использования частей БД для решения близких задач.
Очевидно, для решения этих проблем нужно представлять БД в виде набора зависящих друг от друга частей (версий), имеющих похожую структуру (схему), но различные (не дублирующиеся) данные. Такие части ниже называются компонентами, а состоящая из них БД – многокомпонентной (МКБД). МКБД в одних случаях можно трактовать как БД со встроенной поддержкой версий, а в других – как БД для хранения истории изменения данных.
Задача состоит в том, чтобы разбиение БД на отдельные компоненты, решив перечисленные выше проблемы, не привело ни к понижению скорости выполнения запросов, ни к рассогласованию данных из разных компонентов, ни к потере целостного восприятия каждой версии БД пользователем. В качестве дополнительного преимущества многокомпонентности желательно также повысить эффективность разделения работы по заполнению БД между несколькими пользователями. Последнее особенно необходимо при рассмотрении сложных моделей, поскольку такие модели требуют привлечения нескольких специалистов различного профиля для разработки своих частей.