Система федеративных баз данных ( FDBS ) — это тип метасистемы управления базами данных (СУБД), которая прозрачно отображает несколько автономных систем баз данных в одну федеративную базу данных . Составные базы данных связаны между собой через компьютерную сеть и могут быть географически децентрализованы. Поскольку составные системы баз данных остаются автономными, система федеративных баз данных является контрастной альтернативой (иногда пугающей) задаче слияния нескольких разнородных баз данных. Федеративная база данных, или виртуальная база данных , представляет собой совокупность всех составных баз данных в системе федеративных баз данных. В результате федерации данных фактическая интеграция данных в составных разнородных базах данных отсутствует.
Благодаря абстракции данных федеративные системы баз данных могут предоставлять единый пользовательский интерфейс , позволяющий пользователям и клиентам хранить и извлекать данные из нескольких несмежных баз данных с помощью одного запроса — даже если составляющие базы данных являются неоднородными . Для этого федеративная система баз данных должна иметь возможность разлагать запрос на подзапросы для отправки в соответствующие составляющие СУБД , после чего система должна составлять наборы результатов подзапросов. Поскольку различные системы управления базами данных используют разные языки запросов , федеративные системы баз данных могут применять оболочки к подзапросам для их перевода на соответствующие языки запросов .
Маклеод и Хаймбигнер [1] были одними из первых, кто определил систему федеративной базы данных в середине 1980-х годов.
FDBS — это та, которая «определяет архитектуру и взаимодействует с базами данных, которые минимизируют центральные полномочия, но при этом поддерживают частичное совместное использование и координацию между системами баз данных». [1] Это описание может неточно отражать определение федеративной базы данных Маклеода/Хаймбигнера [1] . Скорее, это описание соответствует тому, что Маклеод/Хаймбигнер назвал составной базой данных. Федеративная база данных Маклеода/Хаймбигнера представляет собой набор автономных компонентов, которые делают свои данные доступными другим членам федерации посредством публикации экспортной схемы и операций доступа; не существует единой центральной схемы, которая охватывает информацию, доступную от членов федерации.
В других исследованиях [2] специалисты определяют федеративную базу данных как совокупность взаимодействующих компонентных систем, которые являются автономными и, возможно, неоднородными .
Тремя важными компонентами FDBS являются автономность, гетерогенность и распределение. [2] Другим измерением, которое также рассматривалось, является сетевая среда компьютерной сети , например, множество DBS в локальной сети или множество DBS в глобальной сети, обновляющие функции, связанные с участвующими DBS (например, отсутствие обновлений, неатомарные переходы, атомарные обновления ).
СУБД можно классифицировать как централизованную или распределенную. Централизованная система управляет одной базой данных, в то время как распределенная управляет несколькими базами данных. Компонентная СУБД в СУБД может быть централизованной или распределенной. Множественная СУБД (MDBS) может быть классифицирована на два типа в зависимости от автономности компонентной СУБД как федеративная и нефедеративная. Нефедеративная система баз данных представляет собой интеграцию компонентных СУБД , которые не являются автономными. Федеративная система баз данных состоит из компонентных СУБД , которые являются автономными, но участвуют в федерации, что позволяет частично и контролируемо совместно использовать их данные.
Федеративные архитектуры различаются по уровням интеграции с компонентными системами баз данных и по объему услуг, предлагаемых федерацией. FDBS можно разделить на категории слабо или тесно связанных систем.
Несколько DBS, из которых FDBS являются определенным типом, можно охарактеризовать по трем измерениям: Распределение, Гетерогенность и Автономность. Другая характеристика может быть основана на измерении сети, например, отдельные базы данных или несколько баз данных в локальной или глобальной сети.
Распределение данных в FDBS обусловлено существованием нескольких DBS до того, как будет построена FDBS. Данные могут быть распределены между несколькими базами данных, которые могут храниться на одном компьютере или нескольких компьютерах. Эти компьютеры могут быть географически расположены в разных местах, но связаны между собой сетью. Преимущества распределения данных помогают повысить доступность и надежность, а также сократить время доступа.
Неоднородности в базах данных возникают из-за таких факторов, как различия в структурах, семантике данных, поддерживаемых ограничениях или языке запросов . Различия в структуре возникают, когда две модели данных предоставляют разные примитивы, такие как объектно-ориентированные (OO) модели , которые поддерживают специализацию и наследование, и реляционные модели , которые этого не делают. Различия из-за ограничений возникают, когда две модели поддерживают два разных ограничения. Например, тип множества в схеме CODASYL может быть частично смоделирован как ограничение ссылочной целостности в схеме отношений. CODASYL поддерживает вставку и сохранение, которые не охватываются только ссылочной целостностью. Язык запросов, поддерживаемый одной СУБД, также может способствовать неоднородности между другими компонентами СУБД . Например, различия в языках запросов с одинаковыми моделями данных или разными версиями языков запросов могут способствовать неоднородности .
Семантические неоднородности возникают, когда есть разногласия относительно значения, интерпретации или предполагаемого использования данных . На уровне схемы и данных классификация возможных неоднородностей включает:
При создании федеративной схемы необходимо устранить такие неоднородности перед интеграцией компонентных схем БД.
Работа с несовместимыми типами данных или синтаксисом запросов — не единственное препятствие для конкретной реализации FDBS. В системах, которые не планируются сверху вниз, общая проблема заключается в сопоставлении семантически эквивалентных , но по-разному названных частей из разных схем (=моделей данных) (таблиц, атрибутов). Попарное сопоставление между n атрибутами приведет к правилам сопоставления (при заданных сопоставлениях эквивалентности) — число, которое быстро становится слишком большим для практических целей. Обычным выходом является предоставление глобальной схемы, которая включает соответствующие части всех схем-членов и предоставление сопоставлений в форме представлений базы данных . Два основных подхода зависят от направления сопоставления:
Оба примера являются примерами интеграции данных , называемой проблемой сопоставления схем .
Основополагающим для разницы между MDBS и FDBS является концепция автономии. Важно понимать аспекты автономии для компонентных баз данных и то, как их можно решать, когда компонентная DBS участвует в FDBS. Существует четыре типа автономий:
Неоднородности в FDBS обусловлены в первую очередь автономностью проектирования.
Исследовательская группа ANSI/X3/SPARC разработала трехуровневую архитектуру описания данных, компонентами которой являются концептуальная схема, внутренняя схема и внешняя схема баз данных. Однако трехуровневая архитектура недостаточна для описания архитектур FDBS. Поэтому она была расширена для поддержки трех измерений FDBS, а именно: распределения, автономии и гетерогенности. Ниже поясняется пятиуровневая архитектура схемы.
Требования гетерогенности и автономности создают особые проблемы, касающиеся управления параллелизмом в FDBS, что имеет решающее значение для правильного выполнения его параллельных транзакций ( см. также Глобальный контроль параллелизма ). Достижение глобальной сериализуемости , основного критерия корректности, в рамках этих требований было охарактеризовано как очень сложное и нерешенное. [2]
Пятиуровневая архитектура схемы включает в себя следующее:
Хотя пятиуровневая архитектура схемы, представленная выше, точно отражает современное состояние интеграции данных, она страдает от серьезного недостатка, а именно, от внешнего вида и ощущений, навязанных ИТ. Современные пользователи данных требуют контроля над тем, как представляются данные; их потребности в некоторой степени противоречат таким подходам снизу вверх к интеграции данных.
