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

• Разделение и изоляция данных
• Дублирование данных
• Зависимость от данных
• Несовместимость файлов
• Фиксированные запросы/быстрое увеличение количества приложений

Разделение и изоляция данных
Когда данные изолированы в отдельных файлах, доступ к ним весьма затруднителен. Например, для создания списка всех домов, отвечающих требованиям потенциальных арендаторов, предварительно нужно создать временный файл со списком арендаторов, желающих арендовать недвижимость типа "дом". Затем в файле PropertyForRent следует осуществить поиск объектов недвижимости типа "дом" с арендной платой ниже установленного арендатором максимума. Выполнять подобную обработку данных в файловых системах достаточно сложно. Для извлечения соответствующей поставленным условиям информации программист должен организовать синхронную обработку двух файлов. Трудности существенно возрастают, когда необходимо извлечь данные из большего количества файлов.
Дублирование данных
Из-за децентрализованной работы с данными, проводимой в каждом отделе независимо от других отделов, в файловой системе фактически допускается бесконтрольное дублирование данных, и это, в принципе, неизбежно.
Бесконтрольное дублирование данных нежелательно по следующим причинам.

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

Зависимость от данных
Как уже упоминалось выше, физическая структура и способ хранения записей файлов данных жестко зафиксированы в коде приложений. Это значит, что изменить существующую структуру данных достаточно сложно. Например, увеличение в файле PropertyForRent длины поля адреса с 40 до 41 символа кажется совершенно незначительным изменением его структуры, но для воплощения этого изменения потребуется, как минимум, создать одноразовую программу специального назначения, преобразующую уже существующий файл PropertyForRent в новый формат. Она должна выполнять следующие действия:

• открыть исходный файл PropertyForRent для чтения;
• открыть временный файл с новой структурой записи;
• считать запись из исходного файла, преобразовать данные в новый формат и записать их во временный файл. Эти действия следует выполнить для всех записей исходного файла;
• удалить исходный файл PropertyForRent;
• присвоить временному файлу имя PropertyForRent.

Помимо этого, все обращающиеся к файлу PropertyForRent программы
должны быть изменены с целью соответствия новой структуре файла. А таких программ может быть очень много. Следовательно, программист должен прежде всего выявить все программы, нуждающиеся в доработке, а затем их перепроверить и изменить. Отметим, что многие подлежащие изменению программы могут обращаться к файлу PropertyForRent, но при этом вообще не использовать поле адреса. Ясно, что выполнение всех этих действий требует больших затрат времени и может явиться причиной появления ошибок. Данная особенность файловых систем называется зависимостью программ от данных (program-data dependence).
Несовместимость форматов файлов
Поскольку структура файлов определяется кодом приложений, она также зависит от языка программирования этого приложения. Например, структура файла, созданного программой на языке COBOL, может значительно отличаться от структуры файла, создаваемого программой на языке С. Прямая несовместимость таких файлов затрудняет процесс их совместной обработки.
Например, предположим, что сотрудникам отдела контрактов требуется найти имена и адреса всех владельцев, недвижимость которых в настоящее время сдана в аренду. К сожалению, в отделе контрактов нет сведений о владельцах недвижимости, так как они хранятся только в отделе реализации. Однако в файлах отдела контрактов имеется поле propertyNo с номерами объектов недвижимости, которые можно использовать для поиска соответствующих номеров в файле PropertyForRent отдела реализации. Этот файл также содержит поле ownerNo с номерами владельцев, которые можно использовать для поиска сведений о владельцах в файле PrivateOwner. Допустим, что программа отдела контрактов создана на языке COBOL, а программа отдела реализации — на языке С.
Тогда с целью поиска соответствующих номеров объектов недвижимости в поле propertyNo в двух файлах PropertyForRent программисту потребуется создать программное обеспечение, предназначенное для преобразования этих полей в некоторый общий формат. Не вызывает сомнения, что этот процесс может оказаться весьма длительным и дорогим.
Фиксированные запросы/быстрое увеличение количества приложений
С точки зрения пользователя возможности файловых систем намного превосходят возможности ручных картотек. Соответственно возрастают и требования к реализации новых или модифицированных запросов. Однако файловые системы требуют больших затрат труда программиста, поскольку все необходимые запросы и отчеты должны быть созданы именно им. В результате события обычно развивались по одному из следующих двух сценариев. Во-первых, во многих организациях типы применяемых запросов и отчетов имели фиксированную форму, и не было никаких инструментов создания незапланированных или произвольных запросов как к самим данным, так и к сведениям о том, какие типы данных доступны.
Во-вторых, в других организациях наблюдалось быстрое увеличение количества файлов и приложений. В конечном счете наступал момент, когда сотрудники отдела обработки данных были просто не в состоянии справиться со всей работой с помощью имеющихся ресурсов. В этом случае нагрузка на сотрудников отдела настолько возрастала, что неизбежно наступал момент, когда программное обеспечение было неспособно адекватно отвечать запросам пользователей, эффективность его падала, а недостаточность документирования имела следствием дополнительное усложнение сопровождения программ. При этом часто игнорировались вопросы поддержки функционирования системы: не предусматривались меры по обеспечению безопасности или целостности данных; средства восстановления в случае сбоя аппаратного или программного обеспечения были крайне ограничены или вообще отсутствовали. Доступ к файлам часто ограничивался узким кругом пользователей, т.е. не предусматривалось их совместное использование даже сотрудниками одного и того же отдела.