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

У лекції 2, "Середовище бази даних" при розгляді трьохрівневої архітектури ANSI-SPARC зовнішнє представлення описувалося як структура бази даних з погляду окремого користувача. У реляційній моделі слово "представлення" (view) має трохи інше значення. Воно характеризує не всю зовнішню модель користувача, а лише деяке використовуване їм віртуальне відношення (virtual relation), тобто відношення, якого насправді самого по собі не існує, але яке динамічно відтворюється на підставі одного чи декількох базових відношень (відношень, що реально існують у базі даних). Представлення може бути побудоване на базі виконання таких операцій реляційної алгебри, як вибірка, проекція, з'єднання, або на основі інших операцій зі значеннями з реально існуючих базових відношень. Таким чином, зовнішня модель може складатися одночасно як з базових (на концептуальному рівні) відношень, так і з представлень, відтворених на основі цих базових відношень. У цьому розділі розглядаються саме такі віртуальні відношення, чи представлення, що є типовим елементом реляційних систем.

3.5.1. Термінологія

Ті відношення, з якими ми мали справу дотепер, називаються базовими відношеннями.

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

Поняття представлення визначається на основі базових відношень.

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

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

3.5.2. Призначення представлень

Механізм представлень може використовуватися з кількох причин.

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

• Він дозволяє організувати доступ користувачів до даних найбільш зручним для них чином, тому ті самі дані в той самий час можуть розглядатися різними користувачами зовсім відмінними способами.

• Він дозволяє спрощувати складні операції з базовими відношеннями. Наприклад, якщо представлення буде визначено на основі з'єднанні двох відношень, то користувач зможе виконувати над ним прості унарні операції вибірки і проекції, що будуть автоматично перетворені засобами СКБД в еквівалентні операції з виконанням з'єднання базових відношень.

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

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

• Більшість користувачів при роботі з записами відношення Staff не повинні мати доступу до атрибута Salary. Для створення представлення, що не містить атрибута Salary, можна застосувати операцію проекції.

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

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

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

Renter (Rno, FName, LName, Address, Tel_No, PrefJType, Max_Rent, Bno)

Ми можемо перетворити його в наступних два відношення:

Renter_Details(Rno, FName, LNane, Address, Tel_Mo, Bno)

Renter_Reqts(Rno, Pref_Type, Hax_Rent)

При цьому користувачі і програми зможуть як і раніше здійснювати доступ до даних, використовуючи структуру старого відношення, якщо вона буде відновлена за допомогою визначення представлення Renter у виді природного об'єднання відношень Renter_Details і Renter_Reqts по атрибутові Rno.