Введення
В даний час у зв'язку з ускладненням процесу прийняття рішень в сучасному бізнесі успіх підприємства безпосередньо залежить від того, як швидко і злагоджено взаємодіють його структури. У наше століття обмін інформацією немислимий без сучасних засобів зв'язку. Одне з таких засобів - сучасні глобальні комп'ютерні мережі. Мережі - важлива частина групового взаємодії, тому що вони дозволяють швидко і ефективно обмінюватися інформацією. Але реальні мережі мають недоліки. Розподілена мережа являє собою вкрай неоднорідне середовище передачі даних: одні ділянки можуть бути побудовані за технологіями ATM або FDDI, інші - на базі повільних протоколів X.25. Реальна швидкість передачі даних в такому середовищі буде прямо залежати від пропускної здатності самого повільного ділянки мережі. Таким чином, доступ віддаленого користувача до корпоративної бази даних іноді може бути істотно ускладнений.
З іншого боку: чи завжди необхідний віддаленому користувачеві повний доступ до всієї бази даних? У більшості випадків запитується тільки та інформація, яка безпосередньо відноситься до його сфери діяльності. Кращим рішенням може бути перенесення частини бази ближче до користувачів. При вирішенні цього завдання подібним способом виходить територіально розподілена база даних. Організація розподіленої бази даних дає масу переваг: знижується час відгуку системи, підвищується надійність зберігання даних, зменшується вартість апаратної частини за рахунок зниження обсягів даних, що зберігаються на одному сервері.
Ефективність такої інформаційної системи безпосередньо залежить від інтенсивності трафіку: чим він нижчий, тим швидше окупаються кошти, вкладені в її побудову. Ключем до успішної реалізації цих систем є правильна організація розподілу та зберігання інформації. Ідеальним способом зниження трафіка в каналах зв'язку є використання технології «клієнт-сервер», що одержала в останні роки широке поширення.
У дипломному проекті розглянуті загальні підходи до реалізації розподілених систем обробки даних на базі технології клієнт-сервер, а також завдання створення діючої інформаційної системи на прикладі системи автоматизації розрахунків з абонентами АТ «Связьинформ» РМ. Актуальність побудови цієї системи обумовлена різким зростанням кількості наданих послуг зв'язку, а також переходом деяких районів на почасову систему тарифікації розмов.
В процесі написання дипломної роботи автором велася розробка архітектури інформаційної системи, механізму реплікації даних, засобів віддаленого доступу та віддаленого адміністрування системи, структури БД, а також деяких компонентів клієнтської частини системи (довідкової служби та картотеки абонентів).


1. Основні підходи до проектування розподілених баз даних
1.1 Основні поняття теорії реляційних баз даних

У вузькому сенсі слова, база даних - це деякий набір даних, необхідних для роботи (актуальні дані). Дані - це відображення об'єктів реального світу. У традиційній термінології об'єкти реального світу, відомості про які зберігаються в базі даних, називаються сутностями - entities, а їх актуальні ознаки - атрибутами (attributes). Кожна ознака конкретного об'єкта є значення атрибута.
У базі даних відображаються не тільки фізичні об'єкти. Вона здатна зберігати відомості про абстракціях, процеси, явища - тобто про все, з чим людина стикається у своїй діяльності. Так, наприклад, в базі даних можна зберігати інформацію про замовлення на поставку деталей на склад (хоча це не фізичний об'єкт, а процес). Атрибутами сутності "замовлення" будуть назва поставляється деталі, кількість деталей, назву постачальника, термін поставки і т.д. Об'єкти реального світу пов'язані один з одним безліччю складних залежностей, які необхідно враховувати в інформаційній діяльності. Відзначимо, що в базі даних потрібно зберігати тільки актуальні, значимі зв'язку.
Таким чином, в широкому сенсі слова база даних - це сукупність описів об'єктів реального світу і зв'язків між ними, актуальних для конкретної прикладної області.
Спосіб, за допомогою якого сутності, атрибути та зв'язку відображаються на структури визначається моделлю даних.
Традиційно всі СУБД класифікуються в залежності від моделі даних, яка лежить в їх основі. Прийнято виділяти ієрархічну, мережну і реляційну моделі даних. Іноді до них додають модель даних на основі інвертований списків. Відповідно говорять про ієрархічних, мережних, реляційних СУБД або про СУБД на базі інвертований списків.
Найбільш поширеними на сьогоднішній день є реляційні СУБД. Вони стали фактичним промисловим стандартом. Коротко розглянемо реляційну модель даних, не вникаючи в її деталі.
Вона була розроблена Коддом ще в 1969-70 роках на основі математичної теорії відносин і спирається на систему понять, найважливішими з яких є таблиця, ставлення, рядок, стовпець, первинний ключ, зовнішній ключ.
Реляційної вважається така база даних, в якій всі дані представлені для користувача у вигляді прямокутних таблиць значень даних, і всі операції над базою даних зводяться до маніпуляцій з таблицями. Таблиця складається з рядків і стовпців і має ім'я, унікальне всередині бази даних. Таблиця відображає тип об'єкта реального світу (сутність), а кожна її рядок - конкретний об'єкт.
Значення атрибутів вибираються з множини допустимих значень, яке називається доменом (domain).
Кожен стовпець має ім'я, яке зазвичай записується у верхній частині таблиці. Воно має бути унікальним в таблиці, проте різні таблиці можуть мати стовпці з однаковими іменами. Будь-яка таблиця повинна мати принаймні один стовпець; стовпці розташовані в таблиці відповідно до порядку проходження їхніх імен при її створенні. На відміну від стовпців, рядки не мають імен, порядок їх проходження в таблиці не визначений, а кількість логічно не обмежена.
Так як рядки в таблиці не впорядковані, неможливо вибрати рядок за її позиції. Крім того, прив'язка до номера рядка некоректна в розрахованих на багато користувачів СУБД. Будь-яка таблиця має один або декілька стовпців, значення в яких однозначно ідентифікують кожен її рядок. Такий стовпець (або комбінація стовпців) називається первинним ключем (primary key). Якщо таблиця задовольняє цій вимозі, вона називається відношенням (relation).
Взаємозв'язок таблиць є найважливішим елементом реляційної моделі даних. Вона підтримується зовнішніми ключами (foreign key).
Таблиці неможливо зберігати й обробляти, якщо в базі даних відсутні "дані про дані", наприклад, Описувачі таблиць, стовпців і т.д. Їх називають зазвичай метаданими. Метадані також представлені в табличній формі і зберігаються в словнику даних (data dictionary).
Крім таблиць, в базі даних можуть зберігатися та інші об'єкти, такі як екранні форми, звіти (reports), представлення (views) і навіть прикладні програми, що працюють з базою даних.
Для користувачів інформаційної системи недостатньо, щоб база даних просто відображала об'єкти реального світу. Важливо, щоб таке відображення було однозначним і несуперечливим. У цьому випадку говорять, що база даних задовольняє умові цілісності (integrity).
Для того, щоб гарантувати коректність і взаємну несуперечність даних, на базу даних накладаються деякі обмеження, які називають обмеженнями цілісності (data integrity constraints).
Існує кілька типів обмежень цілісності. Потрібно, наприклад, щоб значення в стовпці таблиці вибиралися тільки з відповідного домену. На практиці враховують і більш складні обмеження цілісності, наприклад, цілісність за посиланнями (referential integrity). Її суть полягає в тому, що зовнішній ключ не може бути дороговказом на неіснуючу рядок у таблиці. Обмеження цілісності реалізуються за допомогою спеціальних засобів, таких як прищепила (rules), тригери (triggers) і домени (domains).
Самі по собі дані в комп'ютерній формі не представляють інтерес для користувача, якщо відсутні засоби доступу до них. Доступ до даних здійснюється у вигляді запитів до бази даних, які формулюються на стандартному мовою запитів. Сьогодні для більшості СУБД такою мовою є SQL.
Поява і розвитку цієї мови як засобу опису доступу до бази даних пов'язано зі створенням теорії реляційних баз даних. Прообраз мови SQL виник у 1970 році в рамках науково-дослідницького проекту System/R, робота над яким велася в лабораторії Санта-Тереза фірми IBM. Нині SQL - це стандарт інтерфейсу з реляційними СУБД. Популярність його настільки велика, що розробники нереляціонних СУБД (наприклад, Adabas або Betrieve), забезпечують свої системи SQL-інтерфейсом.
Мова SQL має офіційний стандарт - ANSI/ISO. Більшість розробників СУБД дотримуються цього стандарту, однак часто розширюють його для реалізації нових можливостей обробки даних. Нові механізми управління даними можуть бути використані тільки через спеціальні оператори SQL, в загальному випадку не включені до стандарт мови.
SQL не є мовою програмування в традиційному поданні. На ньому пишуться не програми, а запити до бази даних. Тому SQL - декларативний мову. Це означає, що з його допомогою можна сформулювати, що необхідно отримати, але не можна вказати, як це слід зробити. Зокрема, на відміну від процедурних мов програмування (Сі, Паскаль, Ада), в мові SQL відсутні такі оператори, як if ... then ... else, for, while, хоча слід зазначити, що в розширенні SQL для збережених процедур і тригерів (SQL/PTL - SQL/Procedure And Trigger Language) вони присутні.
Запит на мові SQL складається з одного або кількох операторів, що слідують один за одним і розділених крапкою з комою.
Нижче в таб. 2.1 подані найбільш важливі оператори, які входять в стандарт ANSI/ISO SQL.

Синтаксис оператора їх дії
SELECT Вибрати дані з бази даних
INSERT Вставити дані в таблицю
DELETE Видалити дані з таблиці
UPDATE Змінити дані в таблиці
GRANT Надіслати права на дію над об'єктом
REVOKE Відібрати права на дію над об'єктом
COMMIT Підтвердити транзакцію
ROLLBACK Відкинути транзакцію
CREATE Створити об'єкт бази даних
DROP Видалити об'єкт бази даних

Таб. 2.1. Основні оператори мови SQL.

У запитах на мові SQL використовуються імена, які однозначно ідентифікують об'єкти бази даних. Поряд з простими, використовуються також складні імена - наприклад, кваліфікаційне ім'я стовпця (qualified column name) визначає ім'я стовпця та ім'я таблиці, якій він належить.
Кожен стовпець у будь-якій таблиці зберігає дані певних типів. Розрізняють базові типи даних - рядки символів фіксованої довжини, цілі та дійсні числа, і додаткові типи даних - рядки символів змінної довжини, грошові одиниці, дату і час, логічні дані (два значення - "Істина" і "ЛОЖЬ"). У мові SQL можна використовувати числові, рядкові, символьні константи та константи типу "дата" і "час".
Одним із засобів, що забезпечують швидкий доступ до таблиць, є індекси. Індекс - це структура бази даних, що представляє собою покажчик на конкретну рядок таблиці. Індекс містить значення, що взяті з одного або декількох стовпців конкретної рядки таблиці, а також посилання на цей рядок. Значення в індексі впорядковані, що дозволяє СУБД виконувати швидкий пошук в таблиці.
Якщо індексів для таблиці не існує, то для виконання запиту СУБД повинна переглянути всю таблицю, послідовно вибираючи з неї рядки і перевіряючи для кожної з них умова вибору. Для великих таблиць такий запит буде виконуватися дуже довго.
Якщо ж був попередньо створений індекс по стовпцях, що входять у ваше WHERE запиту, то час пошуку в таблиці буде скорочено до мінімуму. Індекс створюється оператором SQL CREATE INDEX (СТВОРИТИ ІНДЕКС).
Для користувача СУБД інтерес представляють не окремі оператори мови SQL, а певна їх послідовність, оформлена як єдине ціле і що має сенс з його точки зору. Кожна така послідовність операторів мови SQL реалізує певну дію над базою даних. Воно здійснюється за кілька кроків, на кожному з яких над таблицями бази даних виконуються деякі операції. Так, у банківській системі переклад деякої суми з короткострокового рахунку на довгостроковий виконується в декілька операцій. Серед них - зняття суми з короткострокового рахунку, зарахування на довгостроковий рахунок.
Якщо в процесі виконання цієї дії відбудеться збій, наприклад, коли перша операція буде виконана, а друга - ні, то гроші будуть втрачені. Отже, будь-яка дія над базою даних повинне бути виконано повністю, або не виконуватися зовсім. Така дія отримало назву транзакції.
Обробка транзакцій спирається на журнал, який використовується для відкоту транзакцій і відновлення стану бази даних

1.2 Сервер бази даних
1.2.1 Технологія та моделі "клієнт-сервер"

"Клієнт-сервер" - це модель взаємодії комп'ютерів в мережі. Як правило, комп'ютери не є рівноправними. Кожен з них має своє, відмінне від інших, призначення, грає певну роль. Деякі комп'ютери в мережі володіють і розпоряджаються інформаційно-обчислювальними ресурсами, такими як процесори, файлова система, поштова служба, служба друку, база даних. Інші мають можливість звертатися до цих служб, користуючись послугами першим. Комп'ютер, що керує тим чи іншим ресурсом, прийнято називати сервером цього ресурсу, а комп'ютер, який хоче ним скористатися - клієнтом. Конкретний сервер визначається видом ресурсу, яким він володіє. Так, якщо ресурсом є бази даних, то мова йде про сервер баз даних, призначення якого - обслуговувати запити клієнтів, пов'язані з обробкою даних; якщо ресурс - це файлова система, то говорять про файловому сервері або файл-сервер і т.д.
У мережі один і той же комп'ютер може виконувати роль як клієнта, так і роль сервера. Наприклад, в інформаційній системі, що включає персональні комп'ютери, велику ЕОМ і міні-комп'ютер під керуванням UNIX, останній може виступати як в якості сервера бази даних, обслуговуючи запити від клієнтів - персональних комп'ютерів, так і як клієнт, направляючи запити великий ЕОМ.
Цей же принцип розповсюджується і на взаємодію програм. Якщо один з них виконує деякі функції, надаючи іншим відповідний набір послуг, то така програма розглядається як сервер. Програми, які користуються цими послугами, прийнято називати клієнтами. Так, ядро реляційної SQL-орієнтованої СУБД часто називають сервером бази даних або SQL-сервером, а програму, що обертається до нього за послугами з обробки даних - SQL-клієнтом.
Спочатку СУБД мали централізовану архітектуру. У ній сама СУБД і прикладні програми, які працювали з базами даних, функціонували на центральному комп'ютері (велика ЕОМ або міні-комп'ютер). Там же розташовувалися бази даних. До центрального комп'ютера були підключені термінали, які виступали в якості робочих місць користувачів. Усі процеси, пов'язані з обробкою даних: підтримка введення, що здійснюється користувачем, формування, оптимізація та виконання запитів, обмін із пристроями зовнішньої пам'яті і т.д., виконувалися на центральному комп'ютері, що висувало жорсткі вимоги до його продуктивності. Особливості СУБД першого покоління безпосередньо пов'язані з архітектурою великих ЕОМ і міні-комп'ютерів і адекватно відображають всі їхні переваги та недоліки.
В даний час фактичним стандартом для розрахованих на багато користувачів СУБД, стала архітектура "клієнт-сервер".
Якщо передбачається, що проектується інформаційна система (ІС) буде побудована за технологією "клієнт-сервер", то це означає, що прикладні програми, реалізовані в її рамках, будуть мати розподілений характер. Іншими словами, частина функцій прикладної програми (або, простіше, додатки) буде реалізована в програмі-клієнті, інша - у програмі-сервер, причому для їх взаємодії буде визначено деякий протокол.
Основний принцип технології "клієнт-сервер" полягає у розподілі функцій стандартного інтерактивного додатки на чотири групи, що мають різну природу. Перша група - це функції введення і відображення даних. Друга група поєднує чисто прикладні функції, характерні для даної предметної області.
До третьої групи відносяться фундаментальні?? УНКЦ зберігання і управління інформаційними ресурсами (базами даних, файловими системами і т.д.). Нарешті, функції четвертої групи - службові, що грають роль зв'язок між функціями перших трьох груп. Відповідно до цього в будь-якій програмі виділяються наступні логічні компоненти:

* Компонент подання, що реалізує функції першої групи;
* Прикладної компонент, який підтримує функції другої групи;
* Компонент доступу до інформаційних ресурсів, що підтримує функції третьої групи;
* Протокол взаємодії.

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

* Модель файлового сервера (File Server - FS);
* Модель доступу до віддалених даними (Remote Data Access - RDA);
* Модель півночі бази даних (DataBase Server - DBS);
* Модель сервера додатків (Application Server - AS).

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



Рис.1.1. Модель файлового сервера.

FS-модель послужила фундаментом для розширення можливостей персональних СУБД в напрямку підтримки багатокористувацького режиму. У таких системах на кількох персональних комп'ютерах виконується як прикладна програма, так і копія СУБД, а бази даних містяться в поділюваних файлах, які знаходяться на файловому сервері. Коли прикладна програма звертається до бази даних, СУБД направляє запит на файловий сервер. У цьому запиті вказані файли, де знаходяться запрошувані дані. У відповідь на запит файловий сервер направляє по мережі потрібний блок даних. СУБД, отримавши його, виконує над даними дії, які були декларовані в прикладній програмі.
До технологічним недоліків моделі відносять високий мережевий трафік (передача безлічі файлів, необхідних додатку), вузький спектр операцій маніпулювання даними ( "дані - це файли"), відсутність адекватних засобів безпеки доступу до даних (захист тільки на рівні файлової системи) і т.д . Всі перераховані недоліки - наслідок внутрішньо притаманних FS-моделі обмежень, що визначаються її характером.
Більш технологічна RDA-модель істотно відрізняється від FS-моделі характером компонента доступу до інформаційних ресурсів. Це, як правило, SQL-сервер. У RDA-моделі коди компонента уявлення і прикладного компонента сполучені і виконуються на комп'ютері-клієнті. Останній підтримує як функції введення і відображення даних, так і суто прикладні функції. Доступ до інформаційних ресурсів забезпечується або операторами спеціальної мови (мови SQL, якщо мова йде про бази даних) або викликами функцій спеціальної бібліотеки (якщо є відповідний інтерфейс прикладного програмування - API).



Рис 2.2. Модель доступу до віддалених даних.

Клієнт направляє запити до інформаційних ресурсів (наприклад, до баз даних) по мережі віддаленого комп'ютера. На ньому функціонує ядро СУБД, яке обробляє запити, виконуючи визначені в них дії і повертає клієнтові результат, оформлений як блок даних. При цьому ініціатором маніпуляцій з даними виступають програми, які виконуються на комп'ютерах-клієнтах, у той час як ядра СУБД відводиться пасивна роль - обслуговування запитів і обробка даних.
RDA-модель позбавляє від недоліків, властивих як систем з централізованою архітектурою, так і системам з файловим сервером.
Перш за все, перенесення компонента уявлення і прикладного компоненту на комп'ютери-клієнти істотно розвантажує сервер БД, мінімізуючи загальне число процесів операційної системи. Сервер БД звільняється від невластивих йому функцій; процесор або процесори сервера цілком завантажуються операціями обробки даних, запитів і транзакцій. Це стає можливим завдяки відмові від терміналів та оснащенню робочих місць комп'ютерами, які володіють власними локальними обчислювальними ресурсами, повністю використовуваними програмами переднього плану. З іншого боку, різко зменшується завантаження мережі, тому що по ній передаються від клієнта до сервера не запити на введення-виведення (як у системах з файловим сервером), а запити на мові SQL, а їхній обсяг істотно менше.
Основна перевага RDA-моделі полягає в уніфікації інтерфейсу "клієнт-сервер" у вигляді мови SQL. Дійсно, взаємодія прикладного компонента з ядром СУБД неможливо без стандартизованого засобу спілкування. Запити, що направляються програмою ядра, повинні бути зрозумілі обом сторонам. Для цього їх слід сформулювати на спеціальній мові. Але в СУБД вже існує мова SQL, про який йшлося вище. Тому було б доцільно використовувати його не тільки як засіб доступу до даних, але і як стандарту спілкування клієнта і сервера.
На жаль, RDA-модель не позбавлена ряду недоліків. По-перше, взаємодія клієнта і серверу за допомогою SQL-запитів істотно завантажує мережу. По-друге, задовільний адміністрування додатків в RDA-моделі практично неможливо через поєднання в одній програмі різних за своєю природою функцій (функції подання та прикладні функції).
Поряд з RDA-моделлю все більшої популярності набуває перспективна DBS-модель. Остання реалізована в деяких реляційних СУБД (Informix, Ingres, Sybase, Oracle, InterBase). Її основу складає механізм збережених процедур - засіб програмування SQL-сервера. Процедури зберігаються в словнику бази даних, розділяються між декількома клієнтами і виконуються на тому ж комп'ютері, де функціонує SQL-сервер. Мова, якою розробляються процедури, що зберігаються (SQL/PTL), представляє собою процедурне розширення мови запитів SQL і унікальний для кожної конкретної СУБД.
У DBS-моделі компонент подання виконується на комп'ютері-клієнті, у той час як прикладної компонент оформлений як набір збережених процедур і функціонує на комп'ютері-сервері БД. Там же виконується компонент доступу до даних, тобто ядро СУБД. Переваги DBS-моделі: можливість централізованого адміністрування прикладних функцій, і зниження трафіку (замість SQL-запитів по мережі направляються виклики збережених процедур), можливість поділу процедури між декількома додатками, економія ресурсів комп'ютера за рахунок використання одного разу створеного плану виконання процедури. До недоліків можна віднести обмеженість коштів, що використовуються для написання збережених процедур, які представляють собою різноманітні процедурні розширення SQL, не витримують порівняння за функціональними можливостями з мовами третього покоління, такими як C або Pascal. Сфера їх використання обмежена конкретною СУБД, в більшості СУБД відсутні можливості налагодження й тестування розроблених збережених процедур.



Рис.1.3. Модель сервера баз даних.

На практиці часто використовується змішані моделі, коли підтримка цілісності бази даних і деякі найпростіші прикладні функції виконуються збереженими процедурами (DBS-модель), а більш складні функції реалізуються безпосередньо в прикладній програмі, яка працює на комп'ютері-клієнті (RDA-модель). Так чи інакше, сучасні розраховані на багато користувачів СУБД спираються на RDA-і DBS-моделі і при створенні ІС, що припускає використання тільки СУБД, обирають одну з цих двох моделей, або їх розумне поєднання.
У AS-моделі процес, що виконуються на комп'ютері-клієнті, відповідає, як звичайно, за інтерфейс з користувачем (тобто реалізує функції першої групи). Звертаючись за виконанням послуг до прикладного компоненту, цей процес відіграє роль клієнта додатка (Application Client - AC). Прикладної компонент реалізований як група процесів, що виконують прикладні функції і називається сервером додатка (Application Server - AS). Всі операції над інформаційними ресурсами виконуються відповідним компонентом, по відношенню до якого AS грає роль клієнта. З прикладних компонентів доступні ресурси різних типів - бази даних, черги, поштові служби та ін



Ріс.1.4. Модель сервера додатків.

RDA-і DBS-моделі спираються на двухзвенний схему розподілу функцій. У RDA-моделі прикладні функції додані програми-клієнта, в DBS-моделі відповідальність за їх виконання бере на себе ядро СУБД. У першому випадку прикладної компонент зливається з компонентом вистави, в другому - інтегрується в компонент доступу до інформаційних ресурсів. У AS-моделі реалізована триланкового схема розподілу функцій, де прикладної компонент виділений як найважливіший ізольований елемент програми, для його визначення використовуються універсальні механізми багатозадачного операційної системи, і стандартизовані інтерфейси з двома іншими компонентами. AS-модель є фундаментом для моніторів обробки транзакцій (Transaction Processing Monitors - TPM), або, простіше, моніторів транзакцій, які виділяються як особливий вид програмного забезпечення.
У період створення перших СУБД технологія "клієнт-сервер" тільки зароджувалася. Тому спочатку в архітектурі систем не було адекватного механізму організації взаємодії такого типу, в сучасних же системах він життєво необхідний.
Щоб зрозуміти проблему, розглянемо еволюцію серверів баз даних. Перший час домінувала модель, коли управління даними (функція сервера) і взаємодія з користувачем були поєднані в одній програмі. Потім функції керування даними були виділені в самостійну групу - сервер, однак модель взаємодії користувача з сервером відповідала парадигмі "один-до-одного", тобто сервер обслуговував запити рівно одного користувача (клієнта), і для обслуговування декількох клієнтів потрібно було запустити еквівалентне число серверів. Виділення сервера в окрему програму - революційний крок, що дозволяє, зокрема, помістити сервер на одну машину, а програмний інтерфейс з користувачем - на іншу, здійснюючи взаємодія між ними по мережі. Однак необхідність запуску великої кількості серверів для обслуговування безлічі користувачів сильно обмежувала можливості такої системи.
Проблеми, що виникають в моделі "один-до-одного", вирішуються в архітектурі систем з виділеним сервером, здатним обробляти запити від багатьох клієнтів. Сервер єдиний володіє монополією на керування даними та взаємодіє одночасно з багатьма клієнтами. Логічно кожен клієнт зв'язаний з сервером окремою ниткою (thread) або потоком, по якому пересилаються запити. Така архітектура отримала назву багатопотокової (multi-threaded).
Вона дозволяє значно зменшити навантаження на операційну систему, що виникає при роботі великого числа користувачів. З іншого боку, можливість взаємодії з одним сервером багатьох клієнтів дозволяє в повній мірі використовувати колективні об'єкти (починаючи з відкритих файлів і закінчуючи даними із системних каталогів), що сильно зменшує потреби в пам'яті і загальне число процесів операційної системи. Наприклад, системою з архітектурою "один-до-одного" буде створено 50 копій процесів СУБД для 50 користувачів, тоді як системі з багатопотокової архітектурою для цього знадобитися тільки один сервер.
Однак таке рішення створює нову проблему. Так як сервер може виконуватися тільки на одному процесорі, виникає природне обмеження на застосування СУБД для мультипроцесорних платформ. Якщо комп'ютер має, наприклад, чотири процесори, то СУБД з одним сервером використовують тільки один з них, не завантажуючи залишилися три.
У деяких системах ця проблема вирішується заміною виділеного сервера на диспетчер або віртуальний сервер (virtual server), який втрачає право монопольно розпоряджатися даними, виконуючи тільки функції диспетчеризації запитів до актуальних серверів. Таким чином, в архітектуру системи додається новий шар, який розміщується між клієнтом і сервером, що збільшує витрату ресурсів на підтримку балансу завантаження (load balancing) і обмежує можливості управління взаємодією "клієнт-сервер". По-перше, стає неможливим направити запит від конкретного клієнта конкретного сервера, по-друге, сервери стають рівноправними - неможливо встановлювати пріоритети для обслуговування запитів.
Сучасне рішення проблеми СУБД для мультипроцесорних платформ полягає в можливості запуску кількох серверів бази даних, у тому числі і на різних процесорах. При цьому кожен із серверів повинен бути багатопотокових. Якщо дві ці умови виконані, то є підстави говорити про багатопотокової архітектурі з декількома серверами (multi-threaded, multi-server architecture).

1.2.2 Механізми реалізації активного ядра

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

1. Необхідно, щоб база даних у будь-який момент часу правильно відображала стан предметної області - дані повинні бути взаємно несуперечність.
2. База даних повинна відображати деякі правила предметної області, закони, за якими вона функціонує (business rules).
3. Необхідний постійний контроль за станом бази даних, відстеження всіх змін, і адекватна реакція на них.
4. Необхідно, щоб виникнення деякої ситуації в базі даних чітко і оперативно впливало на хід виконання прикладної програми. Багато програм вимагають оперативного оповіщення про всі відбуваються в базі даних змін.

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

* Процедурами бази даних;
* Правилами (тригери);
* Подіями в базі даних;
* Типами даних, що визначаються користувачем;

1.2.3 Збережені процедури

У різних СУБД вони носять назву збережених (stored), приєднаних, що розділяються і т.д. Нижче будемо користуватися термінологією, прийнятою в СУБД InterBase.
Використання процедур бази даних переслідує чотири цілі:

* Забезпечується новий незалежний рівень централізованого контролю доступу до даних, що здійснюється адміністратором бази даних.
* Одна процедура може використовуватися декількома прикладними програмами -?? то дозволяє істотно скоротити час написання програм за рахунок оформлення їх загальних частин у вигляді процедур бази даних. Процедура компілюється і поміщається в базу даних, стаючи доступною для багаторазових викликів. Так як план її виконання визначається один раз при компіляції, то при наступних виклики процедури фаза оптимізації пропускається, що істотно заощаджує обчислювальні ресурси системи.
* Використання процедур баз даних дозволяє значно знизити трафік мережі в системах з архітектурою "клієнт-сервер". Прикладна програма, що викликає процедуру, передає серверу лише її ім'я і параметри. У процедурі, як правило, концентруються повторювані фрагменти з декількох прикладних програм. Якщо б ці фрагменти залишилися частиною програми, вони завантажували би мережу посилкою повних SQL-запитів.
* Процедури бази даних у поєднанні з правилами, надають адміністратору потужні засоби підтримки цілісності бази даних.

В сучасних СУБД процедура зберігається безпосередньо в базі даних і контролюється її адміністратором. Вона має параметри і повертає значення. Процедура бази даних створюється оператором CREATE PROCEDURE (СТВОРИТИ ПРОЦЕДУРУ) і містить визначення змінних, оператори SQL (наприклад, SELECT, INSERT), оператори перевірки умов (IF/THEN/ELSE) оператори циклу (FOR, WHILE), а також деякі інші. < br />
1.2.4 Правила (тригери)

Механізм правил (тригерів) дозволяє програмувати обробку ситуацій, що виникають при будь-які зміни в базі даних. Правило надається таблиці бази даних і застосовується при виконанні операцій над таблицею включення, видалення або оновлення рядків.
Застосування правила полягає у перевірці сформульованих у ньому умов, при виконанні яких відбувається виклик специфікований всередині правила процедури бази даних. Важливо, що правило може бути застосовано як до, так і після виконання оновлення, отже, можлива скасування операції.
Таким чином, правило дозволяє визначити реакцію сервера на будь-яку зміну стану бази даних. Правила (так само, як і процедури) зберігаються безпосередньо в базі даних незалежно від прикладних програм. Одна з цілей механізму правил - відображення деяких зовнішніх правил діяльності організації.
Найважливіша мета механізму правил - забезпечення цілісності бази даних. Один з аспектів цілісності - цілісність за посиланнями (referential integrity) - стосується зв'язки двох таблиць між собою. Цей зв'язок підтримується зовнішніми ключами. Механізм правил дозволяє реалізувати і більш загальні обмеження цілісності.

1.2.5 Механізм подій

Механізм подій в базі даних (database events) дозволяє прикладним програмам і сервера бази даних повідомляти інші програми про настання в базі даних певної події і тим самим синхронізувати їх роботу. Оператори мови SQL, що забезпечують повідомлення, називають сигналізаторами подій в базі даних (database event alerters). Функції управління подіями цілком лягають на сервер бази даних.
Механізм подій