Организация баз данных ГИС 2 страница

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

1.Эти системы активно использовали в течение многих лет, дольше, чем какую-либо из реляционных СУБД. В них накоплены большие базы данных, и поэтому одна из актуальных проблем ин­формационных систем — использование их совместно с современ­ными системами.

2. Системы не были основаны на каких-либо абстрактных мо­делях. Абстрактные представления ранних систем появились поз­же на основе анализа и выявления общих признаков у различных систем вместе с реляционным подходом.

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

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

К числу наиболее известных систем, основанных на инверти­рованных списках, относятся Datacom/DB компании Applied Data Research, Inc. (ADR), ориентированная на использование компь­ютеров основного класса фирмы IBM, и Adabas компании Software.

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

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

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

К достоинствам реляционного подхода организации СУБД можно отнести:

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

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

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

Реляционные системы не сразу получили широкое распростра­нение.

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

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

В настоящее время основными недостатками реляционных СУБД являются:

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

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

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

Высший уровень СУБД поддерживают крупные БД (сотни и тысячи Гбайт и более), обслуживающие тысячи пользователей, например ORACLE7, ADABAS 5.3.2, SQL SERVER11.

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

SQL Server 10, сотр. Sybase — продукт, поддерживающий обра­ботку в реальном времени и процессы решений. Он является СУБД одного уровня с Огас1е7, но имеет некоторые ограничения в плане масштабируемости и использует ограниченное число аппа­ратных и программных платформ.

Средний уровень СУБД поддерживают БД до нескольких сот Гбайт, обслуживают сотни пользователей. Представители: InterBase 3.3, Informix-On-Line7.0, Microsoft SQL Server 6.0.

Среди реляционных СУБД Informix-On Line 7.0, сотр. Software поддерживает такие современные технологии, как тиражирование данных, синхронизирующее распределенные БД, и большие дво­ичные объекты. Его можно применять для запуска OLTP-приложений (высокоскоростной обработки транзакций), но скорость обработки в этом случае меньше, чем у продуктов верхней части рынка. Установка возможна на ограниченном числе платформ. Имеет большие возможности для расширения.

Microsoft SQL Server 6.0, corp. Microsoft — хорошая СУБД, кото­рая интегрирована с Windows NT, дополняя ее. Недостатки: недо­статочная масштабируемость, малое число поддерживаемых про­граммных платформ.

Нижний уровень СУБД составляют системы, которые под­держивают БД до 1 Гбайта и имеют менее 100 пользователей. Ис­пользуют их, как правило, в небольших подразделениях. Предста­вители: NetWare SQL 3.0, Gupta SQL-Base Server.

Настольные СУБД предназначены для одного пользователя, ис­пользуются для ведения настольной БД или как клиент для под­ключения к серверу БД. Имеют очень ограниченные возможности по обработке данных, а также характеризуются отсутствием воз­можности установки в сети. Представители: FoxPro 2.6, corp. Microsoft, Paradox 5.0, соrр. Borland

При использовании конкретной СУБД необходимо учитывать три ключевых фактора: архитектуру взаимодействия клиент/сер­вер; способ или метод реализации основных функций; уровень поддержки распределенных БД.

Одно из главных условий, определяющих необходимость ис­пользования технологии баз данных при создании ГИС, — под­держка современными СУБД сетевых возможностей хранения и использования технологий локальных сетей (LAN) и удаленных сетей в так называемых распределенных БД. Тем самым дости­гаются оптимальное использование вычислительных ресурсов и возможность коллективного доступа пользователей к запрашива­емым БД.

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

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

1. Действия по переструктуризации данных.

2. Трансформация проекций и изменение систем координат.

3. Операции вычислительной геометрии.

4. Оверлейные операции (наложение разноименных и разно­типных слоев данных).

5. Общие аналитические, графоаналитические и моделирую­щие функции.

Результаты обработки данных должны трансформироваться в «человекочитаемый» документ. Программные средства ГИС включают достаточно широкий набор средств генерации выход­ных данных.

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

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

К числу функций СУБД принято относить: управление данны­ми во внешней памяти; управление буферами оперативной памя­ти; управление транзакциями; ведение журнала изменений дан­ных; поддержка языков базы данных (рис. 3.9).

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

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

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

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

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

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

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

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

Для восстановления БД после жесткого сбоя используют жур­нал и архивную копию БД. Архивная копия — это полная копия БД к моменту начала заполнения журнала (имеется много вариан­тов более гибкой трактовки смысла архивной копии). Для нор­мального восстановления БД после жесткого сбоя необходимо, чтобы журнал не пропал. К сохранности журнала во внешней па­мяти в СУБД предъявляются повышенные требования. Тогда вос­становление БД состоит в том, что, исходя из архивной копии, по журналу воспроизводится работа всех транзакций, которые закон­чились к моменту сбоя. В принципе можно даже воспроизвести работу незавершенных транзакций и продолжить их работу после завершения восстановления. Однако в реальных системах это обычно не делается, поскольку процесс восстановления после жест­кого сбоя достаточно длителен.

Для работы с базами данных используются специальные языки, в целом называемые языками баз данных. В ранних СУБД поддер­живалось несколько специализированных по своим функциям языков. Чаще всего выделялись два языка: язык определения схемы БД (SDL — Schema Definition Language) и язык манипулирования данными (DML — Data Manipulation Language). SDL служил глав­ным образом для определения логической структуры БД, т.е. той структуры БД, какой она предоставляется пользователям. DML содержал набор операторов манипулирования данными, т. е. опе­раторов, позволяющих заносить данные в БД, удалять, модифици­ровать или выбирать существующие данные.

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

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

содержит специальные средства определения ограничений це­лостности БД. При компиляции операторов модификации БД компилятор SQL на основании имеющихся в БД ограничений це­лостности генерирует соответствующий программный код;

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

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

В реляционной СУБД можно выделить:

ядро СУБД (часто его называют Data Base Engine);

компилятор языка БД (обычно SQL);

командный язык;

набор утилит (рис. 3.10).

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

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

Такой язык обладает следующими средствами и характеристи­ками:

средствами описания, как хранимых данных, так и операций над ними (поиск и модификация);

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

средствами защиты базы данных;

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

вычислительными функциями;

средствами форматирования экрана терминала и генераторами отсчетов.

Кроме того, он обеспечивает высокую производительность тру­да программиста.

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

создает таблицы;

выбирает и/или изменяет данные в таблицах;

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

Манипулируя системными командами, можно читать сообще­ния, посылаемые с терминала, выбирать правила, описывающие структуру необходимой части данных, отыскивать и извлекать нужные данные, применять правила обработки, обновлять нахо­дящиеся в базе элементы. С помощью команд, возможно, также со­ставлять запросы и сообщения. Типовое меню может включать в себя следующие варианты выбора: посылку или отображение со­общения, завершение сеанса работы, выбор запроса и т. п.

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

Таким образом, язык БД предоставляет в распоряжение пользователя следующие возможности:

выбирать мощные средства работы с файлами, позволяющие выбирать, модифицировать, сортировать, объединять, отыскивать данные и выполнять сложные запросы. Все пользовательские опе­рации выполняются только над выбранными данными. За счет этого независимо от действий пользователя данные в файле об­новляются лишь однократно;

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

пользоваться встроенными генераторами масок для формати­рования экранов терминала с заданием индивидуальных заголов­ков;

применять генератор отчетов, работающий по схеме, состав­ленной пользователем в диалоговом режиме;

вызывать заранее составленные последовательности команд с помощью меню.

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

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

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

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

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

Компромиссное решение проблемы — применение так называ­емых псевдокомпиляторов, которые предварительно обраба­тывают операторы исходной программы и лишь затем выполняют их в режиме интерпретации.

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

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

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

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

Дата добавления: 2015-04-29