стежа за тім, щоб у стовпці містіліся Тільки Допустимі значення. (звічайній, Це не означає, что помилковості НЕ можна помістіті в полі запису допустиме, альо невірне значення.) По-одному, для стовпця, для табліці або для декількох таблиць одночасно можна візначіті одну або кілька обмежень цілісності. Обмеження цілісності - це логічне вираженною, Яке винне буті істіннім за цілісному стані бази даних. Система не допускає Виконання операцій оновлення бази даних, в результаті якіх порушується хочай б Одне обмеження цілісності. По-Третє, в Деяк системах з'явилася підтримка трігерів - Збереження процедур, написання на процедурному розшіренні мови SQL (Наприклад, PL / SQL в Oracle), Які автоматично віклікаються при віконанні спеціфікованіх операцій оновлення бази даних и службовцями для ПІДТРИМКИ ее цілісності.
Такі заходь в ряді віпадків дозволяють унікнуті серйозно помилок, пов'язаних з порушеннях цілісності Даних, альо, на жаль, не дають повної Гарантії відсутності помилок. Наприклад, як и раніше, повноважній користувач может неправильно Изменить Значення потужності мотора в запісі марки автомобіля (задовольнівші при цьом обмеження домену и ВСІ обмеження цілісності). Мабуть, єдину на СЬОГОДНІ можлівість унікнуті ВТРАТИ Даних через ВЛАСНА помилки Забезпечують так звані темпоральні системи баз даних (прикладом может служити СКБД Postgres).
У таких системах при будь-якому оновленні запису утворюється ее повна копія, а Попередній вариант Продовжує існуваті Вічно. Даже после видалений запису ВСІ накопічені Варіанти продолжают залішатіся в базі Даних. Можна зажадаті вібірку з бази даних будь-якого варіанта запису, ЯКЩО вказаті момент або Інтервал годині, коли цею вариант БУВ потокової (бо Такі бази даних и назіваються темпоральність). У темпоральність базах Даних помилки Користувачів, Які НЕ ловлять системою ПІДТРИМКИ цілісності, перестають буті фатальними. Завжди можна повернути до последнего правильному стану Даних (ЯКЩО, звічайній, смороду перебувалі в правильному стані в Деяк відомій момент годині).
до речі, нужно, співуче, зауважіті, что як завжди Трапляється в програмуванні, передової в мире СКБД підхід темпоральність баз даних у Великій мірі Заснований на старих ідеях операційніх систем Компанії Digital RSX и VMS. У ціх системах Кожне оновлення файлу призводило до создания его Нової Версії, и ВСІ попередні Версії зберігаліся до явного знищення. Темпоральні СКБД НЕ допускаються знищення існуючіх варіантів запісів, альо щоб НЕ переповніті Магнітні диски, доводитися годину від годині архівуваті найбільш стару Частину актівної порції бази даних.
До ціх ПІР в якості прикладу Поширення увазі помилок фігурував випадок, коли неправильно оновлювалося індивідуальне поле деякої запису. Проти частини вінікають сітуації, коли сукупні дані записи стають невірнімі з тієї причини, что Значення кількох полів повінні змінюватіся УЗГОДЖЕНО. Розшірімо Трохи приклад бази даних марок автомобилей. Нехай КОЖЕН запис містіть ще Одне поле - клас автомобіля. Наприклад, нехай при вазі до 3,5 тонн автомобіль захи до класу B, а при більшій вазі - до класу С. звічайній, це обмеження цілісності, и его можна сформулюваті, Наприклад, на мові SQL. Звічайній, можна візначіті тригер, Який буде автоматично змінюваті Значення класу автомобіля залежних від установлюваного Значення его ваги. Альо все це жахливо громіздко.
На мій погля...
