Развитие баз данных — различия между версиями

Материал из Викиконспекты
Перейти к: навигация, поиск
(Достоинства)
м (rollbackEdits.php mass rollback)
 
(не показано 87 промежуточных версий 4 участников)
Строка 1: Строка 1:
 
== Простые и структурированные файлы ==
 
== Простые и структурированные файлы ==
 
=== Модель данных простого файла ===
 
=== Модель данных простого файла ===
 +
Самая простая форма организации данных в базе, соответственно, была создана одной из первых. Из-за своей простоты имеет множество недостатков, однако до сих пор используется во многих областях.
 
==== Структура ====
 
==== Структура ====
 +
В структуре содержится минимально необходимое количество информации о данных, из-за чего отсутствует возможность верификации данных при чтении.
 
*Заголовок (названия столбцов)
 
*Заголовок (названия столбцов)
 
*Данные (просто текст)
 
*Данные (просто текст)
 +
 
==== Пример ====
 
==== Пример ====
 +
Сверху располагаются названия столбцов, разделенные запятыми. После чего на отдельных строках идут записи, также разделенные запятыми.
 +
 
  ФИО,Предмет,Оценка
 
  ФИО,Предмет,Оценка
 
  Иванов И.И.,Java,4
 
  Иванов И.И.,Java,4
Строка 10: Строка 15:
 
  Петров П.П.,Java,5
 
  Петров П.П.,Java,5
 
  Петров П.П.,Базы данных,4
 
  Петров П.П.,Базы данных,4
 +
 
=== Модель данных структурированного файла ===
 
=== Модель данных структурированного файла ===
 +
Важным достоинством структурированного файла является возможность быстро находить строчку по номеру (так как нам известен фиксированный размер строки, мы можем посчитать смещение).
 
==== Структура ====
 
==== Структура ====
 +
Теперь в информацию добавлены записи о типе данных и о их размере, такми образом мы получаем больше возможностей для верификации при чтении данных. Так же здесь появляется смысл хранить номера строк для быстрого поиска в данных.
 
*Заголовок (названия столбцов, типы и длины)
 
*Заголовок (названия столбцов, типы и длины)
 
*Данные (записи одинаковой структуры)
 
*Данные (записи одинаковой структуры)
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь к строке, содержащей заголовки, добавляется дополнительная строка с типами и длинами. В данном формате цифра обозначает количество символов для этого поля.
 
  ФИО          Предмет    Оценка
 
  ФИО          Предмет    Оценка
 
  String, 14    String, 12  Number, 1
 
  String, 14    String, 12  Number, 1
Строка 21: Строка 31:
 
  Петров П.П.  Java          5
 
  Петров П.П.  Java          5
 
  Петров П.П.  Базы данных  4
 
  Петров П.П.  Базы данных  4
 +
 
=== Достоинства ===
 
=== Достоинства ===
* Простота чтения
+
* Простота чтения (так как данные можно просто читать построчно)
  
 
=== Недостатки ===
 
=== Недостатки ===
* Сложность поиска
+
* Сложность поиска (прямо следует из достоинства, так как в случае простого файла записи надо читать построчно, а в случае структурированного быстро мы находим только запись по номеру)
 
* Сложность обработки (в каждом месте для этого нужен будет свой код)
 
* Сложность обработки (в каждом месте для этого нужен будет свой код)
 
* Сложность хранения данных разны типов (например, для дат не понятно, в каком порядке идут данные)
 
* Сложность хранения данных разны типов (например, для дат не понятно, в каком порядке идут данные)
Строка 34: Строка 45:
 
* dBase
 
* dBase
 
* Excel / LibreOffice Calc
 
* Excel / LibreOffice Calc
 +
 
== Файловые системы ==
 
== Файловые системы ==
 
=== Файловая модель данных ===
 
=== Файловая модель данных ===
 +
Заметим, что поиск в файлах оказывается на практике слишком долгим. Однако, у нас имеются файловые системы, таким образом появляется идея переложить задачу поиска на них. Простейший способ структурированной организации данных. Характеризуется множеством не связанных между собой независимых файлов, состоящих из однотипных записей с одноуровневой структурой.
 
==== Представление данных ====
 
==== Представление данных ====
* Файл – одна запись
+
Имеем структуру из каталогов и файлов, лежащих внутри. В файлы можем заносить не только сами данные, но и некоторые ограничения на них.
 +
* Файл – одна запись (одноуровневая структура)
 
* Каталоги – подчиненные записи
 
* Каталоги – подчиненные записи
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь через символ / обозначено разделение на подкаталоги, у которых внутри лежат файлы с некоторыми конкретными для каждого случая данными. Данные в файле так же могут быть структурированными.
 
* Иванов И.И./Данные – ФИО, адрес, etc
 
* Иванов И.И./Данные – ФИО, адрес, etc
 
* Иванов И.И./Оценки/Java – 4
 
* Иванов И.И./Оценки/Java – 4
Строка 46: Строка 62:
 
* Иванов П. П./Оценки/Java – 5
 
* Иванов П. П./Оценки/Java – 5
 
* Петров П. П./Оценки/Базы данных – 4
 
* Петров П. П./Оценки/Базы данных – 4
 +
 
=== Достоинства ===
 
=== Достоинства ===
* Структурирование данных
+
* Структурирование данных (у нас есть опция хранения в файлах дополнительной информации о данных)
* Простота реализации
+
* Простота реализации (мы используем для реализации готовую файловую систему)
 +
 
 
=== Недостатки ===
 
=== Недостатки ===
 
* Сложно извлекать требуемые данные (в примере сложно посчитать среднюю оценку по предмету)
 
* Сложно извлекать требуемые данные (в примере сложно посчитать среднюю оценку по предмету)
 
* Нет проверки целостности (но можно, например, добавить проверку уникальности)
 
* Нет проверки целостности (но можно, например, добавить проверку уникальности)
* Большое количество файлов (не все файловые системы такое потянут)
+
* Большое количество файлов (не все файловые системы такое потянут с приемлимой производительностью)
  
 
=== Реализации ===
 
=== Реализации ===
 
* FATx, ExtX, NTFS, APFS
 
* FATx, ExtX, NTFS, APFS
 
* DOM
 
* DOM
 +
 
== Иерархические базы данных ==
 
== Иерархические базы данных ==
 
=== Иерархическая модель данных ===
 
=== Иерархическая модель данных ===
Иерархия это полезно, но складывать это в файловую систему не очень эффективно.
+
Заметим, что работа файловых систем с большим количеством файлов оказывается на практике слишком дорогой. Тогда появляется идея построить иерархию самостоятельно. Такая модель является совокупностью взаимосвязанных объектов, cвязь двух объектов отражает их подчиненность. Иерархия это полезно, но складывать это в файловую систему не очень эффективно.
 
Предложена и реализована IBM в 1966.
 
Предложена и реализована IBM в 1966.
 
==== Представление данных ====
 
==== Представление данных ====
 +
Теперь мы храним дерево записей, при этом для каждой записи мы знаем ее тип и структуру. Таким образом исчезает проблема с ошибками в типах хранящихся данных. Так же для каждой записи имеется произвольное количество подчиненных записей (детей).
 
* Дерево записей
 
* Дерево записей
 
* Отношения родитель – ребенок (как каталоги и подкаталоги)
 
* Отношения родитель – ребенок (как каталоги и подкаталоги)
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь в рамки обведены узлы дерева, где мы храним сами данные и их тип, а стрелочками обозначены отношения родитель-ребенок.
 +
 +
 
[[Файл:Intro hierarch.png|400px]]
 
[[Файл:Intro hierarch.png|400px]]
  
 
=== Достоинства ===
 
=== Достоинства ===
* Проверка целостности записей и отношений (также можем разрешать добавлять дубликаты, где необходимо)
+
* Проверка целостности записей и отношений (можем проверять отдельные поля записей при сохранении, записи целиком, описанные в структуре отношения, также можем разрешать добавлять дубликаты, где необходимо)
* Последовательное расположение записей
+
* Последовательное расположение записей (таким образом мы оптимизируем последовательный доступ к данным, что оптимизирует некоторые запросы)
 
* Эффективность реализации (за счет группировки данных одного типа)
 
* Эффективность реализации (за счет группировки данных одного типа)
  
 
=== Недостатки ===
 
=== Недостатки ===
* Представление только древовидных данных
+
* Представление только древовидных данных (например отношение многие ко многим требует от нашей модели обратного ''ссылок'', которые невозможно обеспечить в древовидной структуре)
 
* Существенно меняющееся время запроса в отношении многие-ко-многим в зависимости от того, кто выше в иерархии. Можно хранить две версии, однако возникает проблема с их согласованием, то есть в этот момент мы начинаем допускать некорректные данные.
 
* Существенно меняющееся время запроса в отношении многие-ко-многим в зависимости от того, кто выше в иерархии. Можно хранить две версии, однако возникает проблема с их согласованием, то есть в этот момент мы начинаем допускать некорректные данные.
  
Строка 82: Строка 106:
 
== Сетевые базы данных ==
 
== Сетевые базы данных ==
 
=== Сетевая модель данных ===
 
=== Сетевая модель данных ===
Нет единой строгой иерархии, могут существовать дополнительные.
+
Отсутствие отношения многие ко многим очень сильно затрудняет реализацию разумных запросов в иерархической модели даных. Для решения этой проблемы была предложена сетевая модель данных. Эта модель также является совокупностью взаимосвязанных объектов, однако здесь нет единой строгой иерархии, то есть могут существовать дополнительные с более низкой эффективностью поиска. Таким образом сетевые модели данных по сравнению с иерархическими являются более универсальными.
 
Предложена CODASYL в 1969.
 
Предложена CODASYL в 1969.
 
====Представление данных====
 
====Представление данных====
 +
Мы отказываемся от дерева записей, ослабляя требования до ориентированного графа. Таким образом мы допускаем наличие у сущности нескольких владельцев и отношение владелец - запись становится отношением многие ко многим.
 
* Ориентированный граф записей
 
* Ориентированный граф записей
 
* Отношения владелец – запись
 
* Отношения владелец – запись
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь в рамки так же обведены узлы ориентированного графа, где мы храним сами данные и их тип. Теперь черными стрелочками обозначены отношения родитель-ребенок основной иерархии, а синие обозначают дополнительные отношения.
 +
 +
 
[[Файл:Intro network.png|400px]]
 
[[Файл:Intro network.png|400px]]
  
 
=== Достоинства ===
 
=== Достоинства ===
* Представление всех типов связей
+
* Представление всех типов связей (так как нам теперь доступна связь многие ко многим)
* Возможность описания структуры
+
* Возможность описания структуры (аналогично иерархической модели данных)
* Эффективность реализации (сильно меняется от основной иерархии к дополнительной)
+
* Эффективность реализации (сильно меняется от основной иерархии к дополнительной из-за физического хранения данных только в одной последовательности)
  
 
=== Недостатки ===
 
=== Недостатки ===
* Сложность реализации
+
* Сложность реализации (так как теперь нам нужно хранить дополнительные внешние указатели, что вызывает сложности при перемещении записей)
* Жесткое ограничение структуры
+
* Жесткое ограничение структуры (нужно заранее продумывать необходимые дополнительные иерархии)
 +
 
 
=== Реализации ===
 
=== Реализации ===
 
* Integrated Data Store
 
* Integrated Data Store
Строка 104: Строка 134:
 
== Реляционные базы данных ==
 
== Реляционные базы данных ==
 
=== Реляционная модель данных ===
 
=== Реляционная модель данных ===
Предложена Э. Ф. Коддом в 1969.
+
Заранее прописывать связи оказывается на практике довольно неудобно, поэтому вместе с сетевой моделью появляется реляционная модель данных, где связи задаются непосредственно в запросах (при этом вы можете их описать). Это самая популярная на данный момент модель данных. Отличается от предыдущих моделей заданием связей непосредственно в запросах, а также наличием математической модели, позволяющей оптимизировать эти запросы.  Предложена Э. Ф. Коддом в 1969.
 
====Структура====
 
====Структура====
 +
Теперь мы храним данные в различных табличках, умея проверять целостность cвязей благодаря этому. Так же связи теперь могут задаваться в запросах.
 
* Данные хранятся в таблицах
 
* Данные хранятся в таблицах
 
* Проверка целостности заданных связей
 
* Проверка целостности заданных связей
 
* Связи задаются в запросах
 
* Связи задаются в запросах
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь в рамки обведены таблицы с однотипными данными, а стрелки показывают общие идентификаторы, по которым можно определить связи между ними.
 +
 
[[Файл:Intro relational.png|400px]]
 
[[Файл:Intro relational.png|400px]]
  
 
=== Достоинства ===
 
=== Достоинства ===
* Представление всех типов связей
+
* Представление всех типов связей (теперь связи симметричные, а значит в отношении многие ко многим не будет основных и побочных иерархий)
* Гибкая структура данных
+
* Гибкая структура данных (из-за задания связей непосредственно в запросах)
 
* Математическая модель (благодаря этому можем находить более эффективные эквивалентные запросы)
 
* Математическая модель (благодаря этому можем находить более эффективные эквивалентные запросы)
  
 
=== Недостатки ===
 
=== Недостатки ===
* Сложность реализации
+
* Сложность реализации (так как нужно дополнительно реализовывать и оптимизатор)
* Сложность представления иерархических данных
+
* Сложность представления иерархических данных (когда в иерархии содержатся элементы одинакового типа)
 
* Сложность составления эффективных запросов (сильно зависит от оптимизатора)
 
* Сложность составления эффективных запросов (сильно зависит от оптимизатора)
  
Строка 129: Строка 163:
 
Уметь хранить графы объектов в памяти очень полезно. Предложена в 1985. Сейчас такие базы данных в основном реализуются через слой трансляции в реляционную базу.
 
Уметь хранить графы объектов в памяти очень полезно. Предложена в 1985. Сейчас такие базы данных в основном реализуются через слой трансляции в реляционную базу.
 
====Структура====
 
====Структура====
 +
Структура аналогична тому, как этот объект хранится в памяти. Это и является основным преимуществом данной модели.
 
* Сущность – объект  
 
* Сущность – объект  
 
* Связь – поле
 
* Связь – поле
 
* Ограничения целостности – определение объекта
 
* Ограничения целостности – определение объекта
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь в рамки обведены определения структуры объектов, а стрелкой обозначены ссылки от одного объекта к другому.
 +
 
[[Файл:Intro object.png|400px]]
 
[[Файл:Intro object.png|400px]]
  
 
=== Достоинства ===
 
=== Достоинства ===
* Простота представления объектов
+
* Простота представления объектов (из-за ориентированности модели данных на данную задачу)
* Гибкая структура данных
+
* Гибкая структура данных (так как можем хранить произвольные объекты)
 
* Логичное направление ссылок (соответственно направлению в объектах)
 
* Логичное направление ссылок (соответственно направлению в объектах)
  
 
=== Недостатки ===
 
=== Недостатки ===
* Сложность реализации
+
* Сложность реализации (так как стандартный способ - трансляция в реляционную модель)
* Сложность миграции схемы
+
* Сложность миграции схемы (что будет с объектами в базе, если мы захотим добавить им поле)
* Малая распространенность
+
* Малая распространенность (в основном используются через ORM)
 +
 
 
=== Реализации ===
 
=== Реализации ===
 
* Oracle Database Objects
 
* Oracle Database Objects
Строка 150: Строка 189:
 
== NoSQL ==
 
== NoSQL ==
 
=== Документ-ориентированные ===
 
=== Документ-ориентированные ===
 +
Мы можем быстро искать документы с произвольным содержанием.
 
==== Представление данных ====
 
==== Представление данных ====
 
* Слабоструктурированные документы
 
* Слабоструктурированные документы
Строка 156: Строка 196:
 
* Выборка по свойствам
 
* Выборка по свойствам
 
==== Пример ====
 
==== Пример ====
 +
В рамки обведены содержания отдельных документов. Как видно из примера они могут существенно отличаться.
 +
 
[[Файл:Intro history document.png|400px]]
 
[[Файл:Intro history document.png|400px]]
 +
 
=== Ключ-значение ===
 
=== Ключ-значение ===
 +
Имеем маленькие значения и хотим их быстро идентифицировать по ключам. Если хотим ссылки - храним в значении массивы ключей. В данной модели мы умеем только по ключу доставать небольшое значение.
 
==== Представление данных ====
 
==== Представление данных ====
 +
Представляет собой ассоциативный массив.
 
* Ключ
 
* Ключ
 
* Произвольное значение
 
* Произвольное значение
 +
 
==== Пример ====
 
==== Пример ====
 +
Здесь в рамки обведено определение ассоциативного массива.
 +
 
[[Файл:Intro history keyvalue.png|400px]]
 
[[Файл:Intro history keyvalue.png|400px]]
 +
 
=== Другие ===
 
=== Другие ===
 
==== Табличные ====
 
==== Табличные ====
 +
Если у нас отсутствуют сложные взаимосвязи между данными, мы можем хотеть оптимизировать использование одной большой таблицы.
 
* Одна большая таблица
 
* Одна большая таблица
 
* Хранится построчно
 
* Хранится построчно
 +
 
==== Столбчатые ====
 
==== Столбчатые ====
 +
Представим, что запись у нас содержит множество столбцов. Нужно ли нам каждый раз читать их все, как происходит в традиционном подходе? В таком случае нам выгодно хранить столбцы отдельно друг от друга.
 
* Одна большая таблица
 
* Одна большая таблица
 
* Хранится по столбцам
 
* Хранится по столбцам
 +
 
==== Графовые ====
 
==== Графовые ====
 +
Часто мы можем захотеть хранить графы объектов. Один из примеров - социальные сети.
 
* Граф объектов
 
* Граф объектов
 
* Данные в узлах
 
* Данные в узлах
 
* Данные на ребрах
 
* Данные на ребрах
 +
 
=== Достоинства ===
 
=== Достоинства ===
* Большой выбор
+
* Большой выбор (можем любое свойство предыдущих моделей обменивать на производительность)
 
* Гибкость (возникают проблемы, если появляется незапланированный сценарий использования)
 
* Гибкость (возникают проблемы, если появляется незапланированный сценарий использования)
* Скорость работы
+
* Скорость работы (но зависит от реализации)
  
 
=== Недостатки ===
 
=== Недостатки ===
* Множество вещей делается в коде
+
* Множество вещей делается в коде (который надо будет проверять, поддерживать и обновлять)
 
* Нет оптимизатора
 
* Нет оптимизатора
 
* Легко ошибиться (так как большинство вещей делается в коде)
 
* Легко ошибиться (так как большинство вещей делается в коде)

Текущая версия на 19:36, 4 сентября 2022

Содержание

Простые и структурированные файлы

Модель данных простого файла

Самая простая форма организации данных в базе, соответственно, была создана одной из первых. Из-за своей простоты имеет множество недостатков, однако до сих пор используется во многих областях.

Структура

В структуре содержится минимально необходимое количество информации о данных, из-за чего отсутствует возможность верификации данных при чтении.

  • Заголовок (названия столбцов)
  • Данные (просто текст)

Пример

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

ФИО,Предмет,Оценка
Иванов И.И.,Java,4
Иванов И.И.,Базы данных,5
Петров П.П.,Java,5
Петров П.П.,Базы данных,4

Модель данных структурированного файла

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

Структура

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

  • Заголовок (названия столбцов, типы и длины)
  • Данные (записи одинаковой структуры)

Пример

Здесь к строке, содержащей заголовки, добавляется дополнительная строка с типами и длинами. В данном формате цифра обозначает количество символов для этого поля.

ФИО           Предмет     Оценка
String, 14    String, 12  Number, 1
Иванов И.И.   Java          4
Иванов И.И.   Базы данных   5
Петров П.П.   Java          5
Петров П.П.   Базы данных   4

Достоинства

  • Простота чтения (так как данные можно просто читать построчно)

Недостатки

  • Сложность поиска (прямо следует из достоинства, так как в случае простого файла записи надо читать построчно, а в случае структурированного быстро мы находим только запись по номеру)
  • Сложность обработки (в каждом месте для этого нужен будет свой код)
  • Сложность хранения данных разны типов (например, для дат не понятно, в каком порядке идут данные)
  • Нет проверки целостности (но можно проверять количество столбцов или добавить модуль чтения и записи типизированных файлов)

Реализации

  • Данные на перфокартах
  • dBase
  • Excel / LibreOffice Calc

Файловые системы

Файловая модель данных

Заметим, что поиск в файлах оказывается на практике слишком долгим. Однако, у нас имеются файловые системы, таким образом появляется идея переложить задачу поиска на них. Простейший способ структурированной организации данных. Характеризуется множеством не связанных между собой независимых файлов, состоящих из однотипных записей с одноуровневой структурой.

Представление данных

Имеем структуру из каталогов и файлов, лежащих внутри. В файлы можем заносить не только сами данные, но и некоторые ограничения на них.

  • Файл – одна запись (одноуровневая структура)
  • Каталоги – подчиненные записи

Пример

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

  • Иванов И.И./Данные – ФИО, адрес, etc
  • Иванов И.И./Оценки/Java – 4
  • Иванов И.И./Оценки/Базы данных – 5
  • Петров П. П./Данные – ФИО, адрес, etc
  • Иванов П. П./Оценки/Java – 5
  • Петров П. П./Оценки/Базы данных – 4

Достоинства

  • Структурирование данных (у нас есть опция хранения в файлах дополнительной информации о данных)
  • Простота реализации (мы используем для реализации готовую файловую систему)

Недостатки

  • Сложно извлекать требуемые данные (в примере сложно посчитать среднюю оценку по предмету)
  • Нет проверки целостности (но можно, например, добавить проверку уникальности)
  • Большое количество файлов (не все файловые системы такое потянут с приемлимой производительностью)

Реализации

  • FATx, ExtX, NTFS, APFS
  • DOM

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

Иерархическая модель данных

Заметим, что работа файловых систем с большим количеством файлов оказывается на практике слишком дорогой. Тогда появляется идея построить иерархию самостоятельно. Такая модель является совокупностью взаимосвязанных объектов, cвязь двух объектов отражает их подчиненность. Иерархия это полезно, но складывать это в файловую систему не очень эффективно. Предложена и реализована IBM в 1966.

Представление данных

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

  • Дерево записей
  • Отношения родитель – ребенок (как каталоги и подкаталоги)

Пример

Здесь в рамки обведены узлы дерева, где мы храним сами данные и их тип, а стрелочками обозначены отношения родитель-ребенок.


Intro hierarch.png

Достоинства

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

Недостатки

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

Реализации

  • IBM Information Management System
  • Windows registry

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

Сетевая модель данных

Отсутствие отношения многие ко многим очень сильно затрудняет реализацию разумных запросов в иерархической модели даных. Для решения этой проблемы была предложена сетевая модель данных. Эта модель также является совокупностью взаимосвязанных объектов, однако здесь нет единой строгой иерархии, то есть могут существовать дополнительные с более низкой эффективностью поиска. Таким образом сетевые модели данных по сравнению с иерархическими являются более универсальными. Предложена CODASYL в 1969.

Представление данных

Мы отказываемся от дерева записей, ослабляя требования до ориентированного графа. Таким образом мы допускаем наличие у сущности нескольких владельцев и отношение владелец - запись становится отношением многие ко многим.

  • Ориентированный граф записей
  • Отношения владелец – запись

Пример

Здесь в рамки так же обведены узлы ориентированного графа, где мы храним сами данные и их тип. Теперь черными стрелочками обозначены отношения родитель-ребенок основной иерархии, а синие обозначают дополнительные отношения.


Intro network.png

Достоинства

  • Представление всех типов связей (так как нам теперь доступна связь многие ко многим)
  • Возможность описания структуры (аналогично иерархической модели данных)
  • Эффективность реализации (сильно меняется от основной иерархии к дополнительной из-за физического хранения данных только в одной последовательности)

Недостатки

  • Сложность реализации (так как теперь нам нужно хранить дополнительные внешние указатели, что вызывает сложности при перемещении записей)
  • Жесткое ограничение структуры (нужно заранее продумывать необходимые дополнительные иерархии)

Реализации

  • Integrated Data Store
  • Integrated Database Management System
  • TurboIMAGE

Реляционные базы данных

Реляционная модель данных

Заранее прописывать связи оказывается на практике довольно неудобно, поэтому вместе с сетевой моделью появляется реляционная модель данных, где связи задаются непосредственно в запросах (при этом вы можете их описать). Это самая популярная на данный момент модель данных. Отличается от предыдущих моделей заданием связей непосредственно в запросах, а также наличием математической модели, позволяющей оптимизировать эти запросы. Предложена Э. Ф. Коддом в 1969.

Структура

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

  • Данные хранятся в таблицах
  • Проверка целостности заданных связей
  • Связи задаются в запросах

Пример

Здесь в рамки обведены таблицы с однотипными данными, а стрелки показывают общие идентификаторы, по которым можно определить связи между ними.

Intro relational.png

Достоинства

  • Представление всех типов связей (теперь связи симметричные, а значит в отношении многие ко многим не будет основных и побочных иерархий)
  • Гибкая структура данных (из-за задания связей непосредственно в запросах)
  • Математическая модель (благодаря этому можем находить более эффективные эквивалентные запросы)

Недостатки

  • Сложность реализации (так как нужно дополнительно реализовывать и оптимизатор)
  • Сложность представления иерархических данных (когда в иерархии содержатся элементы одинакового типа)
  • Сложность составления эффективных запросов (сильно зависит от оптимизатора)

Реализации

  • Oracle Database
  • SQLite

Объектные базы данных

Объектная модель данных

Уметь хранить графы объектов в памяти очень полезно. Предложена в 1985. Сейчас такие базы данных в основном реализуются через слой трансляции в реляционную базу.

Структура

Структура аналогична тому, как этот объект хранится в памяти. Это и является основным преимуществом данной модели.

  • Сущность – объект
  • Связь – поле
  • Ограничения целостности – определение объекта

Пример

Здесь в рамки обведены определения структуры объектов, а стрелкой обозначены ссылки от одного объекта к другому.

Intro object.png

Достоинства

  • Простота представления объектов (из-за ориентированности модели данных на данную задачу)
  • Гибкая структура данных (так как можем хранить произвольные объекты)
  • Логичное направление ссылок (соответственно направлению в объектах)

Недостатки

  • Сложность реализации (так как стандартный способ - трансляция в реляционную модель)
  • Сложность миграции схемы (что будет с объектами в базе, если мы захотим добавить им поле)
  • Малая распространенность (в основном используются через ORM)

Реализации

  • Oracle Database Objects
  • ObjectDB

NoSQL

Документ-ориентированные

Мы можем быстро искать документы с произвольным содержанием.

Представление данных

  • Слабоструктурированные документы
    • XML
    • JSON
  • Выборка по свойствам

Пример

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

Intro history document.png

Ключ-значение

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

Представление данных

Представляет собой ассоциативный массив.

  • Ключ
  • Произвольное значение

Пример

Здесь в рамки обведено определение ассоциативного массива.

Intro history keyvalue.png

Другие

Табличные

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

  • Одна большая таблица
  • Хранится построчно

Столбчатые

Представим, что запись у нас содержит множество столбцов. Нужно ли нам каждый раз читать их все, как происходит в традиционном подходе? В таком случае нам выгодно хранить столбцы отдельно друг от друга.

  • Одна большая таблица
  • Хранится по столбцам

Графовые

Часто мы можем захотеть хранить графы объектов. Один из примеров - социальные сети.

  • Граф объектов
  • Данные в узлах
  • Данные на ребрах

Достоинства

  • Большой выбор (можем любое свойство предыдущих моделей обменивать на производительность)
  • Гибкость (возникают проблемы, если появляется незапланированный сценарий использования)
  • Скорость работы (но зависит от реализации)

Недостатки

  • Множество вещей делается в коде (который надо будет проверять, поддерживать и обновлять)
  • Нет оптимизатора
  • Легко ошибиться (так как большинство вещей делается в коде)