Клієнт-серверна модель
Сучасна СУБД повинна задовольняти ряду вимог, найважливіше у тому числі - високопродуктивний інтелектуальний сервер бази даних. Далі ми розглянемо основні тенденції його розвитку і обговоримо конкретні механізми, в яких вони знаходять своє втілення.
Процес технічного вдосконалення сервера бази даних поки залишається невидимим для більшості користувачів сучасних СУБД. Тому при виборі тієї чи іншої системи вони, як правило, не враховують ні технічний рівень рішень, закладених в механізм його функціонування, ні вплив цих рішень на загальну продуктивність СУБД. Тим часом її якість визначається аж ніяк не багатством інтерфейсів з користувачем, що не різноманітністю засобів підтримки розробок, а в першу чергу залежить від особливостей архітектури сервера бази даних. Далі будуть розглянуті моделі технології "клієнт-сервер", визначено місце сервера БД в цих моделях і коротко описані найважливіші механізми сервера БД - процедури, правила (тригери), події. Останні будуть проілюстровані прикладами, в яких використаний діалект SQL, прийнятий в СУБД Ingres.
Технологія і моделі "клієнт-сервер".
"Клієнт-сервер" - це модель взаємодії комп'ютерів в мережі. Як правило, комп'ютери не є рівноправними. Кожен з них має своє, відмінне від інших, призначення, грає свою роль. Деякі комп'ютери в мережі володіють і розпоряджається інформаційно-обчислювальними ресурсами, такими як процесори, файлова система, поштова служба, служба друку, база даних. Інші ж комп'ютери мають можливість звертатися до цих служб, користуючись послугами перших. Комп'ютер, керуючий тим чи іншим ресурсом, прийнято називати сервером цього ресурсу, а комп'ютер, який бажає їм скористатися - клієнтом. Конкретний сервер визначається видом ресурсу, яким він володіє. Так, якщо ресурсом є бази даних, то мова йде про сервер баз даних. призначення якого - обслуговувати запити клієнтів, пов'язані з обробкою даних; якщо ресурс - це файлова система, то говорять про файловому сервері. або файл-сервері, і т. д.
У мережі один і той же комп'ютер може виконувати роль як клієнта, так і сервера. Наприклад, в інформаційній системі, що включає персональні комп'ютери, велику ЕОМ і міні-комп'ютер під керуванням UNIX, останній може виступати як в якості сервера бази даних, обслуговуючи запити від клієнтів - персональних комп'ютерів, так і в якості клієнта, направляючи запити великий ЕОМ.
Цей же принцип поширюється і на взаємодію програм. Якщо одна з них виконує деякі функції, надаючи іншим відповідний набір послуг, то така програма виступає в якості сервера. Програми, які користуються цими послугами, прийнято називати клієнтами. Так, ядро реляційної SQL-орієнтованої СУБД часто називають сервером бази даних, або SQL-сервером, а програму, що обертається до нього за послугами з обробки даних - SQL-клієнтом.
Спочатку СУБД мали централізовану архітектуру (рисунок 10). У ній сама СУБД і прикладні програми, які працювали з базами даних, функціонували на центральному комп'ютері (велика ЕОМ або міні-комп'ютер). Там же розташовувалися бази даних. До центрального комп'ютера були підключені термінали, які виступали в якості робочих місць користувачів. Всі процеси, пов'язані з обробкою даних, як: підтримка введення, здійснюваного користувачем, формування, оптимізація і виконання запитів, обмін з пристроями зовнішньої пам'яті і т.д. виконувалися на центральному комп'ютері, що подавала жорсткі вимоги до його продуктивності. Особливості СУБД першого покоління безпосередньо пов'язані з архітектурою систем великих ЕОМ і міні-комп'ютерів і адекватно відображають всі їхні переваги і недоліки. Однак нас більше цікавить сучасний стан багатокористувацьких СУБД, для яких архітектура "клієнт-сервер" стала фактичним стандартом.
Малюнок 10 - Системи з централізованою архітектурою
Для більш чіткого уявлення про її особливості необхідно розглянути кілька моделей технології "клієнт-сервер", що і буде зроблено.
Якщо передбачається, що проектована інформаційна система (ІС) буде мати технологію "клієнт-сервер", то це означає, що прикладні програми, реалізовані в її рамках, будуть мати розподілений характер. Іншими словами, частина функцій прикладної програми (або, простіше, додатки) буде реалізована в програмі-клієнті, інша - в програмі-сервері, причому для їх взаємодії буде визначено певний протокол.
Основний принцип технології "клієнт-сервер" полягає в поділі функцій стандартного інтерактивного додатки на чотири групи, що мають різну природу. Перша група - це функції введення і відображення даних. Друга група об'єднує чисто прикладні функції, характерні для даної предметної області (наприклад, для банківської системи - відкриття рахунку, переказ грошей з одного рахунку на інший і т.д.). До третьої групи відносяться фундаментальні функції зберігання та управління інформаційними ресурсами (базами даних, файловими системами і т.д.). Нарешті, функції четвертої групи - це службові функції (які відіграють роль зв'язок між функціями перших трьох груп.
Відповідно до цього в будь-якому додатку виділяються наступні логічні компоненти:
- компонент уявлення, який реалізує функції першої групи;
- прикладної компонент, що підтримує функції другої групи;
- компонент доступу до інформаційних ресурсів, що підтримує функції третьої груп, а також вводяться і уточнюються угоди про способи їх взаємодії (протокол взаємодії).
Відмінності в реалізаціях технології "клієнт-сервер" визначаються чотирма факторами. По-перше, тим, у які види програмного забезпечення інтегровані кожен з цих компонентів. По-друге, тим, які механізми програмного забезпечення використовуються для реалізації функцій всіх трьох груп. По-третє, як логічні компоненти розподіляються між комп'ютерами в мережі. По-четверте, які механізми використовуються для зв'язку компонентів між собою.
Виділяються чотири підходи, реалізовані в моделях:
· Модель файлового сервера (File Server - FS);
· Модель доступу до віддалених даних (Remote Data Access - RDA);
· Модель півночі бази даних (DataBase Server - DBS);
· Модель сервера додатків (Application Server - AS).
FS-модель є базовою для локальних мереж персональних комп'ютерів. Не так давно вона була виключно популярною серед вітчизняних розробників, які використовували такі системи, як FoxPRO, Clipper, Clarion, Paradox і т.д. Суть моделі проста і всім відома. Один з комп'ютерів в мережі вважається файловим сервером і надає послуги з обробки файлів інших комп'ютерів. Файловий сервер працює під управлінням мережевої операційної системи (наприклад, Novell NetWare) і грає роль компонента доступу до інформаційних ресурсів (тобто до файлів). На інших комп'ютерах в мережі функціонує додаток, в кодах якого суміщені компонент уявлення та прикладної компонент (рисунок 11). Протокол обміну являє собою набір низькорівневих викликів, що забезпечують додатком доступ до файлової системи на файл-сервері.
Малюнок 11 - Модель файлового сервера
FS-модель послужила фундаментом для розширення можливостей персональних СУБД в напрямку підтримки багато режиму. У таких системах на кількох персональних комп'ютерах виконується як прикладна програма, так і копія СУБД, а бази даних містяться в поділюваних файлах, які знаходяться на файловому сервері. Коли прикладна програма звертається до бази даних, СУБД направляє запит на файловий сервер. У цьому запиті вказані файли, де знаходяться запитувані дані. У відповідь на запит файловий сервер направляє по мережі необхідний блок даних. СУБД, отримавши його, виконує над даними дії, які були декларовані в прикладній програмі.
До технологічних недоліків моделі відносять високий мережевий трафік (передача безлічі файлів, необхідних додатку), вузький спектр операцій маніпуляції з даними ( "дані - це файли"), відсутність адекватних засобів безпеки доступу до даних (захист тільки на рівні файлової системи) і т. д. Власне, перераховане не їсти недоліки, але - наслідок внутрішньо властивих FS-моделі обмежень, визначених її характером. Непорозуміння виникають, коли FS-модель використовують не за призначенням, наприклад, намагаються інтерпретувати як модель сервера бази даних. Місце FS-моделі в ієрархії моделей "клієнт-сервер" - це місце моделі файлового сервера, і нічого більше. Саме тому приречені на провал спроби створення на основі FS-моделі великих корпоративних систем - спроби, які робилися в недавньому минулому і нерідко робляться зараз.
Більш технологічна RDA-модельсущественно відрізняється від FS-моделі характером компонента доступу до інформаційних ресурсів. Це, як правило, SQL-сервер. У RDA-моделі коди компонента уявлення і прикладного компонента суміщені і виконуються на комп'ютері-клієнті. Останній підтримує як функції введення і відображення даних, так і чисто прикладні функції. Доступ до інформаційних ресурсів забезпечується або операторами спеціального мови (мови SQL, наприклад, якщо мова йде про бази даних), або викликами функцій спеціальної бібліотеки (якщо є відповідний інтерфейс прикладного програмування - API).
Клієнт направляє запити до інформаційних ресурсів (наприклад, до баз даних) по мережі віддаленого комп'ютера. На ньому функціонує ядро СУБД, яке обробляє запити, виконуючи зазначені в них дії, і повертає клієнтові результат, оформлений як блок даних (малюнок 12). При цьому ініціатором маніпуляцій з даними виступають програми, виконуються на комп'ютерах-клієнтах, в той час як ядру СУБД відводиться пасивна роль - обслуговування запитів та обробка даних.
Малюнок 12 - Модель доступу до віддалених даних
RDA-модель позбавляє від недоліків, властивих як системам з централізованої архітектурою, так і системам з файловим сервером.
Перш за все перенесення компонента уявлення і прикладного компонента на комп'ютери-клієнти істотно розвантажує сервер БД, зводячи до мінімуму загальне число процесів операційної системи. Сервер БД звільняється від невластивих йому функцій; процесор або процесори сервера цілком завантажуються операціями обробки даних, запитів і транзакцій. Це стає можливим завдяки відмові від терміналів і оснащенню робочих місць комп'ютерами, які володіють власними локальними обчислювальними ресурсами, повністю використовуваними програмами переднього плану. З іншого боку, різко зменшується завантаження мережі, так як по ній передаються від клієнта до сервер не запити на вхід-видобуток (як в системах з файловим сервером), а запити на мові SQL, їх обсяг істотно менше.
Основна перевага RDA-моделі - уніфікація інтерфейсу "клієнт-сервер" у вигляді мови SQL. Дійсно, взаємодія прикладного компонента з ядром СУБД неможливо без стандартизованого кошти спілкування. Запити, що направляються програмою ядра, повинні бути зрозумілі обом. Для цього їх слід сформулювати на спеціальній мові. Але в СУБД вже існує мова SQL, про який вже йшла мова. Тому доцільно використовувати його не тільки як засіб доступу до даних, але і стандарту спілкування клієнта і сервера.
Таке спілкування можна порівняти з бесідою кількох людей, коли один відповідає на питання інших (запитання ставляться одночасно). Причому робить це він так швидко, що час очікування відповіді наближається до нуля. Висока швидкість спілкування досягається насамперед завдяки чіткому формулюванню питання, коли запитувачу і відповідає не потрібно додаткових консультацій по суті питання. Розмовляли обмінюються кількома короткими однозначними фразами, їм нічого не потрібно уточнювати.
На жаль, RDA-модель не позбавлена ряду недоліків. По-перше, взаємодія клієнта і сервера за допомогою SQL-запитів істотно завантажує мережу. По-друге, задовільний адміністрування додатків в RDA-моделі практично неможливо через суміщення лише у програмі різних за своєю природою функцій (функції уявлення та прикладні).
Поряд з RDA-моделлю все більшої популярності набуває перспективна DBS-модель (рисунок 13). Остання реалізована в деяких реляційних СУБД (Informix, Ingres, Sybase, Oracle). Її основу становить механізм збережених процедур - засіб програмування SQL-сервера. Процедури зберігаються в словнику бази даних, розділяються між декількома клієнтами і виконуються на тому ж комп'ютері, де функціонує SQL-сервер. Мова, на якому розробляються збережені процедури, представляє собою процедурне розширення мови запитів SQL і унікальний для кожної конкретної СУБД.
Малюнок 13 - Модель сервера бази даних
У DBS-моделі компонент подання виконується на комп'ютері-клієнті, в той час як прикладної компонент оформлений як набір збережених процедур і функціонує на комп'ютері-сервері БД. Там же виконується компонент доступу до даних, тобто ядро СУБД. Переваги DBS-моделі очевидні: це і можливість централізованого адміністрування прикладних функцій, і зниження трафіку (замість SQL-запитів по мережі направляються виклики збережених процедур), і можливість поділу процедури між декількома додатками, і економія ресурсів комп'ютера за рахунок використання раз створеного плану виконання процедури . До недоліків моделі можна віднести обмеженість коштів, які використовуються для написання збережених процедур, які представляють собою різноманітні процедурні розширення SQL, що не витримують порівняння з образотворчим засобам і функціональними можливостями з мовами третього покоління, такими як C або Pascal. Сфера їх використання обмежена конкретною СУБД, в більшості СУБД відсутні можливості налагодження і тестування розроблених збережених процедур.
На практиці часто використовується змішані моделі, коли підтримка цілісності бази даних і деякі найпростіші прикладні функції підтримуються збереженими процедурами (DBS-модель), а більш складні функції реалізуються безпосередньо в прикладній програмі, яка виконується на комп'ютері-клієнті (RDA-модель). Так чи інакше сучасні розраховані на багато користувачів СУБД спираються на RDA- і DBS-моделі і при створенні ІС, який передбачає використання тільки СУБД, вибирають одну з цих двох моделей або їх розумне поєднання.
Модель сервера додатків.
В AS-моделі (рисунок 14) процес, що виконується на комп'ютері-клієнті, відповідає, як зазвичай, за інтерфейс з користувачем (тобто здійснює функції першої групи). Звертаючись за виконанням послуг до прикладного компоненту, цей процес відіграє роль клієнта додатка (Application Client - AC). Прикладний компонент реалізований як група процесів, що виконують прикладні функції, і називається сервером додатка (Application Server - AS). Всі операції над інформаційними ресурсами виконуються відповідним компонентом, по відношенню до якого AS грає роль клієнта. З прикладних компонентів доступні ресурси різних типів - бази даних, черги, поштові служби і ін.
RDA- і DBS-моделі спираються на двухзвенную схему поділу функцій. У RDA-моделі прикладні функції додані програми-клієнта, в DBS-моделі відповідальність за їх виконання бере на себе ядро СУБД. У першому випадку прикладної компонент зливається з компонентом уявлення, по-другому - інтегрується в компонент доступу до інформаційних ресурсів. В AS-моделі реалізована трехзвенная схема поділу функцій, де прикладної компонент виділено як найважливіший ізольований елемент програми, для його визначення використовуються універсальні механізми багатозадачного операційної системи, і стандартизовані інтерфейси з двома іншими компонентами. AS-модель є фундаментом для моніторів обробки транзакцій (Transaction Processing Monitors - TPM), або, простіше, моніторів транзакцій, які виділяються як особливий вид програмного забезпечення.
На закінчення відзначимо, що, часто, говорячи про сервер бази даних, мають на увазі як комп'ютер, так і програмне забезпечення - ядро СУБД. При описі архітектури "Клієнт-сервер" під сервером бази даних ми мали на увазі комп'ютер. Далі сервер бази даних буде розумітися як програмне забезпечення - ядро СУБД.