Введення до баз даних
Олексій Федоров, Наталія Єлманова
Перш ніж звернутися до конкретних продуктів, слід розглянути, що є архітектурою «клієнт-сервер», чим серверні СУБД відрізняються від настільних і які загальні риси сучасних серверних СУБД.
Архітектура «клієнт-сервер»
Як було зазначено в попередній статті, обробка даних за допомогою мейнфреймів та міні-ЕОМ, популярна в 70-ті роки, мала свої переваги, певною мірою втрачені пізніше, в епоху персональних комп'ютерів та настільних СУБД. Зокрема, однією з таких переваг була централізація зберігання та обробки даних. Однак повсюдне захоплення настільними СУБД та їх мережевими версіями, викликане доступністю та дешевизною як самого програмного забезпечення, так і його експлуатації, змусило багатьох користувачів на довгі роки забути про «мейнфреймову» модель обчислень.
Ми вже говорили про те, що недоліки настільних СУБД зазвичай виявляються не відразу, а лише в процесі тривалої експлуатації, коли обсяг даних, що зберігаються, і кількість користувачів стають досить великими — це призводить до зниження продуктивності додатків, які використовують такі СУБД.
Відомо багато випадків, коли для вирішення подібних проблем закуповувалося дороге мережеве обладнання з метою збільшення пропускної спроможності мережі, а також застосовувалися інші «хитрощі» на кшталт зберігання метаданих або часто використовуваних даних у клієнтських додатках або просто на локальних жорстких дисках. Нерідко також застосовувався підхід, що веде до децентралізації зберігання даних. Типовий приклад такого підходу — створення кількох однотипних локальних баз даних, наприклад для різних підрозділів компанії або для різних часових періодів (років, кварталів, місяців), що полегшувало роботу,пов'язану із введенням даних, але підвищувало вартість їхньої статистичної обробки та аналізу — у цьому випадку потрібно було обробляти дані з різних джерел. Однак усі ці заходи дозволяли лише відкласти на якийсь час вирішення проблеми зниження продуктивності, але не усували головної нестачі інформаційних систем, заснованих на настільних СУБД, — обробки даних у клієнтському додатку.
Радикальним вирішенням проблеми мережного трафіку та інших проблем, що виникають при збільшенні обсягу даних та числа користувачів, став перехід до архітектури «клієнт-сервер», що запозичила багато переваг старої «мейнфреймової» моделі обчислень, зокрема централізацію зберігання та обробки даних.
Принцип централізації зберігання та обробки даних є базовим принципом архітектури клієнт-сервер. Для його реалізації використовується так званий сервер баз даних, виконаний як додаток або сервіс операційної системи, і тільки він може реально маніпулювати файлами, в яких зберігаються дані, - для клієнтських додатків ці файли є абсолютно марними (і, при правильній організації доступу користувачів до файлів мережі, взагалі не повинні бути доступні).
Сервер баз даних здійснює цілий комплекс дій щодо управління даними. Основними його обов'язками є:
-
виконання запитів на вибір і модифікацію даних і метаданих, одержуваних від клієнтських додатків, що функціонують на персональних комп'ютерах локальної мережі;
підтримка цілісності посилань даних відповідно до визначених у базі даних правил;
Як робоче місце користувача може бути використаний звичайний персональний комп'ютер, що дозволяє невідмовлятися від звичного робочого середовища. Іншими словами, у найпростішому випадку клієнт-серверна інформаційна система складається з двох основних компонентів:
-
сервера баз даних, що управляє даними та виконує запити клієнтських додатків;
Існують і складніші реалізації архітектури «клієнт-сервер», наприклад багатоланкові інформаційні системи з використанням серверів додатків, що реалізують бізнес-логіку та здійснюють обробку даних. Однак обговорення архітектури таких систем знаходиться поза даним оглядом — про подібні системи ми, можливо, поговоримо в кінці цього циклу.
Переваги архітектури «клієнт-сервер»
Інформаційні системи, що використовують архітектуру «клієнт-сервер», мають серйозні переваги в порівнянні з їх аналогами, створеними на основі мережевих версій настільних СУБД. Нижче буде розглянуто найважливіші з них.
Однією з найважливіших переваг архітектури клієнт-сервер є зниження мережевого трафіку при виконанні запитів. Наприклад, при необхідності вибору п'яти записів з таблиці, що містить мільйон записів, клієнтська програма надсилає серверу запит, який сервером аналізується на коректність і, якщо запит коректний, компілюється, оптимізується і виконується. Після цього результат запиту (ті п'ять записів, а не вся таблиця) передається назад клієнту. При цьому, формулюючи запит, можна не замислюватися про те, чи є в базі даних індекси, здатні полегшити пошук потрібних записів, якщо вони є, то вони будуть використані сервером, а якщо ні, запит все одно буде виконаний, хоча, можливо, це займе більше часу, ніж привикористання індексів. Але в будь-якому випадку — є індекси чи ні — до клієнтського додатка передається лише результат запиту, і в цьому випадку мережевий трафік не залежить ні від наявності, ні від числа записів у таблицях, до яких зроблено запит.
Другою перевагою архітектури «клієнт-сервер» є можливість зберігання бізнес-правил (наприклад, правил цілісності посилань або обмежень на значення даних) на сервері, що дозволяє уникнути дублювання коду в різних клієнтських додатках, що використовують загальну базу даних. Крім того, в цьому випадку будь-яке редагування даних, у тому числі редагування засобами, не передбаченими розробниками інформаційної системи (наприклад, різними утилітами адміністрування сервера), може бути здійснене лише з урахуванням цих правил. Якщо останні версії деяких настільних СУБД і здатні зберігати обмеження на значення даних або тексти SQL-запитів, тригери і процедури, що зберігаються в них, як правило, відсутні — їх просто нікому виконувати. Винятком тут, мабуть, є лише Microsoft Data Engine, але, як ми вже говорили в попередній статті даного циклу, віднести до настільних цю СУБД можна досить умовно — фактично MSDE є локальним сервером баз даних, що володіє всіма характерними для серверної СУБД атрибутами, включаючи окремий серверний процес.
У першій статті цього циклу (див. Комп'ютерПрес 3'2000) ми вже згадували про те, що для опису серверних бізнес-правил у найбільш типових ситуаціях (наприклад, при реалізації зв'язків master/detail) нерідко використовуються так звані CASE-засоби (CASE означає Computer-Aided System Engineering) для створення діаграм "сутність-зв'язок". Ці інструменти дозволяють описати подібні правила на рівні логічної тафізичної моделі даних без будь-якого програмування, а потім згенерувати код відповідних серверних об'єктів - тригерів, збережених процедур, серверних обмежень. У цьому випадку клієнтські програми будуть позбавлені значної частини коду, пов'язаного з реалізацією бізнес-правил безпосередньо в додатку. Відзначимо також, що частина коду, пов'язаного з обробкою даних, також може бути реалізована у вигляді процедур сервера, що зберігаються, що дозволяє ще більше «полегшити» клієнтський додаток, а це означає, що вимоги до робочих станцій можуть бути не настільки високі. Це в кінцевому підсумку знижує вартість інформаційної системи навіть при використанні дорогих серверних СУБД і апаратного забезпечення.
Сучасні серверні СУБД мають також широкі можливості резервного копіювання та архівації даних, а нерідко й оптимізації виконання запитів. Вони також, як правило, надають можливість паралельної обробки даних, особливо у разі використання багатопроцесорних комп'ютерів як сервер баз даних.
Отже, ми розглянули переваги архітектури клієнт-сервер і переконалися, що ця технологія вирішує багато проблем, що виникають при використанні настільних СУБД. Однак перед тим, як обговорювати найбільш популярні серверні СУБД, звернемо увагу на те, якими способами вирішується проблема модернізації застарілих інформаційних систем, заснованих на настільних СУБД, з метою переходу до архітектури «клієнт-сервер», і з якими проблемами при цьому можна зіткнутися. .
Модернізація застарілих інформаційних систем
З проблемою модернізації застарілих інформаційних систем рано чи пізно стикається майже кожен розробник чи IT-менеджер. У нашій країні все ще не важко зустрітибанківські системи, що використовують dBase, а також відносно нові комерційні розробки, створені за допомогою Clipper, засобом обміну даними яким служать аж ніяк не Internet і не мережеві протоколи, а кур'єр з дискетами та електричка (це зовсім не завжди відбувається через непоінформованість розробників - просто у їхніх клієнтів немає і найближчим часом не буде грошей на пристойне обладнання та відповідну інфраструктуру). Саме тому ми вважаємо, що проблема модернізації інформаційних систем в Україні ще довго залишатиметься актуальною.
У кожній організації, що переживає процес модернізації інформаційної системи, виникають проблеми. В одній користувачі вимагають зберегти звичний інтерфейс користувача (ті, хто давно програмує на Delphi, напевно, пам'ятають популярне завдання з серії «угоди користувачеві, що звикли до DOS», — як у формі введення даних змусити клавішу Enter робити те, що зазвичай робить клавіша Tab ); в іншій потрібно зуміти не просто перенести в нову базу успадковані дані, а й змінити їх відповідно до потреб, що виникли (наприклад, виправити помилки, допущені багато років тому при проектуванні даних, або об'єднати дані з декількох різних джерел); у третій організації збереглося і використовується велика кількість звітів, створених за допомогою старої настільної СУБД, і необхідно забезпечити можливість їх використання у новій інформаційній системі; у четвертій процес введення нових даних відбувається безперервно, і це накладає обмеження на те, як саме робити процес заміни СУБД та клієнтських додатків.
1. Заміна СУБД із збереженням структури бази даних та додатків користувача (або відносно невеликою їх модернізацією).
2. Заміна і СУБД, і користувацькихдодатків із збереженням структури бази даних.
3. Заміна СУБД, додатків користувача і одночасна модернізація структури бази даних.
Якщо говорити про перший варіант модернізації, у цьому відношенні найбільше пощастило користувачам Microsoft Access - процес заміни бази даних Microsoft Access на MSDE (або Microsoft SQL Server) відбувається досить безболісно, і програми користувача при цьому зазвичай зберігають свою працездатність. Оскільки у разі всі ці СУБД (Access, MSDE і SQL Server) належать одному виробнику, перенесення даних з-поміж них здійснюється цілком коректно, зі збереженням всіх визначених у базі даних бізнес-правил. Крім того, утиліти перенесення даних з Access містяться в комплекті постачання та інших серверних СУБД (наприклад, Oracle). Відносно безболісно можна перенести дані з Visual FoxPro до Microsoft SQL Server.
Щодо заміни інших версій настільних СУБД на серверні, тут можуть виникнути певні проблеми. Наприклад, при перенесенні даних з dBase або Paradox в яку-небудь серверну СУБД, що обслуговує їх додаток, написаний на Delphi, цілком може відмовитися працювати навіть після коректного переналаштування бібліотек доступу до даних, особливо якщо воно містить відомості про метадані. Можливі також різні неприємності, пов'язані з використанням малих і великих літер у найменуваннях полів, застосуванням українських найменувань полів (і взагалі локалізованих версій, що підтримують національні традиції написання чисел і дат і нерідко перетворюють числові дані та дати при переносі в іншу СУБД на щось неймовірно) , несумісності деяких типів даних (це особливо часто відбувається при перенесенні таблиць Paradox до інших СУБД). Нарешті, якщо у сервернійСУБД визначено будь-які бізнес-правила, немає жодної гарантії, що вони ідеально дотримувалися в настільній СУБД, з якої переносяться дані, і в цьому випадку деяка кількість «ручної» праці з розбору даних, що не відповідають цим правилам, вам або вашим користувачам гарантовано .
Другий варіант модернізації інформаційної системи є по суті створення нового проекту по готовій моделі даних плюс щойно розглянуте перенесення даних до нової СУБД. Що стосується третього варіанта модернізації, його можна розглядати як два самостійні проекти. Перший є створення інформаційної системи практично «з нуля», другий — заповнення бази успадкованими даними. При цьому, оскільки структури баз даних різні, стандартними утилітами перенесення даних (є в комплекті постачання багатьох засобів розробки та серверних СУБД) тут зазвичай обійтися не вдається — як правило, у цьому випадку створюються «одноразові» додатки, які роблять необхідні перетворення даних у процесі їх перенесення.
Обговоривши проблеми, що виникають під час перенесення інформаційних систем, використовували настільні СУБД, в архітектуру «клієнт-сервер», можна перейти до обговорення того, які послуги надають сучасні серверні СУБД і чим із цього погляду слід керуватися під час їх вибору.