Модель данных

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:

  • аспект структуры: методы описания типов и логических структур данных в базе данных;
  • аспект манипуляции: методы манипулирования данными;
  • аспект целостности: методы описания и поддержки целостности базы данных.

Аспект структуры определяет, что из себя логически представляет база данных, аспект манипуляции определяет способы перехода между состояниями базы данных (то есть способы модификации данных) и способы извлечения данных из базы данных, аспект целостности определяет средства описаний корректных состояний базы данных.

Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных[1].

Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т. д.

О терминологии[править | править код]

В литературе, статьях и в обиходной речи иногда встречается использование термина «модель данных» в смысле «схема базы данных» («модель базы данных»). Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе К. Дж. Дейт, М. Р. Когаловский, С. Д. Кузнецов. Модель данных есть теория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. По выражению К. Дейта соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке[1].

М. Р. Когаловский поясняет эволюцию смысла термина следующим образом. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса. Во второй половине 1970-х годов во многих публикациях, посвященных указанным проблемам, для этих целей стал использоваться все тот же термин «модель данных». В настоящее время в научной литературе термин «модель данных» трактуется в подавляющем большинстве случаев в инструментальном смысле (как инструмент моделирования)[2].

Тем не менее, длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных»[3] он определил модель данных как комбинацию трёх компонентов:

  • коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели;
  • коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов, которые законным образом могут появиться в любой такой базе данных;
  • коллекции операций, применимых к таким экземплярам объектов для выборки и других целей[4].

Примеры[править | править код]

Различают как минимум следующие модели данных:

Связи и функции[править | править код]

Система управления базами данных может предоставлять одну или несколько моделей. Оптимальная структура зависит от естественной организации данных приложения и от требований приложения. Большинство систем управления базами данных построены вокруг одной конкретной модели данных, хотя продукты могут предлагать поддержку более чем одной модели.

Различные модели физических данных могут реализовать любую данную логическую модель. Большинство СУБД будут предлагать пользователю некоторый уровень контроля при настройке физической реализации, поскольку выбор, который был сделан, оказывает значительное влияние на производительность.

Модель - это не просто способ структурирования данных: она также определяет набор операций, которые могут выполняться над данными. Реляционная модель, например, определяет такие операции, как 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).

См. также[править | править код]

Примечания[править | править код]

  1. 1 2 Дейт К. Дж. Введение в системы баз данных. — 8-е изд. — М.: «Вильямс», 2006.
  2. М. Р. Когаловский. Абстракции и модели в системах баз данных (недоступная ссылка). Дата обращения 2 марта 2010. Архивировано 13 июня 2008 года.
  3. Codd, E.F. "Data Models in Database Management. Proc. Workshop in Data Abstraction, Databases, and Conceptual Modelling (Michael L. Brodie and Stephen N. Zilles, eds.), Pingree Park, Colo. (June 1980): ACM SIGART Newsletter No. 74 (January 1981); ACM SIGMOD Record 11(2), February 1981; ACM SIGPLAN Notices 16(1), January 1981
  4. Дейт К. Дж. Реляционная модель выдержит испытание временем (пер. с Date, C.J. The relational model will stand the test of time // Intelligent Enterprise, June 1, 1999, Volume 2, Number 8)

Литература[править | править код]

  • Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
  • Когаловский М. Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
  • Когаловский М. Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
  • Цикритзис Д., Лоховски Ф. Модели данных = D. Tsichritzis, F. Lochovsky. Data Models. Prentice Hall, 1982. — М.: Финансы и статистика, 1985. — 344 с.