Термін «цілісність» використовується для опису точності і коректності (або несуперечності) даних, що зберігаються в базі даних.
Якщо термін «безпека» означає захист даних від несанкціонованого доступу, то «цілісність» означає захист від санкціонованого доступу, тобто цілісність виникає тоді, коли у користувача є права роботи з базою даних, але при цьому він працює коректно (не вводить якихось даних, які призводять базу даних в неправильне положення).
Обмеження цілісності можуть бути будь-якого ступеня складності. У ряді випадків додаткові різні обмеження називають бізнес-правилами. Коли мова йде про елементарні обмеження, то тут використовується ключове слово CHECK (контроль правильності введення даних, відповідності цих даних іншим ...), їх називають елементарними, вони найчастіше бувають жорстко вписані. Розширені правила можуть включати питання цілісності між окремими таблицями, наприклад, «немає дітей без батьків». А бізнес-правила можуть стосуватися конкретних сфер застосування баз даних (наприклад, у бухгалтерської бази даних свої, в іншої інші ...). При цьому самі обмеження можуть бути встановлені на сервері, на клієнті або на проміжних програмних засобах (middleware).
А) Розглянемо варіант «на сервері», тобто обмеження розміщують у вигляді коду на сервері. У цьому випадку дані самостійно захищаються від втручання і випадкового стирання, і всі клієнти автоматично підкоряються цим обмеженням. Це призводить до того, що самі клієнтські програми можуть бути більш простими, оскільки в них вже не треба закладати обмежень. По-друге, виконання обмежень на сервері швидше, тому що їх не треба висилати на сервер, а треба тільки надіслати помилку. Однак є певні проблеми, пов'язані з тим, що мова SQL не такий гарний, у порівнянні з універсальними мовами, і там не так просто хитрі обмеження зробити. За своєю суттю обмеження зберігаються в системних таблицях бази даних, у них зазвичай є або автоматично створювані, або створювані користувачем імена (останній варіант краще, тому що якщо автоматично, то йдуть номера, в яких важко знайти потрібне обмеження). У InterBase автоматично вони називаються integer _№. До недоліків також можна віднести неможливість клієнтського додатка реагувати на деякі помилкові ситуації (Наприклад, проблеми з мережею).
В) Розміщення обмежень на рівні проміжних засобів. До проміжних засобів відносяться такі системи як ODBC, GDBC, різні API, які надають уніфікований доступ до баз даних (OLE DB ...). Тут теж є певні плюси і мінуси. Мінуси перш за все пов'язані з тим, що, незважаючи на те, що таких API стало багато, проте досить сильно розвинених засобів створення обмежень мало, по-друге, всі ці API зазвичай прив'язані до операційної системи (бази даних як правило роблять так, щоб вони і там, і там могли працювати, а ось ці проміжні кошти - зазвичай приналежність або UNIX, або Windows, або ще чого-небудь).
Типи (види) умов цілісності даних:
1. обов'язковість даних - як тільки ви ввійдете в набір даних того чи іншого поля, поки не введете будь-які дані, вас система із засобу набору не випустить (NOT NULL).
2. перевірка на правильність (validity checking) - перевірка діапазону значень (правильність введення дати, розміру чисел)
3. цілісність (entity integrity) - відповідність зовнішнього ключа і primary key
4. посилальна цілісність (referent integrity) - як правило, перевіряють в двох місцях: на клієнті, на сервері.
5. несуперечливість (business правила) - ділові правила, залежить від конкретних СУБД.
Реалізація ділових правил у прикладній програмі (на стороні клієнта) має ряд недоліків:
- дублювання - якщо є якісь обмеження і кілька додатків, то потрібно не забути зайти в код кожної програми і зробити там відповідне обмеження.
- недостатня узгодженість - великі системи пишуть різні програмісти і можуть по різному реалізувати одні і ті ж обмеження, які в результаті працюють по різному (з різною швидкістю тощо) не узгоджено.
- труднощі супроводу - системи не бувають статичні, їх часто доробляють і переробляють відповідно до зовнішніми змінами, доводиться забиратися в код програми і вносити зміни.
- складність - велика кількість різних бізнес правил, тому будь-яке, навіть просте оновлення таблиці, наприклад, призводить до тривалого процесу, тому що потрібно робити багато перевірок.
У 1986 році фірма «say base» ввело поняття «тригера», що дозволило включити (перенести) написання ділових правил на сервер і, отже, зменшити обсяг прикладних програм.
Недоліки тригерів:
- складність бази даних, коли ділові правила стають частиною бази даних,
- прихованість правил - логіка спрацьовування тригерів буває не завжди зрозумілою, особливо для програмістів, які приходять на модернізацію програми, тобто доводиться розбиратися в чужій програмі і логіці, що важко. Це іноді називають прихованими правилами.
Спонсор поста:
двадцять тисяч рублів на новий рік - новий чудовий конкурс. Зроби собі подарунок на новий рік, просто займи третє місце у видачі Яндекса.