БАЗОВІ ЗМІННІ ВІДНОСИНИ ТА ПОДАННЯ

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

Примітка В [33] базові змінні відносини називаються реальними змінними відносини

Реляційні системи, очевидно, повинні надавати кошти для створення, в першу чергу, базових змінних відносини У мові SQL, наприклад, ця функція забезпечується оператором CREATE TABLE (тут слово TABLE використовується у вузькому

сенсі, як базова змінна відносини) Базові змінні відносини, звичайно ж, повинні бути іменованими, як, наприклад, показано нижче

CREATE TABLE EMP ..

Однак реляційні системи зазвичай підтримують ще один вид іменованих змінних відносини, званих уявленнями У будь-який конкретний момент їх значення є похідним відношенням (і тому спрощено можна вважати, що подання – це похідна мінлива відносини) Значення даного подання в даний час є результатом обчислення певного реляційного вираження в даний момент, а згадане реляционное вираз визначається в момент створення цього подання Наприклад, для визначення уявлення ТОРЕМР можна використовувати наступний оператор

CREATE VIEW ТОРЕМР AS

) { EMP#, ENAME, SALARY }

( EMP WHERE SALARY &gt 3 3K

Примітка Оскільки в даний момент це несуттєво, в прикладі для зручності використовується змішана нотація мов SQL та Tutorial D

При виконанні цього оператора вираз, наступне за ключовим словом AS і

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

реальна змінна відносини з імям ТОРЕМР, що має поточне значення, яке показано на рис 37 тільки в незатінених ділянках І користувач повинен мати можливість оперувати цією виставою точно так, як якщо б воно було звичайною базової змінної відносини

Рис 37 Віртуальна мінлива відносини ТОРЕМР (незатененние ділянки)

як уявлення базової змінної відносини ОМР

Примітка Вище вже було сказано, що якщо такі змінні відносини, як DEPT і ОМР, можна вважати реальними, то змінну відносини ТОРЕМР слід розглядати як віртуальну змінну відносини, інакше кажучи, як змінну відносини, яка зовні існує як така, але насправді її немає (значення цієї змінної відносини в будь-який даний момент залежить від значень деяких

інших змінних відносини) І дійсно, в [33] уявлення називаються

віртуальними змінними відносини

Однак будьте уважні: відзначаючи, що значення змінної відносини ТОРЕМР є відношенням, яке було б результатом, якби визначальне дане подання вираз був на самому справі обчислено, ми зовсім не хочемо сказати, що існує окрема копія цих даних Інакше кажучи, ми зовсім не маємо на увазі, що вираз, що визначає уявлення, дійсно обчислюється Навпаки, уявлення – це по суті просто вікно, через яке можна бачити частину значення базової змінної відносини ОМР Звідси випливає, що будь-які зміни в базовій змінної відносини будуть автоматично та негайно надходити в подібне вікно (Звичайно, якщо ці зміни відносяться до незатененние частини реальної змінної відносини) Аналогічно, зміни, внесені в змінну відносини ТОРЕМР, будуть автоматично та негайно застосовані до дійсного змінного відносини ОМР і, отже, стануть видні через це вікно (приклади будуть наведені пізніше)

Нижче показаний приклад запиту, що використовує уявлення TОРЕМР

(ТОРЕМР WHERE SALARY <42К) {ОМР #, SALARY}

Якщо в якості вихідних використовуються дані на рис 37, то результат буде мати вигляд, показаний на рис 38

Рис 38 Результат використання подання ТОРЕМР

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

( ТОРЕМР WHERE SALARY < 42К) {ОМР #, SALARY}

модифікується системою наступним чином

( ((ОМР ​​WHERE SALARY> ЗЗК) {ОМР #, ENAME, SALARY}) WHERE SALARY < 42К) {ОМР #, SALARY}

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

(ОМР WHERE SALARY> ЗЗК AND SALARY <42К) {ОМР #, SALARY}

Обчислення даного виразу призводить до результату, показаному вище Іншими словами, первісна операція над виставою просто перетвориться в еквівалентну операцію над відповідної базової змінної відносини, після чого

отримана еквівалентна операція виконується звичайним чином (точніше, оптимізується і виконується звичайним чином)

В якості іншого прикладу розглянемо операцію видалення DELETE

DELETE TOPEMP WHERE SALARY &lt 42K

Насправді буде виконана наступна операція

DELETE EMP WHERE SALARY> ЗЗК AND SALARY < 42К;

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

CREATE VIEW JOINEX AS

( ( EMP JOIN DEPT ) WHERE BUDGET &gt 7M ) { EMP#, DEPT# }

До питання визначення та обробки подань ми ще повернемося в главі 10 Між іншим, зараз вже можна пояснити сенс наведеного в кінці розділу 22 зауваження, що стосується того, що термінуявлення(View) в реляційному контексті має досить специфічне значення, що не співпадає із значенням, приписаним йому в архітектурі ANSI / SPARC На зовнішньому рівні цієї архітектури база даних сприймається як зовнішнє подання, яке визначається зовнішньої схемою (і різні користувачі можуть мати різні зовнішні подання) У реляційних системах, навпаки, уявлення, як пояснювалося вище, є спеціально іменованої похідною віртуальної змінної відносини Тому реляційним аналогом зовнішнього подання ANSI / SPARC зазвичай служить безліч з декількох змінних відносини, кожна з яких є поданням до реляційному сенсі Зовнішня схема складається з визначень таких подань (З цього випливає, що в реляційної моделі подання є одним із способів забезпечення логічної незалежності від даних,хоча ще раз слід зазначити, що сучасні комерційні продукти мають серйозні недоліки в цій частині Подробиці наведені у главі 10)

Архітектура ANSI / SPARC є досить загальною і допускає довільні перетворення між зовнішнім і концептуальним рівнями В принципі, навіть типи структур даних, підтримувані на цих двох рівнях, можуть бути різними: наприклад, концептуальний рівень може бути реляційних, тоді як конкретному користувачеві може бути передане зовнішнє уявлення ієрархічного тіпа5 Однак на практиці в більшості систем в якості базових на обох рівнях використовуються однакові типи структур Реляційні продукти не є виключенням з цього загального правила – представлення як і раніше залишається змінної відносини, як і базові змінні відносини А оскільки на обох рівнях підтримуються однакові типи обєктів, на цих рівнях застосовується один і той же подязик даних (зазвичай це мова SQL) Дійсно, той факт, що представлення – це змінна

5 Приклад здійснення такої можливості приведений в главі 27

відносини, так само важливий для реляційних систем, як для математики важливо те, що підмножина є множиною

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

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

■ Базові змінні відносини реально існують в тому сенсі, що вони багато в площать в собі дані, які дійсно зберігаються в базі даних

■ Уявлення, навпаки, реально не існують, а просто надають раз особисті способи перегляду реальних даних

Однак така характеристика, хоча і корисна в неформальному сенсі, неточно відображає справжній стан справ Дійсно, користувачі можуть розглядати базові змінні відносини як фізично збережені, оскільки фактично головна мета створення реляційних систем полягає в тому, щоб дати можливість користувачеві працювати з базовими змінними відносини як з фізично існуючими, не піклуючись про те, як ці змінні відносини фізично представлені в памяті Але (і це дуже суттєва але!) Подібні погляди користувачів на те, як відбувається обробка даних, не можна тлумачити так, ніби базова змінна відносини – це безпосередньо фізично зберігається змінна відносини (наприклад, як єдиний бережене файл) Як пояснювалося в розділі 32, базові змінні відносини найкраще представляти як абстракцію для деякого набору даних, що зберігаються – абстракцію, що приховує всі деталі рівня зберігання даних В принципі, базова змінна відносини і її бережене еквівалент6 можуть відрізнятися в довільній ступеня

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

6 Наступна цитата з однієї нещодавно вийшла книги демонструє деякі непорозуміння, обговорювані тут, а також непорозуміння, які обговорювалися в розділі 33: Важливо розрізняти збережені відносини, які є таблицями, і віртуальні відносини, які є уявленнями .. [Ми] будемо використовувати термін ставлення тільки в тих випадках, коли замість нього можна використовувати термін «таблиця» або «подання» Якщо необхідно буде підкреслити, що дане відношення є збереженим ставленням, а не поданням, то в цьому випадку ми будемо використовувати термін базове ставлення або базова таблиця Подібні цитати, на жаль, – не рідкість

Джерело: Дейт К Дж, Введення в системи баз даних, 8-е видання: Пер з англ – М: Видавничий дім «Вільямс», 2005 – 1328 с: Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*