лекции Войнов

3.4.2. Базы данных и файловые системы

Рассмотрим подробнее отличия баз данных и файловых систем на конкретном примере. Предположим, в АИС необходимо реализовать учет сотрудников. Система должна выполнять следующие действия: выдавать списки сотрудников по отделам, поддерживать возможность перевода сотрудника из одного отдела в другой, приема на работу новых сотрудников и увольнения работающих. Для каждого отдела должна поддерживаться возможность получения имени руководителя этого отдела, общей численности отдела, общей суммы выплаченной в последний раз зарплаты и т.д.

Для каждого сотрудника должна быть предусмотрена возможность выдачи номера удостоверения по полному имени сотрудника, выдачи полного имени по номеру удостоверения, получения информации о текущем соответствии занимаемой должности сотрудника и о размере его зарплаты.

Каким образом поставленная задача может быть решена в файловой системе? Рассмотрим вариант ее решения путем расширения базовых возможностей файловой

системы за счет специальной библиотеки функций. Вся информация о сотрудниках будет храниться в одном файле. Поскольку минимальной информационной единицей в данном случае является сотрудник, естественно потребовать, чтобы в этом файл содержалась одна запись для каждого сотрудника. Какие поля должна содержать такая запись? Полное имя сотрудника (СОТР_ИМЯ), номер его удостоверения (СОТР_НОМЕР), информацию о его соответствии занимаемой должности (для простоты: «да» или «нет») (СОТР_СТАТ), размер зарплаты (СОТР_ЗАРП), номер отдела (СОТР_ОТД_НОМЕР). Поскольку используется только один файл, запись должна содержать также имя руководителя отдела (СОТР_ОТД_РУК).

Функции информационной системы требуют, чтобы обеспечивалась возможность доступа к этому файлу по уникальным ключам (т.е. недублируемым разных записях признакам) СОТР_ИМЯ и СОТР НОМЕР. Кроме того, должна обеспечиваться возможность выбора всех записей с общем значением СОТР_ОТД_НОМЕР, то есть доступ по неуникальному ключу. Дня того, чтобы получить численность отдела или общий размер зарплаты, каждый раз при выполнении такой функции информационная система должна будет выбрать все записи о сотрудниках отдела и посчитать соответствующие общие значения.

Таким образом, даже для такой простой системы ее реализация на базе файловой системы, во-первых, требует создания специальной надстройки (прикладной программы) для многоключевого доступа к файлам, во-вторых, вызывает требование избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя), а также выполнения массовой выборки и вычислений для получения суммарной информации об отделах. Кроме того, если в ходе эксплуатации системы возникнет необходимость выдавать списки сотрудников, получающих заданную зарплату, то придется либо полностью просматривать файл, либо реструктуризовать его, объявив ключевым поле СОТР_ЗАРП.

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

Прежде всего, система должна теперь знать, что она работает с двумя информационно связанными файлами (это шаг в сторону схемы базы данных), должна знать структуру и смысл каждого поля (например, что СОТР_ОТД_НОМЕР в файле СОТРУДНИКИ и ОТД_НОМЕР в файле ОТДЕЛЫ означают одно и то же), а также понимать, что в ряде случаев изменение информации в одном файле должно автоматически вызывать модификацию во втором файле, чтобы их общее содержимое было согласованным. Например, если на работу принимается новый сотрудник, то необходимо добавить запись в файл СОТРУДНИКИ, а также соответствующим образом изменить поля ОТД_ЗАРП и ОТД_РАЗМЕР в записи файла ОТДЕЛЫ, описывающей отдел этого сотрудника.

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

Но это еще не все, что обычно требуется от СУБД. Во-первых, даже в рассмотренном примере неудобно реализовывать такие запросы как «выдать общую численность отдела, в котором работает Петр Иванович Сидоров». Было бы гораздо проще, если бы СУБД позволяла сформулировать такой запрос на близком пользователям языке. Такие языки называются языками запросов к базам данных.

Например, на специальном языке SQL (Structured Query Language - язык структурированных запросов) этот запрос можно было бы выразить в форме:

SELЕСТ ОТД_РАЗМЕР

FRОМ СОТРУДНИКИ, ОТДЕЛЫ

WHERE COTP_ИМЯ = «ПЕТР ИВАНОВИЧ СИДОРОВ»

АND СОТР_ОТД_НОМЕР = ОТД_НОМЕР

Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос. Среди ее метаданных будет содержаться информация о том, что поле СОТР_ИМЯ является ключевым для файла СОТРУДНИКИ, а ОТД_НОМЕР - для файла ОТДЕЛЫ, и система сама воспользуется этим. Если же возникнет потребность в получении списка сотрудников, не соответствующих занимаемой должности, то достаточно предъявить системе запрос

SELЕСТ СОТР _ИМЯ, СОТР_НОМЕР

FRОМ СОТРУДНИКИ

WHERE СОТР_СТАТ = «НЕТ»,

и система сама выполнит необходимый полный просмотр файла СОТРУДНИКИ, поскольку поле СОТР_СТАТ не является ключевым.

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

Наконец, желательно обеспечить параллельную (например, многотерминальную) работу с базой данных сотрудников. Если опираться только на использование файлов, то для обеспечения корректности на все время модификации любого из двух файлов доступ других пользователей к этому файлу будет блокирован (вспомните возможности файловых систем для синхронизации параллельного

доступа). Таким образом, зачисление на работу Петра Ивановича Сидорова существенно затормозит получение информации о сотруднике Иване Сидоровиче Петрове, даже если они будут работать в разных отделах. Настоящие СУБД обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным.

Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем.

Содержание