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