Розподілена (федеративна) база даних є віртуальна база даних, компоненти якої фізично зберігаються в кількох реальних базах даних на декількох різних вузлах. Кожен вузол працює під управлінням власної СКБД, і кінцевий користувач будь-якого вузла може отримати доступ до даних на іншому вузлі . У федеративній базі даних поєднується ефективність доступу, так як дані в основному зберігаються там само, де й обробляються, і розширені можливості доступу до віддалених даних.

Головною причиною створення федеративних баз даних є об'єктивна розподіленість підприємств — структурна і фізична. Як правило, єдина інформаційна система підприємства створюється не «з нуля», а як об'єднання вже наявних інформаційних систем його структурних і / або територіальних підрозділів. Технологія федеративних баз даних є гарним інструментом для такої інтеграції. Таке об'єднання відбувається в рамках корпоративної (можливо навіть, локальної) інтрамережі. Коли кілька підприємств тимчасово об'єднують свої зусилля в деякому спільному проекті, потрібне об'єднання їх інформаційних систем (або їх частин) у загальну базу даних. У переважній більшості випадків вузли такої федеративної бази даних взаємодіють через глобальну мережу.

Як зазначалося вище, для кінцевого користувача розподілена база даних повинна виглядати так само, як і нерозподілена. Від творців і адміністраторів розподілених баз даних (тих, хто використовує засоби визначення даних і управління ними відповідно) потрібне знання розподілу і відповідні спеціальні дії^[1].

Особливістю федеративних баз даних є логічна інтеграція даних, коли користувач має єдиний доступ до всієї сукупності даних, проте самі дані фізично залишаються в первісному джерелі. Ця особливість є ключовою відмінністю федеративного підходу від централізованого, що використовує фізичну інтеграцію, коли дані з різнорідних джерел дублюються на загальному вузлі, до якого звертаються всі користувачами. Федеративний же підхід передбачає зберігання даних в самих джерелах, коли центральний вузол здійснює трансляцію запитів з урахуванням особливостей конкретного джерела. У випадку з обчислювальним сховищем даних, федеративна база даних є більш правильним вибором з таких причин:

• Федеративні технології менш схильні до помилок зі спотвореннями і цілісністю, тому що дані залишаються на своїх вихідних місцях.
• У федеративну архітектуру простіше додавати нові джерела, що особливо важливо в динамічно розвинутих системах.
• Федеративний підхід, на відміну від централізованого, завжди гарантує отримання актуальних даних від першоджерела, тоді як при централізованому підході копії даних в центральному вузлі можуть застарівати.

Варто відзначити, що в складних випадках, коли потрібен перетин великих масивів даних з різних джерел, федеративні бази даних повинні надавати можливість зберігати частину інформації централізовано, забезпечуючи, таким чином, гібридний підхід.^[2]

Напрямок інтегрованих чи федеративних систем неоднорідних БД і мульти-БД з’явився в зв’язку з необхідністю комплексування систем БД, заснованих на різних моделях даних і керованих різними СУБД.

Основною задачею інтеграції неоднорідних БД є надання користувачам інтегрованої системи глобальної схеми БД, представленої в деякій моделі даних, і автоматичне перетворення операторів маніпулювання БД глобального рівня в оператори, зрозумілі відповідним локальним СУБД. У теоретичному плані проблеми перетворення вирішені.

При строгій інтеграції неоднорідних БД локальні системи БД утрачають свою автономність. Після включення локальної БД у федеративну систему всі подальші дії з нею, включаючи адміністрування, повинні вестися на глобальному рівні. Оскільки користувачі часто не погоджуються втрачати локальну автономність, бажаючи проте мати можливість працювати з усіма локальними СУБД однією мовою і формулювати запити з одночасною вказівкою різних локальних БД, розвивається напрямок мульти-БД. У системах мульти-БД не підтримується глобальна схема інтегрованої БД і застосовуються спеціальні способи іменування для доступу до об’єктів локальних БД. Як правило, у таких системах на глобальному рівні допускається тільки вибірка даних. Це дозволяє зберегти автономність локальних БД.^[3]

В силу гетерогенності і розподіленості джерел даних в сховищі даних, управління єдиного інформаційного середовища є складним завданням. Джерелами даних можуть бути реляційні СКБД, бізнес-додатки, плоскі файли, вебсервіси і т. д. Кожен з них має власний формат зберігання даних, виклики і спосіб видачі результатів. Крім того, джерела можуть розташовуватися на значній відстані один від одного, в різних мережах з різними протоколами доступу.

Програмне забезпечення, яке здійснює управління федеральної базою даних, в обов'язковому порядку повинно відповідати наступним вимогам:

Доступ до даних федеративної БД здійснюється через центральний вузол, що приховує від користувачів розташування даних і особливості взаємодії з їх джерелом. Таким чином, користувачі можуть здійснювати SQL-запити до даних, які насправді є нереляціонні, або розташовуються у зовнішній СКБД, що не підтримує синтаксис цих запитів.

Джерела даних в обчислювальному сховищі даних можуть мати найрізноманітнішу структуру і способи доступу, наприклад:

• Текстові файли з табличною структурою
• СКБД сімейства Oracle, DB2, Sybase, Informix, Microsoft SQL Server, MySQL і т. д.
• Вебсервіси
• Джерела даних XML
• Файли Microsoft Excel
• Джерела даних ODBC, OLE DB і багато інших

Завдання центрального вузла полягає в забезпеченні доступу до всіх джерел з урахуванням вимог до прозорості, продуктивності і безпеки.

Під розширенням мається на увазі можливість створення засобів для підключення нових джерел даних до федеративної БД. Це можуть бути будь-які джерела структурованої інформації.

Для забезпечення розширення програмні засоби федеративної БД повинні підтримувати стандарт ANSISQL / MED-ManagementofExternalData (управління зовнішніми даними). Даний стандарт реалізує розширення SQL, що дозволяє реляційним СКБД звертатися до зовнішніх даних і управляти ними.

Зовнішні джерела можуть надавати набір функціональності по обробці даних, що не підтримується в СКБД центрального вузла. В цьому випадку, програмне забезпечення федеративної БД має коректно транслювати запит до даної функціональності на джерело даних, надаючи йому можливість виконати ці дії самостійно.

У деяких випадках може виявитися необхідним створення так званих наскрізних сесій. В цьому випадку всі запити будуть відразу передаватися на джерело даних без будь-якої обробки на центральному вузлі.

У даної вимоги є і зворотна сторона, яка називається компенсацією функціональності. У тому випадку, якщо фрагмент запиту містить дії, які не підтримуються безпосереднім джерелом даних, центральний сервер заміщає дані дії власної функціональністю. Все це так само здійснюється прозоро для користувачів.

Однією з головних проблем у вирішенні завдання об'єднання розподілених джерел даних є проблема забезпечення продуктивності. Інтеграційне ПЗ повинно враховувати можливості зовнішніх джерел даних, такі, як наявність індексів у таблиць реляційних СКБД, типи даних, а також доступні кількісні показники — число рядків, середня довжина рядка, число вузлових і листових елементів в індексах і т. д. Іншим важливим показником є ​​топологія мережі. Для досягнення максимальної продуктивності програмне забезпечення федеративної бази даних має вміти отримувати цю інформацію з джерел, зберігати її в системному каталозі і враховувати при складанні плану виконання розподіленого запиту.

Оскільки в федеративній БД користувач отримує доступ до всіх джерел через центральний вузол, інтеграційне програмне забезпечення має забезпечувати наскрізну авторизацію і розділяти права між користувачами на доступ до тих чи інших ресурсів. Управління доступом має здійснюватися для кожної комбінації користувач — джерело даних. Така комбінація зберігає в собі ім'я користувача на центральному вузлі, ідентифікатор зовнішнього джерела даних, а також ім'я користувача та пароль, які будуть використовуватися при доступі до цього джерела для авторизації. Якщо ім'я користувача і його пароль на центральному вузлі збігаються з віддаленим, то не повинно бути необхідності створювати таку комбінацію.

Консолідація даних в розподілених гетерогенних системах є важливим і складним завданням. З наявних підходів до вирішення цього завдання, найкращим є підхід з організацією федеративних баз даних. Створення та управління такою структурою вимагає використання спеціалізованого програмного забезпечення, яке в свою чергу має відповідати ряду вимог до прозорості, гетерогенності, безпеки, продуктивності і т. д. На ринку інтеграційного програмного забезпечення існує ряд рішень від великих виробників, заснованих на промислових реляційних СКБД, на базі яких можна організувати федеративну структуру доступу до даних. Для вибору конкретного рішення необхідно його детальний розгляд на предмет відповідності наданих можливостей вимогам до систем такого типу:

Ibm db2 Information Integrator

Дане рішення ґрунтується на СКБД IBMDB2UniversalDatabase і орієнтоване на створення розподілених систем з федеративним доступом. Підтримується велика кількість найрізноманітніших джерел даних, а також стандарт SQL/MED, що дозволяє створювати власні розширення. Особлива увага приділяється продуктивності і безпеці платформи, а також зручності у використанні і управлінні.

Microsoft SQL Server

Інтеграція СКБД Microsoft SQL Server з зовнішніми джерелами здійснюється за допомогою використання служб Microsoft Integration Services — платформи для побудови рішень по інтеграції і перетворення даних на рівні підприємства. Служби Integration Services можуть витягувати і перетворювати дані з різних джерел, таких як файли XML, плоскі файли, реляційні СКБД і т. д. Існує можливість використання графічних інструментів Integration Services для створення готових рішень або самостійного створення об'єктної моделі служб Integration Services за допомогою доданих програмних засобів.

Oracle Streams

Інтеграційні рішення Oracle початково спрямовані на реалізацію підходу з централізованим доступом, однак, технологія Oracle Streams Transparent Gateways надає кошти для реалізації моделі з федеративним доступом. Зовнішні джерела даних можна зареєструвати в СКБД Oracle у вигляді посилань, названих DB-links, і використовувати дані з цих джерел в розподілених запитах. Підтримується доступ до плоских файлів, XML-файлів, джерелам ODBC і т. д.

Створення системи надання ресурсів з використанням технології обчислень сховища даних на базі наявних ресурсів підприємства раціонально розбити на три основних етапи: аналіз наявних ресурсів підприємства, потужності яких можна об'єднати в обчислювальне сховище даних; створення прототипу середовища обчислень сховища даних на малій підмножині наявних ресурсів; розгортання прототипу в повному масштабі на всіх ресурсах.

1. Аналіз наявних ресурсів організації

   Одна з переваг моделі обчислень сховища даних в тому, що вона дозволяє ефективно використовувати потужності наявних ресурсів шляхом їх віртуалізації і подальшого надання віртуалізованих ресурсів користувачам на їх вимоги. Таким чином, першим необхідним етапом є дослідження парку наявних ресурсів, потужності яких можуть бути віртуалізовані. Віртуалізації передує консолідація: ІТ-сервіси централізуються, збираються в одному місці, після чого на цій базі можна будувати віртуалізовані інфраструктури. Консолідація істотно зменшує вартість вилучених робочих місць, підвищує якість обслуговування користувачів, знижує вартість володіння інформаційним полем компанії.

2. Створення прототипу середовища обчислень сховища даних

   На даному етапі відбувається створення середовища обчислень сховища даних в малому масштабі, проводиться настройка і налагодження функціональності. Починається процес консолідації ресурсів. В даному випадку мається на увазі використання 4-5 консолідованих регіональних центрів обробки даних, що надають частину своїх ресурсів для віртуалізації і організації доступу через обчислювальне сховище даних.

3. Розгортання прототипу в повному масштабі

   Створений на попередньому етапі прототип переноситься на виділені ресурси в повному масштабі. Організовується система єдиного доступу до ресурсів, розподілених у рамках регіональних центрів. Розподілена система регіональних центрів функціонує в рамках єдиного середовища обчислювального сховища даних, що надає доступ до віртуалізованих ресурсів.^[2]

Ця стаття має кілька недоліків. Будь ласка, допоможіть удосконалити її або обговоріть ці проблеми на сторінці обговорення. Ця стаття є сирим перекладом з російської мови. Можливо, вона створена за допомогою машинного перекладу або перекладачем, який недостатньо володіє обома мовами. Будь ласка, допоможіть поліпшити переклад. (квітень 2018) Ця стаття потребує додаткових посилань на джерела для поліпшення її перевірності. Будь ласка, допоможіть удосконалити цю статтю, додавши посилання на надійні (авторитетні) джерела. Зверніться на сторінку обговорення за поясненнями та допоможіть виправити недоліки. Матеріал без джерел може бути піддано сумніву та вилучено. (квітень 2018)