Рис. 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. У ньому реалізовані всього два методи: Для виклику фабрики класу існує спеціальний спільний метод 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) - Служби багаторівневих розподілених додатків. Вона забезпечує створення додатків для розподілених систем баз даних на основі єдиного підходу. Багаторівневі додатки являють собою розподілені системи віддаленого доступу до даних, які складаються як мінімум з трьох логічних рівнів. Сервер БД, що забезпечує функціонування використовуваної додатком БД і безпосередню обробку запитів користувачів. Для створення серверів БД є готові рішення, що надаються цілою низкою компаній. У залежності від призначення БД, обсягу, розв'язуваних завдань завжди можна підібрати найбільш відповідний варіант. сервер додатків, який складає так зване ПО проміжного шару. Зазвичай це спеціально розроблена програма, яка забезпечує взаємодію клієнтів з сервером БД. У цій області завжди знайдуться проблеми, які необхідно вирішувати: конфлікти доступу до даних, реєстрація, управління транзакціями і т.д.поетому сервер додатків надає мінімально необхідний проміжний рівень. Зазвичай він називається брокером даних. Серйозні багаторівневі додатки мають кілька рівнів ПО проміжного шару. З найбільш поширених вирішуваних завдань можна виділити реєстрацію користувачів і розмежування доступу, захист від несанкціонованого доступу, управління блокуваннями. Часто проміжний рівень повинен забезпечити доступ до БД клієнтів з різними програмними й апаратними платформами. Сукупність клієнтських програм або клієнтський рівень програми. У даному випадку використовуються «тонкі» (або «слабкі») клієнти, які, на відміну від аналогічних програм в архітектурі клієнт / сервер, виконують тільки мінімальні функції по відображенню даних і передачі запитів серверу, а результатів - назад.
Рис.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 використовуються у всіх, як серверних, так і в настільних реляційних СУБД. Поняття пост-реляційної бази даних. Пост-реляційними, часто називають багатовимірні бази даних. Дані в багатовимірних базах, подаються у вигляді розріджених багатовимірних масивів, а не плоских таблиць, як в реляційних базах. Для певних завдань, багатовимірні бази можуть давати значний виграш у швидкодії, в порівнянні з реляційними. Найбільш відомі багатовимірні СУБД: Різновиди СУБД. Крім реляційних, об'єктно-орієнтованих та багатовимірних СУБД, також давно відомі ієрархічні і мережеві бази даних. Дані та зв'язку між ними, в ієрархічних БД представлені у вигляді дерев. Для деяких завдань, така форма подання даних може виявитися набагато ефективнішою, ніж будь-яка інша. У мережевих базах, дані можуть бути пов'язані довільним чином, але ці зв'язки повинні створюватися попередньо, разом зі структурою даних. У порівнянні з реляційними БД, мережева модель може давати виграш у швидкодії, при деякій втрати гнучкості. Поняття «сервер баз даних». Під сервером БД зазвичай мається на увазі СУБД, запущена на тій же машині, де знаходяться файли БД, і монопольно розпоряджається цими файлами. При цьому, всі користувальницькі додатки повинні працювати з базою тільки через цю СУБД, використовуючи її мову запитів. Поняття «Клієнт». Клієнтом до БД, зазвичай називають користувальницький додаток, яка спілкується з сервером БД. Модель роботи, в якій клієнт спілкується безпосередньо із сервером, не використовуючи проміжних додатків, називається архітектурою клієнт-сервер. Як клієнт спілкується з сервером. На користувача машинах, зазвичай встановлюються спеціальні програми-шлюзи, які, через мережевий протокол, забезпечують зв'язок з сервером БД. Через ці шлюзи, додатки передають запити серверу і отримують результати. Часто, додатково встановлюється бібліотека (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 лютого Принципи побудови та етапи проектування баз даних Проектування інформаційних баз даних звіт за відвантаженими товарами
|