2. Технология обработки и хранения информации.

Геоинформационные системы

Основной процедурой в информационном процессе является обработка информации. Она объединяет целый комплекс работ и рассматриватся как интегрирующая в базовых технологиях с прикладным программным продуктом общего прользования типа Microsoft Офис -2007, -2010. В настоящее время не менее важными и широко распространенными рассмативаются информационные технологии хранения. Хранение и накопление информации являются одними из основных дейст­вий, осуществляемых над информацией и главным средством обес­печения ее доступности в течение определенного промежутка времени. Хранимые данные не зависят от программ пользователей, для модификации и внесения изменений данных применяется общий управляющий метод.

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

База данных (БД) - совокупность взаимо­связанных данных на основе системы управления базами данных (СУБД).

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

Рис. 2.23 Основные процедуры обработки данных

Хранилище данных (ХД) — (используют термины Data Warehouse, «склад данных», «информационное хранилище») — это предметно-интегрированная, автоматизированная система накопления и хранения данных, агрегированных по многим измерениям. Основные отличия ХД от БД и БнД: агрегирование данных (вычисление различных показателей); пополнение ХД происходит на периодиче­ской основе в приведении данных к одному моменту времени; формирование новых агрегатов данных в едином формате; доступ к ХД осуществляется на основе многомерного куба или гиперкуба.

Витрины данных — множество тематических БД, содержащих информацию, относящуюся к отдельным инфор­мационным аспектам предметной области. Альтернативой хранилищу данных является концепция витрин данных (Data Mart) (рис.2.25).

Еще одним важным направлением развития баз данных являются репозитарии. Репозитарий, в упрощенном виде, можно рассматривать просто как базу данных, предназначенную для хране­ния не пользовательских, a системных данных. По отношению к пользователям применяют трехуровневое представление для описания предметной области: концептуальное, логическое и внутреннее (физическое)

Концептуальный уровень связан с частным представлением дан­ных группы пользователей в виде внешней схемы, объединяемых общностью используемой информации.

Рис. 2.24. Основные компоненты банка данных

На рис. 2.26 представлен фрагмент базы данных «Сбыт» и одно из возможных его концептуальных представлений, которое отража­ет не только объекты и их свойства, но и взаимосвязи между ними.

Логический уровень является обобщенным представлением данных всех пользователей в абстрактной форме. Используются три вида моделей: иерархическая, сетевые и реляционные. Сетевая модель является моделью объектов-связей, допускаю­щей только бинарные связи «многие к одному» и использует для описания модель ориентированных графов. Иерархическая модель является разновидностью сетевой, являю­щейся совокупностью деревьев. Реляционная модель использует представление данных в виде таблиц (реляций), в ее основе лежит математическое понятие теоретико-множественного отношения, она базируется на реляционной алгебре и теории отношений

Физический (внутренний) уровень связан со способом фактического хранения данных в запоминающих устройствах ЭВМ. Во многом определяется конкретным методом управления. Основными компонентами физического уровня являются хранимые записи, объединяемые в блоки; указатели, необходимые для поиска данных; данные переполнения; промежутки между блоками; служебная информация.

По наиболее характерным признакам БД можно классифици­ровать следующим образом:

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

по характеру использования данных: прикладные и предметные.

Рис.2.25. Принцип построения хранилища данных

Рис. 2.26. Фрагмент базы данных «Сбыт» и одно из его возможных концептуальных представлений

Рис. 2.27. Представление базы данных «Сбыт» на логическом уровне для различных моделей (Инфологическая модель)

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

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

Важным аспектом при проектирования БД является проблема интеграции и распределения данных. Господствовавшая до недавнего времени концепция интеграции данных при резком увеличении их объема, оказалась несостоятельной. Этот факт, а также увеличение объемов памяти внешних запоминающих устройств при их удешевлении, широкое внедрение сетей передачи данных способствовало внедрению распределенных БД. Распределение данных по месту их использования может осуществляться различными способами:

1. Копируемые данные. Одинаковые копии данных хранятся в различных местах использования, так как это дешевле передачи данных. Модификация данных контролируется централизованно;

2. Подмножество данных. Группы данных, совместимые с исходной базой данных, хранятся отдельно для местной обработки;

3. Реорганизованные данные. Данные в системе интегрируются при передаче на более высокий уровень;

4. Секционированные данные. На различных объектах используются одинаковые структуры, но хранятся разные данные;

5. Данные с отдельной подсхемой. На различных объектах используются различные структуры данных, объединяемые в интегрированную систему;

6. Несовместимые данные. Независимые базы данных, спроекти­рованные без координации, требующие объединения.

Важное влияние на процесс создания БД оказывает внутреннее содержание информации. Существует два направления:

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

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

Для работы с БД используется специальный обобщенный инструментарий в виде СУБД (МБД), предназначенный для управления БД и обеспечения интерфейса пользователя. Основные стандарты СУБД:

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

- универсальность (по отношению к концептуальному и логическому уровням, типу ЭВМ);

- совместимость, неизбыточность;

- безопасность и целостность данных;

- актуальность и управляемость.

Существуют два основных направления реализации СУБД: программное и аппаратное.

Программная реализация СУБД представляет собой набор программных модулей, работает под управлением конкретной ОС и выполняет следующие функции: описание данных на концептуальном и логическом уровнях; загрузку данных; хранение данных; поиск и ответ на запрос (транзакцию); внесение изменений; обеспечение безопасности и целостности.

Обеспечивает пользователя следующими языковыми средсвами: языком описания данных (ЯОД); языком манипулирования данными (ЯМД); прикладным (встроенным) языком данных (ПЯД, ВЯД).

Аппаратная реализация предусматривает использование так называемых машин баз данных. Их появление вызвано возросшими объемами информации и требованиями к скорости доступа. Термин «компьютер БД» — автономный процессор баз данных или процессор, поддерживающий СУБД. Основные направления МБД: параллельная обработка; распределенная логика; ассоциативные ЗУ; конвейерные ЗУ; фильтры данных и др.

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

Системы управления базами данных (СУБД, DBMS – Database Management System) на протяжении всего пути развития компьютерной техники совершенствовались, поддерживая все более сложные уровни абстрактных данных, заданных пользователем, и обеспечивая взаимодействие компонентов, распределенных в глобальных сетях и постепенно интегрирующихся с телекоммуникационными системами. В настоящее время успешно развиваются два типа СУБД. Это распределенные и параллельные.

Распределенная база данных (DDB - distributed database рис.2.28) - это совокупность множества взаимосвязанных баз данных, распределенных в телекоммуникационной сети. Система управления распределенной базой данных определяется как программная система, которая позволяет управлять базой данных таким образом, чтобы ее распределенность была прозрачна для пользователей. В этом определении следует уточнить два отличительных условия. Первое заключается в том, что система состоит из (возможно, пустого) множества узлов приема запросов (query site) и непустого множества узлов данных (data site). Узлы данных обладают средствами для хранения данных, а узлы приема запросов - нет; на них лишь выполняются программы, реализующие пользовательский интерфейс для доступа к данным, хранящимся в узлах данных. Второе условие заключается в том, что узлы логически представляют собой независимые компьютеры, на которых установлены собственные операционные системы (может быть, одинаковые на всех узлах, а возможно, и разные) и могут выполняться независимые приложения. Т. е. узлы - это компьютеры, связанные сетью, а не процессоры, составляющие многопроцессорную конфигурацию. Важнейший отличительный признак - слабосвязанный характер среды, где каждый узел имеет собственную операционную систему и функционирует независимо.

Рис.2.28. Распределенная база данных в АИУС РСЧС.

Если снять упомянутые выше отличительные условия в определении распределенной СУБД, то мы получим определение системы параллельных баз данных. Не существует четкого разграничения между параллельными и распределенными СУБД. В частности, архитектуры параллельных СУБД без разделяемых ресурсов, которые обсуждаются ниже, схожи со слабосвязанными распределенными системами. Параллельные СУБД реализуют преимущества новейших многопроцессорных архитектур и служат основой высокопроизводительных серверов баз данных высокой доступности, стоимость которых значительно ниже эквивалентных систем на мэйнфреймах. Параллельную СУБД можно определить как реализацию СУБД для многопроцессорного компьютера.

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

1. Распределенная/параллельная база данных - это именно база данных, а не "коллекция" файлов, индивидуально хранимых на разных узлах сети. В этом заключается разница между DDB и распределенной файловой системой. Распределенные данные представляют собой DDB, только если они связаны в соответствии с некоторым структурным формализмом (таким как реляционная модель), а для доступа к ним имеется единый высокоуровневый интерфейс.

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

3. Распределение (включая фрагментацию и репликацию) данных по множеству узлов невидимо для пользователей. Это свойство называется прозрачностью. Технология распределенных/параллельных баз данных распространяет основополагающую для управления базами данных концепцию независимости данных на среду, где данные распределены и тиражированы по множеству компьютеров, связанных сетью. Это обеспечивается за счет нескольких видов прозрачности: прозрачность сети (следовательно, прозрачность распределения), прозрачность репликации и прозрачность фрагментации. Прозрачность доступа означает, что пользователи имеют дело с единым логическим образом базы данных и осуществляют доступ к распределенным данным точно так же, как если бы они хранились централизованно. В идеале полная прозрачность подразумевает наличие языка запросов к распределенной СУБД, не отличающегося от языка для централизованной СУБД.

Технологии распределенных и параллельных СУБД направлены также на повышение надежности, поскольку благодаря репликациям данных исключаются одиночные точки отказа. Отказ одного узла или сбой на линии связи не приводит к выходу из строя всей системы. Даже если часть данных становится недоступной, при правильной организации системы пользователи могут иметь доступ к остальной части информации. Под "правильной организацией" понимается поддержка распределенных транзакций и протоколов обеспечения надежности (т. е. протоколов фиксации и восстановления).

В среде параллельных и распределенных СУБД упрощается решение вопросов, связанных с возрастанием объема баз данных или потребностей обработки. При этом редко возникает необходимость в серьезной перестройке системы; расширение возможностей обычно достигается за счет добавления процессорных мощностей или памяти.

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

С учетом соотношения эффективность/стоимость для микропроцессоров и рабочих станций экономически выгоднее оказывается составить систему из нескольких небольших компьютеров, чем реализовать ее на эквивалентной по мощности одной большой машине. Множество коммерческих распределенных СУБД функционируют на мини-компьютерах и рабочих станциях именно по причине более выгодного соотношения эффективность/стоимость. Технологии, основанные на применении рабочих станций, получили столь широкое распространение благодаря тому, что большинство коммерческих СУБД способны работать в рамках локальных сетей, где в основном и используются рабочие станции. Развитие распределенных СУБД, предназначенных для глобальных сетей WAN, может привести к повышению роли мэйнфреймов. С другой стороны, распределенные СУБД будущих поколений, скорее всего, будут поддерживать иерархические сетевые структуры, состоящие из кластеров, в пределах которых компьютеры взаимодействуют на базе локальной сети, а сами кластеры соединяются между собой посредством высокоскоростных магистралей.

Серверы баз данных как базовая системная поддержка информационной системы в технологии "клиент-сервер" следует рассматривать как основу процессов хранения информации. Сам термин "сервер баз данных" обычно используют для обозначения всей СУБД, которая включает и серверную, и клиентскую части. Такие системы предназначены для хранения и обеспечения доступа к базам данных.

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

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

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

Общим решением проблемы мобильности систем, основанных на технологии "клиент-сервер" является опора на программные пакеты, реализующие протоколы удаленного вызова процедур (RPC - Remote Procedure Call). При использовании таких средств обращение к сервису в удаленном узле выглядит как обычный вызов процедуры. Средства RPC, в которых, естественно, содержится вся информация о специфике аппаратуры сети и сетевых протоколов, переводит вызов в последовательность сетевых взаимодействий. Тем самым, специфика сетевой среды и протоколов скрыта от прикладного программиста. Если система реализована на основе стандартного пакета RPC, она может быть легко перенесена в любую открытую среду.

Технология “клиент-сервер” применительно к СУБД сводится к разделению системы на две части приложение-клиент (front-end) и сервер базы данных (back-end). Эта технология совмещает лучшие черты обработки данных на мэйнфреймах и технологии “файл-сервер”. От мэйнфреймов технология “клиент-сервер” позаимствовала такие черты, как централизованное администрирование, безопасность, надежность. От технологии “файл-сервер” унаследованы низкая стоимость и возможность распределенной обработки данных, используя ресурсы компьютеров-клиентов. Сейчас графический интерфейс пользователя стал стандартом для систем “клиент-сервер”. Кроме того, технология “клиент-сервер” значительно упрощает и ускоряет разработку приложений за счет того, что правила проверки целостности данных находятся на сервере. Неправильно работающее кли­ентское приложение не может привести к потере или искаже­нию данных. Все эти возможности, ранее свойственные только сложным и дорогостоящим системам, сейчас доступны даже небольшим организациям. Стоимость оборудования, про­граммного обеспечения и обслуживания для персональных компьютеров в десятки раз ниже, чем для мэйнфреймов. Особенности обработки данных в различных технологиях по­казаны на рис.2.29. Локальный компьютер, невключенный в сеть, имеет в памяти следующие программные продукты: СУБД, данные и локальные приложения (а).

Локальные приложения,

СУБД и данные

а)

Данные

б)

в)

Рис. 2.29. Обработка и хранение информации в локальной БД (а) и на основе технологии «файл-сервер» (б) и «клиент-сепрвер» (в)

Технология «файл-сервер» - имеет на сервере данные, а у клиента – сетевое приложение и данные (б). Технология «клиент-сервер» у клиента имеет клиентское приложение, а у сервера БД – СУБД и данные (в).

Принципы взаимодействия между клиентскими и серверными частями заключаются в следующем. Доступ к базе данных от прикладной программы или пользователя производится путем обращения к клиентской части системы. В качестве основного интерфейса между клиентской и серверной частями выступает язык баз данных SQL. Это язык по сути дела представляет собой текущий стандарт интерфейса СУБД в открытых системах. Собирательное название SQL-сервер относится ко всем серверам баз данных, основанных на SQL. Серверы баз данных, интерфейс которых основан исключительно на языке SQL, обладают преимуществами и недостатками. Очевидное преимущество – стандартность интерфейса. В пределе, хотя пока это не совсем так, клиентские части любой SQL-ориентированной СУБД могли бы работать с любым SQL-сервером вне зависимости от того, кто его произвел.

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

Одним из перспективных направлений СУБД является гибкое конфигурирование системы, при котором распределение функций между клиентской и пользовательской частями СУБД определяется при установке системы.

Преимущества протоколов удаленного вызова процедур особенно важны в системах управления базами данных, основанных на технологии "клиент-сервер". Это объесняется во-первых, тем, что использование механизма удаленных процедур позволяет действительно перераспределять функции между клиентской и серверной частями системы, поскольку в тексте программы удаленный вызов процедуры ничем не отличается от удаленного вызова, и следовательно, теоретически любой компонент системы может располагаться и на стороне сервера, и на стороне клиента, а во-вторых, механизм удаленного вызова скрывает различия между взаимодействующими компьютерами. Физически неоднородная сеть компьютеров приводится к логически однородной сети взаимодействующих программных компонентов. В результате пользователи не обязаны серьезно заботиться о разовой закупке совместимых серверов и рабочих станций.

В типичном на сегодняшний день случае на стороне клиента СУБД работает только такое программное обеспечение, которое не имеет непосредственного доступа к базам данных, а обращается для этого к серверу с использованием языка SQL. В некоторых случаях хотелось бы включить в состав клиентской части системы некоторые функции для работы с "локальным кэшем" базы данных, т.е. с той ее частью, которая интенсивно используется клиентской прикладной программой. В современной технологии это можно сделать только путем формального создания на стороне клиента локальной копии сервера базы данных и рассмотрения всей системы как набора взаимодействующих серверов.

С другой стороны, иногда хотелось бы перенести большую часть прикладной системы на сторону сервера, если разница в мощности клиентских рабочих станций и сервера чересчур велика. В общем-то при использовании RPC это сделать нетрудно. Но требуется, чтобы базовое программное обеспечение сервера действительно позволяло это. В частности, при использовании ОС UNIX проблемы практически не возникают.

Основная часть любой системы “клиент-сервер” – это сервер БД. Со времени возникновения технологии “клиент-сервер” появилось много вариантов архитектуры процессора БД, поскольку он во многом определяет успех всей системы. Основное требование к серверу БД – обеспечение минимального времени выполнения запросов при максимально возможном числе пользователей. Существуют две основные архитектуры для построения процессора БД: архитектура с несколькими процессами и многопоточная архитектура. Рассмотрим их.

Архитектура с несколькими процессами характеризуется тем, что несколько экземпляров исполняемого файла работают одновременно. Эти системы отличаются хорошей масштабируемостью, но требуют значительных расходов памяти, так как память каждому экземпляру приложения выделяется отдельно. Эта архитектура подразумевает наличие эффективного механизма взаимодействия процессов и полагается на операционную систему при разделении процессорного времени между отдельными экземплярами приложения. Самый известный пример сервера, построенного по этой архитектуре, - Oracle Server. Когда пользователь подключается к БД Oracle, он в действительности запускает отдельный экземпляр исполняемого файла процессора базы данных.

Многопоточная архитектура эта архитектура использует только один исполняемый файл, с несколькими потоками исполнения. Главное преимущество – более скромные требования к оборудованию, чем для архитектуры с несколькими процессами. Здесь сервер берет на себя разделение времени между отдельными потоками, иногда давая преимущество некоторым задачам над другими. Кроме того, отпадает необходимость в сложном механизме взаимодействия процессов. По этой архитектуре построены MS SQL Server и Sybase SQL Server.

Типовой сервер баз данных отвечает за выполнение следующих функций:

- поддержание логически согласованного набора файлов;

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

- восстановление информации после разного рода сбоев (транзакция);

- организацию реально параллельной работы нескольких пользователей сети (мультимидейность).

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

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

файлового сервера (File Server – FS);

доступа к удаленным данным (Remote Data Access – RDA);

сервера баз данных (Data Base Server – DBS);

сервера приложений (Application Server – AS).

FS-модель является базовой для локальных ТКС (рис.2.27.). Достоинством такой модели – простота. Недостаток с увелчением объема данных и пользователей резко снижается производительность.

Более технологичная RDA – модель существенно отличается от FS – модели характером компанента доступа к информацонным ресурсам. Это, как правило, SQL –сервер (рис.2.28). Подробнее о SQL-сервере см. ниже. Доступ к инфорационным ресурсам обеспечивается либо операторами специального языка типа SQL, либо вызовами функций специальной библиотеки. Эта модель лишина недостатков, имеющихся как у систем с централизованной архитектурой, так и у систем с файловой системой.

DBS - модель реализована в реляционных СУБД (Informix, Ingres, Sybase, Oracle). Ее основу составляет механизм хранимых процедур – средство программирования SQL – сервера (рис.2.30). Процедуры храняться в словаре базы данных, разделяются между собой клиентами и выполняются на том же компьютере, где функционрует SQL – сервер. Язык, на котором разрабатывются хранмые процедуры, представляет собой процедурное расширение языка запросов SQL и уникален для каждой конкретной СУБД.

Запросы к файловой системе

Рис.2.30. Модель файлового сервера

Но и она имеет недостатки, порой существенные. Это при запросах значительно загружается сеть и сложное администрирование приложений, где совмещаются различные по природе функции (представления и прикладные).

Данные

Рис.2.31. Модель доступа к удаленным данным

К недостаткам модели можно отнести ограниченность средств, используемых для написания хранимых процедур. На практике часто используются смешанные модели для обеспечения целостности данных. Современные многопользовательские СУБД опираются на RDA- и DBS- модели. При создании ИС, выбирается СУБД, ориентированой на одну из двух указанных моделей либо на их разумное сочетание.

Рис.2.32. Модель сервера баз данным

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

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

Очень важным пораметром СУБД является транзакция. Понятие транзакции имеет непосредственную связь с понятием целостности БД. Очень часто БД может обладать такими ограничениями целостности, которые просто невозможно не нарушить, выполняя только один оператор изменения БД. Поэтому для поддержания подобных ограничений целостности допускается их нарушение внутри транзакции с тем условием, чтобы к моменту завершения транзакции условия целостности были соблюдены. В системах с развитыми средствами ограничения и контроля целостности каждая транзакция начинается при целостном состоянии БД и должна оставить это состояние целостными после своего завершения. Несоблюдение этого условия приводит к тому, что вместо фиксации результатов транзакции происходит ее нарушение и БД остается в таком состоянии, в котором находилась к моменту начала транзакции, т.е. в целостном состоянии.

Рис.2.33. Модель сервера приложений

Если быть немного более точным, различаются два вида ограничений целостности: немедленно проверяемые и откладываемые. К немедленно проверяемым ограничениям целостности относятся такие ограничения, проверку которых бессмысленно или даже невозможно откладывать. Примером ограничения, проверку которого откладывать бессмысленно, являются ограничения домена (возраст сотрудника не может превышать 150 лет). Более сложным ограничением, проверку которого невозможно отложить, является следующее: зарплата сотрудника не может быть увеличена за одну операцию более, чем на 100,000 рублей. Немедленно проверяемые ограничения целостности соответствуют уровню отдельных операторов языкового уровня СУБД. При их нарушениях не производится откат транзакции, а лишь отвергается соответствующий оператор.

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

Развитие моделей транзакций важно для распределенных систем по целому ряду причин. Наиболее существенная из них заключается в том, что новые прикладные области, которые будут поддерживаться распределенными СУБД (инженерное проектирование, офисные информационные системы, кооперативная деятельность и др.), требуют транзакций, включающих более абстрактные операции над сложными типами данных. Далее, для подобных приложений характерна другая парадигма разделения данных, отличная от той, которая принята в традиционных СУБД. Например, система поддержки кооперативной деятельности предполагает, скорее, кооперацию при доступе к общим данным, чем конкуренцию. Именно этими изменяющимися требованиями вызвана необходимость разработки новых моделей транзакций и соответствующих критериев корректности.

Применительно к системам баз данных архитектура "клиент-сервер" интересна и актуальна главным образом потому, что обеспечивает простое и относительно дешевое решение проблемы коллективного доступа к базам данных в локальной сети. В некотором роде системы баз данных, основанные на архитектуре "клиент-сервер", являются приближением к распределенным системам баз данных, конечно, существенно упрощенным приближением, но зато не требующим решения основного набора проблем действительно распределенных баз данных.

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

В реляционных базах данных (Relational Database System, RDBS) все данные отображаются в двумерных таблицах. База данных, таким образом, это ни что иное, как набор таблиц. RDBS и ориентированные на записи системы организованы на основе стандарта B-Tree или методе доступа, основанном на индексации – Indexed Sequential Access Method (ISAM) и являются стандартными системами, использующимися в большинстве современных программных продуктов. Для обеспечения комбинирования таблиц и для определения связей между данными, которые практически полностью отсутствуют в большинстве программных реализаций B-Tree и ISAM, используется языки, подобные SQL (IBM), Quel (Ingres) и RDO (Digital Equipment), причем стандартом отрасли в настоящее время стал язык SQL, поддерживаемый всеми производителями реляционных СУБД.

Язык для взаимодействия с БД SQL появился в середине 70-х и был разработан в рамках проекта экспериментальной реляционной СУБД System R. Исходное название языка SEQUEL (Structered English Query Language) только частично отражает суть этого языка. Этот язык был ориентирован главным образом на удобную и понятную пользователям формулировку запросов к реляционной БД, но на самом деле уже являлся полным языком БД, содержащим помимо операторов формулирования запросов и манипулирования БД средства определения и манипулирования схемой БД; определения ограничений целостности и триггеров; представлений БД; возможности определения структур физического уровня, поддерживающих эффективное выполнение запросов; авторизации доступа к отношениям и их полям; точек сохранения транзакции и откатов.

Оригинальная версия SQL – это интерпретируемый язык, предназначенный для выполнения операций над базами данных. К этим операция в основе своей относятся запросы к БД. Поэтому язык SQL – декларативный язык. Реальные приложения обычно написаны на других языках, генерирующих код на языке SQL и передающих их в СУБД в виде текста в формате ASCII. Нужно отметить также, что практически все реальные реляционные (и не только реляционные) системы помимо реализации стандарта ANSI SQL, известного сейчас в последней редакции под именем SQL2, SQL3 включают в себя дополнительные расширения, например, поддержка архитектуры клиент-сервер или средства разработки приложений.

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

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

Решение компании Oracle в области складов данных основывается на двух факторах: широкий ассортимент продуктов самой компании и деятельность партнеров в рамках программы Warehouse Technology Initiative. Возможности Oracle в области складов данных базируются на следующих составляющих:

- наличие реляционной СУБД Oracle 7, которая постоянно совершенствуется для лучшего удовлетворения потребностей складов данных;

- существование набора готовых приложений, обеспечивающих возможности разработки склада данных;

- высокий технологический потенциал компании в области анализа данных;

- доступность ряда продуктов, производимых другими компаниями.

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

К СУБД коллективного пользования на настоящее время относятся Оracle, Informix и др. Это СУБД огромных различных информационных ресурсов, например СУБД Access позволяет в режиме «мультидоступа» обслужить до 50 пользователей одновременно, то СУБД Оracle – несколько тысяч и т.д.

Объектно-реляционные адаптеры, такие как Odapter компании Hewlett-Packard для СУБД Oracle, можно с успехом использовать во многих областях, например в качестве связующего програмного обеспечения, объединяющего объектно-ориентированные приложения с реляционными СУБД. Производительность в этих условиях зависит от способа доступа к реляционной базе данных. Каждая РСУБД состоит из двух уровней: уровня управления данными (data manager layer) и уровня управления носителем (storage manager layer).

Первый из них обрабатывает операторы на языке SQL, а второй отображает данные в базе. Шлюз или адаптер могут взаимодействовать как с уровнем данных (то есть обращаться к РСУБД при помощи SQL), так и с уровнем носителя (вызовами процедур низкого уровня). Ядро реляционной SQL –часто называют сервером базы данных, или SQL-сервер, а программу, обращающую к нему за услугами по обработке данных – SQL-клиент. Однако для решения задач МЧС РФ СУБД огромных информационных ресурсов эксплуатировать экономически не выгодно. Поэтому используются отдельные модули СУБД Оracle. Таким модулем является СУБД MS SQL-Server. Этот модуль характеризуется следующими собенностями:

Несколько совместно используемых баз данных, характеризующих различные стороны некоторой предметной области, называют системой баз данных. В качестве синонима термина «система база данных» иногда применяют термин «банк данных», однако это понятие почти вышло из употребления (см. раздел 1).

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

Основными моделями данных применяемых в МЧС России являются:

иерархическая модель;

сетевая модель;

реляционная модель.

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

Общие недостатки других рассмотренных моделей и реализованных на их основе СУБД заключаются в следующем:

чрезмерная сложность использования (в сравнении с реляционным подходом) в ходе эксплуатации;

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

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

Реляционный подход является наиболее распространенным в настоящее время, что обусловлено:

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

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

Реляционные системы далеко не сразу получили широкое распространение. В то время, как основные теоретические результаты в этой области были получены также в 70-х годах, и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако отмеченные выше преимущества и постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД. Типичным представителем настольных СУБД этого класса является СУБД Access, входящая в состав пакета программ Microsoft Office.

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

Одним из важнейших аспектов реляционного подхода стала идея отделения логической структуры данных от физического их представления. Логический уровень представления данных соответствует взгляду ни них конечного пользователя, на физическом уровне эти данные обрабатываются компьютером. Развитие этой идеи привело к разработке обобщенной структурной модели базы данных, получившей название трехуровневой базой данных (рис.2.34). Эта модель была предложена исследовательской группой Американского национального института стандартов (ANSI), поэтому ее часто называют трехуровневой моделью ANSI/SPARC.

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

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

На внутреннем уровне рассматривается представление данных в компьютерной памяти в форме последовательностей хранимых записей. При этом становятся актуальными вопросы их адресации, оптимального поиска нужной записи из множества записей и т.п. Внутренне представление предполагает бесконечное линейное адресное пространство; подробности отображения этого пространства на физические устройства хранения не включаются в трехуровневую модель, так как сильно зависят от конкретной аппаратуры.

Рис. 2.34. Модель трехровневой модели базы данных ANSI/SPARC

Кроме хранения данных технологии баз данных являются основными в создании геоинформационных систем (ГИС). В современных условиях, когда в мире существуют космические навигационные системы ГЛОНАСС и НАВСТАР картографичемкая информация на бумажной основе очень старая технология. Внедрение ГИС в приемники ГЛОНАСС во все виды транспорта и отдельным специалистам позволит значительно быстрее проводить анализ информации и опертивно примать решение (рис.2.35).

Географические информационные системы осуществляют следующие фукции: ввод информации, ее хранение, осуществление запросов и анализа хранимой информации, отображение и вывод в удобной форме. Вся информация разделена на оверлейные слои, которые объединяются по различным признакам. Собранные в единый интегральный слой они представляют географическую информации в разных методах измерения (2D или 3D) (ри.2.33).

ГИС состоит из баз данных. Основными из них являются БД координатных и атрибутных данных.(рис.2.36). Графической средой ГИС является векторные и растовые модели (рис.2.37).

Рис.2.35. Российская космически-навигационная система ГЛОНАСС

Чтобы реализовать картографическую информацию в виде базы данных ее необходимо “оцифровать”. Порядок “оцифровки” представлен на рис.2.38. Он заключается в следующем. Заданный участок карты разбивается на определенные участки и информации в виде цифр переноситься в базу данных. Это как правило отдельные точки и изолинии взятые на карте.

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

Многомасштабность информации.

Блок поиска информации (на основе SQL).

Наличие оверлейных слоев.

Блок расчетных задач по вопросам МЧС.

Рис.2.36. Оверлейность данных ГИС

Рис.2.37. Структура ГИС

Пакет инструментальных средств ГИС значительно обширный, но отечественные программы пока очень далеки от совершенства. Среди завоевавших на информационном рынке можно выделить систему “GeoDraw”, ”GeoGraph”, “ArcGIS”, “ArcCad”, “ArcView”, “ArcInfo”, “AtlasGIS для Windows”, ”WinGIS”, спецсистема “ER Mapper”, “MapInfo”, Панарама, Интеграция, Экстремум. Классификация ГИС в России соответствует их создателям: Федеральной службе Геодезии и картографии России (Роскартография). Формат FIM. Военно-топографической службе Генерального штаба Вооруженных сил России (ВТУ ГШ). Формат SXF. В рамках МЧС НИИ ГОЧС создал ГИС «Экстремум» (рис.2.38).

Эффективность внедрения представлена на графике рис.2.39. по данным отснователя американского ученого Роджера Томлинсона [ ].

Таким образом, технологии хранения информации на основе баз данных в МЧС РФ являются самыми важными и их необходимо развивать и совершенствовать.

Рис.2.38. Графические модели ГИС

Рис.2.39. Представление поверхностей регулярной сетью точек и изолиниями

Рис.2.40. Картографическая база данных ГИС «ЭКСТРЕМУМ»

Рис.2.41. Эффективность внедрения ГИС по опыту экспертов