Шпора_РБД_37-48 (Шпоры по распределительным базам данных)

37) Структура распределения данных и программ

Она отражает алгоритм доступа, уровень и распределение.

1. Динамический доступ к информации, информация – не распределенная, БД - локальная.

2. К локальной инф-ии осущ-ся статический доступ

3.Доступ статический, частичная релевантность

4. Алгоритм доступа – статический, БД – локальная, релевантность полная

5. БД – распределенная, алгоритм – статический, релевантность низкая

6. Распределены и данные и программы.

38) Алгоритм разработки сверху-вниз. Схема алгоритма, особенности реализации.

1. Анализ требований (внешней среды)

2. Системные требования

3. Концептуальный дизайн

4. Логический дизайн

5. Глобальная концептуальная схема

6. Информация по доступу

7. Определение внешней схемы

8. Распределение на основе 5-7. (Учитывается пользователь)

9. Локальная концептуальная схема

10. Физическая структура (схема)

11. Физическая схема на носителе.

12. Мониторинг за тем, что мы сделали, за счет обратных связей.

Может повлиять на 10, 8, 3, 4 и скорректировать требования к базе

39) Управление транзакциями. Осн. понятия и определения, модель транзакции.

Транзакция – это единица работы над данными. Проблемы управления транзакциями:

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

- проблемы при аварийном завершении обновлений РБД.

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

Модель транзакций

БД консистента

Успешная транзакция – это та транзакция, которая обеспечивает целостность БД.

40) Различные модели и типы транзакций.

Модели транзакций

1. Общая модель

2. 2-х фазная модель

3. Ограниченная модель

4. Ограниченная 2-х фазная модель

5. Модель действия

Типы транзакций

1. Плоские (flat), простые, в них отсутствуют вложения, имеют одну точку старта и одну точку завершения.

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

41) Монитор распределенной обработки. Архитектура транзакции

4

1. Менеджер транзакций

2. Планировщик

3.Операции (старт, писать, читать, обновлять, удалять)

4. Результаты

5. Взаимодействие с др. планировщиком задач

6. Взаимодействие с др. процессором данных

7. Планировщик и перепланирование запросов

8. Связь с др. менеджером транзакций

9. Взаимодействие с обработчиками данных (процессорами данных)

Монитор распределенной обработки состоит из 2-х модулей:

- менеджера транзакций (координирует выполнение операций над БД)

- планировщика (внутренние специфические алгоритмы для синхронизации и доступа к БД)

Операции:

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

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

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

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

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

42) 2-х фазный протокол обновления БД.

1 – идет идентификация процедуры обновления

2 – ожидание.

В случае работы с РБД по огранич. 2-х фазному протоколу инициатор обновления выдает запрос на обновление, потом он приходит в стадию ожидания. Приходит сообщение, что удаленный узел готов и выдает сигнал на узел-инициатор. На нем осуществляется процедура изменения данных. Начинается обновление. Если процедура прошла успешно, то узел, взаимодействующий с удал. узлом, говорит об успешности процедуры и пишет в журнал (4). Если неуспешно, то (3) происходит откат транзакции, восстановление транзакции по данным журнала.

43) 12 правил Дейта для РБД.

1. Независимость локального сайта. Каждый локальный сайт РБД может действовать как независимая, автономная, централизованная СУБД.

2. Независимость от центрального сайта. Ни один сайт в сети не зависит от центрального или какого-либо другого сайта. Все сайты имеют равные возможности.

3. Независимость от сбоев. Функции системы не зависят от сбоя на каком-либо узле.

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

5. Прозрачность фрагментации. Пользователь видит единую логическую БД и фрагментация прозрачна для пользователя.

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

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

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

9. Независимость от оборудования. Система должна выполняться на любой платформе.

10. Независимость от ОС. Система должна выполняться в любой операционной среде.

11. Независимость от сети. Система должна выполняться на любой сетевой платформе.

12. Независимость от БД. Система должна поддерживать любую БД.

44) Стандарты интерфейса уровня вызовов SAG.

В 1989 г. образовалась группа SQL Access Group (SAG). Она представляет собой консорциум из 42 компаний.

Одной из задач SAG было определение спецификаций форматов и протоколов (Formats And Protocols, FAP) для коммуникаций в системах баз данных клиент-сервер на основе спецификаций Удаленного доступа к базам данных (Remote Database Access, RDA), разработанных Международной организацией по стандартизации (International Standards Organization, ISO). Стандарт RDA описан в документе ISO/IEC 9579, Информационные технологии - Языки баз данных - Удаленный доступ к базам данных (ISO/IEC 9579, Information Technology Database Languages - Remote Database Access), который состоит из двух частей: Общая модель, сервис и протокол (Generic Model, Service and Protocol) и Специализация SQL (SQL Specialization)^ Вторая часть этого документа и стала основой спецификаций FAP⁴, предложенных группой SAG.

45) Архитектура ODBC. Стандарты ODBC и IDAPI.

В 1992 г. возникли сразу два конкурирующих стандарта - ODBC и IDAPI, и оба они основаны на интерфейсе уровня вызовов (Call-Level Interface, CLI), предложенном SAG*. Первый из них - Открытый интерфейс доступа к базам данных (Open DataBase Connectivity, ODBC) был введен и активно продвигался компанией Microsoft. Целью Microsoft было предоставление приложениям Microsoft | Windows доступа к базам данных, основанным на SQL, посредством стандартизованного интерфейса клиент-сервер (рис. 3.6). Главное назначение ODBC - превратить SAG CLI из абстрактного обобщенного стандарта в живую среду, в которой он может непосредственно использоваться в приложениях для ПК.

46) Архитетура IDAPI. Стандарты ODBC и IDAPI.

Несколькими месяцами позже, в ноябре 1992 г., группа компаний под руководством Borland (включающая также IBM, Novell и WordPerfect) объявила аналогичный стандарт интерфейса для систем баз данных клиент-сервер, также основанный на SAG CLI и получивший название Интерфейса прикладного программирования для интегрированных систем баз данных (Integrated Database Application Programming Interface, IDAPI). Архитектура IDAPI показана на рис. 3.7. Стандарт IDAPI концептуально аналогичен ODBC. Оба стандарта специфицируют интерфейсы клиент-сервер, основанные на SAG CLI, но IDAPI изначально был ориентирован, помимо Microsoft Windows, также и на другие платформы и предоставлял в дополнение к SQL-

доступу также и навигационный доступ к серверам баз данных.

47) Категории операторов в API.

1. Среда и соединение. Операторы предназначены для откр/закр. соединения с серверами, управлением дексрипторами, курсорами.

2. Ресурсы и возможности. Группа операторов, управляющих конфигурационными файлами.

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

4. Операторы подготовки и выполнения.

5. Определение данных. Создание индексов, уничтожение таблица индексов

6. Манипулирование. Удаление/обновление строк, управление блокировкой строк и таблиц, управление глобами и открытие курсора.

7. Управление транзакциями. Фиксация и откат транзакций, отмена выполнения отдельных SQL-операторов.

8. Диагностика. Возврат информации об ошибках.

9. Расширение специфичн. для конкретной СУБД. Управление паролями.

10. Прочие (разное). В т.ч. позиционирование курсора.

48) Брокер объектных запросов.

Архитектура брокера запросов объектов (CORBA – Common Object Request Broker Architecture) – определяет механизмы взаимодействия объектов в разнородной сети. Спецификация CORBA разработана для обеспечения возможности интеграции разных объектных систем. Главный компонент спецификации – брокер объектных запросов.

Задачей брокера является предоставление механизма выполнения запроса объекта-клиента: поиск объекта, к которому относится данный запрос, передача необходимых данных, подготовка объекта к обработке. Брокер запросов обеспечивает прозрачное взаимодействие клиентского и серверного приложений.