Зацерковний В.І. та ін. ГІС та бази даних. І бази даних
 Скачать 31.1 Mb.
|
|
Категорії користувачів Внутрішні Зовнішні (кінцеві) Адміністратор даних Адміністратор баз даних Адміністратори додатків Системні програмісти Прикладні програмісти Прямі (регулярні) Непрямі (нерегулярні, випадкові) 355 На групу АБД покладаються найбільш складні обов’язки. В складі групи адміністратора БД повинні бути: – системні аналітики; – проектувальники структур даних і зовнішнього по відношенню до БД інформаційного забезпечення; – проектувальники технологічних процесів обробки даних; – системні програмісти; – прикладні програмісти; – фахівці з технічного обслуговування; – оператори. Системні програмісти – забезпечують функціонування СКБД у середовищі операційної системи, розробляють компоненти, які розши- рюють програмне забезпечення СКБД. Прикладні програмісти – розробляють прикладні програми СКБД, які забезпечують функціонування СКБД. Адміністратор БД: – на стадії проектування і розробки є, зазвичай, керівником проекту створення БД. Він керує роботами з розробки БД і програмного забез- печення БД; – на стадії експлуатації відповідає за функціонування системи (захист даних від руйнування і від несанкціонованого доступу, забезпечення достовірності даних, аналіз ефективності використання ресурсів). Основні функції групи адміністратора БД 1. Аналіз предметної сфери: опис предметної сфери, виявлення обмежень цілісності, визначення статусу (доступності, секретності) інфор- мації, визначення потреб користувачів, визначення відповідності "дані – користувач", визначення об’ємно-часових характеристик обробки даних. 2. Проектування структури БД: визначення складу і структури файлів БД і зв’язків між ними, вибір методів упорядкування даних і методів доступу до інформації, опис БД на мові опису даних. 3. Завдання обмежень цілісності при опису структури БД і процедур обробки БД: • завдання декларативних обмежень цілісності, притаманних предметній сфері; • визначення динамічних обмежень цілісності, притаманних пред- метній сфері в процесі зміни інформації, що зберігається в БД; • визначення обмежень цілісності, що викликана структурою БД; • розробка процедур забезпечення цілісності БД при введенні і корегуванні даних; • визначення обмежень цілісності при паралельній роботі користу- вачів у багатокористувацькому режимі. 356 4. Первісне завантаження і ведення БД: – розробка технології первісного завантаження БД, яка буде різни- тись від процедури модифікації і доповнення даними при штатному вико- ристанні БД; – розробка технології перевірки відповідності введених даних ре- альному стану предметної сфери. БД моделює реальні об’єкти певної предметної сфери та взаємозв’язки між ними, і на момент початку штат- ної експлуатації ця модель повинна повністю відповідати стану об’єктів предметної сфери на даний момент часу; – відповідно до розробленої технології первісного завантаження може знадобитись проектування системи первинного введення даних. 5. Захист даних: • визначення системи паролів, принципів реєстрації користувачів, створення груп користувачів, що мають однакові права доступу до даних; • розробка принципів захисту конкретних даних і об’єктів проек- тування; розробка спеціалізованих методів кодування інформації при її циркуляції в локальній і глобальній інформаційних мережах; • розробка засобів фіксації доступу до даних і спроб порушення системи захисту; • тестування системи захисту; • дослідження випадків порушення системи захисту і розвиток динамічних методів захисту інформації в БД. 6. Забезпечення відновлення БД: – розробка організаційних засобів архівування і принципів віднов- лення БД; – розробка додаткових програмних засобів і технологічних процесів відновлення БД після збоїв. 7. Аналіз звернень користувачів БД – збір статистики за характе- ром запитів, часом їх виконання, вихідними документами, що вимагаються. 8. Аналіз ефективності функціонування БД: • аналіз показників функціонування БД; • планування реструктуризації (змін структури) БД і реорганізації банків даних (БнД). 9. Робота з кінцевими користувачами: – збір інформації про зміну предметної сфери; – збір інформації про оцінку роботи БД; – навчання користувачів, їх консультування; – розробка необхідної методичної і навчальної документації для роботи кінцевих користувачів. 10. Підготовка і підтримка системних засобів: • аналіз існуючих на ринку програмних засобів і аналіз можливості та необхідності їх використання в рамках БД; 357 • розробка необхідних організаційних і програмно-технічних захо- дів з розвитку БД; • перевірка працездатності закуповуваних програмних засобів перед підключенням їх до БД; • опікуватись підключенням нових програмних засобів до БД. 11. Організаційно-методична робота з проектування БД: – вибір або створення методики проектування БД; – визначення цілей і напрямку розвитку системи в цілому; – планування етапів розвитку БД; – розробка загальних словників-довідників проекту БД і концепту- альної моделі; – стикування зовнішніх моделей розроблюваних додатків; – опікуватись підключенням нового додатку до діючої БД; – забезпечення можливості комплексного налагоджування множини додатків, що взаємодіють з однією БД. Адміністратори додатків(АБД) – це група користувачів, яка функціонує під час проектування, створення та реорганізації БД. Проте не для кожної БД можна виділити наведені типи користувачів. Наприклад, при розробці ГІС з використанням настільних СКБД адміністратор БД, адміністратор додатків і розробник найчастіше існують в одній особі. Однак при побудові сучасних складних корпоративних баз геоданих, які використовуються для автоматизації всіх або більшої частини процесів управління територіями, можуть існувати і групи адміністраторів додатків, і відділи розробників. Адміністратори додатків координують роботу розробників при роз- робці конкретної програми або комплексу програм, об’єднаних у функціональну підсистему. Розробники конкретних програм працюють з тією частиною інформації з БД, яка потрібна для конкретного додатка. Адміністратор додатків визначає для додатків підмоделі даних. Тим самим різні додатки забезпечуються власним "поглядом", але не на всю БД, а тільки на потрібну для конкретного додатка ("видиму") її частину. Вся інша частина БД для даного додатка буде "прозорою". Прикладні програмісти мають, зазвичай, у своєму розпорядженні один або декілька мов програмування, за допомогою яких генеруються прикладні програми. Кінцеві користувачі – це основна категорія користувачів, в інтересах яких і створюється база даних. Залежно від особливостей створюваного БД коло його кінцевих ко- ристувачів може істотно різнитись. Це можуть бути непрямі (випадкові) користувачі, які звертаються до БД час від часу за отриманням певної інформації, а можуть бути й прямі (регулярні) користувачі. 358 Прямі кінцеві користувачі працюють з СКБД в інтерактивному ре- жимі. Фактично вони забезпечують актуальність бази даних, тобто вно- сять оперативну інформацію, дають команди на обробку і видачу даних. Непрямі кінцеві користувачі не вступають у безпосередній контакт з програмно-технічними компонентами СКБД. Вони формулюють свої запити службі адміністратора БД і прямим кінцевим користувачам. Випадковими користувачами можуть виступати, наприклад, можливі клієнти ГІС (школярі, студенти, пересічні громадяни тощо), що ознайом- люються з її можливостями послуг з узагальненим або докладним описом того чи іншого. Регулярними користувачами можуть бути фахівці органів влади, управління навколишнього середовища, що працюють зі спеціально роз- робленими для них програмами, які забезпечують автоматизацію їх діяль- ності при виконанні своїх посадових обов’язків. Наприклад, фахівець, який планує роботу з охорони земель, має в своєму розпорядженні програму, яка допомагає йому планувати і розподіляти поточні перевірки земельного законодавства, контролювати хід їх виконання, замовляти необхідну інформацію з різних підрозділів. Головний принцип полягає в тому, що від кінцевих користувачів не повинно вимагатися спеціальних знань у сфері ГІС, обчислювальної техніки і мовних засобів. 10.7. Класифікація СКБД і моделей баз даних Модель даних – сукупність структур даних, обмежень ціліснос- ті та операцій їх обробки. Модель даних є ядром будь-якої бази даних. За допомогою моделі да- них можуть бути подані об’єкти предметної сфери та взаємозв’язки між ними. Моделі даних можна класифікувати за різними ознаками: • за структурою організації даних: – ієрархічні; – мережеві; – реляційні; – багатовимірні; – об’єктно орієнтовані; • за місцем збереження даних: –внутрішня модель (фізична база даних) являє собою найнижчий рівень БД. Вона складається з різних екземплярів типів даних, які зберіга- ються на пристроях зовнішньої пам’яті; –зовнішня модель. Зазвичай, користувача цікавить лише певна части- на БД. Окрім того, користувач не знає, яким чином фізично зберігаються ці 359 дані. Зовнішня модель – це інформаційний зміст бази даних у вигляді, як її уявляє собі користувач. Для звертання до бази даних можуть використо- вуватися як мови програмування, так і спеціалізовані мови, наприклад мова структурованих запитів SQL; • за характером інформації, що зберігається в БД: – фактографічні; – документальні. Якщо провести аналогію з прикладами інформаційних сховищ на паперових носіях, то фактографічні БД – це картотеки, а документальні – це архіви. У фактографічних БД зберігається лаконічна інформація в стро- го визначених форматах. В документальних БД – будь-які документи, причому не обов’язково текстові, але й графіка, відео, звук (мультимедіа). • за технологією обробки даних (рис. 10.8): Рис. 10.8. Класифікація баз даних за технологією обробки Централізована база даних зберігається в пам’яті однієї обчислю- вальної системи. Якщо ця система є мейнфреймом 39 , то доступ здійсню- ється за допомогою терміналів або файловим сервером локальної мережі. Розподілена база даних складається з декількох, можливо, таких, що перетинаються або навіть дублюючих одна одну, частин, які зберігаються в різних ЕОМ обчислювальної мережі. Робота з такою базою здійснюєть- ся за допомогою системи керування розподіленою базою даних (СКРБД); • за способом доступу до даних (рис. 10.9): Рис. 10.9. Класифікація баз даних за способом доступу до даних 39 Мейнфре́йм (від англ. mainframe) – великий універсальний високопродуктивний відмовостій- кий сервер зі значними ресурсами введення-виведення, великим об’ємом оперативної і зовніш- ньої пам’яті, призначеної для використання в критично важливих обчислювальних системах. Класифікація баз даних за технологією обробки Централізовані Розподілені Класифікація баз даних за способом доступу до даних З локальним доступом Віддаленим (мережевим) доступом 360 Системи централізованих баз даних з віддаленим (мережевим) до- ступом припускають різні архітектури подібних систем, а саме – "файл – сервер" і "клієнт – сервер". "Файл – сервер". Архітектура БД з мережевим доступом припускає виділення одного з комп’ютерів мережі як центрального (мережевого). Концепція архітектури БД "файл – сервер" зображена на рис. 10.10. Рис. 10.10. Концепція архітектури БД "файл – сервер" На такій машині зберігається спільно використовувана централізована БД. Усі інші комп’ютери мережі виконують функції робочих станцій, за допомогою яких підтримується доступ користувацької системи до центра- лізованої БД. Файли БД відповідно до користувацьких запитів передаються на робочі станції, де в основному і відбувається обробка. При великій інтен- сивності доступу до одних і тих же даних продуктивність ІС знижується. Користувачі можуть також створювати на робочих станціях локальні БД, які використовуються ними монопольно. Схема обробки інформації в БД за принципом "файл – сервер" представлена на рис. 10.11. До переваг такої архітектури передусім слід віднести відсутність високих вимог до продуктивності сервера (головна вимога – забезпечен- ня необхідного об’єму дискового простору та відсутність необхідності розміщення й інсталяції СКБД на сервері). Серед недоліків такої архітектури потрібно відзначити високий ме- режевий трафік 40 та відсутність спеціальних механізмів захисту файлів БД з боку СКБД. На даний час файл-серверні СКБД (Microsoft Access, Borland Paradox) вважаються застарілими. 40 Мережевий трафік, або інтернет-трафік (англ. traffic – "рух", "вантажообіг") – об’єм інфор- мації, що передається через комп’ютерну мережу за певний період часу. Кількість трафіка ви- мірюється як в пакетах, так і в бітах, байтах та їх похідних: кілобайт (Кб), мегабайт (Мб) тощо. у 361 Рис. 10.11. Схема обробки інформації в БД за архітектурою "файл – сервер" "Клієнт – сервер" За цією концепцією передбачається, що, крім збе- реження централізованої бази даних, центральний комп’ютер (сервер бази даних) повинен забезпечувати виконання основного об’єму обробки даних. Запит на дані, які видаються клієнтом (робочою станцією), породжує пошук і добування даних на сервері. Добуті дані (однак не файли) транс- портуються по мережі від сервера до клієнта. Специфікою архітектури "клієнт – сервер" є використання мови структурованих запитів SQL. Концепція "клієнт – сервер" умовно зображена на рис. 10.12. Рис. 10.12. Схема обробки інформації в БД за принципом "клієнт – сервер" Клієнт 1 Клієнт 2 Клієнт 3 Клієнт 4 SQL SQL набір даних набір даних SQL-сервер Сервер 1. Реєстрація на сервері при вході в клієнтську частину 2. Формування SQL-запиту та його відправка SQL-серверу 3. Виконання отриманого SQL-запиту та відправка наборів даних серверу Комп’ютери клієнтів 362 Схема обробки інформації в БД за принципом "клієнт – сервер" представлена на рис. 10.13. Рис. 10.13. Схема обробки інформації в БД за архітектурою "клієнт – сервер" До переваг такої архітектури передусім треба віднести більш м’який трафік мережі та забезпечення за допомогою SQL-сервера функцій цілісності і забезпечення даних. Крім того, робить можливим у більшості випадків розподіл функцій обчислювальної системи між декількома незалежними комп’ютерами в мережі. Всі дані зберігаються на сервері, який, зазвичай, захищений наба- гато краще за більшість клієнтів і дозволяє використовувати ресурси одного сервера клієнтам з різними апаратними платформами, операцій- ними системами тощо. До недоліків треба віднести високу вартість устаткування. Непра- цездатність сервера може зробити непрацездатною всю обчислювальну мережу. Підтримка роботи даної системи вимагає окремого фахівця – системного адміністратора. Прикладами таких СКБД можуть слугувати Firebird, Interbase, IBM DB2, MS SQL Server, Sybase, Oracle, PostgreSQL, MySQL, ЛИНТЕР. Клієнт-серверна архітектура розділяється на декілька типів: • дворівнева архітектура "клієнт – сервер"; • трирівнева архітектура "клієнт – сервер"; • багаторівнева архітектура або n-рівнева архітектура. Сервер Комунікаційна мережа Робоча станція (Клієнт) Робоча станція (Клієнт) 363 Дворівнева архітектура "клієнт – сервер". У випадку з дворівне- вою архітектурою "клієнт – сервер" база даних розміщується на мереже- вому сервері, проте програма клієнта позбавлена можливості прямого доступу до БД. Доступ до БД регулюється спеціальною програмою – сервером БД (рис. 10.14). Рис. 10.14. Дворівнева архітектура "клієнт – сервер" Взаємодію сервера БД і клієнта реалізується за допомогою SQL-запи- тів, які формує і посилає серверу клієнт. Сервер, прийнявши запит, виконує його і повертає результат клієнту. В клієнтському застосуванні в основному здійснюються інтерпрета- ція отриманих від сервера даних, реалізація призначеного для користувача інтерфейсу, а також реалізація частини бізнес-правил. Проте дворівнева архітектура має низку недоліків: • погіршення продуктивності прямо пропорційна кількості корис- тувачів; • незалежно від того, який тип клієнта використовується, велика частина обробки даних повинна знаходитися в БД, це означає, що вона повністю залежить від можливостей, передбачених у БД виробником; • дворівнева архітектура настільки залежить від конкретної реалізації бази даних, що перенесення існуючих застосувань для різних СКБД стає серйозною проблемою. Трирівнева архітектура "клієнт – сервер". У цій моделі процес, що виконується клієнтом, відповідає за інтерфейс з користувачем, звертаючись за виконанням послуг до прикладного компонента. Прикладний компонент реалізований як група процесів, що виконують прикладні функції, і нази- вається сервером додатка. Всі операції над інформаційними ресурсами баз даних виконуються компонентами доступу до ресурсів. Таким чином, на Перший рівень Клієнт Другий рівень Сервер бази даних База даних Прикладний компонент Компонент представлення Компонент доступу до ресурсів SQL Виклик 364 відміну від попередньої архітектури, обмін між клієнтом і сервером здійснюється за допомогою спеціально розробленого набору команд (API), а не SQL-запитів. Набір цих команд визначається розробником, що до- зволяє йому обмежити набір допустимих дій з даними, доступних клієнтові. Трирівнева архітектура "клієнт – сервер" представлена на рис. 10.15. |