Обычно с документом в программах можно делать всё, что угодно, пока не настала пора его сохранить. Испортив неаккуратными действиями, можно вернуться к исходному документу, не сохраняя изменения. В БД это не так.
Таблицы БД не являются самостоятельными документами, а только сама БД – документ. Ей соответствует файл на диске. Структура таблиц – тоже документ. В некоторых системах она имеет отдельный файл, а вот в Access такого файла нет, но структура таблиц входит в состав общего файла БД наряду с запросами, формами, отчётами и другими объектами. При изменении структуры таблицы система управления БД всегда выдаёт запрос на сохранение изменений.
Но содержание таблиц – это совсем другое дело. Его нельзя сохранить принудительной командой или, наоборот, отказаться от его сохранения. Все изменения сохраняются автоматически в режиме реального времени. Режим реального времени означает, что, пока мы работаем с таблицей, происходит её непрерывное сохранение. Как только заканчивается ввод данных в одно поле и происходит переход к следующему полю, данные немедленно записываются на жёсткий диск. Начинающих это вводит в заблуждение. Экспериментируя с таблицами, надо знать, что все изменения, которые вносятся в их содержание, имеют необратимый характер. Нельзя что-то изменить, удалить, а потом отказаться от сохранения и вернуться к исходному варианту.
Эта особенность СУБД требует аккуратного отношения к работе с таблицами. Для экспериментов надо создавать отдельные копии базы или таблицы и работать с ними.
СУБД должны учитывать, что с базами могут одновременно работать много людей. В БД один пользователь, вносящий изменения в базу, блокирует только одну запись, с которой он работает, причём ненадолго. Как только ввод очередной записи завершается, она становится доступной всем инспекторам для просмотра, а некоторым (кому положено по должности) и для редактирования.
Если в локальной и глобальной сети с одной базой работают несколько пользователей, то каждый может видеть в режиме реального времени те изменения, которые вносят в данные его коллеги.
Создатели СУБД не могут полагаться на то, что конкретный пользователь не забудет своевременно дать команду сохранить. Они учитывают и то, что во время работы может произойти аварийное отключение электричества. Ни при каких условиях информация не должна теряться, поэтому все изменения данных немедленно и автоматически сохраняются на диске.
В СУБД Access процесс создания реляционной базы данных не ограничивается созданием таблиц, а включает также создание схем данных.
Схема данных наглядно отображает таблицы и связи между ними, а также обеспечивает использование связей при обработке данных. В схеме данных устанавливаются параметры обеспечения целостности связей в базе данных. Таким образом, осуществляется неразрывная связь внемашинного проектирования БД с этапом её создания с помощью СУБД.
Между записями двух таблиц (например, таблиц А и В) могут существовать следующие виды связей:
- «один к одному» (каждой записи из А соответствует одна запись из В, например, преподаватель читает только один предмет);
- «один ко многим» (каждой записи из А соответствует несколько записей из В, например, на кафедре работает несколько преподавателей);
- «многие к одному» (множеству записей из А соответствует одна запись из В, например, несколько студентов учатся в одной группе);
- «многие ко многим» (множеству записей из А соответствует множество записей из В, например, у нескольких студентов занятия ведут несколько преподавателей).