db4o

Цитата со страницы «О нас»:

db4o is the open source object database that enables Java and .NET developers to store and retrieve any application object with only one line of code, eliminating the need to predefine or maintain a separate, rigid data model.

Разве Amazon SimpleDB не реляционален?

db4o, как упоминал Эрик, является Объектно-ориентированная система управления базами данных (OODBMS).

Есть объектно-ориентированные базы данных (например, Gemstore). Большая таблица Google и простое хранилище Амасона Я не уверен, как вы бы классифицировали, но оба основаны на сокращении карты.

Старые нереляционные базы данных:

Сетевая база данных

Иерархическая база данных

Оба в основном вышли из моды, когда стали возможны отношения.

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

Рассматриваемая нами нереляционная база данных, ориентированная на документы, называется Apache CouchDB.

Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API. Among other features, it provides robust, incremental replication with bi-directional conflict detection and resolution, and is queryable and indexable using a table-oriented view engine with JavaScript acting as the default view definition language.

Наш интерес заключался в предоставлении хранилища предпочтений пользователей с распределенным доступом, которое было бы невосприимчивым к изменениям формы, к которому мы могли бы сериализовать объекты предпочтений из Java и так же легко получить к ним доступ с помощью Javascript из клиентского приложения на основе XULRunner.

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

4. Навигационная. Включает дерево / иерархию и график / сеть.

Файловые системы, семантическая сеть, XML, объектные базы данных, CODASYL и многие другие подпадают под эту категорию.

Эти 4 почти все.

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

Существуют системы BASE (Базовая доступность, Мягкое состояние, Согласованность в конечном итоге), и они хорошо работают с простыми моделями данных, содержащими огромные объемы данных. BigTable от Google, Persevere от Dojo, Dynamo от Amazon, Cassandra от Facebook - вот некоторые примеры.

См. СВЯЗЬ

Световая база данных корреляции - это новая революционная нереляционная база данных. Система управления корреляционной базой данных (CDBMS) не зависит от модели данных и предназначена для эффективной обработки незапланированных, специальных запросов в среде аналитической системы. В отличие от систем управления реляционными базами данных или баз данных, ориентированных на столбцы, корреляционная база данных использует архитектуру хранилища на основе значений (VBS), в которой каждое уникальное значение данных сохраняется только один раз, а автоматически сгенерированная система индексирования поддерживает контекст для всех значений (данные 100% проиндексировано). Запросы выполняются с использованием естественного языка вместо SQL (NoSQL).

Узнайте больше на: www.datainnovationsgroup.com

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

Идея тройного хранилища состоит в том, чтобы хранить базу данных на основе графов, чьи корни модели данных находятся в RDF. С помощью RDF вы описываете узлы и ассоциации между узлами (другими словами, ребра). Данные организованы в тройки:

start node ----relation----> end node 

(в речи RDF: субъект - предикат -> объект). С помощью этой очень простой модели данных любую сеть данных можно представить, добавляя все больше и больше троек, при условии, что вы придаете смысл узлам и отношениям.

RDF является очень общим, и это модель данных на основе графов, хорошо подходящая для критериев поиска, ищущих все тройки с определенной комбинацией субъекта, предиката или объекта в любой комбинации. В конце концов, с помощью языка запросов под названием SPARQL вы также можете выполнять более сложные запросы, операция, которая сводится к поиску изоморфизма графа на графе, как с точки зрения топологии, так и с точки зрения значения вершины-ребра (мы увидим это в настоящее время). SPARQL позволяет выполнять только запросы SELECT (и аналогичные). Ни DELETE, ни INSERT, ни UPDATE. Информация, которую вы запрашиваете (например, конкретные узлы, которые вас интересуют), отображается в таблицу, которую вы получаете в результате своего запроса.

Сама по себе топология не имеет большого значения. Для этого был изобретен язык схем. На самом деле, несколько, и называть их языками схемы в некоторых случаях очень ограничивает. Самыми известными и используемыми сегодня являются RDF-Schema, OWL (Lite и Full), которые предшествуют устаревшему DAML + OIL. Суть этих языков в том, чтобы, сводя к минимуму, придать значение узлам (путем предоставления им типа, также описываемому как тройка) и отношениям (ребрам). Кроме того, вы можете определить «диапазон» и «домен» этих отношений или, иначе говоря, какой тип является начальным узлом, а какой тип конечным узлом: например, вы можете сказать, что свойство «numberOfWheels» может применяться только для подключения узла типа Vehicle к ненулевому целочисленному значению.

 ns:MyFiat --rdf:type--> ns:Vehicle
 ns:MyFiat --ns:numberOfWheels-> 4

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

ns:MyFiat --ns:numberOfWheels--> 4

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

ns:MyFiat --rdf:type--> ns:Vehicle

потому что в своей онтологии вы сказали, что только объекты типа Vehicle могут быть описаны свойством numberOfWheels.

И наоборот, вы можете использовать механизм вывода для проверки ваших данных на соответствие онтологии, чтобы отказаться от несовместимых данных (что-то вроде XML-схемы для XML). В этом случае вам понадобятся обе тройки, чтобы ваши данные были успешно приняты тройным хранилищем.

Дополнительными характеристиками тройных хранилищ являются формулы и контекстно-зависимое хранилище. Формулы - это утверждения (как обычно, троекратный объект-предикат субъекта), описывающие что-то гипотетическое. Я никогда не использовал формулы, поэтому не буду вдаваться в подробности того, чего не знаю. Осведомленность о контексте - это в основном подграфы: проблема с хранением троек в том, что вам нечего сказать, откуда они берутся. Предположим, у вас есть два дилера, которые указывают одинаковую цену на компонент. Один говорит, что цена 5,99, а другой 4,99. Если вы просто сохраните обе тройки в базе данных, теперь вы ничего не знаете о том, кто предоставил каждую информацию. Есть два способа решить эту проблему.

Один из них - овеществление. Реификация означает, что вы сохраняете дополнительные тройки для описания другой тройки. Это расточительно и превращает жизнь в ад, потому что вам нужно овладеть каждой сохраненной тройкой. Альтернатива - контекстная осведомленность. Наличие контекстно-зависимого хранилища Это похоже на возможность упаковать кучу троек в контейнер с меткой на нем (идентификатор контекста). Теперь вы можете использовать этот идентификатор как тему для дополнительных операторов, тем самым описывая группу троек в одном действии.