4. Представлення

Механізм уявлень (view) є могутнім засобом СУБД, що дозволяє приховати реальну структуру БД від деяких користувачів за рахунок визначення представлення БД. Реально уявлення є деяким береженим в БД запитом, а для користувача нічим не відрізняється від базового відношення БД. Будь-яка реалізація уявлення повинна гарантувати, що полягання відношення, що представляється, точно відповідає поляганню даних, на яких визначено це уявлення. Звичайно обчислення уявлення проводиться кожного разу при його використовуванні. Розглянемо ці аспекти докладніше

Розглянемо приклад створення уявлення на основі відношення SP (Оцінки), приведеного на мал. 1. 11

СТВОРИТИ УЯВЛЕННЯ VIEW1

ДЛЯ (SP.OCENKA >= 3) [NAME, SN, OCENKA]

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

У прикладі створюється уявлення VIEW1. яке складається з трьох атрибутів - NAME, SN і OCENKA, причому вибиратимуться тільки ті кортежі, для яких оцінка буде більше або рівно 3, - грубо кажучи, інформація по успішних студентах. З таким уявленням користувач може працювати, як з реально існуючим.

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

Очевидно, що із збільшенням кількості даних, бережених в БД, виникає необхідність в розширенні за рахунок додавання нового атрибуту або відношення - це ми і називатимемо зростанням БД.

Реструктуризація даних має на увазі, що інформація залишається та ж, але змінюється її розташування, наприклад, за рахунок перегруповування атрибутів відносин. Припустимо, що відношення SP через які-небудь причини необхідно розділити на два - SPO і SPP, що приведене на мал. 1.23.

SPP
SN	PN	NAME

Мал. 1.23. Структура відносин SPO і SPP

Зрозуміло, що з'єднання одержаних відносин відтворить відношення SP. Отже, для подальшої роботи можна створити уявлення SP, а значить, у користувача складеться враження, що ніякій реструктуризації просто не проводилося.

СТВОРИТИ УЯВЛЕННЯ SP SPP З'ЄДНАТИ З SPO

Будь-яка призначена для користувача програма після цього замість відношення SP використовуватиме створене уявлення для маніпуляції з даними.

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

Нарешті, використовуючи механізм уявлень можна приховати службові дані, які не цікаві користувачу. Так, номер студентського квитка, як правило, інтересу для користувача не представляє, проте він служить для забезпечення зв'язку відносин в БД. Можна створити уявлення, де замість номерів студентських квитків будуть підставлені прізвища студентів з іншого відношення. Очевидно, таке уявлення більш зручне у використовуванні

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

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

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

Отже, представлення - це фактично той же запит, який виконується всякий раз. коли представлення бере участь в якій-небудь команді. Висновок цього запиту при цьому в кожний момент часу стає змістом представлення.

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

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