Гомогенные и гетерогенные распределенные базы данных
Гомогенная РаБД — состоит из объектов (БД) одного и того же типа, включенных в однородную (гомогенную) информационную сеть, использующую одинаковые протоколы и интерфейсы доступа ко всем объектам сети, включая локальные базы дынных.
Гетерогенная РаБД состоит из объектов (локальных БД, модулей, контуров) различных фирм-производителей, включающих разнотипные технические средства и фрагменты разнородных сетей разной топологии, которые могут работать по различным протоколам (интерфейсам доступа).
Гетерогенные РаБД облегчают интеграцию разнородных информационных источников, структурированных (с наличием нормализованной схемы), слабоструктурированных и иногда даже неструктурированных.
Обычно гетерогенная (разнородная) РаБД конструируется с использованием центральной БД, которая фактически управляет базами данных компонентов, так что пользователи получают однородные интерфейсы доступа к данным, сохраненным в БД различных объектов и богатые функциональные возможности разнородной системы. Такая разнородная ИС называется системой объединенных мультибаз данных (MDBS).
MDBS представляет для пользователя иллюзию одиночной базы данных, поддерживающую только глобальную схему. Глобальная схема интегрирует схемы локальных БД, фактически поддерживающих все данные пользователя.
MDBS фактически управляет множественными шлюзами (или драйверами), чтобы поддержать непротиворечивость данных внутри локальных БД.
|
|
|
Двенадцать правил К. Дейта
В 1981 г К. Дейт опубликовал свои 12 правил для разработки распределенных БД, которые в сокращенном виде могут быть сформулированы следующим образом:
1. Локальная автономность. Локальные данные должны находиться под локальным владением и управлением, включая функции безопасности, целостности, представления данных в памяти.
2. Никакой конкретный сервис не должен возлагаться на какой-либо специально выделенный центральный узел.
3. Непрерывность функционирования. Система не должна останавливаться в случае необходимости добавления нового узла или удаления в распределенной среде некоторых данных.
4. Независимость от местоположения. Пользователи и приложения не обязаны знать о том, где физически располагаются данные.
5. Независимость от фрагментации. Фрагменты (называемые также разделами) данных должны поддерживаться и обрабатываться средствами РаСУБД таким образом, чтобы пользователи или приложения могли бы вообще ничего не знать об этом.
6. Независимость от тиражирования. Те же принципы независимости и прозрачности относятся и к механизму тиражирования.
7. Распределенная обработка запросов. Обработка запросов должна производиться распределенным образом.
|
|
|
8. Управление распределенными транзакциями. На распределенные базы данных необходимо распространить механизмы управления транзакциями и управления одновременным доступом.
9. Независимость от оборудования. Одно и то же программное обеспечение РаСУБД должно выполняться на различных аппаратных платформах и функционировать в системе в качестве равноправного партнера. (На практике достичь этого исключительно сложно — отмечал уже сам К. Дейт).
10. Независимость от операционных систем. Эта проблема тесно связана с предыдущей, и она также разрешается аналогичным образом.
11. Независимость от сети. Узлы могут быть связаны между собой с помощью множества разнообразных сетевых и коммуникационных средств. Многоуровневая модель, присущая многим современным информационным системам (например, семиуровневая модель OSI, модель TCP/IP, уровни SNA и DECnet), обеспечивает решение этой проблемы не только в среде РБД, но и для информационных систем вообще.
12. Независимость от СУБД. Локальные СУБД должны иметь возможность участвовать в функционировании РаСУБД
Однако несмотря на всю привлекательность этих правил и на давность их возникновения степень реализации их в современных коммерческих СУБД очень низкая — отмечается в современной научно-технической литературе по распределенным базам данных.
|
|
|
Рассмотрим подробнее одно из приведенных выше правил по обработке распределенных запросов, которая заключается в том, что при выполнении данной операции следует всегда использовать принцип оптимизации, обеспечивающей минимизацию использования сети.
Вопрос оптимизации является более важным для распределенной системы, чем для централизованной системы. Причина в том, что для выполнения запроса, охватывающего несколько узлов, существует множество способов перемещения данных по сети. И здесь важно найти наиболее эффективную стратегию. При этом время отклика системы варьируется от минимального, составляющего десятые доли секунды, до максимального, исчисляемого несколькими часами.
Таким образом, время отклика в такой системе может оказаться меньше времени отклика в централизованной системе. На самом грубом уровне процесс обработки распределенных запросов можно разбить на следующие фазы:
1. В узле, в котором инициирован запрос, производится грамматический разбор предложения SQL с построением внутреннего представления запроса в виде дерева. На основе информации каталогов узлов производится замена имен объектов, фигурирующих в запросе, на их системные идентификаторы.
|
|
|
2. Затем формируется глобальный план выполнения запроса с применением техники оптимизации.
3. Если в глобальном плане выполнения запроса участвуют дополнительные узлы, производится его декомпозиция на части, каждую из которых можно выполнить в одном узле, и эти части рассылаются в эти дополнительные узлы.
4. В каждом узле, участвующем в глобальном плане выполнения запроса, выполняются заключительные фазы: оптимизация и генерация машинных кодов. А также производится проверка прав пользователя, обрабатываются представления базы данных.
РаСУБД обладают следующими преимуществами:
- позволяют соединить децентрализованные и централизованные системы обработки распределенных баз данных, тем самым распределить нагрузку между различными компонентами системы;
- обладают лучшими адаптивными свойствами (приспособлением к возникающим условиям) против других систем;
- обеспечивают высокую надежность, доступность и низкую чувствительность к выходу из строя отдельных компонентов.
К недостаткам РаСУБД можно отнести следующие факторы:
- наличие значительного большего числа функций против обычных СУБД;
- необходимость синхронизации при обработке поисковых и корректирующих запросов;
- усложнение задач проектирования БД как на логическом, так и на физическом уровнях;
- включение при проектировании дополнительных уровней моделей данных, что влечет за собой увеличение времени обработки;
- более высокая стоимость передачи данных и более низкая надежность передачи данных по сравнению с централизованными БД.
Хранилища данных
Для того чтобы принимать обоснованные решения, организации необходима надежная система данных. Такая система должна включать как текущие, так и исторические данные, чтобы можно было выявлять динамику процессов и прогнозировать будущие результаты.
Технология интеграции данных — ключевой фактор для объединения этих данных и создания информационной инфраструктуры, которая включает Хранилища данных, витрины данных и операционные склады данных.
По определению автора и основоположника концепции хранилищ данных (Data Warehouse) Уильяма Инмона:
Хранилище данных — это предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления, призванные выступать в роли единого и единственного источника истины, обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений
Создание Хранилища данных (или, в более ограниченном масштабе, витрины данных, содержащей данные только об одном предмете) существенно упрощает доступ к необходимым данным и их аналитическую обработку. Аналитическая обработка данных необходима для анализа тенденций изменения и прогнозирования бизнес-процессов, что требует сбора данных с отметками времени из многочисленных источников в единое Хранилище или витрину данных.
Таким образом, задачей интеграции данных является получение единой и цельной картины корпоративных бизнес-данных и тенденции их изменения.
Существует три основных метода интеграции данных: консолидация, федерализация и распространение.
Консолидация данных. При использовании этого метода данные собираются из нескольких первичных систем и интегрируются в одно постоянное место хранения. Такое место хранения может быть использовано для подготовки отчетности и проведения анализа, как в случае Хранилища данных, или как источник данных для других приложений, как в случае операционного склада данных.
Преимуществом консолидации данных является то, что этот подход позволяет осуществлять трансформацию значительных объемов данных (реструктуризацию, согласование, очистку и/или агрегирование) в процессе их передачи от первичных систем к конечным местам хранения. Некоторые сложности, связанные с данным подходом, — это значительные вычислительные ресурсы, которые требуются для поддержки процесса консолидации данных, а также существенные ресурсы памяти, необходимые для поддержки конечного места хранения. Но с учетом постоянно совершенствования аппаратных средств это не проблема.
В среде Хранилищ данных одной из самых распространенных технологий поддержки консолидации является технология ETL (извлечения, преобразования и загрузки — extract, transform, and load). Еще одна распространенная технология консолидации данных — управление содержанием корпорации ECM (enterprise content management). Большинство решений ECM направлены на консолидацию и управление неструктурированными данными, такими как документы, отчеты и web-страницы.
При использовании этого метода обычно существует некоторая задержка между моментом обновления информации в первичных системах и временем, когда данные изменения появляются в конечном месте хранения. В зависимости от потребностей бизнеса такое отставание может составлять несколько секунд, часов или дней. Термин «режим, приближенный к реальному времени» часто используется для описания конечных данных, обновление которых отстает от источника на несколько секунд, минут или часов. Данные, не отстающие от источника, считаются данными в режиме реального времени, но это трудно достижимо при использовании метода консолидации данных.
Федерализация данных обеспечивает единую виртуальную картину одного или нескольких первичных файлов данных.
По определению, процесс федерализации данных всегда заключается визвлеченииданных из первичных систем на основании внешних требований. Все необходимые преобразования данных осуществляются при их извлечении из первичных файлов. Интеграция корпоративной информации EII (Enterprise information integration) — пример технологии, которая поддерживает федеративный подход к интеграции данных.
Считается, что основное преимущество федеративного подхода — тот факт, что он обеспечивает доступ к текущим данным и избавляет от необходимости консолидировать первичные данные в новой БД (Хранилище данных).
Федерализацию данных целесообразно использовать в тех случаях, когда стоимость консолидации данных перевешивает бизнес-преимущества, которые она предоставляет.
Приложения распространения данных осуществляют копирование данных из одного места в другое, работая в оперативном режиме.
Обновления в первичной системе могут передаваться в конечную систему синхронно или асинхронно. Независимо от используемого типа синхронизации, метод распространения гарантирует доставку данных в систему назначения.
Примерами технологий распространение данных, являются интеграция корпоративных приложений EAI (Enterprise application integration) и тиражирование корпоративных данных EDR (Еnterprise data replication).
Большим преимуществом метода распространения данных является то, что он может быть использован для перемещения данных в режиме реального времени или близком к нему. Другие достоинства включают гарантированную доставку данных и двустороннее распространение данных.
При использовании этого метода обычно существует некоторая задержка между моментом обновления информации в первичных системах и временем, когда данные изменения появляются в конечном месте хранения. В зависимости от потребностей бизнеса такое отставание может оставлять несколько секунд, часов или дней. Термин «режим, приближенный к реальному времени» часто используется для описания конечных данных, обновление которых отстает от источника на несколько секунд, минут или часов. Данные, не отстающие от источника, считаются данными в режиме реального времени, но это трудно достижимо при использовании метода консолидации данных.
Вопросы для самопроверки
1. В чем заключается эволюция концепции обработки данных?
2. Какие основные достоинства использования компьютерных сетей?
3. На какие уровни в модели OSI подразделяются все протоколы сети?
4. В чем состоит сущность удаленной обработки данных?
5. Какое программное средство применяется в системах совместного использования файлов для работы с многопользовательскими базами данных?
6. Принцип удаленного доступапри использовании архитектур файл/сервериклиент/сервер.
7. Перечислите причины неэффективности архитектуры файл/сервер.
8. Какие основные преимущества имеет система клиент/сервер?
9. Какую архитектуру и преимущества имеют распределенные СУБД?
10. Назовите отличия гомогенных и гетерогенных распределенных баз данных.
11. Какие основные требования предложил К. Дейт в своих 12-ти правилах для распределенных БД?
12. Перечислите основные преимущества и недостатки РаСУБД.
13. Для каких целей создаются Хранилища данных?
Дата добавления: 2019-02-12; просмотров: 1042; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!