1632
правки
Изменения
м
Модель Отсутствие отношения многие ко многим очень сильно затрудняет реализацию разумных запросов в иерархической модели даных. Для решения этой проблемы была предложена сетевая модель данных. Эта модель также является совокупностью взаимосвязанных объектов. Однако , однако здесь нет единой строгой иерархии, то есть могут существовать дополнительные с более низкой эффективностью поиска. Таким образом сетевые модели данных по сравнению с иерархическими являются более универсальными.
Самая Заранее прописывать связи оказывается на практике довольно неудобно, поэтому вместе с сетевой моделью появляется реляционная модель данных, где связи задаются непосредственно в запросах (при этом вы можете их описать). Это самая популярная на данный момент модель данных. Отличается от предыдущих моделей заданием связей непосредственно в запросах, а также наличием математической модели, позволяющей оптимизировать эти запросы. Предложена Э. Ф. Коддом в 1969.
rollbackEdits.php mass rollback
== Иерархические базы данных ==
=== Иерархическая модель данных ===
Заметим, что работа файловых систем с большим количеством файлов оказывается на практике слишком дорогой. Тогда появляется идея построить иерархию самостоятельно. Такая модель является совокупностью взаимосвязанных объектов. Связь , 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)
=== Реализации ===
* Выборка по свойствам
==== Пример ====
В рамки обведены содержания отдельных документов. Как видно из примера они могут существенно отличаться.
[[Файл:Intro history document.png|400px]]
Имеем маленькие значения и хотим их быстро идентифицировать по ключам. Если хотим ссылки - храним в значении массивы ключей. В данной модели мы умеем только по ключу доставать небольшое значение.
==== Представление данных ====
Представляет собой ассоциативный массив.
* Ключ
* Произвольное значение
==== Пример ====
Здесь в рамки обведено определение ассоциативного массива.
[[Файл:Intro history keyvalue.png|400px]]
