Потребности информационных систем

Потребности информационных систем. Однако ситуация коренным образом отличается для упоминавшихся в начале лекции информационных систем.

Эти системы главным образом ориентированы на хранение, выбор и модификацию постоянно существующей информации.

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

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

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

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

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

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

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

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

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

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

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

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

Но это еще не все, что обычно требуют от СУБД. Во-первых, даже в нашем примере неудобно реализовывать такие запросы как выдать общую численность отдела, в котором работает Петр Иванович Сидоров. Было бы гораздо проще, если бы СУБД позволяла сформулировать такой запрос на близком пользователям языке. Такие языки называются языками запросов к базам данных. Например, на языке SQL наш запрос можно было бы выразить в форме SELECT ОТД РАЗМЕР FROM СОТРУДНИКИ, ОТДЕЛЫ WHERE СОТР ИМЯ ПЕТР ИВАНОВИЧ СИДОРОВ AND СОТР ОТД НОМЕР ОТД НОМЕР Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос.

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

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

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

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

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