Архітектура багатокористувачевих СКБД

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

Телеобробка

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

терміналів).

 

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

· технології файлового сервера;

· технології "клієнт/сервер".

Файловий сервер

У середовищі файлового сервера обробка даних розподілена в мережі, що звичайно представляє собою локальну обчислювальну мережу (ЛОС). Файловий сервер містить файли, необхідні для роботи додатків і самої СКБД, Однак користувальницькі програми і сама СКБД розміщені і функціонують на окремих робочих станціях, і звертаються до файлового сервера тільки в міру необхідності одержання доступу до потрібногоїм файлу - як показане на мал. 2.9. Таким чином, файловий сервер функціонує просто як спільно використовуваний жорсткий диск. СКБД на кожній робочій станції посилає запити файловому серверу по всім необхідним їй даним, що зберігаються на диску файл-сервера. Такий підхід характеризується значним мережевим графіком, що може привести до зниження продуктивності всієї системи в цілому. Розглянемо, наприклад, ситуацію, коли користувач надсилає запит на вибірку даних про всіх співробітників відділення компанії, що знаходиться за адресою '163 Main St'. Цю задачу можна сформулювати за допомогою наступного SQL-оператора:

SELECT fname, Iname

FROM branch b, staff s

WHERE b.bno = s.sno AND b.street = '163 Main St'

 

Оскільки файловий сервер не розуміє команд мовою SQL, СКБД повинна запросити у файлового сервера файли, що відповідають відносинам Branch (Відділення) і Staff (Працівник), а не шукані імена співробітників.

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

· Великий обсяг сіткового графіка.

· На кожній робочій станції повинна знаходитися повна копія СКБД.

·

Керування паралельністю, відновленням і цілісністю ускладнюється, оскільки доступ до тим самим файлів можуть здійснювати відразу кілька екземплярів СКБД.

2.6.3. Технологія „клиент/сервер"

Технологія "клієнт/сервер" була розроблена з метою усунення недоліків, що маються в перших двох підходах. "Клієнт/сервер" означає такий спосіб взаємодії програмних компонентів, при якому вони утворять єдину, систему. Як видно з "самої назви, існує деякий клієнтський процес, що вимагає визначених ресурсів, а також серверний процес, що ці ресурси надає. При цьому зовсім необов'язково, щоб вони знаходилися на тому самому комп'ютері. На практиці прийнято розміщати сервер на одному вузлі локальної мережі, а клієнти — на інших вузлах. На мал. 2.10 показана архітектура типу «клієнт/сервер», а на мал. 2.11 - деякі можливі варіанти топології "клієнт/сервер".

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

 

Рис. 2.11. Альтернативні топології систем, з архітектурою "клієнт/ сервер": а) один клієнт - один сервер; б) трохи клієнтів - один сервер; в) трохи клієнтів - кілька серверів

Таблиця 2.4. Функції, виконувані учасниками взаємодії в середовищі „клиент/сервер"

Клієнт Сервер

Керує користувальницьким інтерфейсом Приймає й обробляє запити до бази даних з боку клієнтів

Приймає і перевіряє синтаксис уведеного Перевіряє повноваження користувачів

користувачем запиту

Виконує програму Гарантує дотримання обмежень цілісності

Генерує запит до бази даних і передає Виконує запити/відновлення і повертає результати клієнту серверу

Відображає отримані дані користувачу Підтримує системний каталог

Забезпечує рівнобіжний доступ до бази даних

Забезпечує керування відновленням

 

Цей тип архітектури має приведеними нижче переваги.

· Забезпечується більш широкий доступ до існуючого базам даних.

· Підвищується загальна продуктивність системи. Оскільки клієнти і сервер знаходяться на різних комп'ютерах, їхні процесори здатні виконувати додатка паралельно. При цьому настроювання продуктивності комп'ютера із сервером спрощується, якщо на ньому виконується тільки робота з базою даних.

· Вартість апаратного забезпечення знижується. Досить могутній комп'ютер з великим пристроєм збереження потрібний тільки серверу— для збереження і керування базою даних.

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

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

· Ця архітектура дуже природно відображається на архітектуру відкритих систем.

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

У трьохрівневій архітектурі "клієнт/сервер" тонкий (неінтелектуальний) клієнт на робочій станції керує тільки користувальницьким інтерфейсом, тоді як середній рівень обробки даних керує всією іншою логікою додатка. Третім рівнем тут є сервер бази даних. Ця трьохрівнева архітектура виявилася більш придатною для деяких середовищ — наприклад, для мереж Internet і intranet, де як клієнта може використовуватися звичайний Web-броузер.

Системні каталоги

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

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

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

· імена користувачів, для яких дозволений доступ до бази даних;

· імена елементів даних у базі даних;

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

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

· імена елементів даних з бази даних;

· типи і розміри елементів даних;

· обмеження, установлені для кожного з елементів даних.

Як уже згадувалося раніше, термін "словник даних" часто використовується для програмного забезпечення більш загального типу, чим просто каталог СКБД. Система словника даних може бути або пасивною, або активної. Активна система завжди погодиться зі структурою бази даних, оскільки вона автоматично підтримується цією системою. Пасивна система може суперечити стану бази даних через ініційованих користувачами зміни. Якщо словник даних є частиною бази даних, то він називається інтегрованим словником даних. Ізольований словник даних володіє своєї власної спеціалізований СКБД. Його переважно використовувати на початкових етапах проектування бази даних для деякої організації, коли потрібно відкласти на якийсь час прив'язку до конкретної СКБД. Однак недолік цього підходу полягає в тім, що після вибору СКБД і втілення бази даних ізольований словник даних значно сутужніше підтримувати в згоді зі станом бази даних. Цю проблему можна було б звести до мінімуму, якщо перетворити при проектуванні словник даних безпосередньо в каталог СКБД. Донедавна ніякого вибору не було взагалі, але в міру розвитку стандартів словників даних ця ідея стає усе більш реальною. У наступному розділі коротко розглядається один зі стандартів словників даних.

Служба IRDS

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

Недавно була почата спроба стандартизувати інтерфейс словників даних для досягнення більшої приступності і спрощенняїх спільного використання. Її результатом стала розробка служби словника інформаційних ресурсів (Information Resource Dictionary System - IRDS). Служба IRDS являє собою програмний інструмент, призначений для керування інформаційними ресурсами організації, а також дляїх документування. Вона включає визначення таблиць, що містять словник даних, і операції, що можуть бути використані для доступудо цих таблиць. Згадані операції забезпечують несуперечливий метод доступу до словника даних і спосіб перетворення визначень даних зі словника одного типу у визначення іншого типу. Наприклад, за допомогою служби IRDS інформація, збережена в IRDS-сумісному словнику даних СКБД DB2, може бути передана в IRDS-сумісний словник даних СКБД Oracle чи спрямована деякому додатку системи DB2. •

Однимз достоїнств служби IRDS є здатність розширення словника даних. Так, якщо користувач захоче зберегти визначення нового типу інформації в якомусь інструменті (наприклад, визначення звітів про керування проектом — у деякой СКБД), то система IRDS у даній СКБД може бути розширена для включення цієї інформації. Визначення IRDS були прийняті як стандарт Міжнародною організацією стандартизації ISO (International Organization for Standardization) (ISO, 1990; 1993).

Стандарти IRDS визначають набір правил збереження інформації в словнику даних і доступу до неї, переслідуючи при цьому три наступні цілі:

· розширюваність даних;

· цілісність даних;

· контрольований доступ до даних.

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

· панельний інтерфейс;

· командна мова;

· файли експорту/імпорту;

· прикладні програми.

Панельний інтерфейс складається з наборупанелей чи екранів, кожний з який надає доступ до заздалегідь описаного набору сервісів. Він трохи нагадує мову QBE і дозволяє користувачам переглядати і змінювати словник даних. Інтерфейс командної мови складається з наборукоманд чи операторів, що дозволяють виконувати маніпуляції зі словником даних. Інтерфейс командної мови може викликатися інтерактивно (за допомогою термінала) чи за допомогою впровадження операторів у програми на мовах програмування високого рівня. Інтерфейс експорту/імпорту генерує файл, якому можна передавати між різними IRDS-сумісними системами. Стандарт IRDS визначає й універсальний формат обміну інформацією. Причому він не вимагає, щоб база даних, що лежить в основі словника даних, відповідала якоїсь однієї моделі даних. Саме тому інтерфейс IRDS-сервісів здатний поєднувати гетерогенні СКБД, як показано на мал. 2.12.

 

Резюме

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

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

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

· Підмова даних складається з двох частин: мови визначення даних DDL (Data Definition Language) і мови керування даними DML (Data Manipulation Language). Мова DDL використовується для опису структури бази даних, а мова DML — для читання і відновлення самої бази даних.

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

· До об'єктних моделей даних відносяться модель "сутність-зв'язок", семантична, функціональна й об ' єктно-орієнтовна моделі, а до моделей даних на основі записів - реляційна, мережна й ієрархічна моделі.

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

· Поняття архітектури "клієнт/сервер" позначає спосіб взаємодії програмних компонентів (клієнта і сервера), при якому клієнтський процес вимагає одержання деякого ресурсу, а сервер його надає. Звичайно, клієнт керує користувальницьким інтерфейсом, а сервер — функціональною частиною бази даних.

· Системний каталог є одним, з фундаментальних компонентів СКБД. Він містить "дані про даний", чи мета-дані. Каталог повинний бути доступний користувачам. Служба IRDS (Information Resource Dictionary System) - це новий стандарт ISO, що визначає методи доступу до словника даних. При цьому допускається їхнє спільне використання і передача з однієї системи в іншу.