28.Представлення в базах даних.

ПРЕДСТАВЛЕННЯ

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

Синтаксис команди:

CREATE VIEW <ім'я вистави>

[(<ім'я стовпця> [,.n ])

[WITH {ENCRYPTION | SCHEMABINDING | VIEW_METADATA}]

AS

< команда SELECT>

[WITH CHECK OPTION];

WITH CHECK OPTION – обмежує дію команд INSERT і UPDATE. При завданні цієї пропозиції вони дозволені лише в тому випадку, якщо вони створюють рядки, які потім видно у представленні.

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

При створенні вистави SQL не здійснює контроль за типом змінних, тобто представлення буде створена без генерації повідомлення про помилку, але при спробі здійснити запит згенерує повідомлення про помилку.

Раніше наголошувалося, що опція WITH CHECK OPTION може обмежити дію команд INSERT і UPDATE, проте існують і інші обмеження на використанні команд DML.

Команда DELETE заборонена, якщо представлення містить:

умова з'єднання

групові функції або пропозиція GROUP BY

пропозиція DISTINCT

стовпець з властивістю IDENT I TY

Команда UPDATE заборонена завжди, коли заборонена команда DELETE, а також у разі, коли стовпці містять вирази.

Команда INSERT заборонена завжди, коли заборонена команда UPDATE, а також тоді, коли який-небудь стовпець таблиці NOT NULL не міститься у представлення.

Після успішного завершення команди CREATE VIEW видається повідомлення

View created (Представлення створена).

Представлення використовуються для:

обмеження доступу до бази даних;

спрощення запитів;

заховання схеми бази даних.

У першому випадку можна не лише обмежити перегляд тих або інших даних, але і склавши обмеження тим або іншим способом, зробити неможливим виконання тієї або іншої комбінації операцій над базами даних (видалення, додавання, редагування).

29.Привілеї в базах даних.

Привілеї – це права користувача на проведення тих чи інших дій над певним об'єктом бази даних.

Для введення елементів системи безпеки застосовується інструкція GRANT, за допомогою якої тим чи іншим користувачам надаються певні привілеї на використання тих чи інших об'єктів бази даних. В інструкції GRANT задається комбінація ідентифікатора користувача, об'єкта і привілеїв. Надані привілеї можна пізніше анулювати за допомогою інструкції REVOKE.

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

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

Пароль служить для підтвердження того, що користувач дійсно має право працювати під введеним ідентифікатором. Ідентифікатори і паролі застосовуються в більшості реляційних СУБД, однак спосіб, яким користувач вводить свій ідентифікатор та пароль, змінюється залежно від СУБД. Наприклад, коли СУБД Oracle працює з інтерактивним SQL-модулем, який називається SQLPLUS, необхідно ввести ім'я користувача і відповідний пароль у командному рядку: SQLPLUS ідентифікатор/пароль.

У багатьох інших СУБД, включаючи Informix, у ролі ідентифікаторів користувачів використовуються імена користувачів, що реєструються в операційній системі мейнфрейму.

У великих виробничих базах даних часто є групи користувачів зі схожими завданнями. У межах кожної групи всі користувачі працюють з однаковими даними і повинні мати ідентичні привілеї. Згідно стандарту ANSI/ISO, з групами користувачів можна вчинити одним з двох способів:

1. Кожному члену групи можна присвоїти один і той же код користувача.

2. Усім членам групи можна присвоїти різні ідентифікатори користувача.

Ті дії, які користувач має право виконувати над об'єктом бази даних, називаються привілеями користувача по відношенню до даного об'єкту. У стандарті SQL для таблиць визначені чотири привілеї:

1. Привілей SELECT дозволяє отримувати дані з таблиці.

2. Привілей INSERT дозволяє додавати нові записи в таблицю.

3. Привілей DELETE дозволяє видаляти записи з таблиці.

4. Привілей UPDATE дозволяє модифікувати записи у таблиці або псевдотаблиці.

Коли користувач створюєте таблицю за допомогою інструкції CREATE TABLE, він стаєте її власником і отримуєте всі привілеї для цієї таблиці (SELECT, INSERT, DELETE, UPDATE та інші привілеї, які є в СУБД). Інші користувачі спочатку не мають ніяких привілеїв на щойно створену таблицю. Щоб вони отримали доступ до таблиці, власник повинен явно надати їм відповідні привілеї за допомогою інструкції GRANT [5].

У багатьох комерційних СУБД крім привілеїв SELECT, INSERT, DELETE і UPDATE, встановлених стандартом SQL, по відношенню до таблиць можуть бути видані додаткові привілеї. Наприклад, в Oracle та Informix передбачені привілеї ALTER та INDEX. Маючи привілей ALTER для якої-небудь таблиці, користувач може за допомогою інструкції ALTER TABLE модифікувати структуру даної таблиці; маючи привілей INDEX, користувач може за допомогою інструкції CREATE INDEX створити індекс для таблиці

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

У SQL дана проблема може бути вирішена за допомогою VIEW – псевдотаблиці.