ться успішно, або (наприклад, у разі непередбаченої помилки) жодна з них не відбивається на даних в постійній пам'яті (фіксується). У сучасних СУБД транзакції не фіксуються до тих пір, поки не надійде спеціальна команда (commit). До фіксації змін у БД можлива їх скасування (так званий відкат) іншою командою (rollback). p align="justify"> Транзакції повністю реалізовані, насамперед, у СУБД, які розраховані на одночасну роботу багатьох користувачів (Oracle, MS SQL Server, IBM DB2, Informix, Sybase). З наявністю великої кількості користувачів різної кваліфікації пов'язана також підтримка у цих СУБД привілеїв, які обмежують доступ до даних і цим підвищують надійність БД. Аналогічні можливості обмеження прав доступу до даних існують і на рівні сучасних файлових систем (ОС Windows NT або Unix). p align="justify"> Мультиплеєрні СУБД зазвичай реалізуються на основі архітектури "клієнт-сервер , в якій дані зберігаються на сервері, а представляються і редагуються користувачем на комп'ютерах-клієнтах, об'єднаних разом з сервером в мережу на основі якого-небудь протоколу транспортного рівня. Мережеві технології також використовуються в т. н. розподілених СУБД, які працюють з однією і тією ж базою даних одночасно на великій кількості серверів. У світі файлових систем аналогічні можливості забезпечуються, наприклад, підключенням мережного диска в Windows або монтуванням мережевого пристрою в загальну файлову систему Unix. Однак файлові системи не можуть забезпечити обмін даними через мережеві протоколи більш високого - прикладного - рівня, зокрема, використання сервісу WWW через протокол HTTP. Це істотно полегшує розробку інформаційних систем, оскільки на СУБД покладається відповідальність не тільки за витяг, а й за подання даних користувачеві (у вигляді Web-сторінок).
Одним з основних вимог до СУБД є надійність зберігання даних в постійній пам'яті - можливість відновлення останнього узгодженого стану БД після будь-якого апаратного або програмного збою. Для цього в багатьох СУБД існують спеціальні файли журналу змін, в який записується будь-яка операція перед тим, як вона модифікує дані в БД. Журнал цього типу дозволяє автоматично проводити відкат незавершених транзакцій після несподіваної втрати вмісту оперативної пам'яті (після м'якого збою). Другий тип журналу забезпечує надійність БД по відношенню до жорсткого збою (до виходу з ладу пристрою постійної пам'яті): він зберігається на іншому пристрої разом з резервною копією всій БД, яка періодично (наприклад, раз на місяць) оновлюється. При втраті основної БД над резервною копією повторюються всі транзакції, інформація про яких записана в журналі. Звичайно, надійність досягається за рахунок зменшення продуктивності і деякої надмірності даних при журналированием. Слід зауважити, що деякі сучасні файлові системи (зокрема, NTFS) мають аналогічні засоби відновлення після (м'яких) збоїв. p align="justify"> Та...
