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

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


         

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

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


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

Введение

Часть 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  указатель компаний

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

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

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

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

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

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

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

Быстрое распространение сетей передачи данных, резкое увеличение объема внешней памяти ПК при ее удешевлении в 80-е годы способствовали широкому внедрению РБД.

К достоинствам РБД относятся:

    1) соответствие структуры РБД структуре организаций;

    2) гибкое взаимодействие локальных БД;

    3) широкие возможности централизации узлов;

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

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

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

    7) возможность распределения файлов в соответствии с их активностью;

    8) независимые разработки локальных БД через стандартный интерфейс.

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

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

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

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

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

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

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

    1) ЯОД в рамках схемы должен быть один для всех локальных БД;

    2) доступ должен быть коллективным к любой области РБД с соответствующей защитой информации;

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

    4) степень централизации должна быть разумной;

    5) необходимы сбор и обработка информации об эффективности функционирования РБД ссылка на источники литературы.

В дальнейшем рассмотрении РБД выделим:

    1) изучение состава, работы и особенностей РБД при условии, что она спроектирована (процедура использования РБД);

    2) рассмотрение процедуры создания РБД (проектирование РБД).

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

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

Общий набор (система таблиц) данных, хранимых в РБД, показан в табл. 12.1.

Таблица 12.1.

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

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

Таблица 12.1.

Пользовательский уровень состоит из фрагментов (например, строки A, B, C, 1, 2, 3 или столбцы табл. 12.1) глобального уровня, которые составляют фрагментарный, логический уровень.

Выделяют горизонтальную и вертикальную ссылка на источники литературы фрагментацию (расчленение).

Фрагментация горизонтальнаяГоризонтальное фрагментирование связано с делением данных по узлам. Горизонтальные фрагменты не перекрываются.

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

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

Так, например, локализация для примера в табл. 12.1. может иметь вид, показанный в табл. 12.3.

Таблица 12.3.

Локализация данных

Имя таблицы Фрагменты Распределение фрагментов по узлам
Служащие 1
2
3
1
1,2
1,3
Завод a
a
a
1,2.3
1,2,3
1,2,3
Сырье A
B
C
1
2
3

Очевидно, что для таблицы «Завод» осуществляется дублирование, а для таблицы «Сырье» - расчленение.

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

Физическую реализацию (логического) фрагмента называют Фрагмент хранимыйхранимым фрагментом.

Иначе говоря, РБД можно представить в виде, показанном на рис. 12.3.Рис. 12.03. Уровни представления данных в РБД

Сеть в РБД образуют сетевые операционные системы (например, Windows NT, Novell NetWare). В качестве СУБД, изначально предназначавшихся для использования в сети, следует назвать BTrieve, Oracle, Interbase, Sybase, Informix.

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

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

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

Схема работы РБД ссылка на источники литературы показана на рис. 12.4.Рис. 12.04. Схема работы РБД Пользовательский запрос, определяемый приложением, поступает в Система управления распределенной базы данныхсистему управления распределенной базы данных (СУРБД) и через сетевую и локальную операционные системы попадает в локальную Система управления базы данныхСУБД. Если запрос связан с локализованными данными, СУБД осуществляет вызов данных из локальной БД, которые поступают пользователю. Если часть данных для выполнения приложения находится в другой локальной БД, локальная СУБД дополнительно через локальные и сетевые операционные системы осуществляет удаленный вызов процедуры (Remote Procedure Call - PRC), после выполнения которой данные передаются пользователю.

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

Сравнительные характеристики стратегий хранения приведены в табл. 12.4.

Таблица 12.4.

Стратегии хранения данных в РБД

Название стратегии Суть стратегии Достоинства Недостатки
Централизация (в том числе технология клиент/сервер) Единственная копия БД в одном узле Простота структуры




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




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




Объем БД ограничен долговременной памятью. Синхронизация многих копий. Дополнительная память. Слабая реализация параллельной обработки.
Рекомендации применения:
Фактор уверенности превалирует. БЛД невелика. Интенсивность обновления невысока. Интенсивные запросы.
Смешанная Несколько копий хранимого лгического фрагмента в каждом узле Любая степень надежности. Большая доступность. Меньше пересылок. Параллельная обработка.


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

 

На ее основе может быть построен простейший алгоритм выбора стратегии, показанный на рис. 12.5.Рис. 12.05. Алгоритм выбора стратегии хранения: А - запрос локален

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

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

В этой структуре один из компьютеров, имеющий самый большой объем памяти и наиболее высокое быстродействие, становится приоритетным, называемым сервером.

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

На сервере чаще всего хранятся только данные, запрашиваемые клиентами.

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

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

Работа в архитектуре клиент/сервер может поддерживаться и с помощью схемы Open DataBase Connectivity (ODBC), как показано на рис. 12.7.Рис. 12.07. ODBC в архитектуре клиент/сервер

Сеть образуется в этом случае путем соединения серверов.

Обсудим более подробно вариант реализации РБД - архитектуру клиент/сервер.

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

Совместно с термином «клиент/сервер» используются три понятия.

  1. Архитектура: речь идет о концепции построения варианта РБД.

  2. Технология: говорят о последовательности действий в РБД.

  3. Система: рассматриваются совокупность элементов и их взаимодействие.

Об архитектуре клиент/сервер говорилось ранее.

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

    1) сокращается общее время выполнения запросов за счет мощного сервера;

    2) уменьшается доля и увеличивается эффективность использования клиентом (для вычислений) центрального процессора;

    3) уменьшается объем использования клиентом памяти «своего» компьютера;

    4) сокращается сетевой трафик.

К таким крупномасштабным системам предъявляются следующие требования:

    1) гибкость структуры;

    2) надежность;

    3) доступность данных;

    4) легкая обслуживаемость системы;

    5) масштабируемость приложений;

    6) переносимость приложений (на разные платформы);

    7) многозадачность (возможность выполнения многих приложений).

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

СерверСервер осуществляет управление общим для множества клиентов ресурсом. Он выполняет следующие задачи:

    1) управляет общей БД;

    2) осуществляет доступ и защиту данных, их восстановление;

    3) обеспечивает целостность данных.

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

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

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

    1) предоставляет интерфейс пользователю;

    2) управляет логикой работы приложений;

    3) проверяет допустимость данных;

    4) осуществляет запрос и получение данных с сервера.

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

В качестве СОС могут использоваться Windows NT, Novell NetWare (чаще всего при применении DOS). Коммуникационное программное обеспечение позволяет компьютерам взаимодействовать на языке специальных программ - коммуникационных протоколов.

В общем случае такое взаимодействие осуществляется с помощью семиуровневой схемы ISO с соответствующими протоколами [57]. Для локальных сетей схема упрощается. Протоколами для Winows NT служат Transmission Control Program/Internet Program (TCP/IP), для NetWare - Sequenced Packed eXchange/Internet Packed eXchaned (SPX/IPX).

Разнообразие сетевых средств делает необходимым создание стандартного промежуточного программного обеспечения клиент/сервер, находящегося на сервере и клиентах. Говорят о прикладном программном интерфейсе (Application Programming Interface - API).

Сюда относятся Open Database Connectivity (ODBC) и Integrated Database Application Programming Interface (IDAPI), используемый в приложении Delphi и СУБД InterBase.

Взаимодействие клиентов и сервера можно представить себе следующим образом.

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

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

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

Работа сервера может иметь такой порядок.

  1. После поступления запроса диспетчер ставит его в очередь по схеме «первым пришел - первым обслужен».

  2. Процесс переднего раздела выбирает «самый старый»запрос и начинает его обработку. После завершения результаты помещаются в очередь для передачи клиенту.

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

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

  1. Запись данных из БД в промежуточную (буферную) память рабочей области (при чтении) и обратно (при обновлении).

  2. Запись в журнал транзакций.

  3. Архивация (копирование) групп транзакций.

  4. Аварийное завершение транзакций.

  5. Периодическая запись на диск контрольных точек для обеспечения восстановления данных в РБД после аппаратного сбоя.

Администратор распределенной базы данныхАдминистратор РБД (АРБД) должен решать следующие задачи ссылка на источники литературы.

  1. Планирование РБД и распределение памяти.

  2. Настройка конфигурации сети.

  3. Создание РБД.

  4. Работа с разработчиками приложений.

  5. Создание новых пользователей и управление полномочиями.

  6. Регулярная архивация БД и выполнение операций по ее восстановлению.

  7. Управление доступом к БД с помощью ОС и СОС, средств защиты и доступа.

В больших системах АРБД может состоять из ряда лиц, отвечающих, например, за ОС, сеть, архивацию, защиту.

Таким образом, система клиент/сервер своеобразна: с одной стороны, ее можно считать разновидностью централизованной многопользовательской БД, с другой стороны, она является частным случаем РБД.

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

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

Использование для составления сценария CASE-средств значительно сокращает трудоемкость работ по проектированию. Иначе эта процедура выполняется вручную с помощью команд языка SQL.

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

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

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

  2. Целесообразно использовать на сервере хранимые процедуры, совокупность которых можно инкапсулировать в виде пакета (модуля). В результате трафик уменьшится: клиент будет передавать только вызов процедуры и ее параметры, а сервер - результаты выполнения процедуры.

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

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