Модель базы данных — тип модели данных, которая определяет логическую структуру базы данных и принципиально определяет, каким образом данные могут быть сохранены, организованы и обработаны. Наиболее популярным примером модели базы данных является реляционная модель, которая использует табличный формат.
Общие логические модели данных для баз данных:
Объектно-реляционная база данных объединяет две связанные структуры.
Модели физических данных включают:
Другие модели:
Система управления базами данных может предоставлять одну или несколько моделей. Оптимальная структура зависит от естественной организации данных приложения и от требований приложения. Большинство систем управления базами данных построены вокруг одной конкретной модели данных, хотя продукты могут предлагать поддержку более чем одной модели.
Различные модели физических данных могут реализовать любую данную логическую модель. Большинство СУБД будут предлагать пользователю некоторый уровень контроля при настройке физической реализации, поскольку выбор, который был сделан, оказывает значительное влияние на производительность.
Модель - это не просто способ структурирования данных: она также определяет набор операций, которые могут выполняться над данными. Реляционная модель, например, определяет такие операции, как select (project) и join. Хотя эти операции могут быть не явными в конкретном языке запросов, они обеспечивают основу, на которой строится язык запросов.
Плоская (или табличная) модель состоит из одного двумерного массива элементов данных, где все члены данного столбца считаются одинаковыми значениями, и предполагается, что все члены строки связаны друг с другом. Например, столбцы для имени и пароля, которые могут использоваться как часть базы данных безопасности системы. Каждая строка будет иметь конкретный пароль, связанный с отдельным пользователем. Столбцы таблицы часто имеют тип, связанный с ними, определяя их как символьные данные, информацию о дате или времени, целые числа или числа с плавающей запятой. Этот табличный формат является предшественником реляционной модели.
Эти модели были популярны в 1960-х, 1970-х годах, но в наши дни их использование можно найти в основном в старых системах. Они характеризуются, прежде всего, навигацией с прочными связями между их логическими и физическими представлениями и недостатками в независимости данных.
В иерархической модели, данные организованы в виде древовидной структуры, подразумевая одного родителя для каждой записи. Поле сортировки сохраняет одноуровневые записи в определенном порядке. Иерархические структуры широко использовались в ранних системах управления базами данных мейнфреймов, таких как IBM IMS, и теперь описывают структуру XML-документов. Эта структура допускает одно взаимное отношение между двумя типами данных. Эта структура очень эффективна для описания многих взаимосвязей в реальном мире; Рецепты, оглавление, порядок абзацев / стихов, любую вложенную и отсортированную информацию.
Эта иерархия используется как физический порядок записей в хранилище. Доступ к записи осуществляется путем навигации вниз по структуре данных с помощью указателей в сочетании с последовательным доступом. Из-за этого иерархическая структура неэффективна для некоторых операций с базой данных, когда полный путь (в отличие от восходящей линии связи и поля сортировки) также не включен для каждой записи. Такие ограничения были компенсированы в более поздних версиях IMS дополнительными логическими иерархиями, наложенными на базовую физическую иерархию.
Сетевая модель расширяет иерархическую структуру, позволяя отношения «многие ко многим». Модель была наиболее популярна заменой на реляционную модель и определялась спецификацией CODASYL.
Сетевая модель организует данные с использованием двух фундаментальных понятий, называемых записями и наборами. Записи содержат поля (которые могут быть организованы иерархически, как в языке программирования COBOL). Наборы (не путать с математическими наборами) определяют отношения «один ко многим» между записями: один владелец, многие члены. Запись может быть владельцем в любом количестве наборов и членом в любом количестве наборов.
Набор состоит из круговых связанных списков, где один тип записи, владелец набора или родительский элемент, появляется один раз в каждом круге, а второй тип записи, подчиненный или дочерний, может появляться несколько раз в каждом круге. Таким образом, между любыми двумя типами записей может быть установлена иерархия, например, тип A является владельцем B. В то же время может быть определен другой набор, где B является владельцем A. Таким образом, все множества содержат общий ориентированный граф (Право собственности определяет направление) или сетевую конструкцию. Доступ к записям является либо последовательным (обычно в каждом типе записи), либо навигацией в круговых связанных списках.
Сетевая модель способна представлять избыточность данных более эффективно, чем в иерархической модели, и может быть более одного пути от узла-предка до потомка. Операции сетевой модели являются навигационными по стилю: программа поддерживает текущую позицию и перемещается из одной записи в другую, следуя отношениям, в которых участвует запись. Записи также можно найти, указав значения ключа.
Хотя это не является существенной особенностью модели, сетевые базы данных обычно реализуют установленные отношения с помощью указателей, которые непосредственно адресуют местоположение записи на диске. Это дает отличную производительность поиска за счет таких операций, как загрузка базы данных и реорганизация.
Популярными продуктами СУБД, которые его использовали, были IDMS Cincom Systems и Total ID Cullinet. IDMS получила значительную клиентскую базу; В 1980-х годах он принял реляционную модель и SQL в дополнение к своим оригинальным инструментам и языкам. Большинство объектных баз данных (изобретенных в 1990-х годах) используют навигационную концепцию для быстрой навигации по сетям объектов, обычно используя идентификаторы объектов как «умные» указатели на связанные объекты. Объективность / БД, например, реализует так называемые отношения один к одному, один-ко-многим, многие-к-одному и многие-ко-многим, которые могут перекрещивать базы данных. Многие базы данных объектов также поддерживают SQL, сочетая сильные стороны обеих моделей.
В инвертированном файле или инвертированном индексе содержимое данных используется как ключи в таблице поиска, а значения в таблице являются указателями на расположение каждого экземпляра данного элемента контента. Это также логическая структура современных индексов базы данных, которые могут использовать только содержимое из определенных столбцов в таблице поиска. Модель данных с инвертированными файлами может помещать индексы во второй набор файлов рядом с существующими файлами плоских баз данных, чтобы эффективно получать доступ к необходимым записям в этих файлах.
Примечательным для использования этой модели данных является ADABAS DBMS of Software AG, представленная в 1970 году. ADABAS приобрела значительную клиентскую базу и существует и поддерживается до сегодняшнего дня. В 1980-х годах она приняла реляционную модель и SQL в дополнение к своим оригинальным инструментам и языкам.
Документарно-ориентированная база данных Clusterpoint использует инвертированную модель индексирования для обеспечения быстрого полнотекстового поиска объектов данных XML или JSON и предоставления возможности масштабирования для больших данных. Clusterpoint имеет встроенный вычислительный движок, который позволяет выполнять комбинированный SQL-запрос, свободный текстовый поиск и код JavaScript прямо внутри распределенной базы данных. Как данные, так и инвертированные индексы посредством масштабируемого масштабирования и репликации могут быть распределены на большом количестве серверов для поддержки миллиардов объектов данных в одной и той же базе данных Clusterpoint. Язык запросов Clusterpoint JS / SQL сочетает синтаксис SQL и JavaScript с полнотекстовым поиском, где инвертированный указатель используется для доставки результатов текстового поиска в миллисекундах и соответствующей разбивки на страницы в веб-и мобильных приложениях. Инвертированный индекс базы данных базы данных Clusterpoint также поддерживает программируемое ранжирование релевантности, позволяющее настраивать результаты поиска без дополнительных усилий по кодированию. Подобно реляционным базам данных, Clusterpoint поддерживает распределенные транзакции базы данных, совместимые с ACID, для обеспечения согласованной базы данных документов, где данные инвертированного индекса немедленно обновляются вместе с любыми обновлениями содержимого документа XML или JSON. Инвертированный индекс также используется для поддержки отчетов в режиме реального времени в режиме реального времени, аналитики, детализации и интеллектуального анализа данных по REST API в базе данных Clusterpoint.
Реляционная модель была введена Э. Ф. Коддом в 1970 году как способ сделать системы управления базами данных более независимыми от какого-либо конкретного приложения. Это математическая модель, определенная в терминах логики предикатов и теории множеств, а используемые ею системы используются в системах мэйнфреймов, пк и микрокомпьютеров.
Продукты, которые обычно называются реляционными базами данных, фактически реализуют модель, которая является лишь приближением к математической модели, определенной Коддом. Три ключевых термина широко используются в моделях реляционных баз данных: отношения, атрибуты и домены. Отношение - это таблица со столбцами и строками. Именованные столбцы отношения называются атрибутами, а домен - это набор значений, которые могут принимать атрибуты.
Основной структурой данных реляционной модели является таблица, в которой информация о конкретном объекте (скажем, работнике) представлена в строках (также называемых кортежами) и столбцах. Таким образом, «отношение» в «реляционной базе данных» относится к различным таблицам в базе данных; Отношение представляет собой набор кортежей. В столбцах перечислены различные атрибуты объекта (например, имя сотрудника, адрес или номер телефона), а строка является фактическим экземпляром объекта (конкретного сотрудника), который представлен отношением. В результате каждый кортеж таблицы employee представляет различные атрибуты одного сотрудника.
Все отношения (и, следовательно, таблицы) в реляционной базе данных должны придерживаться некоторых основных правил, которые можно квалифицировать как отношения. Во-первых, упорядочение столбцов несущественно в таблице. Во-вторых, не может быть одинаковых кортежей или строк в таблице. И, в-третьих, каждый кортеж будет содержать одно значение для каждого из его атрибутов.
Реляционная база данных содержит несколько таблиц, каждая из которых похожа на таковую в «плоской» модели базы данных. Одна из сильных сторон реляционной модели заключается в том, что в принципе любое значение, имеющее место в двух разных записях (принадлежащих к одной таблице или к разным таблицам), подразумевает взаимосвязь между этими двумя записями. Тем не менее, для обеспечения явных ограничений целостности отношения между записями в таблицах также могут быть определены явно, путем идентификации отношений родитель-ребенок, характеризующихся присвоением мощности (1: 1, (0) 1: M, M: M ). Таблицы также могут иметь назначенный единственный атрибут или набор атрибутов, которые могут действовать как «ключ», которые могут использоваться для однозначной идентификации каждого кортежа в таблице.
Ключ, который может использоваться для однозначной идентификации строки в таблице, называется первичным ключом. Ключи обычно используются для объединения или объединения данных из двух или более таблиц. Например, таблица Employee может содержать столбец с именем Location, который содержит значение, соответствующее ключу таблицы Location. Ключи также важны при создании индексов, которые облегчают быстрый поиск данных из больших таблиц. Любой столбец может быть ключом, или несколько столбцов могут быть сгруппированы вместе в составной ключ. Нет необходимости заранее определять все ключи; Столбец можно использовать в качестве ключа, даже если он изначально не был предназначен.
Ключ, который имеет внешний, реальный смысл (например, имя человека, ISBN книги или серийный номер автомобиля), иногда называют «естественным» ключом. Если никакой естественный ключ не подходит (подумайте о многих людей по имени Браун), может быть назначен произвольный или суррогатный ключ (например, указывая идентификационные номера сотрудников). На практике большинство баз данных имеют как сгенерированные, так и естественные ключи, поскольку сгенерированные ключи могут использоваться внутри, чтобы создавать связи между строками, которые не могут сломаться, в то время как естественные ключи можно использовать, менее надежно, для поиска и для интеграции с другими базами данных. (Например, записи в двух независимо разработанных базах данных могут быть сопоставлены номером социального страхования, за исключением случаев, когда номера социального страхования неверны, отсутствуют или изменены).
Наиболее распространенным языком запросов, используемым с реляционной моделью, является язык структурированных запросов (SQL).
Данная модель является специализированной адаптацией реляционной модели, используемой для представления данных в хранилищах данных, таким образом, что данные можно легко суммировать с помощью интерактивной аналитической обработки или запросов OLAP. В размерной модели схема базы данных состоит из одной большой таблицы фактов, которые описываются с использованием измерений и мер. Измерение предоставляет контекст факта (например, кто участвовал, когда и где это произошло, и его тип) и используется в запросах для группировки связанных фактов. Размеры имеют тенденцию быть дискретными и часто являются иерархическими; Например, местоположение может включать здание, штат и страну. Мера - это количество, описывающее факт, такой как доход. Важно, чтобы меры могли быть в значительной степени агрегированы, например, доходы от разных мест могут быть объединены вместе.
В запросе OLAP выбираются измерения, а факты группируются и объединяются вместе для создания сводки.
Размерная модель часто реализуется поверх реляционной модели, используя звездную схему, состоящую из одной высоко нормированной таблицы, содержащей факты, и окружающих денормализованных таблиц, содержащих каждое измерение. Альтернативная физическая реализация, называемая схемой снежинок, нормализует многоуровневые иерархии внутри измерения в несколько таблиц.
Хранилище данных может содержать многомерные схемы, которые обмениваются таблицами измерений, что позволяет использовать их вместе. Составление стандартного набора измерений является важной частью моделирования размеров.
Его высокая производительность сделала размерную модель самой популярной структурой базы данных для OLAP.
Продукты, предлагающие более общую модель данных, чем реляционная модель, иногда классифицируются как пост-реляционные. Альтернативные термины включают «гибридную базу данных», «RDBMS с расширенными объектами» и другие. Модель данных в таких продуктах включает в себя отношения, но не ограничивается информационным принципом Кодда, который требует, чтобы вся информация в базе данных была явно указана с точки зрения значений в отношениях и никоим образом.
Некоторые из этих расширений к реляционной модели объединяют понятия из технологий, которые предшествуют реляционной модели. Например, они позволяют представить ориентированный граф с деревьями на узлах. Немецкая компания sones реализует эту концепцию в своем GraphDB.
Некоторые пост-реляционные продукты расширяют реляционные системы с нереляционными функциями.
Графовые базы данных допускают еще более общую структуру, чем сетевая база данных; Любой узел может быть подключен к любому другому узлу.
Многозначные базы данных являются «кусковыми» данными, поскольку они могут хранить точно так же, как реляционные базы данных, но также позволяют уровень глубины, который реляционная модель может приближать только с помощью подтаблиц. Это почти идентично тому, как XML выражает данные, когда заданное поле / атрибут может иметь несколько правильных ответов одновременно. Многозначность можно рассматривать как сжатую форму XML.
Преимущество заключается в том, что атомарность фактуры (концептуального) и фактуры (представления данных) взаимно однозначна. Это также приводит к меньшему количеству чтений, меньшему количеству проблем с ссылочной целостностью и значительному снижению аппаратного обеспечения, необходимого для поддержки заданного объема транзакций.
В 1990-х годах парадигма объектно-ориентированного программирования применялась к технологии баз данных, создавая новую модель базы данных, известную как базы данных объектов. Это направлено на предотвращение несоответствия объектно-реляционного импеданса - накладные расходы на преобразование информации между ее представлением в базе данных (например, в виде строк в таблицах) и его представление в прикладной программе (как правило, как объекты). Более того, система типов, используемая в конкретном приложении, может быть определена непосредственно в базе данных, позволяя базе данных применять одни и те же инварианты целостности данных. Базы данных объектов также вводят ключевые идеи объектного программирования, такие как инкапсуляция и полиморфизм, в мир баз данных.
Базы данных объектов пострадали из-за отсутствия стандартизации: хотя стандарты были определены ODMG, они никогда не были реализованы достаточно хорошо, чтобы обеспечить совместимость между продуктами. Тем не менее, базы данных объектов успешно использовались во многих приложениях: обычно специализированные приложения, такие как технические базы данных или базы данных молекулярной биологии. Тем не менее, идеи объектной базы данных были восприняты реляционными поставщиками и повлияли на расширения, сделанные для этих продуктов, и действительно на язык SQL.
Альтернативой переходу между объектами и реляционными базами данных является использование библиотеки объектно-реляционного сопоставления (ORM).
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .