7.3. Управління доступом до даних в розрахованій на багато користувачі субд.

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

В розрахованих на багато користувачі СУБД говорять про проблему конкуренції — спробах багатьох користувачів одночасно виконувати операції з одними і тими ж даними. Фактично, задача забезпечення паралельного доступу до даних — одна з найважливіших і найочевидніших задач серверу бази даних. Сервер бази даних повинен управляти інформацією так, щоб при збереженні цілісності даних користувачі чекали виконання роботи іншими користувачами мінімальний час. Якщо сервер бази не може задовольнити одну з цієї мети, то користувачі відразу помітять наслідки. Коли багато транзакцій конкурують за одні і ті ж дані, то користувачі зіткнуться з поганою продуктивністю або отримають неточні результати.

Це проблеми, але ORACLE7 вирішує ці проблеми. Розглянемо як це він робить.

Запобігання руйнуючих взаємних впливів за допомогою блокувань даних.

Коли дві конкуруючі за одні і ті ж дані операції втручаються в роботу один одного, це може привести до неточних результатів або втрати цілісності даних. Це називається “ руйнуючий взаємний вплив”. Для запобігання таких ситуацій при одночасному доступі користувачів до даних застосовуються блокування. Аналогічно тому як “вертушка” в прохідній не дозволяє проходити через неї одночасно двом, блокування даних запобігає в розрахованій на багато користувачі СУБД руйнуючому впливу. Існують блокування, що виключають і розділяються.

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

Коли користувач намагається виконувати операції з даними, з якими працює хтось ще, ORACLE7 автоматично їх блокує і запобігає можливості руйнуючого впливу. Якщо це можливо (тобто не приведе до руйнуючого впливу), завжди використовує блокування, що розділяється. Проте, якщо таке блокування залишає можливість руйнуючого впливу, встановлюється блокування запрошуваних вашою транзакцією даних, що виключає. Блокування, що виключає, запобігає можливості блокувати ті ж дані за допомогою блокування будь-якого типу і за рахунок усунення паралельного доступу до одних і тих же даних забезпечує їх цілісність.

Отримання точних даних при високому ступені доступу: запити, злагоджене читання і підтримка версій.

Попередні приклади показують, як Огасlе7 для одного і того набору даних обробляє дві різні транзакції оновлення. А що відбувається у разі запитів, що містять тільки операції читання? Як Огaсlе7 обробляє конкуруючі запити і запити з операціями оновлення, повертаючи точні результати ?

В зтих ситуаціях Оraсlе7 використовує наступний підхід. По-перше, транзакція не вимагає блокування рядків для будь-якого типу запитів. Це означає, що дві транзакції можуть давати одночасно в точності один і той же запит без якої-небудь конкуренції за один набір рядків. Відсутність блокувань читання означає також, що такий запит не може блокувати оновлення і навпаки.

Як же Огасlе7 повертає точні результати, якщо він не встановлює блокування для запитів? Можна було б вважати, що без блокування рядка для запитів конкуруюче із запитом оновлення може дати для запиту неточний набір результатів.

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

Сегменти відкоту.

Використовуючи бережені в сегментах відкоту дані, Огасlе7 може створювати для запиту злагоджені по читанню копії (набори результатів) даних. Сегмент відкоту (або сегмент відміни транзакцій) — це область пам'яті на диску, яку Оraclе7 використовує для тимчасового зберігання старих значень даних, що обновляються транзакцією видалення або оновлення рядків. Якщо користувач відміняє транзакцію, то Оraclе7 прочитує привласнений транзакції сегмент відкоту і повертає змінені нею рядки в початковий стан. Крім того, Оrасlе7 використовує сегмент відкоту в механізмі виділення версій. Якщо запиту потрібні дані, які в процесі його виконання змінюються, то Оrасlе7 за допомогою даних сегменту відкоту генерує злагоджений по читанню копію даних (заданий момент часу). Все це відбувається автоматично.

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

Забезпечення захисту даних.

Невже хто завгодно може увійти до бази даних Оrасlе7 і почати використовувати дані, читати табличну інформацію і модифікувати її? Звичайно, ні! Якби це було так, то користувачі могли б бачити дані, які для них не призначаються (такі як заробітна платня їх начальника), а зловмисники могли б легко стерти або змінити дані на свій розсуд (наприклад, підвищити зарплату самим собі). Одним з обов'язків серверу бази даних є забезпечення захисту всієї інформації СУБД. Незалежно від того, хочте чи ні захистити свої дані від очей неуповноважених користувачів або зловмисників, захист є важливою функцією бази даних. Для забезпечення захисту Оrасlе7 використовує систему вибіркового управління доступом зто означає, що адміністратор привласнює пропуску для всіх зареєстрованих в базі даних користувачів і дає їм повноваження на виконання в базі даних конкретних операцій з конкретними даними. Різні методи управління захистом Оraclе7 описуються в наступних розділах.

Надання користувачам доступу до бази даних.

Доступ до бази даних Огасlе7 дуже нагадує доступ до телефонної банківської системи. По-перше, вам потрібно отримати загальний доступ до бази даних. Щоб надати кому-небудь доступ до бази даних Оraclе7, адміністратор повинен зареєструвати його і створити в базі даних нового користувача (визначивши його ім'я). Для забезпечення захисту доступу пароль повинен відповідати імені цього нового користувача. Для підключення до бази даних користувач повинен ввести і ім'я, і пароль. Нового користувача створює, наприклад, наступний оператор SQL:

CREATE USER safеdorow IDENTIFID p1e

Як показує цей приклад, адміністраторам слід вибирати осмислені імена користувачів (наприклад, об'єднавши ім'я і прізвище). Проте користувачі повинні вибирати складні і не несучі ніякого значення паролі. Це утруднятиме їх визначення зловмисниками.

Після отримання користувачем доступу до бази даних Оraclе7 операції його в цій СУБД обмежують інші засоби контролю доступу.

Розширення і обмеження повноважень.

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

Система захисту Оraclе7 дуже нагадує захист телефонної банківської системи. Адміністратор може управляти всіма операціями з базою даних і доступом до даних, у тому числі тим, які користувачі можуть створювати таблиці і уявлення, какие—создавать і модифікувати табличні області, а які — прочитувати і модифікувати різні таблиці і представлення бази даних. Це робиться шляхом надання і відміни різних повноважень або прав доступу. Наведемо приклади вживаних для цього команд SQL GRANT і REVOKE:

GRANT CREATE SESSION, CREATE TABLE TO safd

REVOKE CREATE TABLE FROM allin

Оператор GRANT дає користувачу SAFD повноваження на підключення до бази даних (тобто на ініціалізацію сеансу з базою даних) і створення таблиць. Оператор REVOKE відміняє повноваження користувача ALLIN на створення таблиць.

Огас1е7 має два широкі класи повноважень, про які розказується в наступних двох розділах: повноваження на об'єкти і системні повноваження.

Системні повноваження: управління розширеними системними операціями.

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

Користувач з системними повноваженнями ALTER DATABASE може змінювати фізичну структуру бази даних, додаючи до неї нові файли.

Користувач з системними повноваженнями DROP TABLESPACE може видаляти будь-яку табличну область (за винятком табличної області SYSTEM).

Користувач з системними повноваженнями SELECT ANY TABLE може опитувати будь-яку таблицю бази даних.

Це лише деякі з безлічі системних повноважень Oracle7. Оскільки системні повноваження — це дуже широкі повноваження, адміністраторам слід надавати їх тільки іншим адміністраторам.

Повноваження на об'єкти бази даних: управління доступом до даних.

Повноваження на об'єкти управляють роботою бази даних з конкретним її об'єктом. (Об'єкт — це щось, що знаходиться усередині бази даних: таблиця, уявлення, роль, процедура, користувач і т.д.). Наприклад, адміністратор може управляти тим, хто опитує таблицю CUSTOMER. Для цього він надає повноваження SELECT на цю таблицю тільки конкретним користувачам. Існують і інші повноваження на об'єкти, про які можна отримати інформацію в керівництві по застосуванню Оracle7.

Управління захистом за допомогою ролей.

Управління захистом у великій базі даних клієнт/сервер — складна задача. Безліч працюючих в системі повноважень і користувачів можуть вимагати позначень конкретних повноважень. За відсутності адміністративного інструментального засобу управління захистом може стати справжнім кошмаром. На щастя, Оracle7 пропонує рішення, полегшуюче управління повноваженнями у великій і складній системі клієнт/сервер, — це ролі. Роль є набором відповідних повноважень, які адміністратор може колективно надавати користувачам і іншим ролям. За допомогою ролей адміністратор може значно спростити управління повноваженнями.

Просте управління повноваженнями — ця не єдина перевага використовування ролей. Можливо, більш важливо те, що розробники можуть застосовувати ролі для динамічної зміни домена (поточного набору) повноважень користувачів при роботі їх з різними додатками. Шляхом простого дозволу відповідної ролі при запуску додаток може гарантувати, що всі його користувачі матимуть коректний домен повноважень.

Схеми в Oracle7.

При роботі з Oracle7 ви часто стикатиметеся з терміном “схема”. Це слово може мати самий різний сенс. Аналогічно тому як адміністратори можуть фізично організувати таблиці Oracle7 за допомогою табличних областей, логічно вони організовують таблиці і представлення реляційної бази даних за допомогою схем. Схема - це логічний набір споріднених таблиць і уявлень, а також всіх інших об'єктів бази даних. Наприклад, при додаванні до СУБД клієнт/сервер нового додатку адміністратору для організації таблиць і уявлень, які використовуватиме додаток, слід створити нову схему. На рис.4 показаний додаток для обліку продажів.

Oracle7 насправді схеми бази даних не реалізує. Просто адміністратор створює нового користувача бази даних, який у свою чергу ефективно породжує задану за умовчанням схему бази даних. При створенні користувачем бази даних нового уявлення або таблиці цей об'єкт за умовчанням стає частиною схеми. Фактично, з урахуванням схем бази даних ви можете сказати, що користувач володіє всіма об'єктами в своїй заданої за умовчанням схемі. Реляційні СУБД з більш просунутою реалізацією схеми дозволяють користувачам перемикатися між заданою за умовчанням схемою і іншими схемами бази даних і виконувати різні операції, відповідні поточній схемі. Можливо, в майбутніх версіях Oracle такі засоби будуть реалізовані.

Забезпечення доступності необхідних користувачам даних.

В будь-якій комп'ютерній програмі користувач не зможе отримати доступ до файлу, поки не запустить екземпляр відкриваючого цей файл додатку. Наприклад, щоб відкрити створений за допомогою текстового процесора звіт, користувачу спочатку потрібно запустити цей текстовий процесор, а потім відкрити в ньому файл звіту. Як пояснюється в наступних розділах, робота в СУБД Oracle7 в чомусь аналогічна.

Управління загальною доступністю бази даних при запуску і останові.

Як і при запуску розрахованої на багато користувачі Ос, в Oracle7 ніхто не може використовувати дані, поки адміністратор не запустить сервер і не зробить базу даних доступної. Це вимагає декількох кроків. По-перше, адміністратору потрібно запустити екземпляр бази даних. Экземпляр—это набір буферів пам'яті (тимчасових кеш-буферів даних в оперативній пам'яті комп'ютера) і процесів Ос (планованих ОС задач або завдань), спільно забезпечуючих множинний доступ до бази даних Oracle7 . В ході виконання фази запуску бази даних Oracle7 відкриває різні файли, необхідні для того, щоб зробити базу даних доступної.

Щоб база даних стала неприступною для звичайних користувачів, адміністратор її закриває, размонтирует, від'єднуючи від екземпляра, а потім зупиняє екземпляр. В процесі останову Oracle7 закриває складові базу даних файли Ос. Сервер бази даних Oracle7 виконує запуск екземпляра, щоб зробити систему доступної для використовування, і зупиняє його, щоб перевести її в автономний стан.

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

Файли параметрів і запуск екземпляра.

Кожного разу, коли адміністратор починає новий сеанс, Oracle7 для настройки конфігурації нового екземпляра прочитує файл параметрів ініціалізації. Наприклад, адміністратор може встановити різні параметри для управління розміром буферів пам'яті екземпляра.

Управління частковим доступом до бази даних за допомогою оперативно доступних і автономних табличних областей.

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

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

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

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

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