В чем же проблема с иерархическими и сетевыми моделями баз данных?

Question

До E F Кодд опубликовал свою статью «Реляционная модель данных для крупных банков данных» в 1970 году, hierarchal и network были двумя выдающимися моделями базы данных.

Что именно не так с ними, что они не превалировали?

Answer 1

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

Я действительно работал над обоими видами в 80-х (Codasyl и Nomad/2) и был очень рад, когда SQL стал более широко доступным.

Answer 2

1. не простой способ создания отчетов
2. жестких схем
3. модель сети была слишком похожа на иерархическую структуру, так что это на самом деле не получить выгоды от использования модели сети. вместо того, чтобы иметь один родитель, как в иерархической модели, запись может иметь несколько родителей. поэтому все еще рассматривается в терминах отношений родителя/ребенка.

Что было хорошо в этих моделях - это производительность, и именно поэтому я считаю, что RDBMS становится доминирующим (в начале они выполняли очень плохо).

Если вы хотите углубиться в историю this интервью с Charles Bachman настоятельно рекомендуется читать! Он интересный человек, на самом деле он закодировал первый инструмент автоматического моделирования данных для РСУБД!

BTW, иерархические/сетевые базы данных по-прежнему используются по крайней мере в настройках мэйнфрейма.

Answer 3

Ответы до сих пор охватывают множество практических причин, по которым сетевые и иерархические модели были в конечном итоге смещены реляционной моделью (включая системы баз данных SQL). В статье Кодда 1970 года объясняется, почему требуется новая модель. Это замечательно. Действительно, до Кодда термин «модель данных» был практически неслыханным. Поэтому он придумал термины «иерархическая модель» и «сетевая модель», чтобы описать системы баз данных, которые были построены без какой-либо точной модели.

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

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

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

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

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

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

Во всех «реляционных СУБД», которые вы и я, вероятно, будем использовать, существует мост между использованием данных для идентификации данных и использованием указателей для поиска данных. Он называется индексом. Индекс связывает два элемента: индексный ключ (один или несколько столбцов из таблицы) и указатель (который определяет строку, содержащую индексный ключ). Я замалчиваю все подробности об индексах.

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

Это обзор.

Answer 4

Навигация. Иерархические и сетевые модели зависят от навигационных структур (так называемых указателей/ссылок/графиков) в базе данных. Поэтому их функциональность ограничена конструкцией этих структур. Напротив, реляционная модель «обеспечивает средство описания данных только с его естественной структурой, то есть без наложения дополнительной структуры для целей машинного представления». [1]

По иронии судьбы, текущий тренд «NOSQL» в базы данных также охватывают навигационные структуры, часто просматривая их (совершенно ошибочно, на мой взгляд) как хорошее решение для воспринимаемых ограничений баз данных SQL.

[1] «Реляционная модель данных большого Shared банков данных» Е. Ф. Кодда, 1970