В чём отличие иерархических, сетевых, реляционных и объектно-ориентированных баз данных?

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

Но поскольку иерархическая модель подходит для описания далеко не всех видов данных, начались проработки других моделей: сетевая модель - это расширение связи "один ко многим" до "многие ко многим" между родительскими и подчинёнными узлами, и реляционная модель - строгая математическая концепция, допускающая разные виды связей между сущностями и их отсутствие, включающая нормализацию данных, декларативное описание критериев целостности данных, и таким образом позволяющая строить высокопроизводительные движки БД и моделировать сложные домены. Как обычно, первой популярность приобрела сетевая модель, как наименее отличающаяся от иерархической, её пик пришёлся на 1970-е годы. А когда структуры данных ещё усложнились, тогда, наконец, разработчики оставили сетевой "колхоз" и взяли реляционную модель за основу.

ООБД - это попытки адаптировать модель данных БД к используемому языку программирования. С середины 1980-х годов все ахали и охали на тему объекто-ориентированного программирования (точнее, Страуструп-ориентированного), поэтому начали появляться публикации о соответствующих БД. Но потом, с одной стороны, в современных приложениях оформился курс на разделение логики и данных, а также на отказ от наследования, что позволяет упростить структуру данных приложения и облегчить её отображение на реляционную модель. С другой стороны, типовые ORM успели развиться до того, чтобы эффективно работать даже со сложными маппингами. Например, если в 2000-х годах использование Hibernate было признаком ПТУшного приложения, не содержащего критически важных функций, то сейчас его включают везде, где только можно. С третьей стороны, объект, который не требуется искать по отдельным полям, можно целиком хранить в БД в одном поле CLOB/BLOB или в noSQL БД (которая по сути является реализацией предельно упрощённой реляционной модели до ключ-BLOB, без связей между таблицами и с "колхозом" плохо проработанных функций поверх этого). Так что переусложнённые ООБД, не основанные на математической концепции, как и само ООП, закономерно оказались не у дел. Одни продукты ушли с рынка, другие переехали под расплывчатую вывеску noSQL и продолжают мутировать. Пик популярности ООБД - 1990-е годы.

Мда