Склад і робота РБД

Схема РБД може бути представлена у вигляді, показаному на рис. 10.2. У ній виділяють користувацький, глобальний (концептуальний), фрагментарний (логічний) і розподілений (локальний) рівні представлення даних (рис. 10.3), що визначають мережеву СУБД [11].

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

Схема РБД

Рис. 10.2. Схема РБД

Рівні представлення даних в РБД

Рис. 10.3. Рівні представлення даних в РБД

Таблиця 10.1

Дані в РБД (глобальний рівень)

а) Службовець

N

Ім'я

Завод

Тариф

100

Іванов

1

6

101

Петров

1

6

102

Сидоров

2

10

103

Артемов

2

12

104

Пєчкін

3

5

105

Крамов

3

11

б) Завод

N

Розташування

1

С.-Петербург

2

Вологда

3

Сиктивкар

в) Сировина

N

Назва

Кількість

1

Картон

500

2

Картон

100

2

Листівки

940

3

Брошури

75

У табл. 10.1 різними шрифтами виділені фрагменти БД.

Не всі дані глобального рівня доступні конкретному користувачеві. Найбільш повні дані (користувацький, зовнішній рівень) маються на вузлі 1 головного підприємства. У вузлах (ділянках) 2, 3 дані менш повні. Так, у вузлі 3 вони мають вигляд, показаний в табл. 10.2.

Таблиця 10.2

Користувача рівень в РЕД

а) Службовець

N

Ім'я

Завод

Тариф

104

Пєчкін

3

5

105

Крамов

3

11

б) Завод

N

Розташування

1

С.-Петербург

2

Вологда

3

Сиктивкар

в) Сировина

N

Назва

Кількість

3

Брошури

75

Користувальницький рівень складається з фрагментів (наприклад, рядки 1, 2, 3 таблиця "Завод" табл. 10.1) глобального рівня, які складають фрагментарний, логічний рівень.

Виділяють горизонтальну і вертикальну фрагментації (розчленування). Горизонтальна фрагментація пов'язана з поділом даних по вузлах. Горизонтальні фрагменти нс перекриваються. Вертикальна фрагментація пов'язана з групуванням даних по задачам.

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

Таблиця 10.3

Локалізація даних

Ім'я таблиці

Розподіл фрагментів по вузлах

Службовці

1

1. 2

1. з

Завод

1, 2, 3

I, 2, 3

1, 2, 3

Сировина

1

2

3

Очевидно, що для таблиці "Завод" здійснюється дублювання, а для таблиці "Сировина" - розчленовування.

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

Схема роботи РБД

Рис. 10.4. Схема роботи РБД

Інакше кажучи, РБД можна представити у вигляді, показаному на рис. 10.3.

Мережа в РБД утворюють мережні операційні системи (наприклад, Windows NT, Novell NetWare). В якості СУБД, що спочатку призначалися для використання в мережі, слід назвати BTrieve, Oracle, InterBase, Sybase, Informix.

В силу распределенности даних особливу значимість здобуває словник даних (довідник) РБД, який на відміну від словника централізованої БД має розподілену, багаторівневу структуру.

У загальному випадку можуть бути виділені мережний, загальний зовнішній, загальний концептуальний, локальні зовнішні, локальні концептуальні та внутрішні складові словника РБД.

Природно, що для роботи в РБД необхідні адміністратори РБД і локальних БД, робочими інструментами яких є перераховані словники.

Схема роботи РБД показана на рис.

10.4.

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

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

Порівняльні характеристики стратегій зберігання наведено в табл. 10.4. На її основі може бути побудований найпростіший алгоритм вибору стратегії, наведеної на рис. 10.5.

Таблиця 10.4

Стратегії зберігання даних

Назва

Суть стратегії

Гідність

Недоліки

Централізація (у тому числі технологія клієнт- сервер)

Єдина копія в одному вузлі

Простота структури

Швидкість обробки обмежена одним вузлом

Обмежений

доступ

Мала надійність

Довготривала пам'ять визначає обсяг БД

Локалізація

(розчленування)

Єдина копія, розчленування по вузлах (повна копія БД не допускається)

Обсяг БД визначається пам'яттю мережі

Зниження вартості РБД Час відгуку при паралельній обробці зменшується

Мала чутливість до вузьких місць

Підвищена надійність при високій локалізації даних

Запит може бути по всіх вузлах

Доступ гірше, ніж при централізації

Рекомендація

застосування:

довготривала пам'ять обмежена в порівнянні з обсягом БД;

повинна бути підвищена ефективність функціонування при високому ступені локалізації

Дублювання

У кожної локальної БД повна копія

Вище надійність, доступ і ефективність вибірки, простота відновлення.

Локальна асинхронна обробка в вузлах

Отримання швидких відповідей

Обсяг БД обмежений довготривалою пам'яттю Потреба синхронізації багатьох копій Потреба у додатковій пам'яті

Слабка реалізація паралельної обробки Рекомендації застосування: фактор надійності превалює;

БД невелика; інтенсивність оновлення невисока;

інтенсивні

запити

Змішана

Кілька копій збереженого логічного фрагмента в кожному вузлі

Будь-яка ступінь надійності Велика доступність

Менше пересилань даних Паралельна обробка

Треба зберігати словники

Зростання вартості узгодження даних

Різна частота звернення вузла до різних частин БД

Втрата надійності через розчленування даних

Мала вільна довготривала пам'ять через дублювання

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

Алгоритм вибору стратегії зберігання

Рис. 10.5. Алгоритм вибору стратегії зберігання:

А - запит локален

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

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

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

Робота в архітектурі клієнт-сервер може підтримуватися і за допомогою схеми Open DataBase Connectivity (ODBC), як показано на рис. 10.7. У цьому випадку мережа утворюється шляхом з'єднання серверів. Таке з'єднання забезпечується або засобами СУБД (SQL Server) або моніторами транзакцій (TUXEDO).

Архітектура клієнт-сервер

Рис. 10.6. Архітектура клієнт-сервер

Обговоримо більш докладно варіант реалізації РБД - архітектуру клієнт-сервер.

ODBC в архітектурі клієнт-сервер

Рис. 10.7. ODBC в архітектурі клієнт-сервер

Спільно з терміном "клієнт-сервер" використовуються три поняття.

  • 1. Архітектура: йдеться про концепції побудови варіанту РБД.
  • 2. Технологія: кажуть про послідовність дій у РБД.
  • 3. Система: розглядаються сукупність елементів та їх взаємодію.

Про архітектуру клієнт-сервер говорилося раніше.

Технологія клієнт-сервер дозволяє підвищити продуктивність праці:

  • • скорочується загальний час виконання запитів за рахунок потужного сервера;
  • • зменшується частка і збільшується ефективність використання клієнтом (для обчислень) центрального процесора;
  • • зменшується обсяг використання клієнтом пам'яті "свого" комп'ютера;
  • • скорочується мережевий трафік.

До таких великомасштабним систем пред'являються такі вимоги: I) гнучкість структури; 2) надійність; 3) доступність даних; 4) легкість обслуговування системи; 5) масштабованість додатків; 6) переносимість додатків (на різні платформи); 7) багатозадачність (можливість виконання багатьох додатків).

Відзначимо, що архітектурі клієнт-сервер передувала архітектура файл-сервер, в якій можливі такі варіанти.

  • 1. На комп'ютерах-клієнтах є копія БД. Робота за таким варіантом має наступні складності: синхронізація даних різних копій в кінці роботи БД; високий трафік (потоки даних між сервером і клієнтами, оскільки передається в будь-якому випадку вміст всієї БД).
  • 2. У СУБД Access, яка спочатку створена як локальна, передбачений режим поділу бази даних. Таблиці залишаються на сервері (back-end), а решта об'єктів (запити, звіти) передаються клієнтам (front-end). У цьому випадку, як і раніше великий трафік, в силу чого при використанні файл-серверів кількість підключаються клієнтів - при їх надійній роботі - до чотирьох.

У той же час було потрібно підключення десятків і навіть сотень клієнтів [1-3]. Цього вдалося досягти в архітектурі (режимі, технології) клієнт-сервер. У цьому режимі трафік різко зменшується, оскільки по мережі передаються тільки ті дані, які відповідають запитам клієнтів [2].

Для цього довелося побудувати СУБД, спочатку призначені для роботи в мережі. Фірма Microsoft [27-29] змушена була - на додаток до СУБД Access, яка використовувалася за допомогою програми ODBC тільки для клієнтських цілей - запропонувати в якості сервера Microsoft SQL Server. Така структура виявилася великовагової і незручною, оскільки розробнику турбувалися знати вже два СУБД.

З інших пропозицій дуже вдалим виявився програмний продукт Delphi [30-36], в рамках якого можуть використовуватися СУБД dBase, Paradox, і, при окремій інсталяції, InterBase (режим клієнт-сервер). При цьому СУБД InterBase підтримується, поряд з мовою програмування SQL, потужним, зрозумілим, простим і широко поширеним мовою програмування (Object) Pascal [11], побудованим із застосуванням об'єктно-орієнтованого підходу [33].

Остання обставина дозволяє легко будувати об'єктно-реляційні бази даних (див. Гл. 9). Високий ступінь автоматизації програмування дає можливість різко спростити і знизити трудомісткість процедур створення інтерфейсу користувача, і особливо алгоритму програми.

В системі клієнт-сервер можливо виділити наступні складові: сервер, клієнт, інтерфейс між клієнтом і сервером, адміністратор.

Сервер здійснює управління спільним для безлічі клієнтів ресурсом. Він виконує наступні завдання:

  • • управляє загальної БД;
  • • здійснює доступ і захист даних, їх відновлення;
  • • забезпечує цілісність даних.

До БД на сервері пред'являються ті ж вимоги, як і до централізованої багатокористувацької БД.

Слід зазначити, що результати запитів клієнта поміщаються в робочу область пам'яті сервера, яка в ряді СУБД (наприклад, Oracle) називають "таблична область". Оскільки вона не займає багато місця, для кожного клієнта-користувача доцільно створювати свою табличну область. У цьому випадку вихідні таблиці стають для користувача недоступними, а архівація (копіювання) БД додатку клієнта спрощується.

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

  • • надає інтерфейс користувачу;
  • • управляє логікою роботи додатків;
  • • перевіряє допустимість даних;
  • • здійснює запит та одержання даних з сервера.

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

В якості СОС можуть використовуватися Windows NT, Novell NetWare. Комунікаційне програмне забезпечення дозволяє комп'ютерам взаємодіяти на мові спеціальних програм - комунікаційних протоколів.

У загальному випадку така взаємодія здійснюється за допомогою семиуровневой схеми ISO з відповідними протоколами. Для локальних мереж схема спрощується. Протоколомі для Windows NT служить Transmission Control Program / Internet Program (TCP / IP), для NetWare - Sequenced Packed eXchange / Intemet Packed eXchaned (SPX / IPX).

Різноманітність мережевих засобів робить необхідним створення стандартного проміжного програмного забезпечення клієнт-сервер, що знаходиться на сервері і клієнтах. Говорять про прикладному програмному інтерфейсі (Application Programming Interface - API). Сюди відносяться Open DataBase Connectivity (ODBC) і Integrated Database Application Programming Interface (IDAPI), використовуваний в додатку Delphi і СУБД InterBase.

Взаємодія клієнтів і сервера можна уявити собі таким чином.

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

Якщо підключення здійснено, починає працювати сервер, що виконує два види процесів: переднього розділу і фонові.

Процеси переднього розділу безпосередньо обробляють запити, фонова складова пов'язана з управлінням процесом обробки.

Робота сервера може мати такий порядок.

  • 1. Після надходження запиту диспетчер ставить його в чергу за схемою "першим прийшов - першим обслужений".
  • 2. Процес переднього розділу вибирає "найстаріший" запит і починає його обробку. Після завершення результати поміщаються в чергу для передачі клієнту.
  • 3. Диспетчер посилає результати з черги відповідному клієнту.

При обробці запиту фонові процеси виконують інші важливі операції, основними з яких є наступні:

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

Адміністратор РБД (АРБД) повинен вирішувати наступні завдання [39].

  • 1. Планування РБД і розподіл пам'яті.
  • 2. Налаштування конфігурації мережі.
  • 3. Створення РБД.
  • 4. Робота з розробниками додатків.
  • 5. Створення нових користувачів і керування повноваженнями.
  • 6. Регулярна архівація БД і виконання операцій по її відновленню.
  • 7. Управління доступом до БД за допомогою ОС і СОС, засобів захисту та доступу.

У великих системах AРБД може складатися з ряду осіб, що відповідають, наприклад, за ОС, мережа, архівацію, захист.

Таким чином, система клієнт-сервер своєрідна: з одного боку, її можна вважати різновидом централізованої багатокористувацької БД, з іншого боку, вона є окремим випадком РБД.

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

Основне обмеження для роботи такої системи - мінімальний трафік. Тому при розробці програми, крім звичайних завдань (з'ясування мети додатки, логіки обробки, виду інтерфейсу) особливу увагу слід звернути на розробку DLL- сценарію і розподіл функцій між клієнтами і сервером.

Використання для складання сценарію CASE-засобів значно скорочує трудомісткість робіт з проектування. Інакше ця процедура виконується вручну за допомогою команд мови SQL.

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

Щоб його знизити, можливо використовувати наступні рекомендації.

  • 1. Забезпечення цілісності для всіх додатків краще централізувати і здійснювати на сервері. Це дозволить не тільки скоротити трафік, але і раціонально використовувати СУРБД, поліпшивши управління цілісністю (посилальної, обмежень, тригерів) даних.
  • 2. Доцільно використовувати на сервері збережені процедури, сукупність яких можна инкапсулировать у вигляді пакету (модуля). У результаті трафік зменшиться: клієнт буде передавати тільки виклик процедури і її параметри, а сервер - результати виконання процедури.
  • 3. У ряді випадків клієнтам слід отримувати повідомлення бази даних (наприклад, завідувачу складом - про нижній рівень запасів, при якому слід виконувати нове замовлення). Якщо повідомлення виробляється по запиту клієнта, трафік збільшується. Простіше цю (збережену) процедуру розмістити на сервері, який буде автоматично повідомляти клієнта про виникнення події. У той же час клієнт при необхідності може отримувати інформацію за допомогою простих викликів процедур.

У режимі клієнт-сервер виділяють два різновиди структури: однорівневу, про яку йшла мова до цих пір, і багаторівневу (рис. 10.8).

При використанні режиму "товстого" клієнта (однорівнева структура) клієнтські програми знаходяться безпосередньо на машинах користувачів, або частково на сервері у вигляді системи збережених процедур. Складність клієнтської частини деколи вимагає її

Однорівнева -

Рис. 10.8. Однорівнева - "товстий" клієнт (а) і багаторівнева - "тонкий" клієнт (б) структури клієнт-сервер

адміністрування. Використання системи збережених процедур значною мірою знижує навантаження на мережу. При використанні "тонкого" клієнта (багаторівнева структура) додатка користувачів лежать і виконуються на окремому потужному сервері (сервері додатків, який може бути і на одному комп'ютері з сервером БД), що значною мірою знижує вимоги до користувальницькою машинам.

Так, в СУБД InterBase в однорівневої структурі в кожному клієнті є утиліта Borland Database Engine (BDE - ядро Delphi) обсягом 8 Мбайт. У багаторівневій структурі BDE-утиліта є тільки в сервері додатків, а обсяг пам'яті, займаної клієнтом, знижується до 212 кбайт. Досягається цей результат за рахунок ускладнення структури.

 
< Попер   ЗМІСТ   Наст >