д, більш витонченням решение подібніх проблем Забезпечують системи про «єктно-орієнтованих баз даних (ООБД). У таких системах зберігаються НЕ запису Даних, а об» єкти. Коженая про «єкт має внутрішнім станом (по-простому, зберігає усередіні собі запис Даних), а такоже набором методів, тоб процедур, с помощью якіх (і Тільки таким чином) можна звернута до Даних, что становляит внутрішній стан об» єкта, та/або Изменить їх.
У разі ООБД конструювання бази даних Полягає в розробці структурованих и методів про «єктів. Тому можна Написати методи таким чином, щоб при роботі з будь-яким об »єктом Було Неможливо порушіті его цілісність. Наприклад, ООБД марок автомобилей Складанний б з об «єктів, внутрішній стан якіх являло б собою записи тієї ж структури, як и раніше, а до числа методів входив бі метод« Изменить Вагу автомобіля ». Тоді код цього методу автоматично змінював бі й клас автомобіля при вінікненні відповідної умови. До речі, зауважімо, что БУВ бі відсутній метод «Изменить клас автомобіля», значення класу Було б доступно Тільки з читання. Помилкові стану об »єктів все одне Можливі, оскількі Ніхто НЕ заважає звернута до методу« Изменить Вагу автомобіля »з невірнімі, хоч и правдоподібнімі параметрами. Як и раніше, Єдиним способом Зберегти можлівість доступу до последнего варіанту об'єкта з правильному стане є Використання техніки темпоральність баз даних.
З приводу підходу ООБД існує и ряд критичних зауваження. Зокрема, багатьох НЕ влаштовує, что вместо суто декларативних обмежень цілісності и полудекларатівніх трігерів, вікорістовуваніх в реляційніх системах, в ООБД для ПІДТРИМКИ внутрішньої цілісності об'єктів доводитися писати суто Процедурний код. Альо у шкірного свои уподобання. Особисто мені Ближче підхід ООБД.
Завершуючі цею невеличкий екскурс в область ЗАСОБІВ ПІДТРИМКИ цілісності Даних, ще раз зауважімо, что в будь-якому випадка при достатності старанні можна нашкодіті Собі больше, чем зловмісній ворог. Піклуючісь про захист від других, слід подуматі, наскількі ти захіщеній від ВЛАСНА помилок.
· У контексті баз даних Термін безпека означає захист Даних від несанкціонованого Розкриття, Зміни або знищення. SQL дозволяє індивідуально захіщаті як цілі табліці, так и окремі їхні поля. Для цього є Дві більш-Менш незалежні возможности:
· Механізм уявлень, Розглянуто у попередня розділі и вікорістовуваній для пріховування засекречених Даних від Користувачів, Які НЕ володіють правом доступу;
· Підсистема санкціонування доступу, что дозволяє надаті зазначенім Користувачи певні прівілеї на доступ до Даних и дати їм можлівість вібірково и дінамічно передаваті Частину віділеніх прівілеїв іншім Користувачи, скасовуючи Згідно ЦІ прівілеї, Якщо буде нужно.
Зазвічай при установці СКБД в неї вводитися Якийсь ідентифікатор, Який винен далі розглядатіся як ідентифікатор найбільш прівілейованого користувача - системного адміністратора. Коженая, хто може Войти в систему з Цім ідентіфікатором (і может вітримати тести на достовірність), буде вважатіся системним адміністратором до виходе з системи. Системний адміністратор может створюваті бази даних и має ВСІ прівілеї на їх Використання. ЦІ прівілеї або їх частина могут надаватіся іншім Користувачи (Користувач з іншімі ідентіфікаторамі). У свою черго, Користувачі, Які отримай прівілеї від системного адміністр...
