ю. При цьому змінювати структуру бази даних можна тільки в головній репліці. Ці зміни структури даних тиражуються на основі принципу відкладених оновлень, тобто через спеціальну синхронізацію реплік.
Частковість відступи від принципу відсутності центральної установки полягає в тому, що на відміну від чисто централізованих систем, вихід з ладу головної репліки не тягне відразу загибель всієї розподіленої системи, так як інші репліки продовжують функціонувати автономно. Більше того, на практиці СУБД, що підтримують технологію реплицирования, дозволяють користувачеві з певними повноваженнями (адміністратору системи) перетворити будь-яку репліку в головну і тим самим повністю відновити працездатність всієї системи.
Технології реплікації даних в тих випадках, коли не потрібно забезпечувати великі потоки та інтенсивність оновлюваних в інформаційній мережі даних, є економічним рішенням проблеми створення розподілених інформаційних систем з елементами централізації в порівнянні з використанням дорогих клієнт-серверних систем.
На практиці для спільної колективної обробки даних застосовуються змішані технології, що включають елементи об'єктного скріплення даних, реплікацій і клієнт-серверних рішень. При цьому додатково до проблеми логічного проектування, т. Е. Проектування логічної схеми організації даних (таблиці, поля, ключі, зв'язку, обмеження цілісності), додається не менш складна проблема транспортно-технологічного проектування інформаційних потоків, розмежування доступу і т. Д. До жаль, поки не опрацьовані теоретико-методологічні та інструментальні підходи для автоматизації проектування розподілених інформаційних систем з урахуванням факторів як логіки, так і інформаційно-технологічної інфраструктури предметної області.
Проте, розвиток і все більш широке поширення розподілених інформаційних систем, обумовлене самою розподіленої природою інформаційних потоків і технологій, є основною перспективою розвитку автоматизованих інформаційних систем.
Для виявлення (розпізнавання) тупиків в реплікованих системах застосовуються такі ж алгоритми, які були розроблені в моніторах транзакцій централізованих систем «Клієнт-сервер», - будується і підтримується аналогічний граф очікування транзакцій і застосовуються аналогічні алгоритми розпізнавання і руйнування тупиків, засновані в основному на техніці пріоритетів.
У цілому ряді предметних областей розподілених інформаційних систем режим реального часу з погляду безперервності узгодження даних не потрібно. Такі системи автоматизують ті організаційно-технологічні структури, в яких інформаційні процеси не настільки динамічні. Якщо взяти, наприклад, автоматизовану інформаційну систему документообігу, то традиційна «швидкість» переміщення і руху службових документів відповідає робочому дню або в кращому випадку робочим годинах. У цьому випадку оновлення реплік розподіленої інформаційної системи, якщо вона буде побудована на технології реплицирования, потрібно, скажімо, тільки лише один раз за кожен робочий час, або за кожен робочий день.
Такого роду інформаційні системи можна будувати на основі принципу відкладених оновлень. Накопичені в якій-небудь репліці зміни даних спеціальної командою користувача направляються для поновлення всіх інших реплік систем. Така операція називається синхронізацією реплік. Можливість конфліктів і тупиків в цьому випадку при синхронізації реплік істотно знижується, а нечисленні подібні конфліктні ситуації легко вирішити організаційними заходами [11].
Рішення другої проблеми узгодженості даних, а саме - узгодженості структури даних, здійснюється через часткове відступ, Як і в системах «Клієнт-сервер», від принципу відсутності центральної установки і грунтується на техніці «головною» репліки.
Суть цієї техніки полягає в тому, що одна з реплік бази даних системи оголошується головною. При цьому змінювати структуру бази даних можна тільки в головній репліці. Ці зміни структури даних тиражуються на основі принципу відкладених оновлень, т. Е. Через спеціальну синхронізацію реплік. Частковість відступи від принципу відсутності центральної установки полягає в тому, що на відміну від чисто централізованих систем, вихід з ладу головної репліки не тягне відразу загибель всієї розподіленої системи, так як інші репліки продовжують функціонувати автономно. Більше того, на практиці СУБД, що підтримують технологію реплицирования, дозволяють користувачеві з певними повноваженнями (адміністратору системи) перетворити будь-яку репліку в головну і тим самим повністю відновити працездатність всієї системи.
Процес синхронізації реплік в сучасних СУБД включає обмін тільки тими даними, які були змінені або додані в різних репліках. З цією метою в системному каталозі бази даних створюються спеціальні т...
