Моде́ль да́нных, множество допустимых типов данных, а также отношений и операций, определённых на данных этих типов. С математической точки зрения модель данных может трактоваться как алгебраическая система. В информационных технологиях модель данных служит инструментом проектирования, создания и использования баз данных и некоторых других информационных ресурсов.

Понятие модели данных возникло на ранней стадии развития технологий баз данных, а впоследствии стало использоваться и в других областях информационных технологий, например, в веб-технологиях, в технологиях информационных систем, основанных на знаниях, в системах интеграции данных из множества источников. Одной из ранних публикаций, в которой используется понятие модели данных, хотя без какого-либо явного определения, является широко известная статья Э. Кодда (Codd. 1970), описывающая предложенную им реляционную модель данных. Ранее эта работа была опубликована как отчет автора, выполненный в исследовательском центре компании IBM в Сан-Хосе (Калифорния).

Первоначально термин употреблялся как синоним структуры данных конкретной базы данных. Структурная трактовка полностью согласовывалась с математическим определением понятия модели как множества с заданными на нём отношениями, что оправдывало использование этого термина. Она и до сих пор встречается в литературе. Объектом моделирования при этом являются не данные вообще, а конкретная база данных. При такой трактовке модель данных – это результат моделирования базы данных, описание которого называется схемой базы данных (или схемой данных в информационных технологиях, оперирующих иными источниками данных).

В процессе развития теории и технологий баз данных возникла потребность в термине, который обозначал бы не результат, а инструмент моделирования данных, и для этой цели также стали использовать термин «модель данных». Поэтому для корректной трактовки смысла этого термина нужно учитывать контекст использования. Далее будут рассматриваться свойства только моделей данных – инструментов моделирования. Определение, соответствующее пониманию как инструмента моделирования, было предложено в Тьюринговской лекции Э. Кодда (Codd. 1982).

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

Наряду с полнофункциональными моделями данных существуют и широко используются на практике модели данных с неполными функциями, обладающие только дескриптивными средствами – структурным компонентом, например, широко используемая модель «сущность – связь» (ER-модель).

Механизмы, реализующие модели данных, являются ключевыми функциональными компонентами программных продуктов, обеспечивающих управление данными в информационных системах, которые основаны на технологиях баз данных. Такие системы называют системами баз данных, а указанные программные продукты – системами управления базами данных (СУБД).

Модели данных являются также основой автоматизированных систем проектирования баз данных (см. CASE-технологии). В таких системах проектировщик описывает структуру предметной области системы базы данных средствами, удобными для восприятия человеком и независимыми от СУБД, выбранной для разработки системы базы данных. Это может быть некоторая модель данных, например ER-модель, диаграмма классов языка UML, подходящая онтология и др. На основе созданного описания, называемого концептуальной схемой предметной области, автоматически генерируется схема базы данных, представленная средствами той модели данных, которая поддерживается выбранной целевой СУБД.

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

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

Для поддержки иерархии абстракции данных механизмы каждого уровня многоуровневой архитектуры СУБД реализуют некоторую модель данных, обеспечивающую соответствующее представление данных и операции над ними её средствами. Кроме того, СУБД обладает механизмами отображения моделей данных между смежными уровнями многоуровневой архитектуры. Операции над данными более высокого уровня архитектуры отображаются с помощью таких механизмов в соответствующие операции над соответствующими данными более низкого уровня до тех пор, пока процесс отображения не достигнет операций над реально хранимыми данными, представленными на нижнем уровне архитектуры. На каждом из более верхних уровней данные формируются, когда они необходимы, из данных смежных нижних уровней в соответствии с их описанием. Каждая группа специалистов, имеющих дело с системой базы данных, взаимодействует с соответствующим ей уровнем архитектуры СУБД, на котором поддерживается представление данных, адекватное её потребностям. Благодаря такому подходу пользователь системы базы данных избавлен от необходимости знать, как реально хранится база данных во внешней памяти. Кроме того, он «видит» только ту часть базы данных, которая ему нужна, и она может быть представлена совсем не так, как «выглядит» полная база данных.

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

Можно различными способами охарактеризовать конкретную модель данных и описать её функциональность. Например, это можно сделать вербально на естественном языке. Некоторые модели могут быть описаны формализованным образом. Так, для реляционной модели Э. Кодд предложил строгое математическое описание. Однако для практического использования в технологиях управления данными модель данных должна быть представлена в виде специальных языковых средств – набора строго определенных искусственных языков или единого языка, определяющих функциональные возможности её структурного и операционного компонентов.

Структурный компонент модели данных представляется языком описания (определения) данных. Средствами такого языка определяются схемы баз данных, которыми способна управлять используемая СУБД. Операционный компонент модели данных может быть ориентирован на т. н. конечного пользователя – пользователя, взаимодействующего с системой базы данных в интерактивном режиме, или на пользователя-программиста, разрабатывающего приложения системы базы данных. Языки, предназначенные для конечного пользователя, называются языками запросов. Они позволяют осуществлять поиск, выборку, обновление или удаление данных из базы данных. Некоторые языки запросов дают возможность также генерировать различные агрегированные или статистические данные. Языки, предназначенные для пользователей-программистов, называются языками манипулирования данными. Для них создаются связывания с традиционными языками программирования, в среде которых используются их функции – вставка, обновление, удаление, выборка данных, навигация по структуре базы данных (для графовых моделей) и др.

Со времени рождения технологий баз данных (начало 1960-х гг.) было создано множество разнообразных моделей данных для прикладных применений, многие из которых продолжают использоваться в настоящее время, а также для исследовательских целей. Главные их различия заключаются в том, для какого уровня архитектуры СУБД они предназначены, в парадигме моделирования, на которой они основаны, в степени формализованности и уровне семантики данных, которые они позволяют представлять, в особенностях их структурного и операционного компонентов, универсальности или специализированности области применения.

Далее рассматриваются некоторые наиболее известные модели данных:

• Графовая модель. Модель данных, в которой допустимые структуры данных могут быть представлены в виде графа общего или какого-либо специального вида, например в виде дерева. Необходимую группу операций в языке манипулирования данными, основанном на такой модели, представляют навигационные операции. Операции над данными здесь имеют позаписный (англ. Record-by-Record), не множественный характер. К графовым моделям относятся, в частности, иерархическая модель, сетевая модель данных CODASYL, RDF-модели, т. е. модели, основанные на RDF-графах.

• Модель «сущность – связь». Модель данных, кратко называемая ER-моделью (от англ. Entity-Relationship Model) и предназначенная, по замыслу автора, для описания модели предметной области в процессе проектирования базы данных. Однако эта модель была использована позднее также в ряде экспериментальных СУБД. Основными элементами ER-модели являются именованные множества сущностей, множества связей между ними, которые могут быть двуместными или многоместными, ориентированными или неориентированными. Сущности и связи обладают атрибутами. В модели вводится ограничение целостности данных – зависимость по существованию, ассоциируемое с двумя множествами сущностей. Это ограничение является близким по смыслу к ограничению целостности по ссылкам в реляционной модели.

• Иерархическая модель. Модель данных, в основе которой используется иерархическая древовидная структура данных. Вершинами этой структуры являются записи различных типов, называемые сегментами и состоящие из простых элементов данных различных типов. При этом родительской записи соответствует произвольное число экземпляров подчиненных записей каждого типа. Экземпляр записи каждого типа идентифицируется уникальным ключом, определенным для этого типа. База данных представляет собой совокупность таких деревьев. В модели данных предусматриваются навигационные операции по структуре базы данных и операция поиска сегмента. Поддерживается концепция текущего состояния – вершины дерева структуры данных (в терминах экземпляров, а не типов), достигнутая в результате последней выполненной навигационной операции. Навигационные операции могут использовать идентификацию целевой записи относительно этого текущего состояния. Наряду с навигационными операциями поддерживаются операции манипулирования данными – вставка, обновление и удаление записей с естественным каскадным распространением операции удаления. Иерархическая модель данных активно использовалась во многих СУБД на платформе мейнфреймов до появления реляционных систем. Наиболее известным её представителем является модель данных СУБД IMS компании IBM, первая версия которой была разработана в конце 1960-х гг.

• Сетевая модель данных CODASYL. Модель данных, начальная версия которой была конструктивно описана Рабочей группой по базам данных CODASYL в её отчете, выпущенном в 1969 г. В отчете были впервые высказаны концепции многоуровневой архитектуры СУБД, представлен полный комплекс языковых средств описания данных и манипулирования данными, связанных со всеми архитектурными уровнями СУБД. В дальнейшем предложенные языковые спецификации получили серьёзное развитие в работах образованного для этой цели Комитета по языку описания данных CODASYL, а также ряда других комитетов, действующих в рамках этой организации. Эта модель относится к категории графовых моделей, представляет собой разновидность сетевой модели данных. Имеет дело со структурами данных, конструируемыми из записей, которые подобны по своей структуре записям языка COBOL, и связей вида «N:1», причем все экземпляры записей – участников связи соединяются в список. Такие структуры данных называются наборами CODASYL, или просто наборами. Записи и наборы типизируются. База данных состоит из экземпляров типов наборов и экземпляров типов записей, описанных в схеме. Экземпляр типа записи может принадлежать многим наборам, но только не нескольким экземплярам наборов одного типа, или не принадлежит никакому набору. В модели предусмотрены средства навигации и манипулирования данными такой структуры.

• Реляционная модель Э. Кодда. Модель данных, основанная на математическом понятии отношения и представлении отношений в форме таблиц. Операционные возможности модели имеют две эквивалентные формы – в терминах реляционной алгебры и реляционного исчисления. В отличие от других её версий, модель, опубликованная в (Codd. 1970), получила название базовой реляционной модели. Позднее (1979) Э. Кодд опубликовал  расширенную реляционную модель RM/T, значительно обогатившую базовую версию. Были предложены важные дополнения, включенные позднее в стандарт SQL, касающиеся, в частности, ограничений целостности по ссылке. Благодаря простоте и естественности структуры данных и манипулятивных операций, полной независимости от среды хранения данных, поддержке виртуальных, а не физических связей между данными (на основе значений данных, а не указателей), существованию её строгого формального определения реляционная модель позволила сформировать развитую математическую теорию основанных на ней баз данных, а СУБД, поддерживающие реляционную модель, заняли доминирующее положение среди инструментальных средств разработки систем баз данных. Компания IBM, сотрудником которой являлся Э. Кодд, разработала язык SEQUEL, воплощающий функциональность предложенной реляционной модели и послуживший в дальнейшем прототипом стандарта SQL. Хотя SQL квалифицируется как язык запросов, он является единым полнофункциональным языком модели данных, обладающим как дескриптивными (структурный компонент модели), так и операционными возможностями. В действующей версии стандарта ISO этого языка он воплощает объектно-реляционную модель данных. Эта гибридная модель сочетает возможности реляционных моделей с объектными свойствами данных. Стандарт включает также ряд расширений: для создания темпоральных систем баз данных, для интерактивной аналитической обработки данных (OLAP), а также средства связывания для ряда традиционных, в частности объектных, языков программирования.

• Темпоральная модель данных. Модель данных, предусматривающая поддержку концепции времени. Развитые модели такого рода поддерживают концепцию двумерного времени. При этом различаются действительное время – время, когда факт имел место в реальности, и время транзакции – время, когда факт помещается в систему. Вместе с тем возможно использование и третьего аспекта времени – времени, определяемого пользователем. Это измерение времени не поддерживается моделью, и интерпретация таких временных свойств является заботой пользователя или приложения. Концепция двумерного времени была впервые предложена еще в 1981 г. в дипломной работе студента Калифорнийского университета UCLA Я. Бен-Цви (J. Ben-Zvi).

• Объектная модель. Модель данных, многочисленные разновидности которой получили широкое распространение в области программирования, баз данных и информационных систем. Основное понятие таких моделей – понятие объекта, т. е. сущности, обладающей состоянием и поведением. Состояние объекта определяется совокупностью его атрибутов, которые могут принимать значения предписанных типов. Поведение, в свою очередь, определяется совокупностью операций (методов), специфицированных для этого объекта. Для объектов поддерживается их индивидуальность, которая не изменяется при изменении состояния объекта. Принципиально важно, что различаются интерфейсы объектов и их реализации. Интерфейс определяет свойства объекта, видимые пользователю, – его свойства и сигнатуры операций. Реализация определяет внутренние свойства объекта, которые инкапсулируются интерфейсом и остаются скрытыми от пользователя. Объекты в объектных моделях типизируются. Различаются встроенные типы объектов – объектов с предопределенными свойствами, и типы объектов, определяемые пользователем. Предусматривается наследование свойств типа объектами подтипа. Разработаны также объектные модели, которые наряду с атомарными типами объектов поддерживают сложные типы – контейнеры и типы-коллекции. Стандартом де-факто объектной модели для систем баз данных стал стандарт ODMG.

• Многомерная модель. Модель данных, оперирующая многомерными представлениями данных (в виде гиперкуба). Разновидности многомерной модели стали широко использоваться в середине 1990-х гг. в связи с развитием технологий OLAP. Основные понятия такой модели – измерение и ячейка. Каждое измерение представляет собой множество однородных значений данных, образующее грань гиперкуба. Примерами измерений являются годы, месяцы, кварталы, регионы, города, районы, названия предприятий, виды продукции и т. п. Измерения играют роль индексов, совокупности значений которых идентифицируют в гиперкубе конкретные его ячейки, или осей координат в многомерной системе координат гиперкуба. Ячейки (называемые также показателями) представляют собой, как правило, числовые величины. Операционные возможности многомерных моделей данных, используемых в OLAP, ориентированы на поддержку анализа данных. Предусматривается конструирование разнообразных агрегаций данных в рамках заданного гиперкуба, построение различных его проекций – подмножеств гиперкуба, полученных путем фиксации значений каких-либо измерений, детализация (дезагрегация) и вращение (изменение порядка измерений) данных, а также ряд других операций.

• Модели данных СУБД NoSQL. Как альтернатива системам баз данных SQL, с начала 2000-х гг. развивается направление NoSQL. Основное внимание при этом уделяется системам баз данных, которые предназначены для хранения и анализа больших объемов неструктурированной информации, а также для распределённого хранения. Для СУБД NoSQL нет какой-либо стандартизованной модели данных, и для каждой пользователю необходимо осваивать её программное обеспечение. В отличие от реляционных баз данных, структура данных не регламентирована (или слабо типизирована, если проводить аналогии с языками программирования) – можно включать новые элементы структуры и задавать их значения без предварительного соответствующего изменения схемы базы данных.

• Модель данных XML. В процессе развития веб-технологий в 1990-х гг. начал создаваться Консорциумом Всемирной паутины (англ. World Wide Web Consortium – W3C) и использоваться на практике комплекс новых стандартов веб-технологий – стандартов XML. Эти стандарты нашли применение и в технологиях баз данных. Стали разрабатываться системы баз данных XML. При этом использовалось несколько различных моделей данных с языком описания данных DTD или XML Schema. Наиболее распространенным является вариант модели, представленной совокупностью языка DTD в этой функции и языка запросов XQuery.

Важность роли моделей данных в технологиях баз данных подтверждается тем фактом, что за работы в области разработки моделей данных одной из самых престижных наград в области информатики – премии Тьюринга, присуждаемой международной организацией Ассоциация вычислительной техники (англ. Association for Computing Machinery – ACM) – в разное время были удостоены идеолог сетевой модели данных CODASYL Ч. Бахман (1973) и создатель реляционной модели Э. Кодд (1981).