db4o

Кавычка от "о" странице:

db4o является объектной базой данных с открытым исходным кодом, которая позволяет Java и разработчикам.NET сохранить и получить любой объект приложения только с одной строкой кода, избавляя от необходимости предопределить или поддержать отдельную, твердую модель данных.

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

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

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

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

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

Существуют основанные на объектах базы данных (Gemstore, например). Большая Таблица Google и Простое устройство хранения данных Amason, я не уверен, как Вы категоризировали бы, но оба - карта - уменьшают базирующийся.

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

Разве SimpleDB Amazon не является нереляционным?

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

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

Apache CouchDB является распределенной, отказоустойчивой и ориентированной на документ базой данных без схем, доступной через УСПОКОИТЕЛЬНОГО HTTP/JSON API. Среди других функций это предоставляет устойчивой, возрастающей репликации двунаправленное обнаружение конфликта и разрешение, и является queryable и индексируемым использованием табличного механизма представления с JavaScript, действующим как язык определения представления по умолчанию.

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

4. Навигационный. Включает Дерево/Иерархию и График/Сеть.

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

Те 4 - в значительной степени это.

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

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

См. ССЫЛКА

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

Идея тройного хранилища состоит в том, чтобы хранить базу данных на основе графов, чьи корни модели данных лежат в 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. Если вы просто сохраните обе тройки в базе данных, теперь вы ничего не знаете о том, кто предоставил каждую информацию. Есть два способа решить эту проблему.

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

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

Подробнее: www.datainnovationsgroup.com