Організація віддаленого доступу до розподілених баз даних

Інформатика, програмування

дивитися на реферати схожі на "Організація віддаленого доступу до розподілених баз даних"

Зміст

Введення 4

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

1.1 Основні поняття теорії реляційних баз даних 6
1.2 Сервер бази даних 10

1.2.1 Технологія та моделі "клієнт-сервер" 10

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

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

1.2.4 Правила (тригери) 21

1.2.5 Механізм подій 21
1.3 Обробка розподілених даних 22
1.4 Взаємодія з PC-орієнтованими СУБД 30
1.5 Обробка транзакцій 33
1.6 Засоби захисту даних в СУБД 37
1.7 Застосування CASE-засобів для інформаційного моделювання в системах обробки даних. 41

2. Реалізація розподіленої бази даних з віддаленим доступом 43

2.1 Аналіз існуючої системи 44
2.2 Нова схема обміну інформацією 45
2.3 Вибір операційної системи 47
2.4 Вибір сервера баз даних 48
2.5 Вибір засобів розробки 55
2.6 Організація взаємодії між серверами 56

2.6.1 Вибір моделі розподіленої бази даних 56

2.6.2 Модель взаємодії 56

2.6 .3 Використання шару RPC для розподіленої обробки даних на платформі Windows NT 57

2.6.4 Компоненти Microsoft RPC 57

2.6.5 Механізм роботи RPC 58

2.6 .6 Організація логічного каналу передачі даних 61
2.7 Організація доступу видалених користувачів 61

2.7.1 Необхідність віддаленого доступу 61

2.7.2 Використання шару RAS для віддаленого доступу на платформі

Windows NT 61

2.7.3 Забезпечення інформаційної безпеки при віддаленому доступі 63
2.8 Проектування структури бази даних 63
2.9 Схема реплікації даних 65
2.10 Проектування комунікаційного сервера 67

2.10.1 Постановка задачі 67

2.10.2 Архітектура комунікаційного сервера 68

2.10.3 Допоміжне програмне забезпечення 70

3 . Техніко-економічне обгрунтування 71

3.1 План виконання дипломного проекту 71
3.2 Розрахунок очікуваної тривалості виконання робіт та їх дисперсій 73
3.3 Побудова стрічкового графіка виконання роботи 74
3.4 Визначення планової собівартості НДР 76

Висновок 79

Список літератури 80

Додаток 1 82

Додаток 2 131

Додаток 3 132

Додаток 4 156

Додаток 5 159

Додаток 6 162

Введення

В даний час у зв'язку з ускладненням процесу прийняття рішень всучасному бізнесі успіх підприємства безпосередньо залежить від того, як швидкоі злагоджено взаємодіють його структури. У наше століття обмін інформацієюнемислимий без сучасних засобів зв'язку. Одне з таких засобів - сучасніглобальні комп'ютерні мережі. Мережі - важлива частина груповоговзаємодії, тому що вони дозволяють швидко і ефективно обмінюватисяінформацією. Але реальні мережі мають недоліки. Розподілена мережаявляє собою вкрай неоднорідне середовище передачі даних: одні ділянкиможуть бути побудовані за технологіями ATM або FDDI, інші - на базіповільних протоколів X.25. Реальна швидкість передачі даних в такому середовищібуде прямо залежати від пропускної здатності самого повільного ділянкимережі. Таким чином, доступ віддаленого користувача до корпоративної базіданих іноді може бути істотно ускладнений.

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

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

У дипломному проекті розглянуті загальні підходи до реалізаціїрозподілених систем обробки даних на базі технології клієнт-сервер, атакож завдання створення діючої інформаційної системи на прикладі системиавтоматизації розрахунків з абонентами АТ «Связьинформ» РМ. Актуальністьпобудови цієї системи обумовлена різким зростанням кількостінадаваних послуг зв'язку, а також переходом деяких районів напочасову систему тарифікації розмов.

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

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

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

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

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

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

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

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

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

Вона була розроблена Коддом ще в 1969-70 роках на основіматематичної теорії відносин і спирається на систему понять, найважливішимиз яких є таблиця, ставлення, рядок, стовпець, первинний ключ,зовнішній ключ.

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

Значення атрибутів вибираються з множини допустимих значень,яке називається доменом (domain).

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

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

Взаємозв'язок таблиць є найважливішим елементом реляційної моделіданих. Вона підтримується зовнішніми ключами (foreign key).

Таблиці неможливо зберігати й обробляти, якщо в базі данихвідсутні "дані про дані", наприклад, Описувачі таблиць, стовпців і т.д.
Їх називають зазвичай метаданими. Метадані також представлені в табличнійформі і зберігаються в словнику даних (data dictionary).

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

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

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

Існує кілька типів обмежень цілісності. Потрібно,наприклад, щоб значення в стовпці таблиці вибиралися тільки звідповідного домену. На практиці враховують і більш складні обмеженняцілісності, наприклад, цілісність за посиланнями (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.

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

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

Кожен стовпець у будь-якій таблиці зберігає дані певних типів.
Розрізняють базові типи даних - рядки символів фіксованої довжини, ціліі речові числа, і додаткові типи даних - рядка символівзмінної довжини, грошові одиниці, дату і час, логічні дані (двазначення - "Істина" і "ЛОЖЬ"). У мові 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-запитів.

. Процедури бази даних у поєднанні з правилами, предост