ОБЛАСТЬ ЗАСТОСУВАННЯ ВИСТАВ

Підтримка уявлень бажана з багатьох причин Зазначимо деякі з них

■&nbsp&nbsp&nbsp&nbsp Користувачам надається можливість використовувати кошти скороченою записи операторів – свого роду макроси.

Розглянемо запит Визначити усі міста, в яких зберігаються деталі, що поставляються деякими постачальником, що знаходиться в Лондоні. Необхідний запит можна легко сформулювати з допомогою уявлення CITY_PAIR (пари міст), визначеного в підрозділі Додаткові приклади попереднього розділу

( CITY_PAIR WHERE SCITY = London ) { PCITY }

Сформулювати даний запит, не користуючись цим поданням, буде набагато складніше

( ( ( S RENAME CITY AS SCITY ) JOIN SP JOIN ( P RENAME CITY AS PCITY ) )

WHERE SCITY = London ) { PCITY

}

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

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

деякі додаткові витрати мають місце тільки на етапі розгортання уявлень (як і у випадку макросів)

■&nbsp&nbsp&nbsp&nbsp Уявлення дозволяють різним користувачам різним чином бачити одні й ті ж дані в один і той же час

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

■&nbsp&nbsp&nbsp&nbsp Забезпечується автоматичний захист прихованих даних

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

■&nbsp&nbsp&nbsp&nbsp Уявлення можуть забезпечувати логічну незалежність від даних

Це одне з найважливіших потенційних переваг уявлень, тому ми розглянемо його окремо в наступному розділі

Логічна незалежність від даних

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

Примітка Аспект зростання тут обговорюється тільки для повноти викладу Він досить важливий, але його звязок з уявленнями дуже відносна

■&nbsp&nbsp&nbsp Зростання бази даних

У міру зростання бази даних, акумулюючої нові види інформації, повинна відповідно зростати і кількість використовуваних в ній визначень структур даних Можливі два різновиди зростання

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

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

Жодна із зазначених різновидів зростання не повинна надавати будь-якого впливу на роботу існуючих користувачів або програм користувача, принаймні, в принципі (проте см у цьому звязку пункт 6 вправи 861, наведеного у розділі 8, в якому розглядається одна з проблем, що виникають при використанні конструкції SELECT * в мові SQL)

■&nbsp&nbsp&nbsp&nbsp Реструктуризація бази даних

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

VAR SNC BASE RELATION { S# S#, SNAME NAME, CITY CHAR } KEY { S# }

ill

VAR ST BASE RELATION { S# S#, STATUS INTEGER

} KEY { S# }

Тут істотно те, що колишня змінна відносини S стає зєднанням двох нових змінних відносини SNC і ST (а обидві нові змінні відносини, SNC і ST, є проекціями старої змінної відносини S) Отже, можна створити уявлення, яке буде передбачати виконання зазначеного зєднання, і присвоїти йому імяе

VAR  S   VIEW

SNC   JOIN   ST   

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

2 Це можливо лише в принципі На жаль, сучасні продукти SQL (і сам стандарт мови SQL) в цілому не підтримують операції маніпулювання даними в поданнях належним чином і, отже, не забезпечують повною мірою логічної незалежності від змін, подібних показаним в цьому прикладі Говорячи конкретніше, більшість програмних продуктів (але не всі) в даний час коректно підтримують лише операції вибірки даних через подання, але, наскільки відомо автору, жоден з продуктів SQL не підтримує правильно операції оновлення за допомогою уявлень (до того ж, безумовно, це не передбачено і стандартом), тому сучасні продукти SQL не забезпечують повну логічну незалежність від даних стосовно операцій оновлення Примітка Є один програмний продукт, який правильно підтримує операції оновлення за допомогою уявлень (хоча він не є програмним продуктом SQL), який описаний в [201]

Слід зазначити, що заміна початкової змінної відносини S, що містить дані про постачальників, двома проекціями цієї змінної відносини, SNC і ST, в загальному випадку не така вже тривіальна задача Зокрема, слід враховувати, що деяких додаткових дій потребують мінлива відносини SP, що містить відомості про постачання, оскільки в ній використовується зовнішній ключ, що посилається на вихідну змінну відносини з даними про постачальників S (див упр 1014)

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

Два важливих принципи

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

■ Користувач, який сам визначає деяке уявлення V, безумовно, знайомий з відповідним виразом X, визначальним це подання Він може використовувати імя V скрізь, де застосовно вираз X, розглядаючи його при цьому просто як скорочений запис даного виразу

■ Користувач, якому відомо лише те, що подання v існує і його можна застосовувати, найчастіше незнайомий з виразом X, визначальним це подання З його точки зору уявлення V має виглядати і дійство вать точно так само, як звичайна базова змінна відносини

Зі сказаного можна зробити висновок, що питання про те, якою є дана змінна відносини, базової або похідної (тобто уявленням), певною мірою залежить від точки зору користувача Розглянемо випадок змінних відносини S, SNC і ST, що використовувалися в обговоренні питаньреструктуризації в попередньому розділі Очевидно, що існують наступні два можливих підходи до аналізу взаємозвязку між цими змінними відносини:

■ визначити S як базову змінну відносини, a SNC і ST – як представле ня, які є проекціями цієї базової змінної відносини або

■ визначити SNC і ST як базові змінні відносини, a S – як представле ня, що є зєднанням цих двох базових змінних отношенія3

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

3 Див обговорення декомпозиції без втрат в розділі 122 глави 12

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

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

Джерело: Дейт К Дж, Введення в системи баз даних, 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>

*

*