Система федеративных баз данных
Эта статья нуждается в дополнительных цитатах для проверки . ( ноябрь 2023 г. ) |
Система федеративных баз данных ( FDBS ) — это тип метабазами системы управления данных (СУБД), которая прозрачно отображает несколько автономных систем баз данных в одну федеративную базу данных . Составляющие базы данных связаны между собой компьютерной сетью и могут быть географически децентрализованы. Поскольку составляющие системы баз данных остаются автономными, объединенная система баз данных является контрастной альтернативой (иногда сложной) задаче слияния нескольких разрозненных баз данных. Объединенная база данных, или виртуальная база данных , представляет собой совокупность всех баз данных, составляющих систему объединенных баз данных. В результате объединения данных в составных разрозненных базах данных не происходит фактической интеграции данных.
Посредством абстракции данных системы федеративных баз данных могут обеспечить единый пользовательский интерфейс , позволяющий пользователям и клиентам хранить и извлекать данные из нескольких несмежных баз данных с помощью одного запроса , даже если составляющие базы данных неоднородны . С этой целью система объединенных баз данных должна иметь возможность разлагать запрос на подзапросы для отправки в соответствующие составляющие СУБД , после чего система должна составлять наборы результатов подзапросов. Поскольку различные системы управления базами данных используют разные языки запросов , системы объединенных баз данных могут применять к подзапросам оболочки для их перевода на соответствующие языки запросов .
Определение
[ редактировать ]Маклеод и Хаймбигнер [1] были одними из первых, кто в середине 1980-х годов определил систему федеративных баз данных.
FDBS - это система, которая «определяет архитектуру и соединяет базы данных, которые сводят к минимуму центральные полномочия, но поддерживают частичное совместное использование и координацию между системами баз данных». [1] Это описание может не совсем точно отражать точку зрения Маклеода/Хеймбигнера. [1] определение объединенной базы данных. Скорее, это описание соответствует тому, что Маклеод/Хеймбигнер назвал составной базой данных. Объединенная база данных Маклеода/Хеймбигнера представляет собой набор автономных компонентов, которые делают свои данные доступными для других членов федерации посредством публикации схемы экспорта и операций доступа; не существует единой центральной схемы, охватывающей информацию, доступную от членов федерации.
Среди других опросов, [2] Специалисты-практики определяют объединенную базу данных как совокупность взаимодействующих компонентных систем, которые являются автономными и, возможно, гетерогенными .
Тремя важными компонентами FDBS являются автономия, неоднородность и распределение. [2] Другим измерением, которое также рассматривалось, является сетевая среда, компьютерная сеть , например, множество DBS по локальной сети или множество DBS по глобальной сети, связанные с обновлением функций участвующих DBS (например, отсутствие обновлений, неатомарные переходы, атомарные обновления ).
Архитектура ФДБС
[ редактировать ]СУБД . можно разделить на централизованную и распределенную Централизованная система управляет одной базой данных, а распределенная — несколькими базами данных. Компонентная СУБД в СУБД может быть централизованной или распределенной. Множественные DBS (MDBS) можно разделить на два типа в зависимости от автономности компонента DBS: федеративные и нефедеративные. Нефедеративная система баз данных представляет собой интеграцию компонентов СУБД , которые не являются автономными.Система федеративных баз данных состоит из компонентов DBS , которые являются автономными, но при этом участвуют в федерации, что позволяет осуществлять частичное и контролируемое совместное использование своих данных.
Федеративные архитектуры различаются в зависимости от уровней интеграции с компонентными системами баз данных и объема услуг, предлагаемых федерацией. FDBS можно разделить на слабо и тесно связанные системы.
- Слабосвязанные базы данных требуют, чтобы компоненты баз данных создавали свою собственную объединенную схему . Пользователь обычно обращается к другим компонентным системам баз данных, используя язык мультибазы данных, но это устраняет любые уровни прозрачности местоположения, вынуждая пользователя иметь непосредственное знание объединенной схемы. Пользователь импортирует необходимые ему данные из других баз данных компонентов и интегрирует их со своими собственными, чтобы сформировать объединенную схему.
- Тесно связанная система состоит из систем-компонентов, которые используют независимые процессы для создания и публикации интегрированной федеративной схемы.
Множественные DBS, особым типом которых являются FDBS, можно охарактеризовать по трем измерениям: распределение, неоднородность и автономия. Другая характеристика может быть основана на измерении сети, например, одной базы данных или нескольких баз данных в локальной или глобальной сети.
Распределение
[ редактировать ]Распределение данных в FDBS происходит из-за существования нескольких DBS до создания FDBS. Данные могут быть распределены по нескольким базам данных, которые могут храниться на одном или нескольких компьютерах. Эти компьютеры могут быть географически расположены в разных местах, но связаны между собой сетью. Преимущества распределения данных помогают повысить доступность и надежность, а также сократить время доступа.
Неоднородность
[ редактировать ]Неоднородности в базах данных возникают из-за таких факторов, как различия в структурах, семантике данных, поддерживаемых ограничениях или языке запросов . Различия в структуре возникают, когда две модели данных предоставляют разные примитивы, например объектно-ориентированные (ОО) модели , поддерживающие специализацию и наследование, и реляционные модели , которые этого не делают. Различия из-за ограничений возникают, когда две модели поддерживают два разных ограничения. Например, тип набора в CODASYL схеме может быть частично смоделирован как ограничение ссылочной целостности в схеме отношений. CODASYL поддерживает вставку и сохранение, которые не фиксируются только ссылочной целостностью. Язык запросов, поддерживаемый одной СУБД, также может способствовать гетерогенности между другими компонентами СУБД . Например, различия в языках запросов с одинаковыми моделями данных или разные версии языков запросов могут способствовать гетерогенности .
Семантическая неоднородность возникает, когда возникают разногласия по поводу значения, интерпретации или предполагаемого использования данных . На уровне схемы и данных классификация возможных неоднородностей включает в себя:
- Конфликты именования, например, базы данных используют разные имена для представления одной и той же концепции.
- Конфликты предметной области или данных конфликты представления , например, базы данных используют разные значения для представления одной и той же концепции.
- Конфликты точности, например, базы данных , использующие одни и те же значения данных из доменов разной мощности для одних и тех же данных .
- Конфликты метаданных , например, одни и те же понятия представлены на уровне схемы и уровне экземпляра.
- данных Конфликты , например, отсутствующие атрибуты.
- Конфликты схем , например конфликт таблиц и таблиц, который включает конфликты имен, конфликты данных и т. д.
При создании объединенной схемы необходимо устранить такие неоднородности, прежде чем интегрировать схемы компонентов БД.
Сопоставление схем, сопоставление схем
[ редактировать ]Работа с несовместимыми типами данных или синтаксисом запросов — не единственное препятствие на пути конкретной реализации FDBS. В системах, которые не планируются сверху вниз, общая проблема заключается в сопоставлении семантически эквивалентных , но по-разному названных частей из разных схем (= моделей данных) (таблиц, атрибутов). Попарное сопоставление n атрибутов приведет к правила сопоставления (с учетом сопоставлений эквивалентности) — число, которое быстро становится слишком большим для практических целей. Распространенным выходом является создание глобальной схемы, которая включает в себя соответствующие части всех схем-членов и обеспечивает сопоставления в форме представлений базы данных . Два основных подхода зависят от направления отображения:
- Глобальный как вид (GaV): глобальная схема определяется с точки зрения базовых схем.
- Локальный как вид (LaV): локальные схемы определяются в терминах глобальной схемы.
Оба являются примерами интеграции данных , называемой проблемой сопоставления схем .
Автономия
[ редактировать ]Фундаментальным различием между MDBS и FDBS является концепция автономии. Важно понимать аспекты автономии компонентных баз данных и то, как их можно решить, когда компонентная DBS участвует в FDBS.Речь идет о четырех видах автономий:
- Автономия проектирования, которая означает возможность выбирать дизайн независимо от данных, языка запросов или концептуализации, функциональности реализации системы.
Неоднородности в FDBS обусловлены, прежде всего, автономностью конструкции.
- Автономия связи относится к общей работе СУБД по взаимодействию с другими СУБД или нет.
- Автономия выполнения позволяет компоненту СУБД контролировать операции, запрашиваемые локальными и внешними операциями.
- Автономия ассоциации дает компоненту DBS возможность отделиться от федерации, что означает, что FDBS может работать независимо от любой отдельной DBS .
Исследовательская группа ANSI/X3/SPARC разработала трехуровневую архитектуру описания данных, компонентами которой являются концептуальная схема, внутренняя схема и внешняя схема баз данных. Однако трехуровневая архитектура недостаточна для описания архитектуры FDBS. Поэтому он был расширен для поддержки трех измерений FDBS, а именно: распределения, автономии и гетерогенности. Ниже описана пятиуровневая архитектура схемы.
Управление параллелизмом
[ редактировать ]Требования гетерогенности Глобальное и автономности создают особые проблемы, касающиеся управления параллелизмом в FDBS, что имеет решающее значение для правильного выполнения параллельных транзакций (см. также управление параллелизмом ). Достижение глобальной сериализуемости , основного критерия правильности, в соответствии с этими требованиями было охарактеризовано как очень сложное и нерешенное. [2]
Пятиуровневая архитектура схемы для FDBS
[ редактировать ]Пятиуровневая архитектура схемы включает в себя следующее:
- Локальная схема — это, по сути, концептуальная модель компонентной базы данных, выраженная в собственной модели данных. [3]
- Схема компонента — это подмножество локальной схемы, которой организация-владелец готова поделиться с другими пользователями FDBS, и которая преобразуется в общую модель данных . [3]
- Схема экспорта представляет собой подмножество схемы компонента, доступное для конкретной федерации. [3] Он может включать информацию об управлении доступом, касающуюся его использования конкретным пользователем федерации. Схема экспорта помогает управлять потоком данных.
- Федеративная схема — это интеграция нескольких схем экспорта. Он включает информацию о распределении данных, которая генерируется при интеграции схем экспорта. [3]
- Внешняя схема извлекается из федеративной схемы и определяется для пользователей/приложений конкретной федерации. [3]
Точно отражая современное состояние интеграции данных, пятиуровневая архитектура схемы, описанная выше, страдает серьезным недостатком, а именно внешним видом, навязанным ИТ. Современные пользователи данных требуют контроля над тем, как представляются данные; их потребности в некоторой степени противоречат таким восходящим подходам к интеграции данных.
См. также
[ редактировать ]- Интеграция корпоративной информации (EII)
- Виртуализация данных
- Управление основными данными (MDM)
- Соответствие схемы
- Предположение об универсальном отношении
- Связанные данные
- СПАРКЛ
Ссылки
[ редактировать ]- ^ Jump up to: а б с " Маклеод и Хаймбигнер (1985). «Федеративная архитектура управления информацией» . Транзакции ACM в информационных системах, том 3, выпуск 3 . стр. 253–278.
- ^ Jump up to: а б с " Шет и Ларсон (1990). «Федеративные системы баз данных для управления распределенными, гетерогенными и автономными базами данных» . Обзоры вычислительных систем ACM, Vol. 22, №3 . стр. 183–236.
- ^ Jump up to: а б с д и Масуд, Найер; Иглстон, Барри (декабрь 2003 г.). «Концептуальные модели компонентов и федерации в системе федеративных баз данных» (PDF) . Малайзийский журнал компьютерных наук . 16 (2): 47–57. Архивировано из оригинала (PDF) 7 марта 2016 г. Проверено 3 марта 2016 г.
Внешние ссылки
[ редактировать ]- DB2 и базы данных объединения
- Проблемы с тем, где выполнять соединение, известное как «нажатие», и другие характеристики производительности.
- Рабочий пример объединения Oracle, Informix, DB2 и Excel
- Фрейтас, Андре, Эдвард Карри, Жоау Габриэль Оливейра и Шон О'Риайн. 2012. «Запрос к разнородным наборам данных в сети связанных данных: проблемы, подходы и тенденции». IEEE Интернет-вычисления 16 (1): 24–33.
- База данных IBM Gaian: динамическая распределенная федеративная база данных
- Федеративная система, методы и механизмы реализации и использования такой системы.