CC BY
35
© А.М. Валуев, А.С. Панкратов, 2010
А.М. Валуев, А.С. Панкратов
ОБ ОДНОМ ПОДХОДЕ К ИНТЕГРАЦИИ ИНФОРМАЦИИ ИЗ НЕЗАВИСИМЫХ БАЗ ДАННЫХ В СИСТЕМАХ АВТОМАТИЗИРОВАННОГО УПРАВЛЕНИЯ
Рассматривается проблема интеграции и совместного использования независимых баз данных по угольным месторождениям с целью уточнения параметров залегания и качества угольных слоёв. В качестве технологии интеграции предлагается использование медиатора с участием вспомогательного хранилища данных.
Ключевые слова: базы данных, интеграция информации, мультибазовые системы, медиатор, хранилище.
Лроявляющаяся во многих аспектах современной жизни нашей страны тенденция децентрализации различных сфер хозяйственной деятельности ведёт к необходимости формирования устойчивых межведомственных и межкорпоративных связей, объединения на информационном и иных уровнях в рамках одной предметной области. Иными словами, в настоящее время возникает потребность в разного рода интеграционных процессах, актуальность которых ощущается в настоящее время во всём мире. Одним из важнейших аспектов процесса интеграции является проблема консолидации информации из различных и независимых источников, в частности, объединение в единое целое разнородных баз данных, без ущерба их независимости.
Данной проблематике посвящён ряд работ российских и зарубежных авторов. Среди российских учёных, занимающихся проблемами интеграции можно назвать работы Л.В. Масель, А.В. Чер-ноусова, А. Кудинова. Однако следует отметить, что в настоящее время лишь намечаются основные контуры обобщённого подхода к решению задачи интеграции данных из разных компьютерных систем (см., например, [1]), большинство публикаций на эту тему затрагивает лишь отдельные аспекты проблемы либо частные предметные области (например, учёт объектов недвижимости) со своими специфическими особенностями [2, 3]. Настоящая работа посвящена задачам горного производства и также не претендует на
общность, однако представляется, что описанный ниже подход может иметь и более широкое применение.
В работе рассматриваются вопросы построения компьютерной системы для ведения баз данных по сложноструктурным пологим угольным месторождениям, характерным для Восточной Сибири и Дальнего Востока, которые разрабатываются или могут разрабатываться открытым способом. Это является необходимым для проведения по ним комплекса расчетов, позволяющих обосновать принципиальные проектные решения, примером чего служат выполненные в Московском государственном горном институте исследования на основе базы данные эксплуатационной разведки и опробования [4]. Одной из важнейших её функций является уточнение параметров залегания и качества угольных слоёв на основе вновь введённых данных и сопоставление их с уже имеющейся информацией в базе. Однако представляется целесообразным эту компьютерную систему расширить: а именно, для уточнения информации использовать с помощью компьютерной сети базы данных других организаций, связанных тем или иным образом с угольной промышленностью. Это могут быть, например, данные геофизической разведки, маркшейдерская база данных, база данных оперативно-диспетчерского управления внутри карьера, база данных железной дороги о передвижениях грузовых составов, включая составы с углем, база данных сбытовой организации, база данных какой-либо электростанции о запасах угля и выходе электроэнергии при его сжигании по календарным периодам. Все названные базы данных отличаются в общем случае разнородным характером, поскольку выполнены своими разработчиками и ориенти-рованы на свой класс задач. Поэтому для построения расширенной компьютерной системы, описывающей сложноструктурные пологие угольные месторождения, в качестве первого этапа потребуется создание интегрированной (мультибазовой) системы, прозрачным образом располагающуюся поверх уже существующих баз данных (в дальнейшем -источников), содержащих информацию о месторождениях данных регионов и объединяющую их в единое целое [5]. Настоящая работа посвящена описанию такой интегрированной системы.
Существует три основных подхода к интеграции баз данных
■ Федеративные базы данных - источники независимы, но могут сообщаться между собой для обмена информацией. Такой подход эффективен при наличии небольшого числа источников: при п источниках для обеспечения связи каждого с каждым потребуется написать п(п-1) фрагментов программного кода, обеспечивающих трансляцию запросов.
■ Хранилища данных - данные от источников на периодической основе загружаются в централизованное хранилище, возможно, с предварительной обработкой с целью приведения их в соответствие со структурой хранилища.
■ Медиаторы - программные компоненты, принимающие запросы от пользователей и затем направляющие их к соответствующим источникам, возможно, с предварительной трансляцией; полученные ответы от источников приводятся в соответствие со структурой медиатора, объединяются и выдаются пользователю.
Для рассматриваемой задачи представляется целесообразным использовать технологию медиатора, поддерживающего постоянно обновляемый каталог данных, призванный оптимизировать работу системы. На основе этого каталога запросы направляются только к тем источникам, которые могут содержать требуемую информацию и не направляются к остальным источникам.
Поскольку подобным интегрированным мультибазовым системам приходится работать «с тем, что есть», т. е. с той информацией, которую каждый из источников выставил в сеть «для общего пользования», представляется уместным разделить все источники на два класса, будем их условно называть «категория “А”» и «категория “В”». Опишем каждую из них.
Категория «А». Источники этой категории относятся к организациям (как правило, сходных или смежных предметных областей), договорившимся между собой о совместном доступе к своим данным. Каждый источник выставляет в сеть часть своих данных, и эти выставленные данные от разных источников описывают сходные сущности, содержат ряд одинаковых характеристик, но могут отличаться в наименованиях таблиц, полей, типах данных, множествах допустимых значений, также возможны ситуации, когда какая-либо характеристика присутствует в одном источнике, но отсутствует в другом. Будем полагать, все источники используют
формат таблиц .dbf и поддерживают SQL-формат запросов. Интеграция источников данной категории решается с помощью таблиц соответствия, на основе которых осуществляется перекодировка запросов.
Категория «В». В [6] такие источники названы «источниками с ограниченными возможностями». К примеру, источник может не быть базой данных, поддерживающей SQL, а управляться с помощью устаревших технологий или уникальных методов и приёмов (проблема «унаследованных систем»). Такие структуры спроектированы на применение особых разновидностей запросов, и они зачастую не позволяют осуществить перенос данных в среду современной системы. В сети они обычно бывают оснащены только Web-интерфейсами и допускают обращение к себе исключительно при посредничестве форм и не воспринимают произвольные SQL-запросы: пользователю предлагается ввести значения определённых атрибутов, и в результате обработки запроса Web-сервер возвращает наборы значений других атрибутов, удовлетворяющие заданным критериям. При работе медиатора с такого рода источниками потребуется поддержка при медиаторе дополнительного оптимизатора, генерирующего план исполнения запроса, учитывающего возможности источников, и программных кодов, позволяющих обращаться к Web-форме источника, ответы на запросы загружать во временные таблицы с возможностью применения к ним операций реляционной алгебры.
Будем полагать, что в рассматриваемой задаче объединения баз данных, касающихся информации об угольных месторождениях, присутствуют источники обеих категорий. Для рабочей модели к категории «А» можно отнести данные геологической и геофизической разведок, маркшейдерская база данных и база данных оперативно-диспетчерского управления внутри карьера, к категории «В» - база данных железной дороги о передвижениях грузовых составов, база данных сбытовой организации, базы данных электростанций. При этом из некоторых источников (базы данных железной дороги и электростанций) можно извлекать лишь косвенную информацию, касающуюся параметров месторождений. В связи с этим, работа с данными источниками должна вестись «по особому режиму», с применением методов оперативной аналитической обработки (OLAP), организации кубов данных, технологии разработки данных (data mining) [5, 6]. Подобная работа требует отдельного
рассмотрения и выходит за рамки настоящей публикации. Что касается базы данных сбытовой организации, будем полагать, что, относясь к категории «В», она, тем не менее, позволяет извлекать информацию, связывающую участок разработки с качеством добываемого на этом участке угля.
Основные требования к интегрирующей системе:
■ она должна предоставлять доступ ко всей информации от источников (с возможностью последующей фильтрации), касающейся конкретного месторождения либо какого-то из его участков;
■ соответствующие подзапросы направлять не ко всем источникам, а только к тем, где имеются запрашиваемые данные; для этой цели создаётся централизованный каталог-хранилище, в который от источников периодически закачивается информация обо всех новых участках месторождения, появившихся в базе данных источника после предыдущей закачки;
■ подключать к системе новые источники информации.
Потребуется также создать рабочие интерфейсы для пользователя и администратора, последний должен иметь возможность отслеживать состояние хранилища и процесс закачки данных.
В процессе построения такой системы возникает подзадача уникальной идентификации участков месторождения, поскольку на разных источниках (в силу их независимости) может быть свой принцип именования. К примеру, для организации, ведущей эксплуатационную разведку и опробование месторождения, это может быть наименование месторождения, координаты скважины в локальной системе координат, название разведочной линии; для геофизиков (после обра-ботки данных геофизической разведки) - наименование площади, её географические границы, наименование геофизического профиля и его параметры, координаты точки на профиле. Чтобы не перегружать схему, будем полагать, что эта подзадача решена, и при медиаторе (интегрирующей оболочке) прописаны правила приведения параметров участка месторождения (на источниках) к единому формату (к примеру, представляющего собой значения географической широты и долготы).
Таблица 1
Структура таблицы MR
Имя поля Описание
тс Код месторождения
MRN Наименование месторождения
ORIGIN X Г еографическая широта начала локальной системы координат
ORIGIN Y Г еографическая долгота начала локальной системы координат
Таблица 2
Структура таблицы GEOSK
Имя поля Описание
MRC Код месторождения
SKV Наименование скважины
KROVLA Глубина кровли, метров
POCHVA Глубина почвы, метров
MOSH Мощность, равная разности глубин почвы и кровли, метров
ZOLA Зольность (в процентах)
UDV Удельный вес (плотность), т/м3
PORODA Тип породы
PLAST Наименование пласта
Таблица 3
Структура таблицы SKVG
Имя Описание
поля
MRC Код месторождения
SKV Наименование скважины
X Абсцисса устья скважины в локальной системе координат, м
Y Ордината устья скважины в локальной системе координат, м
OTM US Высотная отметка устья скважины, м
LIN Название разведочной линии
N Вспомогательная величина, характеризующая положение скважины относительно границ этапа
Структура медиатора в простейшем случае объединяет все структуры источников, однако для практической задачи целесообразно использовать лишь некое подмножество этого объединения, содержащее характеристики, существенные для данной задачи. Продемонстрируем принцип работы медиатора на модели, охватывающей два источника категории «А»: база данных эксплуатационников и геофизиков. Будем их именовать, соответственно, DB1 и DB2.
Модельная структура источника DB1: содержит три таблицы -MR, GEOSK и SKVG (здесь и далее ключевые поля подчёркнуты).
Источник DB2 содержит обработанные данные геофизической съёмки. Эта съёмка в общем случае представляет собой замеры
геофизического поля (гравитационного, магнитного либо сейсмических колебаний после взрывных работ) вдоль некоторой линии (профиля) на земной поверхности. При обработке этих первичных данных значения геофизического поля восстанавливаются вдоль профиля в толще земли, и по конфигурации линий уровня восстановленного поля становится возможным оценить границы раздела геологических сред и плотности этих сред.
Модельная структура источника DB2 представляет собой описания для точек профилей (с некоторым шагом) уровней раздела геологических сред и их плотностей. Последние два показателя представляют для каждой точки многозначный атрибут, в связи с чем выносятся в отдельную таблицу. Источник содержит три таблицы: PROFIL, TOCHKA и SLOI
Таблица 4 Описанную
структуру источников можно дополнить информацией о типах значений полей, однако чтобы не перегружать схему, в данной работе предполагается, что при медиаторе описаны правила преобразования стандартных типов данных, на основании которых преобразование типов в случае необ-Таблица 6 ходимости делается
автоматически.
Структура медиатора в простейшем случае объединяет все структуры источников, однако для данной задачи целесообразно использовать лишь некое подмножество этого объединения, содержащее наиболее существенные характеристики, а именно: координаты точки (скважины), глубина кровли, глубина почвы, зольность, плотность, тип по-
Структура таблицы SLOI
Имя поля Описание
ш Номер точки
GL Глубина верхней границы слоя
PLOTN Плотность слоя
Структура таблицы PROFIL
Имя поля Описание
PN Код профиля
PNAME Название профиля
PSTART X Широта начала профиля
PSTART Y Долгота начала профиля
PEND X Широта конца профиля
PEND Y Долгота конца профиля
Таблица 5
Структура таблицы ТОСНКА
Имя поля Описание
ш Уникальный номер точки
PN Код профиля
БВТ Расстояние до точки от начала профиля
OTM Высотная отметка точки
Таблица 7
Структура таблицы POINTS
Имя поля Описание
PN Номер точки
POINT X Г еографическая широта точки
POINT Y Г еографическая долгота точки
Таблица 8
Структура таблицы GEO
Имя поля Описание
PN Номер точки
KROVLA Глубина кровли, метров
POCHVA Глубина почвы, метров
ZOLA Зольность (в процентах)
UDV Удельный вес (плотность), т/м3
PORODA Тип породы
роды. В связи с многозначностью атрибутов их можно свести в две таблицы: POINTS и GEO.
Взаимосвязь элементов данных из различных источников (необходимую при исполнении запросов к медиатору) описывается, как правило, с помощью таблиц соответствия. При интеграции данных с помощью медиатора, представляющего, по сути, виртуальную базу данных (представление для пользователя), эта виртуальная база имеет свои характеристики (реквизиты), которые также заносятся в общую таблицу соответствия. Для рассматриваемой задачи все соответствия могут быть сведены в две таблицы 9 и 10.
Для остальных источников (категории «А»), равно как и для подключения новых источников этой категории, в таблицах TA-BLE_CORR_GEO и TABLE_CORR_POINTS заводятся новые колонки - в простейшем случае с названиями соответствующих атрибутов, в более сложных случаях с функциями преобразования.
Вспомогательное хранилище-каталог, содержащееся при медиаторе, представляет собой перечень точек, на которые имеется на каком-либо источнике геологическая информация с указанием соответствующего источника. Координаты точки при этом представлены в формате медиатора. По сути, оно является обновляемой на периодической основе таблицей Таблица 9
Таблица TABLECORRGEO, описывающая простые соответствия атрибутов
Медиатор.
таблица
Медиатор. DB1. DB1. DB2. DB2.
таблица. таблица таблица. таблица таблица.
поле поле поле
GEO KROVLA GEOSK KROVLA SLOI GL
GEO POCHVA GEOSK POCHVA SLOI NULL
GEO ZOLA GEOSK ZOLA SLOI NULL
GEO UDV GEOSK UDV SLOI PLOTN
GEO PORODA GEOSK PORODA SLOI NULL
Таблица 10
Таблица TABLE_CORR_POINTS, содержащая функции приведения координат точки к формату медиатора (географическая широта и долгота) F1X, F1Y, F2X, F2Y
Медиатор. таблица Медиатор. таблица. поле DB1. значение DB2. значение
POINTS POINT_X F 1X(MR. ORIGIN X, MR.ORIGIN Y, SKVG.X, SKVG.Y) F2X(PROFIL.PSTART X, PROFIL.PSTART Y, PRO-FIL.PEND X, PRO-FIL.PEND_Y, TOCHKA.DIST)
POINTS POINT_Y F1Y(MR. ORIGIN X, MR.ORIGIN Y, SKVG.X, SKVG.Y) F2Y(PROFIL.PSTART X, PROFIL.PSTART Y, PRO-FIL.PEND X, PRO-FIL.PEND Y, TOCHKA.DIST)
«POINTS_CAT» с полями «POINT_X», «POINT_Y» и «SOURCE» (идентификатор источника).
Основной запрос, который адресуется медиатору, может быть сформулирован так: вывести всю имеющуюся на источниках и представленную в медиаторе геологическую информацию по заданной точке и вблизи неё в радиусе d (величина d задаётся пользователем). Предусматривается возможность фильтрации запроса по ряду критериев.
Исполнение этого запроса происходит в три этапа. На первом этапе запрос адресуется таблице «POINTS_CAT» и по заданным координатам точки (преобразованным в формат медиатора) определяются источники, где следует искать информацию для основного запроса. На втором этапе происходит обращение с исходным запросом к каждому из найденных на первом этапе источникам. При этом для каждого источника SQL-код запроса преобразуется к виду, который данный источник способен воспринять. Преобразова-
ние запроса производится с помощью таблиц соответствия TABLE_CORR_GEO и TABLE_CORR_POINTS с использованием обратных функций преобразования координат точек F1X-1, F1Y-1, F2X-1, F2Y-1. Преобразование состоит в замене операндов SQL-выражения, написанного к медиатору на соответствующие операнды источника из таблиц соответствия. На третьем этапе медиатор получает ответы от источников и производит их обратное преобразование к структуре медиатора. После этого все ответы объединяются и выдаются пользователю. При этом ответы могут дополняться информацией о своём источнике.
Источники категории «В» требуют отдельного подхода, исходящего из конкретных особенностей источника. В частности, для базы данных сбытовой организации, позволяющей связывать участок разработки с качеством добываемого угля, для получения ответа на запрос о качестве угля заданной скважины вначале придётся определять наименование соответствующего участка разработки, представленного на источнике. Для его определения потребуется дополнительная функция соответствия координат точки и названия участка.
------------------------------------------ СПИСОК ЛИТЕРАТУРЫ
1. Юмагужин Н.В. Классификация взаимосвязей в схемах данных // Программные продукты и системы. — 2007 — № 3. - С. 204-212.
2. Торшин Д.В. Организация единого интегрированного пространства на основе универсального формата обмена данными // Научно-технические ведомости СПбГПУ, серия «Информатика. Телекоммуникации. Управление». — 2009. — № 2(71). - С. 26-32.
3. ВоробьёваМ.С. Построение модели интеграции данных в информацион-но-управляющих системах // Модернизация образования в условиях глобализации: Круглый стол «Образование через науку и инновации», 14-15 сентября 2005 г. / Под ред. В. Н. Кутрунова. Тюмень: Изд-во ТюмГУ, 2005. - С. 26-28.
4. Разработка комплекса задач планирования и управления добычными работами и качеством угля на разрезе "Тугнуйский": Отчет по теме СУ-4-306 (заключительный) "Разработка комплекса задач планирования и управления добычными работами и качеством угля на разрезе "Тугнуйский" / С.С. Резниченко, М.П.Подольский, С.Д.Коробов, А.М.Валуев, И.А.Позанова; руководитель С.С. Резниченко. — М.: МГИ, 1993. — 54 л.
5. Коннолли Т., Бегг К., Страчан А. Базы данных: проектирование, реализация и сопровождение. Теория и практика, 2-е изд. - М.: Издательский дом «Вильямс», 2000. - 1120 с.
6. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. - М.: Издательский дом «Вильямс», 2003. - 1088 с. шгЛ
— Коротко об авторах
Валуев АМ — профессор кафедры Организации и управления в горной промышленности, доктор физико-математических наук, e-mail — amva-luev@online.ru, Московский государственный горный университет, Moscow State Mining University, Russia, ud@msmu.ru Панкратов А.С. - кандидат физико-математических наук, доцент кафедры информационных технологий Российского университета дружбы народов, E-mail: sasha.pankratov@gmail.com.
