CC BY-NC-ND
23
УДК 004.65
БОТ 10.28995/2073-6304-2018-2-81-98
Модели и методы управления изменениями облачных баз данных
Николай Л. Лепе
Российский государственный гуманитарный университет, Москва, Россия, fu@rggu.ru
Владимир О. Сиротюк
Институт проблем управления РАН, Москва, Россия, vsirotyuk@ipu.ru
Аннотация. Работа посвящена вопросам обеспечения эффективного управления процессами сопровождения и развития облачных баз данных при изменениях в предметной области пользователей. В работе сформулированы требования и разработаны логическая структура базы метаданных репозитария облачной базы данных, модели и методы внесения изменений в информационные и функциональные требования пользователей, реструктуризации объектной канонической структуры облачной базы данных. В результате реализации предложенных процедур формируются модифицированные объектные модели требований пользователей и модифицированная объектная каноническая структура облачной базы данных, отвечающие требованиям полноты, достоверности и непротиворечивости данных, используемые провайдером облака при проведении оперативной и качественной реорганизации облачной базы данных.
Ключевые слова: облачная технология, облачная база данных, объектная модель требования пользователя, объектная каноническая структура облачной базы данных, база метаданных, репозитарий
Для цитирования:Лепе НЛ, Сиротюк В.О. Модели и методы управления изменениями облачных баз данных // Вестник РГГУ. Серия «Экономика. Управление. Право». 2018. № 2 (12). С. 81-98. БО1: 10.28995/20736304-2018-2-81-98
© Лепе Н.Л., Сиротюк В.О., 2018
Models and methods for cloud database alterations management
Nikolai L. Lepe
Russian State University for the Humanities, Moscow, Russia, fu@rggu.ru
Vladimir O. Sirotyuk
Institute of Control Sciences RAS, Moscow, Russia, vsiroyuk@ipu.ru
Abstract. The work is devoted to the issues of securing the effective management of the maintenance processes and the development of cloud databases with alterations in the user domain.
The authors formulate the requirements and develop the logical structure of the metadata database of the cloud database repository, models and methods for entering alterations into information and functional users requirements, restructuring the object canonical structure of cloud database.
Upon the implementation of proposed procedures a modified object model of user requirements and a modified object canonical structure of cloud databases are formed that meet the requirements of completeness, accuracy and consistency of data used by the cloud provider during the operational and qualitative reorganization of cloud database.
Keywords: cloud technology, cloud database, the object model for the user requirements, object canonical database structure, metadata database, repository
For citation: Lepe NL., Sirotyuk VO. Models and methods for cloud database alterations management. RSUH/RGGU Bulletin. "Economics. Management. Law" Series. 2018;2:81-98. DOI 10.28995/2073-6304-2018-2-81-98
Введение
Использование облачных технологий в качестве информационно-технологической среды распределенной обработки данных, предоставляющей на условиях аренды повсеместный сетевой доступ пользователям к конфигурируемым по требованию
ресурсам (серверам, системам хранения данных, приложениям, программному обеспечению, базам данных, информации и сервисам) провайдера облака обеспечивает ряд важных преимуществ для организации [1-3].
Вместе с тем «перемещение» бизнес-процессов, информационного, программного и технологического обеспечения заказчика в «облако» требует от организаций не только повышенного внимания вопросам обеспечения безопасности арендуемых средств и сервисов провайдера облака и передаваемых ему в доверительное управление программно-информационных ресурсов, но и четкой организации работ по управлению сопровождением и развитием облачных БД (ОБД) и приложений в условиях изменяющихся информационных и функциональных требований пользователей. При расширении знаний о предметной области, выявлении новых закономерностей, сущностей, связей, свойств и характеристик данных, появлении новых пользователей и задач управления и обработки данных могут потребоваться существенные изменения первоначального проекта ОБД, которые могут распространяться как на состав и структуру ОБД, так и прикладное программное обеспечение. Эти изменения вызываются добавлением новых, изменением или удалением существующих информационных элементов, объектов данных, отношений между объектами и элементами, процедур поиска и обработки данных и т. д.
В этих условиях для эффективной реализации поставленных перед функционирующей в «облачной» среде АИУС целей и задач необходимо оперативное и качественное обеспечение полноты, актуальности и достоверности структур данных ОБД в соответствии с изменяющимися во времени информационной и функциональной моделями предметной области пользователей и своевременной реструктуризации и реорганизации ОБД [4, 5].
Эффективным инструментальным средством административного управления изменениями ОБД является репозитарий [6, 7], база метаданных (БмД) которого содержит системные и структурные данные (спецификации логических свойств и физических характеристик данных и связей ОБД; артефакты проектирования; данные управления проектами; данные системной конфигурации; описание свойств и характеристик АИУС, пользователей, приложений и других ресурсов). Использование репозитария позволяет документировать и унифицировать процессы анализа, проектирования, реализации, внедрения и эксплуатации систем, обеспечить согласованность и непротиворечивость требований пользователей, коллективную работу проектировщиков, гибкую поддержку реин-
жиниринга системы и ее развитие, снизить трудоемкость разработки и эксплуатации систем.
БмД репозитария «облачных» АИУС должна поддерживаться ИТ-специалистами предприятия, хорошо знающими предметную область АИУС. Использование единого репозитария обеспечивает разработчиков всей необходимой информацией о результатах моделирования, анализа и синтеза структур ОБД для принятия решений при разрешении различного рода конфликтов и противоречий, координации совместной работы коллектива разработчиков и пользователей в процессе проектирования, а также для корректировки и модификации структур ОБД с учетом изменяющихся требований пользователей АИУС.
В дальнейшем полученные проектные результаты используются провайдером облака при проведении физической реорганизации облачной базы данных. При этом передача проектных данных может производиться с использованием, например, относительно новой «облачной» услуги - виртуальный удаленный рабочий стол (VDI -Virtual Desktop Infrastructure), организуемой в соответствии с моделью DaaS (Desktopas a Service). Данная услуга позволяет получить готовое рабочее окружение ИТ-специалиста (администратора ОБД) со всеми необходимыми приложениями и установленным ПО.
Широкое распространение облачных технологий при создании АИУС различного класса и назначения и в то же время отсутствие формализованных методов анализа изменений предметной области, построения модифицированных информационных и функциональных требований пользователей и синтеза модифицированной структуры ОБД, отвечающих требованиям полноты, достоверности и непротиворечивости данных, и создаваемых на их основе CASE-средств оперативного внесения изменений не позволяют обеспечить эффективное функционирование систем в облачной среде.
Разработка логической структуры БмД репозитария ОБД
БмД репозитария в общем случае содержит адресно-справочную, содержательную и словарную (лингвистическую) информацию о предметной области, информационной и обеспечивающей инфраструктуре АИУС и артефактах проектирования.
Целями создания БмД репозитария ОБД являются: - информационная поддержка управления процессами проектирования, функционирования, внесения изменений и развития ОБД;
- повышение эффективности использования информационных, программных и технологических ресурсов организаций;
- обеспечение непротиворечивости, достоверности, актуальности, полноты и целостности (неизменности) структур ОБД;
- обеспечение координации работ по описанию предметных областей пользователей, созданию, сопровождению, внесению изменений и развитию ОБД.
Кроме того, БмД ОБД используются также как средство стандартизации описания типов данных и используемой терминологии, а также ведения общесистемных языковых средств (классификаторов, тезаурусов, словарей) для ОБД разных типов; конвертирования, трансляции и интеграции различных типов и структур ОБД.
Метаданные, входящие в БмД репозитария ОБД, подвергаются со временем изменениям. Это связано с темпоральными свойствами данных, которые приводят к эволюции структур ОБД. В случае изменения данных БмД должна быть способна одновременно поддерживать метаданные в рамках прежней и новых структур ОБД. При этом серьезные трудности могут возникнуть при сопровождении индивидуальных сущностей предметной области (объектов данных), изменяющихся во времени, а также при их добавлении, изменении или удалении, что вызывает необходимость обеспечения сопоставимости значений свойств таких сущностей в разные временные периоды. В таких случаях необходимо обеспечить корректное одновременное (синхронное), совместное использование данных, относящихся к старой и новой структурам ОБД.
Рассмотрим требования к репозитарию ОБД. Репозитарий ОБД должен удовлетворять следующим основным требованиям.
1. Хранить метаданные всех стадий проектирования и разработки ОБД и предоставлять возможность коллективной работы с ними (механизмы сЬеск1п/сЬескОи1). При этом организация БмД репозитария ОБД должна соответствовать базовым концепциям международного стандарта ШББ 8 [9]. [8].
2. Поддерживать несколько способов визуализации одних и тех же метаданных. Репозитарий должен обеспечить возможность просмотра метаданных на трех уровнях - концептуальном, логическом и физическом в виде гипертекстовых документов.
3. Хранить подробную проектную и эксплуатационную документацию и создавать отчеты.
4. Поддерживать создание и администрирование моделей данных на различных уровнях представления ОБД и предоставлять ин-
терфейсы интеграции с облачными ресурсами и сервисами с использованием, например, услуги виртуального рабочего стола (УБ1).
5. Поддерживать управление версиями и изменениями модели метаданных.
6. Поддерживать соглашения по терминологии предметной области, а также именованию информационных элементов, объектов данных и методов (процедур поиска и обработки данных).
7. Анализировать и извлекать метаданные из множества источников, что гарантирует хранение в БмД актуальной информации об объектах ОБД.
8. Оповещать инструментальные средства и приложения о событиях, представляющих для них интерес, например, об изменении форматов или семантики объектов, контролируемых репозитари-ем. Такой механизм позволяет контролировать рассылку уведомлений между объектами с помощью методов или операций самих объектов.
9. Реализовывать механизм разграничения прав доступа пользователей на хранимые данные и метаданные.
10. Поддерживать форматы экспорта/импорта метамодели, соответствующие международным стандартам ИМЬ и 01М/СБ1Р (СА8ЕБа1а1п1егсЬа^еРогта1) [9].
11. Обладать свойством независимости от поставщиков облачных ресурсов, технологий и сервисов.
С учетом сформулированных требований, а также особенностей представления ОБД в виде объектно-ориентированной БД [5, 10], логическая структура БмДрепозитария ОБД должна содержать следующие разделы метаданных.
1. Раздел «Бизнес-процессы». Включает метаданные для описания условий и последовательностей выполнения бизнес-процессов (функций и процедур поиска и обработки данных) и связанных с ними информационных элементов и ограничений.
2. Раздел «Описание понятий». Содержит метаданные для представления и классификации информации. Составной частью данного раздела является тезаурус терминов предметной области.
3. Раздел «Общие типы данных». Содержит метаданные, обеспечивающие унификацию типов данных для моделей предметной области и структур ОБД различных уровней представления данных (канонического, логического, физического).
4. Раздел «Описание объектной модели данных». Содержит метаданные для описания объектных моделей требований пользователей, а также объектной канонической структуры ОБД.
5. Раздел «Описание схемы ОБД». Включает метаданные для описания структур данных, поддерживаемых в объектно-ориентированных БД. К ним относятся:
- название ОБД, объектов, методов, информационных элементов и других атрибутов;
- ключи групп (агрегатов) данных объектов;
- описания типов данных информационных элементов и ограничений для каждого из них;
- информация о правах доступа пользователей к объектам данных и информационным элементам;
- дата и время последнего изменения, а также идентификатор пользователя, выполнившего данное изменение;
- адресно-справочная информация об организации-собственнике ОБД и провайдере облака;
- информация о составе и характеристиках арендуемого оборудования, используемых облачных услугах и ресурсах провайдера облака;
- ссылки на внешние, не относящиеся к ОБД, но используемые ею в процессе эксплуатации файлы и БД;
- результаты аудита изменений данных пользователями;
- информация о прикладном программном обеспечении.
6. Раздел «Описание реструктуризации моделей данных». Содержит метаданные, описывающие следующие процедуры и процессы:
- процесс реструктуризации объектных моделей требований пользователей при изменениях в предметной области;
- процесс реструктуризации объектной канонической структуры ОБД при изменении объектных требований пользователей;
- процедуры построения модифицированной объектной канонической структуры ОБД;
- процесс преобразования объектной канонической структуры ОБД с учетом ограничений логических структур ОБД различных типов;
- процедуры построения логических структур ОБД (объектно-ориентированных, объектно-реляционных, объектно-иерархических и т. д.);
- процедуры построения рациональных логических структур БД различных типов.
7. Метаданные, описывающие логические и физические структуры ОБД различных типов с учетом особенностей языков описания данных выбранных СУБД.
8. Рабочие метаданные об информационной инфраструктуре АИУС, включая аппаратное и программное обеспечение облачных ИТ.
Формализованное описание исходных данных
Выделим следующие основные типы изменений, которые могут происходить в предметной области АИУС:
- изменения существующих информационных требований и функциональных пользователей, заключающиеся в добавлении и/или удалении информационных элементов, объектов данных и методов их обработки;
- поступление новых информационных и/или функциональных требований пользователей;
- удаление существующих информационных и/или функциональных требований пользователей.
В соответствии с приведенной классификацией основных типов изменений в предметной области процесс их анализа и реструктуризации включает решение следующих задач:
1) анализ и реструктуризация объектной канонической модели ОБД при изменении информационных и функциональных требований пользователей;
2) анализ вновь поступающих требований пользователей и построение модифицированной объектной канонической структуры ОБД;
3) анализ и реструктуризация объектной канонической структуры ОБД при удалении требований пользователей.
Исходными данными для разработанных процедур анализа и реструктуризации являются формализованное описание и характеристики объектной канонической структуры ОБД, полученной на этапе предпроектного анализа предметных областей пользователей [5], а также формализованное описание изменяющихся или новых требований пользователей, задаваемых в виде объектных моделей данных.
Объектная каноническая структура ОБД формализованно представляется в виде графа С^О, А), вершинами которого О = {Ое / е = 1, е0} являются объекты предметной области, а дугами
А={8ее'/е,е' = 1, е0}- связи (отношения) между объектами. Дуги графа Сокбс(О, А) определяют наличие семантических и функциональных связей между объектами и описываются матрицей смеж-
ности Вкбс = ||Ьее,||. Характеристиками графа Сявляются интегральные характеристики объектов и связей между ними [5, 10].
Каждый объект Ое характеризуется множеством входящих в него информационных элементов Бе = {й | I е Ье с Ц, матрицей смежности информационных элементов объекта (ключей и зависимых от них атрибутов) Ве = ЦЬц, ||, множеством методов (процедур поиска и обработки данных) Ре = {рг | г е Яе с Я] и матрицей технологии обработки информационных элементов объекта Wе = ||м>Г} ||; г = 1, Яе , I = 1, Ье . Каждый элемент матрицы Wе удовлетворяет условию:
<< =<
+ 1, если й1 является входным для метода (процедуры) рг 0, если й не используется в методе (процедуре) рг _ -1, если й1 является выходным для метода (процедуры) рг-
Таким образом, составы объектов канонической структуры ОБД описываются входящими в них информационными элементами, методами и структурой отношений между ними и задаются в виде множеств Н(Ое) = {Бе, Ре, (й, рг), ..., (йь, рг,), {(й, й)}}. На основании матрицы Wе строится матрица технологической достижимости Ме, описывающая последовательность выполнения методов (процедур) объекта, пути доступа между элементами [10, 11], а также структуру обработки данных (принадлежность информационных элементов к входным или выходным элементам для последовательности методов их обработки).
Основной характеристикой информационного элемента объекта является тип данного, который определяет диапазон возможных значений информационного элемента, допустимые операции над его значениями, а также способ хранения данных в памяти. Различают простые типы данных, к которым относятся строковые, действительные и другие величины, а также составные или сложные типы данных - массивы, списки, файлы. Информационные элементы относятся к одному типу данных, если для всех значений данных из их доменов выполняются заданные условия и ограничения по диапазону значений информационных элементов, операциям обработки данных и способу хранения данных.
Типы данных информационных элементов объектной канонической структуры ОБД задаются матрицей смежности £ = | , проиндексированной по осям множеством типов данных Т = {¿¡} и полным множеством информационных элементов Б0 = {| ] е Ь }
ОБД. К одному типу данных относятся информационные элементы, для которых = 1, V dJ е О0.
Информация об изменяющихся требованиях пользователей задается в режиме диалога с администратором ОБД в следующем виде:
1. При удалении информационного элемента 4 из к-го объекта - в виде пары (4, к), где к - идентификатор объекта (к е е0} из которого удаляется элемент.
2. При добавлении информационного элемента 4 в к-й объект - в виде четверки (4, р, 4, к), где к - идентификатор объекта, подлежащего изменению, р{ - метод обработки данных, используемый для добавляемого информационного элемента, 4 - групповой элемент (агрегат данных) объекта, с которым устанавливается отношение смежности.
3. При добавлении к-го требования - в виде модели спецификации информационных требований, задаваемой множеством кортежей Мкспец = <аЯр>, где к - индекс пользователя, а и Ь - структурные элементы предметной области, Я - отношение между элементами, и модели спецификации функциональных требований пользователя (модели спецификации инцидентов), формализованно представляемой в виде предиката М^ = кк(й1| 4 е Бк с Б), где кк - метод обработки (процедура поиска и обработки данных). Для формирования спецификаций информационных и функциональных требований пользователей могут использоваться алгоритмы, приведенные в работах [10, 11].
4. При удалении требования к-го пользователя - в виде объектной модели требования к-го пользователя, формализованно представляемой в виде графа Скоб(Бк, Ц) и матрицы смежности Вк = ||Ьк ||, где Бк = {й^ /1 = 1, Ьк, Ькс Ь} - множество объектов данных с входящими в них информационными элементами (включая ключи и атрибуты данных) и процедурами поиска и обработки данных; ик = Цо6 и Цэл и Цпр - множество дуг (отношений) между объектами, где и°б - множество дуг, характеризующих интерфейсную часть объектов; Цэл - множество дуг, характеризующих структуру взаимосвязей между информационными элементами объектов данных; Ц^ - множество дуг, характеризующих реализационную часть объектной модели данных, а именно, технологию поиска и обработки данных для к-го пользователя в виде реализации совокупности методов (процедур) поиска и непосредственной обработки данных, включая петли и непосредственно дуги [10].
Методы реструктуризации объектной канонической структуры ОБД при изменении информационных требований пользователей
При удалении информационного элемента й{ разработанные процедуры анализа и реструктуризации проводятся в следующем порядке.
1. По введенному номеру к выбирается объект Ок е О, подлежащий изменению.
2. Выполняется проверка, является ли элемент й{ корневым в структуре объекта Ок, т. е. существует ли в технологической матрице достижимости Мк единичный элемент в позиции (йр ра), ра е Ре. Если нет, то переход на 3. В противном случае - на 9.
3. По матрице технологии Wk определяется множество методов Ра, для которых элемент й{ является выходным.
4. Осуществляется удаление строк и столбца в матрице Wk, соответствующих методам множества Ра и информационному элементу й.
5. Информационный элемент й{ и методы множества Ра удаляются из состава объекта Ок, Н(Ок) = Н(Ок)\й{, Н(Ок) = Н(Ок)\Ра.
6. На основании матрицы типов данных информационных элементов S = ||5г>|| определяется тип 1} данного информационного элемента й., = 1.
7. На основании матрицы смежности объектов Вкбс = ||Ьее,|| определяется объект Ое, в состав которого входит элемент й{ типа } т. е. проверяется выполнение условия: Н(Ое) С\й{* 0? Если условие выполняется, то переход на 8, в противном случае - на 10.
8. Производится удаление элемента типа й{ из состава объекта Ое, т. е.
Н(Ое) = Н(Ое)\й,
9. Принимается решение о невозможности удаления информационного элемента, так как при этом структура объекта Ок распадается на ряд не связанных между собой подструктур.
10. Конец. Вывод на печать преобразованного графа объектной канонической структуры ОБД и соответствующей ей матрицы смежности.
Процедуры анализа и реструктуризации при добавлении нового информационного элемента й{ проще и заключаются в следующем. По заданному номеру к выбирается объект Ок е О, подвергающийся изменению. Информационный состав объекта расширяется путем добавления нового элемента, т. е. Н(Ок) = Н(Ок) и й;.
В матрице смежности информационных элементов к-го объекта Вк = ||Ь| || на пересечении г-й строки (4-го информационного элемента) и 7-го столбца (4;-го группового элемента) вводится единичное значение. В матрице технологии Жк добавляется новый столбец, соответствующий информационному элементу 4, и на пересечении со строкой рг фиксируется 1.
По завершении процедур реструктуризации объектной канонической структуры ОБД при изменении информационных требований пользователей в соответствующие разделы логической структуры БмД репозитария ОБД вносятся изменения.
Методы анализа вновь поступающих требований пользователей и построения модифицированной объектной канонической структуры ОБД
Пусть Онов = {Ок} - множество новых объектов, выявленных и сформированных в процессе анализа вновь поступающих информационных требований. Каждый новый объект Ок характеризуется множеством входящих в него информационных элементов Бк ={411 е Ц}, матрицей смежности информационных элементов Вк = ||Ьк ||, множеством методов (процедур поиска и обработки данных) Рк = {рг|г е Як} и матрицей технологии обработки информационных элементов Жк = ||^|||. Состав нового объекта Ок описывается входящими в него элементами, методами и структурой отношений между ними и задается в виде множества И(Ок) = {Бк, Рк (4,рк), ...,
(4, р^, {(4, 4.)}}.
Для сокращения трудоемкости реструктуризации объектной канонической структуры ОБД при добавлении нового объекта на начальном этапе разработанных процедур определяется подмножество пересечения Б' полного множества информационных элементов объектной канонической структуры ОБД Б0 и нового объекта Б к, т. е. Б' = Б0 п Бк.
При этом возможны следующие случаи.
1. Б' = 0, т. е. новый объект состоит только из новых информационных элементов, отсутствующих в имеющейся объектной канонической структуре ОБД.
2. Б* * 0, т. е. добавляемый объект содержит информационные элементы, имеющиеся в объектной канонической структуре ОБД.
В случае, когда объект Ок состоит только из новых информационных элементов, т. е. Б' = 0, реструктуризация объект-
ной канонической структуры ОБД выполняется в следующем порядке.
1. По информации о характеристиках информационных элементов объекта Ок определяется тип каждого информационного элемента Ок и его принадлежность существующим типам данных объектной канонической структуры
мости вводятся новые типы данных и, таким образом, множество новых информационных элементов сопоставляется с множеством соответствующих им типов данных. Матрица типов данных 5||5}|| расширяется путем добавления новых столбцов, соответствующих информационным элементам объекта Ок, и строк, соответствующих новым типам данных.
2. Определяется подмножество объектов Ое е О, для которых выполняется условие Н(Ое) П Н(Ок) = Н(Ок).
3. Проверка условия: Ое * 0? Если да, то переход на 4, в противном случае - на 5.
4. Выполнение условия свидетельствует о существовании объектов, состоящих из типов данных нового объекта. В этом случае процедура добавления нового объекта состоит из следующих шагов:
4.1. Проводится анализ методов обработки данных, которые входят в состав объектов множества Ое и нового объекта Ок. Для этого сравниваются матрицы технологий каждого объекта Же и нового объекта Жк. В случае, когда матрица технологии объекта Ое содержит процедуры, не определенные в матрице Жк, осуществляется удаление данных процедур из состава объекта Ое, т. е. вычеркивается соответствующая строка из матрицы Же.
4.2. Между объектами множества Ое и объектом Окопределяются отношения наследования и в матрице смежности В^ на пересечении строки и столбца, соответствующих анализируемым объектам, фиксируется 1. Переход на 6.
5. На графе объектной канонической структуры ОБД Ск°сб(О, А) вводится новая вершина Ок, соответствующая новому объекту, а также (для обеспечения связности канонической структуры) дополнительная вершина О5(б <£ Ь) и дуги из нее в вершину Ок и в вершины верхнего уровня иерархии графа ^(О, А).
6. Конец. Завершение процедур анализа. Вывод на печать модифицированного графа объектной канонической структуры ОБД Скмсод(О, А) и соответствующей ей матрицы смежности Вк°сб = ||Ьее'||.
Если новый объект Ок содержит имеющиеся на графе объектной канонической структуры ОБД С°!(О, А) информационные
элементы, т. е. Б* * 0, то операциям, описанным выше, предшествуют следующие.
1. Определяется множество объектов {Оп} объектной канонической структуры ОБД, которые содержат элементы множества Б*.
2. Проверяется условие: Б* = Бк? Если да, то переход на 3, в противном случае - на 5.
3. Выполнение условия Б* = Бк свидетельствует о том, что в состав добавляемого объекта входят только существующие на графе объектной канонической структуры ОБД информационные элементы. В этом случае новый объект на графе Скосб(О, А) не формируется.
4. По матрице достижимости графа Скосб(О, А) проверяется наличие путей доступа между объектами Ое, в которых они присутствуют. При наличии путей доступа между выделенными объектами никаких преобразований объектной канонической структуры ОБД не требуется. В случае отсутствия связи между парой объектов Оа и Ор, в которые вошли элементы добавляемого объекта, данная связь устанавливается на графе Скосб(О, А) путем фиксации в матрице смежности Вкосб = ||Ьее,|| единичных записей на пересечении строки и столбца, соответствующих объектам Оа и Ор. В БмД репозитария ОБД заносится справочная информация о принадлежности анализируемых информационных элементов новым объектам. Переход на 6.
5. Из состава объекта Ок удаляются информационные элементы подмножества пересечения Б*, т. е. Н(Ок) = И(Ок)\Б". В случае, когда множество {Оп} содержит только один объект, проектировщиком ОБД принимается решение о переносе оставшихся в объекте Ок информационных элементов и процедур в объект Оп. В случае принятия такого решения состав объекта Оп модифицируется путем добавления информационных элементов и процедур из объекта Ок, т. е. Н(Оп) = Н(Оп)и Н(Ок). В противном случае, на графе объектной канонической структуры ОБД Скосб(О, А) вводится новая вершина Ок, устанавливается взаимосвязь между объектом Ок и объектами множества {Оп}; в матрице смежности ВО6 = ||Ьее,|| вводятся дополнительные строка и столбец Ок и фиксируются единичные записи.
6. Конец. Завершение процедур анализа и реструктуризации.
В дальнейшем выполняются процедуры реструктуризации объектной канонической структуры ОБД, аналогичные описанным выше для случая Б* = 0.
При добавлении нового требования пользователя, формализованно представляемого в виде модели информационной специфи-
кации М|;пец = <аЯр>, и модели функциональной спецификации Мпр = Ик(411 41 е Бкс Б), выполняется следующая последовательность процедур.
На первом этапе на основании моделей информационных и функциональных спецификаций осуществляется построение с использованием предложенных в [10] методов объектной модели требований пользователей, представляемой в виде графа С°кЬ(Бк, Ц).
На втором этапе описание элементов объектной модели, в частности, наименования объектов данных, информационных элементов, процедур и отношений между ними, приводится в соответствие с метаданными элементов объектной канонической структуры ОБД, хранящимися в БмДрепозитария. При необходимости вносятся правки в словарь-справочник данных БмД.
На третьем этапе выполняются операции объединения графа объектной канонической структуры ОБД Скос6(О, А) и графа сформированной объектной модели требований пользователей С1Ь(Бк, Ц). Для выполнения этих операций могут использоваться методы и алгоритмы, предложенные в [11] и основанные на совмещении идентичных информационных элементов независимо от уровня их размещения на графах Скос6(О, А) и С°к(Бк, Ц).
На четвертом этапе выполняется упорядочение и нормализация полученного обобщенного графа объектной канонической структуры с использованием методов и алгоритмов, предложенных в [5].
На пятом этапе сформированная в результате добавления нового требования пользователя объектная каноническая структура ОБД Скмсод(О, А) и соответствующая ей матрица смежности Вкмсод = ||Ьее,|| выводятся на печать.
Методы анализа и реструктуризации
объектной канонической структуры ОБД
при удалении информационных требований пользователей
Исходной для процедур данного этапа является информация об информационных структурах Бк, подлежащих удалению. Каждая удаляемая структура формализованно задается в виде графа С°Ь(Бк, Ц) объектной модели требования к-го пользователя. При этом возникают проблемы удаления информационной структуры из объектной канонической модели ОБД, а также исключения информации по соответствующему информационному требованию из БмД репозитария. Решение данных проблем предполагает проведение комплексного анализа имеющихся структур пользовате-
лей с целью выявления наличия в них одинаковых структурных элементов. Для этого определяется подмножество информационных элементов, специфичных для информационной структуры 5к: Ьк
Як = Вк \ и (Д п Бк), I * к. 1=1
При этом возможны три случая.
1. В** = 0. В этом случае реструктуризацию объектной канонической модели ОБД проводить не следует, так как все структурные элементы, входящие в удаляемую структуру Бк, присутствуют в информационных структурах других пользователей.
2. В*** = Вк. Этот случай соответствует ситуации, когда все информационные элементы удаляемой структуры Бк уникальны и они могут быть без нарушения целостности ОБД удалены из объектной канонической модели. Для этого определяется множество {О;} объектов объектной канонической структуры, в состав которых входят информационные элементы подмножества В***, т. е. Н(О;) П Д*** = 0, УО; е О. Информационные составы объектов множества {О;} модифицируются путем удаления из них информационных элементов множества Д", т. е. Н(О;) = Н(О;)\Д**, УО; е О.
3. Дк * 0. В этом случае удалению подлежит только часть элементов информационной структуры Бк, вошедших в подмножество В**. Процедуры реструктуризации аналогичны рассмотренным выше процедурам удаления одного элемента и заключаются в последовательном удалении элементов множества П'к.
Следует отметить, что независимо от того, будет ли проводиться реструктуризация объектной канонической модели или нет, вся информация, хранящаяся в БмД репозитария по анализируемой информационной структуре Бк, подлежит удалению.
Заключение
Таким образом, предложенные в работе методы и алгоритмы обеспечивают в автоматизированном режиме оперативное внесение изменений в информационные и функциональные требования пользователей, реструктуризацию объектных моделей пользователей и построение модифицированной объектной канонической структуры ОБД. Разработанные методы и алгоритмы обеспечивают полноту, актуальность, непротиворечивость и достоверность структур данных ОБД в соответствии с изменяющимися во време-
ни характеристиками предметной области и требованиями пользователей и своевременную реструктуризацию и реорганизацию ОБД. Предложенные методы использовались при разработке ряда проектов информационной инфраструктуры Евразийского патентного ведомства Евразийской патентной организации.
Литература
1. Cloud Computing: Principles, Systems and Applications / Nick Antonopoulos, Lee Gillam. L.: Springer, 2010. 379 p.
2. Батура Т.В., Мурзин Ф.А., Семич Д.Ф. Облачные технологии: основные модели, приложения, концепции и тенденции развития // Программные продукты и системы. 2014. № 3 (107). С. 64-72.
3. Mell P., Grance T. The NIST Definition of Cloud Computing. Recommendations of the National Institute of Standards and Technology. NIST Special Publication 800-145. 2011. September.
4. Черняк Л. Интеграция - основа облака // Открытые системы. СУБД. 2011. № 07.
5. Сиротюк В.О., Косяченко С.А. Моделирование предметных областей пользователей при использовании облачных технологий // Вестник РГГУ. Серия «Экономика. Управление. Право». 2017. № 4 (10). С. 74-87.
6. Саймон А. Репозитарии и управление метаданными. СУБД. 1996. № 5-6. С. 154-162.
7. Сиротюк В.О. Модели и методы синтеза оптимальных логических структур и базы метаданных репозитария распределенных баз данных в АСУ // Автоматика и телемеханика. 1999. № 1. С. 166-186.
8. Noll J., Scacchi W. Integrating Diverse Information Repositories: Distributed Hypertext Approach. IEEEComputer. 1991. December.
9. Фаулер М. UML. Основы. Краткое руководство по стандартному языку объектного моделирования. 3-е изд. СПб.: Символ-Плюс, 2018. 192 с.
10. Кульба В.В., Микрин Е.А., Сиротюк В.О., Сиротюк О.В. Модели и методы проектирования оптимальных структур объектно-ориентированных баз данных в автоматизированных информационно-управляющих системах. М.: ИПУРАН, 2005. 103 с.
11. Кульба В.В., Ковалевский С.С., Косяченко С.А., Сиротюк В.О. Теоретические основы проектирования оптимальных структур распределенных баз данных. М.: СИНТЕГ, 1999. 660 с. (Серия «Информатизация России на пороге XXI века»)
References
1. Cloud Computing: Principles, Systems and Applications / Nick Antonopoulos, Lee Gillam. L.: Springer, 2010. 379 p.
2. Batura TV., Murzin FA., Semich DF. Cloud Technologies. Basic Models, Applications, Concepts and Trends. Software products and systems. 2014;3(107):64-72. (In Russ.)
3. Mell P., Granee T. The NIST Definition of Cloud Computing. Recommendations of the National Institute of Standards and Technology. NIST Special Publication 800-145. 2011. September.
4. Chernyak L. Integration - the Foundation of the Cloud. Open systems. DBMS. 2011;07. (In Russ.)
5. Sirotyuk VO., Kosyachenko SA. Modeling of subject domains at users of cloud technologies. RSUH/RGGUBulletin. "Economics. Management. Law" Series. 2017;4(10): 74-87. (In Russ.).
6. Saimon A. Repositories and metadata management. DBMS. 1996;5-6:154-62. (In Russ.)
7. Sirotyuk VO. Models and methods of synthesis of optimal logical structures of the database and the metadata repository of distributed databases in the PMS. Automation and remote control. 1999;1;66-86. (In Russ.)
8. Noll J., Scacchi W. Integrating Diverse Information Repositories. Distributed Hypertext Approach. IEEEComputer. 1991. December.
9. Fowler M. UML Distilled. A Brief Guide to the Standard ObjectModeling Language. 3rd ed. Saint-Petersburg: Simvol-Plyus Publ.; 2018. 192 c. (In Russ.)
10. Kul'ba VV., Mikrin EA., Sirotyuk VO., Sirotyuk OV. Models and methods of designing optimal structures of object-oriented databases in automated information and control systems. Moscow: IPURAN Publ.; 2005. 103 p. (In Russ.)
11. Kul'ba VV., Kovalevskii SS., Kosyachenko SA., Sirotyuk VO. Theoretical foundations of designing optimum structures of the distributed databases. Moscow: SINTEG Publ.; 1999. 660 p. ("Informatization of Russia on the threshold of 21st century" Series) (In Russ.)
Информация об авторах
Николай Л. Лепе, кандидат физико-математических наук, Российский государственный гуманитарный университет, Москва, Россия; 125993, Россия, Москва, Миусская пл., д. 6; fu@rggu.ru
Владимир О. Сиротюк, доктор технических наук, доцент, Институт проблем управления им. В.А. Трапезникова РАН, Москва, Россия; 117997, Россия, Москва, ул. Профсоюзная, д. 65; vsirotyuk.55@icloud.com
Information about the authors
Nikolay L. Lepe, Ph.D. in Physics and Mathematics, Russian State University for the Humanities, Moscow, Russia; bld. 6, Miusskaya Square, Moscow, Russia, 125993; fu@rggu.ru
Vladimir O. Sirotyuk, Doctor in Engineering, associate professor, V.A. Trapeznikov Institute of Control Sciences of the Russian Academy of Sciences, Moscow, Russia; bld. 65, Profsoyuznaya Str., Moscow, Russia, 117806; vsirotyuk.55@icloud.com
