НЕЗАЛЕЖНІСТЬ ВІД СУБД

Знову звернімося до обговорення дванадцяти спільних цілей систем розподілених баз даних Остання з перерахованих цілей передбачала забезпечення незалежності від СУБД Як вказувалося в розділі 213, припущення про суворої однорідності виявляється невиправдано суворим, оскільки насправді необхідна лише підтримка будь-якими СУБД на різних вузлах одного і того ж інтерфейсу Як зазначалося у розділі 213, якщо, наприклад, СУБД Ingres і Oracle підтримують офіційний стандарт SQL (не більше і не менше), Можна буде добитися, щоб вони грали ролі партнерів в неоднорідній розподіленої системі Фактично така можливість – один з перших доводів, який зазвичай наводиться на користь стандарту мови SQL Тут ця можливість розглядається більш докладно

Примітка Обговорення буде побудовано конкретно на прикладі СУБД Ingres і Oracle, просто для того, щоб дати більш реальне уявлення про стан справ Проте, розглянуті концепції, безумовно, мають загальне застосування

Шлюзи

Припустимо, що є два вузли (X і Y), на яких встановлені СУБД Ingres і Oracle, відповідно Також припустимо, що деякий користувач і на вузлі X бажає отримати доступ до єдиної розподіленої базі даних, яка містить дані як з бази даних Ingres на вузлі X, так і з бази даних Oracle на вузлі Y За визначенням користувач і – це користувач СУБД Ingres, і, отже, з точки зору даного користувача розподілена база даних повинна бути базою даних Ingres В результаті обовязок надавати необхідну функціональну підтримку лягає на СУБД Ingres У чому ж полягає така підтримка

В принципі, все досить просто: СУБД Ingres повинна надати спеціальну програму, завдання якої – забезпечити можливість звертатися до СУБД Oracle, як до

СУБД Ingres . Такі програми зазвичай називають шлюзами (А останнім часом – оболонками) Рассмотрім6 рис 217 Шлюз може функціонувати на вузлі Ingres, на вузлі Oracle або (як це показано на малюнку) на деякому спеціальному вузлі між двома

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

СУБД Незалежно від того, де саме встановлено шлюз, необхідно, щоб він забезпечував всі перераховані нижче функції (Зверніть увагу на те, що при реалізації деяких з цих функцій виникають вельми складні проблеми Однак в стандартах RDA і DRDA, які розглядалися в розділі 215, врахована наявність деяких з таких проблем, як і в стандарті, заснованому на використанні мови XML (див главу 27))

Рис 217 Гіпотетичний шлюз до СУБД Oracle, наданий в СУБД

Ingres

■ Реалізація протоколів для обміну інформацією між СУБД Ingres і Oracle

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

СУБД Ingres, в формат, який підходить для СУБД Oracle, а також кошти відображений ня формату повідомлень, в якому передаються результати з СУБД Oracle, в

формат, необхідний для СУБД Ingres

■ Надання можливостей сервера SQL для СУБД Oracle (функціонально він аналогічний інтерактивного сервера SQL, який в даний час є в більшості продуктів) Іншими словами, повинна існувати можливість виконувати за допомогою шлюзу в базі даних Oracle довільні незапланований ві запити мовою SQL Для цього шлюз повинен забезпечувати динамічну підтримку мови SQL або, швидше за все, інтерфейсу рівня викликів (Call-Level Interface – CLI), такого як SQL / CLI, ODBC або JDBC на вузлі Oracle (див розділ 4) Примітка Як альтернатива шлюз може забезпечити безпосереднє використання інтерактивного процесора SQL, що надається СУБД Oracle

■ Відображення між типами даних Ingres і Oracle Це завдання включає ряд підзадач, які повинні враховувати відмінності в процесорах (тобто різні структури машинних слів), відмінності в кодуванні символів (інакше порівняння символьних рядків і запити з конструкціями ORDER BY можуть дати непередбачувані результати), відмінності у форматах чисел з плаваючою комою (широко відома проблема), відмінності у підтримці дат і часу (в даний час автору невідомі СУБД, які надавали б ідентичну підтримку в цій області), не кажучи вже про відмінності в типах, визначених користувачем Більш детальну інформацію можна знайти в [156], де наводиться розгорнуте обговорення даних питань

▪ Відображення діалекту мови SQL СУБД Ingres в діалект мови SQL СУБД Oracle (оскільки фактично ні СУБД Ingres, ні СУБД Oracle не підтримують точно стандарт мови SQL) Насправді кожен продукт підтримує певні можливості, які не підтримує інший, а також є й такі мовні засоби, які в обох продуктах мають один і той же синтаксис, але різну семантику

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

■ Відображення інформації зворотного звязку від СУБД Oracle (коди повернення і тд) у формат СУБД Ingres

■ Відображення каталогу СУБД Oracle в формат СУБД Ingres, щоб вузол Ingres і користувачі на вузлі Ingres могли визначити, що ж міститься в базі даних Oracle

■ Рішення безлічі проблем семантичного невідповідності, які напевно є між такими різними системами (див, наприклад, [218], [2111], [2114], [2136] і [2138]) Як приклади таких проблем можна вказати відмінності в способах іменування (СУБД Ingres дозволяє використовувати імя атрибута ОМР #, а в СУБД Oracle доводиться замінювати його на EMPNO) відмінності в типах даних (СКБД Ingres може використовувати символьну рядок для подання атрі буту, який в СУБД Oracle представляється числовий величиною) відмінності в одиницях виміру (в СУБД Ingres можуть використовуватися сантиметри, а в СУБД Oracle використовуються дюйми) відмінності в логічних уявленнях ін формації (в СУБД Ingres можна опускати кортежі в тих випадках, де в СУБД Oracle використовуються невизначені значення) і багато інших прикладів

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

■ Контроль блокування на вузлі Oracle даних, які потрібні для вузла Ingres, тобто перевірка, чи дійсно дані будуть заблоковані, коли це потребу ється для вузла Ingres І знову-таки, чи буде шлюз насправді готовий виконати цю функцію, очевидно, залежить від відповіді на питання, чи відповідає архі тектура механізму блокування СУБД Oracle архітектурі механізму блокування СУБД Ingres

Глава 21 Розподілені бази даних855

До цих пір ми розглядали незалежність від СУБД лише в контексті реляційних систем А як же бути з нереляціоннимі системами Чи існує можливість включення нереляційних вузла в розподілену систему, в якій всі інші вузли є реляційними Чи можна, наприклад, надати доступ до вузла IMS з вузла Ingres або Oracle Безумовно, така можливість була б дуже корисною на практиці, оскільки відкривала б доступ до величезної кількості данних7, що зберігаються в системах СУБД IMS та інших системах, створених до появи реляційного підходу Але чи можна це здійснити

Якщо дане питання означає: Чи можна вирішити таке завдання на всі 100%” (Мається на увазі Чи можуть всі нереляційні дані стати доступними з реляційного інтерфейсу і чи можуть всі реляційні операції стати застосовними до цих даних ), то відповідь буде гранично категоричним: Ні (З причин, викладених у всіх подробицях в [2114]) Але якщо питання звучить так: Чи можна надати деякий практично застосовний рівень функціональних можливостей”, То очевидно відповідь буде позитивною Але в даній книзі ця тема докладно не розглядається Додаткові відомості наведені в [2113] і [2114]

Проміжне програмне забезпечення для доступу до даних

Шлюзи, які описані в попередньому підрозділі, іноді більш конкретно називаються шлюзами типу Точка-точка. Такі шлюзи мають ряд очевидних недоліків По-перше, вони надають обмежену незалежність від розміщення По-друге, для практично однакових додатків може знадобитися використовувати декілька окремих шлюзів (скажімо, один – для СУБД DB2, інший – для СУБД Oracle і третій – для СУБД Informix), не маючи при цьому ніякої підтримки, наприклад, для операції зєднання, яка включає кілька вузлів різних типів, і тд Внаслідок цього (і незважаючи на технічні труднощі, зазначені в попередньому підрозділі) за кілька останніх років через досить короткі інтервали часу стали зявлятися продукти, що реалізують шлюзи з усе більш складними функціональними можливостями Фактично всі розробки, які ставилися до так званого проміжного програмного забезпечення (Middleware) для доступу до даних або до сполучній програмному забезпеченню (Mediator), тепер виділилися в важливе самостійний напрям програмування

Очевидно, що зазначені вище терміни (проміжне програмне забезпечення і оболонка) визначені не зовсім точно Будь частина програмного забезпечення, що використовується для приховування відмінностей між окремими системами, які призначені для спільної роботи, наприклад, монітор виконання транзакцій, може обгрунтовано вважатися проміжним програмним забезпеченням [213] Але ми зараз зосередимося на тому, що можна назвати проміжним програмним забезпеченням для доступу до даних Прикладом такого програмного забезпечення можуть служити продукти Cohera компанії Cohera, DataJoiner корпорації IBM, а також OmniConnect і InfoHub корпорації Sybase Як приклад розглянемо продукт DataJoiner [216]

7 Як показує звичайна ділова практика, в таких системах досі розміщено близько 85% виробничих даних (тобто величезна частина даних знаходиться в нереляційних системах баз даних і навіть у файлових системах) І дуже мала надія на те, що користувачі будуть коли-небудь переносити ці дані в більш нові системи

Охарактеризувати цей продукт можна кількома способами (рис 218) З точки зору окремого клієнта він виглядає, як звичайний сервер бази даних (тобто СУБД) DataJoiner зберігає дані, підтримує запити SQL, надає доступ до каталогу, виконує оптимізацію запитів і тд (Фактично основою системи DataJoiner є версія AIX СУБД DB2 компанії IBM) Але дані зберігаються в основному не на вузлі системи DataJoiner (хоча така можливість також є), а на будь-якій кількості інших прихованих від користувача вузлів, які контролюються кількома іншими СУБД (або навіть диспетчерами файлів, подібними, наприклад, VSAM) Таким чином, DataJoiner фактично дає користувачеві доступ до віртуальної базі даних, яка являє собою обєднання всіх таких прихованих від користувача баз даних і / або файлів Крім того, ця система дозволяє використовувати запроси8, які охоплюють всі зазначені бази даних та / або файли, а також приймає рішення щодо створення глобально оптимальних планів виконання запитів, використовуючи закладені в ній знання про можливості, прихованих від користувача систем (а також про характеристики мережі)

Примітка У продукті DataJoiner емулюються також деякі можливості мови SQL СУБД DB2 для систем, які не підтримують такі можливості безпосередньо Прикладом може служити опція WITH HOLD ДЛЯ оголошення курсора

(Див главу 15)

Система, подібна описаної вище, – далеко ще не полная розподілена система баз даних, оскільки всі можливі вузли, приховані від користувача, не мають інформації про існування один одного (тобто не можуть розглядатися як рівноправні партнери у спільному справі) Однак якщо до прихованих від користувача вузлам буде додано новий вузол, він зможе використовувати всі можливості, надані вузлам клієнтів і, отже, видавати запити через систему DataJoiner, яка гарантує доступ до будь-якого вузла (або відразу до всіх інших вузлів) В цілому це означає, що система являє собою так звану інтегровану систему, яка відома і як система, що складається з декількох баз даних [2117] Інтегрована система – це розподілена система, зазвичай неоднорідна, яка підтримує майже повну локальну автономію Локальні транзакції в ній управляються локальними СУБД реалізація ж глобальних транзакцій – це окреме питання [217]

Для кожної з прихованих від користувача систем в програмному продукті DataJoiner

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

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

s На слові запити потрібно зробити наголос можливості поновлення неминуче стають обмеженими, особливо у звязку з тим (але не тільки через це), що система, прихована від користувача, являє собою, скажімо, СУБД IMS або є якийсь інший системою, що не підтримує мову SQL (знову-таки, см [2114])

недавно включила в технологію DataJoiner свій програмний продукт-СУБД DB2 очевидно, це було зроблено з метою удосконалення СУБД DB2, щоб вона взяла на себе роль єдиного справжнього інтерфейсу (Принаймні, єдиного справжнього інтерфейсу IBM) до даних, збереженим у всіх формах (до часу написання даної книги за допомогою зазначеної технології надавався доступ до даних, збереженим, крім усього іншого, в СУБД Informix, Oracle, SQL Server і Sybase) Іншими словами, за допомогою своєї СУБД DB2, в якій застосовується технологія DataJoiner, компанія IBM зробила спробу вирішити проблему, відому під назвою проблеми інтеграції інформації [219]

Рис 218 DataJoiner – приклад проміжного програмного забезпечення для доступу до даних

Заключне слово

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

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*