2. Використання

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

Використання уявлень не дає якихось абсолютно нових можливостей у роботі з БД, але може бути дуже зручно.

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

• Використання уявлень дозволяє відокремити прикладну схему подання даних від схеми зберігання. З точки зору прикладної програми структура даних відповідає тим уявленням, з яких програма ці дані витягує. Насправді дані можуть зберігатися зовсім іншим чином, достатньо лише створити уявлення, що відповідають потребам програми. Поділ дозволяє незалежно модифіковані прикладну програму і схему зберігання даних: як при зміні структури фізичних таблиць, так і при зміні програми досить змінити уявлення відповідним чином. Зміна програми не зачіпає фізичні таблиці, а зміна фізичної структури таблиць не вимагає коректування програми.

• За допомогою уявлень забезпечується ще один рівень захисту даних. Користувачеві можуть надаватися права тільки на виставу, завдяки чому він не буде мати доступу до даних, що знаходяться в тих же таблицях, але не призначених для нього.

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

3. Специфічні типи уявлень

Деякі СУБД мають розширені уявлення для даних, доступних тільки для читання. Так, СУБД Oracle реалізує концепцію " матеріалізованих уявлень "- уявлень, що містять заздалегідь обрані невіртуальний набори даних, спільно використовуваних в розподілених БД. Ці дані беруться з різних віддалених джерел (з різних серверів розподіленої СУБД). Цілісність даних у матеріалізованих уявленнях підтримується за рахунок періодичних синхронізацій або з використанням тригерів. Аналогічний механізм передбачено в Microsoft SQL Server версії 2000.

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