SELECT СПІВР_ІМ’Я, СПІВР_НОМЕР

FROM СПІВРОБІТНИКИ

WHERE СПІВР_СТАТ = "НІ",

і система сама виконає необхідний повний перегляд файла СПІВРОБІТНИКИ, оскільки поле СПІВР_СТАТ не є ключовим.

Далі, уявіть собі, що в нашій первинній реалізації інформаційної системи, заснованій на використанні бібліотек розширених методів доступу до файлів, обробляється операція реєстрації нового співробітника. Слідуючи вимогам узгодженої зміни файлів, інформаційна система вставила новий запис в файл СПІВРОБІТНИКИ і мала намір модифікувати запис файла ВІДДІЛИ, але саме в цей момент сталося аварійне вимкнення живлення. Очевидно, що після перезапуску системи її база даних буде знаходитися в неузгодженому стані. Зажадається з'ясувати це (а для цього треба явно перевірити відповідність інформації з файлах СПІВРОБІТНИКИ і ВІДДІЛИ) і привести інформацію в узгоджений стан. Справжня СУБД бере таку роботу на себе. Прикладна система не зобов'язана піклуватися про коректність стану бази даних.

Нарешті, уявимо собі, що ми хочемо забезпечити паралельну (наприклад, багатотермінальну) роботу з базою даних співробітників. Якщо спиратися тільки на використання файлів, то для забезпечення коректності на весь час модифікації будь-кого з двох файлів доступ інших користувачів до цього файла буде блокований (пригадайте можливості файлових систем для синхронізації паралельного доступу). Таким чином, зарахування на роботу Петра Івановича Сидорова істотно загальмує отримання інформації про співробітника Іванові Сидоровичі Петрове, навіть якщо вони будуть працювати в різних відділах. Справжня СУБД забезпечує набагато більш тонку синхронізацію паралельного доступу до даних.

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