Главная страница
Навигация по странице:

  • 13.1.3. Виконання транзакцій

  • 13.2. Обробка транзакцій

  • 13.2.3. Монітори транзакцій

  • 13.3. Оптимізація баз даних

  • Рис. 13.4.

  • Методи оптимізації баз даних

  • 13.4. Організація безпеки баз даних

  • Методи забезпечення безпеки баз даних Фізичні Апаратні Програмні Організаційні 42113.5. Захист баз даних від несанкціонованого доступу

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


    Скачать 31.1 Mb.
    НазваниеІ бази даних
    АнкорЗацерковний В.І. та ін. ГІС та бази даних.pdf
    Дата06.02.2018
    Размер31.1 Mb.
    Формат файлаpdf
    Имя файлаЗацерковний В.І. та ін. ГІС та бази даних.pdf
    ТипКнига
    #15245
    страница41 из 49
    1   ...   37   38   39   40   41   42   43   44   ...   49
    13.1.2. Рівні ізоляції
    Прийнято виділяти чотири рівні виконання транзакцій: рівень серіалізації транзакцій (SERIALIZIBLE), рівень достовірного читання
    (REPEATABLE
    READ), рівень підтвердженого читання
    (READ
    COMMITTED), рівень непідтвердженого читання (READ UNCOMMITTED).
    Найвищий рівень виконання транзакцій спрямований на збереження цілісності даних і розв’язок проблем, пов’язаних з появою проміжних да- них, неузгоджених даних і рядків-примар, а найнижчий рівень націлений лише на підвищення швидкості виконання запитів.
    Проміжні дані з’являються тоді, коли незавершена транзакція мо- дифікує кортеж відношення, а інша транзакція зчитує цей кортеж. Якщо перша транзакція буде відмінена, то виявиться, що друга транзакція отримала дані, які ніколи не існували. Така ситуація з’являється на рівні непідтвердженого читання.
    На рівні підтвердженого читання транзакції можуть читати тільки підтверджені дані. Однак це не вирішує проблему неузгоджених даних.

    414
    Наприклад, у ході транзакції виконується запит, який визначає се- реднє значення за певним числовим атрибутом відношення. По завер- шенні цього запиту інша транзакція, що працює з тим же відношенням, видаляє або додає кортежі. Якщо перша транзакція буде повторно виконувати свій запит, то вона отримає інші результати.
    Проблема неузгоджених даних розв’язується на рівні достовірного читання. В цьому режимі кортежі, до яких транзакція звертається для читання або запису, блокуються. В даному разі виникає проблема, пов’язана з появою кортежів-примар.
    Транзакція може заблокувати всі кортежі, з якими ведеться робота, проте вона не може завадити іншій транзакції додати кортеж в той же час відношення. Якщо в ході транзакції вводяться два запити на вибірку, а між ними друга транзакція додає в відношення новий кортеж, то цей кортеж стане "примарою", оскільки вона з’являється в ході однієї і тієї ж транзакції.
    На рівні серіалізації транзакції примусово виконуються одна за одною в порядку пріоритету. Якщо дві транзакції будуть прагнути оновити один і той же кортеж, то одна з транзакцій буде оголошена такою, що програла в тупиковій ситуації і відмінена.
    На будь-якому рівні нижче рівня серіалізації з’являється ризик порушення цілісності даних. Однак, якщо в рамках поставлених завдань потрібно збільшити швидкість виконання запитів, то цілісність даних відходить на другий план і можна застосовувати один з трьох інших рівнів виконання транзакцій.
    13.1.3. Виконання транзакцій
    Багато СКБД за замовчуванням працюють у режимі автоматичного завершення транзакцій. В цьому разі кожен запит є самостійною транзакцією, яка після отримання результатів запиту негайно завершується.
    Однак для забезпечення одночасного доступу до даних використову- ються механізми блокування БД. СКБД може блокувати, в разі потреби, відносини цілком, кортежі, атрибути або сторінки, які є довільним блоком даних, пов’язаних з відношенням.
    Також для виконання транзакцій у деяких СКБД використовується механізм складання послідовності виконання транзакцій, що являє собою лічильник для створення унікальних числових ідентифікаторів. У цьому разі в БД жодні потоки виконання транзакцій не отримають однакові
    ідентифікатори, отже, не завадять роботі один одного.
    Проектувальники БД можуть створювати послідовності і самі за допомогою первинних ключів з автоматичним збільшенням значення при додаванні кортежу.

    415
    13.2. Обробка транзакцій
    Відслідковувати рівень виконання транзакції розробнику необхідно при проектуванні спеціалізованої БД, у більшості ж інших випадків доцільно використовувати вже готові і пророблені системи обробки тран- закцій, наприклад, OLTP-системи, OLAP-системи або монітори транзакцій.
    13.2.1. OLTP-системи
    У разі використання в БД сильно нормалізованих моделей даних прийнято застосовувати так звані OLTP-додатки (On-Line Transaction
    Processing – оперативна обробка транзакцій).
    Основною функцією таких систем є виконання більшої кількості коротких транзакцій, при цьому транзакції виглядають відносно просто, наприклад, операція читання або запису, і час очікування запитів не перевищує декілька секунд.
    Однак OLTP-системи мають низку недоліків. У таких системах транзакцій дуже багато, виконуються вони одночасно, і в разі помилки транзакція повинна повність відкотитись.
    Практично всі запити до БД в OLTP-додатках складаються з команд вставки, оновлення та видалення. Запити на вибірку головним чином призначені для надання користувачам можливості вибору даних з різних відношень. При цьому більша частина запитів відома заздалегідь ще на етапі проектування системи. Таким чином, критичними для OLTP- додатків є швидкість і надійність виконання коротких операцій онов- лення даних. OLTP-системи вимагають захисту від несанкціонованого доступу, порушення цілісності, апаратних і програмних збоїв.
    13.2.2. OLAP-системи
    В БД, що використовують принципи побудови систем підтримки прийняття рішень, сховищ даних, систем інтелектуального аналізу даних, застосовуються OLAP-додатки (On-Line Analitical Processing – опера- тивна аналітична обробка даних).
    Такі системи характеризуються такими ознаками. Додавання даних відбувається рідко і головним чином великими блоками. Дані, додані в систему, зазвичай ніколи не видаляються. В таких системах перед завантаженням дані проходять різні процедури обробки. Запити до бази даних є достатньо складними. При цьому швидкість виконання запитів є важливою, але не критичною.

    416
    Дані OLAP-додатків зазвичай представлені у вигляді одного або де- кількох гіперкубів і використовують багатомірні моделі даних. Оператив- ність обробки великих об’ємів даних в OLAP досягається за рахунок засто- сування потужної багатопроцесорної обчислювальної техніки, складних методів аналізу і спеціальних сховищ даних, що накопичують інформацію з різних джерел за великий період часу та забезпечують швидкий доступ до неї. В більшості випадків складний аналітичний запит неможливо сфор- мулювати в термінах стандартної мови запитів SQL, і доводиться засто- совувати спеціалізовані мови, орієнтовані на аналітичну обробку даних.
    13.2.3. Монітори транзакцій
    Зі зростанням складності розподілених обчислювальних систем ви- никають проблеми ефективного використання їх ресурсів. Для розв’язку цих проблем до складу розподілених OLTP-систем вводять додатковий компонент – монітор транзакцій.
    Монітори транзакцій виконують дві основні функції в СКБД: дина- мічний розподіл запитів у системі й оптимізацію кількості виконуваних серверних додатків. Перша функція спрямована на оптимальний розподіл обчислювальних ресурсів між декількома серверами при обробці великої кількості запитів, друга функція спрямована на розв’язок завдання запуску необхідної і достатньої кількості серверних додатків для обробки запитів із забезпеченням максимальної швидкості обробки транзакцій.
    Якщо в системі використовується монітор транзакцій, то з боку розробника не потрібно додаткових витрат для підтримки контролю цілісності даних, і він може зосередитись на розв’язку інших завдань.
    13.3. Оптимізація баз даних
    Оптимізація БД – це процес налаштування системи, спрямований на підвищення швидкості її роботи або скорочення об’єму використовуваної пам’яті. У більшості випадків успіх при оптимізації баз даних досягається тоді, коли накопичено достатній досвід проектування і супроводу таких систем. Врешті-решт оптимізація спрямована на економію грошових коштів, пов’язаних з експлуатацією і супроводом БД, отже, фінансові витрати на оптимізацію не повинні перевищувати економічної ефектив- ності від впровадження засобів оптимізації.
    Оптимізація починається з організаційних заходів, спрямованих на оновлення апаратної частини, оновлення операційної системи та онов- лення безпосередньо СКБД (рис. 13.3).

    417
    Рис. 13.3. Організаційні заходи при оптимізації бази даних
    Найбільший ефект приносить оновлення апаратної частини, при цьо- му саме цей організаційний захід може виявитися найдешевшим варіантом.
    Гордон Мур встановив, що обчислювальні потужності здвоюються кожні півтора роки. Незважаючи на таке стрімке зростання продуктив- ності, питома вартість обчислювальних засобів невпинно знижується, що й гарантує досягнення необхідного результату.
    Наступним етапом організаційних заходів, спрямованих на оптимі- зацію бази даних, є оновлення операційної системи. Залежно від цілей і завдань, які ставляться перед БД, можна використовувати або безплатні облегшені операційні системи, або комерційні операційні системи.
    Оновленню підлягає і сама СКБД. Постійно випускаються нові версії програмних продуктів такого типу, які розв’язують або нові завдання, або старі, на новому рівні. При цьому в нових версіях СКБД зазвичай виправ- лено похибки, які також можуть істотно впливати на ефективність роботи.
    Однак, оскільки не завжди вдається досягти потрібного ефекту за рахунок організаційних заходів, іноді доводиться застосовувати безпосе- редньо методи оптимізації БД. Класифікацію методів оптимізації баз даних наведено на рис. 13.4.
    Рис. 13.4. Методи оптимізації баз даних
    Організаційні заходи при оптимізації базиданих
    Оновлення апаратної частини
    Оновлення СКБД
    Оновлення операційної системи
    Методи оптимізації баз даних
    Т
    ес ти прод ук ти в
    нос ті
    О
    пт им
    із аці
    я
    О
    б сл уг ов ув ан ня в
    ід нош ень
    Н
    ал аш тув ання се рв ера
    П
    ере к
    ом пі
    л я
    ці
    я
    С
    К
    Б
    Д
    проекту додатків запитів
    інструкцій

    418
    Попереднім етапом оптимізації БД є оцінка продуктивності. Прак- тично всі розробники СКБД надають комплекс тестів продуктивності, що включають в себе перевірку декількох стандартних аспектів функціону- вання БД, наприклад, швидкості виконання запитів, операцій зчитування
    і запису, а також поради з усунення недоліків, виявлених у процесі тестування системи.
    Такі тести відбивають тільки відносну продуктивність сервера. За їх допомогою можна дізнатись, наскільки зросте швидкість його роботи при зміні рекомендованих налаштувань, вони лише непрямо допомагають в оптимізації БД.
    Оптимізація БД починається з оптимізації проекту. Основною ме- тою даного методу є визначення прийнятного рівня надлишковості даних
    і денормалізація деяких відношень.
    Для цього процесу характерним є створення підсумкових даних.
    Наприклад, можна додати до відношення атрибут, що зберігає результати обчислень по інших атрибутах, іноді застосовують технологію створення не тільки підсумкових атрибутів, а й цілих відношень, причому, якщо такі відношення зберігають часто змінювану інформацію, можна зробити
    їх резидентними.
    Також особливу увагу при оптимізації проекту приділяють визна- ченню типів даних. Наприклад, іноді доцільно не використовувати тип даних змінної довжини, що підтримується багатьма сучасними СКБД. Як правило, в них зберігаються відеофільми, звукозаписи, зображення. З точки зору оптимізації проекту більш ефективним є запам’ятовування лише шляху до таких файлів, при окремому збереженні їх від БД.
    Оптимізація додатків, що працюють з БД, головним чином полягає в використанні технології кешування. Для швидкого підключення до БД можна кешувати з’єднання з БД, можна кешувати дані з відношень, що ви- користовуються найбільш часто, або перед виконанням вставки кортежем у відношення, щоб потім здійснити виконання цієї операції в пакетному режимі.
    У разі використання мови запитів SQL оптимізувати запит доволі складно, хоча різноманітні підходи до реалізації одного й того ж завдання можуть заощадити процесорний час. При проектуванні запитів необхідно особливу увагу приділяти роботі з індексами, оскільки вони дозволяють
    істотно підвищити швидкість роботи додатка. Якщо подібний індекс ще не існував, то за потреби його слід створити, оскільки в багатьох проек- тах пріоритетним завданням є збільшення швидкості роботи додатка, а не економія дискового простору.
    Крім оптимізації запитів, можна застосовувати методи оптимізації
    інших інструкцій, наприклад, інструкцій вставки і видалення. Щоб уни- кнути витрат часу на аналіз інструкції, можна скористатися перевагами

    419
    значень за замовчуванням: замість того щоб вказувати значення всіх атри- бутів, можна задати лише ті, які відрізняються від стандартних установок.
    Для того щоб не дублювати синтаксис однотипних операцій, необхідно використовувати багаторядкові інструкції. Також можна скористатися командами, що дозволяють поміщати інструкції в чергу без блокування клієнтського додатка, що підвищує його оперативність.
    Періодично для прискорення виконання запитів необхідно здійсню- вати оптимізацію відношень. По-перше, можна видаляти порожні проміж- ки, що залишилися після видалення кортежів. По-друге, можна з’єднувати розподілені фрагменти відношень з динамічними кортежами. По-третє, можна сортувати відношення й індекси. У разі якщо відношення протягом часу практично не змінюється і дисковий простір обмежений, можна архівувати відношення, однак після цього воно буде доступним лише для зчитування.
    Розподіл ресурсів сервера, а головним чином оперативної пам’яті, також впливає на продуктивність баз даних. Збільшення об’єму пам’яті сприяє прискоренню роботи СКБД, оскільки в оперативній пам’яті вона зберігає представлення і часові відношення. Існує безліч зразків конфігу- раційних файлів з різними варіантами налаштувань, що стосуються вико- ристання пам’яті сервера, практично для всіх баз даних і операційних систем. Підбір найбільш придатних конфігурацій сервера в сукупності з тестуванням системи може принести позитивні результати при прове- денні оптимізації баз даних.
    Необхідність у компіляції при оптимізації баз даних виникає в тому разі, коли для використовуваної платформи неможливо знайти ском- пільовану версію СКБД або використовувані бібліотеки чи компілятори морально застаріли. Інструкцій з перекомпіляції на інформаційних ресурсах розробників БД доволі багато, однак цей метод оптимізації є крайнім і застосовується в тому разі, коли всі інші варіанти оптимізації не принесли прийнятного результату.
    13.4. Організація безпеки баз даних
    Для організації безпеки БД недостатньо організувати охорону при- міщень і встановити програмні засоби захисту. Потрібен комплексний підхід, який передбачає організацію захисту СКБД відповідно до її структури, завдань і можливостей захисту.
    Систему безпеки БД потрібно планувати з початку її розробки і виконувати на всіх етапах життєвого циклу.
    На практиці створення системи захисту часто починається в процесі експлуатації БД. Система безпеки повинна бути багаторівневою, адапто- ваною до нових умов функціонування.

    420
    Для ефективної побудови системи безпеки необхідно, по-перше, виді- лити уразливі елементи з СКБД, по-друге, виявити загрози для виділених елементів, по-третє, сформувати вимоги до системи безпеки і, нарешті, вибрати методи та засоби задоволення висунутим вимогам.
    Безпека СКБД може бути порушена внаслідок реалізації загроз, які являють собою можливість навмисної або випадкової дії, що може при- звести до порушення безпеки інформації, яка зберігається та оброблюється.
    Основними видами загроз у СКБД є несанкціоноване або неко- ректне використання ресурсів, поява похибок у програмних і апаратних засобах, викрадення носіїв інформації, виведення з ладу засобів збереження або передачі даних.
    Існуючі методи забезпечення безпеки БД можна розділити на чотири основні класи: фізичні, апаратні, програмні й організаційні (рис. 13.5).
    Рис. 13.5. Методи забезпечення безпеки баз даних
    Фізичний захист спрямований на обмеження доступу сторонніх осіб у приміщення, де розташований сервер з встановленою СКБД. Фізичні методи забезпечення безпеки включають засоби охоронної сигналізації, що засновані на різних принципах.
    Основними апаратними засобами забезпечення безпеки є засоби захисту процесорів, наприклад, перевірка припустимості команд, що видаються, пристроїв зовнішньої пам’яті, каналів зв’язку і систем електроживлення.
    До програмних методів забезпечення безпеки БД відносять засто- сування вбудованих засобів операційних систем і антивірусних програм, використання спеціалізованих комерційних додатків і утиліт.
    Організаційний захист передбачає сукупність дій, пов’язаних з розробкою і прийняттям законодавчих документів, що стосуються питань захисту інформації, а також з проведенням пропагандистських заходів щодо роботи з БД в межах правового поля.
    Однак найбільший інтерес становить синтез двох підходів, які реа- лізують програмно-апаратні методи забезпечення захисту інформації в
    БД. Програмно-апаратні засоби забезпечення безпеки допомагають як захистити СКБД від зовнішніх впливів, так і запобігти виникненню похи- бок у самих додатках, що працюють з БД.
    Методи забезпечення безпеки баз даних
    Фізичні
    Апаратні
    Програмні
    Організаційні

    421
    13.5. Захист баз даних від несанкціонованого доступу
    Для захисту від несанкціонованого доступу за допомогою програмно- апаратних засобів використовують технологію реєстрації спроб доступу в систему з боку користувачів і програм, а також гнучку політику швидких повідомлень про такі спроби.
    Захист від несанкціонованого доступу з боку користувачів у сучасних системах реалізується двома способами: парольним захистом і шляхом
    ідентифікації й автентифікації
    47
    Найпростіший парольний захист є доволі слабким засобом забезпе- чення безпеки БД, особливо якщо пароль не шифрується. Основний її не- долік полягає в тому, що всі користувачі, що використовують однаковий пароль, з точки зору СКБД, ідентичні. Незручність парольного захисту для користувача полягає в тому, що при використанні простого і короткого пароля з’являється загроза його підбору зловмисниками, а якщо пароль складний, то користувач повинен додатково його зберігати на іншому носієві і відповідно забезпечувати йому додатковий захист.
    Більш серйозний контроль доступу в систему відбувається, якщо кожного користувача, що підключається до БД, спочатку ідентифікувати, а потім автентифікувати – переконатися, що це саме він, і при запиті ресурсів контролювати його повноваження.
    Для автентифікації можна використовувати особисту інформацію користувача, електронні ключі, електронні жетони, магнітні картки, активні засоби розпізнавання або біометричні засоби. Найбільш перспективними є біометричні засоби захисту баз даних. До них відносяться контроль за відбитками пальців, зчитування сітчатки ока, розпізнавання голосу, визначення ДНК людини. Однак багато з цих методів проходять етапи доопрацювання та апробації.
    Одним із різновидів несанкціонованих програм є комп’ютерні віруси.
    Кількість комп’ютерних вірусів постійно зростає, отже, і потенційний збиток від їх роботи також пропорційно зростає. Тому проблема захисту БД від комп’ютерних вірусів на всіх стадіях їх розвитку є надзвичайно актуальною. Для цього в СКБД розробники включають засоби діагносту- вання стану програмно-апаратних засобів, локалізації і видалення вірусів, усунення наслідків їх дії.
    1   ...   37   38   39   40   41   42   43   44   ...   49


    написать администратору сайта