Применение  технологий построения распределенных систем «сверху вниз» с применением  фрагментации и тиражирования возможно только при создании новых приложений. Чаще создание интегрированной среды  осуществляется объединением существующих БД и соответствующих информационных менеджеров в дополнение к некоторым вновь проектируемым компонентам БД. 

Билет 12. Различные типы распределенных БД

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

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

1. Глобальная схема должна содержать все данные
2. Все изменения в локальной БД должны распространяться на глобальную схему.
3. Клиентские приложения сами м.б. распределены на множество узлов. Это означает, что для осуществления какой-либо операции над локальной БД необходим доступ к глобальной схеме. В этом случае глобальная схема может быть централизована.

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

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

Недостатки:

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

 

Неоднородные  системы мультибаз  данных

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

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

Билет 13. Концептуальная архитектура мультибаз данных

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

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

Медиаторы – это программный модуль, предназначенный для упрощения, абстрагирования, сокращения, слияния и объяснения данных, которыми обменивается приложение.

Функции медиаторов:

• сбор «необходимого объема» данных
• поддержка абстракции и обобщения
• интеграция текста с данными
• поддержка промежуточных результатов

Интегральная  целостность: с помощью политранзакций. 

Билет 14. Хранилища данных

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

Архитектура

Принципы  организации хранилища.

1. Проблемно предметная ориентация: данные объединяются  в категории и хранятся  и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют.
2. Интегрированность: объединяет данные т.о., что бы они удовлетворяли всем требованиям всего предприятия, а не единственной функции бизнеса.
3. Некорректируемость: данные в хранилище данных не создаются, т.е. поступают из внешних источников, не корректируются, не удаляются.
4. Зависимость от времени: данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени.

Процессы  работы с данными.

1. извлечение – перемещение информации от источников данных в отдельную БД, приведение их к единому формату.
2. Преобразование – подготовка информации к хранению в оптимальной форме для реализации запроса, необходимого для принятия решений.
3. Анализ.
4. Представление.

Источниками данных могут быть: 

• Традиционные системы регистрации операций (БД)
• Отдельные документы
• Наборы данных

Источники данных классифицируются:

1. Территориальное и административное размещение.
2. Степень достоверности.
3. Частота обновляемости.
4. Система хранения и управления данными.

Вся эта  информация используется в словаре  метаданных. В словарь метаданных автоматически включаются словари  источников данных. Здесь же форматы  данных для их последующего согласования, периодичность пополнения данных, согласованность во времени.

Задача  словаря метаданных состоит в  том, что бы освободить разработчика от необходимости стандартизировать  источники данных.

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

Логическая  структура данных хранилища данных отличается от структуры данных источников данных.

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

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

Кроме извлечения данных из БД, принятия решений  важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя.

С т.з. пользователя в процессе извлечения знаний  из БД должны решаться след. преобразования: данные ---- информация ---- знания ---- полученные решения.

Методы  выявления и анализа  знаний:

1.Ассоциация.

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

3.Классиффикация  – выявление характеристик группы, к которой принадлежит объект.

4. Кластеризация  – группы заранее не сформированы.

5. Прогнозирование – моделирование поведения определенного объекта на основе имеющихся знаний.

       Средства извлечения  знаний:

1. Нейронные  сети. Пакеты, к. созданы для прогнозирования  определенной области.

2. Деревья  решений.

3. Индуктивное  обучение.

4. Визуализация данных.

5. Нечеткая логика.

6. Различные  статистические методы. 

Билет 15. Характеристика ООБД.

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

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

      Эти проблемы связаны:

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

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

Свойства  ООБД:

1. Высокоэффективное  представление, учитывающее особенности  типов, через типы, методы, объекты. 

2. Использование  инкапсуляции.

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

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

Билет 16. Манифест ООБД.

В манифесте  ООБД  (Atkinson et al., 1989)  предлагаются  обязательные характеристики, которым должна отвечать любая ООБД. Их выбор основан на 2 критериях: система должна быть объектно-ориентированной  и представлять собой БД.