Вступление
Модель данных - это способ представления некоторых данных. Данные можно представить на разных уровнях, поэтому между собой модели данных образуют иерархию, когда одна модель данных выражается через другую на языке более низкого уровня. Например:
Выражение процесса в окружающем мире через некоторые структуры данных, а действие с ними через API. Это самый высокий уровень.
При необходимости сохранять эти данные можно выбрать текстовый вид, например в виде json или xml.
Способ внутреннего представления json или xml в БД (на уровне последовательности байт), благодаря чему становятся возможными операции с этими данными, такие как поиск, вставка, обновление, удаление части данных.
Выражение байт в терминах эл. тока. Аппаратный уровень.
Таким образом, верхний слой инкапсулирует сложность нижестоящего слоя.
Уровень 1 можно представить для хранения данных через 3 модели данных:
- Документоориентированная модель (иерархическая)
- Реляционная
- Графовая
Документоориентированная хорошо подходит для хранения иерархических данных со связями 1 ко многим. Однако связь многие ко многим и многие к одному с ее помощью нельзя реализовать. В соответствие с этой моделью данные представляются в виде единого документа. Некоторые из NoSQL баз данных являются представителями этой модели. Получили широкое распространение в 2010-х годах. Данные не имеют четкой структуры.
Плюсы - можно получить за раз все части документа, обеспечивают лучшую локальность данных, лучшую пропускную способность по записи, лучше подходят для выражения некоторых моделей данных (отсюда менее лаконичные запросы) и легко масштабируются
Минусы - в память грузится весь документ. И меняется он тоже весь, что затратно по времени. Реализации этой модели чаще не дают гарантий, которые дает реляционная модель.
Пример - хранения документов в виде json в MongoDB.
Реляционная модель - самая универсальная из трех.
Плюсы: поддерживает все виды соединений и могут представлять иерархические и графовые модели данных (через таблица с ребрами и вершинами и рекурсивные запросы через common table expressions). Также современные реляционные БД позволяют хранить неструктурированные документы json и xml и производить с ними манипуляции.
Минусы: запросы получаются громоздкими, а сами данные организованы сложно для понимания. Пример - PostgreSQL c языком SQL.
Графовая модель является самой узкоспециализированной. Подходит для случаев, когда потенциально любые данные могут быть взаимосвязаны. Для этого вершины еще могут хранить тип сущности. Например, есть пользователь и его место жительства. Пользователь связан с городом. Город связан с регионом. Регион со страной. И все этой разные типы сущностей.
Представляется в виде вершин (сущности) и ребер (связи).
Вершины имеют:
идентификатор
множество ид входящих ребер
множество ид исходящих ребер
метаинформация в виде пар ключ-значение (json)
Ребра имеют:
ид вершины-начала
ид вершины-конца
идентификатор
метаинформация в виде пар ключ-значение (json)
Данные не имеют четкой структуры. Пример - Neo4j с языком запросов Cypher.
Особенность языков запросов к хранилищам
Если рассмотреть языки запросов, которые используют реализации этих трем моделей, до обнаружим, что все они декларативные, когда мы указывает результат, к которому хотим прийти, а вся логика по достижению этого результата определяется оптимизатором.
Top comments (0)