Системи управління базами даних - коротко про головне

1. 3.1. Аспекти мережевої взаємодії
2. прозорість мережі
3. Автоматичне перетворення форматів даних
4. Автоматична трансляція кодів
5. 3.2. Розподілені бази даних
6. 3.3. Технологія тиражування даних
7. 3.4. Взаємодія з PC-орієнтованими СУБД

Г. М. Ладиженський

Jet Infosystems, тел .: (095) 972-11-82

Одна з головних особливостей сучасних інформаційних систем -розподіленого характер. Зростає їх масштаб, вони охоплюють все більше число точок по всьому світу. Сучасний рівень прийняття рішень, оперативне управління інформаційними ресурсами вимагає все більшої їх децентралізації. Інформаційні системи знаходяться в постійному розвитку - в них додаються нові сегменти, розширюється діапазон функцій вже діючих. Прикладом розподіленої системи може послужити система резервування квитків великої авіакомпанії, що має свої філії в різних частинах Землі. Головна проблема таких систем - організація обробки розподілених даних. Дані знаходяться на комп'ютерах різних моделей і виробників, що функціонують під управлінням різних операційних систем, а доступ до даних здійснюється різнорідним програмним забезпеченням. Самі комп'ютери територіально віддалені один від одного і знаходяться в різних географічних точках планети. Відповіддю на завдання реальному житті стали дві технології: технологія розподілених баз даних (Distributed Database) і технологія тиражування даних (Data Replication).

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

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

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

3.1. Аспекти мережевої взаємодії

У Розділі 2 були розглянуті чотири моделі технології "клієнт-сервер". Традиційною і найбільш популярною є модель доступу до віддалених даних (RDA-модель). Розглянемо її ще раз, але більш детально. Отже, є комп'ютер, на якому запускаються програми переднього плану (в яких реалізовані як функції інтерфейсу з користувачем, так і прикладні функції) - клієнт (званий зазвичай локальним вузлом - local node), з'єднаний в мережі з комп'ютером, на якому виконується сервер бази даних , і знаходиться сама база даних (зазвичай його називають віддаленим вузлом - remote node). Всі проблеми, що виникають при взаємодії клієнта і сервера, повинен вирішувати спеціальний компонент СУБД, званий комунікаційним сервером (Communication Server, DBMS Server Net). Для підтримки взаємодії клієнта і сервера він повинен функціонувати на віддаленому вузлі; в той же час на локальному вузлі повинна виконуватися програма зв'язку, взаємодіюча з комунікаційним сервером (DBMS Client Net).

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

• прозорість розташування
• прозорість мережі
• Автоматичне перетворення форматів даних
• Автоматична трансляція кодів
• Межоперабельность
• прозорість розташування

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

Будь-який користувач або будь-яка прикладна програма оперує з однією або декількома базами даних. У тому випадку, коли прикладна програма і сервер БД виконуються на одному і тому ж вузлі, проблеми розташування не виникає. Для отримання доступу до бази даних користувачеві або програмою досить вказати ім'я бази даних, наприклад: SQL DBname де DBname - ім'я бази даних.

Однак в тому випадку, коли прикладна програма запускається на локальному вузлі, а база даних знаходиться на віддаленому, то виникає проблема ідентифікації віддаленого вузла. Для того, щоб отримати доступ до бази даних на віддаленому вузлі, необхідно вказати ім'я віддаленого вузла і ім'я бази даних. Якщо використовувати жорстко фіксоване ім'я вузла в парі "імя_узла, імя_БД", то прикладна програма стає залежною від розташування БД. Наприклад, звернення до БД "host :: stock", де перший компонент є ім'я вузла, буде залежним від розташування.

Одне з можливих рішень цієї проблеми полягає у використанні віртуальних імен вузлів. Управління ними забезпечується спеціальним програмним компонентом СУБД - сервером імен (Name Server), який адресує запити клієнтів до серверів.

При установці компоненти DBMS Client Net на локальних вузлах виконується процедура ідентифікації вузлів, коли реальному імені віддаленого вузла ставиться у відповідність віртуальне ім'я, яке потім використовується при зверненні до бази даних. Якщо база даних перенесена на інший вузол, то ніяких змін в прикладну програму вносити не потрібно - досить лише поставити у відповідність віртуальному імені вузла ім'я нового вузла.

прозорість мережі

Клієнт і сервер взаємодіють через мережу з конкретною топологією; для підтримки взаємодії завжди використовується певний протокол. Отже, воно повинно бути організовано таким чином, щоб забезпечувати незалежність як від використовуваного мережного апаратного забезпечення, так і від протоколів мережевого обміну. Щоб забезпечити прозорий доступ користувачів і програм до віддалених даних в мережі, що об'єднує різнорідні комп'ютери, комунікаційний сервер повинен підтримувати як можна більш широкий діапазон мережевих протоколів (TCP / IP, DECnet, SNA, SPX / IPX, NetBIOS, AppleTalk, і ін.).

Автоматичне перетворення форматів даних

Як тільки кілька комп'ютерів різних моделей під управлінням різних операційних систем з'єднуються в мережу, відразу виникає питання про узгодження форматів представлення даних. Дійсно, в мережі можуть бути комп'ютери, що відрізняються розрядністю (16-ти, 32-х і 64-х розрядні процесори), порядком проходження байт в слові, поданням чисел з плаваючою точкою і т.д. Завдання комунікаційного сервера полягає в тому, щоб на рівні обміну даними забезпечити узгодження їх форматів між віддаленим і локальним вузлами про те, щоб дані, витягнуті з бази даних сервером на віддаленому вузлі і передані по мережі, були б правильно витлумачені прикладної програмою на локальному вузлі.

Автоматична трансляція кодів

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

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

Системи з архітектурою "один-до-одного" (див. Розділ 2) для обслуговування сервером бази даних одночасно безлічі клієнтів змушені завантажувати окремий комунікаційний сервер для кожної пари "клієнт-сервер". В результаті навантаження на операційну систему збільшується, різко зростає загальне число її процесів, що витрачають обчислювальні ресурси. Це - один з рецидивів архітектури "один-до-одного".

Саме тому для сучасних розподілених СУБД важливо мати багатопотокових комунікаційний сервер, який бере на себе завдання мережевий підтримки безлічі клієнтів, одночасно звертаються до сервера. На кожному вузлі мережі він підтримує безліч пар сполук "клієнт-сервер" і дозволяє існувати одночасно безлічі незалежних сеансів роботи з базами даних.

3.2. Розподілені бази даних

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

Розглянемо приклад. Нехай БД Склад розташована на вузлі Узел_1, а БД Підприємства - на вузлі Узел_2. У першій міститься таблиця Деталь, у другій - Постачальник. Нехай БД Номенклатура повинна включати таблиці Деталь і Постачальник, фізично належать різним БД. Логічно вона буде розглядатися як нерозподілений БД. Нижче наведені оператори SQL, які встановлюють посилання на таблиці локальних баз даних. Вони включені в опис розподіленої бази даних і передаються сервера розподіленої БД, про який мова піде нижче.

Таким чином, при описі розподіленої БД Номенклатура явно задаються посилання на конкретні таблиці реально існуючих баз даних; однак при роботі з такою базою даних це фізичний розподіл даних прозоро для користувача.

До сих пір ми говорили про проблеми мережевої взаємодії клієнта і сервера. Їх рішення за допомогою комунікаційного сервера є необхідним (але не достатньою) умовою підтримки розподілених баз даних. Невирішеними поки залишаються наступні завдання:

• Управління іменами в розподіленої середовищі;
• Оптимізація розподілених запитів;
• Управління розподіленими транзакціями.

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

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

Що стосується другого завдання, то вона вимагає інтелектуального рішення. Розподілений запит торкається кількох баз даних на різних вузлах, причому обсяги вибірки можуть бути дуже різними. Звернемося до БД Номенклатура, яка розподілена по двом вузлам мережі. Таблиця Деталь зберігається на одному вузлі, таблиця Постачальники - на іншому. Розмір першої таблиці - 10000 рядків, розмір другої - 100 рядків (безліч деталей поставляється невеликим числом постачальників). Припустимо, що виконується запит:

Результат запиту - таблиця, яка містить стовпець Названіе_деталі з таблиці Деталь, і стовпці Названіе_поставщіка і Адрес_поставщіка з таблиці Постачальник. Тобто результуюча таблиця являє собою об'єднання (join) двох таблиць. Воно виконане по стовпцю Номер_поставщіка в таблиці Деталь (зовнішній ключ) і одну Номер таблиці Постачальник (первинний ключ).

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

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

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

Рішення всіх трьох завдань, про які йшлося вище, покладено на спеціальний компонент СУБД - сервер розподілених баз даних (Distributed Database Server).

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

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

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

Для СУБД це якість означає наступне:

• можливість додатків, створених засобами розробки даної СУБД, оперувати над базами даних в "чужому" форматі так, як ніби це власні бази даних;
• властивість СУБД, що дозволяє їй служити в якості постачальника даних для будь-яких додатків, створених засобами розробки третіх фірм, що підтримують певний стандарт звернення до баз даних.

Перше досягається використанням шлюзів, друге - використанням інтерфейсу ODBC, який буде розглянуто в п.3.4.

До сих пір ми розглядали однорідні бази даних, тобто БД в форматі конкретної СУБД. У той же час СУБД може здійснювати доступ до БД в іншому форматі. Це робиться за допомогою шлюзу. Наприклад, СУБД INGRES отримує доступ до бази даних в форматі СУБД Rdb через спеціальний шлюз. Якщо СУБД Альфа здійснює доступ до бази даних в форматі Бета (або просто до бази даних Бета), то говорять, що Альфа має шлюз в Бета.

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

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

Малюнок 1.

Глобальна база даних розподілена по трьох вузлів. Вузол A - це комп'ютер VAX 6000/560 з ОС VMS і СУБД Rdb, де розташована локальна БД Підприємства в форматі Rdb. Другий (вузол B) представляє собою комп'ютер SUN Sparc Server 1000 під керуванням операційної системи Solaris. На ньому функціонує СУБД Ingres і знаходиться локальна БД Склад в форматі INGRES. Як вузла C виступає mainframe IBM c операційною системою MVS і СУБД DB2. На ньому розташована локальна БД Інструмент в форматі DB2.

Сервер розподіленої БД - компонент СУБД Ingres - виконується на вузлі B. Комунікаційні сервери Ingres працюють на всіх трьох вузлах. Вузли A і B використовують для взаємодії протокол TCP / IP, в той час як вузли B і C спілкуються відповідно до стандарту SNA.

Локальні БД на всіх трьох вузлах управляються абсолютно автономно. Розподілена БД Виробництво містить таблиці з усіх трьох локальних БД. Для доступу сервера розподіленої БД до БД Підприємства необхідний шлюз з Ingres в Rdb, а для доступу до БД Інструмент - шлюз з Ingres в DB2.

Шлюз з Ingres в DB2 дозволяє маніпулювати даними в форматі DB2 так, як ніби вони - дані в форматі Ingres. Шлюз з Ingres в Rdb дозволяє оперувати з даними у форматі Rdb так, як ніби вони - дані в форматі Ingres.

Всі ці деталі не видно кінцевому користувачеві. Він працює з БД Виробництво так, як ніби це централізована БД Ingres. Це і є повністю прозорий доступ до даних.

Відзначимо, що технологія розподілених БД захищає інвестиції в програмне забезпечення. Вона може розглядатися як "міст", перекинутий від mainframe-систем і нереляційних СУБД до сучасним професійним СУБД на платформі RISC-комп'ютерів. Вона дозволяє розробляти для них прикладні програми, забезпечуючи їм доступ до величезних масивів інформації на великих ЕОМ і тим самим гарантує м'який і безболісний перехід до нової платформи.

3.3. Технологія тиражування даних

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

Тиражування даних - це асинхронний перенесення змін об'єктів вихідної бази даних (source database) в БД, що належить різним вузлам розподіленої системи. Функції тиражування даних виконує спеціальний модуль СУБД - сервер тиражування даних, званий репликатором (replicator). Його завдання - підтримка ідентичності даних у приймаючих базах даних (target database) даним в вихідної БД. Сигналом для запуску реплікатора служить спрацьовування правила (див. Розділ 2), що перехоплює будь-які зміни тиражируемого об'єкта БД. Можливо і програмне керування репликатором за допомогою сигналізаторів про події в базі даних.

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

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

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

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

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

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

3.4. Взаємодія з PC-орієнтованими СУБД

Спочатку професійні СУБД створювалися для потужних високопродуктивних платформ - IBM, DEC, Hewlett-Packard, Sun Але потім, беручи до уваги зростання популярності і широке поширення персональних комп'ютерів, їх розробники приступили до перенесення (портированию) СУБД в операційні середовища desktop-комп'ютерів (OS / 2 , NetWare, UnixWare, SCO UNIX).

В даний час більшість компаній - постачальників СУБД розвиває три напрямки своїх систем. По-перше, вдосконалення СУБД для корпоративних інформаційних систем, які характеризуються великою кількістю користувачів (від 100 і вище), базами даних величезного обсягу (їх часто називають надвеликими базами даних - Very Large Data Base - VLDB), змішаним характером обробки даних (рішення задач оперативної обробки транзакцій і підтримки прийняття рішень) і т.д. Це - традиційна область mainframe-систем і наближаються до них по продуктивності RISC-комп'ютерів.

Інше, не менш важливий напрямок - СУБД, що підтримують так звані робочі групи. Цей напрямок характеризується відносно невеликою кількістю користувачів (камерний характер застосування СУБД) зі збереженням, проте, всіх "багатокористувацьких" якостей. Системи цього класу орієнтовані переважно на "офісні" застосування, які не потребують спеціальних можливостей. Так, більшість сучасних багатокористувацьких СУБД має версії системи, функціонуючі в мережевий операційній системі Novell NetWare. Ядро СУБД оформлено тут як завантажуваний модуль NetWare NetWare Loadable Module - NLM), що виконується на файловому сервері. База даних також розташовується на файловому сервері. SQL-запити надходять до ядру СУБД від прикладних програм, які запускаються на станціях мережі - персональних комп'ютерах (відзначимо, що, незважаючи на використання файлового сервера, тут ми маємо справу з RDA-моделлю).

Нарешті, новий імпульс у розвитку отримало напрямок desktop-версій СУБД, орієнтованих на персональне використання - переважно в операційному середовищі MS Windows (системи цього класу отримали неформальне визначення "light").

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

В останні роки (1987-94) в нашій країні було розроблено безліч програм, орієнтованих на використання СУБД типу PARADOX, FoxPRO, dBASE IV, Clipper. При переході на більш потужну багато користувачів СУБД у користувачів виникає природне бажання інтегрувати вже існуючі розробки в цю середу. Наприклад, може виникнути потреба зберігати локальні дані на персональному комп'ютері і здійснювати до них доступ за допомогою системи FoxPRO, і одночасно мати доступ до глобальної базі даних під керуванням СУБД Oracle. Організація такого доступу, коли програма може одночасно працювати і з персональної, так і з розрахованої на багато користувачів СУБД являє собою складну проблему з наступних причин.

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

Фахівці фірми Microsoft розробили стандарт Open Database Connectivity (ODBC). Він являє собою стандарт інтерфейсу прикладних програм (Application Programming Interface - API) і дозволяє програмам, що працюють в середовищі Microsoft Windows, взаємодіяти (за допомогою операторів мови SQL) з різними СУБД, як з персональними, так і з розрахованими на багато користувачів, що функціонують в різних операційних системах. Фактично, інтерфейс ODBC універсальним чином відокремить чисто прикладну, змістовний бік додатків (обробка електронних таблиць, статистичний аналіз, ділова графіка) від власне обробки та обміну даними з СУБД. Основна мета ODBC - зробити взаємодію додатки і СУБД прозорим, не залежних від класу і особливостей використовуваної СУБД (мобільним з точки зору використовуваної СУБД).

Відзначимо, що стандарт ODBC є невід'ємною частиною сімейства стандартів, які полегшують написання і забезпечують вертикальну відкритість додатків (WOSA - Windows Open Services Architecture - відкрита архітектура сервісів системи Windows).

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

Малюнок 2.

ODBC-архітектура містить чотири компоненти:

• додаток;
• менеджер драйверів;
• драйвери;
• джерела даних.

Ролі серед них розподілені наступним чином. Додаток викликає функції ODBC для виконання SQL-інструкцій, отримує і інтерпретує результати; менеджер драйверів завантажує ODBC-драйвери, коли цього вимагає додаток; ODBC-драйвери обробляють виклики функцій ODBC, передають оператори SQL СУБД і повертають результат у додаток; джерело даних (data source) - об'єкт, що приховує СУБД, деталі мережного інтерфейсу, розташування і повне ім'я бази даних і т.д.

Дії, що виконуються додатком, що використовує інтерфейс ODBC, зводяться до наступного: для початку сеансу роботи з базою даних додаток має підключитися до джерела даних, її приховує; потім додаток звертається до бази даних, посилаючи SQL-інструкції, запитує результати, відстежує і реагує на помилки і т.д., тобто має місце стандартна схема взаємодії докладання і сервера БД, характерна для RDA-моделі. Важливо, що стандарт ODBC включає функції управління транзакціями (початок, фіксація, відкіт транзакції). Завершивши сеанс роботи, додаток має відключитися від джерела даних.

Продовження в наступному номері.

(C) Jet Infosystems 1995