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

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

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

Функції нашої інформаційної системи вимагають, щоб забезпечувалася можливість багатоключового доступу до цього файла по унікальних ключах (що не дублюється в різних записах) СПІВР_ІМ’Я і СПІВР_НОМЕР. Крім того, повинна забезпечуватися можливість вибору всіх записів із загальному значенням СПІВР_ВІД_НОМЕР, тобто доступ по не унікальному ключу. Для того, щоб отримати чисельність відділу або загальний розмір зарплати, кожний раз при виконанні такої функції інформаційна система повинна буде вибрати всі записи про співробітників відділу і полічити відповідні загальні значення.

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

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

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

Поняття узгодженості даних є ключовим поняттям баз даних. Фактично, якщо інформаційна система (навіть така простій, як в нашому прикладі) підтримує узгоджене зберігання інформації в декількох файлах, можна говорити про те, що вона підтримує базу даних. Якщо ж деяка допоміжна система управління даними дозволяє працювати з декількома файлами, забезпечуючи їх узгодженість, можна назвати її системою управління базами даних. Вже тільки вимога підтримки узгодженості даних в декількох файлах не дозволяє обійтися бібліотекою функцій: така система повинна мати деякі власні дані (метадані) і навіть знання, що визначають цілісність даних.

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

SELECT ВІД_РОЗМІР

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

WHERE СПІВР_ІМ’Я = "ПЕТРО ІВАНОВИЧ СИДОРЕНКО"

AND СПІВР_ВІД_НОМЕР = ВІД_НОМЕР

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