Зацерковний В.І. та ін. ГІС та бази даних

Комп’ютери клієнтів

Рис. 10.11. Схема обробки інформації в БД за архітектурою "файл – сервер"

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

Запит на дані, які видаються клієнтом (робочою станцією), породжує пошук і добування даних на сервері. Добуті дані (однак не файли) транспортуються по мережі від сервера до клієнта. Специфікою архітектури "клієнт – сервер" є використання мови структурованих запитів SQL. Концепція "клієнт – сервер" умовно зображена на рис. 10.12.

361

Схема обробки інформації в БД за принципом "клієнт – сервер" представлена на рис. 10.13.

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

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

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

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

Прикладами таких СКБД можуть слугувати Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР.

Клієнт-серверна архітектура розділяється на декілька типів:

•дворівнева архітектура "клієнт – сервер";

•трирівнева архітектура "клієнт – сервер";

•багаторівнева архітектура або n-рівнева архітектура.

362

Дворівнева архітектура "клієнт – сервер". У випадку з дворівне-

вою архітектурою "клієнт – сервер" база даних розміщується на мережевому сервері, проте програма клієнта позбавлена можливості прямого доступу до БД. Доступ до БД регулюється спеціальною програмою – сервером БД (рис. 10.14).

Рис. 10.14. Дворівнева архітектура "клієнт – сервер"

Взаємодію сервера БД і клієнта реалізується за допомогою SQL-запи- тів, які формує і посилає серверу клієнт. Сервер, прийнявши запит, виконує його і повертає результат клієнту.

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

Проте дворівнева архітектура має низку недоліків:

•погіршення продуктивності прямо пропорційна кількості користувачів;

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

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

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

363

відміну від попередньої архітектури, обмін між клієнтом і сервером здійснюється за допомогою спеціально розробленого набору команд (API), а не SQL-запитів. Набір цих команд визначається розробником, що дозволяє йому обмежити набір допустимих дій з даними, доступних клієнтові. Трирівнева архітектура "клієнт – сервер"представлена на рис. 10.15.

API

Прикладний

Другий рівень компонент Сервер додатка

База

даних

Рис. 10.15. Трирівнева архітектура "клієнт – сервер"

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

Багаторівнева архітектура "клієнт – сервер" – різновид архітекту-

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

Трирівнева архітектура є окремим випадком багаторівневої, але якщо розглядати їх окремо, то можна виділити декілька переваг багаторівневої архітектури перед трирівневою, такі як:

•масштабованість. Навантаження поділяється на декілька webсерверів, які взаємодіють з БД або з сервером наступного рівня.

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

364

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

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

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

• за характером використання:

–персональні СКБД;

–багатокористувацькі СКБД.

До персональних СКБД відносяться VISUAL FOXPRO, ACCESS та ін. До багатокористувацьких СКБД відносяться, наприклад, СКБД ORACLE та

INFORMIX.

Багатокористувацькі СКБД включають в себе сервер БД і клієнтську частину, працюють в неоднорідному обчислювальному середовищі, припускають різні типи ЕОМ і різні операційні системи. Тому на базі СКБД можна створити інформаційну систему, що функціонує за технологією "клієнт – сервер".

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

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

• за типом використовуваних даних:

–слабко типізовані;

–сильно типізовані.

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

365

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

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

Більшість моделей, що використовуються в автоматизованих системах, зокрема в БД, належать до сильно типізованих.

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

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

366

367

Модель даних розглядається як сполучення трьох компонентів:

•структурна частина – набір правил, за якими може бути побудована база даних;

•керуюча частина, яка визначає типи припустимих операцій з даними;

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

Схема класифікації моделей даних за рівнями подання наведена на рис. 11.2.

Моделі даних

ІнфологічніМоделіданихмоделі

Діаграма Бахмана

Модель "сутність – зв’язок"

Даталогічні моделі

Рис. 11.2. Класифікація моделей даних за рівнями подання

368

11.2. Інфологічні моделі

Інфологічна модель (інформаційно-логічна модель, ІЛМ) –

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

Класифікація інфологічних моделей представлена на рис. 11.3.

ІЛМ даних використовуються на ранніх стадіях проектування для опису структур даних у процесі розробки баз даних або додатків.

Мета інфологічного проектування – створити структуровану інфор-

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

адекватно відображати модельовану ПС;

однозначно трактувати модель;

чітко визначати ПС, що моделюється (кінцевість моделі);

легко розширюватись (забезпечувати введення і видалення нових даних без зміни попередньо визначених);

забезпечувати композицію і декомпозицію моделі в зв’язку з великою розмірністю реальних інфологічних моделей;

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

забезпечувати можливість застосування мови специфікацій моделі як при ручному, так і при автоматизованому проектуванні СКБД.

ІЛМ ПС може бути описана різним чином (рис. 11.4).

369

Існує два підходи до інфологічного проектування: аналіз об’єктів і синтез атрибутів (семантичні моделі). Підхід, що базується на аналізі об’єктів, називається низхідним, а на синтезі атрибутів – висхідним.

Семантичні моделі головну увагу приділяють структурі даних. Найбільш поширеною семантичною моделлю є модель "сутність – зв’язок"

(Entity Relationship model, ER-модель).

ER-модель складається із сутностей, зв’язків, атрибутів, доменів ат-

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

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

Зближення цих моделей реалізується в розширеному ER-моде-

люванні (Extended Entity Relationship model, EER-модель).

Модель "сутність – зв’язок". Оскільки реальний світ складається із сутностей та зв’язків, модель "сутність – зв’язок" можна розглядати як універсальний спосіб подання даних. Основна мета побудови моделі "сутність

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

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

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

Зв’язок – асоціювання двох або більше сутностей.

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

370