CC BY
68
ИНФОРМАТИКА
УДК 519.673: 004.9
АВТОМАТИЗАЦИЯ СИНТЕЗА БАЗ ДАННЫХ СИСТЕМЫ СИТУАЦИОННОГО МОДЕЛИРОВАНИЯ ПО ИХ КОНЦЕПТУАЛЬНОМУ ОПИСАНИЮ*
А. Я. Фридман
ФГБУН Институт информатики и математического моделирования технологических процессов КНЦ РАН
Аннотация
Представлены средства автоматической генерации реляционных баз данных, необходимых для конструирования модели, выполнения имитационного моделирования промышленно-природных комплексов (ППК), хранения и анализа его результатов с учетом возможности оперативного изменения структуры модели, а также средств моделирования компонентов ППК. Основное достоинство предложенного способа создания БД состоит в том, что пользователь непосредственно формирует только концептуальную модель данных с использованием привычных ему терминов, а создание файловой структуры БД и выборка необходимых подсхем данных производится в соответствии с заданными описаниями автоматически. Ключевые слова:
концептуальная модель, пространственный динамический объект, автоматическая генерация баз данных, имитационное моделирование.
CONCEPTUAL-DESCRIPTION-BASED AUTOMATION OF DATABASES SYNTHESIS IN SITUATIONAL MODELING SYSTEM
Alexander Ya. Fridman
Institute for Informatics and Mathematical Modelling of Technological Processes of the KSC of the RAS
Abstract
The paper introduces automatic means to generate relational databases necessary to create a model of an industry-natural complex (INC), simulate its functioning, store and analyze results of this simulation considering operative changes of the model structure and software to simulate the INC components. The major advantage of the proposed technique of DBs generation is that a user has to just design a conceptual model of an INC based on his/her customary terms while DBs files structure generation and specification of necessary data subschemas, according to the given descriptions, are accomplished automatically.
Keywords:
conceptual model, spatial dynamic object, automatic generation of databases, simulation. Введение
Различные вопросы анализа и синтеза сложных объектов в настоящее время решаются с помощью информационно-аналитических систем (ИАС). Их функционирование связано с вводом, обработкой, хранением и выдачей в соответствии с требованиями пользователей разнородной информации, которую нельзя регламентировать и стандартизовать заранее. Эффективность и качество подобных ИАС существенно зависят от методов и технологии автоматизации проектирования их баз данных (БД). Поскольку количество, структура и объем необходимых данных определяется непосредственно в
^Работа частично поддержана грантами РФФИ (проекты № № 14-07-00256-а, 14-07-00257-а, 15-07-04760-а, 15-07-02757-а).
ходе эксплуатации ИАС, необходимо включать в их состав средства автоматической генерации БД. Одно
из направлений повышения оперативности и гибкости структуры БД ИАС - использование при их разработке принципа типизации, реализуемого применением адекватных экономическим и организационным условиям моделей и методов синтеза типовых структур локальных и распределенных баз данных. В то же время существующие методологии разработки, а также инструментальные и программные средства автоматизации проектирования и сопровождения БД, как правило, не обеспечивают комплексных решений, не поддерживают многих функций автоматизации проектирования БД [1-3]. Изложенное обосновывает актуальность темы настоящей работы, в которой предлагается метод автоматической генерации стандартизованных таблиц данных на основе их пользовательского описания в концептуальной модели предметной области (КМПО) ИАС. Без потери общности изложение ведется на примере ситуационной системы моделирования (ССМ) [4-7], которая представляет собой ИАС для исследования иерархических пространственных динамических объектов, в частности промышленно-природных комплексов, и, соответственно, содержит встроенные геоинформационную (ГИС) и экспертную (ЭС) системы, что вносит специфику и в организацию БД ССМ. Основа КМПО - не алгоритмическая модель передачи и преобразования данных, как в аналитических моделях, а декларативное описание структуры объекта и взаимодействия его составных частей. Таким образом, КМПО изначально ориентирована на формализацию знаний экспертов. В КМПО определяются элементы исследуемой предметной области и описываются отношения между ними, которые задают структуру и причинно-следственные связи, существенные в рамках определенного исследования. КМПО поддерживает соответствие между реальным ППК и его моделью.
Как следует из названия, любой ППК включает природные и технические объекты. Каждый такой объект может представлять собой многоуровневую систему подобъектов, связанных различными сигналами, которые моделируются потоками данных и трактуются в ССМ как ресурсы, используемые и/или расходуемые объектами в ходе их жизнедеятельности. Изменения ресурсов внутри объектов описываются в модели некоторым набором процедур или функций, именуемых процессами. Для анализа поведения ППК и сравнения различных наборов значений ресурсов между собой используются один или несколько критериев качества -функционалов, определенных на тех или иных наборах ресурсов. Таким образом, в КМПО ППК описываются три вида элементов (сущностей) реального мира - объекты, процессы и данные (или ресурсы). Объекты отображают организационную и пространственную структуру моделируемого комплекса с каждым из них можно связать набор процессов. Под процессом понимается некоторое действие (процедура), преобразующее подмножество данных, называемых входными по отношению к рассматриваемому процессу, в другое их подмножество, именуемое выходным. Данные характеризуют состояние системы. Они используются при реализации процессов, являются результатами их выполнения. Выполнение любого процесса изменяет данные и соответствует переходу системы из одного состояния в другое. Взаимосвязи и взаимодействие объектов реального мира описываются с помощью отношений на множествах элементов модели. Имена элементов КМПО задаются в терминах предметной области, как правило, каждому элементу модели назначается исполнитель, обеспечивающий его реализацию в ходе моделирования. Тип исполнителя определяет характеристики реализации, например, язык программирования, на котором реализуется исполнитель некоторого процесса, и тип исполнителя в алгоритмическом языке.
Организация баз данных ситуационной системы моделирования
Значения исходных данных для проведения моделирования могут вводиться в ССМ либо из базы экспериментальных (исходных) данных (БИД), либо из базы, в которой хранятся сценарные данные, соответствующие желаемой или предполагаемой динамике объекта
исследования. Для имитации используются встроенные функции и библиотека программных модулей (БИЭЗ), имитирующих представленные в КМПО процессы, ссылки (указатели) на процессы обработки данных также хранятся в БД.
В ССМ применяются реляционные базы данных, которые наиболее распространены в приложениях, несмотря на наличие альтернативных принципов построения БД [8]. В качестве стандартного формата хранения данных в исследовательской версии ССМ принят формат DBF, поскольку его поддерживает используемая в настоящее время ГИС ArcInfo.
Базу данных ССМ можно разделить на две части: предметно-зависимую и предметно-независимую, структура файлов первой части постоянна и не зависит от предметной области, в которой применяется ССМ, структура файлов второй части БД определяется структурой КМПО, т. е. проведенной пользователем декомпозицией понятий и связей элементов объекта исследования. В первую часть входят базы данных основных подсистем ССМ: КМПО, ЭС и ГИС, вторую часть назовем базой данных предметной области (БДПО), ее структура синтезируется автоматически на различных этапах работы ССМ. В первых версиях ССМ БДПО была реализована в виде файловой структуры, последние версии используют идеологию сервера SQL [2]. Далее, если это не вызывает разночтений, БД будет называться каждая реляционная таблица, содержащая записи определенного типа.
При разработке баз данных ССМ, кроме обычных принципов проектирования БД, ориентированных на повышение эффективности процедур поиска, были приняты меры по устранению возможных ошибок, часто вызываемых различным написанием строковых величин. Поэтому все процедуры логической обработки, поиск, сортировка и т. д. выполняются только по служебным числовым кодам, присваиваемым именам и значениям данных в ходе их ввода в компьютер. Строковые величины используются только при визуализации данных. Даже списковые данные, имеющие числовые значения, обрабатываются по такому же принципу [4]. Это дает возможность осуществлять контроль диапазонов значений величин, хранимых в полях переменной длины (далее они называются еще memo-полями [2]), не обращаясь к содержимому этих полей. Кроме того, тем самым существенно упрощается изменение языка, на котором ведется диалог с пользователем (например, переход с русского языка на английский). Ниже, кроме специально оговоренных случаев, при упоминании значения строковой величины имеется в виду соответствующий ей код, доступ к строковым данным осуществляется через специальные справочники, структура которых поясняется при описании использующих их баз.
Рассмотрим структуру основных баз данных, присутствующих во всех реализациях ССМ, поскольку в каждом приложении по пожеланиям заказчика создавались дополнительные специализированные БД, включаемые обычно в БДПО.
База данных концептуальной модели
Одно из требований к системе моделирования состоит в обеспечении хранения модели предметной области, созданной пользователем в режиме редактирования. Назначение БД КМПО состоит в хранении и обеспечении ускоренного доступа к характеристикам элементов модели и связей между ними. Для создания БД хранения концептуальной модели в ССМ используется принцип модели сущность - связь (ER-модели) [2]. Как уже упоминалось, в КМПО имеются три множества сущностей - это множество процессов P, множество объектов O и множество данных (ресурсов) Res. Множества однотипных связей образуют отношения, заданные между объектами КМПО в явном виде: ОР, РО, и отношения, определяемые косвенно: объект -суперобъект, объект - приписанные к нему процессы, процесс - последующий процесс, данное -процессы-генераторы, данное - процессы-потребители.
Наиболее удобной для хранения данных, имеющих древовидную структуру, представляется вторая нормальная форма. Установленные на КМПО иерархические и другие отношения между объектами можно отобразить в реляционной структуре в виде ключей идентификации строк таблицы. Если из атрибутов таблицы, содержащей экземпляры данных
некоторого уровня иерархии КМПО, построить ключевое выражение для строк таблицы, содержащей экземпляры подобъектов, то выбор экземпляра объекта верхнего уровня будет однозначно определять выбор соответствующих экземпляров подчиненных данных. Таким образом в физическую структуру БДПО закладывается система ссылок, соответствующих отношениям, заданным на КМПО.
Иерархическая структура в этом случае определяется по системе встроенных указателей [6]. Для каждого элемента КМПО в базе данных КМПО создается одна запись, тип полей записи определяется форматом фреймов элементов КМПО. В запись включается набор указателей -ссылок на другие записи, которые соответствуют элементам модели, вступающим с рассматриваемым в определенные отношения. Под указатели на управляющее данное и суперданное (при его наличии) отводится по одному полю записи, в которые помещаются номера записей соответствующих элементов. Число элементов, вступающих с рассматриваемым в другие отношения (например отношения порождения), является переменным и не может быть определено однозначно для всех элементов модели. В этом случае набор указателей на соответствующие элементы представляется массивом из N номеров записей. Массив переменной длины в реляционной БД удобно располагать в двух полях записи. В одном поле хранится число N, определяющее количество элементов массива, а в другом поле, размер которого не фиксирован (поле типа memo), хранятся значения элементов массива.
Кроме полей, задающих отношения элемента с другими элементами модели, в записи присутствуют поля данных, идентифицирующих сам элемент и задающих его атрибуты: номер, имя, вид (процесс, ресурс или данное), тип отношения иерархии и др.
Каждому элементу модели каждого вида соответствует одна запись файла формата DBF. В определенные memo-поля каждой записи заносятся данные о связях данного элемента с другими элементами модели (входные и выходные элементы, подчиненные элементы, предшествующие процессы, если таковые заданы), а также данные о характеристиках элемента (имена, формулы и типы характеристик). Связи описываются путем перечисления в соответствующих memo-полях номеров элементов КМПО, с которыми указанный элемент вступает в определенные отношения. Данные о характеристиках есть упорядоченное перечисление соответствующих значений.
Кратко представим структуру и ключевые поля основных баз данных КМПО в той степени, насколько это необходимо для описания интерфейса между подсистемами ССМ в различных режимах работы системы. Во всех таблицах этого подраздела, иллюстрирующих тип записей баз данных, затенены поля переменной длины, при описании ключей, которые состоят из нескольких полей, символ Ф используется для обозначения конкатенации как строковых, так и числовых величин, причем результат последней операции рассматривается как число (например, при значении поля "а" - 300, а поля "б" - 15 значение ключа "а Ф б" равно 30015).
База данных "Описание объектов" и ее справочники представлена на рис. 1, здесь а - номер уровня объекта в дереве объектов, Р - порядковый номер объекта на его уровне, 4 - тип декомпозиции, cato - категория объекта. Первичный ключ равен а Ф р, вторичные - все поля. Когда ниже употребляется выражение "код объекта" без специальной оговорки, имеется в виду соответствующая этому объекту величина а Ф р. В поле psup заносится порядковый номер Р суперобъекта данного объекта на вышележащем уровне декомпозиции.
а Р код_типао th Psup cat0
а Ф р имяо
код типао типо
Рис. 1. База данных "Описание объектов"
База данных "Связи объектов" показана на рис. 2, здесь и ^^оШ: - списки входных
и выходных ресурсов. В соответствии с вышеизложенным перед каждым тето-полем вводится
числовое поле (на рисунках обозначается N), в которое заносится количество данных, хранимых в тето-поле. Эта величина - параметр стандартных функций СУБД, обеспечивающих запись и считывание данных из полей переменной длины. В поле N графы comp рис. 2 заносится список кодов подобъектов текущего объекта либо код имени покрытия ГИС, реализующего опцию "area", в таком случае N : = 0. В графы ОР, ОА и ОО по той же схеме при конструировании и анализе КМПО заносятся списки элементов КМПО, находящихся с заданным в соответствующих отношениях [4].
а Ф ß comp list_in list_out OP OA OO
N list N list N list N list N list N list
Рис. 2. База данных "Связи объектов"
Две уже описанные базы являются основными базами КМПО и используются на всех стадиях создания и исследования модели. Две следующие базы "Классификация объектов" и "Классификация процессов" (рис. 3 и 4) применяются при решении задачи классификации и поэтому содержат поля с параметрами критерия качества.
а Ф ß кодг(сгй0) ai ai0 Aai Aai
Рис. 3. База данных "Классификация объектов"
кодр кодр(сгйр) m ai aio Aai
list list list
Рис. 4. База данных "Классификация процессов"
Значения ключевого поля <код^> базы "Классификация процессов" присваиваются при формировании базы "Описание процессов", показанной с ее справочниками на рис. 5. В поле "код объекта" заносится величина а Ф р объекта, к которому приписан процесс.
кодр код_типар код_испр catp код функц. типа код объекта
Рис. 5. База данных "Описание процессов"
В поле "код_исп/' вводится код исполнителя процесса из справочников для процессов и ресурсов КМПО (рис. 6).
код исп. имя исп. расширение
0 ЭС
Рис. 6. Структура справочников по исполнителям процессов и ресурсов
Указанные справочники имеют одинаковый тип записи для процессов и ресурсов, в них заносятся имена и при необходимости расширения всех функций и программ, реализующих соответствующие элементы КМПО в ходе имитации. Нулевой код присваивается ЭС ССМ.
Структура базы данных "Связи процессов" аналогична структуре базы "Связи объектов" (рис. 7), но в графы РО и РР вводятся коды элементов КМПО, связанные с данным процессом отношениями РО и РР (см. выше).
Поля базы "Описание ресурсов" содержат данные для фреймов процессов (рис. 8). В поля "source" и "destin" в ходе анализа КМПО заносятся коды процессов, порождающих и потребляющих данный ресурс соответственно.
коДp ist in list out PO PP
N list N list N list N list
Рис. 7. База данных "Связи объектов"
кодг catr код испг source destin
кодг код типа,-
код_типа? типг
Рис. 8. База данных "Описание ресурсов"
Альтернативные структуры объектов в КМПО хранятся в базе "Описание объектов" (поле 4 на рис. 1), для хранения альтернативных процессов используется специальная база "Наборы ресурсов" (рис. 9). В поля "потребитель" и "источники" заносится код и списки кодов элементов КМПО, для которых данный набор является входным и выходным соответственно.
d k ind list res потребитель источники
Рис. 9. База данных "Наборы ресурсов"
Последняя база, входящая в состав БД КМПО, содержит информацию о результатах анализа разрешимости шаблонов процессов КМПО [4].
Хранение данных и правил в ЭС ССМ
База данных ЭС в ССМ содержит параметры и переменные, не описанные в КМПО и предназначенные пользователем для внутреннего применения в правилах ЭС. В частности, это могут быть и вспомогательные переменные управляющих формул ЭС, и переменные вероятности. Поэтому в ЭС ССМ в полной мере представлены средства ручного ввода и корректировки параметров и переменных.
кодд типд кол зн имяд положение
Рис. 10. Справочник "Данные ЭС"
В процессе ввода и вывода данных используется справочник "Данные ЭС" (рис. 10), который содержит следующие поля: "кодд" - численное значение кода данного (первичный ключ); "типд" - указатель типа данного - 1 для параметров, 2 для переменных и 3 для переменных вероятностей (кроме фиксированного значения вероятности, любому данному может быть поставлена в соответствие переменная, в которой хранится распределение вероятности - используется при формировании правил и проведении экспертизы); "кол_зн" -количество значений параметра или переменной, список которых хранится в тето-поле "Значения"; "имяд" - имя данного в виде последовательности символов (применяется только
для визуализации); "положение" - расположение данного в дереве вывода: G - цель, L - лист и М - промежуточное данное.
Имеется еще ряд полей, содержащих вспомогательную информацию, которая используется в процессе экспертизы.
Для работы со значениями данных используется справочник "Значения данных ЭС" (рис. 11), содержащий, кроме уже описанных, следующие поля: "кодзн" - код значения данного, который присваивается автоматически при вводе значения; "имязн" - имя значения в виде последовательности символов; "р0" - начальная вероятность (при вероятностном выводе).
кодд кодзн имязн ро
Рис. 11. Справочник "Значения данных ЭС"
Каждое логическое условие правила ЭС хранится в отдельной записи БД ЭС, что, по мнению автора, существенно ускоряет процедуры вывода, так как позволяет помечать появление фактов, констатацию истинности или ложности, а также блокировку использования некоторого данного сразу во всех правилах, содержащих это данное. Такая возможность в значительной степени объясняет и оправдывает выбор СУБД в качестве программной среды для разработки ЭС в исследовательской версии ССМ.
При вводе и редактировании правил используется база данных "Правила" (рис. 12), которая содержит, кроме описанных ранее, поля: "нпр"- номер правила; "часть" - признак части правила (1 - для части ЕСЛИ, 2 - для части ТО и 3 - для части ИНАЧЕ); "знак" - код знака отношения данного и его значения (для параметров - 1 - равно, 2 - не равно, для переменных - 1 - равно, 2 - не равно, 3 - больше, 4 - больше или равно, 5 - меньше, 6 - меньше или равно); "список" -поле memo, в котором перечислены коды используемых в правиле значений данного; N - как и ранее, количество значений данного в предыдущем тето-поле; "Rem" - поле примечаний (это обозначение используется для полей комментариев и в других базах); "Act" -признак активности правила (заполняется в ходе экспертизы).
нпр часть знак список Rem Act
Рис. 12. База "Правила"
База данных "Правила" содержит также другие поля для хранения вспомогательной информации и организации управления выводом.
нпр часть ноб итер русл использ
Рис. 13. База данных "Факты"
База данных "Факты" (рис. 13) хранит информацию об имеющихся к началу экспертизы и появляющихся в ее ходе фактах. В процессе сеанса работы с ЭС база редактируется, пополняется новыми фактами и т. д., она содержит следующие еще не описанные поля: "нпр" и "часть" - поля, совпадающие по формату с соответствующими полями базы "Правила", сюда записываются номер правила и признак части правила из базы "Правила", из которого получен данный факт. Если он получен по данным пользователя (введен в базу до начала экспертизы), то в эти поля записываются значения 9999 и 9 соответственно; "ноб" - номер объекта, для которого проводится экспертиза (а Ф р при экспертизе массива объектов, 1 - при экспертизе одиночного объекта); "итер" - номер итерации в процессе экспертизы, на которой получен факт
(для начального факта - 0); "русл" - условная вероятность значения данного, для которого записан факт; "использ" - признак использования факта в процессе экспертизы (0 - не учтен, 1 - учтен, 2 - ошибка).
Кроме вышеописанных основных баз данных, имеется база данных "Контроль БЗ", содержащая вспомогательную информацию для проведения процедур контроля базы знаний.
Для всех перечисленных баз данных разработан набор индексов, ускоряющих подготовку и выбор данных по различным условиям, которые требуются в ходе экспертизы.
Существенной и ценной частью базы данных ЭС является архив логико-трансформационных правил (ЛТП), созданных автоматически или вручную в процессе исследования модели ССМ. Эти правила хранятся в том же формате, как и все действующие правила ЭС (они дополнительно атрибутируются временем создания и комментарием пользователя), и могут быть вновь активированы по выбору пользователя.
Основные характеристики БД ГИС
Пространственные данные в языке ГИС ArcInfo хранят геометрическое местоположение географических объектов вместе с атрибутивной информацией об этих объектах. Данные о местоположении хранятся в векторных структурах, а соответствующая атрибутивная информация - во множестве таблиц, географически связанных с описываемыми объектами. Это также называется геосвязанной структурой данных (georelational data structure).
Если существуют дополнительные таблицы, обеспечивающие описательные характеристики объектов, то они могут быть присоединены к атрибутивной таблице темы. Присоединение основано на значениях полей, одинаковых в обеих таблицах. Названия полей могут быть различны в обеих таблицах, но тип данных должен быть одним и тем же. Во время присоединения устанавливается тип соединения одна-к-одной (one-to-one) или много-к-одной (many-to-one) между результирующей таблицей (таблицей темы) и дополнительной таблицей.
Основной справочник, обеспечивающий взаимодействие ГИС с КМПО и ЭС - справочник "ГИС-элементы КМПО", связывающий коды ГИС-элементов с таблицами их ГИС-описаний.
Для представления результатов моделирования на картографической основе используется набор ГИС-операций над ГИС-элементами КМПО, который зависит от языка используемой ГИС. Применение операций описывает справочник "ГИС-операции" (рис. 14), связывающий служебный код операции (код0п) с ее именем на языке ГИС (имяоп), количеством участвующих в операции объектов N<,n (в исследовательской версии ССМ это 1 или 2) и списком их ГИС-типов (типыо), а также количеством параметров операции (N^) и списком их ГИС-имен (list^).
кодоп имяоп типыо N 1 *пар Н^пар
Рис. 14. Справочник "ГИС-операции"
База данных предметной области
Под базой данных предметной области моделирования понимается совокупность конкретных значений данных предметной области, хранящихся на внешних запоминающих устройствах (ВЗУ) компьютера. Кроме данных, хранящихся на ВЗУ, при моделировании используются данные, которые существуют только в оперативной памяти компьютера, и данные, которые вводятся в диалоговом режиме или выводятся на устройства вывода. Данные такого рода могут не сохраняться на внешних запоминающих устройствах и, следовательно, не принадлежат БД предметной области [9, 10].
При описании данных вводится три категории данных предметной области: постоянные, временные, оперативные. Этим категориям при конструировании КМПО назначаются исполнители типов DB (GEN), CMP и TMP соответственно. К постоянным относятся данные, которые не изменяются в ходе моделирования (данные натурного эксперимента, данные
сценариев, постоянные коэффициенты и т. п.). Временные данные - это, как правило, промежуточные или целевые результаты вариантов моделирования. При повторных реализациях моделирования временные данные либо заменяются, либо хранятся в виде версий. Постоянные и временные данные записываются в ходе моделирования на внешние запоминающие устройства и составляют БД предметной области. Временные данные могут удаляться при завершении моделирования. Оперативные данные создаются и хранятся в памяти только в процессе выполнения соответствующей программы и уничтожаются по ее завершению.
Предложенное разделение на классы позволяет использовать аппарат имен, исполнителей и типов исполнителей при автоматической генерации БДПО и анализе КМПО на целостность и разрешимость. Логическая структура БДПО определяется структурой исполнителей для постоянных и временных данных.
Основной "границей" между БДПО и БД КМПО по типу включенных в нее данных является использование значений данных, а по типу задач - анализ ситуаций. Поэтому главный справочник БДПО "Данные КМПО" имеет вид, показанный на рис. 15. В дополнение к обычному числовому полю "кол_зн" (количество значений данного) и соответствующему ему memo-полю "Значения", аналогичным полям справочников "Данные ЭС" (рис. 10) и "Значения данных ЭС" (рис. 11), в него введены еще поля "кодш™*" и "код^™"", содержащие максимальное и минимальное значение кодов значений данного. Поскольку при программной реализации ССМ принято соглашение, что коды значений каждого данного представляют собой последовательности натуральных чисел без пропусков, причем для переменных направление увеличения этих кодов совпадает с направлением увеличения самих значений, такая структура справочника значений данных КМПО позволяет проводить все процедуры контроля корректности формирования любых подмножеств значений данного без обращения к самим значениям. В этом же справочнике хранятся коды значений данных по умолчанию (default).
КОДг кол-во зн-й код знтах код знтш список зн-й default
Рис. 15. Справочник "Данные КМПО"
Значительную часть БДПО составляют базы исходных данных, в которых, как уже отмечалось, хранятся и экспериментальные данные (ЭД), и данные сценариев. Обычно для каждого листьевого параметра/переменной с типом исполнителя DB создается отдельная база исходных данных с двумя основными полями: дата-время и код значения данного, выбираемый из списка допустимых значений. Обоснование такого решения дано ниже [9, 10].
Характерной чертой исследуемых с помощью ССМ нестационарных ППК является изменение значений многих их характеристик во времени. Некоторые изменения можно описать функциональными зависимостями (тип исполнителя GEN). Для определения значений таких данных в некоторый момент t достаточно задать функцию изменения и начальные условия:
Y = F(Yo, X, t) или dY/dt = f(Yo, X, to). (1)
При этом в БДПО имеет смысл хранить только значения параметров уравнений (1) - Y0 и X с привязкой к конкретной временной точке t0. Значения данных для произвольного времени вычисляются в процессе моделирования с помощью соотношения (1). Однако в реальных пространственных системах возможность функционального описания динамики характеристик ограничена, так как сложность самих систем и их взаимодействия с окружающим миром не позволяет выявить или учесть все значимые параметры и формализовать взаимосвязи между ними. Некоторые аналитические взаимосвязи параметров исследуемой системы удается определить (выявить) только в результате проведения моделирования.
Основная часть изменяющихся характеристик задается в виде временных рядов. Рассмотрим несколько типичных ситуаций формирования временных рядов значений
параметров исследуемой системы. Первая, самая простая ситуация, когда при моделировании используется только один изменяющийся параметр объектов исследуемой системы и изменения фиксируются с постоянным временным шагом. В этом случае данные, характеризующие объект, реализуются в компьютере в виде записи базы данных. Причем в явном виде объект, соответствующий этой записи, в КМПО может быть не декларирован. Запись определяется набором полей, куда, как правило, входят:
"адресные" данные, определяющие связь конкретного экземпляра объекта с соответствующим экземпляром объекта верхнего уровня иерархии;
одиночные данные {res,}, характеризующие объект и не изменяющиеся во времени; массив, представляющий временной ряд значений res,k изменяющегося параметра res,, помещенный в поле переменной длины (тето-поле).
Использование поля типа memo в данном случае позволяет хранить в БД временные ряды с различным числом элементов. Число элементов временного ряда задается значением данного, которое назначено в КМПО управляющим для res,.
Такой способ хранения временных рядов обеспечивает максимальную компактность БД. Однако он не эффективен, когда при моделировании требуется индивидуальный доступ к отдельному заданному элементу временного ряда или возникает необходимость использовать значения элементов временного ряда для поиска или сортировки данных.
Второй вариант - изменение некоторого набора параметров исследуемой системы с одинаковым временным шагом. Подобная ситуация достаточно типична при моделировании производственных систем, в частности, региональной энергетики [4]. Для каждого энергопроизводящего объекта ежегодно фиксируется набор параметров. Значение практически любого параметра может изменяться ежегодно. При исследованиях энергопроизводителей необходим целевой доступ к набору показателей для любого года. Для каждого года создается отдельная запись в соответствующей БД. Для каждого типа энергопроизводящих объектов формируется отдельный исполнитель - файл БД, так как состав параметров для них различен. Поле, в котором содержится год, используется в индексном выражении для БД.
Недостаток такой организации БДПО - частичное дублирование неизменяющихся данных в записях БД.
Третий вариант - наличие данных предметной области, изменяющихся нерегулярно и имеющих различную дискретность изменений. Здесь необходимо определить временной шаг для рядов значений каждого из изменяющихся параметров, в пределах которого значение параметра считается неизменным. Для хранения данных можно предложить несколько моделей.
По аналогии с первой ситуацией значения изменяющихся параметров можно разместить в memo-полях, дополнив значением момента времени получения экземпляра данного. Однако при этом невозможно организовать быстрый доступ к экземплярам на заданный момент времени. Кроме того, в БД может появиться большое количество дублирующихся значений, если в течение нескольких временных шагов параметр не изменялся.
Использование отдельных записей для каждого временного шага также неэффективно. Во-первых, редко удается использовать кратные значения дискретности различных параметров исследуемого объекта, что позволило бы совместить моменты времени фиксации их значений. Во-вторых, не избежать избыточности БД из-за дублирования значений параметров с большей дискретностью в записях изменений значений параметров с малой дискретностью.
Решение проблемы дает использование БДПО, в которой для каждого типа изменяющегося данного (переменной или параметра) формируется отдельная база. Связь экземпляра значения с конкретным объектом задается полем "Идентификатор Объекта". Запись в БД производится только в том случае, если значение параметра Xk(i) для объекта о, на момент времени t(i) отличается от значения Xk(i - 1), записанного на момент времени t(i - 1) = t(i) - At (где At - шаг дискретности). Фактически в БД хранятся моменты времени, отмечающие границы интервалов, на протяжении которых значения параметра не изменялись, и значения параметра на этих
интервалах. Продолжительность любого интервала может составлять произвольное число шагов дискретности от 1 до N (где N = T/ At - число шагов дискретности за все время наблюдений T).
Таким образом обеспечивается компактное хранение параметров исследуемой системы и возможность доступа к параметрам и экземплярам их значений на любой момент времени.
После ввода ЭД получают статус "только для чтения" и могут быть только введены повторно, а для сценариев допускается одновременное существование в системе многих версий. Чтобы обеспечить доступ ко всем имеющимся в ССМ БИД, их имена формируются как "кодг Ф Ver", где кодг - код данного, а Ver - номер версии (целое неотрицательное число), причем ЭД соответствует версия 0. Каждая БИД имеет 2 поля, куда записываются моменты модельного времени, в которые происходит изменение значения данного, и код нового значения (естественно, из списка допустимых значений), причем любая БИД должна содержать значения данного на моменты начала и окончания сценария, чтобы эти моменты были четко заданы. Для ЭД, вводимых в ССМ автоматически, в базу их описания вводятся дополнительные поля, содержащие интервал опроса датчиков данных и команду для опроса. Этот способ применялся в приложении ССМ к прогнозу горных ударов для организации ввода данных от частных методик.
Результаты имитации (данные категории СМР) хранятся в базах такой же структуры, как БИД, но имена этих баз строятся как "код^ Ф кодг", где код^ есть код сценария, по которому проводилась имитация, он описан несколько ниже.
Следующая группа баз БДПО содержит описания преобразований, выполняемых процессами частного вида, а именно разветвителями, преобразователями и буферами [4, 5]. База "Разветвители"включает код процесса и количество ветвлений, а также тето-поле с описанием коэффициентов ветвления, в него могут вводиться либо константы (тогда они записываются в формате с плавающей точкой), либо коды функций из справочника "Исполнители процессов". Данные в это поле вносятся в порядке, соответствующем порядку перечисления ресурсов в списках входных данных этих процессов.
Аналогично построена база "Буферы/преобразователи", но в ней есть 2 тето-поля, содержащие описания значений или функций потерь и задержек по времени, вносимых соответствующими процессами. Контроль корректности значений состоит в проверке их неотрицательности, а значения потерь должны быть еще и меньше 1.
Последняя база собственно БДПО, база "Фрагменты" (рис. 16), содержит описание исследованных фрагментов КМПО, ее первичным ключом является "кодОПР Ф кодф", где кодОПР есть код объекта принятия решения (ОПР) для данного фрагмента, а кодф - служебный код фрагмента, вводимый при утверждении фрагмента для имитации. Одному ОПР может соответствовать много фрагментов, различающихся списками объектов - участников фрагмента Оф, а при одинаковых участниках фрагмента - списками зафиксированных на время имитации альтернатив. Эта информация хранится в трех последних полях базы "Фрагменты", причем в предпоследнее поле вносятся величины а Ф р для альтернатив объектов и а Ф k -для альтернатив наборов ресурсов (k - номер набора). В последнее поле базы вносятся значения зафиксированных управляющих данных (т. е. фактически номер зафиксированной ветви) в том же порядке, в каком альтернативы перечислены в предыдущем поле.
код фраг. кодопр Оф N фикс альт-в список фикс. альт-в
Рис. 16. База "Фрагменты"
Две оставшиеся базы входят в архив БДПО, поскольку в них хранятся основные результаты решения задач ССМ за длительный срок, которые могут применяться пользователем и системой для сопоставления результатов моделирования, разработки новых и уточнения имеющихся ЛТП.
База "Сценарии" (рис. 17) содержит описание исследованных сценариев, большинство данных в ней соответствуют данным фрейма сценария, в тето-поле данных по сценарию заносятся значения "кодг Ф Ver" (см. выше) для данных, которые конструировались пользователем. Остальные исходные данные фрагмента должны иметься в базах ЭД. В поля "ЛТП" экспертная система вносит информацию о сработавших в ходе исследования фрагмента логико-трансформационных правилах, в поля "ГИС-операции" вносятся имена ГИС-покрытий с результатами применения использованных в данном сценарии ГИС-операций. Справочник базы "Сценарии", показанный на том же рисунке, кроме обычных полей со служебным кодом и именем сценария, содержит пользовательский комментарий, который вводится при утверждении сценария для имитации и предназначен для облегчения поиска по архиву при необходимости восстановить данные и результаты уже смоделированного сценария.
Набор баз "Классы ситуаций" (рис. 18) предназначен для аккумуляции результатов решения задачи классификации ситуаций в целях их дальнейшего использования. Для каждого ОПР создается своя база, имя которой синтезируется по коду ОПР. Первичным ключом служит код фрагмента, связываемый с аналогичным полем базы "Фрагменты" (рис. 16). В базы "Классы ситуаций" заносятся сведения о фактах, заданных при формировании исходной ситуации, и перечни объектов-участников Оф для достаточных ситуаций, оптимальных в каждом классе достаточных ситуаций. Количество таких классов равно количеству входных переменных критерия качества для данного ОПР, столько же полей "Оптимальные достаточные ситуации" содержит соответствующая база "Классы ситуаций".
кодф код,с начало конец данные по сценарию ЛТП ГИС-операции
N list N list N liStnüKD
код,с имя,с Rem
Рис. 17. База "Сценарии"
кодф исходная ситуация сист. время оптим. дост. ситуации Rem
кол-во фактов список фактов класс1 класс N^
Охф О^
Рис. 18. База "Классы ситуаций"
Внутренние БД объектов КМПО
Практика использования ССМ показала, что в ряде приложений, где имеются значительные предшествующие наработки в части создания моделей объектов, которые должны быть включены в состав КМПО ССМ, не всегда удается организовать обмен ресурсами внутри объекта, используя только форматы данных, представленные выше в этом разделе. Например, в задаче моделирования лесных экосистем типичные объекты модели - контрольные и исследуемые площадки - характеризовались массивом строковых данных и могли содержать различное (от 50 до 200) количество разновозрастных деревьев, в свою очередь описываемых некоторым массивом числовых и строковых данных, а также временным рядом годичных приростов, длина которого соответствовала возрасту дерева. Поэтому в ССМ предусмотрены возможности автоматизированного ввода и анализа массивов данных различных форматов, связанных при необходимости системой ссылок, а также некоторые дополнительные средства работы с более сложными структурами данных, опирающиеся на аппарат исполнителей данных [4] и представленные далее. Цель применения этих средств в ССМ состоит в организации интерфейса между нестандартными (для КМПО ПТК) моделями объектов предметной области
и остальными компонентами КМПО ССМ. Поскольку такие наборы данных обычно локализованы внутри объектов КМПО, в дополнение к дереву объектов может строиться дерево внутренних процессов объекта, дерево исполнителей, и почти всегда строится дерево данных (ресурсов).
Типы данных в языках программирования подразделяются на два класса: стандартные (встроенные) и произвольные (пользовательские) типы. Для организации имитационного моделирования существен не тип самого данного предметной области, а тип его представления в компьютере - исполнителя данного. В качестве встроенного множества типов в ССМ используется традиционный для большинства языков программирования высокого уровня набор: символьный, числовой, логический (простые или конкретные типы); массив, запись, файл (структурные или родовые типы).
При использовании архитектуры SQL-сервера термину "файл" соответствует понятие "таблица" или "таблица данных". Ниже используется термин "файл".
В массив могут входить только однотипные данные (простые или одинаковые по структуре родовые). Запись может состоять из разных по типам элементов, как простых, так и структурных. Файл может рассматриваться как массив записей или неделимая, без определения структуры, единица хранения данных на внешних запоминающих устройствах. В процессе формирования данных КМПО исполнители задаются только тогда, когда они необходимы как структурные единицы алгоритмического уровня. Конкретные исполнители создаются для структур данных не выше уровня файла. Для данных верхних уровней иерархии исполнитель трактуется как некоторая структура, возможно именованная, исполнителей более низких уровней.
БД объекта предметной области со сложной внутренней структурой данных в общем случае представляет собой набор файлов, содержащих экземпляры постоянных и временных данных, декларированных в концептуальной модели. Файлы как исполнители могут быть назначены данным различных уровней иерархии данных. Если файл задан в качестве исполнителя элементарному данному КМПО, то он - неделимый элемент модели БД. Формат файла в таком случае может быть произвольным, но учитывается при создании программы -исполнителя процесса, для которого соответствующее данное является входным.
Процессам концептуальной модели предметной области в качестве исполнителей назначаются программные модули. Следовательно, структуру исполнителей данных, связанных с процессами отношениями "вход - выход", можно рассматривать как описание логической структуры данных в исполняемых прикладных программах - подсхемы данных [11]. Элементы подсхемы не всегда можно связать с одним суперобъектом, имеющим исполнителем файл. В общем случае описание данных в КМПО задает внешнюю структуру базы данных объекта.
Базис для построения файловой структуры БД сложного объекта составляет множество исполнителей исходных данных КМПО. Каждому экспериментальному данному соответствует исполнитель файлового типа (неделимый файл) или встроенного типа. Исполнители неэлементарных уровней представляются некоторой структурой исполнителей нижних уровней иерархии. В зависимости от типов подчиненных данных это может быть массив или запись.
Для обеспечения автоматизации создания файловой системы БД в ССМ введены вспомогательные структурные типы данных, не отражающиеся в КМПО. Один из них - тип POF_X, - "часть файла_Х". Исполнитель такого типа не имеет собственной физической реализации в компьютере. Назначение ter(res/) := POF_X, трактуется как указатель на то, что структура данных, соответствующая ресурсу res/, физически есть часть файла БД с именем FILE_NAME. Введение предложенного типа данных делает необязательным включение в модель ресурса, которому назначается исполнитель с именем FILE_NAME файлового типа, чтобы создать требуемый файл БД FILE_NAME [10].
Понятия первичных и вторичных файлов БД рассмотрены в [12]. К первичным файлам отнесены файлы, ориентированные на задачу первичного учета. При полноте учета первичные файлы составляют полную информационную модель характеризуемого ими объекта. Файлы,
формы и порядок записей в которых ориентированы на прикладные программы, отнесены к вторичным. Целесообразность создания вторичных файлов обосновывается ускорением доступа к данным, хранящимся в этих файлах. Осуществление ускоренного селективного доступа к данным по заданным условиям входит в стандартные требования к современным СУБД. Для этого используются ключевые выражения - индексы. При работе с СУБД индексы задаются на этапе формирования физической структуры файла БД и представляют собой некоторые выражения, построенные из функциональных лексем и имен полей БД. Любую таблицу данных (файл БД) можно проиндексировать по нескольким полям и иметь любое число индексов (индексных файлов). Индексные файлы содержат информацию о расположении записей БД в соответствии с заданным порядком тех полей, по котором выполнено индексирование. Средства современных СУБД позволяют создавать мультииндексные файлы, являющиеся по существу соединением нескольких простых индексных файлов. Простейший вариант ключевого выражения, по которому проводится индексирование, имеет вид: I = F1 + ... + Fk, где Fj - имя поля базы данных. Использование мультииндексных файлов, фильтров и т. д. позволяет, не создавая вторичных файлов, осуществлять выборки необходимых подсхем данных из первичных файлов.
Часть данных КМПО, включающая постоянные и временные данные с исполнителями типов DB и CMP, задает структуру первичных файлов БД объекта предметной области. Подсхемы данных, которые необходимы при выполнении конкретных вариантов расчета, задаются в основном в классе оперативных (тип исполнителя ТМР). В соответствии с принципом разделения данных на классы, эти данные не имеют собственных структурных единиц хранения на внешних устройствах. Назначение типа исполнителя POF_X, данным этого класса означает, что в оперативной памяти создается динамическая структура для хранения соответствующей подсхемы данных, хранящихся в первичном файле БД с именем, совпадающим с именем исполнителя рассматриваемого ресурса.
Введение другого вспомогательного структурного типа - IND_X, - позволяет автоматизировать процесс создания индексных выражений для ускоренного селективного доступа к данным [4]. Порядок включения элементов в индексное выражение задается отношениями следования, определенными на множестве подобъектов объекта с типом исполнителя IND_X,. Ресурсы КМПО, из которых формируется индексное выражение, могут иметь разные типы исполнителей. Поэтому в систему поддержки моделирования включается набор функций построения индексных выражений. Эти функции генерируют индексное выражение на основе шаблона соответствующего ресурса КМПО, осуществляя при необходимости определенные преобразования типов элементов индекса. При этом должны соблюдаться некоторые дополнительные правила назначения типов, описанные далее.
Ресурс res,, которому назначен такой исполнитель, т. е. tr(res ) = IND_X,, может содержать в соответствующем ему поддереве данных КМПО объекта только данные с типом отношения иерархии "композиция". Кроме этого, в КМПО объекта должен входить ресурс resk такой, что он является суперобъектом по отношению к res,, и его исполнитель однозначно определяет принадлежность исполнителей соответствующего поддерева данных к некоторому файлу. Приведенные условия дают правило использования типа исполнителя данного IND_X,: для любых двух ресурсов res,, res,, принадлежащих некоторому объекту КМПО ССМ, должно выполняться следующее соотношение:
((tr(res,) = IND_X,) v (res, е hr*(res,) v (thr(o,) = &)) ^
^ ((thr(res,) = &) v (tr(resk) = POF_X,) v (tr(rest) = FILE) v (e0(o)=e0(ok)) (2)
для некоторого resk: res,- е hr*(resk), где hr*(resk) - множество подчиненности [4] объекта, порождающего этот ресурс.
Правило (2) учитывается при анализе назначений типов исполнителей ресурсов.
Если в КМПО отсутствует нужный ресурс res,: (er(res,) = FILE_NAME, tr(res,) = FILE), но имеет место некоторое множество данных {res,1,..., resik}: (er(res,1) = ... = er(resik) = FILE_NAME,
Mres/^POFJ, ..., tr(res/)=POF_£), то файл формируется на их основе. Число полей записи файла равно мощности множества FN, полученного в результате объединения множеств элементарных данных поддеревьев КМПО, соответствующих каждому данному res,': FN ::= {res*1: (res*1 e h^res/)) v (hr(res/) = 0} u...
...u {res*4: (res*4 e h^res/)) v (hr(res/) = 0)}. (3)
Имя и тип каждого поля определяются именем и типом исполнителя соответствующего данного - er(res*'), tr(res*'), res*' e FN. Если в состав записи в качестве элементарных данных входят элементы массива и этот массив, в свою очередь, является элементом записи, т. е. существуют данные res/, res/, resd и множество данных {о*'}, для которых справедливо: (er(res/)=FILE_NAME) v (tr(res/) = POF_I) v (rest'' e h,*(res/)) v (^(res/) =*) v v (resd e hr*(res/) v (hr(resd) = &)) v (res*' e hr(res/)) v (tr(res*')=*) v v (res*' e hr*(res/)) v (h(res*') = 0), (4)
то массив можно не разбивать на отдельные элементы, а хранить в одном поле БД типа memo. При этом, как и в случае хранения массивов ссылок в БД концептуальной модели, в записи присутствует поле, задающее длину массива с именем er(resd).
При наличии в КМПО данных res/1,..., res/ таких, что tr(res/) = IND_1, ..., tr(res/)=IND_K и существовании данного res/', для которого найдется другое данное res^, такое, что (res/ e hr*(res') v (er(res')=FILE_NAME), для созданного файла БД с именем FILE_NAME формируется мультииндексный файл с тем же именем - структурный мультииндексный файл, где хранятся индексные выражения, сформированные по данным res/,..., res/ КМПО. Получаемые индексные выражения представляют собой текстовую конкатенацию полей БД, соответствующих подобъектам элементарного уровня каждого res/'. Число индексов для каждого файла FILE_NAME БД будет равно числу данных, имеющих тип исполнителя IND_X и имя исполнителя FILE_NAME.
Общее количество файлов, образующих БД объекта, равно количеству различных имен исполнителей, тип которых определяет наличие соответствующего файла.
Для обмена данными между БД и программами - исполнителями процессов КМПО в ССМ включаются два вида сервисных процедур - процедуры считывания и процедуры записи. Процедуры считывания осуществляют индексацию БД по индексу выбираемой подсхемы и считывание в оперативную память из файлов БД элементов заданной подсхемы. Процедуры записи реализуют обратную процедуру - запись результатов работы программы - исполнителя процесса в БД. При этом либо происходит поиск требуемых записей в БД и обновление значений полей, входящих в рассматриваемую подсхему, значениями соответствующих переменных памяти, либо создание новых записей и заполнение в них определенных полей. Указанные сервисные процедуры автоматически включаются в исполняемые программы реализации процесса, если входными или выходными данными процесса являются подсхемы БД [9].
Автоматическое формирование БД объекта не предусматривает индивидуального задания размеров полей БД. Размер поля, отводимого под данное, зависит от его типа. В результате размеры БД, полученной в ходе работы ССМ, будут, как правило, превышать размеры аналогичной БД, построенной средствами стандартной СУБД. В качестве еще одного недостатка следует отметить ограниченность конструкций индексных выражений. В современных СУБД допускается построение индексов не только непосредственно из имен полей БД, но и в виде некоторой комбинации различных функций от этих полей. Основное достоинство предложенного способа создания БД состоит в том, что пользователь непосредственно формирует только концептуальную модель данных с использованием привычных ему терминов, а создание файловой структуры БД и выборка необходимых подсхем данных производится в соответствии с заданными описаниями автоматически.
Заключение
На примере ситуационной системы моделирования, ранее разработанной автором, представлены средства автоматической генерации реляционных баз данных, необходимых для конструирования модели, выполнения имитационного моделирования ППК, хранения и анализа его результатов с учетом возможности оперативного изменения структуры модели, а также средств моделирования компонентов ППК. Описаны способы организации моделирования с использованием информации от встроенных ГИС и ЭС.
Основные отличия предложенных методов от существующих заключаются в том, что они базируются на концептуальном описании элементов ППК и предоставляют широкие возможности автоматизации контроля корректности модели, сопоставительного анализа вариантов реализации структуры ППК при различных сценариях его функционирования.
ЛИТЕРАТУРА
1. Интероперабельные информационные системы: архитектуры и технологии /Брюхов Д. О. [и др.] // СУБД. 2005. N 4. 2. Ling Liu, Tamer M. Özsu (Eds.). Encyclopedia of database systems. 2009. 4100 p. 3. Teorey T., Lightstone S., Nadeau T. Database modeling & design: Logical design. 4th edition. Morgan Kaufmann Press, 2005. 720 p. 4. Фридман А. Я. Ситуационное управление структурой промышленно-природных систем. Методы и модели. Saarbrucken: LAP LAMbErT Academic Publishing, 20l5. 530 с. 5. Фридман А. Я. Ситуационная концептуальная модель пространственного динамического объекта как семиотическая формальная система // Когнитивно-семиотические аспекты моделирования в гуманитарной сфере. Казань: нИи «Прикладная семиотика» АН РТ,
2015. С. 37-60. 6. Фридман А. Я., Курбанов В. Г. Формальная концептуальная модель промышленно-природного комплекса как средство управления вычислительным экспериментом // Труды СПИИРАН. 2014. № 6(37). С. 424453. 7. Фридман А. Я. Интерпретация концептуальной модели пространственного динамического объекта в классе формальных систем // Вестник КНЦ РАН. 2015. № 4 (23). С. 100-112. 8. Kroenke David M. and David J. Auer. Database concepts. 3rd ed. New York: Prentice, 2007. 9. Информационные технологии регионального управления / С. В. Емельянов [и др.]. М.: Едиториал УРСС, 2004. 400 с. 10. Олейник А. Концептуальное моделирование региональных систем. Saarbrucken: LAP LAMBERT Academic Publishing, 2011. 204 с. 11. Мартин Дж. Организация баз данных в вычислительных системах. М.: Мир, 1980. 664 с. 12. Дейт К. Введение в системы баз данных. М.: Наука, 1980. 464 с.
Сведения об авторе
Фридман Александр Яковлевич - доктор технических наук, профессор, ведущий научный сотрудник ФГБУН Института информатики и математического моделирования Кольского научного центра РАН; e-mail: fridman@iimm.ru
Information about the author
Alexander Ya. Fridman - Dr. Sci. (Eng.), Professor, leading scientific researcher of the Institute for Informatics and Mathematical Modelling of the KSC of the RAS; e-mail: fridman@iimm.ru
Библиографическое описание статьи
Фридман А. Я. Автоматизация синтеза баз данных системы ситуационного моделирования по их концептуальному описанию / А. Я. Фридман // Вестник Кольского научного центра РАН. -
2016. - № 1 (24). - С. 100-115.
Bibliographic Description
Alexander Ya. Fridman. Conceptual-Description-Based Automation of Databases Synthesis in Situational Modeling System. Herald of the Kola Science Centre of the RAS. 2016, vol. 1 (24), pp. 100-115.
