3 Запит оновлення

Оператор UPDATE застосовується для зміни значень в групі записів або в одному записі вказаної таблиці.

Формат оператора:

<оператор_зміни> ::=

UPDATE ім’я_таблиці SET ім’я_колонки = <вираз>[,...n]

[WHERE <умова_вибірки>]

Параметр ім’я_таблиці – це або ім'я таблиці бази даних, або ім'я уявлення, що оновлюється. В пропозиції SET указуються імена одного і більш стовпців, дані в яких необхідно змінити. Пропозиція WHERE є необов'язковою. Якщо вона опущена, значення вказаних стовпців будуть змінені у всіх рядках таблиці. Якщо пропозиція WHERE присутня, то будуть оновлені тільки ті рядки, які задовольняють умові відбору. Вираз є новим значенням відповідного стовпця і повинне бути сумісно з ним по типу даних.

Приклад 9.4. Збільшити ціну товарів першого сорту на 25%.

UPDATE Товар SET Товар.Ціна=Товар.Ціна*1.25

WHERE Товар.Сорт = "Перший"

Приклад 9.4. Оновлення вибраних записів.

Приклад 9.5. В операції з максимальною кількістю товару збільшити число товарів на 10%.

UPDATE Операція SET Операція.Кількість = Операція.Кількість*1.1

WHERE Операція.Кількість = (SELECT Max(Операція.Кількість) FROM Операція)

Приклад 8.6. Оновлення вибраних записів.

4 Введення в поняття "цілісність даних"

Виконання операторів модифікації даних в таблицях бази даних INSERT, DELETE і UPDATE може привести до порушення цілісності даних і їх коректності, тобто до втрати їх достовірності і несуперечності.

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

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

• обов'язкові дані;

• обмеження для доменів полів;

• корпоративні обмеження;

• цілісність сутностей;

• посилальна цілісність.

Обов'язкові дані

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

Обмеження для доменів полів

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

Корпоративні обмеження цілісності

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

Цілісність сутностей

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

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

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

Посилальна цілісність

Вказане обмеження цілісності торкається зовнішніх ключів.

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

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

Існує три різновиди зв'язку між таблицями бази даних:

"один-до-багатьох";

"один-до-одного";

"багато-до-багатьох".

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

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

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

Відношення "багато-до-багатьох" має місце в наступних випадках:

одному запису в батьківській таблиці відповідає більше одного запису в дочірній таблиці ;

одному запису в дочірній таблиці відповідає більше одного запису в батьківській таблиці.

Вважається, що всякий зв'язок "багато-до-багатьох" може бути замінена на зв'язок "один-до-багатьох" (один або декілька).

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

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

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

Наступна проблема пов'язана з організацією підтримки посилальної цілісності при виконанні операцій модифікації даних в базі. Тут можливі наступні ситуації:

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

• Видалення рядка з дочірньої таблиці. Ніяких порушень посилальної цілісності не відбувається.

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

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

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

• NO ACTION. Видалення рядка з батьківської таблиці забороняється, якщо в дочірній таблиці існує хоча б один рядок, що посилається на неї.

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

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

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

• NO CHECK. При видаленні рядка з батьківської таблиці ніяких дій по збереженню посилальної цілісності даних не робиться.

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

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

Рівень підтримки цілісності даних в різних системах істотно варіюється.

Ідеологія архітектури клієнт-сервер вимагає перенесення максимально можливого числа правил цілісності даних на сервер. До переваг такого підходу відносяться:

• гарантія цілісності бази даних, оскільки всі правила зосереджені в одному місці (в базі даних);

• автоматичне вживання певних на сервері обмежень цілісності для будь-яких додатків;

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

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

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

До недоліків зберігання обмежень цілісності на сервері можна віднести:

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

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

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

Контрольні питання

1. Що таке у вашому розумінні активний запит?

2. Перерахуйте відомі вам оператори активних запитів.

3. Яким чином працює оператор додавання нових даних?

4. Поясніть його параметри.

5. Чи є які правила використання оператору вставки даних?

6. Яким чином працює оператор видалення записів?

7. Поясніть його параметри.

8. Чи є які правила використання оператору видалення даних?

9. Яким чином працює оператор оновлення записів?

10. Поясніть його параметри.

11. Чи є які правила використання оператору оновлення даних?

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

13. В чому полягає призначення цілісності?

14. Перерахуйте відомі вам типи обмежень.

7