Кузнецов О.Л., Никитин А.А., Черемисина Е.Н. Геоинформатика и геоинформационные системы

Подождите немного. Документ загружается.

двумя символами для года завершения работ и тремя (или более)

символами для регистрационного номера файлов в базе данных на

год завершения работ. Например, Р48 92 005 содержит результаты

работ, завершенных в 1992г. в пределах листа Р – 48 с номером фай-

ла исходных данных 005. Информация о каждом файле региональной

базы (масштаб работ, вид сети наблюдений, координаты, «ключи»

для перехода от относительных координат в записях файла к истин-

ным координатам, дискрипторы, характеризующие содержание фай-

ла и т.д.) помещаются в поисковый образ файла. Поисковые образы

всех файлов РФБД объединяют в один файл поисковых образов, хра-

нимых при поиске данных на диске. Сами файлы региональных ФБД

хранятся на лентах или дисках. В настоящее время на территории

Российской Федерации организовано 12 региональных вычислитель-

ных центров для хранения геоинформации по листам миллионного

масштаба. Эти центры более или менее равномерно распределены по

территории России и созданы в городах: Владивосток, Хабаровск,

Иркутск, Якутск, Красноярск, Новосибирск, Тюмень, Екатеринбург,

Саратов, Ростов-на-Дону, Москва, С – Петербург. Региональные или

архивные ФБД используются для создания локальных целевых ФБД;

– временная целевая БД предназначена для обобщения и комплексной

интерпретации геолого-геофизических материалов в пределах кон-

кретной территории с целью решения задачи прогноза того или тех

видов минерального сырья, экологических проблем и т.д. Для созда-

ния временной целевой базы данных пользователь (геолог, геохимик,

геофизик) формирует запрос, указывая привязку требуемых данных

по месту (миллионный лист, граничные координаты, площадей),

времени (временной интервал проведения работ, данные которых

представляют интерес для решения конкретной задачи), детальности

работ и их содержанию. Программное обеспечение региональных

ФБД с помощью файлов поисковых образов позволяет установить, в

каких файлах и на каких лентах (дисках) находится требуемая ин-

формация и, следовательно, извлечь эту информацию, сформировать

на её основе временную целевую ФБД;

– постоянно действующие целевые ФБД создаются по месторожде-

ниям определенного типа, по отдельным скважинам (в том числе

сверхглубоким), отдельным локальным структурам. Такие базы дан-

ных обычно отличаются спецификой решаемых задач, например,

контроль за эксплуатацией нефтегазовой залежи. Формы взаимодей-

ствия этих целевых ФБД с региональными ФБД могут быть самые

разные.

Приведенные выше типы баз данных и их взаимодействие между со-

бой можно представить в виде схемы, приведенной на рис. 3.2.

Рис. . Схема взаимодействия баз

геолого-геофизических данных

3.2

3.5. Распределенные базы данных и хранилища данных

В достаточно простом понимании термин «распределенная база

данных» (РБД) обозначает конфигурацию баз данных, которая объединяет

базы данных в одной компьютерной системе и осуществляет в различные

моменты времени доступ к данным нескольких различных удаленных баз

данных. Эта конфигурация должна обеспечивать для всех приложений дос-

туп к любым данным, независимо от их местоположения и формата.

Область распределенных баз данных расширяется обычно и на сис-

темы управления распределенной информацией. Таким образом, распреде-

ленная база данных – это совокупность логически взаимосвязанных баз

данных, распределенных в компьютерной сети, а система управления рас-

пределенной базой данных (РСУ БД)) – это программная система, обеспе-

чивающая управление распределенной базой данных и прозрачность её рас-

пределенности для пользователей.

Основными характеристиками РБД и РСУБД являются [33]:

– локальная автономность, т.е. локальные данные содержащиеся в

любой БД находятся под локальным управлением;

– непрерывность функционирования, состоящая в том, что система не

прерывается в случае добавления нового узла (новой БД) или удале-

ния данных, изменения определения данных и даже при переходе к

новой версии СУБД в отдельной БД;

– независимость от местоположения, т.е. пользователи не обязаны

знать о том, где физически расположены данные;

– распределенная обработка запросов, т.е. обработка любых запросов

осуществляется распределенным образом;

– независимость от оборудования, означающая, что одно и то же

программное обеспечение выполняется на различных компьютерах в

РСУБД;

– независимость от операционных систем;

– независимость от сети, т.е. разные БД могут быть связаны между

собой путем разных сетевых и коммуникационных средств;

– независимость от СУБД, т.е. локальные СУБД должны иметь воз-

можность участвовать в функционировании РСУБД.

Однако не все РСУБД обладают перечисленными характеристиками.

Однако каждая РСУБД должна обеспечить удаленный запрос и на удален-

ном узле выполненные группы запросов. При этом каждый запрос относит-

ся только к одному узлу, но запросы, составляющие распределенную еди-

ницу работы (так называемую транзакцию) могут выполняться совместно на

нескольких узлах. Кроме того, каждая РСУБД должна обеспечивать распре-

деленный запрос, т.е. выполнение запросов, охватывающих множество баз

данных на разных узлах (ЭВМ).

Выделяются следующие модели распределенных баз данных:

– однородные распределенные системы, имеющие в основе один про-

дукт СУБД и обычно с единственным языком, например SQL с рас-

ширениями для управления распределенными данными;

– неоднородные распределенные системы баз данных, которые вклю-

чают две или более существенно различающиеся между собой СУБД,

например, использующие различные структуры (модели) баз данных

(реляционные и иерархические).

Построение РБД осуществляется как «сверху вниз», так и «снизу

вверх». Первый подход аналогичен построению обычных БД, но объекты

РБД не сосредоточены в одном узле, а распределяются по нескольким вы-

числительным системам путем фрагментации или тиражирования.

Фрагментация означает декомпозицию объектов БД, например, ре-

ляционные таблицы, разбитые на две или более частей, размещают на раз-

ных компьютерах. Разбиение на фрагменты осуществляется либо по геогра-

фическому, либо по другому (допустим по физическим полям) признаку.

Тиражирование означает создание дубликатов данных, для которых

реализуется множество различных физических копий объектов базы данных

(обычно это таблицы) и поддерживается их идентичность с некоторой

«главной» копией.

Построение РБД «сверху вниз» применятся к однородным РБД, для

которых вначале определяется глобальная схема, а затем производится рас-

пределение объектов базы данных.

При построении РБД «снизу вверх» проводится объединение уже

существующих баз данных так, чтобы иметь доступ как к новым, так и

прежним (старым) ресурсам данных.

При использовании больших и очень больших баз данных актуаль-

ным является реализация параллельных систем баз данных. Такие системы

обеспечивают разделение вычислительных задач на большое количество па-

раллельно выполняемых операций. Подобные задачи возникают, например,

при фильтрации сейсмической информации, при решении прямых задач

ядерной геофизики методом Монте-Карло. Параллельные вычисления вы-

полняются на разных процессорах. Однако, во многих языках, например в

Коболе, отсутствуют средства распараллеливания. Реализация параллель-

ных систем баз данных осуществляется на основе реляционных баз данных

терабайтного объема.

С распределенными базами данных непосредственно связано понятие

о хранилище данных.

Хранилище данных – логически интегрированный источник данных

для систем поддержки принятия решений и для информационных систем

руководителя.

Заметим, что хранилище данных – это не то же самое, что БД, хотя

оно обычно реализуется на основе некоторой СУБД или распределенной

СУБД.

Основным предназначением хранилища данных является информа-

ционная поддержка принятия решений, а не каждодневный деятельности

той или организации, или того или иного вычислительного центра.

Обычно хранилище данных ориентировано на определенную пред-

метную область и организуется на основе некоторого подмножества данных

операционной БД. Источником данных для хранилища являются различные

приложения. Так, для Министерства природных ресурсов РФ – это леса,

водные и минеральные ресурсы, которые чаще всего реализуются на разных

платформах и для них необходимы средства интеграции.

Такие данные агрегированы в различной степени и не представляют-

ся в виде отдельных экземпляров записей, как в обычной операционной БД.

Наиболее полезным использование хранилищ является в тех областях, кото-

рые связаны с управлением долговременно хранимой информации, напри-

мер, таких, как цифровые библиотеки, в частности, геологические фонды.

В целом хранилище данных обеспечивает основу для создания сис-

тем поддержки принятия решений и информационной системы руководите-

ля.

Выделяются четыре принципа организации хранилища данных:

– предметная организация, при которой в информационной системе

поддерживается несколько предметных областей: лес, вода, мине-

ральные ресурсы, причем минеральные ресурсы могут быть также

представлены различными областями (типами месторождений): уг-

леводороды, рудные и нерудные полезные ископаемые.

– возможность интеграции данных из различных предметных облас-

тей, хранимых на разных носителях информации;

– -неизменчивость данных, состоящая в том, что в хранилище данных

не поддерживаются для традиционных БД операций обновления дан-

ных, а реализуется «массовая загрузка» данных;

– -изменения во времени, отражающие то обстоятельство, что время –

ключевой момент как создания БД, так и её содержанияе.

3.6. Примеры построения баз данных

Проведем основные рассуждения при построении БД вначале для ги-

потетичного, но весьма характерного при геолого – геофизических исследо-

ваниях примера, а затем подробно рассмотрим содержание БД и СУБД для

системы КОСКАД.

Для гипотетического примера выберем смешанный тип построения

БД, которая обычно имеет все элементы перечисленных выше моделей, т. е.

БД несет в себе элементы иерархической, реляционной и файловых струк-

тур.

Такой тип структурирования данных получил широкое распростра

нение благодаря внедрению персональных компьютеров, а также в связи с

развитием информационных технологий, в частности, WEB – технологий.

В качестве языка описания БД выберем язык HTML в версии 3.2, ко-

торый будет понят и правильно интерпретирован, независимо от компью-

терной платформы (HMTL – Hyper Text Markup Language – гипертекстовый

язык меток, т.е.формат. Язык разметки, позволяющий описать структуру

документа – страницы WWW). Страница содержит собственный содержа-

тельный текст и информацию для броузера: описание вида документа или

ссылки на WWW страницы, серверы.

Основной HTML послужил язык SGML (Standard Generalized Markup

Languge – стандартный обобщенный язык разметки, принятый Междуна-

родной Организацией Стандартов (МОС) – ISO – (International Standard Or-

ganization), в качестве стандарта ISO – 8879 в 1986г. Просмотр информации

в формате HTML проводится с помощью программ – броузеров. Имеются

многочисленные программы, предоставляющие доступ к информации в ба-

зах данных и её преобразование в файлы HTML.

Для просмотра содержания БД необходимо наличие персонального

компьютера под управлением операционной системы, например, Microsoft

Windows, а также Linux. Далее следует использовать Web – броузер (специ-

альная программа-обозреватель, которая интерпретирует и отображает

HTML-дескрипторы на экране дисплея). Например, Web – броузер Internet

Explorer 5.0 интегрирован в операционную систему Windows 98.

Общую структуру БД можно представить таким образом (см. рис. 3.3).

На компьютере запускается программа – броузер и на экране появля-

ется изображение:

выберите интересующий Вас регион:

1. г. Москва и Московская область;

2. г. Санкт-Петербург;

3. г. Саратов.

Перечисление регионов, в

которых проводились

работы

Г. С анкт -

Петербург

Г. Москва и

Московская

область

Г. Саратов

Перечисление

конкретных

территорий и

участков

работ

Перечисление

конкретных

территорий и

участков

работ

Перечисление

конкретных

территорий и

участков

работ

Различные

данные

Различные

данные

Различные

данные

Рис.3.3.Структура базы данных.

Пользователю предлагается выбрать конкретно интересующий его

регион, например, Москва, нажав на ссылку, при этом пользователь попада-

ет на второй иерархический уровень и выбирается участок для более де-

тального просмотра. Таким образом, можно дойти до самого нижнего уров-

ня, «спускаясь» по иерархическому дереву до конкретных цифровых дан-

ных, отображенных как графически, так и в виде файла.

Например, самый нижний уровень участка «Крылатское» (или «Бу-

тово» и т. д.) – профиль с данными по магниторазведке.

Следующий пример относится к организации БД и СУБД для компь-

ютерной системы КОСКАД-3D.

Эта система функционирует с БД, предназначенной для хранения

пространственной количественной геолого-геофизической информации. Как

исходная, так и результирующая информация организована в трехмерные

регулярные сети, которые являются основным структурным элементом БД.

Каждая трехмерная сеть в базе данных характеризуется количеством пике-

тов на профиле N, числом профилей M, количеством отсчетов (слоев) NS (в

качестве слоев могут быть представлены данные, измеренные на разных вы-

сотах или глубинах), расстоянием между отсчетами t ms, количеством циф-

ровых признаков в каждой точке сети Кр и координат X

, Y

, Z

нижнего уг-

ла сети. При этом число пикетов, профилей и слоев сети ограничивается

лишь ресурсами конкретной ЭВМ. На рис. 3.4 показано направление осей,

принятой в программном комплексе, правосторонней декартовой системы

координат. Отдельная точка сети может быть описана вектором геолого-

геофизических цифровых признаков, максимальная размерность которого

ограничивается 256-ю признаками.

Рис.3.4. База данных системы КОСКАД-3D.

Файловая база данных системы КОСКАД-3D построена таким обра-

зом, чтобы минимизировать среднее время доступа к данным вычислитель-

ных и сервисных процедур. При этом обеспечивается быстрый доступ к ин-

формации, относящейся к конкретному профилю или времени, за счет уве-

личения времени доступа к информации на одноименных пикетах разных

профилей или слоев сети, что позволяет оптимизировать процесс доступа к

информации для большинства функциональных процедур программного

комплекса. Из тех же соображений (уменьшения среднестатистического

времени доступа к информации) структура базы данных обеспечивает очень

быстрый доступ к отдельному признаку сети, за счет увеличения времени

доступа к вектору признаков в отдельной точке сети.

Ориентация обрабатывающих процедур комплекса на анализ данных,

организованных в трехмерные сети не исключает, как частный случай, эф-

фективной обработки информации, организованной в двумерные и одно-

мерные сети.

Файловая БД системы КОСКАД-3D включает:

– общесистемный файл OPS. MGA, содержащий информацию об ос-

новных характеристиках системы;

– описательный файл OPF. MGA, содержащий информацию о пара-

метрах сети;

– файлы AnAm.MGA, непосредственно содержащие содержательную

информацию по каждой сети в базе данных (nm- двузначный поряд-

ковый номер сети в базе данных).

Структура общесистемного файла OPS.MGA представлена в таблице 7.

Таблица 7.

Идентификатор

параметра

Длина поля в битах Описание параметра

Dim 4

Размерность данных в

базе

данных Dim=2-2D,

Dim=3-3D.

Mdl 4

Максимальная длина

файла в базе данных