Если структура данных оказывалась сложнее, чем традиционная иерархия, простота организации иерархической модели становилась ее недостатком. Например, в базе данных для хранения заказов один заказ мог участвовать в трех различных отношениях предок/потомок, связывающих заказ с клиентом, разместившим его, со служащим, принявшим заказ, и с заказанным товаром.
В связи с этим для таких приложений, как обработка заказов, была разработана новая, сетевая модель данных. Она являлась улучшенной иерархической моделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок. В сетевой модели такие отношения называются множествами.
С точки зрения программиста, доступ к сетевой базе данных был очень похож на доступ к иерархической базе данных. Прикладная программа могла:
- найти конкретную запись предка по ключу (например, номер клиента)
- перейти к первому потомку в конкретном множестве (первый заказ, размещенный клиентом)
- перейти в сторону от одного потомка к другому в конкретном множестве (следующий заказ, сделанный этим же клиентом)
- перейти вверх от потомка к его предку в другом множестве (служащий, принявший заказ)
И опять программисту приходилось искать информацию в базе, последовательно перебирая записи, однако, указывая при этом не только направление, но и требуемое отношение.
Подобно своим иерархическим предкам, сетевые базы данных были очень “жесткими”. Наборы отношений и структуру записей приходилось задавать наперед. Изменение структуры базы данных обычно означало перестройку последней.
Как иерархическая, так и сетевая базы данных были инструментами программистов. Чтобы получить ответ на запрос: “Какой товар наиболее часто заказывает компания Х? ”, программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.