В чем конкретно проблема иерархических и сетевых моделей баз данных? - PullRequest
4 голосов
/ 06 августа 2010

До того, как в 1970 г. Э. Ф. Кодд опубликовал свою статью "Реляционная модель данных для крупных совместно используемых банков данных", иерархическая и сеть были двумя выдающимися моделями базы данных.*

Что именно было с ними не так, что они не одержали победу?

Ответы [ 4 ]

5 голосов
/ 06 августа 2010

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

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

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

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

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

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

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

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

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

Это обзор.

5 голосов
/ 06 августа 2010

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

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

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

Что было хорошо в этих моделях, так это производительность, и именно это, я думаю, заставило СРБД занять так много времени, чтобы стать доминирующим (в начале они работали очень плохо).

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

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

0 голосов
/ 06 августа 2010

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

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

[1] «Реляционная модель больших общих банков данных»EF CODD, 1970

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...