- •4. Нормалізація реляційної моделі даних
- •5, Мова sql.Загальна характеристика.
- •7. Використання агрегатних функцій
- •8. Вибір з кількох таблиць
- •9. Підзапити
- •10. Засоби маніпулювання даними
- •12. Представлення
- •1. Спосіб створення і вміст уявлень
- •2. Використання
- •3. Специфічні типи уявлень
- •13. Індекси
- •14. Транзакції
2. Використання
Подання використовуються в запитах до БД тим же чином, як і звичайні таблиці. У разі SQL-СУБД ім'я подання може знаходитися в SQL-запиті на місці імені таблиці (в реченні FROM). Запит з уявлення обробляється СУБД точно так само, як запит, в якому на місці імені подання знаходиться підзапит, що визначає це подання. При цьому СУБД з розвиненими можливостями оптимізації запитів перед виконанням запиту з уявлення можуть проводити спільну оптимізацію запиту верхнього рівня і запиту, визначає подання, з метою мінімізації витрат на вибірку даних.
Використання уявлень не дає якихось абсолютно нових можливостей у роботі з БД, але може бути дуже зручно.
Подання приховують від прикладної програми складність запитів і саму структуру таблиць БД. Коли прикладної програмі потрібно таблиця з певним набором даних, вона робить найпростіший запит з підготовленого подання. При цьому навіть якщо для отримання цих даних потрібно надзвичайно складний запит, сама програма цього запиту не містить.
Використання уявлень дозволяє відокремити прикладну схему подання даних від схеми зберігання. З точки зору прикладної програми структура даних відповідає тим уявленням, з яких програма ці дані витягує. Насправді дані можуть зберігатися зовсім іншим чином, достатньо лише створити уявлення, що відповідають потребам програми. Поділ дозволяє незалежно модифіковані прикладну програму і схему зберігання даних: як при зміні структури фізичних таблиць, так і при зміні програми досить змінити уявлення відповідним чином. Зміна програми не зачіпає фізичні таблиці, а зміна фізичної структури таблиць не вимагає коректування програми.
За допомогою уявлень забезпечується ще один рівень захисту даних. Користувачеві можуть надаватися права тільки на виставу, завдяки чому він не буде мати доступу до даних, що знаходяться в тих же таблицях, але не призначених для нього.
Оскільки SQL-запит, що вибирає дані уявлення, зафіксований на момент його створення, СУБД отримує можливість застосувати до цього запиту оптимізацію або попередню компіляцію, що позитивно позначається на швидкості обігу до подання, в порівнянні з прямим виконанням того ж запиту з прикладної програми.
3. Специфічні типи уявлень
Деякі СУБД мають розширені уявлення для даних, доступних тільки для читання. Так, СУБД Oracle реалізує концепцію " матеріалізованих уявлень "- уявлень, що містять заздалегідь обрані невіртуальний набори даних, спільно використовуваних в розподілених БД. Ці дані беруться з різних віддалених джерел (з різних серверів розподіленої СУБД). Цілісність даних у матеріалізованих уявленнях підтримується за рахунок періодичних синхронізацій або з використанням тригерів. Аналогічний механізм передбачено в Microsoft SQL Server версії 2000.
По самій суті подання можуть бути доступні тільки для читання. Тим не менш, в деяких СУБД (наприклад, в Oracle) подання можуть бути редагованими, як і звичайні фізичні таблиці. Редагування може допускатися для вистав, вибраних з єдиною фізичної таблиці таким чином, щоб кожного запису в поданні відповідала строго один запис у таблиці-джерелі, а в числі полів вистави був первинний ключ фізичної таблиці. При виконанні команд редагування, додавання або видалення для такого подання сервер СУБД перетворює ці команди у відповідні команди для фізичної таблиці-джерела. Зрозуміло, якщо у поданні використовується угруповання записів або перетворення значень в полях, редагування такого подання неможливо навіть теоретично. Але і такі подання можуть, тим не менш, редагуватися, за допомогою написання відповідних тригерів (хоча осмисленість подібних операцій цілком залишиться на совісті програміста). Втім, редаговані уявлення, як і можливість створення тригерів для вистав, підтримують лише деякі СУБД.