Зацерковний В.І. та ін. ГІС та бази даних. І бази даних
 Скачать 31.1 Mb.
|
|
Рис. 10.15. Трирівнева архітектура "клієнт – сервер" Уведення додаткового рівня дозволяє здолати деякі обмеження дво- рівневої архітектури, описаних у загальних рисах вище. Як і з дворівне- вою моделлю, рівні можуть розташовуватися або на різних комп’ютерах, або на одному комп’ютері в тестовому режимі. Багаторівнева архітектура "клієнт – сервер" – різновид архітекту- ри "клієнт – сервер", у якій функція обробки даних винесена на один або де- кілька окремих серверів. Це дозволяє розділити функції зберігання, обробки і представлення даних для ефективнішого використання можливостей серверів і клієнтів. Трирівнева архітектура є окремим випадком багаторівневої, але якщо розглядати їх окремо, то можна виділити декілька переваг багато- рівневої архітектури перед трирівневою, такі як: • масштабованість. Навантаження поділяється на декілька web- серверів, які взаємодіють з БД або з сервером наступного рівня. • захищеність. Використання декількох фізичних рівнів підвищує захищеність інформаційної системи від мережевих атак, а також функцію Перший рівень Клієнт Другий рівень Сервер додатка База даних Прикладний компонент Компонент представлення Компонент доступу до ресурсів SQL API Третій рівень Сервер бази даних 365 захисту можуть виконувати всі рівні сервера, розподіляючи тим самим навантаження; • стабільність. При втраті працездатності одного з проміжних рівнів його функцію можуть поділити між собою рівні ідентичної функціональ- ності, що залишились. Хоча продуктивність у такій ситуації й зменшиться, проте система залишиться працездатною, на відміну від трирівневої системи. Багаторівнева архітектура зазвичай складається з чотирьох рівнів (рис. 10.16), де сервер мережі відповідає за обробку з’єднання між клієн- том, браузером і сервером системи. Рис. 10.16. Багаторівнева архітектура "клієнт – сервер" • за характером використання: – персональні СКБД; – багатокористувацькі СКБД. До персональних СКБД відносяться VISUAL FOXPRO, ACCESS та ін. До багатокористувацьких СКБД відносяться, наприклад, СКБД ORACLE та INFORMIX. Багатокористувацькі СКБД включають в себе сервер БД і клієнт- ську частину, працюють в неоднорідному обчислювальному середовищі, припускають різні типи ЕОМ і різні операційні системи. Тому на базі СКБД можна створити інформаційну систему, що функціонує за техно- логією "клієнт – сервер". Універсальність багатокористувацьких СКБД проявляється відпо- відно у високій ціні і комп’ютерних ресурсах, необхідних для підтримки СКБД, що становлять собою сукупність мовних і програмних засобів, призначених для створення, ведення і використання БД. Персональні СКБД забезпечують можливість створення персональ- них БД і дешевих додатків, що працюють з ними, і, за потреби, створення додатків, що працюють із сервером БД; • за типом використовуваних даних: – слабко типізовані; – сильно типізовані. У сильно типізованих моделях усі дані мають належати до певної категорії або типу. Якщо дані не підпадають під жодну з категорій, їх Клієнт Сервер додатка Логіка додатка БД Сервер БД БД Збережені процедури Тригери Інтерфейс користувача Службові функції 366 потрібно типізувати штучно. Деякі моделі будуються у такий спосіб, що категорії визначаються наперед і не можуть змінюватись динамічно. У цьому разі модельований світ начебто вміщується в гальмівну сорочку. Наприклад категорія "службовець" – строго фіксована, й усі об’єкти повинні мати однакові властивості та структуру. Сильно типізовані моделі мають значні переваги, бо дають змогу побудувати абстракції властивостей даних і дослідити їх у термінах категорій. Більшість моделей, що використовуються в автоматизованих систе- мах, зокрема в БД, належать до сильно типізованих. Для слабко типізованих належність даних до тієї або іншої категорії не має жодного значення. Категорії використовуються настільки, наскільки це доцільно в кожному конкретному випадку. Окремі дані можуть існувати як незалежно, так і у зв’язку з іншими. Інформація про категорії, якщо вони використовуються, розглядається як додаткова. На відміну від сильно типізованих моделей, слабко типізовані забез- печують інтеграцію даних і категорій. Найкращі можливості такої інте- грації надаються численням предикатів, яке у багатьох моделях викорис- товується для зображення знань, що підтримуються базовими засобами моделювання. 367 ХІ. МОДЕЛІ БАЗ ДАНИХ 11.1. Класифікація моделей баз даних за рівнями подання Модель даних – це інтегрований набір понять для опису даних, зв’язків між ними і обмежень, що накладаються на дані. Реалізація (implementation) заданої моделі даних – це фізичне втілення на реальній машині компонентів абстрактної машини, яке в сукупності складають цю модель. Загальний опис БД прийнято називати схемою бази даних. Для кожного рівня архітектури ANSI-SPARC існують свої схеми (рис. 11.1). Рис. 11.1. Рівні схем баз даних ІНФОЛОГІЧНА МОДЕЛЬ ДАНИХ Узагальнений, не прив’язаний до будь-яких ЕОМ та СУБД опис предметної сфери (набір даних, їх типів, довжин, зв’язків і т. д.) ДАТАЛОГІЧНА МОДЕЛЬ ДАНИХ Опис на мові конкретної СКБД ФІЗИЧНА МОДЕЛЬ ДАНИХ Опис даних, що зберігаються БАЗА ДАНИХ Окремі користувачі БД Адміністратор БД <Слова>, <С 1 >, Формули A=f(x,y,z) Графіки, зображення Таблиці, моделі Моделі та описи, які використовуються в СКБД 368 Модель даних розглядається як сполучення трьох компонентів: • структурна частина –набір правил, за якими може бути побудована база даних; • керуюча частина, яка визначає типи припустимих операцій з даними; • набір обмежень підтримки цілісності даних (необов’язковий компонент), який гарантує коректність використовуваних даних. Схема класифікації моделей даних за рівнями подання наведена на рис. 11.2. Рис. 11.2. Класифікація моделей даних за рівнями подання Моделі даних Моделі даних Інфологічні моделі Даталогічні моделі Діаграма Бахмана Модель "сутність – зв’язок" Документальні моделі Орієнтовані на формат документа Дескрипторні моделі Тезаурусні моделі Фотографічні Теоретико-графові Ієрархічна Мережева Теоретико-множинні Реляційна Бінарних асоціацій Фізичні моделі Об’єктно орієнтовані Засновані на файлових структурах Засновані на сегментно-стратегічній адресації 369 11.2. Інфологічні моделі Інфологічна модель (інформаційно-логічна модель, ІЛМ) – людиноорієнтована, незалежна від типу СКБД модель ПС, яка визначає сукупності інформаційних об’єктів, їх атрибутів і відношень між ними, динаміку змін ПО, а також характер інформаційних потреб користувачів. Класифікація інфологічних моделей представлена на рис. 11.3. Рис. 11.3. Класифікація інфологічних моделей ІЛМ даних використовуються на ранніх стадіях проектування для опису структур даних у процесі розробки баз даних або додатків. Мета інфологічного проектування – створити структуровану інфор- маційну модель ПС, для якої розроблятиметься БД. Під час проектування на інфологічному рівні створюється ІЛМ, яка повинна: адекватно відображати модельовану ПС; однозначно трактувати модель; чітко визначати ПС, що моделюється (кінцевість моделі); легко розширюватись (забезпечувати введення і видалення нових даних без зміни попередньо визначених); забезпечувати композицію і декомпозицію моделі в зв’язку з великою розмірністю реальних інфологічних моделей; легко сприйматись різними категоріями користувачів (бажано, щоб ІЛМ модель будував або брав участь побудові фахівець, що працює в даній ПС, а не тільки проектувальник систем машинної обробки даних); забезпечувати можливість застосування мови специфікацій моделі як при ручному, так і при автоматизованому проектуванні СКБД. ІЛМ ПС може бути описана різним чином (рис. 11.4). Інфологічні моделі Моделі представлення добре структурованої інформації Моделі представлення недостатньо структурованої інформації IDEF- моделі Діаграми потоків даних ER-моделі Дескрипторні моделі Семантичні мережі. Тезаурус Фрейми 370 Рис. 11.4. Складові інфологічної моделі Існує два підходи до інфологічного проектування: аналіз об’єктів і синтез атрибутів (семантичні моделі). Підхід, що базується на аналізі об’єктів, називається низхідним, а на синтезі атрибутів – висхідним. Семантичні моделі головну увагу приділяють структурі даних. Най- більш поширеною семантичною моделлю є модель "сутність – зв’язок" (Entity Relationship model, ER-модель). ER-модель складається із сутностей, зв’язків, атрибутів, доменів ат- рибутів, ключів. Моделювання даних відображає логічну структуру даних, так само, як блок-схеми алгоритмів відображають логічну структуру програми. Об’єктні моделі головну увагу приділяють поведінці об’єктів даних і засобам маніпуляції даними. Головне поняття таких моделей − об’єкт, тобто сутність, яка має стан і поведінку. Стан об’єкта визначається сукупністю його атрибутів, а поведінка об’єкта визначається сукупністю операцій специфікованих для нього. Зближення цих моделей реалізується в розширеному ER-моде- люванні (Extended Entity Relationship model, EER-модель). Модель "сутність – зв’язок". Оскільки реальний світ складається із сутностей та зв’язків, модель "сутність – зв’язок" можна розглядати як уні- версальний спосіб подання даних. Основна мета побудови моделі "сутність – зв’язок" – забезпечення найбільш природного для людини способу збору та представлення даних і відомостей, які будуть зберігатися в базі даних. Сутність – певний відокремлений об’єкт (який можна відрізни- ти від інших), відомості про який необхідно зберігати в базі даних. При цьому розрізняють поняття тип сутності та екземпляр сутності. До типу сутності відносять набір однорідних даних, а кожний елемент набору буде екземпляром сутності. Наприклад, типом сутності може бути список землевласників, кожен з яких окремо буде його екземпляром. Зв’язок – асоціювання двох або більше сутностей. Оскільки в базі даних потрібні користувачеві дані можуть стосува- тися різних сутностей, то необхідно вказати їх взаємозв’язок. Наприклад, Інфологічна модель Опис об’єктів і зв’язків між ними Опис інформаційних потреб користувачів Алгоритмічні зв’язки показників Лінгвістичні відношення Обмеження цілісності 371 сутність Товари у моделі даних Склад пов’язана із двома сутностями Постачальник та Споживач. При цьому зрозуміло, що один і той самий тип товару можуть постачати різні постачальники, а споживати конк- ретний екземпляр товару – тільки конкретний споживач. Характер зв’язків між елементами бази даних визначає модель організації даних. Найбільш відомими є ієрархічна, мережева та реляційна моделі даних. Модель "сутність – зв’язок" (англ. Entity-relationship (ER) model або entity-relationship diagram) – модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених конструкцій блоків. ER- модель була запроваджена Пітером Пін-Шен Ченом 41 (Peter Chen) у 1976 р., який запропонував представляти ПС за допомогою графічних діаграм, що містять невелику кількість різнорідних компонентів. Надалі багатьма авторами були розроблені свої варіанти подібних мо- делей (нотація Мартіна, нотація IDEF1X, нотація Баркера тощо). Крім того, різні програмні засоби, що реалізують одну й ту ж нотацію, можуть від- різнятися своїми можливостями. По суті, всі варіанти діаграм "сутність – зв’язок" виходять з однієї ідеї – малюнок завжди наочніший від текстового опису. Такі діаграми використовують графічне зображення сутностей предметної сфери, їх властивостей (атрибутів) і взаємозв’язків між сутностями. ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп’ютерних додатків та інших систем (моделей). За допомогою такої моделі виділяють найсуттєвіші елементи (вузли, блоки) моделі і встановлюють зв’язки між ними. Основними поняттями моделі "сутність – зв’язок"є сутність, зв’язок і атрибут. Сутність (entity) – це реальний або уявний об’єкт, інформація про який повинна зберігатись у БД і бути доступною. Кожна сутність повинна мати найменування, виражене іменником в однині. Прикладами сутностей можуть бути такі класи об’єктів, як "Район", "Ґрунт", "Водозбори". Для позначення сутності об’єкта в різних системах використовуються прямокутники, блоки з заокругленими кутами, овали з найменуванням тощо (рис. 11.5): Рис. 11.5. Зображення сутності 41 Пітер Пін-Шен Чен – американський професор комп’ютерних наук в університеті штату Луїзіана. Район Ґрунти Водозбори 372 Примірник сутності– це конкретний представник даної сутності. Наприклад, представником сутності "Район" може бути "Район Деснян- ський". Екземпляри сутностей повинні бути помітними, тобто сутності повинні мати певні властивості, які б були унікальними для кожного екземпляра цієї сутності. При визначенні типу сутності необхідно гарантувати, що кожний екземпляр сутності може бути відрізнений від будь-якого іншого екземп- ляра тієї ж сутності. Атрибут сутності – це іменована характеристика, яка виступає певною властивістю сутності і слугує для уточнення, ідентифікації, класифікації, числової характеристики або виразу стану сутності. Імена атрибутів заносяться в прямокутник, що зображує сутність, під ім’ям. Найменування атрибута має бути виражене іменником в однині (іноді можливо з прикметником, який його характеризує). Прикладами атрибутів сутності "Співробітник" можуть бути такі атрибути, як "Табель- ний номер", "Прізвище", "Ім’я", "По батькові", "Посада", "Зарплата" тощо. Атрибути зображуються в межах прямокутника, що визначає сутність (рис. 11.6). Рис. 11.6. Зображення атрибутів Набір сутностей (entity set) – множина сутностей одного типу (що мають однакові властивості). Сутність фактично є множиною атрибутів, що описують власти- вості всіх членів даного набору сутності. Ключ сутності – це набір ненадлишкових атрибутів, значення яких у сукупності є унікальними для кожного екземпляра сутності. Ненадлишковість атрибута означає, що видалення будь-якого атрибута з ключа порушує його унікальність. Сутність може мати кілька різних ключів. Ключові атрибути зображуються на діаграмі підкресленням (рис. 11.7). Зв’язок – це графічно зображувана асоціація, що встанов- люється між двома типами сутностей. Співробітник Табельний номер Прізвище Ім’я По батькові Посада Зарплата 373 Рис. 11.7. Зображення ключа Одна сутність може бути пов’язана з іншою сутністю або сама з со- бою. Зв’язки дозволяють за однією сутністю знаходити інші, пов’язані з нею. Наприклад, зв’язки між сутностями можуть виражатися наступними фразами – "СПІВРОБІТНИК може мати декілька ДІТЕЙ", "кожен СПІВРОБІТНИК зобов’язаний числитися тільки в одному ВІДДІЛІ". Зв’язок подається у вигляді неспрямованої лінії, яка з’єднує дві сутності або яка веде від сутності до неї самої (рис. 11.8): Рис. 11.8. Зображення зв’язку В будь-якому зв’язку, відповідно до існуючої пари сутностей, що по- в’язані між собою, виділяються два кінці. На кожному кінці зв’язку зазна- чаються ім’я кінця зв’язку, ступінь кінця зв’язку (скільки екземплярів даного типу сутності повинно бути присутнім у кожному екземплярі даного типу зв’язку), обов’язковість зв’язку (чи повинен будь-який екземпляр даного типу сутності брати участь у певному екземплярі даного типу зв’язку). Примітка. Спостерігаються відмінності в способі зображення характеру зв’язків між об’єктами (використання "стрілок", "лапок", "точок" тощо для відображення "множинного" кінця зв’язку). Вони не накладають жодного відбитку на методологію побудови концептуальної моделі і алгоритм наступного переходу до даталогічної моделі. Бажано, щоб позначення, що використовуються, були інтуїтивно зрозумілими, занадто не захаращували модель, були прості в зображенні. Найчастіше переваги розробників у використанні тих або інших позна- чень визначаються просто звичкою. За можливості треба намагатись використовувати стандартизовані позначення або які широко поширені. Співробітник Дитина має належить Район Номер району Назва району Площа району Кількість населення 374 Рис. 11.9. Приклади обов’язкового і факультативного зв’язку Зв’язки можуть бути факультативнимиабообов’язковими(рис. 11.9). Кожен зв’язок має два кінці і одне або два найменування. Найме- нування зазвичай виражається в невизначеній дієслівної формі: "мати", "належати" тощо. Кожне з найменувань відноситься до свого кінця зв’язку. Іноді найменування не пишуться через їх очевидність. Кожен зв’язок може мати один із типів зв’язку представлених на рис. 11.10. Зв’язок типу "один до одного" означає, що один примірник першої сутності (лівої) пов’язаний з одним примірником другої сутності (правої). Зв’язок "один до одного" найчастіше свідчить про те, що насправді ми маємо всього одну сутність, неправильно розділену на дві. Зв’язок типу "один до багатьох" означає, що один примірник першої сутності (лівої) пов’язаний з декількома екземплярами другої сутності (пра- вої). Це найбільш часто використовуваний тип зв’язку. Ліва сутність (з боку "один") називається батьківською. Права (з боку "багато") – дочірньою. |