АссистентНовый вопросИсторияОбласти знаний
Партнёрские проектыСпецпроектыСтать автором
Сменить язык
О РУВИКИ

Проектирование баз данных

Проектирование баз данных (итал. progettazione di basi di dati) — процесс создания подробной модели базы данных в информатике. Такая модель включает все проектные решения на логическом и физическом уровнях, а также физические параметры хранения, необходимые для генерации языка определения данных (DDL), который затем используется для реализации базы данных. Полностью определённая модель данных содержит спецификации для каждой отдельной сущности.

Описание

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

Проектирование базы данных обычно состоит из ряда шагов[2], которые принято разделять на три основных уровня[3][4]:

  1. Концептуальное (инфологическое) проектирование. На этом этапе создаётся высокоуровневая, независимая от конкретной СУБД модель, которая описывает предметную область, основные сущности и связи между ними. Ключевыми задачами являются определение данных для хранения и установление отношений между ними, а результатом часто служит ER-диаграмма[5].
  2. Логическое проектирование. На этом этапе концептуальная модель преобразуется в логическую структуру. В современных условиях ключевым шагом здесь является выбор между реляционной (SQL) и различными NoSQL моделями (документными, графовыми и др.), который определяется специфическими требованиями задачи[6]. Для реляционной модели этот этап включает нормализацию[3], определение группировки информации в таблицы и установление отношений между ними[1].
  3. Физическое проектирование. Это финальный этап, на котором логическая модель реализуется в рамках конкретной СУБД. Здесь определяются точные типы данных, создаются индексы, настраиваются параметры хранения и безопасности для достижения оптимальной производительности[7].

Определение данных для хранения

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

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

Определение отношений между данными

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

Логическая структура данных

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

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

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

Описанный подход, основанный на организации данных в таблицы со строгой, заранее определённой структурой, является классическим для реляционных баз данных. Его ключевая цель — минимизировать избыточность и дублирование информации, что достигается с помощью процесса нормализации[9]. В результате создается логически целостная структура, где каждая таблица представляет отдельную сущность, а связи между ними устанавливаются с помощью первичных и внешних ключей[10].

В то же время, с ростом популярности NoSQL-систем, получил распространение альтернативный подход к логическому проектированию, ориентированный в первую очередь на потребности приложения и шаблоны запросов (query-driven modeling)[11]. В отличие от реляционной модели, NoSQL-базы данных предлагают гибкую схему и разнообразие моделей хранения (документные, ключ-значение, графовые и др.)[12][13]. В таких системах для оптимизации производительности чтения часто применяется денормализация — сознательное дублирование данных для объединения связанной информации в одну структуру, что позволяет избежать сложных соединений[11].

Диаграмма ER (модель «сущность—связь»)

Пример ER-диаграммы

Проектирование баз данных включает также построение диаграмм модели «сущность—связь» (ER). Такие диаграммы значительно облегчают процесс проектирования.

Атрибуты на ER-диаграмме обычно изображаются в виде овалов с указанием имени и соединяются с соответствующей сущностью или связью.

Пример: пример проектирования для Microsoft Access[14]

  1. Определите цель базы данных — это поможет подготовиться к следующим шагам.
  2. Соберите и организуйте необходимые сведения — соберите все типы информации, которые должны храниться в базе данных (например, название продукта или номер заказа).
  3. Разделите данные на таблицы — выделите основные сущности или объекты, например «Продукты» или «Заказы»; каждая сущность становится отдельной таблицей.
  4. Преобразуйте элементы данных в столбцы таблицы — определите, какая информация должна храниться в каждой таблице (например, для таблицы «Сотрудники» это могут быть «Фамилия», «Дата найма» и др.).
  5. Определите ключи (первичные ключи) — выберите первичный ключ для каждой таблицы — один столбец или группу столбцов, которые однозначно идентифицируют строку (например, код товара или номер заказа).
  6. Установите связи между таблицами — проанализируйте, как данные в одной таблице связаны с данными другой, при необходимости добавьте поля или даже создайте новые таблицы для более корректного отражения связей.
  7. Уточните структуру — проверьте проект на наличие ошибок: создайте таблицы, внесите несколько тестовых записей, проверьте корректность результатов и внесите необходимые изменения.
  8. Примените правила нормализации — проверьте, соответствуют ли таблицы нормальным формам, исправьте структуру при необходимости.

Нормализация

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

Нормализация остаётся фундаментальным подходом для систем с большим количеством транзакций (OLTP), где важна согласованность данных. Стандартное правило проектирования предполагает приведение структуры базы данных к одной из нормальных форм. На практике большинство систем стремятся к достижению третьей нормальной формы (3НФ), которая обеспечивает хороший баланс между устранением аномалий и сложностью структуры[17]. Более высокие формы (например, 4НФ и 5НФ) применяются реже, так как могут чрезмерно усложнить схему и привести к снижению производительности из-за большого количества соединений (JOINs)[18].

Главным компромиссом нормализации является производительность операций чтения. Поэтому для её повышения активно применяется денормализация — осознанное добавление избыточных данных для ускорения запросов[18]. Денормализация используется:

  • для ускорения отчётов и аналитики в системах бизнес-аналитики (BI)[19];
  • в высоконагруженных системах для быстрого извлечения полной информации об объекте без сложных соединений[20];
  • для фиксации исторических данных на определённый момент времени (например, адрес доставки в заказе)[19].

Применение в современных архитектурах

Актуальность нормализации и денормализации напрямую зависит от типа базы данных и архитектуры приложения.

Реляционные СУБД

Современные реляционные СУБД (например, PostgreSQL) предлагают гибридные подходы. Они позволяют использовать типы данных, такие как JSONB, для хранения слабоструктурированных данных в денормализованном виде внутри реляционной таблицы. Это даёт возможность хранить гибкие по структуре объекты (например, характеристики товара), не создавая множество дополнительных таблиц, но сохраняя преимущества реляционной модели для основных данных[21]. Для борьбы со снижением производительности из-за соединений также используются материализованные представления, продвинутые оптимизаторы запросов[22] и грамотное индексирование[23].

NoSQL-системы

В NoSQL-системах, особенно документо-ориентированных (например, MongoDB), преобладает подход с денормализацией для обеспечения горизонтальной масштабируемости и высокой производительности чтения[24]. Связанные данные часто хранятся внутри одного документа, что позволяет получить всю необходимую информацию за один запрос, избегая соединений[20].

NewSQL и гибридные системы (HTAP)

NewSQL-базы данных (например, TiDB, CockroachDB) стремятся объединить гарантии ACID-транзакций реляционных моделей с масштабируемостью NoSQL. Системы класса HTAP (Hybrid Transactional/Analytical Processing) позволяют одновременно выполнять транзакционные (OLTP) и аналитические (OLAP) запросы на одних и тех же данных. Это достигается за счёт использования разных движков хранения (например, строкового для транзакций и колоночного для аналитики), между которыми оптимизатор запросов распределяет нагрузку[25][17].

Микросервисная архитектура

В микросервисной архитектуре часто применяется паттерн CQRS (Command Query Responsibility Segregation), который разделяет модели данных для операций записи и чтения[20].

  • Модель для записи (Command) может быть полностью нормализованной для обеспечения максимальной целостности данных.
  • Модель для чтения (Query) часто является денормализованным, специально подготовленным представлением, оптимизированным для быстрых и сложных запросов.

Такой подход позволяет сохранить строгость данных при их изменении и одновременно обеспечить высокую производительность для их отображения[16].

В итоге, нормализация в современных системах является не самоцелью, а одним из инструментов проектирования. Она остаётся стандартом для обеспечения целостности данных, но почти всегда используется в связке с денормализацией, применяемой точечно для оптимизации производительности[26].

Проектирование для NoSQL-систем

Проектирование для NoSQL-систем кардинально отличается от классического реляционного подхода. Оно отталкивается от потребностей приложения, ставя во главу угла гибкость, производительность и масштабируемость, иногда в ущерб строгой согласованности данных[27]. В основе лежит методология, ориентированная на конкретные запросы приложения (query-driven modeling), а не на абстрактную структуру предметной области.

Основные принципы

  • Гибкая схема данных. NoSQL-базы не требуют жёстко определённой схемы (schema-on-read), что позволяет хранить неструктурированные или полуструктурированные данные и легко изменять их структуру в процессе разработки.
  • Разнообразие моделей данных. В отличие от единой табличной модели в SQL, NoSQL предлагает несколько моделей, каждая из которых оптимизирована под свои задачи: документо-ориентированные (MongoDB), ключ-значение (Redis), колоночные (Cassandra) и графовые (Neo4j).
  • Денормализация для производительности. Для ускорения операций чтения широко применяется денормализация — сознательное дублирование и объединение связанных данных в одну структуру. Это позволяет избежать сложных и медленных соединений (JOINs) на стороне приложения.
  • Горизонтальное масштабирование. Системы изначально проектировались для лёгкого горизонтального масштабирования (шардинга), то есть распределения данных по множеству серверов.

Методология проектирования

Процесс проектирования для NoSQL является итеративным и состоит из следующих шагов:

Шаг 1: Анализ требований и шаблонов доступа

Этот этап является ключевым. Вместо создания нормализованной модели проектирование начинается с анализа того, как приложение будет использовать данные. Определяются основные бизнес-сущности и, что более важно, все основные запросы к данным: какая информация будет запрашиваться вместе, каково соотношение операций чтения и записи, каковы требования к производительности для каждого запроса. Также прогнозируется ожидаемый объём данных для планирования масштабирования[28].

Шаг 2: Выбор подходящей модели данных

На основе шаблонов доступа выбирается наиболее подходящая модель данных:

  • Ключ-значение (англ. Key-Value). Простая модель для хранения данных в виде пар «ключ-значение». Идеальна для кэширования, хранения сессий и пользовательских профилей. Примеры: Redis, Riak[29][30].
  • Документо-ориентированная (англ. Document). Данные хранятся в гибких, полуструктурированных документах, обычно в формате JSON или BSON[31]. Подходит для систем управления контентом, каталогов товаров и приложений с эволюционирующей структурой данных. Примеры: MongoDB, CouchDB[32].
  • Колоночная (англ. Column-Family). Данные хранятся в ячейках, сгруппированных в колонки, а не в строки. Эффективна для аналитических систем, логов и приложений с высокой нагрузкой на запись. Примеры: Apache Cassandra, HBase[32].
  • Графовая (англ. Graph). Модель состоит из узлов (вершин) и рёбер (связей). Незаменима для данных со сложными взаимосвязями: социальных сетей, рекомендательных систем, систем обнаружения мошенничества. Примеры: Neo4j, Amazon Neptune[29].

Шаг 3: Логическое проектирование (моделирование данных)

На этом этапе определяется конкретная структура хранения данных. Ключевым решением является выбор между встраиванием связанных данных и использованием ссылок[33]:

  • Встраивание (англ. Embedding). Связанные данные, которые часто запрашиваются вместе и имеют отношение «один-ко-многим» с небольшим числом дочерних элементов, встраиваются в один родительский документ. Это позволяет получить всю информацию за один запрос.
  • Ссылки (англ. Referencing). Если вложенные данные велики, часто обновляются или используются отдельно в других частях системы, предпочтительнее использовать ссылки (аналог внешних ключей в SQL).

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

Шаг 4: Физическое проектирование и оптимизация

Заключительный этап включает выбор конкретной СУБД, определение стратегии индексирования для ускорения запросов и учёт компромиссов, накладываемых теоремой CAP (выбор между согласованностью и доступностью)[31]. Важной особенностью является итеративность: гибкость схемы позволяет легко вносить изменения в модель данных по мере развития приложения и появления новых требований[34].

Физическое проектирование

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

Традиционный подход

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

Управляемые облачные СУБД (DBaaS)

В управляемых облачных сервисах (англ. Database-as-a-Service, DBaaS), таких как Amazon RDS, Azure SQL Database и Google Cloud SQL, большая часть задач физического администрирования абстрагирована от пользователя[36]. Облачный провайдер берет на себя ответственность за оборудование, операционную систему, а также установку и обновление СУБД[37]. Роль проектировщика смещается с управления физическими дисками на выбор высокоуровневых параметров:

  • Класс производительности: Выбор типа виртуальной машины (количество vCPU, объем ОЗУ) и типа хранилища (например, англ. General Purpose SSD, англ. Provisioned IOPS SSD), что косвенно определяет физическую производительность.
  • Отказоустойчивость: Настройка репликации в разные зоны доступности (англ. Multi-AZ) для обеспечения высокой доступности, что реализуется провайдером «под капотом»[38].
  • Автоматизированные советники: Использование встроенных в платформу инструментов, которые анализируют нагрузку и автоматически рекомендуют создать или удалить индексы для повышения производительности[39].

При этом возможность логического секционирования таблиц сохраняется, но его физическая реализация автоматизирована[40].

«Облачно-нативные» (Cloud-Native) СУБД

СУБД, изначально спроектированные для облака (англ. Cloud-Native), такие как Amazon Aurora, имеют архитектуру, которая фундаментально отличается от традиционных монолитных систем[41]. В таких СУБД традиционное понятие физического дизайна практически исчезает. Ключевым архитектурным решением является разделение вычислений и хранения. Движок базы данных, отвечающий за обработку запросов и кэширование, отделен от уровня хранения. Вместо записи страниц данных на диск, Aurora отправляет в распределенное хранилище только записи журнала транзакций (англ. redo log)[42]. Уровень хранения автоматически реплицирует данные (например, 6 копий в 3 зонах доступности) и обеспечивает самовосстановление, что гарантирует высочайшую отказоустойчивость без ручной настройки[38].

Бессерверные (Serverless) СУБД

Бессерверные СУБД, такие как англ. Amazon Aurora Serverless и англ. Azure SQL Database Serverless, доводят идею абстракции до максимума, позволяя разработчику не думать о выделенных серверах[43][44]. Физический дизайн заменяется управлением конфигурацией сервиса:

  • Автоматическое масштабирование по требованию: Система сама выделяет и освобождает вычислительные ресурсы в зависимости от нагрузки, а пользователь задает лишь минимальные и максимальные границы[45].
  • Оплата за фактическое использование: Тарификация происходит за потребленные ресурсы (например, в секунду), а не за время работы выделенного сервера.
  • Автоматическая пауза и возобновление: База данных может «засыпать» в периоды неактивности, что снижает затраты, но приводит к появлению новой проблемы — задержки при «холодном старте» (возобновлении работы)[45].

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

Современные тенденции (2015—2025)

За период с 2015 по 2025 год проектирование баз данных претерпело кардинальные изменения, сместив фокус с универсальных реляционных систем на гетерогенные, специализированные и облачные архитектуры. Этот сдвиг был продиктован экспоненциальным ростом объемов данных, разнообразием их типов и новыми требованиями со стороны приложений, особенно в области искусственного интеллекта[47].

Расцвет NoSQL и полиглотная персистентность Если в 2015 году реляционные базы данных (SQL) все еще доминировали в корпоративном секторе благодаря своей надежности и ACID-транзакциям[48], то к середине десятилетия подход NoSQL («не только SQL») стал мейнстримом[49]. Вместо попыток использовать одну базу данных для всех задач, разработчики начали применять специализированные решения, что легло в основу концепции полиглотной персистентности (англ. Polyglot Persistence) — использования нескольких технологий хранения данных в рамках одного приложения[50]. Широкое распространение получили:

  • Документо-ориентированные СУБД (MongoDB, Couchbase) с гибкой схемой на основе JSON-подобных документов[48].
  • Хранилища «ключ-значение» (Redis, DynamoDB), незаменимые для кэширования и систем, работающих в реальном времени[48].
  • Колоночные СУБД (Cassandra, ClickHouse), оптимизированные для аналитических запросов (OLAP)[51].
  • Графовые СУБД (Neo4j, Amazon Neptune), популярность которых значительно выросла для анализа сложных взаимосвязей в социальных сетях и рекомендательных системах[48][52].

В ответ традиционные SQL-базы, в первую очередь PostgreSQL, расширили функциональность, добавив поддержку JSONB и других расширений, что стерло четкую границу между SQL и NoSQL[53].

Переход в облако (DBaaS) и появление NewSQL К 2025 году облачные базы данных (англ. Database-as-a-Service, DBaaS) стали доминирующей моделью развертывания[54]. Основными драйверами роста стали снижение затрат на оборудование и администрирование, гибкость и масштабируемость, а также передача задач по обеспечению безопасности и доступности провайдерам[54]. В ответ на потребность в масштабируемости NoSQL и гарантиях транзакций SQL возник класс систем NewSQL. Такие СУБД, как CockroachDB, YDB и Spanner, изначально проектировались как распределенные реляционные базы данных, обеспечивающие горизонтальную масштабируемость и отказоустойчивость без отказа от ACID-свойств[55].

Интеграция искусственного интеллекта Одной из ключевых тенденций второй половины десятилетия стала интеграция ИИ. СУБД начали внедрять алгоритмы машинного обучения для внутренних задач, таких как оптимизация запросов и автоматическое индексирование[56]. Взрывной рост генеративных нейросетей в 2022—2023 годах привел к появлению и популяризации векторных баз данных (Pinecone, Milvus, Qdrant)[51]. Эти системы специализируются на хранении и поиске векторных представлений (эмбеддингов), что является основой для семантического поиска и архитектуры RAG[48].

Новые архитектурные подходы

  • Бессерверные (англ. Serverless) базы данных позволяют платить не за выделенные мощности, а за фактическое количество выполненных запросов, что идеально подходит для приложений с переменной нагрузкой[56].
  • Мультимодельные базы данных поддерживают несколько моделей данных (например, документы, графы и ключ-значение) в рамках одного ядра, предлагая компромисс между специализированными СУБД и сложностью управления несколькими системами[57].
  • Ветвление баз данных (англ. Branching) — концепция создания «веток» базы данных по аналогии с Git, что упрощает разработку, тестирование и процессы CI/CD.

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

Примечания

  1. ↑ 1 2 Narain Gehani. The Database Book: Principles & Practice using MySQL : [англ.]. — Silicon Press, 2006. — ISBN 0-929306-35-X.
  2. ↑ T.J. Teorey, S.S. Lightstone и др. Database Design: Know it all : [англ.]. — Morgan Kaufmann Publishers, 2009.
  3. ↑ 1 2 2. Этапы проектирования баз данных. StudFiles. Дата обращения: 3 ноября 2025.
  4. ↑ Проектирование баз данных: этапы, методология, современные подходы. Decosystems. Дата обращения: 3 ноября 2025.
  5. ↑ 2.1 Концептуальное проектирование. Модель «сущность-связь». ЕНУ им. Л.Н. Гумилева. Дата обращения: 3 ноября 2025.
  6. ↑ Будущее больших данных: 5 прогнозов от экспертов на 2020-2025. idatica. Дата обращения: 3 ноября 2025.
  7. ↑ ЭТАПЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ. Universum: технические науки (31 января 2024). Дата обращения: 3 ноября 2025.
  8. ↑ T. Teorey, S. Lightstone, T. Nadeau. Database Modeling & Design: Logical Design : [англ.]. — Morgan Kaufmann Press, 2005. — ISBN 0-12-685352-5.
  9. ↑ Проектирование реляционных баз данных. Часть 1. Habr (24 мая 2023). Дата обращения: 3 ноября 2025.
  10. ↑ Этапы проектирования баз данных. StudFiles. Дата обращения: 3 ноября 2025.
  11. ↑ 1 2 Моделирование данных для NoSQL баз данных. Habr (1 июня 2020). Дата обращения: 3 ноября 2025.
  12. ↑ NoSQL для начинающих: как выбрать подходящую базу данных. Habr (12 сентября 2023). Дата обращения: 3 ноября 2025.
  13. ↑ Что такое NoSQL и чем он отличается от SQL. Yandex Cloud (28 октября 2022). Дата обращения: 3 ноября 2025.
  14. ↑ Database design basics (англ.). Office.com. Дата обращения: 25 июня 2024.
  15. ↑ Нормализация отношений. StudFiles. Дата обращения: 3 ноября 2025.
  16. ↑ 1 2 CQRS (Command Query Responsibility Segregation) Design Pattern in Microservices. GeeksforGeeks. Дата обращения: 3 ноября 2025.
  17. ↑ 1 2 How We Build an HTAP Database That Simplifies Your Data Architecture. DZone. Дата обращения: 3 ноября 2025.
  18. ↑ 1 2 Query performance in PostgreSQL. OTUS. Дата обращения: 3 ноября 2025.
  19. ↑ 1 2 HTAP Demystified: Defining Modern Data Architecture. PingCAP. Дата обращения: 3 ноября 2025.
  20. ↑ 1 2 3 CQRS Design Pattern in Microservices Architectures. Coding Shuttle. Дата обращения: 3 ноября 2025.
  21. ↑ PostgreSQL, JSONB и производительность. Habr (25 июля 2016). Дата обращения: 3 ноября 2025.
  22. ↑ Оптимизатор запросов в PostgreSQL. Habr (28 ноября 2024). Дата обращения: 3 ноября 2025.
  23. ↑ Оптимизация хранимых процедур в PostgreSQL: 4 трюка для взрывного ускорения. proglib.io (7 ноября 2024). Дата обращения: 3 ноября 2025.
  24. ↑ MongoDB для начинающих: полное руководство. Habr (24 октября 2024). Дата обращения: 3 ноября 2025.
  25. ↑ Real-Time Data Processing with TiDB’s HTAP Architecture. PingCAP. Дата обращения: 3 ноября 2025.
  26. ↑ Нормализация и денормализация в базах данных. OTUS. Дата обращения: 3 ноября 2025.
  27. ↑ ОСОБЕННОСТИ ПРОЕКТИРОВАНИЯ РЕЛЯЦИОННЫХ И НЕРЕЛЯЦИОННЫХ БАЗ ДАННЫХ. Современные наукоемкие технологии. Дата обращения: 3 ноября 2025.
  28. ↑ Руководство по NoSQL для разработчиков. JavaRush. Дата обращения: 3 ноября 2025.
  29. ↑ 1 2 Шпаргалка по проектированию системы NoSQL. HackerNoon. Дата обращения: 3 ноября 2025.
  30. ↑ NoSQL: что это за базы данных, для чего они нужны и как работают. Skillbox. Дата обращения: 3 ноября 2025.
  31. ↑ 1 2 Проектирование баз данных NoSQL. AI Future School. Дата обращения: 3 ноября 2025.
  32. ↑ 1 2 NoSQL Data Architecture Patterns. GeeksforGeeks. Дата обращения: 3 ноября 2025.
  33. ↑ Моделирование и секционирование данных в Azure Cosmos DB. Пример из реальной жизни. Microsoft Learn. Дата обращения: 3 ноября 2025.
  34. ↑ NoSQL базы данных: что это такое, виды, преимущества и недостатки. АРСИС. Дата обращения: 3 ноября 2025.
  35. ↑ 1 2 СУБД в облаках: новые архитектуры. Osp.ru. Дата обращения: 3 ноября 2025.
  36. ↑ База данных как сервис: зачем бизнесу облачные СУБД и в каких случаях их используют. Iteco.Cloud. Дата обращения: 3 ноября 2025.
  37. ↑ DBaaS: что это такое, преимущества и недостатки, сравнение с On-premise. Habr (28 ноября 2022). Дата обращения: 3 ноября 2025.
  38. ↑ 1 2 Aurora Vs. RDS: 7 Key Differences To Know Before Choosing. CloudZero. Дата обращения: 3 ноября 2025.
  39. ↑ Monitor and tune performance in Azure SQL Database and Azure SQL Managed Instance. Microsoft Learn. Дата обращения: 3 ноября 2025.
  40. ↑ Секционированные таблицы и индексы. Microsoft Learn. Дата обращения: 3 ноября 2025.
  41. ↑ Amazon Aurora vs Traditional Databases: Why Choose Aurora? DEV Community. Дата обращения: 3 ноября 2025.
  42. ↑ Amazon Aurora: Design considerations for high throughput cloud-native relational databases. Amazon Science. Дата обращения: 3 ноября 2025.
  43. ↑ Что такое бессерверные вычисления? Amazon Web Services. Дата обращения: 3 ноября 2025.
  44. ↑ Serverless: что это такое, как работает и зачем нужно. Habr (16 мая 2022). Дата обращения: 3 ноября 2025.
  45. ↑ 1 2 Optimize price-performance with compute auto-scaling in Azure SQL Database serverless. Microsoft Azure Blog (9 мая 2023). Дата обращения: 3 ноября 2025.
  46. ↑ Serverless compute tier for Azure SQL Database. Microsoft Learn. Дата обращения: 3 ноября 2025.
  47. ↑ 1 2 3 4 5 Векторные базы данных и их роль в ИИ: эмбеддинги и генерация. DTF. Дата обращения: 3 ноября 2025.
  48. ↑ SQL vs NoSQL: когда и что лучше использовать. Habr (23 августа 2021). Дата обращения: 3 ноября 2025.
  49. ↑ Polyglot Persistence: What Is It and Why Does It Matter? (англ.). Packt. Дата обращения: 3 ноября 2025.
  50. ↑ 1 2 Базы данных в 2025 году. ZNN. Дата обращения: 3 ноября 2025.
  51. ↑ Теория графов. Применение на практике. Habr (29 декабря 2015). Дата обращения: 3 ноября 2025.
  52. ↑ Эффективное управление базами данных в 2025: как выбирать между SQL и NoSQL. IT-Novosti.ru. Дата обращения: 3 ноября 2025.
  53. ↑ 1 2 Облачные базы данных в 2025 году. ИКС-МЕДИА. Дата обращения: 3 ноября 2025.
  54. ↑ NewSQL: как это работает и почему за этим будущее. Habr (12 ноября 2024). Дата обращения: 3 ноября 2025.
  55. ↑ 1 2 Твоя БД скоро станет умнее тебя: 5 трендов open-source баз данных 2025. proglib.io (25 февраля 2025). Дата обращения: 3 ноября 2025.
  56. ↑ Эволюция баз данных: SQL, NoSQL и новинки 2025 года. itproger. Дата обращения: 3 ноября 2025.

Литература

  • Paolo Atzeni, Stefano Ceri, Stefano Paraboschi, Riccardo Torlone. Basi di dati : [итал.]. — McGraw-Hill Education, 2014. — ISBN 978-88-386-6587-5.
  • Narain Gehani. The Database Book: Principles & Practice using MySQL : [англ.]. — Silicon Press, 2006. — ISBN 0-929306-35-X.
  • S. Lightstone, T. Teorey, T. Nadeau. Physical Database Design: the database professional's guide to exploiting indexes, views, storage, and more. Morgan Kaufmann Press, 2007. ISBN 0-12-369389-6
  • M. Hernandez. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design. 3rd Edition. Addison-Wesley Professional, 2013. ISBN 0-321-88449-3

Ссылки

Категории