Первые технологии, или немного истории

Путь развития БД - это путь все большего и большего отстранения программного обеспечения от физических структур данных.

До появления БД информация хранилась в отдельных файлах. Самые первые системы управления файлами позволяли программистам создавать, записывать, обновлять и читать эти файлы. Файловая система имеет органический недостаток: программы должны точно знать , где расположены данные. Как следствие - для определения адресов в развитых системах хранения данных необходимо применение сложных, трудно оптимизируемых и модифицируемых алгоритмов.

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

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

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