Федеративные базы данных: Архитектура и принципы функционирования
Federated database system
Федеративная СУБД: объединение автономных баз данных в единую систему без интеграции данных. Преимущества, архитектура и отличия от полной консолидации.
Сравнивайте с английским: нажмите на абзац — оригинал откроется в окне. Кнопка EN под абзацем показывает его прямо в тексте.
Введение
Федеративная система баз данных (FDBS) — это тип системы управления метабазами данных (DBMS), которая прозрачно отображает несколько автономных систем баз данных в единую федеративную базу данных. Составляющие базы данных соединены между собой посредством компьютерной сети и могут быть географически распределены. Поскольку составляющие системы баз данных остаются автономными, федеративная система баз данных представляет собой альтернативу (иногда сложной) задаче объединения нескольких разнородных баз данных. Федеративная база данных, или виртуальная база данных, является композицией всех составляющих баз данных в федеративной системе баз данных. Федерация данных не приводит к фактической интеграции данных в составляющих разнородных базах данных. Благодаря абстракции данных, федеративные системы баз данных могут предоставлять унифицированный пользовательский интерфейс, позволяя пользователям и клиентам хранить и извлекать данные из нескольких несмежных баз данных с помощью одного запроса, даже если составляющие базы данных гетерогенны. Для этого федеративная система баз данных должна уметь разбивать запрос на подзапросы для отправки в соответствующие составляющие СУБД, после чего система должна объединять результирующие наборы подзапросов. Поскольку различные системы управления базами данных используют разные языки запросов, федеративные системы баз данных могут применять обертки к подзапросам для преобразования их в соответствующие языки запросов.
A federated database system (FDBS) is a type of meta database management system (DBMS), which transparently maps multiple autonomous database systems into a single federated database. The constituent databases are interconnected via a computer network and may be geographically decentralized. Since the constituent database systems remain autonomous, a federated database system is a contrastable alternative to the (sometimes daunting) task of merging several disparate databases. A federated database, or virtual database, is a composite of all constituent databases in a federated database system. There is no actual data integration in the constituent disparate databases as a result of data federation. Through data abstraction, federated database systems can provide a uniform user interface, enabling users and clients to store and retrieve data from multiple noncontiguous databases with a single query—even if the constituent databases are heterogeneous. To this end, a federated database system must be able to decompose the query into subqueries for submission to the relevant constituent DBMSs, after which the system must composite the result sets of the subqueries. Because various database management systems employ different query languages, federated database systems can apply wrappers to the subqueries to translate them into the appropriate query languages.
Определение
МакЛеод и Хеймбигнер одними из первых дали определение федеративной системе баз данных в середине 1980-х годов. Федеративная СУБД – это система, которая "определяет архитектуру и связывает базы данных, минимизируя централизованное управление, но поддерживая частичный обмен данными и координацию между системами баз данных". На практике федеративную базу данных определяют как совокупность взаимодействующих компонентных систем, которые являются автономными и, возможно, разнородными. Три важных компонента федеративной СУБД – это автономия, разнородность и распределенность. Компонентная схема – это подмножество локальной схемы, которым организация-владелец готова поделиться с другими пользователями федеративной СУБД, и она преобразуется в общую модель данных. Экспортная схема представляет собой подмножество компонентной схемы, доступное для конкретной федерации. Она может включать информацию об управлении доступом при использовании конкретным пользователем федерации. Экспортная схема помогает управлять потоком контроля данных. Федеративная схема – это интеграция нескольких экспортных схем. Она включает информацию о распределении данных, которая формируется при интеграции экспортных схем. Внешняя схема извлекается из федеративной схемы и определяется для пользователей/приложений конкретной федерации. Хотя вышеописанная пятиуровневая архитектура схемы точно отражает современное состояние дел в области интеграции данных, она имеет существенный недостаток – навязанный ИТ внешний вид. Современные пользователи данных требуют контроля над способом представления данных; их потребности в некоторой степени противоречат подобным подходам к интеграции данных снизу вверх.
McLeod and Heimbigner were among the first to define a federated database system in the mid 1980s. A FDBS is one which "define[s] the architecture and interconnect[s] databases that minimize central authority yet support partial sharing and coordination among database systems". practitioners define a Federated Database as a collection of cooperating component systems which are autonomous and are possibly heterogeneous. The three important components of an FDBS are autonomy, heterogeneity and distribution. Component schema is the subset of the local schema that the owner organisation is willing to share with other users of the FDBS and it is translated into a common data model. Export Schema represents a subset of a component schema that is available to a particular federation. It may include access control information regarding its use by a specific federation user. The export schema helps in managing flow of control of data. Federated Schema is an integration of multiple export schemas. It includes information on data distribution that is generated when integrating export schemas. External schema is extracted from a federated schema, and is defined for the users/applications of a particular federation. While accurately representing the state of the art in data integration, the Five Level Schema Architecture above does suffer from a major drawback, namely IT imposed look and feel. Modern data users demand control over how data is presented; their needs are somewhat in conflict with such bottom up approaches to data integration.