Проектування баз даних
46


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

Існує багато альтернатив обробки даних у мережі. Є дві технології, які використовуються при обробці в мережі: клієнт — сервер і файл — сервер. В обох цих технологіях розподілена база даних зберігається на сервері, а з клі­єнтських машин здійснюють доступ до даних, які зберігаються на сервері.

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

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

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

Розподілені системи, які підтримують архітектуру клієнт — сервер, можна ще визначити як системи типу: багато-клієнтів/одіїн-сервер чи бигато-клієнтів/багато-серверів. У системах першого типу управління базою даних централізоване і виконується досить просто, оскільки вся база збері­гається на одному сервері. У таких системах управління доступом до даних клієнтів зводиться до управління процесами блокування та управління бу­ферами клієнтів.

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

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

6.4. УПРАВЛІННЯ ОДНОЧАСНИМ ДОСТУПОМ ДО ДАНИХ

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

Під час роботи в мережі можуть виникнути проблеми з розподілом дос­тупу до даних кількох користувачів. Наприклад, при паралельному внесенні змін в один і той самий запис один користувач може стерти зміни іншого ко­ристувача. Для вирішення колізій такого плану і забезпечення функціонуван­ня бази даних у таких випадках використовується блокування чи інакше — накладання замків (захватів). Блокування виконуються за правилами сумісно­сті блокувань, що виключає виникнення конфліктів типу читання — запис, запис — читання чи запис — запис. Існують три методи блокування: гіентра-лізоване блокування, блокування первинної копії і розподілене блокування [16.]. При і/ентралізованому блокуванні для всієї розподіленої бази даних під­тримується єдина таблиця блокувань, яка розміщується на одному з вузлів під управлінням єдиного менеджера блокувань. Менеджер блокувань відповідає за встановлення та зняття захватів від імені всіх транзакцій. Оскільки управ­ління блокуванням зосереджено на одному з вузлів, то воно аналогічно цент­ралізованому управлінню одночасним доступом до даних. Такий підхід має певні проблеми при його функціонуванні. По-перше, недостатню надійність, яка при відмові чи недоступності центрального вузла блокувань може призве­сти до виходу з ладу всієї системи. По-друге, центральний вузол може стати вузьким місцем у системі через великі обсяги обробки даних на ньому і через генерованість навколо нього інтенсивного графіка мережі.

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

Розподілене (деііенралізоване) блокування пропонує розподілити обов'язки з управління блокуванням між усіма вузлами системи. Під час блокування згідно з цим механізмом необхідна координація взаємодій ме­неджерів блокувань кількох вузлів. Цей підхід до блокування усуває недо­ліки централізованого блокування, пов'язані з перевантаженням централі­зованого вузла, проте він складніший і характеризується більш високими комунікаційними витратами. Цей алгоритм використовується в системах System R і NonStop SQL.

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