Тема 4 Базы данных ГиЗИС

Общее понятие. Стадии проектирования. Проектирование географических баз данных (БД). Классификация баз данных ГИС. Представление пространственных данных в БД и цифровой карте. Системы управления БД ГИС (СУБД ГИС). Содержание и классификация системы управления базой данных

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

База данных ГИС включает графические и атрибутивные дан­ные, которые могут храниться вместе или отдельно.

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

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

Концептуальное проектирование

• определение конечной цели использования ГИС

• уровень и детальность базы данных (масштаб, классификации)

• пространственные элементы

• непространственные элементы

• определение источников пространственных и непространственных данных

• возраст и иные временные характеристики данных

• территория, которую должны покрыть данные

• информационная изученность территории

• стандартные точки (тики) для пространственного совмещения данных

• проблемная область непространственных данных, определяющая их особенности

Логическое проектирование

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

• проект пространственной "нарезки" листов карт

• составление словаря непространственных данных

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

• редактирование пространственных и непространственых данных, их стыковка через идентификаторы

Физическое проектирование

• Размещение данных и программных средств ГИС на диске

• Физический объема базы данных

• Потребности дискового пространства

• Скорость доступа к файловым структурам

Базы данных делят на иерархические, сетевые и реляционные.

Иерархические базы данных устанавливают строгую подчинен­ность между записями и состоят из упорядоченного набора деревьев (из упорядоченного набора нескольких экземпляров одного типа дерева). Тип дерева состоит из одного «корневого» типа за­писи и упорядоченного набора из нуля или более типов поддере­вьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи (рис. 3.5).

Здесь Квартал является предком для Земельного участка, а Зе­мельный участок — потомком для Квартала. Земельный участок является предком для Части участка, а часть участка — потомком для Земельного участка. Между типами записи поддерживаются связи. Автоматически поддерживается целостность ссылок между предками и потомками.

Типичный представитель иерархических систем — Information Management System (IMS) фирмы IBM. Первая версия появилась в

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

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

Типичный представитель сетевых систем — Integrated Database Management System (IDMS) компании Cullinet Software, Inc., предназначенная для использования на машинах основного клас­са фирмы IBM под управлением большинства операционных сис­тем. Архитектура системы основана на предложениях Data Base Task Group (DBTG) Комитета по языкам программирования Conference on Data Systems Languages (CODASYL).

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

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

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

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

Все значения, содержащиеся в одном и том же столбце, явля­ются данными одного типа. Например, в столбце «Районный центр» содержатся только слова, в столбце «Площадь» содержатся десятичные числа, а в столбце «ID» — целые числа, представляю­щие коды объектов, установленные пользователем. Связь между таблицами осуществляется по полям.

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

Понятие «тип данных» в реляционной модели данных полнос­тью адекватно понятию «тип данных» в языках программирова­ния Обычно в современных реляционных БД допускается хране­ние символьных, числовых данных, битовых строк, специализи­рованных числовых данных (таких, как «деньги»), а также специ­альных «темпоральных» данных (дата, время, временной интервал) Достаточно активно развивается подход к расшире­нию возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, напри­мер системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и «деньги».

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

Схема отношения — это именованное множество пар [имя атри­бута имя домена (или типа, если понятие «домен» не поддерживаетсян Степень, или «арность», схемы отношения — мощность этого множества. Степень отношения СОТРУДНИКИ равна че­тырем т е оно является 4-арным. Если все атрибуты одного отно­шения определены на разных доменах, следует использовать для именования атрибутов имена соответствующих доменов (не забы­вая конечно, о том, что это является всего лишь удобным спосо­бом именования и не устраняет различия между понятиями «до­мен» и «атрибут»).

Схема базы данных (в структурном смысле) - это набор имено­ванных схем отношений.

Кортеж соответствующий данной схеме отношения, — это множество пар (имя атрибута, значение), которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отно­шения «Значение» является допустимым значением домена дан­ного атрибута (или типа данных, если понятие «домен» не поддер­живается) Тем самым степень, или «арность», кортежа, т. е. число элементов в нем, совпадает с «арностью» соответствующей схемы

отношения. Попросту говоря, кортеж — это набор именованных значений заданного типа.

Отношение — это множество кортежей, соответствующих од­ной схеме отношения. Иногда, чтобы не путаться, говорят «отно­шение-схема» и «отношение-экземпляр», иногда схему отноше­ния называют заголовком отношения, а отношение как набор кортежей — телом отношения. На самом деле понятие «схема от­ношения» ближе всего к понятию «структурный тип данных» в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколь­ко отношений с данной схемой.

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

Обычным представлением отношения является таблица, заго­ловком которой служит схема отношения, а строками — кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят «столбец табли­цы», имея в виду «атрибут отношения». Реляционная база дан­ных — это набор отношений, имена которых совпадают с именами схем отношений в схеме БД.

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

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

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

При этом:

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

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

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

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

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

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

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

В простых программных средствах ГИС отсутствуют специфи­ческие средства организации хранения, доступа к данным и маниг-пулирования или эти функции реализуются средствами операци­онной системы в рамках ее файловой организации.

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

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

Широкое применение при разработке программного обеспечения ГИС получили реляционные СУБД.

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

К общим характеристи­кам ранних систем можно отнести следующие:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Среди реляционных СУБД Informix-OnLine 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, сотр. Borland

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

· архитектуру взаимодействия клиент/сер­вер;

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

· уровень поддержки распределенных БД.

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

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

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

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

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

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

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

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

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

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

картографические.

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

К числу функций СУБД принято относить:

1. управление данны­ми во внешней памяти;

2. управление буферами оперативной памя­ти;

3. управление транзакциями;

4. ведение журнала изменений дан­ных;

5. поддержка языков базы данных (рис. 3.9).

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

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

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

o набор утилит

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

Можно выделить такие компоненты ядра, как

· менеджер данных,

· менеджер буферов,

· менеджер транзакций и

· менеджер журнала.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

При выборе СУБД руководствуются следующими требовани­ями:

возможность оперировать данными разного типа;

наличие языка запросов высокого уровня;

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

наличие возможностей работы в сетях;

наличие возможности обработки больших объемов информа­ции;

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

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