ПСАБПП. Вступ у предмет. Поняття бізнесупроцесів та їх автоматизація
 Скачать 1.23 Mb.
|
|
9.2. Технологія доступу, зберігання та адміністрування даних у КІС Широкий розвиток КІС висунув на порядок денний проблему ефективного доступу як до локальних баз даних, так і розподілених на значній території. Недалекі ті часи, коли розробники прикладного програмного забезпечення для доступу до баз даних у середовищі СУБД фірми Microsoft використовували дві об’єктні технології Microsoft: Data Access Objects (DAO) — для доступу до локальних баз даних і Remote Data Objects (RDO ) — для доступу до віддалених баз даних. У них було реалізовано два різні програмні механізми, що пов’язувалося з необхідністю оптимізувати вирішення двох окремих завдань — доступу до локальних і віддалених БД відповідно. Подальший розвиток інформаційних систем зажадав створення технології, щоб забезпечували єдиний підхід під час роботи з базами даних різних класів. Для розв’язання цієї проблеми фірма Microsoft розробила нову технологію доступу до локальних і віддалених даних — ActiveX Data Objects (ADO), яка є частиною архітектури Microsoft Universal Data Access (MUDA ). Розроблена Microsoft технологія ActiveX призначена для надання доступу до Windows-додатків через Internet, однак в основному використовується в інтрамережах, що пов’язано з міркуваннями безпеки. Основу MUDA складає OLE DB (Object Linking and Embedding Data Base) — низькорівневий програмний СОМ-інтерфейс доступу до даних, створений під час розвитку ідеології відкритих систем на базі ODBC (Open Data Base Connectivity). Однак якщо ODBC призначений для роботи з реляційними базами даних (Access, DBF, SQL і ін.), то OLE DB пропонує одноманітний метод доступу до даних, що зберігаються в різних джерелах інформації, зокрема й у нереляційних БД (наприклад, у звичайних лінійних файлах, у папках систем електронної пошти), забезпечуючи при цьому підтримку роботи з наборами даних та ієрархічними наборами записів. Постачальником таких даних може бути будь-яке джерело, зокрема й додатки, написані відповідно до специфікацій OLE DB. Наприклад, доступ до баз даних ODBC виконується за допомогою OLE DB Provider for ODBC. АDО являє собою прикладний об’єктний інтерфейс для корпоративних інформаційних систем більш високого рівня ніж DAO i RDO. Він спрощує розробникам КІС, що використовують мови високого рівня, доступ до засобів OLE DB. Від 1998 р. використовується модернізований варіант АDО 2.0 (від 2000 р. АDО 2.1), який було вперше включено до складу Visual Studio 6.0. Отже, у розпорядженні розробників прикладних програмних засобів на цей час є три різні технології роботи з базами даних: DAO, RDO і АDО, але в перспективі дві перші поступово будуть витіснені АDО, оскільки Microsoft буде вдосконалювати й оновлювати тільки модель АDО. Нова версія АDО 2.1 значно розширила можливості поперед-ньої версії АDО 2.0 і містить значно більший набір нових функцій і кілька вдосконалених функцій з останніх випусків АDО. Окрім модернізованого варіанта основної бібліотеки до складу АDО 2.1 входить додаткова бібліотека ActiveX Data Objects Extensions for DDL and Security , або скорочено ADOX, яка надає розробникам широкий набір інструментів для отримання доступу до структури, моделі безпеки і процедур, що зберігаються в базі даних. ADOX працює з драйверами SQL Server i ODBС OLE DB. Модернізований варіант основної бібліотеки також володіє рядом нових функцій, зокрема поліпшеним індексованим пошуком, можливостями роботи зі зв’язаними таблицями й конфігурування ієрархічних даних. Версія АDО 2.1 постачається спільно з SQL Server 7.0, 2000 і Access 2000. Доступ до бази даних від прикладної програми або користувача виконується зверненням до клієнтської частини системи. Як основний інтерфейс між клієнтською й серверною частинами найчастіше використовується мова SQL. Сервери баз даних, інтерфейс яких ґрунтується лише на мові SQL, мають свої переваги й вади. Основна перевага — це стандартність інтерфейсу. Клієнтська частина будь-якої SQL орієнтованої СУБД може працювати з будь-яким SQL-сервером незалежно від того, хто виробник програмних засобів і обчислювальної техніки. Вадою є те, що за такого високого рівня інтерфейсу між клієнтською й серверною частинами на стороні клієнта працює дуже мало програм СУБД. Це можна вважати нормальним, якщо на стороні клієнта використовується малопотужна робоча станція. Але якщо клієнтський комп’ютер володіє достатньою потужністю, то тоді на нього доцільно покласти більше функцій управління базами даних, розвантаживши в такий спосіб сервер, який є вузьким місцем усієї КІС. З іншого боку, якщо різниця в потужності сервера і клієнтської робочої станції занадто велика, доцільно перенести більшу частину прикладної програми на сторону сервера. Одним із перспективних напрямів удосконалення доступу до даних є гнучке конфігурування системи, при якому розподіл функцій між клієнтською й серверною частинами системи можливий за допомогою використання механізму віддалених процедур. У тексті програми віддалений виклик процедури нічим не відрізняється від віддаленого виклику і теоретично будь-який компонент системи може розміщуватися і на стороні сервера, і на стороні клієнта. Практично на сьогодні на стороні клієнта працює лише таке програмне забезпечення, яке не має безпосереднього доступу до баз даних, а звертається для цього до сервера з використанням мови SQL. Під час забезпечення Web-доступу до існуючих БД можливий ряд альтернативних способів технологічних і організаційних вирішень. Практика використання Web-технологій для доступу до баз даних надає широкий спектр технологічних вирішень, які по-різному пов’язані між собою. Вибір конкретних вирішень для забезпечення доступу залежить від специфіки конкретної СУБД і ряду інших факторів, таких як існування БД, Web-доступ до яких має здійснюватися з мінімальними додатковими витратами; наявність спеціалістів, які спроможні з мінімальними витратами освоїти відповідну гілку технологічних вирішень тощо. Використовують три основні варіанти Web-доступу до баз даних. 1. Однорвзове або періодичне перетворення вмісту БД у статичні документи. За цього варіанта зміст БД переглядає спеціальна програма-перетворювач, яка створює множину файлів — низку HTML-документів. Отримані файли копіюються на WWW-сервер. Доступ до них здійснюється як до статичних гіпертекстових документів сервера. Цей варіант характеризується мінімальними початковими витратами. Він ефективний у разі використання невеликих масивів даних простої структури з нечастим оновленням, а також у разі занижених вимог до актуальності даних, що доставляються за допомогою WWW. Крім того, для нього характерна цілковита відсутність механізму пошуку, але можливе використанням індексування. Як перетворювач може використовуватися програмне забезпечення, яке автоматично або напівавтоматично генерує статичні документи. Програма-перетворювач може бути або самостійно розробленою, або ж інтерпретованим засобом з-поміж існуючих на ринку різноманітних програм типу генераторів звітів. 2. Динамічне створення гіпертекстових документів на основі вмісту БД. У цьому варіанті доступ до БД здійснюється за допомогою спеціальної CGI (Common Gateway Interface ) — програми, що запускається Web-сервером у відповідь на запит Web-клієнта. Ця програма, обробляючи запит, переглядає зміст БД і створює вихідний HTML-документ, який повертається клієнту (рис. 9.1). Рис. 9.1. Схема динамічного створення гіпертекстових документів Використання цього варіанта ефективне для великих баз даних зі складною структурою та в разі необхідності підтримки операцій пошуку, а також за частого оновлення і неможливості синхронізації перетворення БД у статичні документи з оновленням вмісту БД. За цього варіанта можливо вносити зміни до БД за допомогою WWW-інтерфейсів. Для реалізації такої технології необхідно використати взаємодію Web-сервера з програмами CGI, що запускаються. Вибір програмних засобів для реалізації цього варіанта достатньо широкий. Це мови програмування (C++, Perl, Ada) та інтегровані засоби типу генераторів звітів. Під час використання сучасних реляційних СУБД із внутрішніми мовами програмування можливе використання цих мов для генерації документів. До вад варіанта Web-доступу до БД за допомогою CGI можна віднести значний час оброблення запитів, необхідність постійного доступу до основної бази даних, додаткове завантаження засобів підтримки БД, пов’язане з обробленням запитів від Web-сервера. Створення інформаційного сховища на базі високопродуктивної СУБД з мовою запитів SQL. Цей варіант є найбільш вдалим з погляду розвитку сучасних концепцій сховищ даних. В основі його лежить періодичне завантаження даних у сховище з традиційних СУБД. Для оброблення різноманітних запитів, зокрема й від Web-сервера, використовується проміжна БД (інформаційне сховище) з високою продуктивністю. Інформаційне наповнення сховища даних здійснюється спеціалізованим програмним забезпеченням на основі вмісту основних баз даних і охоплює два етапи — перевантаження даних з основних БД до сховища даних (СД) і оброблення запитів (рис. 9.2 і 9.3 відповідно). Рис. 9.2. Перевантаження даних до сховища Рис. 9.9. Оброблення запитів Цей варіант позбавлений усіх вад попередньої схеми. Крім того, після встановлення синхронізації даних інформаційного сховища з основними БД можливе перенесення користувацьких інтерфейсів на інформаційне сховище, що істотно підвищить надійність і продуктивність доступу, дозволить організувати розподілені автоматизовані робочі місця. Основою підвищення продуктивності оброблення Web-запитів і різкого підвищення швидкості розроблення Web-інтерфейсів є використання внутрішніх мов СУБД інформаційного сховища для створення гіпертекстових документів. Для перевантаження даних з основної бази до сховища можуть використовуватися мови програмування, інтегровані засоби, а також спеціалізовані засоби перевантаження, що постачаються із SQL -сервером, і продукти підтримки інформаційних сховищ. Зауважимо, що провідні розробники СУБД останнім часом інтенсивно шукають і пропонують на ринок постреляційні рішення (POSTGRES), чітко розуміючи, що можливості панівної нині реляційної ідеології майже вичерпалися. Найімовірніше, у найближчі роки відбудеться масовий відхід від реляційної побудови баз даних і перехід до об’єктно-орієнтованих СУБД. Напрям POSTGRES належить до числа так званих постреляційних систем, тобто до наступного етапу в розвитку реляційних СУБД. Як відомо, реляційним СУБД притаманна деяка обмеженість під час використання в нетрадиційних галузях, в яких потрібні гранично складні структури даних. Іншою вадою реляційних баз даних є неможливість адекватного відображення семантики предметної галузі. Крім того, суто реляційна модель і реалізовані на ній SQL-сервери потребують потужного устаткування й далеко не завжди дають змогу провести оптимізацію запитів, а тим більше, забезпечити роботу з постійно оновлюваними даними в реальному масштабі часу. Тому сучасні дослідження в галузіпостреляційних систем присвячені переважно усуненню зазначених вад і наданню їм якостей, яких немає в більшості реляційних СУБД. Такими якостями є, наприклад, повнота системи типів, підтримка ієрархії і успадкування типів, можливість управління складними об’єктами і т. ін. Першу постреляційну СУБД — POSTGRES 95 — було спроектовано й розроблено в Каліфорнійському університеті м. Берклі під керівництвом відомого спеціаліста в галузі баз даних професора Стоунбрейкера. СУБД POSTGRES 95 зберігає основні якості реляційних СУБД, але на відміну від них підтримує темпоральну модель зберігання і доступу до даних. Тобто для будь-якого об’єкта даних, створеного в момент часу t і знищеного в момент часу t , у БД зберігаються і доступні користувачам усі його стани в часовому інтервалі (t , t ). Нагадаємо, що звичайні БД зберігають миттєвий знімок моделі предметної галузі, і будь-які зміни в момент часу t деякого об’єкта приводять до недосяжності цього об’єкта в попередній момент часу. Незважаючи на те, що в більшості розвинутих СУБД попередній стан об’єкта зберігається в журналі змін, до нього нема доступу зі сторони користувача. У зв’язку з цим у СУБД POSTGRES 95 переглянуто механізм журналізації змін, відкатів транзакцій і відновлення БД після збою. Особливість системи управління пам’яттю заключається в тому, що не ведеться звичайна журналізація, а миттєво забезпечується коректний стан БД. Система управління пам’яттю полягає також історичні дані, відповідні можливості роботи з якими закладено в мову POSTQUEL . Запити можуть містити виборку даних як за фіксований час, так і за відповідний інтервал часу. Одним з основних положень реляційної моделі даних є вимога нормалізації відношень: поля кортежів можуть містити лише атомарні значення. Надання вихідному табличному представленню предметної галузі першої нормальної форми є основним кроком у процесі проектування реляційної БД. У СУБД POSTGRES 95 реалізовано ненормалізовану реляційну модель даних, яка допускає зберігання як елемента кортежу багатомірних масивів фіксованої та змінної довжини та інших даних, зокрема абстрактних, визначених користувачем типів і т. ін. У СУБД POSTGRES 95 реалізовано дві основні можливості доступу до даних: — за допомогою psgl-інтерфейсу командного рядка командної оболонки Shell; — із прикладної програми, написаної мовою програмування С або іншою мовою з використанням функцій прикладного інтерфейсу LIBPQ. Psgl — це інтерактивний термінальний монітор, що дає користувачу змогу формулювати, редагувати й виконувати набори команд-операторів мови POSTQUEL. Інтерфейс командного рядка Psgl зазвичай використовують адміністратори баз даних для створення, модифікації та вилучення відношень, уведення і надання прав новим користувачам і т. д. Він достатньо зручний для введення великих обсягів інформації в БД і виведення простих звітів. Цей монітор не дає змоги генерувати складні форми звітів, оскільки за його допомогою неможливо розібрати отриманий результат для формування нових запитів. Тому його використання в прикладних програмах досить обмежене. LIBPQ — прикладний програмний інтерфейс СУБД POSTGRES 95. Він представлений набором бібліотечних підпрограм (функцій), які дають змогу клієнтським програмам надсилати запити серверу СУБД і отримувати від нього відповідні результати. Для цього в прикладну програму вносять головний файл бібліотеки LIBPQ-FE.H, убудовують функції LIBPQ і виконують компіляцію коду програми з бібліотеки POSTGRES 95. Для здійснення доступу до баз даних POSTGRES 95 з Internet можна використати такі механізми: CGI, Fast CGI, API, Java . Наприклад, АРІ — модуль сервера Apache PHP — підтримує взаємодію з бібліотеками POSTGRES 95, а також два розроблені ODBC-драйвери, Post ODBC i Open Link ODBC, які спрощують розроблення програм-шлюзів. Крім того, достатньо зручним і простим засобом побудови інтерактивних додатків є CGI (Common Gateway Interface), який не потребує ніякого додаткового програмного забезпечення і досить легкий у застосуванні. 0 1 1 0 Для зберігання і захисту цілісності даних у КІС часто використовуються брандмауери. Брандмауер — це програмна система або комбінація систем, організаційно оформлена на окремому або кількох комп’ютерах, яка дає змогу розділити мережу на дві та більше частин і реалізувати набір правил, що визначають умови проходження пакетів з однієї частини в іншу. Як правило, така межа проводиться між локальною мережею підприємства і Internet, хоча її можна провести і в середині локальної мережі підприємства. Тож брандмауер пропускає через себе весь потік інформації. Для кожного пакета, що проходить, брандмауер приймає рішення, пропускати його чи відкинути. Для того щоб брандмауер міг приймати ці рішення, йому необхідно надати відповідний набір правил. Для підвищення захисту самого брандмауера в операційну сис-тему, під управлінням якої працює брандмауер, вносять відповідні зміни. Ці зміни зачіпають як ядро ОС, так і відповідні файли конфігурації; деякі брандмауери працюють лише в однокористувацькому режимі. Багато з них мають систему перевірки цілісності програмних кодів. При цьому контрольні суми програмних кодів зберігаються в захищеному місці та порівнюються під час старту програми, щоб запобігти підміні програмного забезпечення. Усі брандмауери поділяють на три основні типи: 1. Пакетні фільтри (packet filter). 2. Сервери прикладного рівня (application gateways). 9. Сервери на рівні з’єднання (circuit gateways). Усі ці типи можуть бути реалізовані в одному брандмауері. Пакетні фільтри. Брандмауери з пакетними фільтрами приймають рішення про те, пропускати пакет чи відкинути його, переглядаючи ІР-адреси, прапори або номери ТСР-портів у заголовку цього пакета. Як відомо, ІР-адреса і номер порту — це інформація мережевого і транспортного рівнів відповідно, але пакетні фільтри використовують і інформацію прикладного рівня, бо всі стандартні сервіси TCP/IP з’єднуються з відповідним номером порту. Позитивними якостями пакетних фільтрі є: відносно невелика вартість, гнучкість у визначенні правил фільтрації, а також незначна затримка під час проходження пакетів. Вади брандмауерів з пакетними фільтрами такі: локальна мережа маршрутизується (є видима) з Internet ; у разі порушення працездатності брандмауера всі комп’ютери за ним стають повністю незахищеними або недоступними; правила фільтрації пакетів складні для опису, вимагається досконале знання технології TCP i UDP; аутентифікацію з використанням ІР-адреси можна обманути за допомогою застосування ІР-спуфінга (коли атакуюча система видає себе за іншу, використовуючи її ІР-адресу); відсутність аутентифікації на користувацькому рівні. Сервери прикладного рівня. Брандмауери із серверами прикладного рівня використовують сервери конкретних сервісів (TELNET, FTP, Proxy Server і т.д.), що запускаються на брандмауері та пропускають через себе весь потік інформації, що належить до даного сервісу. Отже, між клієнтом і сервером виникають два з’єднання — від клієнта до брандмауера і від брандмауера до місця призначення. Використання серверів прикладного рівня має низку переваг. По-перше, це дає змогу сховати від зовнішніх користувачів структуру локальної мережі, включаючи інформацію в заголовках поштових пакетів або служби доменних імен (DNS). По-друге, є можливість проведення аутентифікації (підтвердження ідентичності користувача) на користувацькому рівні. Для опису правил доступу використовуються такі параметри як назва сервісу, ім’я користувача, допустимий часовий діапазон використання сервісу, комп’ютери, з яких можна користуватися сервісом, схеми аутентифікації. Сервери протоколів прикладного рівня дають змогу забезпечити найвищий рівень захисту, оскільки взаємодія з зовнішнім світом реалізується через невелику кількість прикладних програм, що цілковито контролюють весь вхідний і вихідний потік інформації. Переваги серверів прикладного рівня такі: локальна мережа невидима з Internet; у разі порушення роботи брандмауера пакети перестають проходити через нього, тому не виникає загрози для захищаємих ним машин, які він захищає; захист на рівні прикладних систем дає змогу здійснювати більшу кількість додаткових перевірок, знижуючи в такий спосіб імовірність злому з використанням дірок у програмному забезпеченні; за допомогою аутентифікації на користувацькому рівні може бути задіяна система негайного попередження про спробу злому. Вадами цього типу є: вища вартість системи та нижча продуктивність порівняно з пакетними фільтрами, неможливість використання протоколів RPC i UDP. |