Теорія проектування віддалених баз даних

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

Розділ 1. ТЕОРІЯ ПРОЕКТУВАННЯ віддалених баз даних

Тема 1.1. Архітектури віддалених баз даних

1.1.1 Основні поняття

Абревіатура ЛВС (вона ж LAN - Local Area Network) розшифровується як локальна обчислювальна мережа. Перші мережі з'явилися в 50 роки. Бурхливий розвиток почався з появою ПК (персонального комп'ютера).

Локальна обчислювальна мережа - це група комп'ютерів, які з'єднані між собою за допомогою спеціальної апаратури, що забезпечує обмін даними. Комп'ютери можуть з'єднуватися один з одним безпосередньо або через вузли зв'язку. Всередині будівлі або в межах невеликої території ЛОМ дозволяє з'єднати між собою групу ПК для сумісного використання інформації.

ЛОМ надає користувачам можливість розділяти ресурси комп'ютера і інформацію, перебуваючи далеко один від одного, вони можуть спільно працювати над проектами і задачами, які вимагають тісної координації і взаємодії. До того ж, навіть якщо комп'ютерна мережа вийде з ладу, ви все ж зможете продовжити роботу на вашому ПК. Нижче перераховані сім завдань, які вирішуються за допомогою ПК, що працює в складі ЛОМ, і які досить важко вирішити за допомогою окремого ПК.

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

Передача файлів. ЛОМ дозволяє швидко копіювати файли будь-якого розміру з однієї машини на іншу без використання дискет.

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

Поділ прикладних програм. ЛОМ дозволяє двом користувачам використовувати одну і ту ж копію програми, наприклад, текстового процесора MS Word. При цьому, звичайно, два користувачі не можуть одночасно редагувати один і той же документ.

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

Поділ принтера. ЛОМ дозволяє декільком користувачам на різних робочих станціях спільно використовувати один або декілька дорогих лазерних принтерів.

Електронна пошта й Інтернет. Ви можете використовувати ЛОМ як поштову службу і розсилати службові записки, доповіді, повідомлення іншим користувачам. Телефон, звичайно, швидше і більш зручний, але електронна пошта передасть ваше повідомлення навіть у тому випадку, якщо в даний момент абонент відсутній на своєму робочому місці, і для цього їй не потрібно паперу.

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

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

Робоча станція - персональний комп'ютер, підключений до мережі, через який користувач отримує доступ до її ресурсів. Робоча станція мережі функціонує як в мережевому, так і в локальному режимі. Вона оснащена власною операційною системою (Windows, Unix, MAC OS і т.д.), забезпечує користувача всіма необхідними інструментами для вирішення прикладних завдань.

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

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

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

Переваги однорангових мереж: низька вартість та висока надійність.

Недоліки однорангових мереж:

  • залежність ефективності роботи мережі від кількості станцій;

  • складність управління мережею;

  • складність забезпечення захисту інформації;

  • труднощі оновлення та зміни програмного забезпечення станцій.

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

Взаємодія між робочими станціями в мережі, як правило, здійснюється через сервер. Логічна організація такої мережі може бути представлена ​​топологією зірка. Роль центрального пристрою виконує сервер.

Переваги мережі з виділеним сервером:

  • надійна система захисту інформації;

  • високу швидкодію;

  • відсутність обмежень на кількість робочих станцій;

  • простота управління порівняно з одноранговими мережами,

Недоліки мережі:

  • висока вартість через виділення одного комп'ютера під сервер;

  • залежність швидкодії і надійності мережі від сервера;

  • менша гнучкість у порівнянні з тимчасової мережею.

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

1.1.2 Основні тенденції розвитку засобів віддаленого управління

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

Тому для сучасних засобів віддаленого доступу дуже важливі хороша масштабованість і підтримка великої кількості віддалених клієнтів.

Відмінності між віддаленим доступом та віддаленим керуванням

Існує два типи віддалених обчислень, і ви повинні вибрати те, що більше підходить до ваших вимог.

Віддалене управління

ПО віддаленого управління використовується вже кілька років. Починаючи з невеликих пакетів, типу PCAnywhere, і закінчуючи великими додатками масштабу підприємства, як SMS. Воно дає користувачам або адміністратору можливість керувати віддаленою машиною і виконувати різноманітні функції. При використанні віддаленого управління, від віддаленої машини на локальну машину надсилаються коди натиснутих клавіш. Локальна машина посилає на віддалену зміни екрану. Обробка і передача файлів, як правило, робляться на локальній машині. На малюнку 1.4 показана схема сеансу віддаленого управління:

Переваги віддаленого управління

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

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

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

Недоліки віддаленого управління

Програми віддаленого управління мають ряд обмежень. Більшість пакетів обмежені роздільною здатністю екрану, яке вони можуть відтворити. Клієнти Terminal Services підтримують максимум 256 кольорів. Крім того, програми, що використовують графіку, сильно завантажують канали зв'язку і можуть звести нанівець всі переваги віддаленого управління. Citrix MetaFrame недавно випустила Feature Release 1, додатковий пакет для MetaFrame 1.8, який дозволяє користувачам використовувати 24-бітний колір.

Клієнт Citrix може масштабувати графіку сесії в залежності від пропускної спроможності каналу зв'язку. Чим більше дозвіл, тим більше завантажується канал. Через це деякі програми, наприклад, системи автоматизованого проектування, не підходять для використання з Terminal Services або MetaFrame. Однак, додатки Windows Office - такі як Word і Excel, - ідеально підходять для сеансів віддаленого доступу.

Feature Release 1 доступний для володарів Subscription Advantage. Він включає Service Pack 2 for MetaFrame 1.8, а також набір нових можливостей, таких як підтримка декількох моніторів, велика глибина кольору, SecureICA.

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

Останній недолік віддаленого управління полягає в тому, що швидкість передачі файлів між локальним і віддаленим ПК обмежена швидкістю з'єднання. Більшість користувачів використовують звичайну телефонну мережу, що дозволяє швидкість максимум 56Кbps. Хоча MetaFrame непогано працює і на модемному з'єднанні 28.8 Kbps, рекомендуються високошвидкісні з'єднання типу ADSL чи кабельні модеми.

Віддалений вузол

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

Віддалений вузол відповідає за обробку, виконання, зміна інформації, з якою він працює. Все це виконується з тією швидкістю, з якою може працювати клієнт.

Через цих обмежень обчислення на віддаленому вузлі висувають високі вимоги до пропускної здатності каналу зв'язку. Це слід враховувати при проектуванні. Як видно на малюнку, між клієнтом на локальному ПК і клієнтом віддаленого вузла є невелика відмінність. Сервер буде однаково обробляти запити від будь-якої машини. Але якщо локальний клієнт запитує 2Мб даних, сервер передасть їх по локальній мережі. Для віддаленого клієнта, по каналу 56К ця передача займе близько 6 хвилин. Крім того, після внесення змін клієнт повинен відправити ці 2Мб назад.

Навіщо використовувати віддалений доступ?

Чому ж компанії воліють використовувати віддалений доступ, а не віддалене управління, незважаючи на всі ці проблеми, які з швидкості з'єднання? Для початківців віддалений доступ простіше. Все, що потрібно - це спосіб підключитися до сервера. Для цього використовується RAS або з'єднання через Інтернет.

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

Віддалений доступ більш безпечний, ніж віддалене управління. Для клієнтів, які використовують Інтернет, існує багато програм, що реалізують захищене з'єднання між клієнтом і сервером. Останнім часом стали дуже популярні віртуальні приватні мережі (VPN).

Сеанси віддаленого доступу не обмежені у графіку. Якщо клієнтський ПК налаштований на 24-бітний колір, то саме така якість він і спробує показати. Однак, у разі великих зображень може знадобитися значний час для їх відображення. Якщо ваш додаток виводить багато графіки, це значно знизить продуктивність.

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

Недоліки обчислення на віддаленому вузлі

Як було сказано вище, швидкість є ключовим аспектом, оскільки передається набагато більше даних, ніж при вилученому керуванні. Частково проблему можна вирішити використанням кабельних модемів і ADSL, але навіть у цьому випадку швидкість становитиме лише 1 / 5 від швидкості в ЛВС, якщо тільки користувач не платить щомісяця $ 1,000 за персональний канал T1.

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

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

1.1.3 Архітектури прикладних систем

У складі прикладної системи зручно виділити прикладне програмне забезпечення й платформу. Формують (поряд з апаратурою) платформу операційну систему, СУБД і програмне забезпечення проміжного шару [1-4] разом називають системним ПЗ.

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

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

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

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

Іноді три зазначені частини називають шарами - від теоретичної моделі, яка розглядає кожну частину програми в термінах її положення щодо користувача, від «переднього шару» (front-end, логіка подання) до «заднього шару» - (back-end, логіка доступу до даними). Одна з функцій «середнього шару» (бізнес-логіка) полягає в забезпеченні двонаправленого перетворення між структурами даних високого рівня переднього шару і низькорівневими структурами заднього шару. У цій моделі становище кожного шару (щодо користувача) безпосередньо пов'язано з різними рівнями абстракції.

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

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

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

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

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

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

Архітектури прикладних систем

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

Як можна помітити, сама «давня», централізована архітектура забезпечує набагато більш масштабоване рішення, ніж дві наступні. Знадобилося три покоління, перш ніж ці розподілені архітектури змогли ефективно конкурувати з рішенням, орієнтованим на універсальний комп'ютер: побудувати розподілену систему набагато важче.

Централізована архітектура

Одна потужна універсальна ЕОМ була єдиною платформою, що виконує всі алгоритми логіки додатка (мал. 2). У централізованої архітектури безліч переваг: проста розробка програм, легкість обслуговування й управління. Саме вони і забезпечили таке довге життя «успадкованих» систем. Смерть універсальних ЕОМ неодноразово проголошувалася після появи чотирьох-і восьмирозрядних ПК на початку 80-х років (комп'ютери PET і VIC-20 компанії Commodore, TRS-80 компанії Radio Shack і безліч інших машин на базі процесорів Z-80, а також 6502 і 6800 виробництва Motorola). Проте вони продовжували працювати, переварюючи десятки мільйонів транзакцій в день, пристосовуючись до постійно збільшується навантажень.

Поділ файлів

Особливу увагу слід приділити одного з типів серверів - файлового сервера (File Server). У поширеній термінології для нього прийнята скорочена назва - файл-сервер.

Файл-сервер зберігає дані користувачів мережі і забезпечує їм доступ до цих даних. Це комп'ютер з великою ємністю оперативної пам'яті, жорсткими дисками великої ємності та додатковими накопичувачами.

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

Файл-сервер виконує наступні функції: зберігання даних, архівування даних, синхронізацію змін даних різними користувачами, передачу даних.

Тільки-но з'явившись, ПК принесли очікування того, що велика кількість маленьких машин може замінити, а, в деяких випадках, і перевершити по продуктивності універсальну ЕОМ. Архітектура поділу файлів, що стала першим кроком до реалізації цієї заяви, включає безліч настільних ПК і файловий сервер, пов'язаних мережею (рис. 3). Файловий сервер завантажує файли з розділяється місця розташування, а прикладні програми виконуються повністю на настільних ПК.

Подібна архітектура була особливо популярна при використанні продуктів на зразок dBASE, FoxPro і Clipper. Спочатку мережі персональних комп'ютерів були засновані на метафорі спільного використання файлів, тому що це було просто. Однак вона добре працювала лише в деяких випадках. По-перше, всі програми повинні вписатися в єдиний ПК. По-друге, спільне використання та конфлікти поновлення надзвичайно знижують продуктивність. Нарешті, враховуючи пропускну здатність мережі, обсяг даних, які можуть передаватися, також невеликий. Всі ці фактори вкрай обмежують число паралельних користувачів, яке здатна підтримувати архітектура поділу файлів [6-8].

Клієнт-сервер

Прагнення виправити архітектуру поділу файлів призвело до заміни файлового сервера сервером баз даних (рис. 4). Замість передачі файлів цілком він пересилає тільки відповіді на запити клієнтів, зменшуючи навантаження на мережу. Ця стратегія викликала поява архітектури клієнт-сервер. З'явившись у 80-х роках, вона ввела поняття «клієнта» (сторона, яка запитує функції / обслуговування) і «сервера» (сторона, що надає функції / обслуговування). На рівні програмного забезпечення поділ на клієнта і сервер є логічним: процеси клієнта і сервера можуть фізично розміщуватися як на одній, так і на різних машинах. Під загальним концептуальною назвою ховаються три варіанти архітектури: двухзвенная, трехзвенная і многозвенная.

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

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

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

Але ще гірше має фундаментальний характер обмеження на число одночасних з'єднань з сервером. Сервер підтримує відкрите сполучення з усіма активними клієнтами, навіть якщо ніякої роботи немає. Це необхідно, щоб сервер міг отримувати сигнали тактового імпульсу, що не так страшно, коли клієнтів менше 100 [9-12], а проте понад цього числа продуктивність починає швидко деградувати до неприпустимо низького рівня. Гарним прикладом виникнення подібної проблеми може служити робота проксі-сервера.

У деяких прикладних системах бізнес-логіку намагаються реалізувати, використовуючи збережені процедури. Ідея полягає в тому, щоб відповідно до «тонкої» конфігурацією клієнта перемістити алгоритми бізнес-логіки на серверну машину, ближче до даних, які потрібні їм постійно. Це виглядає як хороша ідея, однак тільки збільшує головну проблему. Так як здійснюють бізнес-правила процеси тепер управляються СУБД, число користувачів, яких може підтримувати таку систему, обмежена максимумом можливих активних сполук з СУБД. Крім того, від СУБД до СУБД механізми збережених процедур різняться. Тим не менш, двухзвенная архітектура добре працює в маленьких робочих групах [9-12]. З початку 90-х років з'явилася маса інструментальних засобів, що спрощують створення систем в такій архітектурі, у тому числі Delphi і PowerBuilder.

Рис. 6. Триланкового архітектура

З середини 90-х років визнання фахівців отримала трехзвенная архітектура, яка, як і двухзвенная, підтримувала концепцію клієнт-сервер, але розділила систему за функціональними кордонів між трьома шарами: логікою представлення, бізнес-логікою і логікою доступу до даних (рис. 6) . На відміну від двухзвенной архітектури з'являється додаткова ланка - «сервер додатків», цілком, призначене для здійснення бізнес-логіки.

Саме виділення бізнес-логіки в окрему ланку дозволяє подолати фундаментальні обмеження двухзвенной архітектури. Клієнти не підтримують постійного з'єднання з базою даних, а обмінюються інформацією з середньою ланкою тільки тоді, коли це необхідно. У той же час процес середньої ланки підтримує всього кілька активних з'єднань з базою даних, але використовує їх багато разів; тому процеси в середній ланці можуть надавати обслуговування теоретично необмеженому числу клієнтів. У порівнянні з усіма іншими моделями трехзвенная архітектура має настільки багатьма перевагами. Але переваги не даються задарма. Розробка прикладних програм, заснованих на триланкової архітектурі, - більш важка справа, ніж для двухзвенной архітектури або при використанні централізованого підходу. Подолати виникають проблеми допомагає програмне забезпечення проміжного шару [5-9].

Триланкового архітектура

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

Сервер додатків

Рис. 7. Триланкового архітектура з сервером додатків

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

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

Є й інші переваги. По-перше, тому що вся «важлива» частина прикладної логіки тепер централізована в середній ланці, немає необхідності підтримувати складні механізми аутентифікації на стороні клієнтів.

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

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

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

Відзнака «багатоланкової» архітектури від «двухзвенной». Досить поширена модель роботи, коли клієнт звертається не безпосередньо до сервера БД, а до проміжної програмі. Ця програма зазвичай називається сервером додатків. Таку архітектуру називають «триланкової», на відміну від «двухзвенной» архітектури клієнт-сервер.

Монітори обробки транзакцій

Монітори обробки транзакцій (transaction processing monitor, TPM) - найстаріший тип технології розподілених систем, яка з'явилася в 70-х роках в середовищі великих універсальних ЕОМ [9-12]. Однією з перших прикладних систем була інтерактивна середовище підтримки, створена компанією Atlantic Power and Light для спільного використання прикладних служб та інформаційних ресурсів у режимах пакетної обробки і з використанням середовища з поділом часу. TPM (наприклад, IBM CICS) стали головним інструментом побудови високо масштабованих рішень для мережевих прикладних систем. Однак на початку 90-х популярність TPM почала падати; причиною стала поява продуктів категорії TPM «Lite» - моніторів обробки транзакцій всередині СУБД. Їх функціональні можливості були близькі до звичайних TPM, і зі зростаючою тоді популярністю двухзвенной архітектури вони спочатку забезпечили хороше рішення для створення розподілених прикладних систем.

До кінця десятиліття ситуація змінилася. Виявилося, що в той час як звичайний монітор транзакцій може легко підтримувати тисячі користувачів, їх продуктивність стає неприпустимо низькою, коли сукупність користувачів перевищує 100. Сьогодні TPM знову повернулися, але тепер це технологія, яка втілює середня ланка в триланкової архітектурі.

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

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

Рис. 8. Триланкового архітектура з монітором обробки транзакцій

Найпростіша конфігурація - клієнт-A взаємодіє тільки з одним монітором TPM-A (рис. 8), який забезпечує доступ до даних, розташованим на одному комп'ютері (Сервер Даних A). За допомогою двофазного протоколу фіксації монітор може забезпечувати семантику транзакцій і з декількома базами даних. Таким чином, транзакція одного клієнта буде фактично розбита між кількома базами даних; ця ситуація показана у випадку з TPM-B, який взаємодіє з джерелами даних на декількох машинах (Сервер Даних A, Сервер Даних B і Сервер Даних C). У цьому випадку, якщо подтранзакція терпить невдачу на одному з серверів, всі інші подтранзакціі також відкочуються назад, а Клієнт-B отримує повідомлення про таку подію.

Відносини між клієнтами і моніторами, так само як і між моніторами і джерелами даних, фактично є відносинами «багато-до-багатьох». Ця конфігурація часто використовується, щоб забезпечити балансування навантаження. Коли число користувачів збільшується, система може запускати додаткові екземпляри моніторів, які забезпечують доступ до одних і тих же джерел даних.

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

Сервер повідомлень

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

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

Рис. 9. Триланкового архітектура з сервером повідомлень

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

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

Більш того, «інтелект», який направляє повідомлення за додатковим шляху, знаходиться не на клієнта, а на сервері повідомлень. Таким чином, відмови можуть залишатися повністю прихованими від клієнта.

Більшість серверів повідомлень підтримує декілька протоколів зв'язку і виконується на різних платформах.

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

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

Брокер об'єктних запитів

Брокер об'єктних запитів (object request broker, ORB) забезпечує інфраструктуру, яка підтримує розподілені об'єкти, якими можна управляти, як і об'єктами, розташованими «поруч» із процесом, що працюють з ними. За викликом методу (в сенсі об'єктно-орієнтованого програмування) на одному комп'ютері може фактично виконуватися деякий програмний код іншого, притому, що доступ до даних в межах розподіленого об'єкта може потребувати отримання відповідної інформації з віддаленої бази даних. Всі ці деталі залишаються прихованими від прикладної програми [15].

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

Рис. 10. Триланкового архітектура з брокером об'єктних запитів

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

Точно так само розподілені об'єкти можуть «упаковувати» інші прикладні програми. Тому інтеграція додатків може здійснюватися не просто на рівні бізнес-правил, але на рівні об'єктів. Ці два підходи, однак, дуже схожі. Так як бізнес-правила приховані в методах об'єкта, спільне використання об'єкта передбачає спільне використання бізнес-правил. Але об'єкт також містить інформацію про стан, тому він допускає інтеграцію і на рівні даних.

Тема 1.2. Основні технології доступу до даних і типові елементи доступу

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

На зорі існування Windows були впроваджені Спільні файли, буфер обміну і технологія динамічного обміну даними (Dynamic Data Exchange, DDE).

Для забезпечення обміну даними та надання служб був розроблений перший варіант технології зв'язування і впровадження об'єктів (Object Linking and Embedding - OLE 1). вона призначалася для створення складених документів - того, до чого ми всі вже давно звикли. Ця технологія була багато в чому недосконалою, і на зміну їй прийшла технологія OLE 2. Вона представляє спосіб вирішення більш загальної проблеми - як навчити різні програми надавати один одному власні функції (служби) і як навчити їх правильно використовувати ці функції.

Для вирішення цієї проблеми крім OLE був розроблений цілий ряд технологій. В основі цих розробок лежить базова технологія Component Object Model (COM) - Багатокомпонентна Модель Об'єктів. Вона частина ПЗ надає для використання власні служби, а інша отримує до них доступ. При цьому абсолютно не важливо, де розташовані ці частини - в одному процесі, в різних процесах на одному комп'ютері або на різних комп'ютерах.

Додаткові можливості розробникам розподілених додатків на основі COM дає модифікація базової технології - розподілена модель COM (Distributed COM, DCOM).

В даний час COM використовується в самих різних галузях розробки ПЗ. На основі COM розроблені технології автоматизації (Automation), ActiveX, ActiveForm Microsoft Transaction Server. На базі COM створено більшість новітніх продуктів (MS Office, MTS, ...) і технологій Windows (Automation, Drag & Drop, ...).

У складі DELPHI працюють дві динамічні бібліотеки OLE 32. DLL OLEAUT 32. DLL, які містять базові інтерфейси і загальні функції COM.

1.2.1 Розробка додатків на основі COM

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

На зорі існування Windows були впроваджені Спільні файли, буфер обміну і технологія динамічного обміну даними (Dynamic Data Exchange, DDE).

Для забезпечення обміну даними та надання служб був розроблений перший варіант технології зв'язування і впровадження об'єктів Object Linking and Embedding - OLE 1. вона призначалася для створення складених документів - того, до чого ми всі вже давно звикли. Ця технологія була багато в чому недосконалою, і на зміну їй прийшла технологія OLE 2. Вона надає спосіб вирішення більш загальної проблеми - як навчити різні програми надавати один одному власні функції (служби) і як навчити їх правильно використовувати ці функції.

Для вирішення цієї проблеми крім OLE був розроблений цілий ряд технологій. В основі цих розробок лежить базова технологія Component Object Model (COM) - Багатокомпонентна Модель Об'єктів. Вона описує спосіб взаємодії програм будь-якого типу. Одна частина ПЗ надає для використання власні служби, а інша отримує до них доступ. При цьому абсолютно не важливо, де розташовані ці частини - в одному процесі, в різних процесах на одному комп'ютері або на різних комп'ютерах.

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

В даний час COM використовується в самих різних галузях розробки ПЗ. На основі COM розроблені технології Автоматизації (Automation), ActiveX, ActiveForm Microsoft Transaction Server.

У складі Delphi працюють дві динамічні бібліотеки OLE 32. Dll OLEAUT 32. Dll, які містять базові інтерфейси і загальні функції COM.

COM - це технологія, що дозволяє об'єктам взаємодіяти, незважаючи на кордони процесу чи машини, так само легко, як і об'єктів усередині одного процесу. COM забезпечує таку взаємодію, визначаючи, що єдиний шлях управління даними, асоційованими з об'єктом, лежить через інтерфейс об'єкту. Термін «інтерфейс», про який мова піде трохи нижче, означає реалізацію в коді COM-сумісного двійкового інтерфейсу, асоційованого з об'єктом.

СОМ - загальна технологія взаємодії об'єктів стандартізующих як самі об'єкти, так і методи їх взаємодії. Це специфікація, що будується на базі еталонних реалізацій. COM є платформно-незалежної, об'єктно-орієнтованої технологією, що дозволяє створювати бінарні компоненти. Ці компоненти можна використовувати як локально, так і в розподіленому мережному оточенні. COM служить основою для: OLE (технологія складених документів), ActiveX-об'єктів та елементів управління ActiveX, DCOM, COM +.

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

COM + - це еволюція COM і MTS. COM + повністю вбудований в Windows 2000. Він істотно розширює можливості своїх попередників. COM + назад сумісний з DCOM, MTS і COM, і дозволяє створювати розподілені додатки, клієнтські частини яких можна запускати на старих ОС (Windows 9x і Windows NT).

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

COM-об'єкт

У технології COM програма надає для використання свої служби, застосовуючи для цього об'єкти COM. Один додаток містить як мінімум один об'єкт. Кожен об'єкт має один або декілька інтерфейсів. Кожен інтерфейс поєднує методи об'єкта, які забезпечують доступ до властивостей (даними) і виконання операцій. Зазвичай в інтерфейсі об'єднуються всі методи, які виконують операції одного типу або працюючі з однорідними властивостями.

Клієнт отримує доступ до служб об'єкта тільки через інтерфейс і його методи. Цей механізм є ключовим. Клієнту достатньо знати кілька базових інтерфейсів, щоб отримати вичерпну інформацію про склад властивостей і методів об'єкта. Тому будь-який клієнт може працювати з будь-яким об'єктом, незалежно від їхнього середовища розробки. Згідно зі специфікацією COM, вже створений інтерфейс не може бути змінений ні за яких обставин. Це гарантує постійну працездатність додатків на основі COM, незважаючи на будь-які модернізації.

Об'єкт завжди працює в складі сервера COM. Сервер може бути динамічною бібліотекою або виконуваний файл. Об'єкт може мати власні властивості та методи або використовувати дані та служби сервера.

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

Припустимо, що об'єкт COM вбудований в електронну таблицю і забезпечує доступ до математичних операцій. Буде логічно розділити математичні функції на групи за типами і створити для кожної групи власний інтерфейс. Наприклад, можна виділити лінійні, тригонометричні, агрегатні функції і т.д. На рис. 1. об'єкт розташований всередині сервера - електронної таблиці. Інтерфейси позначені кружками, пов'язаними з об'єктом. Нехай інтерфейс лінійних функцій називається ILinear, а інтерфейс агрегатних функцій - IAggregate.

Об'єкт СОМ - це деяка сутність, що має стан та методи доступу, що дозволяють змінювати цей стан. СОМ-об'єкти можна створювати прямим викликом спеціальних функцій, але безпосередньо знищити його неможливо. Замість прямого знищення використовується механізм самознищення, заснований на підрахунку посилань. Найближчим аналогом в об'єктно-орієнтованих мовах програмування є поняття об'єкта в мові Java.

Так, в COM присутнє поняття класу. Клас в COM носить назву CoClass.


Рис. 1. Сервер, об'єкт і його інтерфейси

Згідно з правилами позначення об'єктів COM, базовий інтерфейс IUnknown, який є у будь-якого об'єкта, позначається як гурток, що примикає до верхньої сторони прямокутника об'єкта. Решта інтерфейси позначаються праворуч і ліворуч.


Рис.2. Схема взаємодії клієнта і об'єкта COM

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

Взаємодія між клієнтом і об'єктом забезпечується базовими механізмами COM. При цьому від клієнта приховано, де саме розташований об'єкт: в адресному просторі того ж процесу, в іншому процесі або на іншому комп'ютері. Тому з точки зору розробника клієнтського ПО використання функцій електронної таблиці виглядає як звичайне звернення до методу об'єкта. Механізм забезпечення взаємодії між віддаленими елементами COM називається маршалинга (marshalling).

Виникає питання - як відбувається створення і ініціалізація об'єкта COM при першому зверненні клієнта? Сумнівно, щоб ОС самостійно створювала екземпляри всіх зареєстрованих в ній класів в надії, що один з них знадобиться. Але ж для роботи об'єкта потрібні ще й сервери. Уявіть, що кожного разу при завантаженні Windows наполегливо запускає Word, excel, Internet Explorer і т.д.

Будь-який об'єкт COM є звичайним екземпляром деякого класу, що описує його властивості та методи. Інформація про всі зареєстровані і доступних в даній ОС класах COM зібрана в спеціальній бібліотеці COM, яка використовується для запуску екземпляра класу - об'єкта.

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

Після створення настає черга ініціалізації - об'єкт повинен завантажити необхідні дані, вважати налаштування з системного реєстру і т.д. за це відповідають спеціальні об'єкти COM, які називаються моникер (monikers). Вони працюють приховано від клієнта. Зазвичай моникер створюється разом з класом.

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

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

Ця інформація міститься в бібліотеці типів, яка створюється за допомогою спеціальної мови опису інтерфейсу (Interface Definition Language, IDL).

Об'єкт

Центральним елементом COM є об'єкт. Програми, що підтримують COM, мають у своєму складі один або декілька об'єктів COM. Кожен об'єкт являє собою екземпляр відповідного класу і містить один або кілька інтерфейсів. Що ж таке об'єкт COM?

Будь-який об'єкт є екземпляром деякого класу, тобто являє собою змінну об'єктного типу. Тому об'єкт має набір властивостей і методів, які працюють з цими властивостями. До об'єктів застосовні три основні характеристики: інкапсуляція, успадкування і поліморфізм. Об'єкти COM всім цим вимогам задовольняють.

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

Об'єкт COM може мати будь-яке число інтерфейсів (якщо це число більше нуля), причому кожен інтерфейс має власний покажчиком. Це перша відмінність об'єктів COM від звичайних.

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

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

Інтерфейс

Якщо об'єкт COM є ключовим елементом реалізації COM, то інтерфейси є центральною ланкою ідеології COM. Як двом принципово різним об'єктам забезпечити взаємодію один з одним? Відповідь проста: їм необхідно заздалегідь домовиться про те, як вони будуть спілкуватися.

Інтерфейс якраз є тим засобом, який дозволяє клієнту правильно звернутися до об'єкта COM, а об'єкту відповісти так, щоб клієнт його зрозумів.

Розглянемо невеликий приклад. На вулиці випадково зустрілися дві людини: місцевий житель (об'єкт COM) і заблукав іноземець (клієнт). Передбачливий іноземець взяв із собою словник (бібліотека типів або інтерфейс IUnknown). Іноземцю потрібні знання місцевого жителя про місто. Він дістав ручку і папір і, заглянувши у словник, склав фразу і старанно перемалював незнайомі слова на папір. Місцевий житель виявився не промах. Він прочитав фразу, відібрав у іноземця словник, склав за нього власну фразу і теж написав її на папері. І все закінчилося добре: задоволений клієнт (іноземець) отримав від об'єкта COM (місцевого жителя) результат роботи служби (інформацію про дорогу), а місцевий житель пішов разом зі словником.

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

Для ідентифікації кожен інтерфейс має два атрибути. По-перше, це його ім'я, складене з символів відповідно до правил використовуваної мови програмування. Кожне ім'я має починатися з символу «I». Це ім'я використовується в програмному коді. По-друге, це глобальний унікальний ідентифікатор (Globally Unique IDentifer, GUID), який представляє собою гарантовано унікальне поєднання символів, практично не повторюване ні на одному комп'ютері в світі. Для інтерфейсів такий ідентифікатор носить назву IID (Interface Identifier).

У загальному випадку клієнт може не знати, які інтерфейси є у об'єкту. Для отримання їх переліку використовується базовий інтерфейс IUnknown., Який є у будь-якого об'єкта COM.

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

Тепер залишилося зробити найважливіше - правильно викликати сам метод. Для цього в COM описана реалізація інтерфейсу на основі стандартного двійкового формату. Це забезпечує незалежність від мови програмування.

Рис.3. Формат інтерфейсу COM

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

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

Реалізація інтерфейсу (interface implementation) - це код, який програміст створює для виконання дій, обумовлених у визначенні інтерфейсу. Реалізації інтерфейсів, поміщені в COM-бібліотеки або exe-модулі, можуть використовуватися при створенні об'єктно-орієнтованих додатків. Зрозуміло, програміст може ігнорувати ці реалізації та створити власні. Інтерфейси асоціюються з CoClass'амі. Щоб скористатися реалізацією функціональності інтерфейсу, потрібно створити екземпляр об'єкта відповідного класу, і запитати у цього об'єкта посилання на відповідний інтерфейс.

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

Кожен CoClass має два ідентифікатора - один з них, текстовий, називається ProgID і призначений для людини, а другий, бінарний, називається CLSID.

CLSID є глобально унікальним ідентифікатором (GUID). GUID має розмір 128 біт і унікальний у просторі та часі. Його унікальність досягається шляхом впровадження в нього інформації про унікальні частинах комп'ютера, на якому він був створений, таких, як номер мережевої карти, і часу створення з точністю до мілісекунд. Ця технологія, як і більшість інших базових концепцій в СОМ, запозичена з OSF DCE RPC. За допомогою CLSID можна точно вказати, який саме об'єкт потрібно. Тип даних GUID застосовується і для ідентифікації COM-інтерфейсів. У цьому випадку він називається IID. Згенерувати нове значення типу GUID можна за допомогою API-функції Win32 CoCreateGuid. На практиці використовувати цю функцію доводиться не часто, так як сучасні засоби розробки повністю автоматизують це завдання, а VB взагалі приховує від програміста такі тонкощі, як роботу з CLSID і IID.

Для створення екземпляра об'єкта використовується CLSID. Якщо є лише ProgID CoClass'а або CLSID в строковому вигляді ("{XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX}", де X - шістнадцяткова цифра), то CLSID можна отримати, викликавши функцію CLSIDFromString. Для випадку з ProgID інформація про CoClass'е повинна міститися у реєстрі машини, на якій здійснюється виклик функції. До реєстру інформація заноситься автоматично при реєстрації об'єкта (під час процедури інсталяції або при компіляції).

Перекласти CLSID, IID або будь-який інший GUID у рядок можна за допомогою функції StringFromGUID2. Як вже говорилося вище, практично всі необхідні GUID генеруються автоматично, але при необхідності можна згенерувати GUID вручну, за допомогою утиліти guidgen.

Програміст ніколи не взаємодіє з об'єктом і його даними безпосередньо. Для цього використовуються інтерфейси об'єктів.

Інтерфейс IUnknown

Кожен об'єкт COM обов'язково має інтерфейс IUnknown. Цей інтерфейс має всього три методи, але вони грають ключову роль у функціонуванні об'єкта.

Метод QueryInterface повертає покажчик на інтерфейс об'єкта, ідентифікатор IID якого передається в параметрі методу. Якщо такого інтерфейсу об'єкт не має, метод повертає null.

Зазвичай при першому зверненні до об'єкта клієнт отримує покажчик на інтерфейс. Так як будь-який інтерфейс є нащадком IUnknown, то будь-який інтерфейс має і метод QueryInterface. Тому в загальному випадку не важливо, який саме інтерфейс може використовувати клієнт. За допомогою методу QueryInterface він може отримати доступ до будь-якого інтерфейсу об'єкта.

Інтерфейс IUnknown забезпечує роботу ще одного важливого механізму об'єкта COM - механізму обліку посилань. Об'єкт повинен існувати до тих пір, поки його використовує хоча б один клієнт. При цьому клієнт не може самостійно знищити об'єкт, адже з ним можуть працювати й інші клієнти.

Тому при передачі назовні чергового покажчика на інтерфейс об'єкт збільшує спеціальний лічильник посилань на одиницю. Якщо один клієнт передає іншому покажчик на інтерфейс цього об'єкта, то клієнт, який отримує покажчик, зобов'язаний ще раз інкрементіровать лічильник посилань. Для цього використовується метод AddRef інтерфейсу IUnknown.

При завершенні роботи з інтерфейсом клієнт зобов'язаний викликати метод Release інтерфейсу IUnknown. Цей метод зменшує лічильник посилань на одиницю. Після обнулення лічильника об'єкт знищує себе.

Сервер

Сервер COM являє собою виконуваний файл програми або динамічну бібліотеку, що містить один або кілька об'єктів одного або різних класів. Розрізняють три типи Сервер.

Внутрішній сервер (inprocess server) реалізується динамічними бібліотеками, які підключаються до клієнта і працюють в одному адресному просторі.

Локальний сервер (local server) створюється окремим процесом, який працює на одному комп'ютері з клієнтом.

Віддалений сервер (remote server) створюється процесом, який працює на друго комп'ютері по відношенню до клієнта.

Розглянемо локальний сервер. Одержуваний клієнтом покажчик інтерфейсу в цьому випадку посилається на спеціальний proxy-об'єкт COM (назвемо його заступником, який функціонує всередині клієнтського процесу). Заступник надає клієнту ті ж інтерфейси, що і викликаний об'єкт COM на локальному сервері. Отримавши виклик від клієнта, заступник упаковує його параметри і за допомогою служб ОС передає виклик у процес сервера. У локальному сервері виклик передається ще одній спеціалізованій об'єкту - заглушці (stub), який розпаковує виклик і передає його необхідному об'єкту COM. Результат виклику повертається клієнтові в зворотному порядку.

Розглянемо віддалений сервер. Він функціонує так само, як і локальний сервер. Однак передача викликів між двома комп'ютерами здійснюється засобами DCOM - за допомогою механізму виклику віддалених процедур (Remote Procedure Call, RPC).

Для забезпечення роботи локальних і віддалених серверів використовується механізм маршалинга і демершалінга. Маршалинга реалізує єдиний в рамках COM формат упаковки параметрів запиту, демаршалінг відповідає за розпаковування. В описаних вище реалізаціях серверів за виконання цих операцій відповідають заступник і заглушка. Ці типи об'єктів створюються спільно з основним об'єктом COM. Для цього застосовується IDL.

Бібліотека COM

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

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

При установці використовує COM додатки в системний реєстр записується інформація про всі використовуваних їм об'єктах COM:

  • Ідентифікатор класу (Class Identifier, CLSID), який однозначно визначає клас об'єкта;

  • Тип сервера об'єкта - внутрішній, локальний чи віддалений;

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

  • Для віддалених серверів записується повний мережеву адресу.

Припустимо, що клієнт намагається використовувати деякий об'єкт COM, який до цього моменту не використовувався.

Отже, клієнт не може отримати покажчики на об'єкт і інтерфейс. У цьому випадку він звертається до бібліотеки COM і викликає метод CoCreateInstance, передаючи їй як параметр CLSID потрібного класу, IID інтерфейсу і необхідний тип сервера.

Бібліотека за допомогою диспетчера керування службами (Service Control Manager, SCM) звертається до системного реєстру, за ідентифікатором класу - об'єкт, і повертає бібліотеці покажчик на запитаний інтерфейс.

Бібліотека COM передає управління клієнту, який надалі може звертатися безпосередньо до об'єкта. Схема створення першого екземпляра об'єкту за допомогою бібліотеки COM і системного реєстру наведена на малюнку.

Рис.4. Створення першого примірника об'єкта за допомогою бібліотеки COM

Для неявної ініціалізації створеного об'єкта (установки значень властивостей) може використовуватися спеціальний об'єкт самостійно, застосувавши спеціальні інтерфейси (IPersistFile, IPersistStorage, IPersistStream).

Фабрика класу

Для запуску екземпляра класу використовується спеціальний об'єкт-фабрика класу. З його допомогою можна створити як один об'єкт, так і декілька його екземплярів. Для кожного класу повинна існувати власна фабрика класу.

Об'єкт COM має право називатися фабрикою класу, якщо він підтримує інтерфейс IClassFactory. У ньому реалізовані всього два методи:

  • CoCreateInstance - створює новий екземпляр класу. Всі необхідні параметри, крім IID, метод отримує від фабрики класу. У цьому його відмінність від однойменного загального методу бібліотеки.

  • LockServer-залишає сервер функціонувати після створення об'єкта.

Для виклику фабрики класу існує спеціальний спільний метод CoClassObject. Як параметр йому передається CLSID потрібного класу і IID інтерфейсу (IClassFactory). Метод шукає необхідну фабрику і повертає вказівник на інтерфейс. З його допомогою і використовуючи метод CoCreateInstance, клієнт змушує фабрику класу створити об'єкт.

Бібліотека типів

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

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

Для створення бібліотеки типів, описаної за допомогою операторів IDL, використовуються спеціальні компілятори. Доступ до бібліотеки здійснюється за CLSID класу об'єкта. Крім того, бібліотека має власний GUID, який зберігається в системному реєстрі при реєстрації об'єкта.

Кожна бібліотека типів має інтерфейс ItypeLib, який працює з нею, як з єдиним об'єктом. Для доступу до інформації про окремий інтерфейсі використовується інтерфейс ItypeInfo.

Для доступу до бібліотеки по GUID використовується загальний метод LoadRegTypeLib. Якщо клієнтові відоме ім'я файлу бібліотеки, то можна скористатися методом LoadTypeLib.

1.2.2 Призначення та основні характеристики технологій ADO, MIDAS, MTS, CORBA

Загальні поняття. Відзнака «тонкого» клієнта від «товстого». «Тонким» клієнтом зазвичай називають користувальницький додаток, що не містить ніякої функціональності, і призначене тільки для введення / виведення інформації. Вся обробка даних проводиться на сервері БД, або на сервері додатків. Найчастіше, такий клієнт спочатку не містить взагалі жодних можливостей, а довантажує додаткові модулі з сервера, в міру необхідності. Зазвичай, в якості "тонкого» клієнта, виступають Web броузер + HTML / ASP / Java. «Товстий» клієнт містить всю функціональність і інтерфейсну частину в собі, і при будь-яку зміну, вимагає заміни у всіх користувачів.

Технологія ADO

ADO (Microsoft ActiveX Data Objects) це технологія стандартного звернення до реляційних даних від Microsoft. ADO представляє собою Високо-інтерфейс для доступу до OLE DB-інтерфейсів. Він дозволяє маніпулювати даними за допомогою будь-яких OLE DB-провайдерів, як входять до складу MDAC (Microsoft Data Access Components) деяких інших продуктів Microsoft, так і вироблених сторонніми виробниками. ADO містить набір об'єктів, використовуваних для з'єднання з джерелом даних, для читання, додавання, видалення та модифікації даних.

DAO, ADO, RDO ... Все це схоже на якусь гру слів, де є два ключових поняття: дані та об'єкти. (Data Access Objects - об'єкти доступу до даних, ActiveX Data Objects - ActiveX-об'єкти роботи з даними, Remote Data Objects - об'єкти видалених даних.) Насправді ж мова тут йде про різні технології доступу до даних (див. врізання «Порівняння ADO , DAO і RDO »), які мають не тільки різні внутрішні механізми, але й, що, може бути, набагато важливіше для прикладного програміста, різні перспективи на майбутнє.

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

У результаті кілька років тому Microsoft запропонувала як єдиного інтерфейсу для доступу до локальних і віддалених даних нову технологію ADO, яка сьогодні є частиною архітектури Microsoft Universal Data Access (MUDA).

ADO Extension for DDL and Security (ADOX) застосовується для вирішення різних завдань, недоступних з допомогою звичайних об'єктів ADO. Наприклад, використовуючи об'єкти ADOX, можна витягати метадані з баз даних і, отже, переносити структуру даних з однієї бази даних в іншу (у тому числі й іншого типу). Друга можливість, яка надається цим розширенням, - маніпулювання відомостями про безпеку. Наприклад, за допомогою ADOX можна отримувати інформацію про користувачів бази даних і групах користувачів, а також створювати нових користувачів і групи. ADOX розширює об'єктну модель ADO десятьма новими об'єктами, які можна використовувати як окремо, так і разом з іншими об'єктами ADO, зокрема можна застосовувати об'єкт ADO Connection для з'єднання з джерелом даних і витягувати метадані з нього.

Перш ніж заглиблюватися в деталі об'єктів ADOX, поговоримо про те, що таке метадані. У загальному випадку метадані являють собою описи об'єктів бази даних (таблиць, полів, індексів, ключів, подань, збережених процедур та інших об'єктів). У переважній більшості сучасних СУБД метадані визначаються за допомогою мови SQL (Structured Query Language). До появи ADOX єдиним програмним способом витягу метаданих з джерел даних за допомогою ADO був метод OpenSchema об'єкта ADO Connection. Для створення нових об'єктів у базі даних застосовувався мова Data Definition Language (DDL) - підмножина мови SQL, а також об'єкт ADO Command.

Багаторівневі програми

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

Потужні сервери повинні забезпечувати безперебійний доступ до даних сотень клієнтів одночасно. При цьому клієнтське ПЗ встановлено на різних апаратних платформах і працює під управлінням різних ОС. Користувачі можуть знаходиться в корпоративній мережі, звертатися до сервера через Internet, intranet або по радіоканалу.

Для створення розподілених систем розроблені підходи на основі ряду технологічних рішень. Використовуються технології COM, OLEnterprise, сокети TCP \ IP, Microsoft Transaction Server, CORBA.

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

Створення засобів розробки корпоративних систем доступу до даних є основним напрямком діяльності фірми Inprise.

У Delphi можна створювати додатки для розподілених систем на основі всіх перерахованих підходів. Для цього призначена спеціальна технологія MIDAS (Multi - tired Distributed Application Service) - Служби багаторівневих розподілених додатків. Вона забезпечує створення додатків для розподілених систем баз даних на основі єдиного підходу.

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

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

  2. сервер додатків, який складає так зване ПО проміжного шару. Зазвичай це спеціально розроблена програма, яка забезпечує взаємодію клієнтів з сервером БД. У цій області завжди знайдуться проблеми, які необхідно вирішувати: конфлікти доступу до даних, реєстрація, управління транзакціями і т.д.поетому сервер додатків надає мінімально необхідний проміжний рівень. Зазвичай він називається брокером даних. Серйозні багаторівневі додатки мають кілька рівнів ПО проміжного шару. З найбільш поширених вирішуваних завдань можна виділити реєстрацію користувачів і розмежування доступу, захист від несанкціонованого доступу, управління блокуваннями. Часто проміжний рівень повинен забезпечити доступ до БД клієнтів з різними програмними й апаратними платформами.

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




Рис.5. Структура многоуровнего програми

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

Технологія MIDAS

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

MIDAS - це технологія Borland для створення багаторівневих додатків баз даних. Застосування даної архітектури дозволяє швидко розробляти прості у супроводі та установці, надійні, розподілені БД. Трирівневе додаток баз даних містить кілька компонентів (шарів):

а) Шар БД. Зберігає дані. Виконує функції зберігання інформації, забезпечення цілісності і несуперечності даних. Приклад-локальні (dBase, Paradox) і серверні БД (Oracle, Sybase, MS SQL), текстові файли і т.д.

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

в) Презентаційний шар (тонкий клієнт). Завдання цього шару, використовуючи сервіси шару бізнес логіки, надавати користувачам запитану інформацію у формі зручним і приємним в усіх відношеннях. Може бути виконаний у вигляді традиційного exe файлу або як тонкого клієнта можна використовувати Web броузер.

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

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

Тонкий клієнт для кінцевого користувача нічим не відрізняється від звичайного (товстого) клієнта БД. Різниця в тому, що товстий клієнт через BDE, ADO, компоненти прямого доступу до серверів БД і інші бібліотеки працює з БД, а тонкий клієнт взаємодіє із сервером додатків, використовуючи MIDAS. Сервер додатків приховує від клієнта деталі доступу та обробки БД. На комп'ютері з тонким клієнтом не потрібно встановлювати і налаштовувати BDE, ADO, клієнтську частину сервера БД. Необхідно мати лише невеликі за обсягом dll, які легко переносити разом з exe файлом тонкого клієнта. В якості тонкого клієнта може використовуватися і Web браузер.

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

  • DCOM - розподілений COM розширення базової технології COM, що дозволяє клієнту використовувати властивості і методи віддалених об'єктів на сервері. Елементи COM встановлені в Windows NT, Windows 98, Windows 95 вимагає спеціальної інтсалляціі допаолнітельного ПЗ.

  • Microsoft Transaction Server (MTS) - надбудова над базовою технологією COM, що забезпечує додаткові функції при взаємодії клієнта і сервера. Це управління транзакціями, забезпечення безпеки даних. MTS доступна в ОС Windows NT, Windows 98.

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

  • OLEnterprise - розроблене фірмою Borland розширення об'єктної моделі COM, що забезпечує ряд додаткових можливостей. З його допомогою можна пов'язувати об'єкти, створені на різних мовах програмування. Відповідне ПЗ встановлюється на сервері і клієнті.

  • CORBA (Common Object Request Broker Arhitecture - Архітектура Брокера Загальних об'єктних Запитів) являє собою спеціально розроблений стандарт і ПО, що забезпечує взаімодествіе об'єктів, що маніпулюють даними в різних ОС. Основу архітектура становить ORB (Object Request Broker - Брокер об'єктних Запитів), що забезпечує взаємодію сервера додатків і клієнтів.

Відповідно до технології MIDAS, багаторівневий додаток повинно мати три складові частини:

  • Сервер додатків, який повинен містити в якості основи видалений модуль даних;

  • Клієнт, взаімодествіе якого з сервером забезпечено спецмальнимі компонентами та динамічної бібліотекою DBClient. DLL.

  • Брокер даних, який забезпечує передачу пакетів даних на основі інтерфейсу IProvider.

Технологія MTS

Створюючи в Delphi багаторівневі додатки на основі DCOM, розробники можуть розширити їхні можливості за рахунок використання додаткових функцій, що надаються спеціалізованої системної службою Microsoft Transaction Server (MTS).

MTS може працювати з ОС Windows NT, Windows 98. MTS дозволяє досить гнучко управляти режимами виконання транзакцій в системі і підтримує двофазне завершення транзакцій. Одним із суттєвих недоліків схеми управління транзакціями СОМ є необхідність явною передачі контексту транзакції в якості-аргументу при виклику віддалених методів. Така схема не є ні ефективною, ні гарантує від помилок, особливо при залученні в транзакцію великої кількості об'єктів.

Використання MTS дає серверу ряд додаткових корисних функцій:

  • При виконанні запитів підтримуються транзакції;

  • Працюючи з сервером, кілька клієнтів можуть використовувати для доступу до даних одне з'єднання. Так реалізується спільне використання ресурсів БД.

  • Забезпечуючи додаткове розмежування доступу клієнтів до інтерфейсів.

Для використання можливостей MTS необхідно лише мати встановлені динамічні бібліотеки цієї служби на комп'ютері сервера додатків.

COM + є злиттям COM-і MTS-моделей програмування, таким чином справедлива формула:

COM + MTS = COM +

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

Проте на додаток до цього з'явилися нові сервіси, значно розширюють можливості програм.

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

Потім, з реалізацією розподіленого COM в NT4 (DCOM), ця технологія набула розвитку в напрямку підтримки віддалених звернень до компонентів. MTS створювався для забезпечення роботи серверних компонент і усунення деяких недоліків DCOM. COM + з'явився для уніфікації та об'єднання COM, DCOM і MTS в узгоджену технологію, зрозумілу і зручну для реалізації додатків корпоративного рівня.

Технологія CORBA

CORBA (Common Request Broker Architecture) - архітектура для побудови розподілених об'єктних додатків. Була запропонована некомерційною організацією - консорціумом OMG (Object Management Group), що складається з декількох сотень (!) Провідних компаній з галузі розробки програмного забезпечення (включаючи таких гігантів, як Microsoft і Borland / Inprise). Перша специфікація CORBA з'явилася ще в далекому 1991 році.

Метою розробників CORBA було створення механізмів міжплатформного взаємодії додатків в розподілених системах. Можна вразитися далекоглядності OMG - адже в середині - кінці 80-х років XX століття розподілені системи не грали ту вражаючу ролі в комп'ютерній індустрії, як зараз. Крім того, розширення експансії Intel та Microsoft ставило під загрозу саме наявність різноманітності апаратно-програмних платформ. Тим не менш, у цій обстановці роботи були продовжені, причому результати були настільки успішними, що навіть всемогутній Microsoft вважав за потрібне приєднатися до консорціуму розробників, щоб тримати руку на пульсі розвитку нової перспективної технології.

Як і DCOM, CORBA грунтується на комунікації типу клієнт-сервер. Запитуючи сервіс, клієнт викликає метод, реалізований віддаленим об'єктом, що діють у ролі сервера. Сервіс, що надається об'єктом, инкапсулируется за допомогою інтерфейсу, визначеного на мові IDL. Саме власну мову IDL є однією з родзинок CORBA. Взагалі, існують три різні мови описів під одним і тим же назвою: OMG IDL (очевидно, використовується в CORBA), Microsoft IDL (розроблений для технології DCOM, але в силу двійкового представлення об'єктів не грає в цій технології ключової ролі) і OSF IDL. Проте, в порівнянні з DCOM, CORBA має ряд істотних відмінностей.

Технологія CORBA спочатку проектувалася для створення розподілених систем. У силу цього сервер об'єктів і клієнтські програми, на відміну від COM / DCOM, в технології CORBA, як правило, розташовуються на різних машинах. Взаємодія між клієнтом і сервером відбувається наступним чином. У процесі клієнта є об'єкт-посередник, іменований stub (або Client-Side Stab). Він є повноважним представником сервера і виконує функції, багато в чому схожі з функціями об'єкта Proxy в технології DCOM. Саме до stub за допомогою інтерфейсу об'єкта звертається програма-клієнт так, як ніби stub і являє собою об'єкт. Далі stub перенаправляє запит клієнта до особливого об'єкту, який діє також на машині клієнта. Цей об'єкт називається ORB (Object Required Broker, брокер об'єктних запитів). Отримавши запит, ORB формує широкомовне повідомлення у зовнішню мережу. На це повідомлення відгукується один з об'єктів Smart Agent, який функціонує на одному з комп'ютерів мережевого оточення (локальна мережа або Інтернет). Smart Agent знає, де розташовані відповідні сервери об'єктів (фактично це як би віртуальний мережевий каталог, де зареєстровані деякі сервери), і перенаправляє запит на потрібний сервер. На сервері пакет запиту приймає ще один об'єкт ORB, який дешифрує запит і пересилає його наступного об'єкта - BOA (Basic Object Adapter, базовий адаптер об'єктів). Роль об'єкта BOA полягає у фільтрації, кешуванні запитів і, відповідно, розмежування доступу до об'єкта сервера. Якщо запит пропущений BOA, то він потрапляє в об'єкт сервера skeleton. При цьому в адресному просторі сервера створюється необхідний об'єкт, skeleton поміщає аргументи виклику в стек об'єкту і реалізує власне виклик. Використовуючи об'єкт BOA, skeleton також реєструє створений серверний CORBA-об'єкт за допомогою Smart Agent, а також повідомляє про доступність, факт створення і про готовність об'єкта приймати запити клієнта. Далі слід зворотній зв'язок за описаною ланцюжку об'єктів (рис. 4.6).

<>

Рис. 4.6. Технологія CORBA

Як видно з опису, CORBA реалізує собою типову багатоланкову (тут - триланкову) архітектуру. У ролі Middleware - програмного забезпечення проміжного шару - тут виступає об'єкт Smart Agent. Зазвичай при практичній реалізації програма, що виконує Дії Smart Agent, встановлюється на виділену машину в корпоративній мережі або на кілька машин у мережі Інтернет. При створенні серверів вони реєструються на ДОСТУПНИХ Smart Agent.

ТЕМА 1.3. ВСТУП У РОБОТУ з видаленими базами даних

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

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

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

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

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

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

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

Чи має значення порядковий номер запису в таблиці. Ні. Реляційна алгебра оперує множинами, в яких порядковий номер елемента не несе ніякого смислового навантаження. Записи відрізняться тільки вмістом їх полів. Два записи, в ​​яких всі поля однакові, будуть абсолютно ідентичні в реляційної БД.

Поняття SQL-сервер. Сервер для керування реляційними БД звичайно називають SQL-сервером. SQL (Structured Query Language - мова структурованих запитів) є стандартною мовою для роботи з реляційними БД. Крім стандартних реляційних операцій, ця мова надає можливості для змін структури таблиць. Різні варіанти SQL використовуються у всіх, як серверних, так і в настільних реляційних СУБД.

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

  • Cache

  • Teradata

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

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

Поняття «Клієнт». Клієнтом до БД, зазвичай називають користувальницький додаток, яка спілкується з сервером БД. Модель роботи, в якій клієнт спілкується безпосередньо із сервером, не використовуючи проміжних додатків, називається архітектурою клієнт-сервер.

Як клієнт спілкується з сервером. На користувача машинах, зазвичай встановлюються спеціальні програми-шлюзи, які, через мережевий протокол, забезпечують зв'язок з сервером БД. Через ці шлюзи, додатки передають запити серверу і отримують результати. Часто, додатково встановлюється бібліотека (ODBC, OLE DB і т.п.), що надає додаткам API для роботи з сервером БД.

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

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

Досить поширені наступні ООБД: Cache, FastObjects, GemStone / S, Jasmine, ObjectStore, Objectivity / DB, Versant.

Що можна робити за допомогою SQL. SQL (Structured Query Language - мова структурованих запитів) є стандартною мовою для роботи з реляційними БД. Поділяється на дві основні частини: DDL (Data Definition Language - мова визначення даних) і DML (Data Manipulation Language - мова обробки даних). DDL надає засоби для створення і зміни структури зберігання даних (БД, таблиць, процедур, типів даних і т. п.). DML призначений для читання і зміни даних. Основні оператори DML: select - вибірка, insert - вставка, update - зміна, delete - видалення. Також, за допомогою SQL, часто реалізований доступ до службових функцій SQL-сервера (заклад користувачів, створення резервних копій БД і т.д.).

Навіщо потрібні транзакції. У багатьох випадках, необхідно проведення групи операцій по зміні даних таким чином, щоб ця група мала властивість атомарності (або вся цілком виконується, або вся повністю не виконується). Така група операцій називається транзакцією. У SQL-серверах існують оператори, що дозволяють позначити початок транзакції (begin transaction), її успішне завершення (commit transaction), або відкат транзакції (rollback transaction).

Журнал транзакцій. Будь-які зміни даних, проведені в транзакції, записуються в спеціальний журнал транзакцій (transaction log). При відкат транзакції, дані відновлюються в колишньому вигляді, а записи про зміни видаляються з журналу транзакцій.

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

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

Чому виникає deadlock. Перехресне блокування (deadlock) двох транзакцій виникає при зміні одних і тих же записів в різному порядку. Послідовність дій, що приводить до перехресної блокування:

1. Транзакція A змінює запис X. Заблокована X.

2. Транзакція B змінює запис Y. Заблокована Y.

3. Транзакція A намагається змінити запис Y. Зупинено A.

4. Транзакція B намагається змінити запис X. Зупинено B.

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

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

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

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

Чи можна використовувати свою функцію в SQL-запиті. Ви, практично у всіх сучасних SQL-серверах. Відмінності тільки в синтаксисі визначення і виклику функції. Крім того, деякі сервера дозволяють використовувати функції, написані на інших мовах (не SQL).

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

Збережені процедури (SP - Stored Procedure) представляють собою послідовність команд на розширеннях SQL, або на інших мовах, які підтримуються сервером. Можуть приймати параметри і повертати значення заданого типу. Часто використовуються для виконання операцій, безпосередньо пов'язаних з логікою завдання, для якої проектувалася БД. Іноді, використовуються разом з уявленнями, для забезпечення безпеки БД (всі зміни через SP, всі вибірки через view).

Типи даних є в SQL-сервері. Зазвичай, для полів у таблицях можуть використовуватися тільки найпростіші типи: числа (цілі і дробові), рядки (сильно обмежені по довжині), дата (і час), бінарні дані великого розміру (для тексту, графіки і т.п.). У деяких серверах допускається використання масивів і саморобних структур.

Необхідність зовнішнього ключа. Зовнішній ключ (FK - Foreign Key) використовується для створення жорсткої зв'язки (багато до одного) між двома таблицями. Зовнішній ключ задається тільки в тому випадку, якщо в першій таблиці є поле, що містить значення первинного ключа з другої таблиці. При зміні значення первинного ключа в другій таблиці, можуть бути змінені всі відповідні значення зв'язаного поля в першій таблиці. При видаленні запису з певним первинним ключем з другої таблиці, можуть бути видалені всі записи з відповідним значенням зв'язаного поля в першій таблиці. Зазвичай, при визначенні зовнішнього ключа, по ньому автоматично створюється індекс, який використовується у запитах при об'єднанні цих двох таблиць.

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

Типи SQL серверів та їх особливості

Який тип сервера краще вибрати? На який вистачить грошей.:) Взагалі-то це може сильно залежати від постановки задачі, кількості користувачів і примх замовника. Нижче наведена таблиця найпоширеніших SQL-серверів в порядку (приблизно) убування їх можливостей:

Сервер

Переваги

Недоліки

IBM DB2 Universal Database

Самий наворочений мову запитів, кращий оптимізатор, можливість писати функції на інших мовах.

Висока вартість.

Oracle Database

Безліч додаткових можливостей. Версионном сервер.

Дуже висока вартість сервера і підтримки.

Microsoft SQL Server

Швидко розвивається продукт, вже впритул наближається до своїх більш розвиненим конкурентам. Середня вартість.

Існує тільки для однієї платформи (Win32).

IBM Informix Dynamic Server

Досить розвинений швидкий сервер.

-

Sybase Adaptive Server Enterprise

Досить розвинений сервер. Середня вартість.

-

Sybase Adaptive Server Anywhere

Існує під безліч платформ, включаючи самі екзотичні. Низька вартість.

-

Borland InterBase

Пристойний набір можливостей. Версионном сервер. Безкоштовний.

Щодо повільно працює.

PostgreSQL

Підтримує історичну модель. Можливість створювати свої типи даних. Безкоштовний.

-

MySQL

Швидко працює на простих запитах. Безкоштовний.

Дуже бідна мова запитів. Мало додаткових можливостей.

Посилання (links):
  • http://www.oracle.com/
  • http://www.microsoft.com/
  • http://www.ibm.com/
  • http://www.sybase.com/
  • http://www.interbase.com/
  • http://www.mysql.com/
  • Додати в блог або на сайт

    Цей текст може містити помилки.

    Програмування, комп'ютери, інформатика і кібернетика | Лекція
    309кб. | скачати


    Схожі роботи:
    Методологія проектування баз даних 2
    Проектування реляційних баз даних
    Проектування баз даних MS Access
    Особливості проектування баз даних
    Введення в проектування реляційних баз даних
    Основні принципи проектування баз даних
    Методологія проектування баз даних 2 лютого
    Принципи побудови та етапи проектування баз даних
    Проектування інформаційних баз даних звіт за відвантаженими товарами
    © Усі права захищені
    написати до нас