Цілісність даних

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

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

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

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

Додаткова Детально нормалізація буде описана в розділі 2

інформація

Цілісність домену

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

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

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

Водночас посилальна цілісність є не питанням цілісності первинного ключа, а тільки повязаного з ним зовнішнього

Допустимість порожніх значень в стовпці – це окреме питання, не повязаний з посилальною цілісністю Зовнішній ключ, в принципі, цілком може містити порожні значення

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

Певна користувачем цілісність

Осторонь від вимог цілісності реляційної теорії існує і обумовлена ​​користувачем цілісність Вона може підтримуватися наступним чином:

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

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

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

■ пошук некоректних даних

■ пошук неповних даних

■ пошук сумнівних даних

■ пошук неузгоджених даних

Якість даних безпосередньо залежить від людей, які їх вводять або змінюють Захист даних (тобто контроль над тим, хто саме може переглядати або змінювати їх) також є одним з аспектів підтримки їх цілісності

Цілісність транзакцій

Транзакцією називається єдиний логічний блок роботи, наприклад вставка 100 рядків, оновлення 1000 рядків або виконання логічного ланцюжка оновлень Якість продукту бази даних залежить від того, наскільки його можливості виконання транзакцій відповідають принципам АСШ Як ви памятаєте, ця абревіатура розшифровується як чотири взаємозалежних властивості: атомарность, цілісність, ізоляція і живучість Велика частина архітектури SQL Server заснована саме на цих властивостях, тому, щоб зрозуміти SQL Server, потрібно засвоїти їх значення

■ Властивість атомарности увазі, що транзакція повинна або виконатися вся, або не виконатися в цілому Наприкінці транзакції вона повинна бути або підтверджена, або скасована Якщо частково виконана транзакція записується на диск, то властивість атомарности порушується

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

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

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

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

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

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

Помилки транзакцій

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

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

“Брудна читання

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

Неповторяющееся читання

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

Примарні рядка

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

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

Втрачені поновлення

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

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

Взаимоблокировки

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

■ Перша транзакція блокувала дані А і збирається для свого завершення блокувати дані Б

■ У той же час друга транзакція блокувала дані Б і збирається для свого завершення блокувати дані А

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

Додаткова У главі 51 будуть наведені приклади помилок транзакцій, рівнів ізоляції інформацій і блокувань в SQL Server

Рівні ізоляції

На фізичному рівні будь ядро ​​бази даних, яка допускає логічні транзакції, повинно містити механізми ізоляції Для контролю, які помилки транзакцій допустимі, існують рівні ізоляції, тобто образно кажучи, висота забору між ними У специфікації ANSI SQL-92 визначено чотири рівня ізоляції:

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Read uncommited

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Read commited

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Repeatable read

■&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp&nbsp Serializable

На додаток до цього списку компанія Microsoft у версії SQL Server 2005 додала рівень ізоляції Snapshot По суті, цей рівень створює віртуальну копію, або миттєвий знімок, даних першої транзакції, в результаті чого інші транзакції на неї не впливають Цей метод може призвести до втраченим оновлень

Порожні значення

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

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

■ Дані ще не введені, але незабаром це буде зроблено Наприклад, якщо контактна особа має імя і номер телефону, а адреса буде введений в процесі прийому замовлення

■ Стовпець у цьому рядку взагалі не містить значення Наприклад, стовпець коментаря заповнюється не для всіх співробітників, представлених у списку

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

Можливість існування в стовпці порожнього значення, як правило, визначається в момент його створення Однак візьміть до відома, що за замовчуванням SQL Server не допускає порожніх значень, в той час як стандарт ANSI – допускає

Робота з порожніми значеннями

У звязку з тим що порожнє значення увазі невідомість такого, результат будь-якого виразу, який включає в себе значення null, також не може бути відомий Наприклад, якщо стан банківського рахунку невідомо, а він включений в суму загальних доходів, то ця сума також буде невідома Та ж концепція впроваджена і в SQL Server Як сказав відомий розробник баз даних Філ Сенн: Пусте значення припиняє життя будь-якого іншого . Наприклад, результатом вираження SELECT 1 + NULL буде NULL

Ще одним наслідком невизначеності порожнього значення є те, що одне значення NULL не може дорівнювати іншому З цієї причини для перевірки наявності порожнього значення в мові SQL введена спеціальна вираз IS NULL

Однак такий стандартний режим роботи може бути порушений SQL Server буде ігнорувати присутність порожнього значення у вираженні, якщо встановити для параметра concat_null_yelds_null значення off Інша вираз, ANSI nulls, керує тим, чи буде одне пусте значення вважатися рівним іншому

Суперечливість порожнього значення

Велика частина розробників баз даних дозволяє поміщати в стовпці порожні значення, коли це має сенс

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

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

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


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

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

Ваш отзыв

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

*

*