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

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

Існує два різновиди збережених процедур:

• процедури вибору;

• процедури дії.

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

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

Збереженим процедурам можна передавати параметри й одержувати назад значення параметрів, змінені відповідно до алгоритмів роботи збережених процедур.

Переваги використання збережених процедур:

• одну процедуру можна використовуватися багатьма застосуваннями;

• розвантаження застосувань клієнта шляхом переносу частини коду на сервер і внаслідок цього - спрощення клієнтських додатків;

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

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

Створення збереженої процедури

CREATE PROCEDURE Ім’я_Процедури [(вхідний_параметр тип_даних [,вхідний_параметр тип_даних...])] [RETURNS (вихідн_параметр1 тип_даних [,вихід_параметр2 тип даних ...])] AS <тіло процедури>;

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

Тіло процедури має наступний формат:

[<оголошення локальних змінні процедури>] BEGIN < оператор> [<оператор> ... ] END

Приклад: дана збережена процедура FIND_MAX_KOLVO повертає у вихідному параметрі MAX_KOLVO максимальну кількість товару відгруженого зі складу, найменування якого передається у вхідному параметрі IN_TOVAR.

CREATE PROCEDURE FIND_MAX_KOLVO

(IN_TOVAR VARCHAR(20))

RETURNS (MAX_KOLVO INTEGER)

AS BEGIN

SELECT MAX(KOLVO)

FROM RASHOD WHERE TOVAR = :IN_TOVAR INTO :MAX_KOLVO;

SUSPEND; END;

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

Тригер – це процедура БД, яка автоматично викликається SQL-сервером при оновленні, вилученні або додаванні нового запису в БД. Безпосередньо з програми до тригерів звернутися неможливо. Їм не можна передавати вхідні параметри і отримувати від них значення вихідних параметрів. Тригери розрізняють по наступним подіям зміни БД: додавання нового запису, зміна існуючого запису вилучення запису.

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

Тригер створюється оператором

CREATE TRIGGER Ім’я_Триггера FOR Ім’я_Таблиці [ACTIVE | INACTIVE] {BEFORE | AFTER} {DELETE | INSERT | UPDATE} [POSITION номер] AS <тіло тригера>

Для визначення тіла тригера використовується спеціалізована процедурна мова.

Структура тіла тригера:

[<оголошення локальних змінних>]

BEGIN

< оператор>

END

• ACTIVE | INACTIVE - указує, активний тригер чи ні. Можна визначити тригер «про запас», встановивши для нього INACTIVE. Надалі можна перевизначити тригер як активний. За замовчуванням діє ACTIVE.

• BEFORE | AFTER - вказує, буде виконуватися тригер до (BEFORE) чи після (AFTER)

запам'ятовування змін у БД.

• DELETE | INSERT | UPDATE - вказує операцію над таблицею БД, при виконанні якої спрацьовує тригер.

• POSITION номер - указує, яким по порядку буде виконуватися тригер у випадку наявності групи тригерів, що мають однакові характеристиками операції і часу (до, після операції) виклику тригера. Значення номера задається числом у діапазоні 0..32767.

Тригери з меншими номерами виконуються раніш.

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

Приклад: Створити генератор, який буде повертати унікальне значення для назви кафедри у таблиці “Кафедра”. Попередньо поле C_Number у таблиці “Кафедра” повинно бути створено.

CREATE GENERATOR Chair_C_Number

SET GENERATOR Chair_C_Number TO 1

Звернення до генератора з оператора INSERT:

INSERT INTO Chair (C_Number, C_Title, C_Chief, C_Quant, F_Title)

VALUES (GEN_ID (Chair_C_Number,1), ”ІТ”,”Задоров В.Б.”, “20”, “ФАІТ”)

16. Архітектура із сервером застосувань: визначити властивості цієї схеми, пояснити призначення сервера застосувань; порівняти архітектуру клієнт-сервер та архітектуру відділеного доступу з архітектурою із сервером застосувань.

Розвиток ідей архітектури клієнт-сервер привів до появи триланкової архітектури доступу до БД (у літературі її також називають багатоланковою архітектурою, N-tier чи multi-tier архітектурою).

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

Архітектура клієнт-сервер - двохланкова: першою ланкою в ній є програма клієнта, а другою - сервер БД і сама БД.

У триланковій архітектурі створюється допоміжна програма, у яку включаються всі компоненти-набори даних, що були раніше (у дволанковій архітектурі) власністю клієнтських застосувань. Потім ця програма реєструється в якості COM- MTS- чи CORBA-сервера, після чого вона стає сервером застосувань. Тепер клієнтські програми вже не містять у собі громіздкі коди компонентів-наборів і багатьох інших допоміжних компонентів. Виділення прикладного елемента в окремий ізольований компонент дозволяє зосередити в ньому реалізацію основної маси бізнес-правил і зробити клієнтські застосування незалежними від змін бізнес-логіки. У цьому випадку неправильні дані будуть відкидатися сервером застосувань і не будуть передаватися на сервер БД (рис.4).

Для одержання доступу до серверних даних клієнтські застосування звертаються до віддаленого серверу застосувань, що знаходиться на іншій машині і реалізує необхідний обмін даними. А функцію формування запитів до віддаленого сервера БД виконує сервер застосувань. На ньому ж розміщаються реальні набори даних - результати виконання запитів SQL-сервером.

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

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

Зауважимо, що на рис.5 ліворуч показаний варіант розміщення сервера застосувань на машині сервера БД. Такий варіант найбільш популярний, тому що знижує завантаження мережі і гарантує одночасну роботу обох серверів.

Сервер застосувань може розташовуватися на будь-якій мережній машині, оснащеній BDE у випадку роботи із клієнтським застосуванням створеним у середовищі Delphi. Зрозуміло, у цьому випадку каталог його розміщення повинен бути доступним іншим мережевим машинам, а сама машина сервера застосувань повинна бути включена в період роботи із сервером даних. Більш того, у цій архітектурі можна використовувати файл-серверний варіант розміщення даних (на рис1.5 - праворуч). Таким чином, замість сервера БД з успіхом можуть використовуватися файл-сервери з таблицями Dbase і Paradox. Переваги полегшеного клієнта і централізації бізнес-правил будуть повною мірою виявлятися й у цьому випадку. Крім того, в таких системах істотно знижується навантаження на мережу, тому що фільтрація і добір даних реалізуються сервером застосувань, а клієнту пересилаються лише результати запиту.

Отже, головна перевага триланкової архітектури полягає в створенні «полегшеного» клієнта, що не потребує великих ресурсів пам'яті та процесора і може завантажуватися з мережевого комп'ютера.

Зв'язок «тонких клієнтів» із сервером застосувань здійснюється засобами, що базуються на механізмах OLE - автоматизації й об’єктно-оріентованих викликів, що є стандартами для віддалених процедур у розподілених системах. На сьогоднішній день існують декілька технологій взаємодії б'єктів і програм, що паралельно розвиваються і конкурують : COM(Component Object Model - компонентна модель об'єктів) корпорації Microsoft , CORBA(Common Object Require Broker Architecture - архітектура з постачальником необхідних загальних об'єктів) незалежної групи OMG, MTS(Microsoft Transaction Server) та інші. Ці технології призначені для того, щоб одна програма(клієнт) змогла змусити працювати об'єкт, що є частиною іншої програми(частиною сервера), так, ніби цей об'єкт був частиною клієнта. Причому в загальному випадку обидві ці програми можуть бути розташовані на різних комп'ютерах( у тому числі, що знаходяться в різних частинах світу), написані на різних мовах і таких, що виконуються під керуванням різних операційних систем. Більш того самі омп'ютери можуть бути різного типу - наприклад, IBM- сумісний ПК і робоча станція SUN.