Модель базы данных — это тип модели данных , определяющий логическую структуру базы данных . Она принципиально определяет, каким образом данные могут храниться, организовываться и обрабатываться. Наиболее популярным примером модели базы данных является реляционная модель , которая использует табличный формат.
К общим логическим моделям данных для баз данных относятся:
Объектно -реляционная база данных объединяет две связанные структуры.
Физические модели данных включают в себя:
Другие модели включают в себя:
Определенная система управления базами данных может предоставлять одну или несколько моделей. Оптимальная структура зависит от естественной организации данных приложения и от требований приложения, которые включают скорость транзакций, надежность, удобство обслуживания, масштабируемость и стоимость. Большинство систем управления базами данных построены вокруг одной конкретной модели данных, хотя продукты могут предлагать поддержку более чем одной модели.
Различные физические модели данных могут реализовать любую заданную логическую модель. Большинство программного обеспечения для баз данных предложат пользователю определенный уровень контроля при настройке физической реализации, поскольку сделанный выбор оказывает существенное влияние на производительность.
Модель — это не просто способ структурирования данных: она также определяет набор операций, которые можно выполнять с данными. [1] Например, реляционная модель определяет такие операции, как select , project и join . Хотя эти операции могут быть неявными в конкретном языке запросов , они обеспечивают основу, на которой строится язык запросов.
Плоская (или табличная) модель состоит из одного двумерного массива элементов данных , где все элементы заданного столбца считаются схожими значениями, а все элементы строки считаются связанными друг с другом. Например, столбцы для имени и пароля, которые могут использоваться как часть базы данных безопасности системы. Каждая строка будет иметь определенный пароль, связанный с отдельным пользователем. Столбцы таблицы часто имеют тип, связанный с ними, определяющий их как символьные данные, информацию о дате или времени, целые числа или числа с плавающей точкой. Этот табличный формат является предшественником реляционной модели.
Эти модели были популярны в 1960-х, 1970-х годах, но в настоящее время их можно найти в основном в старых устаревших системах . Они характеризуются прежде всего навигационностью с сильными связями между их логическими и физическими представлениями и недостатками в независимости данных .
В иерархической модели данные организованы в древовидную структуру , подразумевающую одного родителя для каждой записи. Поле сортировки сохраняет родственные записи в определенном порядке. Иерархические структуры широко использовались в ранних системах управления базами данных мэйнфреймов, таких как Information Management System (IMS) от IBM , и теперь описывают структуру XML- документов. Эта структура допускает связь «один ко многим» между двумя типами данных. Эта структура очень эффективна для описания многих связей в реальном мире; рецепты, оглавление, порядок абзацев/стихов, любая вложенная и отсортированная информация.
Эта иерархия используется как физический порядок записей в хранилище. Доступ к записям осуществляется путем перемещения вниз по структуре данных с использованием указателей в сочетании с последовательным доступом. Из-за этого иерархическая структура неэффективна для определенных операций базы данных, когда полный путь (в отличие от восходящей ссылки и поля сортировки) также не включен для каждой записи. Такие ограничения были компенсированы в более поздних версиях IMS дополнительными логическими иерархиями, наложенными на базовую физическую иерархию.
Сетевая модель расширяет иерархическую структуру, допуская отношения «многие ко многим» в древовидной структуре, допускающей множественность родителей. Она была наиболее популярна до того, как ее заменила реляционная модель, и определяется спецификацией CODASYL .
Сетевая модель организует данные с использованием двух фундаментальных концепций, называемых записями и наборами . Записи содержат поля (которые могут быть организованы иерархически, как в языке программирования COBOL ). Наборы (не путать с математическими наборами) определяют отношения «один ко многим» между записями: один владелец, много членов. Запись может быть владельцем в любом количестве наборов и членом в любом количестве наборов.
Набор состоит из кольцевых связанных списков , где один тип записи, владелец набора или родитель, появляется один раз в каждом круге, а второй тип записи, подчиненный или дочерний, может появляться несколько раз в каждом круге. Таким образом, иерархия может быть установлена между любыми двумя типами записей, например, тип A является владельцем B. В то же время может быть определен другой набор, где B является владельцем A. Таким образом, все наборы составляют общий направленный граф (владение определяет направление) или сетевую конструкцию. Доступ к записям либо последовательный (обычно в каждом типе записи), либо путем навигации в кольцевых связанных списках.
Сетевая модель способна представлять избыточность данных более эффективно, чем иерархическая модель, и может быть более одного пути от узла-предка к узлу-потомку. Операции сетевой модели носят навигационный характер: программа сохраняет текущую позицию и переходит от одной записи к другой, следуя связям, в которых участвует запись. Записи также можно локализовать, предоставляя ключевые значения.
Хотя это не является существенной особенностью модели, сетевые базы данных обычно реализуют заданные отношения посредством указателей , которые напрямую адресуют местоположение записи на диске. Это обеспечивает превосходную производительность поиска за счет таких операций, как загрузка и реорганизация базы данных.
Популярными продуктами СУБД, которые ее использовали, были Total от Cincom Systems и IDMS от Cullinet . IDMS приобрела значительную клиентскую базу; в 1980-х годах она приняла реляционную модель и SQL в дополнение к своим исходным инструментам и языкам.
Большинство объектных баз данных (изобретенных в 1990-х годах) используют навигационную концепцию для обеспечения быстрой навигации по сетям объектов, обычно используя идентификаторы объектов в качестве «умных» указателей на связанные объекты. Например, Objectivity/DB реализует именованные отношения «один к одному», «один ко многим», «многие к одному» и «многие ко многим», которые могут пересекать базы данных. Многие объектные базы данных также поддерживают SQL , объединяя сильные стороны обеих моделей.
В инвертированном файле или инвертированном индексе содержимое данных используется в качестве ключей в таблице поиска, а значения в таблице являются указателями на местоположение каждого экземпляра данного элемента контента. Это также логическая структура современных индексов баз данных , которые могут использовать только содержимое из определенных столбцов в таблице поиска. Модель данных инвертированного файла может помещать индексы в набор файлов рядом с существующими плоскими файлами базы данных, чтобы эффективно получать прямой доступ к необходимым записям в этих файлах.
Примечательна тем, что использует эту модель данных, СУБД ADABAS компании Software AG , представленная в 1970 году. ADABAS приобрела значительную клиентскую базу и существует и поддерживается по сей день. В 1980-х годах она приняла реляционную модель и SQL в дополнение к своим оригинальным инструментам и языкам.
Например, документно-ориентированная база данных Clusterpoint использует модель инвертированной индексации для обеспечения быстрого полнотекстового поиска объектов данных XML или JSON .
Реляционная модель была введена Э. Ф. Коддом в 1970 году [2] как способ сделать системы управления базами данных более независимыми от любого конкретного приложения. Это математическая модель, определенная в терминах логики предикатов и теории множеств , и ее реализации использовались в мэйнфреймах, системах среднего уровня и микрокомпьютерах.
Продукты, которые обычно называют реляционными базами данных , на самом деле реализуют модель, которая является лишь приближением к математической модели, определенной Коддом. Три ключевых термина широко используются в моделях реляционных баз данных: отношения , атрибуты и домены . Отношение — это таблица со столбцами и строками. Именованные столбцы отношения называются атрибутами, а домен — это набор значений, которые атрибуты могут принимать.
Базовая структура данных реляционной модели — это таблица, где информация о конкретной сущности (например, сотруднике) представлена в строках (также называемых кортежами ) и столбцах. Таким образом, « отношение » в «реляционной базе данных» относится к различным таблицам в базе данных; отношение — это набор кортежей. Столбцы перечисляют различные атрибуты сущности (например, имя сотрудника, адрес или номер телефона), а строка — это фактический экземпляр сущности (конкретного сотрудника), представленный отношением. В результате каждый кортеж таблицы сотрудников представляет различные атрибуты одного сотрудника.
Все отношения (и, следовательно, таблицы) в реляционной базе данных должны соответствовать некоторым базовым правилам, чтобы считаться отношениями. Во-первых, порядок столбцов в таблице не имеет значения. Во-вторых, в таблице не может быть идентичных кортежей или строк. И, в-третьих, каждый кортеж будет содержать одно значение для каждого из своих атрибутов.
Реляционная база данных содержит несколько таблиц, каждая из которых похожа на таблицу в «плоской» модели базы данных. Одной из сильных сторон реляционной модели является то, что, в принципе, любое значение, встречающееся в двух разных записях (принадлежащих одной и той же таблице или разным таблицам), подразумевает связь между этими двумя записями. Тем не менее, для обеспечения явных ограничений целостности , связи между записями в таблицах также могут быть определены явно, путем идентификации или неидентификации родительско-дочерних связей, характеризуемых назначением мощности (1:1, (0)1:M, M:M). Таблицы также могут иметь назначенный одиночный атрибут или набор атрибутов, которые могут действовать как «ключ», который может использоваться для уникальной идентификации каждого кортежа в таблице.
Ключ, который можно использовать для уникальной идентификации строки в таблице, называется первичным ключом. Ключи обычно используются для объединения или комбинирования данных из двух или более таблиц. Например, таблица Employee может содержать столбец с именем Location , который содержит значение, совпадающее с ключом таблицы Location . Ключи также имеют решающее значение при создании индексов, которые облегчают быстрый поиск данных из больших таблиц. Любой столбец может быть ключом, или несколько столбцов могут быть сгруппированы вместе в составной ключ. Не обязательно определять все ключи заранее; столбец может использоваться в качестве ключа, даже если изначально он не был предназначен для этого.
Ключ, имеющий внешнее, реальное значение (например, имя человека, ISBN книги или серийный номер автомобиля), иногда называют «естественным» ключом. Если не подходит ни один естественный ключ (например, подумайте о многих людях с фамилией Браун ), можно назначить произвольный или суррогатный ключ (например, дав сотрудникам идентификационные номера). На практике большинство баз данных имеют как сгенерированные, так и естественные ключи, поскольку сгенерированные ключи могут использоваться внутри для создания связей между строками, которые не могут быть нарушены, в то время как естественные ключи могут использоваться, что менее надежно, для поиска и интеграции с другими базами данных. (Например, записи в двух независимо разработанных базах данных могут быть сопоставлены по номеру социального страхования , за исключением случаев, когда номера социального страхования неверны, отсутствуют или были изменены.)
Наиболее распространенным языком запросов, используемым в реляционной модели, является язык структурированных запросов ( SQL ).
Размерная модель — это специализированная адаптация реляционной модели, используемой для представления данных в хранилищах данных таким образом, что данные можно легко суммировать с помощью онлайн-аналитической обработки или запросов OLAP . В размерной модели схема базы данных состоит из одной большой таблицы фактов, которые описываются с помощью измерений и мер. Измерение предоставляет контекст факта (например, кто участвовал, когда и где это произошло, а также его тип) и используется в запросах для группировки связанных фактов вместе. Измерения, как правило, являются дискретными и часто иерархическими; например, местоположение может включать здание, штат и страну. Мера — это количество, описывающее факт, например, доход. Важно, чтобы меры можно было осмысленно агрегировать — например, доход из разных местоположений можно суммировать.
В запросе OLAP выбираются измерения, а факты группируются и агрегируются для создания сводки.
Модель измерений часто реализуется поверх реляционной модели с использованием схемы «звезда» , состоящей из одной высоконормализованной таблицы, содержащей факты, и окружающих ее денормализованных таблиц, содержащих каждое измерение. Альтернативная физическая реализация, называемая схемой «снежинка» , нормализует многоуровневые иерархии внутри измерения в несколько таблиц.
Хранилище данных может содержать несколько размерных схем, которые совместно используют таблицы измерений, что позволяет использовать их вместе. Разработка стандартного набора измерений является важной частью размерного моделирования .
Высокая производительность сделала многомерную модель самой популярной структурой базы данных для OLAP.
Продукты, предлагающие более общую модель данных, чем реляционная модель, иногда классифицируются как постреляционные . [3] Альтернативные термины включают «гибридную базу данных», «объектно-усовершенствованную СУБД» и другие. Модель данных в таких продуктах включает отношения , но не ограничена принципом информации Э. Ф. Кодда , который требует, чтобы
вся информация в базе данных должна быть представлена явно в терминах значений в отношениях и никак иначе
— [4]
Некоторые из этих расширений реляционной модели интегрируют концепции из технологий, которые предшествовали реляционной модели. Например, они позволяют представлять направленный граф с деревьями на узлах. Немецкая компания sones реализует эту концепцию в своей GraphDB .
Некоторые постреляционные продукты расширяют реляционные системы нереляционными функциями. Другие пришли примерно в то же самое место, добавив реляционные функции к дореляционным системам. Парадоксально, но это позволяет продуктам, которые исторически являются дореляционными, таким как PICK и MUMPS , делать правдоподобные заявления о том, что они постреляционные.
Модель пространства ресурсов (RSM) — это нереляционная модель данных, основанная на многомерной классификации. [5]
Графовые базы данных допускают даже более общую структуру, чем сетевые базы данных: любой узел может быть подключен к любому другому узлу.
Многозначные базы данных представляют собой «кусковые» данные, поскольку они могут хранить данные точно так же, как реляционные базы данных, но они также допускают уровень глубины, который реляционная модель может только аппроксимировать с помощью подтаблиц. Это почти идентично способу выражения данных в XML, где заданное поле/атрибут может иметь несколько правильных ответов одновременно. Многозначность можно рассматривать как сжатую форму XML.
Примером может служить счет-фактура, который в многозначных или реляционных данных может рассматриваться как (A) Таблица заголовков счетов-фактур — одна запись на счет-фактуру и (B) Таблица деталей счетов-фактур — одна запись на позицию. В многозначной модели у нас есть возможность хранить данные в виде таблицы со встроенной таблицей для представления деталей: (A) Таблица счетов-фактур — одна запись на счет-фактуру, другие таблицы не нужны.
Преимущество в том, что атомарность Invoice (концептуальная) и Invoice (представление данных) являются один к одному. Это также приводит к меньшему количеству чтений, меньшему количеству проблем с целостностью ссылок и значительному уменьшению оборудования, необходимого для поддержки заданного объема транзакций.
В 1990-х годах объектно-ориентированная парадигма программирования была применена к технологии баз данных, создав новую модель базы данных, известную как объектные базы данных . Это направлено на то, чтобы избежать несоответствия объектно-реляционного импеданса — накладных расходов на преобразование информации между ее представлением в базе данных (например, в виде строк в таблицах) и ее представлением в прикладной программе (обычно в виде объектов). Более того, система типов , используемая в конкретном приложении, может быть определена непосредственно в базе данных, что позволяет базе данных применять те же инварианты целостности данных. Объектные базы данных также вводят ключевые идеи объектного программирования, такие как инкапсуляция и полиморфизм , в мир баз данных.
Было испробовано множество таких способов для хранения объектов в базе данных. Некоторые [ which? ] продукты подошли к проблеме со стороны прикладного программирования, сделав объекты, которыми манипулирует программа, постоянными . Обычно это требует добавления какого-либо языка запросов, поскольку обычные языки программирования не обладают способностью находить объекты на основе их информационного содержания. Другие [ which? ] атаковали проблему со стороны базы данных, определив объектно-ориентированную модель данных для базы данных и определив язык программирования базы данных, который обеспечивает полные возможности программирования, а также традиционные средства запросов.
Объектные базы данных страдали из-за отсутствия стандартизации: хотя стандарты были определены ODMG , они никогда не были реализованы достаточно хорошо, чтобы обеспечить взаимодействие между продуктами. Тем не менее, объектные базы данных успешно использовались во многих приложениях: обычно специализированных приложениях, таких как инженерные базы данных или базы данных молекулярной биологии, а не в основной коммерческой обработке данных. Однако идеи объектных баз данных были подхвачены реляционными поставщиками и повлияли на расширения, сделанные для этих продуктов и, конечно, для языка SQL .
Альтернативой переводу между объектами и реляционными базами данных является использование библиотеки объектно-реляционного отображения (ORM).
