ОБД/Л 19/ Представлення даних в реляційній моделі. Способи формування представлень

Лекція 19 Представлення даних в реляційній моделі. Способи формування представлень

План

1. Механізм подання даних в реляційної моделі. 1

2. Створення подання даних. 2

3. Способи формування представлень даних. 3

3.1 Вертикальний зріз таблиці. 3

3.2. Горизонтальний зріз таблиці. 4

3.3. Вертикально-горизонтальний зріз таблиці. 5

3.4. Підмножина рядків і стовпців з'єднання різних таблиць. 5

1. Механізм подання даних в реляційної моделі.

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

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

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

2. Створення подання даних.

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

CREATE VIEW ІмяПросмотра [(столбец_view1 [, столбец_view2 ...])

AS <оператор_select> [WITH CHECK OPTION];

де після ІменіПросмотра слід необов'язковий список стовпців, оператор_select є повнофункціональний оператор SELECT, а необов'язковий параметр WITH CHECK OPTION визначає, чи допускати для оновлюваних переглядів введення записів, які задовольняють умові формування перегляду.

Для видалення перегляду використовується оператор

DROP VIEW ІмяПросмотра;

Розглянемо оператор CREATE VIEW детальніше. Існує необов'язкова можливість присвоєння власного імені (параметр столбец_view1) кожному із стовпців подання. Якщо вказується список імен стовпців, то він повинен мати кількість елементів, дорівнює кількості стовпців у результуючої таблиці запиту, заданого параметром <оператор_select>. Якщо список імен стовпців пропущено, кожен стовпець подання буде мати ім'я стовпця результуючої таблиці запиту, заданого параметром <оператор_select>. Список імен стовпців повинен обов'язково задаватися в тому випадку, якщо в іменах стовпців результуючої таблиці має місце неоднозначність. Подібна ситуація виникає в тих випадках, коли підзапит включає обчислювані поля, а фраза AS з іменами стовпців результуючої таблиці не містить для них імен або ж коли результуюча таблиця створюється за допомогою операції з'єднання і включає стовпці з однаковими іменами.

Заданий параметром <оператор_select> підзапит прийнято називати визначальним запитом. Якщо вказана фраза WITH CHECK OPTION, то гарантується, що в тих випадках, коли рядок даних не задовольняє умові, зазначеному в пропозиції WHERE визначає запиту представлення, вона не буде добавлена ​​в його базову таблицю. Хоча всі представлення створюються за допомогою одного і того ж методу, на практиці для різних цілей використовується різні типи представлень.