Модели представления данных: Комплексный академический анализ исторической эволюции, теоретических основ и современных парадигм

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

Данная работа представляет собой комплексный академический анализ моделей представления данных, начиная с их исторической эволюции и фундаментальных теоретических принципов, заканчивая современными парадигмами и будущими тенденциями. Мы углубимся в формальные определения, рассмотрим архитектурные особенности каждой модели, проведем критический анализ их преимуществ и недостатков, а также исследуем влияние выбора модели на ключевые аспекты проектирования, производительности и масштабируемости информационных систем. Цель — предоставить исчерпывающий и структурированный материал, который послужит надежной базой для дальнейших исследований и практического применения.

Фундаментальные принципы и историческая эволюция моделей данных

История развития технологий баз данных — это летопись постоянного поиска наиболее эффективных способов организации и обработки информации. В этом поиске ключевую роль играет эволюция моделей данных, которые, по сути, являются концептуальными каркасами для построения цифровых хранилищ. Именно понимание их исторического контекста позволяет оценить причины появления каждой новой парадигмы и ее вклад в общую копилку знаний.

Понятие и компоненты модели данных: Вклад Кодда и Дейта

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

Важно различать модель данных как теоретический инструмент и схему базы данных как его конкретную реализацию. Модель данных — это универсальная теория, набор правил и абстракций, в то время как схема базы данных — это конкретный «чертеж» или «план», созданный с помощью этой модели для определенной предметной области. Иными словами, модель данных — это язык, а схема базы данных — это произведение, написанное на этом языке.

Одним из первых, кто формально подошел к определению модели данных, был Эдгар Франк Кодд (Э.Ф. Кодд) — «отец» реляционной модели. Он определил модель данных как комбинацию из трех взаимосвязанных компонентов:

1. Коллекция типов объектов данных: Описание элементов, которые могут быть представлены в базе данных (например, сущности, их атрибуты).
2. Коллекция общих правил целостности: Набор ограничений, которые должны соблюдаться для обеспечения корректности и непротиворечивости данных.
3. Коллекция операций: Допустимые действия над данными, позволяющие их создавать, изменять, удалять и извлекать.

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

• Структурная часть: Определяет методы описания типов и логических структур данных. Это то, как данные организуются и представляются пользователю (например, в виде таблиц, деревьев или графов).
• Манипуляционная часть: Определяет методы манипулирования данными. Это набор операций, которые позволяют изменять состояния базы данных (обновление, удаление, добавление) и извлекать необходимую информацию.
• Целостная часть: Определяет средства описания и поддержки корректных состояний базы данных. Сюда относятся правила, которые гарантируют, что данные остаются согласованными и правильными, несмотря на все операции.

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

Хронология развития технологий баз данных

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

1950-е годы: Предвестники баз данных. Все началось в 1950-х годах с появлением первых магнитных дисков, которые стали революцией в хранении данных. Знаковым событием стал выпуск в 1956 году исследовательской лабораторией IBM системы IBM 305 RAMAC (Random Access Method of Accounting and Control). Эта система использовала 50 вращающихся дисков диаметром 24 дюйма для хранения до 5 мегабайт данных – по тем временам это был колоссальный объем! RAMAC стал первым коммерческим компьютером, который позволил осуществлять прямой доступ к данным, а не только последовательный, что заложило основы для будущих систем управления данными.

1960-е годы: Рождение иерархических систем. С началом 1960-х годов возникла острая потребность в более сложных программных средствах для управления большими объемами взаимосвязанных данных. В 1966 году компания IBM, в сотрудничестве с Rockwell и Caterpillar, спроектировала иерархическую СУБД IMS (Information Management System). Изначально IMS разрабатывалась для обеспечения программы Apollo, а именно для реализации системы управления запасами. Эта система требовала невероятно надежного и эффективного способа управления огромным количеством компонентов и сборочных единиц, что и определило ее иерархическую структуру. Официальной датой выпуска IMS считается 14 августа 1968 года, и она до сих пор используется в некоторых крупных корпоративных системах.

1970 год: Реляционная революция Кодда. Переломным моментом в истории баз данных стал 1970 год, когда Эдгар Франк Кодд, работая в IBM, опубликовал свою знаковую работу «A Relational Model of Data for Large Shared Data Banks». Эта статья, часто называемая «Меморандумом 1970 года», представила миру реляционную модель данных, основанную на строгих математических принципах теории множеств и логики. Идеи Кодда были настолько мощными и элегантными, что они стимулировали целый ряд математических исследований. Впоследствии К. Дж. Дейт, наряду с другими учеными, развивал принципы реляционной модели, а также были созданы теории нормальных форм, которые углубили понимание структуры и целостности данных. Это стало основой для большинства современных СУБД.

1975 год: Стандарт CODASYL для сетевой модели. Пока Кодд продвигал реляционную модель, другая группа, Ассоциация CODASYL (Conference of Data System Languages), разрабатывала свои подходы. В 1975 году CODASYL выпустила «CODASYL Data Base Task Group Report» (DBTG Report), который стал первым стандартом для систем управления базами данных, определившим фундаментальные понятия для сетевой модели данных. Этот стандарт описывал способ организации данных с помощью более гибких связей, чем в иерархических системах, позволяя одной записи иметь несколько «родителей».

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

Классические модели данных: Архитектура, принципы и критический анализ

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

Иерархическая модель данных

Иерархическая модель данных представляет собой один из старейших и наиболее интуитивно понятных способов организации информации, основанный на концепции «родитель-потомок».

Архитектура и принципы работы:
В этой модели информация организуется в виде древовидной иерархии (ориентированного графа), где каждый элемент данных, за исключением корневого, может иметь только одного «родителя», но при этом может иметь сколько угодно «потомков». Основными информационными единицами являются сегмент и поле. Поле данных определяется как наименьшая неделимая единица данных, доступная пользователю. Сегмент же представляет собой логическую группу полей. Для каждого сегмента определяются его тип и экземпляры, формируемые из конкретных значений полей.

• Ключи: Корневая запись каждого дерева обязательно должна содержать ключ с уникальным значением, что позволяет однозначно идентифицировать каждое иерархическое дерево. Ключи некорневых записей должны иметь уникальное значение только в рамках группового отношения со своим родителем. Каждая запись в иерархической модели идентифицируется полным сцепленным ключом, который представляет собой совокупность ключей всех записей от корневой по иерархическому пути до данной записи.
• Операции манипулирования: Основные операции включают поиск записей, навигацию (переход от потомка к предку и от предка к потомку), а также операции по изменению данных: включение, удаление и модификация записей, и включение/удаление записей связей.
• Целостность: Автоматически поддерживается целостность ссылок между предками и потомками, с основным правилом: никакой потомок не может существовать без своего родителя. Удаление родителя автоматически приводит к удалению всех его потомков.

Достоинства и недостатки:

Критерий	Достоинства	Недостатки
Эффективность	Более эффективное использование памяти и простое хранение данных без сложной структуры, особенно для систем с пакетной обработкой. Более быстрое время выполнения CRUD-операций (особенно поиска и чтения) при хорошо предсказуемых путях доступа.	Требуется много памяти для хранения по сравнению с реляционными моделями из-за дублирования данных, особенно при наличии связей «многие-ко-многим». Низкая скорость операций записи, так как каждое изменение может потребовать обновления нескольких связанных сегментов.
Целостность	Автоматическое поддержание ссылочной целостности «родитель-потомок».	Сложно контролировать общую целостность данных из-за дублирования.
Гибкость	Простота навигации по предопределенным путям.	Огромные трудности при реорганизации структуры (иерархии). Невозможность прямого представления связей «многие-ко-многим», что приводит к избыточности данных или сложным обходным путям.
Сложность	Простая для понимания при естественной иерархии данных (например, файловая система).	Сложность запросов, выходящих за рамки предопределенных иерархических путей.

Сетевая модель данных

Сетевая модель данных возникла как попытка преодолеть ограничения иерархической модели, прежде всего, невозможность прямого представления связей «многие-ко-многим».

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

• Элементы: Сетевая модель состоит из набора экземпляров определенного типа записи (аналог сегмента в иерархической модели) и набора экземпляров определенного типа связей между этими записями. Тип связи определяется для двух типов записи: предка (владельца) и потомка (члена). Экземпляр типа связи состоит из одного экземпляра типа записи предка и упорядоченного набора экземпляров типа записи потомка.
• Стандарт CODASYL: Основные принципы сетевой модели данных были разработаны в середине 60-х годов, а эталонный вариант описан в отчетах рабочей группы CODASYL (1971 г.), которые стали де-факто стандартом для сетевых СУБД.
• Операции манипулирования: Набор операций включает поиск конкретной записи, навигацию по связям (переход от предка к первому потомку, к следующему потомку, от потомка к предку), а также стандартные операции по изменению данных: создать/уничтожить/модифицировать запись, включить/исключить из связи, переставить в другую связь.
• Целостность: Целостность данных обеспечивается поддержанием целостности по ссылкам между владельцем отношения и членом отношения.

Достоинства и недостатки:

Критерий	Достоинства	Недостатки
Гибкость	Возможность представления сложных связей «многие-ко-многим», что было значительным шагом вперед по сравнению с иерархической моделью.	Высокая сложность и жесткость схемы БД. Изменение структуры БД практически всегда ведет к перестройке всей базы данных и приложений, что крайне затратно.
Производительность	Возможность эффективной реализации по показателям затрат памяти и оперативности по сравнению с реляционными системами того времени, особенно для данных со сложными, нестандартными связями.	Высокая сложность написания запросов и навигации по данным.
Целостность	Обеспечивает атрибутивную целостность (каждое поле имеет допустимое значение) и ссылочную целостность в рамках отношений «владелец-член».	Сложность обеспечения целостности при изменении сложных графовых структур.

Реляционная модель данных

Реляционная модель данных стала настоящей революцией в мире баз данных, предложив математически строгий и элегантный подход к организации информации, радикально изменивший принципы проектирования и взаимодействия с данными.

Архитектура и принципы работы:
Предложена Э.Ф. Коддом в 1970 году как средство структурирования данных, основанное на строгих математических принципах теории множеств и логики первого порядка. Ключевая идея — представление данных в виде двумерных таблиц, которые Кодд назвал «отношениями» (англ. relations).

• Структурная часть: Постулирует, что единственной структурой данных, используемой в реляционной модели, является нормализованное n-арное отношение (таблица). Это означает, что каждая таблица состоит из строк (кортежей) и столбцов (атрибутов), где каждый столбец содержит значения одного типа данных, а каждая строка уникальна. Порядок строк и столбцов не имеет значения.
• Манипуляционная часть: Описывает два эквивалентных способа манипулирования реляционными данными: реляционную алгебру (процедурный язык, описывающий, как получить результат) и реляционное исчисление (декларативный язык, описывающий, что нужно получить). Эти математические аппараты обеспечивают мощные и гибкие средства для выполнения запросов и модификации данных.
• Целостная часть: Описывает ограничения специального вида, которые должны выполняться для любых отношений:
  • Целостность сущностей: Любой кортеж должен быть отличим от другого. Это обеспечивается наличием первичного ключа — одного или нескольких атрибутов, значения которых уникально идентифицируют каждую строку таблицы и не могут быть NULL.
  • Целостность по ссылкам (внешним ключам): Если отношение включает внешний ключ, то его значения должны либо совпадать со значениями первичного ключа в связанном отношении, либо быть NULL. Это гарантирует, что ссылки между таблицами всегда корректны.

Достоинства и недостатки:

Критерий	Достоинства	Недостатки
Простота и понятность	Данные представляются в виде интуитивно понятных таблиц, что упрощает их восприятие для пользователя.	Далеко не всегда предметная область может быть представлена в виде таблиц без потерь или искусственных усложнений (особенно для сложных, слабоструктурированных данных).
Математическая база	Строгие правила проектирования, основанные на математическом аппарате (реляционная алгебра, исчисление, теория нормализации), обеспечивают высокую надежность и непротиворечивость данных.	Для определенных типов запросов (особенно с большим количеством соединений) и больших объемов данных может наблюдаться относительно низкая скорость доступа и большой объем внешней памяти.
Независимость данных	Полная независимость логической и физической организации данных от прикладных программ, что минимизирует изменения в прикладной программе при изменении реляционной БД.	Сложность описания иерархических и сетевых связей, так как их приходится моделировать с помощью внешних ключей и рекурсивных запросов, что усложняет логику и снижает производительность.
Целостность	Мощные механизмы обеспечения целостности (первичные, внешние ключи, уникальные ограничения, триггеры).	Трудность понимания структуры данных из-за появления большого количества таблиц (до нескольких сотен и даже тысяч в сложных корпоративных системах) в результате логического проектирования и нормализации.

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

Фундаментальный инструментарий реляционной модели: Алгебра и нормализация

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

Реляционная алгебра: Основные операции

Реляционная алгебра — это не просто набор команд, а формальный, теоретический язык операций, который на основе одного или нескольких отношений (таблиц) позволяет создавать другое отношение, не изменяя при этом исходных данных. Ключевое свойство реляционной алгебры — её замкнутость: результатом любой операции над отношениями всегда является ещё одно отношение. Это позволяет строить сложные запросы путем последовательного применения операций.

Э. Кодд предложил восемь основных операций реляционной алгебры, которые можно разделить на две категории: теоретико-множественные и специальные реляционные.

1. Теоретико-множественные операции (применимы к отношениям с одинаковой схемой):

• Объединение (Union, R ∪ S): Операция логического «ИЛИ». Результатом является отношение, содержащее все кортежи, принадлежащие либо первому, либо второму исходным отношениям, либо обоим одновременно, без дублирования.
  • Пример: Объединение таблицы «Студенты_ИТ_факультета» и «Студенты_Мат_факультета» даст список всех студентов, обучающихся на этих факультетах.
• Разность (Difference, R — S): Результатом является отношение, содержащее множество кортежей, принадлежащих R и не принадлежащих S.
  • Пример: Разность «Все_студенты» и «Выпускники» даст список текущих студентов.
• Пересечение (Intersection, R ∩ S): Операция логического «И». Результатом является отношение, которое содержит множество кортежей, принадлежащих одновременно и первому, и второму отношениям.
  • Пример: Пересечение «Студенты_с_отличием» и «Студенты_активисты» даст список студентов, являющихся отличниками и активистами.
• Декартово произведение (Cartesian Product, R × S): Определяет новое отношение, которое является результатом конкатенации каждого кортежа отношения R с каждым кортежем отношения S. Это мощная, но потенциально очень объемная операция, часто используемая как база для других операций.
  • Пример: Декартово произведение «Преподаватели» и «Курсы» создаст все возможные комбинации преподавателей и курсов.

2. Специальные реляционные операции (работают с одним или двумя отношениями):

• Выборка (Selection, σ_{условие}(R)): Возвращает отношение, содержащее все кортежи из заданного отношения, которые удовлетворяют указанным условиям. Это операция, фильтрующая строки.
  • Пример: σ_{Возраст > 25}(Сотрудники) — выборка всех сотрудников старше 25 лет.
• Проекция (Projection, π_{список_атрибутов}(R)): Возвращает отношение, содержащее все кортежи (подкортежи) заданного отношения, которые остались в этом отношении после исключения из него некоторых атрибутов. Это операция, фильтрующая столбцы и удаляющая дубликаты строк.
  • Пример: π_{Имя, Фамилия}(Студенты) — получение списка имен и фамилий всех студентов.
• Соединение (Join, R ⋈_{условие} S): Возвращает отношение, содержащее все возможные кортежи, которые представляют собой комбинацию атрибутов двух кортежей, принадлежащих двум заданным отношениям, при условии совпадения значений в общих атрибутах (для эквисоединения). Существуют различные типы соединений (естественное, внешнее, полусоединение и т.д.).
  • Пример: Соединение таблиц «Заказы» и «Клиенты» по атрибуту «CustomerID» позволяет получить информацию о клиенте для каждого заказа.
• Деление (Division, R ÷ S): Более сложная операция, которая находит кортежи в отношении R, которые связаны со всеми кортежами в отношении S. Часто используется для запросов типа «найти всех поставщиков, которые поставляют все детали».
  • Пример: Если R — (Студент, Курс), S — (Курс), то R ÷ S найдет студентов, которые взяли все курсы из S.

Понимание реляционной алгебры критически важно, так как она лежит в основе всех языков запросов к реляционным СУБД, включая SQL.

Нормальные формы: От 1НФ до 5НФ

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

Нормальная форма (НФ) базы данных — это набор правил и критериев, которым должна отвечать база данных. Каждая следующая нормальная форма содержит более строгие правила и критерии, устраняя определенный набор аномалий. Общепринятой стандартной практикой является достижение как минимум третьей нормальной формы (3НФ), поскольку 3НФ эффективно устраняет большинство аномалий данных, связанных с избыточностью и транзитивными зависимостями, без чрезмерного усложнения структуры.

Рассмотрим основные нормальные формы:

• Первая нормальная форма (1НФ):
  • Условие: Отношение находится в 1НФ, если все его атрибуты являются простыми (атомарными), все используемые домены содержат только скалярные значения, и в таблице не должно быть повторяющихся строк.
  • Суть: Устраняет повторяющиеся группы и гарантирует, что каждая «ячейка» таблицы содержит одно значение.
• Вторая нормальная форма (2НФ):
  • Условие: Отношение находится в 1НФ, и каждый неключевой атрибут должен зависеть от всего первичного ключа. Если первичный ключ составной (состоит из нескольких атрибутов), то ни один неключевой атрибут не должен зависеть только от части первичного ключа.
  • Суть: Устраняет частичные зависимости, когда неключевой атрибут зависит только от части составного первичного ключа.
• Третья нормальная форма (3НФ):
  • Условие: Отношение находится в 2НФ, и отсутствуют транзитивные функциональные зависимости неключевых атрибутов от ключевых. То есть, неключевой атрибут не должен зависеть от другого неключевого атрибута.
  • Суть: Устраняет транзитивные зависимости, когда один неключевой атрибут определяет другой неключевой атрибут.
• Нормальная форма Бойса-Кодда (BCNF):
  • Условие: Является более строгой версией 3НФ. Отношение находится в BCNF, если для каждой нетривиальной функциональной зависимости X → Y, X является суперключом. BCNF применима, когда отношение имеет два или более составных потенциальных ключа, которые пересекаются.
  • Суть: Устраняет аномалии, которые могут оставаться в 3НФ, если в таблице есть несколько перекрывающихся потенциальных ключей.
• Четвертая нормальная форма (4НФ):
  • Условие: Отношение находится в BCNF и не содержит многозначных зависимостей.
  • Суть: Применяется для дальнейшей нормализации в исключительно больших системах (например, в крупных распределенных базах данных с миллионами пользователей и сложными многомерными зависимостями) на сверхбыстродействующих компьютерах. Цель — максимальное сокращение объемов данных за счет устранения многозначных зависимостей.
• Пятая нормальная форма (5НФ):
  • Условие: Отношение находится в 4НФ и не содержит зависимостей соединения без потерь.
  • Суть: Наивысшая нормальная форма, предназначенная для устранения зависимостей соединения (join dependencies) без потерь, которые возникают, когда отношение можно разложить на несколько более мелких отношений, а затем восстановить без потери информации. Её применение также характерно для специализированных, сверхмасштабных систем.

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

Современные модели данных: Новые парадигмы и их особенности

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

Объектно-ориентированная модель данных (ООМД)

В середине 80-х годов, с расцветом объектно-ориентированного программирования (ООП), возникла идея перенести его принципы в мир баз данных. Так появилась объектно-ориентированная модель данных (ООМД), стремящаяся преодолеть «разрыв импеданса» между объектно-ориентированными языками программирования и реляционными СУБД.

Архитектура и принципы работы:
В ООМД при представлении данных имеется возможность идентифицировать отдельные записи базы (объекты) с помощью уникальных объектных идентификаторов (OID). Записи БД и функции их обработки (методы) тесно связаны механизмами, подобными соответствующим средствам в объектно-ориентированных языках программирования (например, SmallTalk, C++ или Java).
Структура объектной модели описывается с помощью трех ключевых понятий объектной парадигмы:

• Инкапсуляция: Означает, что каждый объект обладает внутренним состоянием (хранит данные) и набором методов, через которые можно получить доступ к данным или изменить их. Внутренняя реализация скрыта от внешнего мира, что повышает безопасность и упрощает модификацию.
• Наследование: Подразумевает возможность создавать новые классы (подклассы) из существующих (суперклассов), которые наследуют структуру (атрибуты) и поведение (методы) своих предков. Это способствует повторному использованию кода и организации данных в иерархические структуры.
• Полиморфизм: Позволяет различным объектам по-разному реагировать на одинаковые внешние события или вызовы методов в зависимости от их класса и реализации.

Целостность: Для поддержания целостности объектно-ориентированный подход предлагает автоматическое поддержание отношений наследования, возможность объявить поля данных и методы объекта «скрытыми» (принцип инкапсуляции), а также создание процедур контроля целостности внутри самого объекта.

Достоинства и недостатки:

Критерий	Достоинства	Недостатки
Моделирование	Позволяет представлять сложные объекты и их взаимосвязи более непосредственным и естественным образом, чем реляционные системы, что особенно ценно для приложений, работающих со сложными, иерархически структурированными данными (CAD/CAM, мультимедиа, ГИС).	Отсутствие общих декларативных средств манипулирования данными (как реляционная алгебра или исчисление) приводит к тому, что запросы приходится писать на процедурных языках.
Интеграция	Устраняет «разрыв импеданса» между объектно-ориентированными приложениями и базой данных, упрощая разработку.	Проблема их оптимизации возлагается на программиста, что увеличивает сложность разработки и может приводить к менее эффективному выполнению запросов по сравнению с оптимизаторами реляционных СУБД.
Производительность	Для навигации по сложным объектным графам ООМД может быть быстрее реляционных, так как не требует дорогостоящих операций соединения.	Отсутствие мощных непроцедурных средств извлечения объектов из базы приводит к снижению производительности и усложнению программного кода, так как разработчикам приходится вручную управлять навигацией по связям между объектами.

Объектно-реляционная модель данных (ОРМД)

Объектно-реляционная модель данных (ОРМД), или Extended Relation Data Model (ERDM), стала попыткой найти золотую середину между строгой структурой реляционной модели и гибкостью объектно-ориентированной парадигмы. Она унаследовала простоту структуры реляционных моделей, но включила в себя основные достоинства объектно-ориентированного подхода.

Архитектура и принципы работы:
ОРМД основана на стратегии реляционной модели, но использует заимствования и методы, свойственные объектно-ориентированному подходу. Классическая реляционная модель предполагает неделимость (атомарность) данных, хранящихся в полях записей таблиц (первая нормальная форма). ОРМД снимает это ограничение, допуская объектно-ориентированное построение БД с использованием известных и, что особенно важно, новых типов данных, которые могут быть сложными, структурированными, включать в себя коллекции или даже методы.

• Пользовательские типы данных: ОРСУБД позволяют создавать пользовательские типы данных, которые могут содержать как атрибуты, так и методы. Это позволяет хранить в полях таблицы не просто скалярные значения, а целые объекты.
• Вложенные таблицы и массивы: Возможность использовать вложенные таблицы (коллекции) или массивы в качестве значений атрибутов, что позволяет представлять иерархические и сложные структуры данных без строгой нормализации в отдельные таблицы.
• Наследование: Некоторые ОРСУБД поддерживают наследование типов данных, позволяя создавать иерархии объектов.

Достоинства и недостатки:

Критерий	Достоинства	Недостатки
Выразительность	Возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей, что обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки. Способность обрабатывать более сложные структуры данных, такие как пользовательские типы, вложенные таблицы и массивы, JSON, XML и геометрические данные, повышая выразительность моделирования.	Сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных. Возникает из-за необходимости согласования реляционных принципов (строгая схема, нормализация) с объектными (инкапсуляция, наследование), что может привести к более сложным правилам валидации и управлению ограничениями.
Совместимость	Позволяет использовать накопленные знания и опыт работы с реляционными СУБД, одновременно расширяя их возможности. Стандарты SQL:1999 и SQL:2003 зафиксировали объектные расширения языка SQL, что облегчило их внедрение.	Потенциальная сложность для разработчиков, которые должны понимать как реляционные, так и объектные концепции.
Примеры:	PostgreSQL является одной из первых полностью функциональных объектно-реляционных СУБД, которая, помимо стандартных типов данных, может работать с финансовой информацией, сетевыми адресами, JSON, XML и геометрическими данными, а также позволяет создавать свои типы данных.	Может быть избыточной для простых задач, где достаточно чистой реляционной или NoSQL модели.

NoSQL модели данных (Not only SQL)

В начале XXI века, с появлением концепции Big Data и развитием масштабных веб-сервисов, традиционные реляционные СУБД столкнулись с беспрецедентными вызовами. Это привело к рождению движения NoSQL — не просто «без SQL», а скорее «не только SQL».

Архитектура и принципы работы:
NoSQL — это общее название технологий управления нереляционными базами данных, разработанных для решения проблем, связанных с хранением, извлечением и обработкой больших объемов разнообразных данных. Основные принципы NoSQL включают отказ от реляционной модели для учета специфики обрабатываемых данных, открытый исходный код (для многих решений), а также хорошую горизонтальную масштабируемость.
Применение NoSQL систем стало результатом новых вызовов эпохи Big Data, характеризующейся тремя «V»:

• Volume (Объем): Огромные объемы данных, которые невозможно эффективно хранить и обрабатывать на одном сервере.
• Velocity (Скорость): Высокая скорость поступления и обработки данных (например, потоковые данные с сенсоров, лог-файлы).
• Variety (Разнообразие): Неструктурированные или полуструктурированные данные различных форматов (текст, изображения, видео, JSON, XML).

NoSQL СУБД оказались более приспособлены к таким условиям из-за своей гибкости схемы и горизонтальной масштабируемости.

Основные типы NoSQL хранилищ:

• Ключ-значение (Key-value stores): Наиболее простой вариант хранилища данных, использующий ключ для доступа к значению в рамках большой хэш-таблицы. Высокая скорость чтения/записи.
  • Примеры: Redis, DynamoDB.
• Документоориентированные (Document-oriented): Данные хранятся в виде документов (обычно в формате JSON, BSON или XML). Документ — это самодостаточная единица, которая может быть вложенной и иметь сложную структуру.
  • Примеры: MongoDB, Couchbase.
• Колоночные (Column-family stores): Данные хранятся в виде строк, для доступа к которым используются три ключа: ключ строки, ключ столбца, временная метка. Оптимизированы для агрегации данных по столбцам.
  • Примеры: Apache Cassandra, HBase.
• Графовые (Graph databases): Состоят из узлов (сущностей) и связей между ними; как с узлами, так и со связями можно ассоциировать свойства (пары ключ-значение). Идеальны для работы с сильно связанными данными и сложными запросами по связям.
  • Примеры: Neo4j, ArangoDB.

Достоинства и недостатки:

Критерий	Достоинства	Недостатки
Масштабируемость	NoSQL базы данных проще масштабировать по горизонтали из-за отсутствия сложных логических связей между документами и возможности распределения данных по множеству серверов без жестких требований к согласованности. Это позволяет добиться почти линейного роста производительности при добавлении новых узлов.	Ограниченная или отсутствующая поддержка транзакций (часто только на уровне одного документа или записи) означает, что сложные операции, требующие атомарности, согласованности, изолированности и долговечности (ACID) для нескольких связанных записей, должны реализовываться на уровне приложения, что увеличивает его сложность.
Гибкость схемы	Не требуют строгой схемы данных (schema-less или schema-on-read), что обеспечивает гибкость при изменении структуры данных и значительно ускоряет разработку приложений, поскольку не нужно выполнять миграцию схемы при каждом изменении.	Поддержка структуры данных переносится с сервера в логику приложений. Это требует от разработчиков более тщательного управления форматом и целостностью данных на программном уровне, что может привести к «схеме в коде».
Производительность	Оптимизированы для конкретных моделей данных и шаблонов доступа, обеспечивая более высокую производительность (например, в 10-100 раз быстрее для чтения определенных типов данных) для специализированных задач по сравнению с универсальными реляционными СУБД.	Неунифицированные языки запросов, что усложняет миграцию между различными NoSQL базами данных и требует изучения специфических API.
Стоимость	Часто используют более дешевое, стандартное оборудование благодаря горизонтальному масштабированию.	Отсутствие зрелых инструментов администрирования, мониторинга и резервного копирования по сравнению с реляционными СУБД.

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

Влияние выбора модели данных на проектирование, производительность и масштабируемость систем

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

Этапы проектирования БД и роль нормализации

Проектирование базы данных — это многоэтапный итеративный процесс, который охватывает различные уровни абстракции:

1. Концептуальный уровень: На этом этапе определяются сущности предметной области, их атрибуты и взаимосвязи без привязки к конкретной СУБД или модели данных. Часто используется ER-диаграмма (Entity-Relationship Diagram).
2. Логический уровень: Здесь концептуальная модель преобразуется в конкретную модель данных (например, реляционную, иерархическую, сетевую). Определяются таблицы, поля, первичные и внешние ключи, а также другие ограничения.
3. Физический уровень: На этом этапе логическая модель адаптируется под особенности выбранной СУБД и физического хранилища. Определяются индексы, схемы хранения, методы доступа к данным, параметры производительности.

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

Оптимизация производительности: Сравнение моделей

Оптимизация производительности баз данных является критической задачей в современном мире, где объемы данных растут экспоненциально, а приложения становятся все более сложными. По данным аналитиков, мировой объем данных растет примерно на 25-30% ежегодно, достигая сотен зеттабайт, что делает задачи обработки и хранения все более требовательными.

Реляционные БД: Традиционные реляционные базы данных, хотя и обладают мощными механизмами обеспечения целостности и гибкими языками запросов (SQL), часто не справляются с возрастающими нагрузками, где требуется высокая производительность и масштабируемость для специфических задач. Причины:

• Жесткая схема: Любое изменение схемы (например, добавление нового поля) требует миграции данных и может быть дорогостоящим.
• Сложные операции соединения: Извлечение информации, распределенной по множеству нормализованных таблиц, требует выполнения сложных операций соединения, которые могут быть ресурсоемкими и замедлять выполнение запросов.
• Проблемы блокировок: В условиях высокой конкуренции за ресурсы (много одновременных пользователей) механизмы блокировок, обеспечивающие ACID-транзакции, могут приводить к узким местам и снижению параллелизма.

NoSQL БД: Напротив, NoSQL базы данных оптимизированы для конкретных моделей данных и шаблонов доступа, обеспечивая значительно более высокую производительность (например, в 10-100 раз быстрее для чтения определенных типов данных) для специализированных задач. Вот почему они стали так популярны:

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

Масштабируемость: Вертикальный и горизонтальный подходы

Масштабируемость — это способность системы эффективно справляться с увеличением рабочей нагрузки или объема данных. Различают два основных подхода:

• Вертикальное масштабирование (scaling up): Это увеличение производительности каждого компонента системы. Например, добавление большего количества оперативной памяти, более мощного процессора или более быстрых дисков к существующему серверу базы данных. Этот подход имеет естественные физические и финансовые ограничения.
• Горизонтальное масштабирование (scaling out): Это разбиение системы на более мелкие структурные компоненты и разнесение их по отдельным физическим машинам (серверам). Например, добавление новых серверов к существующему кластеру.

Масштабируемость NoSQL: NoSQL базы данных изначально разрабатывались с учетом горизонтального масштабирования. Они легко распределяют данные по нескольким серверам (шардирование, репликация), что позволяет линейно увеличивать производительность при росте объемов данных без инвестиций в дорогостоящее аппаратное обеспечение. Отсутствие сложных логических связей и строгой схемы упрощает распределение данных и запросов по кластеру.

Масштабируемость реляционных БД: Реляционные базы данных сложнее масштабируются горизонтально, чем NoSQL, поскольку поддержание целостности данных и ACID-транзакций в распределенной среде требует использования сложных технологий:

• Репликация: Создание копий данных на разных серверах для повышения доступности и отказоустойчивости, но запись обычно происходит на одном мастере.
• Партиционирование (шардирование): Разбиение одной большой таблицы на несколько меньших, размещенных на разных серверах. Это требует сложной логики распределения данных и запросов.
• Распределенные транзакции: Поддержание ACID-свойств в распределенной среде чрезвычайно сложно и дорого с точки зрения производительности и задержек.

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

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

Основные тенденции и будущие направления в области моделей данных

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

Эволюция и разнообразие моделей

В процессе эволюции технологий баз данных было создано значительное количество разнообразных моделей – более 20 основных типов и множество их вариаций. Это разнообразие обусловлено реальными потребностями практики обработки данных и появлением новых технологий. Каждая новая модель стремилась решить конкретные проблемы, с которыми сталкивались предшественники, или эффективно обрабатывать новые типы данных. Современные тенденции в сфере СУБД включают не только развитие стандартных реляционных моделей (с появлением таких расширений как JSON-типы данных и аналитические функции), но и бурное развитие моделей NoSQL, появление мультимодельных СУБД и широкое распространение облачных решений.

Развитие объектных и объектно-реляционных подходов

Разработка систем объектно-ориентированных баз данных (ООБД) началась в середине 80-х годов. Это было связано с необходимостью удовлетворения требований приложений, отличных от характерных для систем реляционных баз данных. К таким приложениям относятся CAD/CAM (системы автоматизированного проектирования/производства), мультимедиа-системы, геоинформационные системы (ГИС), где требуется хранение и обработка сложных, иерархически структурированных объектов с поведением. ООБД предлагали более естественный способ моделирования таких сложных сущностей.

Однако чистые ООБД столкнулись с проблемой отсутствия стандартизации и эффективных декларативных языков запросов. Ответ на это пришел в виде объектно-реляционных СУБД (ОРСУБД), которые появились в середине 90-х годов. Знаковыми релизами стали Informix Universal Server в 1996 году, а затем Oracle8 и IBM DB2 Universal Database в 1997 году. Эти системы предложили эволюционный путь для реляционных баз данных, добавив к ним объектные возможности. В 1999 году появился стандарт SQL:1999, в котором были зафиксированы объектные расширения языка SQL, а затем SQL:2003 уточнил и дополнил их, что способствовало стандартизации и распространению ОРСУБД.

Концепция ОРСУБД, как комбинации ООСУБД и РСУБД, очень притягательна. Она позволяет использовать знания и опыт, накопленные за десятилетия работы с реляционными СУБД, одновременно обретая способность обрабатывать более сложные структуры данных, такие как пользовательские типы, вложенные таблицы и массивы, повышая выразительность моделирования. Примером успешной и активно развивающейся объектно-реляционной СУБД является PostgreSQL. Он был впервые выпущен в 1989 году как POSTGRES, а значительные объектно-реляционные возможности были добавлены в начале 90-х годов, что сделало его одной из первых полностью функциональных ОРСУБД. PostgreSQL сегодня поддерживает не только стандартные типы данных, но и позволяет работать с финансовой информацией, сетевыми адресами, JSON, XML и геометрическими данными, а также создавать свои типы данных, что делает его чрезвычайно гибким инструментом.

NoSQL и эпоха Big Data

Появление NoSQL систем стало прямым ответом на новые вызовы эпохи Big Data. Традиционные реляционные СУБД оказались неэффективны при работе с огромными массивами данных, характеризующимися тремя «V»: Volume (огромные объемы), Velocity (высокая скорость поступления и обработки) и Variety (разнообразие форматов данных). NoSQL СУБД оказались более приспособлены к таким условиям из-за своей гибкости схемы (schema-less), способности к горизонтальной масштабируемости и оптимизации для специфических шаблонов доступа.

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

Интеграция и мультимодельные решения

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

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

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

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

Фундаментальные принципы, заложенные Э.Ф. Коддом и К. Дейтом, остаются актуальными, подчеркивая важность структурных, манипуляционных и целостных аспектов любой модели данных. Классические модели – иерархическая, сетевая и реляционная – сформировали основу для понимания того, как данные могут быть организованы, выявив присущие им преимущества в одних сценариях и ограничения в других. Реляционная алгебра и нормальные формы предоставили мощный математический аппарат для обеспечения целостности и эффективности данных, что до сих пор является краеугольным камнем в проектировании большинства информационных систем.

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

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

Список использованной литературы

1. Кодд, Э.Ф. Реляционная модель данных для больших совместно используемых банков данных // СУБД. – 1995. – № 1.
2. Дейт, К. Введение в системы баз данных. – 8-е изд. – М.; СПб.: Вильямс, 2005.
3. Аткинсон, М. Манифест систем объектно-ориентированных баз данных / М. Аткинсон и др. // СУБД. – 1995. – № 4.
4. The Object Data Standard: ODMG 3.0 / Edited by R.G.G. Cattel, Douglas K. Barry. – Morgan Kauffmann Publishers, 2000.
5. Стоунбрейкер, М. Системы баз данных третьего поколения: манифест / М. Стоунбрейкер и др. // СУБД. – 1995. – № 2.
6. Дарвин, Х. Третий манифест / Х. Дарвин, К. Дейт // СУБД. – 1996. – № 1.
7. Date, C. J. Foundation for Object/Relational Databases: The Third Manifesto / C. J. Date, H. Darwen. – Addison-Wesley Pub Co, 1998.
8. Дейт, К. Основы будущих систем баз данных. Третий манифест / К. Дейт, Х. Дарвен. – М.: Янус-К, 2004.
9. Date, C. J. Databases, Types, and the Relational Model. The Third Manifesto / C. J. Date, H. Darwen. – 3th ed. – Addison Wesley, 2006.
10. Кузнецов, С. Базы данных. Вводный курс. – СПб., 2007.
11. Зеленцов, Ю. А. Введение в базы данных. – М., 1997.
12. Модель данных // Википедия. – URL: https://ru.wikipedia.org/wiki/%D0%9C%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 04.11.2025).
13. Реляционная модель данных Состав реляционной модели данных. – URL: http://edu.sfu-kras.ru/sites/default/files/rp_files/38._relyacionnaya_model_dannyh._sostav_relyacionnoy_modeli_dannyh.pdf (дата обращения: 04.11.2025).
14. Сетевая модель данных // Рувики: Интернет-энциклопедия. – URL: https://ru.ruwiki.ru/wiki/%D0%A1%D0%B5%D1%82%D0%B5%D0%B2%D0%B0%D1%8F_%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85 (дата обращения: 04.11.2025).
15. БАЗЫ ДАННЫХ: Теория нормализации. – Оренбургский государственный университет. – URL: http://stud.spsl.osu.ru/docs/BD/BD_lection_02.pdf (дата обращения: 04.11.2025).
16. РЕЛЯЦИОННАЯ АЛГЕБРА. – URL: https://www.mgri.ru/upload/iblock/c38/c38b2552803328ce3e7e22e9603099cd.pdf (дата обращения: 04.11.2025).
17. Объектно-ориентированная модель данных. – URL: http://esstu.ru/fulltext/assets/files/materials/2014_06_15_2.5_object-oriented_model_database.pdf (дата обращения: 04.11.2025).
18. Нормализация отношений при проектировании БД — Реляционные базы данных. – URL: http://www.kgta.ru/materials/database/glava3.html (дата обращения: 04.11.2025).
19. Иерархическая модель данных. – URL: http://edu.sfu-kras.ru/sites/default/files/rp_files/15._ierarhicheskaya_model_dannyh.pdf (дата обращения: 04.11.2025).
20. Иерархическая модель данных. – URL: http://files.lib.sfu-kras.ru/dl/db/db_lect04.html (дата обращения: 04.11.2025).
21. Модели данных. – URL: http://edu.sfu-kras.ru/sites/default/files/rp_files/modeli_dannyh.pdf (дата обращения: 04.11.2025).
22. Сетевая модель данных. – URL: http://www.vgasu.ru/files/bd/lekciya2.pdf (дата обращения: 04.11.2025).
23. Объектно- реляционная модель данных. – URL: http://esstu.ru/fulltext/assets/files/materials/2014_06_15_2.6_object-relational_model_database.pdf (дата обращения: 04.11.2025).
24. Иерархическая и сетевая модели данных: составы моделей, преимущества и недостатки // Базы данных. Полный курс. – URL: https://db.lec.ru/course/view.php?id=7 (дата обращения: 04.11.2025).
25. ОБЪЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ. – URL: http://elib.susu.ru/ftd/A00000000000000049073.pdf (дата обращения: 04.11.2025).
26. ИСТОРИЯ ВОЗНИКНОВЕНИЯ БАЗ ДАННЫХ Текст научной статьи по специальности «Компьютерные и информационные науки — КиберЛенинка». – URL: https://cyberleninka.ru/article/n/istoriya-vozniknoveniya-baz-dannyh/viewer (дата обращения: 04.11.2025).
27. Реляционные и объектно-ориентированные базы данных. – URL: http://www.apmath.spbu.ru/ru/staff/chernyshov_o/database/Lectures/lec5.pdf (дата обращения: 04.11.2025).
28. Базы данных NoSQL. – URL: http://elib.bsut.by/wp-content/uploads/2021/05/Базы-данных-NoSQL.pdf (дата обращения: 04.11.2025).
29. ОСНОВНЫЕ ТЕНДЕНЦИИ РАЗВИТИЯ СОВРЕМЕННЫХ СУБД. – Elibrary. – URL: https://elibrary.ru/item.asp?id=47342614 (дата обращения: 04.11.2025).
30. БАЗЫ ДАННЫХ NоSQL. – URL: https://science-bsea.bgita.ru/2015/it_2015_3_31.pdf (дата обращения: 04.11.2025).
31. ОБЪЕКТНО-ОРИЕНТИРОВАННАЯ МОДЕЛЬ ДАННЫХ. – ektu.kz. – URL: http://www.ektu.kz/sites/default/files/pages/444444.pdf (дата обращения: 04.11.2025).
32. Концепция: Реляционные базы данных и объектно-ориентированные среды. – URL: https://www.ibm.com/docs/ru/rational-rsx/7.0.0?topic=concepts-relational-databases-object-oriented-environments (дата обращения: 04.11.2025).
33. Объектно-реляционные базы данных: прошедший этап или недооцененные возможности? – URL: https://www.osp.ru/os/2006/06/3313936/ (дата обращения: 04.11.2025).
34. Модели представления данных Текст научной статьи по специальности «Компьютерные и информационные науки — КиберЛенинка». – URL: https://cyberleninka.ru/article/n/modeli-predstavleniya-dannyh/viewer (дата обращения: 04.11.2025).
35. 75-я научно-техническая конференция учащихся, студентов и магистрантов: тезисы докладов : в 4-х ч. – Электронная библиотека БГТУ — Белорусский государственный технологический университет. – URL: https://www.bstu.by/static/pdf/books/bstu_75_conf_2024_ch4.pdf (дата обращения: 04.11.2025).
36. РЕЛЯЦИОННАЯ МОДЕЛЬ ДАННЫХ. – Портал информационно-образовательных ресурсов УрФУ. – URL: https://elar.urfu.ru/bitstream/10995/67635/1/978-5-7996-2401-4_2018.pdf (дата обращения: 04.11.2025).
37. Основы реляционной алгебры // Хабр. – URL: https://habr.com/ru/articles/146033/ (дата обращения: 04.11.2025).
38. Примеры и принципы нормализации реляционных баз данных (БД) // DecoSystems. – URL: https://decosystems.ru/articles/primeri-i-principi-normalizacii-relyacionnix-baz-dannix-bd/ (дата обращения: 04.11.2025).
39. Что такое база данных NoSQL? – Amazon AWS. – URL: https://aws.amazon.com/ru/nosql/ (дата обращения: 04.11.2025).
40. БД_ВТ: Лекция 4. Реляционная модель данных. Структурная составляющая реляционной модели. – URL: http://elar.urfu.ru/bitstream/10995/67635/1/978-5-7996-2401-4_2018.pdf (дата обращения: 04.11.2025).
41. Модели данных. – URL: http://window.edu.ru/catalog/pdf2txt/083/54383/page01.pdf (дата обращения: 04.11.2025).