Засоби обробки транзакцій

Очевидно, що БД - це постійно змінюється під впливом користувачів і їхніх команд структура. До цих пір передбачалося, що ця система правильно розроблена і функціонує без яких-небудь збоїв. Проте в реальному житті, через помилки людей, що взаємодіють з СУБД, або через нестійку роботу комп'ютерів виникають збої і помилки і в самій БД. Тому в СУБД застосовують спеціальні способи відміни дій, що викликали такі помилки - це. передусім, транзакції, об яких вже йшлося. Команда SQL, яка надає дію на зміст або структуру БД, не обов'язкове буде необоротною - користувач може встановити, що відбудеться після закінчення її дії: чи залишаться внесені зміни в БД або вони будуть повністю проігноровані.

Транзакція починається всякий раз. коли відбувається сеанс роботи з SQL. Всі команди, які вводяться, будуть частиною цієї транзакції, поки вона не завершиться введенням команди COMMIT WORK або команди ROLLBACK WORK. COMMIT робить всі зміни, вироблені транзакцією, постійними, ROLLBACK може їх відмінити. Нова транзакція починається після кожної команди COMMIT або ROLLBACK.

Синтаксис цих команд дуже простій, щоб залишити всі зміни постійними використовують

COMMIT WORK/

а для відміни зміни ROLLBACK WORK;

В більшості випадків можна встановити параметр, званий AUTOCOMMIT. який буде автоматично запам’ятовувати всі команди, що виконуються, причому дії, які привели до помилки, завжди будуть автоматично відмінені. Звичайно цей режим встановлюється за допомогою команди типу SET AUTOCOMMIT ON;

а повернення до звичайної діалогової обробки запитів - за допомогою команди

SET AUTOCOMMIT OFF;

Крім того, є можливість установки AUTOCOMMIT. яку СУБД виконає автоматично при реєстрації. Якщо сеанс користувача завершується аварійно - наприклад, відбувся збій системи або виконане перезавантаження користувача, - то поточна транзакція виконає автоматичний відкіт змін. Це - одна з причин, по якій варто управляти виконанням діалогової обробки запитів, розділивши команди на різні транзакції.

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

Наприклад, виникла необхідність у видаленні даних про студента Полякова з таблиці STUDENTS. Очевидно, що при цьому потрібне що-небудь зробити з його оцінками за умови, що обмеження зовнішнього ключа відсутнє. Логічне розв'язання буде полягати в тому щоб встановити поле SNUM для записів з його оцінками, в NULL значення і лише після цього виконувати видалення. Це можна реалізувати таким чином:

UPDATE USP

SET SNUM = NULL WHERE SNUM = 3412;

DELETE FROM STUDENTS WHERE SNUM = 3412;

Якщо при цьому виникають які-небудь проблеми, то в користувача є можливість відмінити всі зміни командою ROLLBACK. У випадку, якщо все гаразд, і дію цієї групи команд на БД необхідно запам'ятати, це реалізується командою COMMIT.

В стандарті ANSI/ISO визначена модель транзакцій, а також вказані задачі операторів COMMIT і ROLLBACK. Згідно стандарту вважається, що транзакція автоматично починається з виконання користувачем або програмою першого оператора SQL. Далі відбувається послідовне виконання інших операторів SQL до тих пір, поки транзакція не завершиться одним з чотирьох способів:

1. • команда COMMIT завершує виконання поточної транзакції, причому зміни, внесені в БД, стають постійними. Нова транзакція починається безпосередньо після COMMIT:
2. • команда ROLLBACK відміняє виконання поточної транзакції, зроблені зміни відміняються, а нова транзакція починається безпосередньо після ROLLBACK;
3. • успішне завершення програми обробки даних вважається успішним закінченням транзакції, неначебто була виконана команда COMMIT. Нова транзакція не починається, т. до. програма закінчилася:
4. • неуспішне завершення програми вважається неуспішним закінченням транзакції, неначебто був виконана команда ROLLBACK. Нова транзакція не починається, оскільки програма закінчилася

Звернете увагу на те, що згідно стандартної моделі транзакцій, користувач або програма можуть виконати транзакцію завжди. Традиційно, при інтерактивному використовуванні SQL включено режим AUTOCOMMIT. тобто кожна команда стає окремою транзакцією.

В СУБД SQL Server використовується дещо розширена модель транзакцій, що надає користувачам додаткові можливості. При цьому використовуються команди:

1. • BEGIN TRANSACTION - повідомляє систему про початок транзакції. На відміну від стандартної моделі, початок транзакції задається явно за допомогою цієї команди:
2. • COMMIT TRANSACTION - повідомляє систему про успішне закінчення транзакції. Після виконання цієї команди всі зміни, зроблені в БД протягом транзакції, стають постійними, проте нова транзакція не починається; • SAVE TRANSACTION - створює усередині транзакції точку збереження. СУБД зберігає стан БД в поточній крапці і привласнює збереженому стану ім'я точки збереження, яке указується в операторі;
3. • ROLLBACK TO SAVEPOINT - відміняє зміни, зроблені в БД після точки збереження, повертаючи транзакцію до місця, де був виконаний оператор SAVE TRANSACTION.
4. • ROLLBACK - відміняє всі зміни, зроблені в БД після оператора BEGIN TRANSACTION.

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

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

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

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

3. Методи блокування

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

Обробка системою транзакцій, що виконуються одночасне, називається паралелізмом. При цьому можуть виникати наступні типи проблем:

1. • зміна даних може бути здійснене без урахування модифікації, зробленої іншим процесом. Така ситуація може виникнути, якщо в таблиці успішності відбувається коректування оцінок, а паралельно, іншим користувачем, відбувається встановлення розміру стипендії, виходячи з отриманих студентами оцінок: • зміни даних можуть бути відмінені одним процесом, тоді як модифікованими даними вже скористалися для іншої дії. Цей випадок вже проілюстрований вище, коли мінімальні значення оцінок могли бути вже отримані, після чого перший користувач вироблені зміни оцінок відмінив;
2. • одна дія може частково впливати на результат іншої дії Наприклад, при отриманні звіту про успішність не виключено, що іншим користувачем вироблено видалення із списку одного або декількох студентів, а дані про їхню успішність вже можуть увійти до висновку першого запиту.
3. • тупикова ситуація, яка може відбутися, якщо процеси спробувати виконати конфліктуючі друг з другом дії. Це може виникнути, наприклад, якщо один користувач пробує змінити значення зовнішнього ключа, а інший - батьківського ключа, і це відбувається одночасно.

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

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

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

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

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

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

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

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

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

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

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

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

Розглянемо приклад створення уявлення на основі відношення SP (Оцінки), приведеного на мал. 1. 11

СТВОРИТИ УЯВЛЕННЯ VIEW1

ДЛЯ (SP.OCENKA >= 3) [NAME, SN, OCENKA]

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

У прикладі створюється уявлення VIEW1. яке складається з трьох атрибутів - NAME, SN і OCENKA, причому вибиратимуться тільки ті кортежі, для яких оцінка буде більше або рівно 3, - грубо кажучи, інформація по успішних студентах. З таким уявленням користувач може працювати, як з реально існуючим.

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

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

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

SPP
SN	PN	NAME

Мал. 1.23. Структура відносин SPO і SPP

Зрозуміло, що з'єднання одержаних відносин відтворить відношення SP. Отже, для подальшої роботи можна створити уявлення SP, а значить, у користувача складеться враження, що ніякій реструктуризації просто не проводилося.

СТВОРИТИ УЯВЛЕННЯ SP SPP З'ЄДНАТИ З SPO

Будь-яка призначена для користувача програма після цього замість відношення SP використовуватиме створене уявлення для маніпуляції з даними.

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

Нарешті, використовуючи механізм уявлень можна приховати службові дані, які не цікаві користувачу. Так, номер студентського квитка, як правило, інтересу для користувача не представляє, проте він служить для забезпечення зв'язку відносин в БД. Можна створити уявлення, де замість номерів студентських квитків будуть підставлені прізвища студентів з іншого відношення. Очевидно, таке уявлення більш зручне у використовуванні

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

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

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

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

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

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

5. Створення, видалення і оновлення представлень

Представлення створюється командою CREATE VIEW, після якої указується його ім'я а далі слідує запит, що формує тіло представлення. Наприклад, для створення представлення OTLSTUD, яке містить інформацію про студентів, одержуючих стипендію у розмірі 525. можна скористатися наступною командою:

CREATE VIEW OTLSTUD AS SELECT *

FROM STUDENTS WHERE STIP=525;

Тепер в БД існує представлення з ім'ям OTLSTUD, яке можна використати в командах так само, як і будь-яку іншу таблицю: вона може запитати, модифікована, в неї можуть бути вставлені записи, вона може бути видалена з БД або сполучена з іншими таблицями і представленнями. При виконанні запиту

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

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

Представлення може тепер змінюватися командами модифікації DML. але модифікація не буде впливати на саме представлення. Фактично команди будуть перенаправлені до базової таблиці.

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

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

Коли робиться запит до представлення, насправді системою здійснюється звернення до базових таблиць.

В даному випадку СУБД чудово справляється з своєю задачею. Проте іноді виникають ситуації, коли з'являються проблеми з представленням в результаті комбінації з двох допустимих предикатів, які не будуть працювати.

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

Представлення можуть бути засновані відразу на декількох базових таблицях. Прикладом цьому може служити створення представлення, яке показувало б оцінки студента по учбовому предмету, причому містило б не коди, а повні назви:

Як було сказано вище, припускає об'єднувати представлення з іншими базовими таблицями або представленнями.

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

CREATE VIEW AVGOC

AS SELECT *

FROM USP FIRST

WHERE OCENKA > (SELECT AVG (OCENKA)

FROM USP SECOND

WHERE SECOND.PNUM = FIRST.PNUM);

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

На жаль, достатньо часте представлення є об'єктами, доступними тільки для читання. Це означає, що інформацію з них можна запрошувати, але вони не можуть піддаватися діям команд модифікації. Крім того, існують також деякі команди, які не допустимі у визначеннях уявленні: представлення повинне ґрунтуватися на одиночному запиті, тому об'єднання UNION не дозволяється. Крім цього, у визначенні представлення не використовується впорядкування ORDER BY, т.к., по аналогії з базовою таблицею, в уявленні записи є неврегульованими.

Синтаксис видалення представлення з БД подібний видаленню базових таблиць:

DROP VIEW <VIEW NAME>

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

Як вже було відзначено, не всі представлення здібні до модифікації. Взагалі кажучи, команди модифікації мови DML -ІNSERT. UPDATE і DELETE - кінцевий же можуть застосовуватися для уявлень.

6. Властивості модифікованих представлень

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

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

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

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

Критерії, по яких визначають, чи є представлення модифікується в SQL. наступні:

1. • представлення повинне ґрунтуватися тільки на одній базовій таблиці;
2. • воно повинне містити первинний ключ цієї таблиці.
3. • воно не повинне не мати ніяких полів, які б були агрегатними функціями;
4. • воно не повинне містити DISTINCT в своєму визначенні;
5. • представлення не повинне використати GROUP BY або HAVING в своєму визначенні.
6. • бажано, щоб воно не використало в своєму визначенні підзапити;
7. • воно може бути використане в іншому уявленні, але це представлення повинне також бути модифікується;
8. • воно не повинне використати константи, рядка або виразу значень серед вибраних полів висновку; • для команди INSERT воно може містити будь-які поля основної таблиці, які мають обмеження NOT NULL, якщо інше обмеження за умовчанням не визначене.

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

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

7. Види привілей.