1632
правки
Изменения
м
Модель так же Отсутствие отношения многие ко многим очень сильно затрудняет реализацию разумных запросов в иерархической модели даных. Для решения этой проблемы была предложена сетевая модель данных. Эта модель также является совокупностью взаимосвязанных объектов. Однако , однако здесь нет единой строгой иерархии, то есть могут существовать дополнительные с более низкой эффективностью поиска. Таким образом сетевые модели данных по сравнению с иерархическими являются более универсальными.
Самая Заранее прописывать связи оказывается на практике довольно неудобно, поэтому вместе с сетевой моделью появляется реляционная модель данных, где связи задаются непосредственно в запросах (при этом вы можете их описать). Это самая популярная на данный момент модель данных. Отличается от предыдущих моделей заданием связей непосредственно в запросах, а так же также наличием математической модели, позволяющей оптимизировать эти запросы. Предложена Э. Ф. Коддом в 1969.
Имеем маленькие значения и хотим. их Мы можем быстро идентифицировать по ключам. Если хотим ссылки - храним в значении массивы ключей. В данной модели мы умеем только по ключу доставать небольшое значениеискать документы с произвольным содержанием.
rollbackEdits.php mass rollback
== Простые и структурированные файлы ==
=== Модель данных простого файла ===
Самая простая форма организации данных в базе, соответственно , была создана одной из первых. Из-за своей простоты имеет множество недостатков, однако до сих пор используется во многих областях.
==== Структура ====
В структуре содержится минимально необходимое количество информации о данных, из-за чего отсутствует возможность верификации данных при чтении.
*Заголовок (названия столбцов)
*Данные (просто текст)
==== Пример ====
Сверху располагаются названия столбцов, разделенные запятыми. После чего на отдельных строках идут записи, также разделенные запятыми.
ФИО,Предмет,Оценка
Иванов И.И.,Java,4
Петров П.П.,Java,5
Петров П.П.,Базы данных,4
=== Модель данных структурированного файла ===
Важным достоинством структурированного файла является возможность быстро находить строчку по номеру (так как нам известен фиксированный размер строки , мы можем посчитать смещение).
==== Структура ====
Теперь в информацию добавлены записи о типе данных и о их размере, такми образом мы получаем больше возможностей для верификации при чтении данных. Так же здесь появляется смысл хранить номера строк для быстрого поиска в данных.
*Заголовок (названия столбцов, типы и длины)
*Данные (записи одинаковой структуры)
==== Пример ====
Здесь к строке, содержащей заголовки, добавляется дополнительная строка с типами и длинами. В данном формате цифра обозначает количество символов для этого поля.
ФИО Предмет Оценка
String, 14 String, 12 Number, 1
=== Недостатки ===
* Сложность поиска(прямо следует из достоинства, так как в случае простого файла записи надо читать построчно, а в случае структурированного быстро мы находим только запись по номеру)
* Сложность обработки (в каждом месте для этого нужен будет свой код)
* Сложность хранения данных разны типов (например, для дат не понятно, в каком порядке идут данные)
== Файловые системы ==
=== Файловая модель данных ===
Заметим, что поиск в файлах оказывается на практике слишком долгим. Однако, у нас имеются файловые системы, таким образом появляется идея переложить задачу поиска на них. Простейший способ структурированной организации данных. Характеризуется множеством не связанных между собой независимых файлов, состоящих из однотипных записей с одноуровневой структурой.
==== Представление данных ====
Имеем структуру из каталогов и файлов, лежащих внутри. В файлы можем заносить не только сами данные, но и некоторые ограничения на них.
* Файл – одна запись (одноуровневая структура)
* Каталоги – подчиненные записи
==== Пример ====
Здесь через символ / обозначено разделение на подкаталоги, у которых внутри лежат файлы с некоторыми конкретными для каждого случая данными. Данные в файле так же могут быть структурированными.
* Иванов И.И./Данные – ФИО, адрес, etc
* Иванов И.И./Оценки/Java – 4
=== Достоинства ===
* Структурирование данных(у нас есть опция хранения в файлах дополнительной информации о данных)* Простота реализации(мы используем для реализации готовую файловую систему)
=== Недостатки ===
* Сложно извлекать требуемые данные (в примере сложно посчитать среднюю оценку по предмету)
* Нет проверки целостности (но можно, например, добавить проверку уникальности)
* Большое количество файлов (не все файловые системы такое потянутс приемлимой производительностью)
=== Реализации ===
== Иерархические базы данных ==
=== Иерархическая модель данных ===
Заметим, что работа файловых систем с большим количеством файлов оказывается на практике слишком дорогой. Тогда появляется идея построить иерархию самостоятельно. Такая модель является совокупностью взаимосвязанных объектов. Связь , cвязь двух объектов отражает их подчиненность. Иерархия это полезно, но складывать это в файловую систему не очень эффективно.
Предложена и реализована IBM в 1966.
==== Представление данных ====
Теперь мы храним дерево записей, при этом для каждой записи мы знаем ее тип и структуру. Таким образом исчезает проблема с ошибками в типах хранящихся данных. Так же для каждой записи имеется произвольное количество подчиненных записей (детей).
* Дерево записей
* Отношения родитель – ребенок (как каталоги и подкаталоги)
==== Пример ====
Здесь в рамки обведены узлы дерева, где мы храним сами данные и их тип, а стрелочками обозначены отношения родитель-ребенок.
[[Файл:Intro hierarch.png|400px]]
=== Достоинства ===
* Проверка целостности записей и отношений (можем проверять отдельные поля записей при сохранении, записи целиком, описанные в структуре отношения, также можем разрешать добавлять дубликаты, где необходимо)* Последовательное расположение записей(таким образом мы оптимизируем последовательный доступ к данным, что оптимизирует некоторые запросы)
* Эффективность реализации (за счет группировки данных одного типа)
=== Недостатки ===
* Представление только древовидных данных(например отношение многие ко многим требует от нашей модели обратного ''ссылок'', которые невозможно обеспечить в древовидной структуре)
* Существенно меняющееся время запроса в отношении многие-ко-многим в зависимости от того, кто выше в иерархии. Можно хранить две версии, однако возникает проблема с их согласованием, то есть в этот момент мы начинаем допускать некорректные данные.
== Сетевые базы данных ==
=== Сетевая модель данных ===
Предложена CODASYL в 1969.
====Представление данных====
Мы отказываемся от дерева записей, ослабляя требования до ориентированного графа. Таким образом мы допускаем наличие у сущности нескольких владельцев и отношение владелец - запись становится отношением многие ко многим.
* Ориентированный граф записей
* Отношения владелец – запись
==== Пример ====
Здесь в рамки так же обведены узлы ориентированного графа, где мы храним сами данные и их тип. Теперь черными стрелочками обозначены отношения родитель-ребенок основной иерархии, а синие обозначают дополнительные отношения.
[[Файл:Intro network.png|400px]]
=== Достоинства ===
* Представление всех типов связей(так как нам теперь доступна связь многие ко многим)* Возможность описания структуры(аналогично иерархической модели данных)* Эффективность реализации (сильно меняется от основной иерархии к дополнительнойиз-за физического хранения данных только в одной последовательности)
=== Недостатки ===
* Сложность реализации(так как теперь нам нужно хранить дополнительные внешние указатели, что вызывает сложности при перемещении записей)* Жесткое ограничение структуры(нужно заранее продумывать необходимые дополнительные иерархии)
=== Реализации ===
* Integrated Data Store
== Реляционные базы данных ==
=== Реляционная модель данных ===
====Структура====
Теперь мы храним данные в различных табличках, умея проверять целостность cвязей благодаря этому. Так же связи теперь могут задаваться в запросах.
* Данные хранятся в таблицах
* Проверка целостности заданных связей
* Связи задаются в запросах
==== Пример ====
Здесь в рамки обведены таблицы с однотипными данными, а стрелки показывают общие идентификаторы, по которым можно определить связи между ними.
[[Файл:Intro relational.png|400px]]
=== Достоинства ===
* Представление всех типов связей(теперь связи симметричные, а значит в отношении многие ко многим не будет основных и побочных иерархий)* Гибкая структура данных(из-за задания связей непосредственно в запросах)
* Математическая модель (благодаря этому можем находить более эффективные эквивалентные запросы)
=== Недостатки ===
* Сложность реализации(так как нужно дополнительно реализовывать и оптимизатор)* Сложность представления иерархических данных(когда в иерархии содержатся элементы одинакового типа)
* Сложность составления эффективных запросов (сильно зависит от оптимизатора)
Уметь хранить графы объектов в памяти очень полезно. Предложена в 1985. Сейчас такие базы данных в основном реализуются через слой трансляции в реляционную базу.
====Структура====
Структура аналогична тому, как этот объект хранится в памяти. Это и является основным преимуществом данной модели.
* Сущность – объект
* Связь – поле
* Ограничения целостности – определение объекта
==== Пример ====
Здесь в рамки обведены определения структуры объектов, а стрелкой обозначены ссылки от одного объекта к другому.
[[Файл:Intro object.png|400px]]
=== Достоинства ===
* Простота представления объектов (из-за ориентированности модели данных на данную задачу)
* Гибкая структура данных (так как можем хранить произвольные обьектыобъекты)
* Логичное направление ссылок (соответственно направлению в объектах)
* Сложность реализации (так как стандартный способ - трансляция в реляционную модель)
* Сложность миграции схемы (что будет с объектами в базе, если мы захотим добавить им поле)
* Малая распространенность(в основном используются через ORM)
=== Реализации ===
== NoSQL ==
=== Документ-ориентированные ===
==== Представление данных ====
* Слабоструктурированные документы
* Выборка по свойствам
==== Пример ====
В рамки обведены содержания отдельных документов. Как видно из примера они могут существенно отличаться.
[[Файл:Intro history document.png|400px]]
Имеем маленькие значения и хотим их быстро идентифицировать по ключам. Если хотим ссылки - храним в значении массивы ключей. В данной модели мы умеем только по ключу доставать небольшое значение.
==== Представление данных ====
Представляет собой ассоциативный массив.
* Ключ
* Произвольное значение
==== Пример ====
Здесь в рамки обведено определение ассоциативного массива.
[[Файл:Intro history keyvalue.png|400px]]
=== Другие ===
==== Табличные ====
Если у нас отсутствуют сложные взаимосвязи между данными, мы можем хотеть оптимизировать использование одной большой таблицы.
* Одна большая таблица
* Хранится построчно
==== Столбчатые ====
Представим, что запись у нас содержит множество столбцов. Нужно ли нам каждый раз читать их все, как происходит в традиционном подходе? В таком случае нам выгодно хранить столбцы отдельно друг от друга.
==== Графовые ====
Часто мы можем захотеть хранить графы объектов. Один из примеров - социальные сети.
* Граф объектов
* Данные в узлах
* Данные на ребрах
=== Достоинства ===
* Большой выбор(можем любое свойство предыдущих моделей обменивать на производительность)
* Гибкость (возникают проблемы, если появляется незапланированный сценарий использования)
* Скорость работы (но зависит от реализации)
=== Недостатки ===
* Множество вещей делается в коде(который надо будет проверять, поддерживать и обновлять)
* Нет оптимизатора
* Легко ошибиться (так как большинство вещей делается в коде)
