
- •Лекція№ Тема: Спеціальні аспекти роботи з базами даних.
- •1. Безпека і цілісність баз даних
- •2. Контроль цілісності даних з використанням тригерів
- •Лекція№ Тема: Функції захисту бази даних
- •1.Транзакції і паралелізм
- •2.. Засоби обробки транзакцій
- •3. Методи блокування
- •Лекція№
- •Представлення
- •2. Створення, видалення і оновлення уявлень
- •Лекція№ Тема: Методи захисту інформації
- •1. Безпека баз даних і привілею
- •2. Види привілей.
- •3.Створення, видалення і оновлення привілей
- •4. Системні привілеї
- •Лекція№ Тема: Використовування системного каталога
- •1.Використовування системного каталогу
4. Системні привілеї
Не варто забувати, що в системі завжди є деякі типи користувачів, які автоматично мають більшість або навіть всі привілеї, а також мають можливість передати свій статус кому-небудь за допомогою привілею або групи привілеїв. Зокрема, таким користувачем є адміністратор БД.
В самому загальному випадку є три базового привілею системи:
•
• CONNECT - складається з права реєструватися і права створювати представлення і синоніми, якщо користувачу передані відповідні привілеї об'єкту;
• RESOURCE - складається з права створювати базові таблиці;
• DBA - це привілей користувача, що дає найвищі повноваження в БД
Деякі системи, крім того, мають спеціального користувача, іноді званого SYSADM. SYS або SA, який має щонайвищі повноваження. Фактично це - спеціальне ім'я. а не просто користувач з особливим DBA привілеєм. Бажано, щоб тільки одна людина мала право реєструватися з ім'ям SA.
Команда GRANT є придатною для використовування як з привілеями об'єкту, так і з системними привілеями. Наприклад, адміністратор БД може передати привілей для створення таблиці користувачу SHER таким чином:
GRANT RESOURCE TO SHER;
Спочатку користувач SHER, в більшості випадків, створюється адміністратором БД, автоматично надаючи емупривілегію CONNECT. В цьому випадку звичайно додається пропозиція IDENTIFIED BY. вказуюче пароль. Наприклад, для первинної реєстрації користувача адміністратор бази даних вводить наступне:
GRANT CONNECT TO SHER IDENTIFIED BY Roman
Це приведе до створення користувача з ім'ям SHER, дасть йому право реєструватися і призначить йому пароль Roman 18. Після цього SHER і адміністратор БД мають можливість при необхідності змінити пароль.
Якщо новий користувач буде створювати базові таблиці, для нього потрібно буде також надати привілей RESOURCE. Дана дія породжує іншу проблему - якщо буде зроблена спроба видалити привілей CONNECT цього користувача, і в БД є таблиці, які їм створені, команда відхилюватиме, тому що ця дія залишить таблицю без власника, що не припускає. Отже, перед видаленням користувача спочатку необхідно видалити всі створені їм таблиці.
Таким чином, привілеї дають можливість SQL виконувати дії тільки через певних користувачів в спеціальній системі БД відповідно до встановлених для них дозволів і обмежень.
Лекція№ Тема: Використовування системного каталога
ПЛАН
Використовування системного каталогу
Складові системного каталогу
Створення доступу до каталогу
1.Використовування системного каталогу
Щоб правильно функціонувати, СУБД повинна стежити за багатьма різними об'єктами і елементами БД: таблицями, представленнями, індексами, синонімами, привілеями, користувачами і т. д Є різні способи реалізації цього, проте гущавині всього це відбувається шляхом збереження службової інформації в спеціальних таблицях. Це дає можливість СУБД розміщувати і управляти інформацією, в якій він має потребу, використовуючи ті ж самі процедури, що і для управління даними наочної області. Набір SQL таблиць, що бережуть службову інформацію для своїх внутрішніх потреб, називають системним каталогом, словником даних або системними таблицями.
Таблиці системного каталогу, по суті, нагадують звичайні SQL таблиці, що містять поля і записи даних. Таблиці каталогу створюються і модифікуються за допомогою самій БД, і ідентифікуються за допомогою спеціальних імен, наприклад SYSTEM. БД створює ці таблиці і модифікує їх автоматично, причому користувачами таблиці каталогу не можуть бути безпосередньо піддані дії команди модифікації - якщо це відбудеться, то система може заплутатися і стати непрацездатною. Проте в більшості систем, системний каталог може запитати користувачем, що дає можливість дізнатися про БД додаткову інформацію. Звичайно, ця інформація не доступна всім користувачам - подібно іншим таблицям, доступ до системного каталогу обмежений для користувачів без відповідних привілеїв.
Оскільки каталог належить самою системі, то традиційне привілею системного каталогу надає адміністратор БД. Крім того, деякі привілеї можуть надаватися користувачам автоматично.
Типовий системний каталог складається з наступних таблиць:
• SYSTEMCATALOG - тут зберігається інформація про базові таблиці і представлення; SYSTEMCOLUMNS - дані про поля таблиць; SYSTEMTABLES - дані про системні таблиці системного каталога;
SYSTEMINDEXES - інформація про індекси в таблиці; SYSTEMUSERAUTH - дані про користувачів БД; SYSTEMTABAUTH - дані про об'єктні привілеї користувачів;
• SYSTEMCOLAUTH - дані про привілеї користувачів в полях таблиць:
• SYSTEMSYNONS - синоніми для таблиць.
Адміністратор БД може надати користувачу право переглядати SYSTEMCATALOG наступною командою,
GRANT SELECT ON SYSTEMCATALOG TO SHER;
Після цього SHER зможе побачити деяку інформацію про всі таблиці в БД. Наприклад, інформація про таблиці БД зберігається у вигляді окремого запису. Як правило, її структура така, що присутні поля для імені таблиці, імені користувача-власника, кількість полів в таблиці і ознаки того, чи є вона представленням або базовою таблицею.
Оскільки SYSTEMCATALOG - це таблиця, її можна використати в уявленні. Припустимо, що тільки таблиці каталога є власністю користувача SA. Тоді спробуємо дозволити користувачам бачити тільки їхні власні об'єкти. Для цього спочатку необхідно створити наступне представлення:
CREATE VIEW OWNDB
AS SELECT *
FROM SYSTEMCATALOG
WHERE OWNER = USER;
Тут будемо виходити з того, що поле OWNER містить ідентифікатор доступу USER користувача. Після цього адміністратор БД може надати всім користувачам доступ до цього представлення:
GRANT SELECT ON OWDB TO PUBLIC;
Після цієї команди кожний користувач, здатний вибирати дані тільки про ті об'єкти з SYSTEMCATALOG, власником яких він сам є. Аналогічним чином можна надати можливість користувачам переглядати таблицю SYSTEMCOLUMNS для стовпців з його власних таблиць, традиційна її структура містить найменування поля таблиці в БД і ім'я власника. Таким чином, це реалізується шляхом виконання наступних команд:
CREATE VIEW OWNCOL
AS SELECT *
FROM SYSTEMCOLUMNS
WHERE OWNER = USER;
і
GRANT SELECT ON OWNCOL TO PUBLIC;
Майте на увазі, що в різних СУБД кількість даних і назви полів в таблицях системного каталогу можуть відрізнятися, проте основна ідея при цьому зберігається.
Більшість версій SQL дозволяють поміщати коментарі в спеціальні стовпці поясненні таблиць каталогів SYSTEMCATALOG і SYSTEMCOLUMNS. що зручне. Ці таблиці не завжди можуть пояснити свій зміст. Для цього можна використати команду COMMENT ON з рядком тексту коментаря, наприклад:
COMMENT ON TABLE SHER. TEACHERS IS 'Це список викладачів;
Цей текст буде поміщений в стовпець пояснень SYSTEMCATALOG. Сам коментар поміщається в службову таблицю, в даному випадку, містить інформацію про таблицю TEACHERS, власником якої є SHER.
Приведемо типову структуру таблиці SYSTEMTNDEXES, що містить дані про індекси в БД.
• iname - ім'я індексу:
• іowner - ім'я користувача, який створив індекс;
• tname - ім'я таблиці, які містить індекс:
• en umber - номер стовпця в таблиці, по якому створений індекс;
• tabowner - користувач, який володіє таблицею, що містить індекс;
• numcolumns - кількість стовців в індексі;
• cposition - позиція поточного стовпця серед набору індексів:
• isunique - чи є індекс унікальним.
За допомогою даних з цієї таблиці можна визначити, наприклад, інформацію про індекс з ім'ям SNUMIDX:
SELECT INAME, IOWNER, TNAME, CNUMBER, ISUNIQUE
FROM SYSTEMINDEXES
WHERE INAME = 'SNUMIDX';
Типова структура системної таблиці SYSTEMUSERAUTH, що містить інформацію про користувачів, така:
• username - ідентифікатор доступу користувача;
• password - пароль користувача, що вводиться при реєстрації;
• resource - об'єкти, де користувач має права RESOURCE;
• dba - об'єкти, де користувач має права адміністратора БД.
Так як всі користувачі одержують привілей CONNECT за умовчанням при реєстрації, то він не описаний в таблиці вище. Даними цієї таблиці можна скористатися, наприклад, для знаходження всіх користувачів, які мають привілей RESOURCE:
SELECT USERNAME
FROM SYSTEMUSERAUTH
WHERE RESOURCE;
Таблиця SYSTEMTABAUTH містить привілеї об'єкту, за винятком привілеїв стовпців. Традиційна структура цієї таблиці наступна:
username - користувач, який має привілеї;
grantor - користувач, який передав привілеї;
tname - ім'я таблиці, в якій існують привілеї;
owner - ім'я власника таблиці tname;
selauth - чи має користувач привілей SELECT;
insauth - чи має користувач привілей INSERT;
delauth - чи має користувач привілей DELETE.
Можливі значення для кожного з перерахованих привілеїв об'єкту (три останніх поля) - В, N. і G, причому G указує на те, що користувач має привілей з можливістю її передачі.
Перші чотири стовпці цієї таблиці складає первинний ключ. Оскільки UPDATE і REFERENCES є привілеями, які можуть бути певними стовпцями, відомості про них знаходяться в інших таблицях каталога. Крім того, якщо користувач одержує привілеї в таблиці більш ніж від одного користувача, то вони виділяються окремими рядками в цій таблиці, що необхідно для каскадного відстежування при виклику привілеїв. В якості прикладу приведемо запит, визначальний, які привілеї були передані SA користувачам таблиці STUDENTS:
SELECT USERNAME, SELAUTH, INSAUTH, DELAUTH
FROM SYSTEMTABAUTH
WHERE GRANTOR = 'SA' AND TNAME = 'STUDENTS';
SYSTEMCOLAUTH містить дані про привілеї користувачів в полях таблиць. Типова структура таблиці наступна: user name - користувач, який має привілеї; grantor - користувач, який надав привілеї; tname - ім'я таблиці, в якій існують привілеї; cname - ім'я поля, в якому існують привілеї; owner - власник tname;
updauth - чи має користувач привілей UPDATE в цьому стовпці;
• refauth - чи має користувач привілей REFERENCES в цьому стовпці.
Два останніх поля можуть бути в змозі В, N або G, а окремий рядок тут може існувати для кожного поля будь-якої таблиці. Як і у випадку з SYSTEMTABAUTH, той же привілей може бути описана в більш ніж одному рядку цієї таблиці, якщо вона була передана більш ніж одним користувачем. Для прикладу приведемо запит на визначення стовпців, в яких користувач має привілей REFERENCES:
SELECT OWNER, TNAME, CNAME
FROM. SYSTEMCOLAUTH
WHERE REFAUTH IN ('Y', 'G') AND USERNAME = USER;
Системна таблиця SYSTEMSYNONS містить інформацію про синоніми для таблиць в БД. Типова структура така:
• synonym - ім'я синоніма;
• synowner - користувач, який є власником синоніма;
• tname - ім'я таблиці, використовуваної власником;
• tabowner - ім'я користувача, який є власником таблиці.
. Для висновку, наприклад, всіх синонімів таблиці STUDENTS можна скористатися запитом:
SELECT *
FROM SYSTEMSYNONS
WHERE TNAME = 'STUDENTS'
Як і для звичайних таблиць, в системному каталозі припускає використати складні варіанти запитів. Т.к. принципове їхнє використовування нічим не відрізняється від запитів до звичайних таблиць, розглянемо всього один приклад. За допомогою приведеного запиту можна відобразити поля таблиць і базові індекси, встановлені для них:
SELECT FIRST. TNAME., FIRST. CNAME
INAME, CPOSITION
FROM SYSTEMCOLUMNS FIRST, SYSTEMINDEXES SECOND
WHERE FIRST.TABOWNER = SECOND. TABOWNER AND FIRST.TNAME = ECOND.TNAME AND FIRST.CNUMBER = SECOND.CNUMBER
ORDER BY 3 DESC, 2;
Таким чином, система SQL використовує набір таблиць, званий системним каталогом в структурі БД. Дані цих таблиць можуть запрошуватися користувачем, але не модифікуватися, це може внести безладдя в роботу СУБД.
-