Из Википедии, бесплатной энциклопедии
  (Перенаправлено из Виртуальной базы данных )
Перейти к навигации Перейти к поиску

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

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

Определение [ править ]

Маклеод и Хаймбигнер [1] были одними из первых, кто определил систему федеративных баз данных в середине 1980-х годов.

FDBS - это та, которая «определяет архитектуру и базы данных межсоединений, которые минимизируют центральную власть, но поддерживают частичное совместное использование и координацию между системами баз данных». [1] Это описание может неточно отражать определение федеративной базы данных McLeod / Heimbigner [1] . Скорее, это описание соответствует тому, что Маклеод / Хаймбигнер назвал составной базой данных. Федеративная база данных Маклеода / Хаймбигнера представляет собой набор автономных компонентов, которые делают свои данные доступными для других членов федерации посредством публикации схемы экспорта и операций доступа; не существует единой центральной схемы, охватывающей информацию, доступную от членов федерации.

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

Три важных компонента FDBS - это автономия, неоднородность и распределение. [2] Другим аспектом, который также был рассмотрен, является компьютерная сеть сетевой среды , например, множество DBS по LAN или множество DBS по WAN, функции обновления участвующих DBS (например, отсутствие обновлений, неатомарные переходы, атомарные обновления ).

Архитектура FDBS [ править ]

СУБД может быть классифицирован как централизованные или распределенными. Централизованная система управляет одной базой данных, а распределенная - несколькими базами данных. Компонент A DBS в СУБД может быть централизованным или распределенным. Множественные DBS (MDBS) можно разделить на два типа в зависимости от автономности компонентной DBS на федеративные и нефедеративные. Система нефедеративных баз данных - это интеграция компонентных СУБД , которые не являются автономными. Система объединенной базы данных состоит из компонентов DBS, которые являются автономными, но участвуют в объединении, чтобы обеспечить частичное и контролируемое совместное использование своих данных.

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

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

Множественные DBS, конкретным типом которых являются FDBS, можно охарактеризовать по трем параметрам: распределение, неоднородность и автономность. Другая характеристика может быть основана на измерении сети, например, отдельные базы данных или несколько баз данных в LAN или WAN .

Распространение [ править ]

Распределение данных в FDBS происходит из-за существования нескольких DBS до построения FDBS. Данные могут быть распределены между несколькими базами данных, которые могут храниться на одном или нескольких компьютерах. Эти компьютеры могут быть географически расположены в разных местах, но связаны между собой сетью. Преимущества распределения данных помогают повысить доступность и надежность, а также сократить время доступа.

Неоднородность [ править ]

Основная статья: Гетерогенная система баз данных

Неоднородности в базах данных возникают из-за таких факторов, как различия в структурах, семантике данных, поддерживаемых ограничениях или языке запросов . Различия в структуре возникают, когда две модели данных предоставляют разные примитивы, такие как объектно-ориентированные (OO) модели, которые поддерживают специализацию и наследование, и реляционные модели, которые этого не делают. Различия из-за ограничений возникают, когда две модели поддерживают два разных ограничения. Например, тип набора в схеме CODASYL может быть частично смоделирован как ограничение ссылочной целостности в схеме взаимосвязи. КОДАСИЛподдерживает вставку и сохранение, которые не фиксируются только ссылочной целостностью. Язык запросов, поддерживаемый одной СУБД, также может способствовать неоднородности других компонентных СУБД . Например, различия в языках запросов с одинаковыми моделями данных или разными версиями языков запросов могут способствовать неоднородности .

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

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

При создании объединенной схемы необходимо устранить такие неоднородности перед интеграцией компонентных схем БД.

Сопоставление схемы, сопоставление схемы [ править ]

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

  1. Global as View (GaV): глобальная схема определяется в терминах базовых схем.
  2. Local as View (LaV): локальные схемы определены в терминах глобальной схемы.

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

Автономия [ править ]

Принципиальным отличием MDBS от FDBS является концепция автономии. Важно понимать аспекты автономности компонентных баз данных и то, как они могут быть решены, когда компонентная DBS участвует в FDBS. Рассматриваются четыре типа автономий:

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

Неоднородности в FDBS в первую очередь связаны с автономностью конструкции.

  • Под автономностью связи понимается общая работа СУБД по взаимодействию с другими СУБД или без нее .
  • Автономность выполнения позволяет компонентной СУБД контролировать операции, запрашиваемые локальными и внешними операциями.
  • Автономия ассоциации дает возможность компонентной DBS отделиться от федерации, что означает, что FDBS может работать независимо от любой отдельной DBS .

Исследовательская группа ANSI / X3 / SPARC представила трехуровневую архитектуру описания данных, компонентами которой являются концептуальная схема, внутренняя схема и внешняя схема баз данных. Однако трехуровневая архитектура неадекватна для описания архитектур FDBS. Поэтому он был расширен для поддержки трех измерений FDBS, а именно распределения, автономии и неоднородности. Пятиуровневая архитектура схемы поясняется ниже.

Управление параллелизмом [ править ]

Требования гетерогенности и автономности создают особые проблемы, касающиеся управления параллелизмом в FDBS, что имеет решающее значение для правильного выполнения параллельных транзакций (см. Также Глобальный контроль параллелизма ). Достижение глобальной сериализуемости , основного критерия корректности, в соответствии с этими требованиями было охарактеризовано как очень сложное и нерешенное. [2] Упорядочивание по обязательствам , введенное в 1991 году, предоставило общее решение этой проблемы (см. Глобальную сериализуемость ; см. Упорядочивание по обязательствам также для архитектурных аспектов решения).

Пятиуровневая архитектура схемы для FDBS [ править ]

Пятиуровневая архитектура схемы включает следующее:

  • Локальная схема - это в основном концептуальная модель базы данных компонентов, выраженная в собственной модели данных. [3]
  • Схема компонентов - это подмножество локальной схемы, которой организация-владелец желает поделиться с другими пользователями FDBS, и она преобразуется в общую модель данных. [3]
  • Схема экспорта представляет собой подмножество схемы компонентов, доступной определенной федерации. [3] Он может включать информацию об управлении доступом, касающуюся его использования конкретным пользователем федерации. Схема экспорта помогает в управлении потоком данных.
  • Федеративная схема - это интеграция нескольких схем экспорта. Он включает информацию о распределении данных, которая создается при интеграции схем экспорта. [3]
  • Внешняя схема извлекается из федеративной схемы и определяется для пользователей / приложений конкретной федерации. [3]

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

См. Также [ править ]

  • Интеграция корпоративной информации (EII)
  • Виртуализация данных
  • Управление основными данными (MDM)
  • Соответствие схемы
  • Предположение об универсальной связи
  • Связанные данные
  • SPARQL

Ссылки [ править ]

  1. ^ a b c « МакЛеод и Хаймбигнер (1985). « Федеративная архитектура для управления информацией » . Транзакции ACM по информационным системам, том 3, выпуск 3, стр. 253–278.
  2. ^ a b c « Шет и Ларсон (1990). « Системы федеративных баз данных для управления распределенными, гетерогенными и автономными базами данных » . ACM Computing Surveys, Vol. 22, No. 3, pp. 183–236.
  3. ^ a b c d e Масуд, Найер; Иглстоун, Барри (декабрь 2003 г.). «Компонентные и федеративные концептуальные модели в системе федеративных баз данных» (PDF) . Малазийский журнал компьютерных наук . 16 (2): 47–57. Архивировано из оригинального (PDF) 07 марта 2016 года . Проверено 3 марта 2016 .

Внешние ссылки [ править ]

  • DB2 и базы данных объединения
  • Вопросы о том, где выполнять соединение, также известное как "pushdown", и другие характеристики производительности
  • Рабочий пример объединения Oracle, Informix, DB2 и Excel
  • Фрейтас, Андре, Эдвард Карри, Жоао Габриэль Оливейра и Шон О'Риэн. 2012. «Запросы гетерогенных наборов данных в сети связанных данных: проблемы, подходы и тенденции». IEEE Internet Computing 16 (1): 24–33.
  • База данных IBM Gaian: динамическая распределенная федеративная база данных
  • Федеративная система, методы и механизмы внедрения и использования такой системы