Каков пример нереляционной базы данных? Где / как они используются?

База данных истории PI от OSIsoft не является реляционной. Это сделано только для архивации данных с отметкой времени. Он часто используется в отрасли, особенно в качестве серверной базы данных для всех этих «дашбордов».

В этом нет необходимости быть реляционным, поскольку нет соединений.

• Плоский файл
  • CSV или другие данные с разделителями
  • электронные таблицы
  • / etc / passwd
  • почтовые файлы mbox
• Иерархический
  • Реестр Windows
  • Subversion с использованием файловой системы FSFS вместо Berkley DB

Я бы подумал, что база данных с плоскими файлами в Excel не является реляционной и используется довольно большим количеством людей.

На самом деле это просто таблица базы данных, которую нельзя объединить с другими таблицами.

Рассматриваемая нами нереляционная база данных, ориентированная на документы, называется 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.

Объектно-ориентированные базы данных - один из интересных типов нереляционных баз данных.

Торговый сектор иногда использует базы данных OO, поскольку каждая сделка / контракт может выглядеть как другие в этой категории, но также иметь уникальные атрибуты. ОЧЕНЬ сложно представить это в относительном смысле.

Любой файл или группа файлов, которые содержат данные, но не выражают отношения внутри этих данных, являются нереляционной базой данных.

Хранилище данных Google App Engine:

The App Engine datastore is not a relational database. While the datastore interface has many of the same features of traditional databases, the datastore's unique characteristics imply a different way of designing and managing data to take advantage of the ability to scale automatically.

dBase. Хотя он и продавался как таковой, он не отвечает требованиям.

В качестве объектно-ориентированной базы данных на ум приходит Intersystems Caché. На этом построены некоторые медицинские и библиотечные системы.

RRDtool предназначен для хранения и агрегирования данных журнала. Вы настраиваете интервал выборки и вводите в него данные, а затем он возвращает результаты, основанные на времени. Он оптимизирован для хранения фиксированного размера и через некоторое время начинает агрегировать прошлые результаты. Например, предположим, что у вас есть циклическая база данных с 5-минутным интервалом времени. Даже если вы отправляете ему данные о температуре один раз в секунду, он все равно сохраняет результаты только с 5-минутным шагом. Через неделю он усредняет эти результаты в почасовые значения. Через месяц ежечасные результаты усредняются в дневные числа и т. д.

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

Размерные базы данных - отличные примеры нереляционных баз данных. Они очень часто используются для «Панелей бизнес-аналитики» / «Бизнес-аналитики» для KPI и других типов агрегированных или статистических данных. Обычно они заполняются из реляционных баз данных и могут обеспечить лучшую производительность в определенных ситуациях.

http://en.wikipedia.org/wiki/Dimensional_database

Все базы данных изначально были нереляционными, и только с появлением DB2 и Oracle в середине 1980-х годов они стали общими. До этого в большинстве баз данных использовались либо плоские файлы, либо иерархические.

Плоские файлы по своей сути утомительны, но иерархическая база данных - гораздо меньше, особенно потому, что DB2 была фактически реализована поверх иерархической реализации (а именно VSAM) в первом экземпляре. Я считаю, что VSAM все еще используется в мэйнфреймах и имеет большое значение.

DB / 1 (настолько непонятно, что я даже не могу найти ссылку на википедию) была базой данных прайм-тайм IBM-предшественником для DB2 (отсюда и название). Это было иерархически - в основном у вас был файл, который состоял из любого числа или «корневых» записей, обычно доступных напрямую с помощью ключа. Каждая корневая запись может иметь любое количество дочерних записей, каждая из которых, в свою очередь, может иметь своих собственных дочерних элементов. В результате получается индексный файл или корневые записи, каждый из которых является вершиной потенциальной древовидной структуры. Доступ к дочерним записям может быть сложным - были ограничения прямого доступа, поэтому обычно вам приходилось обходить дерево в поисках нужной записи. «База данных» может содержать любое количество этих файлов, обычно связанных ключами.

Это имело серьезные недостатки - не в последнюю очередь то, что для выполнения чего-либо требовалось написание полной программы - по сути, эквивалент дневной работы для того, что мы теперь можем сделать в SQL за несколько минут. Однако он действительно набирал очки по скорости выполнения: в те дни мэйнфреймы обладали вычислительной мощностью вашего iPhone (хотя и оптимизировали для ввода-вывода данных), а плохие запросы DB2 могли убить многомиллионную установку. Это никогда не было проблемой с DB / 1, и в мире, где программисты были дешевле, чем процессорное время, это имело смысл.

Любая база данных, которая утверждает, что является «базой данных в стиле Беркли» или «базой данных« ключ / значение », не является реляционной.

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

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

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

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

1. Базы данных XML, например xindice
2. Объектные базы данных, например db4o

Имейте в виду, что концепция реляционных баз данных весьма спорна. Такие пуристы, как К. Дж. Дэйт, утверждают, что многие широко используемые базы данных (такие как Oracle и SQL Server) недостаточно соответствуют реляционной модели, чтобы ее можно было назвать «реляционной».

Для dbms на основе графика у вас есть neo4j

Для иерархической БДМ у вас есть любая стандартная файловая система или с "схемой", поддерживающей любую реализацию LDAP.

eXist-db - это база данных xml, которая существует уже давно. Это особенно полезно для xquery над тоннами XML-документов.

1. В моей компании, www.smartsgroup.com, у нас есть проприетарный механизм базы данных, который мы называем «базой данных журнала транзакций». Он построен на плоских файлах, каждый файл содержит последовательность «событий» или «сообщений» в двоичном формате, а также различные индексы этих данных и алгоритмы для воспроизведения состояния книги заказов фондовой биржи. Он оптимизирован для последовательных обновлений и последовательного доступа.

2. В научных приложениях также часто используются проприетарные механизмы баз данных, а не СУБД. Я также работал в компании, у которой есть самая большая в мире база данных записей ЭЭГ мозга: www.brainresource.com. Здесь мы используем базу данных с плоскими файлами, и она нам хорошо сработала.

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

По общему признанию неясная, но интересная альтернатива упомянутым здесь типам баз данных - это ассоциативная база данных, например Sentences, от Технология LazySoft. Существует бесплатная персональная версия, которую вы можете скачать и попробовать самостоятельно. Enterprise Edition также бесплатен, но требует запроса в компанию.

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

• Том брат Лаура
• Сан-Франциско расположен в Калифорния
• Майк имеет кредитный лимит $ 10 000

Предложение может быть предметом или объектом другого предложения:

• (Автобус 570 прибывает 8:15) на Воскресенье
• Мэри говорит (пирог был испечен Уильям)

Итак, все можно свести к сущности и ассоциации.

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

«Ассоциативная модель данных» - это книга, доступная в формате PDF Саймоном Уильямсом, одним из создателей Sentences.

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

Некоторые системы OLAP поддерживаются многомерными базами данных (MOLAP), которые часто используются в финансовом анализе. Они предоставляют интерактивные клиенты, которые позволяют перемещаться по данным на разных уровнях агрегирования.

Есть много ответов, но все они попадают в одну из двух основных категорий:

1. Навигационная. Включает базы данных Tree / Hierarchy и Graph.

2. Базы данных, которые нарушают первую нормальную форму (несколько значений). Включает базы данных Pick и Lotus Notes и его дочерние продукты, такие как CouchDB.

Обновлено: И, конечно, хранилища ключей / значений, такие как BDB, не являются реляционными, но это само собой разумеется, не так ли? Я имею в виду, что это просто хранилища ключей и значений.

Нереляционные базы данных просто не соответствуют требованиям Кодда. Intersystems Caché полностью переписывает / переделывает базу данных старой операционной системы Pick. Судя по тому немногому, что я прочитал о Caché, кажется, что это хороший редизайн. Он позволяет программам .net обращаться к базе данных точно так же, как это было бы с SQL. Caché запускает программы Pick OS без каких-либо изменений. Импортируя файлы Pick в Caché, вы по-прежнему можете запускать с ним свои старые приложения с зеленым экраном, а также писать новые программы с использованием .net, чтобы вы могли перейти на приложения Windows, не отказываясь от многолетней разработки данных, в которую вы уже вложили. Вот некоторая предыстория модели Pick DB. База данных Pick использует записи и поля полностью переменной длины. Все таблицы имеют один уникальный ключ и доступны без чтения индекса. Пик разработал систему для использования алгоритма хеширования, который считывает элемент с диска, как правило, при первом физическом чтении (при условии, что обслуживание системы было выполнено правильно). Поля в Pick не типизированы. Все данные хранятся в виде строки, и кастинг остается на усмотрение программиста. Нулевые значения сохраняются как пустая строка, поэтому нуль не занимает дисковое пространство, как это происходит в SQL. Внешние ключи не требуются. В «реляционном мире» администратор баз данных должен создать и таблицу заголовков заказа, и таблицу элементов строки заказа. В «Модели выбора» есть одна таблица. Например, «Дата заказа» - это поле, в котором будет храниться количество дней с «13 декабря 1967 года» (ОС выбора данных была включена впервые). У программистов Pick не было проблем с Y2k. Второй столбец - это номер клиента. Большая разница в том, что когда вы попадаете в столбец «Номер продукта», он будет «Многозначным» (Несоответствие Кодду). Другими словами, база данных может обрабатывать 1-32000 номеров продуктов в этом столбце. Другие столбцы, такие как «Заказанное количество», будут находиться в контролирующей / зависимой связи с номером продукта и также будут многозначными. Когда вы дойдете до «Отгруженного количества», Pick перейдет в третье измерение и будет иметь поле с дополнительными значениями. У вас будет столбец «Номер отгрузки», который будет содержать несколько значений по отдельным позициям и несколько значений, содержащий количество отгрузки для этой строки для этого номера отгрузки. Нет необходимости во внутренних соединениях. Все данные для этого Заказа хранятся в одной таблице и в одной записи. Никаких сиротских ссор! Во-вторых, определение данных немного другое. Наши словари могут содержать определения для данных, которых нет в этой таблице или которые обрабатываются. Вот несколько примеров: Имя клиента. Это будет определено как «Использовать столбец номера клиента и вернуть поле имени из таблицы клиентов». Другой пример: расширение отдельной позиции может быть определено как вычисление количества * цены / PricePer. Кажется, я где-то читал, что Caché утверждает, что у него более 100 000 установок.

Еще два типа баз данных, которые еще не появились:

1. Репозитории контента - это базы данных, предназначенные для контента (то есть файлов, документов, изображений и т. д.). Обычно они имеют дополнительные конструкции, такие как иерархический способ просмотра контента, поиск, преобразование между различными форматами, управление версиями и многое другое. Примеры - Alfresco, Documentum, JackRabbit, Day, OpenText, многие другие поставщики ECM.

2. Каталоги, то есть Active Directory или каталоги LDAP. Это базы данных, разработанные для сценариев с низкой скоростью записи / высокой скоростью чтения и сильно распределенными по соединениям с большими географическими расстояниями и высокой задержкой. Хотя в основном они используются для аутентификации / авторизации, они не обязательно должны быть, если ваш вариант использования соответствует требованиям.

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