morozov_lektsiyi

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

Пропозиція 3.4. Запити, виражені в SQL, і відповіді до них повинні бути самими нижніми рівнями комунікацій між клієнтом і сервером.

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

1.5.2. Маніфест об’єктно-орієнтованих систем баз даних

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

1.5.3. Симпозіум Національної наукової фундації США

У лютому 1990 року, приблизно в той же час, коли були опубліковано два документиманіфести, Національна наукова фундація США скликала в Пало-Альто, Каліфорнія, симпозіум з тим, щоб виявити „чинники технологічного розвитку, які зможуть виконати функції форсування перспективної технології баз даних і відповідних фундаментальних досліджень, необхідних для практичного упровадження цієї технології”. Не дивно, що у складі учасників були автори Маніфесту третього покоління, а також і деякі з тих, хто вніс свій внесок в Маніфест об’єктно-орієнтованих систем баз даних.

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

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

2.Наступне покоління додатків баз даних матиме мало спільного з сьогоднішніми додатками, пов’язаними з обробкою даних для комерційної діяльності.

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

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

1.Пам’ять. Національному управлінню з аеронавтики і дослідження космічного простору (NASA) хотілося б мати в своєму розпорядженні пам’ять об’ємом 1016 байт для збереження цінних супутникових знімків за декілька років які планувалося колекціонувати в 90-ті роки, і ці дані необхідно зберегти для майбутніх наукових досліджень.

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

зних зачіпають загальну структуру проекту).

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

4.Мультимедійні додатки. Розширення областей використання мультимедійних додатків породжує нові проблеми в управлінні пам’яттю і управлінні транзакціями.

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

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

7.Нові моделі даних. Для підтримки нових класів додатків повинні використовуватися спеціалізовані моделі даних. Деякі з них, пов’язані з просторовими і тчасовими («орієнтованими на якийсь час») базами даних.

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

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

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

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

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

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

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

Тема 2. Управління розподіленою інформацією

2.1. Принципи управління розподіленою інформацією

"Ядром" системи управління розподіленими інформаційними ресурсами є розподілена база даних (РоБД) і система управління розподіленою базою даних (РоСУБД). Тому визначимо спочатку ці поняття.

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

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

Ці визначення можна доповнити, якщо розглянути також різні характеристики РоБД і РоСУБД. В 1987 році До. Дейт опублікував 12 правил для розподілених баз даних.

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

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

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

4.Незалежність від розташування. Користувачі і додатки не зобов’язані знати про те, де фізично розташовуються дані.

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

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

7.Розподілена обробка запитів. Обробка запитів повинна проводитися розподіленим

чином.

8.Управління розподіленими трансакціями. На розподілені бази даних необхідно розповсюдити механізми управління трансакціями і управління одночасним доступом. Ця проблема включає виявлення і розв’язання тупикових ситуацій, переривання після закінчення інтервалів часу, фіксацію і відкат розподілених трансакцій, а також ряд інших питань.

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

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

11.Незалежність від мережі. Вузли можуть бути зв’язані між собою за допомогою різноманітних мережних і комунікаційних засобів. Багаторівнева модель, властива багатьом сучасним інформаційним системам (наприклад, семирівнева модель OSI, модель TCP/IP,

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

12. Незалежність від СУБД. Локальні СУБД повинні мати змогу брати участь у функціонуванні РоСУБД.

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

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

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

2.Видалена одиниця роботи. Це означає, що на видаленому вузлі можна виконати групу запитів як атомарну одиницю (трансакцію). Додаток, взагалі кажучи, може одержувати

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

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

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

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

2.2. Моделі розподілених баз даних

РоБД можуть бути однорідними або неоднорідними, вони можуть будуватися за принципом „зверху вниз” або „знизу до верху”.

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

2.2.1. Однорідні і неоднорідні системи

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

Існує низка „варіацій на тему” однорідної системи РоБД. Так, на деякому вузлі може існувати одна глобально доступна „головна машина СУБД”, з якою були пов’язані компоненти для доступу до даних локальних баз даних, розміщені спільно з самими цими

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

Глобальна схема

Однакові СУБД

Мал. 2.1. Архітектура однорідної розподіленої бази даних

Протилежністю до однорідних систем РоБД є, звичайно, неоднорідні розподілені системи баз даних. Неоднорідні системи включають два або більше продуктів управління даними, що істотно розрізняються (наприклад, реляційні СУБД від різних постачальників, таких, як Oracle і Digital Equipment Corp., або СУБД одного постачальника, але такі, що функціонують на різних платформах і використовують різні структури баз даних, такі, як DB2 і SQL/DS компанії IBM). На мал. 2.2 показана типова конфігурація неоднорідної розподіленої бази даних.

Глобальна схема

Різноманітні СУБД

Мал. 2.2. Архітектура неоднорідної розподіленої бази даних

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

2.2.2. Методи побудови розподілених баз даних „зверху вниз” і „знизу до верху”

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

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

Концептуальна модель

Логічна модель

Реалізаційна модель

Фрагментована реалізаційна модель

Мал. 2.3. Побудова розподіленої бази даних методом „зверху вниз”

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

На мал. 2.4 показана горизонтальна фрагментація, коли в таблиці робляться горизонтальні „зрізи” відповідно до значення, скажімо, якого-небудь стовпця таблиці. Рядки даних про співробітників можуть розбиватися на підмножини, що відповідають філіалам. Дані про продажі фрагментуються за магазинами, де ці продажі проводилися. Фрагментація

може здійснюватися також за принципом „каруселі” (round-robin), а не на основі значень даних.

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

Мал. 2.4. Горизонтальна фрагментація

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

Службовці

Послужний

список Мал. 2.5. Вертикальна фрагментація

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

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

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

Трансакція оновлення

Одночасне оновлення (з керуванням паралелізмом)

Запланована синхронізація дублікатів тільки для читання

Мал. 2.6. Моделі тиражування даних

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

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

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

-управління метаданими;

-розв’язання невідповідностей імпедансу (таких, як різні представлення деякого типу об’єкту даних в різних базах даних, коли, припустимо, елемент MOVIE_TYPE - тип фільму -

водній базі даних має числове уявлення, а в іншій - символьне).

Тема 3. Технологія клієнт-сервер в базах даних

3.1. Основи архітектури клієнт-сервер

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

-створення і перевірка допустимості запитів до бази даних і операцій модифікації

даних;

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

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

На мал. 3.1 приведено концептуальне представлення типового середовища клієнтсервер.

Мал. 3.1. Найпростіше середовище клієнт-сервер

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

Упровадження стандартів дозволяє забезпечити ці дві властивості. Стандарти суттєво впливають на майбутнє систем управління інформацією з архітектурою клієнт-сервер. Зусилля з вироблення стандартів, таких, як RDA (Remote Database Access), DRDA

(Distributed Relational Database Architecture), IDAPI (Integrated Database Application Programming Interface), DAL (Data Access Language) і ODBC (Open DataBase Connectivity),

матимуть визначальний вплив на архітектуру клієнт-сервер в період до кінця 90-х років.

3.2. Основні принципи і критерії оцінки систем клієнт-сервер

Автори відомої монографії "Керівництво з розробки SQL-додатків у архітектурі клієнтсервер приводять список з 12 критеріїв, якими слід керуватися при розробці програмних продуктів і технології надання сервісів клієнт-сервер.

1.Збереження автономності серверу. Клієнти повинні слідувати правилам, встановленими серверами; вони не повинні обмежувати доступність серверів (наприклад, шляхом блокування без необхідності надмірно великих об’ємів даних) і не повинні порушувати цілісність яких-небудь даних серверу.

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

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

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

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

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

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

8.Можливість локального прототипування. Віддаленість інформації не повинна перешкоджати можливості прототипування призначених для користувача додатків.

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

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

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

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