Навигационная база данных представляет собой тип базы данных , в которой записи или объекты находятся в основном, следуя ссылки от других объектов. Этот термин был популяризировал титул Чарльз Бахман 1973 «s премии Тьюринга бумаги, программист как навигатор . [1] В этой статье подчеркивается тот факт, что новые дисковые системы баз данных позволяют программисту выбирать произвольные навигационные маршруты, следуя отношениям от записи к записи, в отличие от ограничений более ранних систем с магнитной лентой и перфокартой, где доступ к данным был строго ограничен. последовательный.
Одной из первых навигационных баз данных была Integrated Data Store (IDS), разработанная Бахманом для General Electric в 1960-х годах. IDS стала основой модели базы данных CODASYL в 1969 году.
Хотя Бахман описал концепцию навигации в абстрактных терминах, идея навигационного доступа стала прочно ассоциироваться с процедурным дизайном языка манипулирования данными CODASYL . Например, в 1982 г. Цихрицис и Лочовский [2] заявляют, что «понятие валюты является центральным в концепции навигации». Под понятием валюты они относятся к идее, что программа поддерживает (явно или неявно) текущую позицию в любой последовательности записей, которые она обрабатывает, и что такие операции, как GET NEXT
и GET PRIOR
получение записей относительно этой текущей позиции, одновременно изменяя текущая позиция извлекаемой записи.
Таким образом, программирование навигационных баз данных стало рассматриваться как процедурное по своей сути ; и, более того, зависеть от поддержки неявного набора глобальных переменных ( индикаторов валют ), содержащих текущее состояние. Таким образом, этот подход рассматривался как диаметрально противоположный декларативному стилю программирования, используемому в реляционной модели . Декларативный характер реляционных языков, таких как SQL, предлагал лучшую производительность программистов и более высокий уровень независимости данных (то есть способность программ продолжать работать по мере развития структуры базы данных). В результате навигационные интерфейсы постепенно вытеснялись во время 1980-е годы декларативными языками запросов.
В течение 1990-х стало ясно, что для некоторых приложений, обрабатывающих сложные данные (например, пространственные базы данных и инженерные базы данных), реляционное исчисление имеет ограничения. В то время началась переоценка всего рынка баз данных, когда несколько компаний описали новые системы, используя маркетинговый термин NoSQL . Многие из этих систем представили языки манипулирования данными, которые, хотя и далеки от CODASYL DML с его индикаторами валют, можно рассматривать как реализацию «навигационного» видения Бахмана. Некоторые из этих языков являются процедурными; другие (например, XPath ) полностью декларативны. Ответвления концепции навигации, такие как база данных графов , нашли новое применение в современных рабочих нагрузках обработки транзакций .
Описание
Навигационный доступ традиционно ассоциируется с сетевой моделью и иерархической моделью в базе данных , и обычно описывает манипулирование данных API , в которых запись (или объекты) обрабатываются по одному за раз, итеративна. Однако основной характеристикой, описанной Бахманом, является поиск записей на основании их взаимосвязи с другими записями: так что интерфейс все еще может быть навигационным, если он имеет функции, ориентированные на наборы. [3] С этой точки зрения, основное различие между навигационными языков манипулирования данными и реляционных языков является использование явных именованных отношений , а не на основе стоимости присоединяется: for department with name="Sales", find all employees in set department-employees
против find employees, departments where employee.department-code = department.code and department.name="Sales"
.
Однако на практике большинство навигационных API-интерфейсов были процедурными: вышеуказанный запрос будет выполняться с использованием процедурной логики в соответствии со строками следующего псевдокода:
получить отдел с именем = 'Продажи'получить первого сотрудника в наборе отделов-сотрудниковдо конца сета делать { получить следующего сотрудника в наборе сотрудников отдела сотрудник процесса}
С этой точки зрения ключевое различие между навигационными API-интерфейсами и реляционной моделью (реализованной в реляционных базах данных ) заключается в том, что в реляционных API-интерфейсах используются «декларативные» методы или методы логического программирования , которые запрашивают систему, что нужно получить, в то время как навигационные API-интерфейсы инструктируют систему в последовательности шаги, как достичь требуемых записей.
Большинство критических замечаний по поводу навигационных API можно разделить на две категории:
- Удобство использования: код приложения быстро становится нечитаемым и трудным для отладки.
- Независимость данных: код приложения должен меняться всякий раз, когда изменяется структура данных
В течение многих лет основной защитой навигационных API была производительность. Системы баз данных, поддерживающие навигационные API, часто используют внутренние структуры хранения, содержащие физические ссылки или указатели от одной записи к другой. Хотя такие структуры могут обеспечивать очень эффективную навигацию, у них есть недостатки, поскольку становится трудно реорганизовать физическое размещение данных. Вполне возможно реализовать навигационные API-интерфейсы без отслеживания низкоуровневых указателей (в статье Бахмана предусматривается, что логические отношения будут реализованы так же, как в реляционных системах, с использованием первичных и внешних ключей), поэтому эти две идеи не следует объединять. Но без преимуществ низкоуровневых указателей в производительности навигационные API становится труднее оправдать.
Иерархические модели часто создают первичные ключи для записей, объединяя ключи, которые появляются на каждом уровне иерархии. Такие составные идентификаторы находятся в именах компьютерных файлов ( /usr/david/docs/index.txt
), в URI, в десятичной системе Дьюи и, если уж на то пошло, в почтовых адресах. Такой составной ключ можно рассматривать как представление пути навигации к записи; но в равной степени его можно рассматривать как простой первичный ключ, обеспечивающий ассоциативный доступ.
Когда в 1980-х годах реляционные системы приобрели известность, навигационные API-интерфейсы (и, в частности, процедурные API-интерфейсы) подверглись критике и потеряли популярность. Однако 1990-е принесли новую волну объектно-ориентированных баз данных, которые часто предоставляли как декларативные, так и процедурные интерфейсы. Одним из объяснений этого является то, что они часто использовались для представления структурированной информации (например, пространственных данных и инженерных данных), где доступ по своей сути рекурсивен: математика, лежащая в основе SQL (в частности, исчисление предикатов первого порядка), не имеет достаточной мощности для поддерживают рекурсивные запросы, даже такие простые, как транзитивное замыкание .
Текущий пример популярного навигационного API можно найти в объектной модели документа (DOM), часто используемой в веб-браузерах и тесно связанной с JavaScript . DOM - это, по сути, иерархическая база данных в памяти с API, который является как процедурным, так и навигационным. Напротив, к одним и тем же данным ( XML или HTML ) можно получить доступ с помощью XPath , который можно разделить на декларативные и навигационные: доступ к данным осуществляется по следующим отношениям, но вызывающая программа не выдает последовательность инструкций, которые необходимо выполнять по порядку. Такие языки, как SPARQL, используемые для извлечения связанных данных из семантической сети , также являются одновременно декларативными и навигационными.
Примеры
Смотрите также
Рекомендации
- ^ Бахман, Чарльз В. (1973). «Программист как навигатор» . Коммуникации ACM . Portal.acm.org. 16 (11): 653–658. DOI : 10.1145 / 355611.362534 . S2CID 18635540 . Проверено 1 октября 2012 .
- ^ Дионисий Ч. Цихрицис и Фредерик Х. Лочовский (1982). Модели данных . Прентис-Холл. п. 67 . ISBN 0-13-196428-3.
- ^ Блажевич, Яцек; Круликовски, Збышко; Морзи, Тадеуш (2003). Справочник по данным и управлению в информационных системах . Springer. п. 18. ISBN 3-540-43893-9.
Внешние ссылки
- DB-Engines Рейтинг навигационных СУБД по популярности, обновляемый по месяцам