2. Причини можливого пошкодження
або втрати даних:
• Псування або зміна даних анонімним
користувачем;
• Завершення роботи програм при системному
збої, коли база даних залишається в
непередбачуваному стані;
• Виникнення конфлікту при виконанні двох і
більше програм, що конкурують за одні й ті ж
дані;
• Зміна бази даних неприпустимим способом
оновлення тощо.
3. 1. Управління доступом до даних
• Схема доступу до даних у реляційних СУБД
базується на наступних принципах:
1.Користувачі СУБД
2.Об’єкти доступу
3.Привілеї
5. Привілеї доступу та передача привілеїв
Привілей Рівень доступу
ALL Вибір, вставка, оновлення, знищення даних і посилання
зовнішнього ключа іншої таблиці на первинний ключ даної
таблиці
SELECT Читання даних
INSERT Запис нових даних
UPDATE Зміна існуючих даних
DELETE Видалення даних
EXECUTE Виконання чи виклик збереженої процедури
REFERENCES Посилання зовнішнього ключа іншої таблиці на первинний ключ
даної таблиці
имя_роли Надає всі привілеї, передані даній ролі
7. SQL ролі
Роль – це метод забезпечення безпеки на рівні груп привілеїв.
8. SQL ролі
Реалізація механізму використання ролі для передачі привілеїв
складається з наступних кроків:
1) створити роль, використовуючи наступний запит:
CREATE ROLE имя_роли;
2) передати цій ролі одну або більше привілеїв, використовуючи
наступний запит:
GRANT <привилегии> TO имя_роли;
3) передати право на використання цієї ролі одному або більше
користувачам за допомогою наступного запиту:
GRANT имя_роли TO <список_пользователей>;
При цьому роль може бути передана із зазначенням пропозиції WITH
ADMIN OPTION, яке означає, що користувачі, які мають дану роль,
можуть передавати право на використання цієї ролі іншим
користувачам;
4) при підключенні до БД користувач, що має будь-яку роль (ролі),
повинен вказати ім'я цієї ролі.
10. Скасування привілеїв
При скасуванні привілеїв запитом REVOKE необхідно враховувати наступні
обмеження і правила:
• Привілеї можуть бути видалені тільки тим користувачем, який їх надав;
• Привілеї, що присвоєні іншими користувачами, не торкаються;
• Видалення конкретної привілеї для користувача А, якому було дано право
передавати її, автоматично видаляє цей привілей для всіх користувачів,
кому вони були послідовно передані користувачем А;
• Привілеї, передані для загального користування (PUBLIC), можуть бути
відібрані тільки у PUBLIC, а не у конкретного користувача або об'єкта БД.
11. Скасування привілеїв
Таким чином, в результаті каскадного видалення прав:
• Користувач Slonov не має права передавати привілей SELECT;
• Користувач Ivanov взагалі позбавлений привілеї SELECT, а має
лише привілей DELETE (але з опцією WITH GRANT OPTION);
• У користувача Petrov немає ніяких привілеїв на доступ до таблиці
PaySumma. Це сталося, тому що у користувача Slonov відібрано
право передачі привілеї SELECT іншим користувачам, а значить, і
всі дії, які він виконав, маючи це право, також анульовані
(відібраний привілей SELECT у користувача Petrov, яку передав
йому Ivanov).
12. Привілеї на представлення
"no permission for SELECT
access to TABLE/VIEW
REQUEST"
"no permission for SELECT
access to TABLE/VIEW
REQUEST"
13. 2. Транзакції
• Транзакція - це група операцій обробки даних,
що виконуються як деяка неподільна дія над
базою даних, осмислена з погляду
користувача.
• Запис даних у БД проводиться тільки при
успішному виконанні всіх операцій групи.
• Якщо хоча б одна з операцій групи
завершується неуспішно, то БД повертається
до того стану, в якому вона була до виконання
першої операції групи.
14. 2. Властивості транзакції
Транзакції характеризуються чотирма класичними властивостями:
• Властивість атомарності виражається в тому, що транзакція
повинна бути виконана в цілому або не виконана зовсім. СУБД
гарантує неможливість фіксації деякої частини дій з транзакції в БД.
• Властивість узгодженості гарантує, що по мірі виконання
транзакцій дані переходять з одного узгодженого стану в інший,
тобто транзакція не руйнує взаємну узгодженість даних.
• Властивість ізольованості означає, що конкуруючі за доступ до
бази даних транзакції фізично обробляються послідовно, ізольовано
одна від одної, але для користувачів це виглядає так, як ніби вони
виконуються паралельно. Наприклад, для будь-яких двох транзакцій
Т1 і Т2 справедливо наступне твердження: Т1 зможе побачити
оновлення Т2 тільки після виконання Т2, а Т2 зможе побачити
оновлення Т1 тільки після виконання Т1.
• Властивість довговічності означає, що якщо транзакція завершена
успішно, то зміни в даних, що виконуються в ній, не можуть бути
втрачені ні за яких обставин (навіть у випадку подальших помилок
або збою системи).
