Московский государственный университет печати

Чертовской В.Д.


         

Базы и банки данных

Учебное пособие


Чертовской В.Д.
Базы и банки данных
Начало
Печатный оригинал
Об электронном издании
Оглавление

Введение

Часть 1. ОСНОВНЫЕ ПОЛОЖЕНИЯ

Раздел 1. Основные понятия

1.

Глава 1. Общие сведения

1.1.

Данные, информация, знания

1.2.

Основные понятия и определения

1.3.

Классификация БД и СУБД

1.4.

Состав СУБД и работа БД

2.

Глава 2. Концепция баз данных

2.1.

Требования, предъявляемые к базам данных

2.2.

Концепция построения БД

2.3.

Методология проектирования баз данных

2.4.

Методология использования баз данных

Раздел 2. Теория баз данных

3.

Глава 3. Общая теория

3.1.

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

3.2.

CASE-технология

3.3.

CASE-средства

4.

Глава 4. Теория реляционных баз данных

4.1.

Математические основы теории

4.2.

Построение БД

4.3.

Использование БД

4.3.1.

Запросы к данным

4.3.2.

Синхронизация процессов доступа

Часть 2. Централизованные базы данных

Раздел 3. Реализация бд (модели БД)

5.

Глава 5. Реляционные БД SQL

5.1.

Логическая структура

5.2.

Создание БД

5.3.

Использование БД

5.3.1.

Язык SQL

5.3.2.

Язык QBE

6.

Глава 6. Сетевые БД

6.1.

Логическая структура

6.2.

Программная реализация

6.2.1.

Создание БД (ЯОД)

6.2.2.

Использование БД (ЯМД)

7.

Глава 7. Иерархические БД

7.1.

Логическая структура

7.2.

Программная реализация

7.2.1.

Создание БД (ЯОД)

7.2.2.

Использование БД (ЯМД)

8.

Глава 8. Взаимосвязь МД

8.1.

Сравнительная характеристика моделей данных

8.2.

Преобразование моделей данных

8.3.

Выбор моделей данных

9.

Глава 9. Физическая БД

9.1.

Вопросы программной реализации БД

9.2.

Организация хранения и доступ

9.3.

Доступ к данным и их обновление

Раздел 4. Современные направления развития БД

10.

Глава 10. Автоматизация проектирования

10.1.

Классический подход к проектированию

10.1.1.

Однопользовательский режим

10.1.2.

Многопользовательский режим

10.2.

Современный подход к проектированию

10.3.

Автоматизация проектирования

11.

Глава 11. Объектно-ориентированные базы данных

11.1.

Недостатки реляционных баз данных

11.2.

Состояние развития ООБД

11.3.

Сущность ООБД

11.4.

Недостатки и перспективы развития ООБД

Часть 3. Распределенные базы данных (РБД)

Раздел 5. Основы теории РБД

12.

Глава 12. Общая характеристика РБД

12.1.

Новые требования, предъявляемые к БД

12.2.

Состав и работа РБД

12.3.

Система клиент/сервер

Раздел 6. Основы теории РБД

13.

Глава 13. Создание РБД

13.1.

Обеспечение целостности

13.2.

Фрагментация и локализация

13.3.

Процесс интеграции

13.4.

Преобразование структуры и данных

13.5.

Однородные и неоднородные РБД

14.

Глава 14. Использование РБД

14.1.

Одновременный доступ

14.2.

Защита

14.3.

Восстановление РБД

14.4.

Запросы

Заключение

Контрольные вопросы

Литература

Указатели
11  именной указатель
360  предметный указатель
163  указатель иллюстраций
25  указатель компаний

14.
Глава 14. Использование РБД

В использовании РБД возможно выделить управление работой БД (одновременный доступ, защита, восстановление), определяемые используемой СУБД, и доступ к данным (запросы).

14.1.
Одновременный доступ

Особенностью База данных распространеннаяРБД является многопользовательский распределенный доступ к данным [ссылка на источники литературы].

Специфика многопользовательского доступа с его проблемами освещена в части I данной работы и потому считается известной читателю. Здесь рассматривается проблема конкурирующего параллельного доступа.

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

Взаимодействие элементов в РБД по-прежнему осуществляется посредством транзакции, которая становится распределенной (рис. 14.1)Рис. 14.01. Распределенная модель транзакции: Ti (суб) транзакции и, воздействуя на целостную БД, после своего завершения оставляет БД целостной. В Транзакциятранзакции выделяют две команды: читать (R) и писать-обновлять (W).

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

В СУРБД в каждом узле ведется свое расписание. Вектор расписаний всех узлов назовем Расписание распределенноераспределенным расписанием (РР).

Последовательное РР (ПРР) - это РР, в котором каждая составляющая последовательна. Последовательностноподобное РР (ППРР) эквивалентно ПРР.

Существует несколько методов синхронизации.

I. Блокировка, которая может быть:

    1) с главным узлом;

    2) с заданием блокировки с помощью предикатов;

    3) с главной копией.

II. Голосование по большинству.

III. Метод предварительного анализа конфликтов.

I. Блокировка.

  1. Выделенный узел становится приоритетным и управляет остальными узлами, как в централизованной БД. Известно (часть I), что блокировка в централизованной БД предусматривает монопольный режим для записи и коллективный режим для чтения. Эти режимы используются и в блокировке с главным узлом, который руководит процессом синхронизации.

    Применяют двух- и трехфазную транзакции.

    В двухфазной транзакции выделяют:

    1) расширение (блокировка ресурса);

    2) сжатие (возвращение ресурса и снятие блокировки).

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

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

  2. Любой кортеж t отношения r со схемой R, для которого предикат P(t) = true, не может быть вставлен в R, удален или изменен другой транзакцией до снятия блокировки.

    Двухфазная блокировка работает здесь следующим образом.

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

    В фазе сжатия (разблокировки) осуществляется удаление строки из таблицы блокировок: первая же разблокировка говорит о начале фазы сжатия.

    Установление факта конфликта здесь по-прежнему проблематично: показано, что в общем случае проблема рекурсивно неразрешима.

    Процедура установления факта конфликта определена математически для предикатов вида [атрибут] F [константа], где в качестве F используются операции из множества (< , =, >, ≠).

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

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

    В свете сказанного дальнейшее развитие синхронизации пошло в направлении децентрализации.

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

II. Голосование по большинству. В общем случае предполагается избыточность РБД: в любом узле есть копия любого элемента.

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

    1) команда чтения в своем узле работает без блокировок и синхронизации;

    2) при записи имя элемента и его новое значение заносятся в список обновления.

После завершения транзакции список разносится по всем узлам и узел голосует за этот список (рис. 14.2).

Если большинство - «за», транзакция принимается и обновление проводится во всех узлах.

Узел голосует «за», если:

    1) элемент данных, прочитанных транзакцией, не был изменен после чтения;

    2) транзакция T не конфликтует с дугой транзакцией T', которая ожидает решения (если данный узел проголосовал «за», но T" еще не была принята или отвергнута в целом) в данном узле.

В позиции 1) используются временные метки (метки времени).

Метка присваивается транзакции и каждому элементу данных (последней транзакции, которая его обновила).

Когда узел принимает список обновления, он сравнивает временные метки и определяет выполнение условий 1) и 2).

Если условие 1) не выполняется, узел отвергает транзакцию, которая рестартует (рис. 14.2).Рис. 14.02. Алгоритм голосования по большинству: А - конфликт есть; Б - текущая транзакция получает большую временную метку, чем ожидающая транзакция; ВР, ТР - временные метки последнего изменения и текущей транзакции

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

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

Чтобы их избежать, узел голосует «против», если условие 1 выполняется, а 2) - нет, и транзакция получает большую временную метку, чем ожидающая транзакция.

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

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

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

Оставшиеся МТ должны синхронизировать свои транзакции.

14.2.
Защита

Здесь речь идет о защите данных в База данныхБД и Приложениеприложений, запрашивающих данные.

Для защиты Администратор распределенной базы данныхадминистратор РБД (АРБД) присваивает пропуска [ссылка на источники литературы] для всех зарегистрированных в РБД пользователей и дает им разрешение на выполнение конкретных операций с конкретными данными.

Проще всего это можно выполнить, как в СУРБД Oracle, с использованием Язык SQLязыка SQL.

В таком случае, как и в централизованной БД, выделяют режимы запрещения и разрешения. К запрещениям относятся пароль, идентификатор пользователя. Они позволяют получить доступ к РБД в целом.

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

Полномочия могут относиться к объектам или системе в целом. Полномочия для отдельных объектов («внутренность таблицы») предоставляют для какой-либо таблицы конкретным пользователям возможность выполнения операций (INSERT, UPDATE, DELETE). Системные полномочия касаются всей БД: создание, изменение структуры, удаление любой табличной области, опрос любой таблицы (CREATE, ALTER, DROP, SELECT).

Как и в централизованной БД, перечисленные полномочия могут быть отменены (REVOKE).

Для целей защиты АРБД может создавать (использовать) роли.

14.3.
Восстановление РБД

Если База данных распределеннаяРБД обеспечивает целостные, непротиворечивые данные, говорят об ее корректном состоянии (корректности).

Восстановление (управление восстановлением) связано с приведением системы в корректное состояние после (аппаратного) сбоя.

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

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

Система восстановления решает две группы задач:

    1) при незначительной неисправности - откат в выполнении текущей транзакции;

    2) при существенных отказах - минимизация работы по восстановлению РБД.

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

Копирование изменений возможно после закрытия БД. Однако для РБД с интенсивными обновлениями копирование (архивацию) следует проводить в процессе работы РБД.

Журнал может содержать одну или более групп файлов регистрации и членов групп для физического сохранения изменений РБД. Любая группа включает один или более файлов, которые могут храниться на разных дисках, как это делается в СУБД Oracle [ссылка на источники литературы].

Процедура восстановления проводится следующим образом.

  1. Устраняется аппаратный сбой.

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

  3. Запускается процесс восстановления:

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

    б) с отменой - отмена незавершенных транзакций, оставшихся после восстановления с применением транзакций.

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

Изучим подробнее процесс отказа.

Возможно выделить следующие основные состояния узла: исправный, неисправный (застопоривший, неуправляемый), восстанавливаемый.

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

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

Обсудим два возможных случая работы узлов в надежной сети: без дублирования и с Дублирование данныхдублированием данных.

При отсутствии дублирования не рассматриваются неуправляемые узлы (узлы с потерей управления).

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

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

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

Может быть частичное и полное (в каждом узле находится полная копия РБД) дублирование.

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

Достоинствами метода основной копии являются единственная последовательность корректировки БД и уменьшение вероятности тупика.

В случае чтения во всех доступных узлах и использования активных узлов формируется и вводится список U записей об активных узлах, а основной узел используется для восстановления. «Основная» транзакция при обновлении должна запрашивать обстановку для записи и корректировки данных во всех узлах списка U, включая основной. Удается избежать некоторых конфликтов (чтение-запись, запись-запись), когда система полностью работоспособна. При наличии отказов и восстановлений список U меняется основным узлом и может возникнуть осложнение.

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

Пример 14.2. Пусть узел 2 восстановился. Он запрашивает информацию о пропущенных транзакциях. Основной узел передает данные по транзакциям T1 , ..., Tn и добавляет узел 2 в список U. Однако транзакция Tn+1 , находящаяся в состоянии фиксации, имеет старый список и не будет записывать в узел 2.

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

Возможны и другие методы [ссылка на источники литературы]:

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

    2) голосование по большинству: если откажут все узлы фрагмента, надо подождать восстановления мажоритарной группы.

Схема восстановления одного из узлов показана на рис. 14.4.Рис. 14.04. Схема восстановления при потере управления: t1, t5 - отказ; t2 - выявление (само) отказа; t3 - начало восстановления; t4 - конец восстановления

Пусть в момент t1 отказал узел 2 и его БД разрушилась. Если узел 2 не будет исправлен до момента времени t5 , то отказ узла 1 или 2 приведет к серьезному сбою. Узел 2 выявляет свой отказ к моменту t2 и начинает восстанавливаться, используя «снимки» других узлов. На интервале t3 - t4 исправные узлы должны продолжать выполнение транзакций, которые должен запоминать узел 2 (и обрабатывать после момента t4 ). С момента t4 узел 2 присоединяется к остальным и система может выдержать второй отказ.

14.4.
Запросы

Если структура Запросзапросов заранее известна (стандартна), то эффективность процесса запроса определяется на описанных ранее этапах фрагментации и локализации [ссылка на источники литературы].

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

Целями (целевыми функциями) оптимизации могут быть:

    1) минимум времени передачи данных;

    2) минимум времени обработки данных в узлах;

    3) увеличение параллельности при обработке и передачах данных;

    4) улучшение трафика и загрузки процессоров в сети;

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

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

    7) выравнивание нагрузки компьютеров.

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

Стоимость ТС обработки данных объема x, пересылаемой в узел i из узлов j и связанной с эксплуатацией физических каналов связи, составляет

,

где , - определяемые системой матрицы стоимости установления связи и передачи единицы информации ( = = 0).

Задержка TD(x) - время между началом и окончанием обработки запроса:

,

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

Примем такие предположения:

    1) каналы связей однородны ();

    2) стоимость передачи высока и затратами на локальную обработку можно пренебречь (учитываются параметры только передачи данных).

Оптимизация запроса может быть разделена на два этапа:

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

    2) локальная оптимизация, проводимая методами, описанными в части I и здесь не рассматриваемыми.

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

Снова, как в части I, используем дерево запросов, в котором каждому из листов соответствует отношение, каждой вершине - операция РА. Конечной вершине соответствует узел РБД (локальная БД), а ответу на вопрос - корневая вершина.

Операции реляционной алгебры (селекция S или s, проекция P или p, соединение J, объединение UN, разность DF, декартово произведение CP, полусоединение SJ) и связывающие их законы описаны в части I данной работы [ссылка на источники литературы с. 41].

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

В связи с этим используем эвристический подход к оптимизации.

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

В этой связи возможны следующие рекомендации.

  1. Унарные операции необходимо выполнить как можно ранее (в узлах). Это иллюстрирует рис. 14.5.Рис. 14.05. Использование унарных операций

  2. Многократно встречающиеся выражения лучше выполнить один раз. Для этого в дереве запроса проводится слияние листьев-отношений, затем - слияние одинаковых промежуточных операций (рис. 14.6).Рис. 14.06. Выделение общих подвыражений: а - исходный; в - преображенный запрос Здесь используется очевидное выражение

    DF(T, SNF (T))=SF (T), NF=NOT F.

  3. Использование полусоединения. Идея полусоединения иллюстрируется на рис. 14.7.Рис. 14.07. Использование полусоединения При традиционной схеме либо R надо пересылать в узел 2, либо S - в узел 1 (пунктирная линия). Можно пересылать лишь один раз S, сокращенную в помощью проекции, в узел 1 и затем осуществлять полусоединение.

    Покажем сказанное на примере. Пусть даны следующие отношения:

    Узел 1 Узел 2
    r(A B) s(B C D) r'(B) s'(B C D)
    14 4 13 16 4 4 13 16
    15 4 14 16 5 4 14 16
    16 7 13 17 6 7 13 17
    24 10 14 16 4
    26 10 15 17 6
    37 11 15 16 7
    38 11 15 16 8
    39 12 15 16 9

    Имеются следующие возможности.

    Переслать S из узла 2 в узел 1 (24 значения).

    Вычислить r'=Рв (r) в узле 1 и переслать его в узел 2, где вычислить s'=J(r', s) и отправить в узел 1. Там найти J(r, s) как J(r, s'), т.е. получить полусоединение. Передается уже 9 + 6 = 15 значений.

    Напомним, что полусоединение r и s или SJ(r, s) есть РR (J(r, s)), Rеr. Если отношения r и s находятся в разных узлах, то вычисление полусоединения уменьшает объем передаваемых данных. Заметим, что для полусоединения справедливо J(SJ(r, s), s).

    Иногда полусоединение может полностью заменить соединение.

    Отметим, что полусоединение чаще применяется при вертикальной фрагментации.

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

Вводят понятие Профиль«профиль», который включает:

    1) мощность (количество полей) отношения R;

    2) «ширину» (число байтов) любого атрибута;

    3) число различных значений атрибута в отношении R.

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

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

Таким образом, задача оптимизации запроса отличается неоднозначностью решения.

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

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

Заключение

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

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

Фактически впервые дано систематическое описание перспективного направления развития БД - сетевого варианта в виде База данных распределеннаяраспределенных баз данных (РБД). Методически последовательно показаны особенности структуры и работы РБД, этапы ее создания и использования, приведено системное изложение процедуры проектирования.

© Центр дистанционного образования МГУП