Однорідні і неоднорідні системи

Однорідні розподілені системи баз даних відносно прості для розуміння. Вони мають в своїй основі один продукт СУБД, звичайно з єдиною мовою баз даних (наприклад, SQL з розширеннями для управління розподіленими даними). СУБД з підтримкою однорідного розподілу є сильно зв’язаними системами, їх вбудовані засоби пошуку даних і засоби обробки запитів побудовані і оптимізовані для досягнення максимальної продуктивності і пропускної спроможності. На мал. 2.1 зображена структура типового однорідного середовища розподіленої бази даних.

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

 

Мал. 2.1. Архітектура однорідної розподіленої бази даних

 

Протилежністю до однорідних систем РоБД є, звичайно, неоднорідні розподілені системи баз даних. Неоднорідні системи включають два або більше продуктів управління даними, що істотно розрізняються (наприклад, реляційні СУБД від різних постачальників, таких, як Oracle і Digital Equipment Corp., або СУБД одного постачальника, але такі, що функціонують на різних платформах і використовують різні структури баз даних, такі, як DB2 і SQL/DS компанії IBM). На мал. 2.2 показана типова конфігурація неоднорідної розподіленої бази даних.

 

Мал. 2.2. Архітектура неоднорідної розподіленої бази даних

 

Як вже згадувалося, однорідні розподілені системи баз даних звичайно проектуються методом „зверху вниз”; неоднорідні ж, навпаки, частіше за все будуються „знизу до верху” з метою створити загальне середовище управління над інформаційними ресурсами, що існували раніше і були відокремленими.

 

2.2.2. Методи побудови розподілених баз даних „зверху вниз” і „знизу до верху”

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

Проте при проектуванні РоБД методом „зверху вниз” передбачається, що її об’єкти не будуть зосереджені в одному місці, а розподіляться по декількох обчислювальних системах (мал. 2.3). Розподіл проводиться шляхом фрагментації або тиражування.

 

Мал. 2.3. Побудова розподіленої бази даних методом „зверху вниз”

 

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

На мал. 2.4 показана горизонтальна фрагментація, коли в таблиці робляться горизонтальні „зрізи” відповідно до значення, скажімо, якого-небудь стовпця таблиці. Рядки даних про співробітників можуть розбиватися на підмножини, що відповідають філіалам. Дані про продажі фрагментуються за магазинами, де ці продажі проводилися. Фрагментація може здійснюватися також за принципом „каруселі” (round-robin), а не на основі значень даних.

Альтернативна модель фрагментації - вертикальна - означає розбиття таблиці не за рядками, а за стовпцях (мал. 2.5). У цьому випадку деяка частина інформації про кожного співробітника зберігається в одному місці, а інша частина (що відноситься до тієї ж таблиці) - в іншому.

 

Мал. 2.4. Горизонтальна фрагментація

 

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

 

Мал. 2.5. Вертикальна фрагментація

 

Тиражування (або реплікація) означає створення дублікатів даних. Реплікати - це низка різних фізичних копій деякого об’єкту бази даних (звичайно таблиці), для яких відповідно до визначених в базі даних правилами підтримується синхронізація (ідентичність) з деякою „головною копією”. Теоретично значення всіх даних в об’єктах, що тиражуються повинні автоматично і негайно синхронізуватися один з одним. В деяких системах копії використовуються виключно в режимі читання і обновляються відповідно до заданого розкладу. В інших середовищах допускається модифікація окремих значень в копіях, і ці зміни розповсюджуються відповідно до процедур планування і координації. На мал. 2.6 показані різні моделі тиражування.

Дотепер основна увага була зосереджена на підході, що передбачає побудову розподілених баз даних „зверху вниз” із застосуванням фрагментації або тиражування. Цю ідеологія можна застосовувати тільки до однорідних РоБД, для яких спочатку визначається глобальна схема, а потім проводиться розподіл об’єктів бази даних. Такий підхід є виправданий при створенні нових додатків.

 

Мал. 2.6. Моделі тиражування даних

 

Набагато вірогідніше, що доведеться вирішувати задачу створення інтегрованого середовища шляхом об’єднання існуючих баз даних і відповідних інформаційних менеджерів, можливо, на додаток до деяких компонентів баз даних, що проектуються наново. В цьому випадку розробники не можуть дозволити собі „розкіш” проектування „зверху вниз”. Тут доводиться вдаватися до проектування „знизу до верху”, де основною проблемою стає об’єднання схем існуючих баз даних, щоб надати як новим, так і колишнім додаткам доступ і до нових, і до старих ресурсів даних (рис 2.7). Таким чином, виникає дисципліна систем мультибаз даних. Процес створення будь-якої форми мультибази даних завжди нетривіальний. Серед багатьох складних технічних проблем, які доводиться при цьому вирішувати, слід відзначити наступні:

- взаємне відображення різних моделей даних (тобто наявність деякого способу глобального доступу до низки форм представлення даних: плоских файлів, ієрархічних, реляційних, об’єктно-орієнтованих баз даних);

- управління метаданими;

- розв’язання невідповідностей імпедансу (таких, як різні представлення деякого типу об’єкту даних в різних базах даних, коли, припустимо, елемент MOVIE_TYPE - тип фільму - в одній базі даних має числове уявлення, а в іншій - символьне).