Объектно-ориентированный подход (стр. 16 из 22)

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

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

4.3. Пример использования: архитектура базы данных обобщённой модели

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

4.3.1. Описание схемы БД

Особенности методологии моделирования, приведшие к разделению базы данных обобщённой модели на четыре функционально различные части (данные сценария, модели, схемы и метаданные), изложены в разделе 4.1.1.2 и проиллюстрированы на рис. 4.2. Ниже приводится более конкретное описание схемы базы данных – названия таблиц и способы их использования. На рисунках таблицы изображены в виде овалов, использующие их блоки программы – в виде "человечков", а способы их использования (направления передачи данных) – в виде стрелок. Данная нотация широко применяется средствах проектирования программных продуктов (CASE-средствах) и носит название Use Case View. Схемы отдельных таблиц, которые обычно представляются на диаграммах Logical View, здесь не рассматриваются, поскольку особенности МКБД проявляются лишь на более высоком, чем атрибуты таблиц, уровне.

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

Рис. 4.3. Таблицы метаданных

Рис. 4.4. Таблицы данных схемы модели

Рис. 4.5. Таблицы данных модели

Рис. 4.6. Таблицы данных сценария

4.3.2. Преимущества и недостатки четырёхуровневой БД

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

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

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

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

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

База данных
				…		Компонент 1		Компонент 2
…		Компонент 1.1		Сценарий 1.2		……
…		Компонент 1.1.1				Сценарий 1.1.2		……

Рис. 4.7. Архитектура базы данных обобщённой модели

4.4. Резюме

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