РЕЛЕВАНТНЫЙ ФАКТ: Объем российского страхового рынка в 2023 году достиг 2,3 трлн рублей, продемонстрировав рост на 25,8% по сравнению с предыдущим периодом. Этот показатель является прямым отражением острой необходимости использования высокопроизводительных, масштабируемых и безопасных информационных систем для обработки столь значительных финансовых потоков и увеличения операционной эффективности.
Введение: Актуальность исследования и постановка задачи
Современный финансовый сектор, в частности страхование, переживает фазу радикальной цифровой трансформации. Если еще десятилетие назад информационная система страховой компании выполняла функцию простого архива договоров, то сегодня она является центральным нервом бизнеса, обеспечивающим не только операционную деятельность, но и конкурентное преимущество за счет скорости, персонализации продуктов и минимизации рисков. И что из этого следует? Это означает, что качество и архитектура базы данных напрямую влияют на финансовую устойчивость и долю рынка страховщика.
Обозначение проблемы. В условиях стремительного роста рынка (2,3 трлн рублей в 2023 году) и вступления в силу жестких требований к информационной безопасности (ФЗ-152), а также на фоне геополитических вызовов, требующих реализации политики импортозамещения, перед российскими страховщиками стоит двойная задача: обеспечить высочайшую производительность и масштабируемость ИС, и при этом перейти на отечественные или открытые программные решения. Устаревшие или неадаптированные информационные системы (ИС) не способны эффективно обрабатывать большие массивы данных, необходимые для точного андеррайтинга и оперативного урегулирования убытков.
Цель исследования. Целью данной работы является разработка и обоснование концептуальной и логической модели реляционной базы данных (РБД), которая служит основой для информационной системы, автоматизирующей ключевые бизнес-процессы рискового страхования. Модель должна отвечать требованиям нормализации, обеспечивать целостность данных и быть готова к реализации на современных промышленных СУБД, поддерживающих стратегию импортозамещения.
Структура работы. Исследование структурировано таким образом, чтобы обеспечить комплексный подход: от анализа актуальных отраслевых трендов (Глава 1) и функциональных требований бизнеса (Глава 2) до непосредственного проектирования архитектуры РБД (Глава 3) и обоснования выбора платформы реализации, включая вопросы безопасности и интеграции (Глава 4).
Структурные трансформации российского рынка лизинга (2022–2025): ...
... напрямую указывает на проблемы импортозамещения и логистики. Категория оборудования ... обусловлен низкой базой, реализацией отложенного спроса и ... обновлением производственных мощностей. Эти данные свидетельствуют о том, что, ... с Гражданским кодексом РФ (глава 34) и ключевым Федеральным законом ... поддержка госпрограмм. Основными антидрайверами рынка стали корпоративные высокотехнологичные сегменты, ...
Глава 1. Теоретические основы и анализ предметной области
Цифровые тренды и роль ИТ на страховом рынке РФ (2020-2025)
На протяжении последних пяти лет российский страховой рынок демонстрирует устойчивый рост и глубокую интеграцию информационных технологий. Ключевой тренд — это переход от стандартного, универсального продукта к персонализированному ценностному предложению, что стало возможным благодаря data-driven подходу.
Влияние ИИ и ML на операционную эффективность. Инвестиции российских страховых компаний в технологии ИИ в 2024 году могли составить от 2,9 млрд до 8,5 млрд рублей, что свидетельствует о стратегической значимости этого направления. Основной эффект достигается в следующих областях:
- Автоматизация андеррайтинга и оценки рисков. Применение моделей машинного обучения (например, градиентного бустинга) позволяет автоматизировать оценку рисков, снижая влияние человеческого фактора и повышая точность тарификации. Более 80% компаний уже используют ИИ при запуске продуктов.
- Увеличение продуктивности. Автоматизация обработки заявок и урегулирования убытков позволяет страховщикам в среднем увеличить продуктивность на 30%.
- Персонализация и управление данными. Сбор и обработка больших данных (Big Data) позволяют сегментировать клиентскую базу и создавать индивидуальные предложения.
Телематика как инструмент тарификации. Ярким примером персонализации является использование телематики в автостраховании (КАСКО).
ИС собирает данные о стиле вождения (резкие торможения, скоростной режим, время суток), привязывая их к конкретному полису. Эта информация позволяет предлагать аккуратным водителям значительные скидки. Таким образом, сам процесс расчета тарифа трансформируется: риск оценивается не по абстрактным статистическим таблицам, а по реальному поведению клиента.
В целом, страховые компании тратят на развитие ИТ-направления от 5% до 10% от величины полученной страховой премии (115–230 млрд рублей совокупного ИТ-бюджета рынка в 2023 году), что подтверждает приоритет инвестиций в высокопроизводительные системы, основой которых, безусловно, является реляционная база данных.
Принципы реляционной модели данных и нормализация
Для обеспечения долговечности, целостности и высокой производительности БД необходимо строго следовать принципам реляционной теории, сформулированным Эдгаром Ф. Коддом. А ведь почему так важна нормализация именно в страховании?
Фундаментальные правила Кодда. Центральным элементом теории являются 12 правил Кодда. Для проектирования РБД страховой компании критически важны следующие:
- Информационное правило (Правило 1): Вся информация (включая метаданные) должна быть представлена в виде значений в таблицах. Это обеспечивает единообразное хранение всех данных: от условий договора до справочников коэффициентов.
- Правило гарантированного доступа (Правило 3): Любое значение в БД должно быть логически доступно через комбинацию имени таблицы, значения первичного ключа (ПК) и имени столбца. Это гарантирует, что поиск и извлечение данных о конкретном клиенте или полисе будет осуществляться быстро и однозначно.
Процесс нормализации. Нормализация — это методологический процесс, направленный на устранение логической избыточности (дублирования) и потенциальной противоречивости данных.
| Нормальная форма | Требование | Цель | Пример |
|---|---|---|---|
| 1НФ | Атомарность значений. Отсутствие повторяющихся групп столбцов. | Обеспечение структурной целостности и возможности поиска. | Нельзя хранить несколько телефонов клиента в одном поле. |
| 2НФ | Отношение должно быть в 1НФ. Неключевые атрибуты должны полностью зависеть от всего составного первичного ключа, а не от его части. | Устранение частичных зависимостей. | Если первичный ключ состоит из (№Договора, №Риска), то дата заключения договора должна зависеть только от №Договора, а не от обеих частей. |
| 3НФ | Отношение должно быть в 2НФ. Неключевые атрибуты не должны транзитивно зависеть от первичного ключа. | Устранение транзитивных зависимостей. | Код города должен находиться в отдельной таблице, чтобы изменение названия города не требовало изменения миллионов строк в таблице Клиентов. |
| НФБК (BCNF) | Более строгое требование: каждый детерминант (атрибут, от которого зависит другой атрибут) должен быть потенциальным ключом. | Устранение зависимостей, не охваченных 3НФ. | Обеспечение максимально возможной минимизации избыточности. |
Для крупной, высоконагруженной РБД страховой компании, где целостность данных о рисках, выплатах и премиях критически важна, достижение Третьей нормальной формы (3НФ) является минимальным стандартом, а стремление к НФ Бойса — Кодда (НФБК) обеспечивает максимальную надежность и гибкость при модификации структуры, позволяя системе быстро адаптироваться к новым регуляторным требованиям или продуктам.
Глава 2. Функциональные требования и бизнес-логика системы
Анализ бизнес-процессов рискового страхования
Информационная система страховой компании должна быть спроектирована вокруг жизненного цикла страхового продукта, который начинается с оценки страхового риска (конкретная опасность, вероятность и ущерб от которой могут быть оценены).
Автоматизация Андеррайтинга. Андеррайтинг — это процесс оценки, анализа и контроля риска. В современной ИС он должен быть максимально автоматизирован.
| Этап бизнес-процесса | Роль ИС | Пример использования ИИ |
|---|---|---|
| Идентификация риска | Сбор исходных данных клиента и объекта страхования. | Анализ профиля клиента в соцсетях или истории вождения (телематика). |
| Оценка и анализ | Применение статистических моделей и тарификаторов. | ИИ-системы на базе градиентного бустинга для предсказания частоты убытков. |
| Принятие решения | Расчет финальной премии и подготовка договора. | Автоматический отказ в случае превышения лимитов риска или выявление скрытой информации. |
Урегулирование убытков. Этот модуль является критически важным для лояльности клиентов. Высокая скорость и прозрачность принятия решений — ключевой нефункциональный показатель. Автоматизация здесь достигла впечатляющих результатов: роботы могут обрабатывать несложные претензии (до 100 тыс. рублей) и готовить данные для финального решения. Некоторые страховщики благодаря ИИ могут принимать решение о выплате по несложным случаям в течение 7–10 минут после получения фото- или видеоматериалов. Это требует от БД способности быстро обрабатывать неструктурированные данные (изображения, видео) и хранить метаданные, связанные с каждым случаем.
Определение функциональных и нефункциональных требований к ИС
База данных должна поддерживать следующие ключевые функциональные модули:
- Управление договорами и полисами: Создание, модификация, пролонгация, архивирование договоров. Необходим строгий учет истории изменений (версионирование).
- Управление клиентской базой (CRM): Хранение полной информации о клиентах (ФИО, контакты, персональные данные (ПДн), история взаимодействий).
- Модуль тарификации: Выполнение сложных расчетных алгоритмов (см. ниже).
- Модуль урегулирования убытков: Регистрация страховых случаев, учет заявленных и выплаченных сумм, ведение претензионной работы.
- Модуль отчетности и аналитики: Формирование обязательной (регуляторной) и управленческой отчетности.
Нефункциональные требования включают: высокую доступность (HA), масштабируемость (способность обрабатывать рост рынка), безопасность (соответствие ФЗ-152) и производительность (TPS — транзакций в секунду) для обслуживания большого числа одновременных пользователей и интеграционных запросов. Каким образом ИС может обеспечить соответствие всем этим жестким требованиям одновременно?
Логика сложного расчета страховой премии
Расчет страховой премии требует не простого суммирования, а применения мультипликативных поправочных коэффициентов. Базовая формула расчета премии в общем виде выглядит так:
Премия = БазоваяСтавка × K₁ × K₂ × ... × Kₙ
Где $K_i$ — поправочные коэффициенты, отражающие различные факторы риска.
Пример: Коэффициент Бонус-Малус (КБМ) в ОСАГО. КБМ является ключевым фактором, который отражает безаварийную историю вождения. Этот коэффициент не статичен, он динамически запрашивается из внешней системы (РСА) и хранится в БД клиента.
| Класс КБМ | Диапазон КБМ | Влияние |
|---|---|---|
| М | 2,45 | Максимальная надбавка (самый рисковый) |
| 3 | 1,17 | Стандартный коэффициент для новичка |
| 13 | 0,46 | Максимальная скидка (самый аккуратный) |
ИС должна быть спроектирована таким образом, чтобы хранить все исторические значения КБМ, базовые ставки (которые могут меняться ЦБ РФ) и обеспечить автоматическое применение этих коэффициентов в момент расчета тарифа. Это требует создания отдельных, нормализованных таблиц для хранения:
- Тарификационных справочников (Базовые ставки по категориям).
- Справочников коэффициентов (КБМ, возраст-стаж, территория).
- Истории изменений коэффициентов для каждого клиента.
Глава 3. Проектирование реляционной базы данных
Разработка концептуальной модели данных (ERD-диаграмма)
Концептуальная модель, представленная в нотации «Сущность-Связь» (ERD), позволяет визуализировать ключевые объекты предметной области и связи между ними.
Ключевые сущности:
- Клиент (Client): Хранит основные ПДн, историю взаимодействий, ссылки на документы. Связь 1:N с Договор.
- Договор (Contract): Основная сущность, содержащая условия страхования. Связь 1:N с Риск, Связь 1:N с Выплата.
- Риск (Risk): Детализация рисков, включенных в договор (например, угон, ДТП, пожар).
- Выплата (Payment): Учет всех заявленных и осуществленных выплат по урегулированным случаям.
- Коэффициент (Coefficient): Справочник всех возможных поправочных коэффициентов (например, КБМ, возраст, территория).
Связь N:M с Договор (через связующую таблицу).
- ОбъектСтрахования (InsuredObject): Автомобиль, квартира и т.д. Связь 1:N с Договор.
- ИсторияКоэффициентовКлиента (ClientCoefficientHistory): Хранит актуальное значение КБМ и его историю. Критически важна для интеграции с РСА.
Пример ключевых связей:
- Клиент $\leftrightarrow$ Договор: 1:N (Один клиент может иметь множество договоров).
- Договор $\leftrightarrow$ Риск: 1:N (Один договор покрывает один или несколько рисков).
- Договор $\leftrightarrow$ Выплата: 1:N (По одному договору может быть несколько страховых случаев и выплат).
- Договор $\leftrightarrow$ Коэффициент: N:M (Один коэффициент может влиять на множество договоров, и один договор использует множество коэффициентов. Реализуется через связующую таблицу Договор_Коэффициент).
Построение логической модели и обоснование нормализации
Логическая модель представляет собой схему отношений (таблиц) с указанием первичных (ПК) и внешних (ВК) ключей.
Пример схемы отношений (фрагмент):
| Отношение (Таблица) | Атрибуты (Столбцы) | Ключи и Зависимости | Обоснование нормализации |
|---|---|---|---|
| Клиент | id_клиент (ПК), ФИО, ДатаРождения, ПаспортСерия, ПаспортНомер, Адрес, ДатаСоздания |
id_клиент (ПК) |
3НФ (нет транзитивных зависимостей, все ПДн зависят только от id_клиент). |
| Договор | id_договор (ПК), id_клиент (ВК), id_объект (ВК), ДатаНачала, ДатаОкончания, СуммаПремии, Статус, ДатаРасчета |
id_договор (ПК) |
3НФ. id_клиент и id_объект — внешние ключи, предотвращающие дублирование данных. |
| Договор_Коэффициент | id_договор (ПК, ВК), id_коэффициент (ПК, ВК), Значение, ДатаПрименения |
Составной ПК: (id_договор, id_коэффициент). |
2НФ и 3НФ. Таблица устраняет зависимость N:M, не содержит неключевых атрибутов, не зависящих от всего составного ключа. |
| Справочник_Коэффициентов | id_коэффициент (ПК), Название, Тип (КБМ, Стаж, Территория) |
id_коэффициент (ПК) |
3НФ (Ставка и Тип зависят только от id). |
Доказательство нормализации (3НФ и НФБК):
Для критически важного отношения Договор_Коэффициент (связующая таблица), первичный ключ является составным: (id_договор, id_коэффициент).
- 1НФ: Все атрибуты (Значение, ДатаПрименения) атомарны.
- 2НФ: Оба атрибута, Значение и ДатаПрименения, полностью функционально зависимы от составного ключа. Невозможно определить Значение, зная только
id_договор(без указания, какой именно коэффициент имеется в виду). - 3НФ: В этом отношении отсутствуют транзитивные зависимости, поскольку нет неключевых атрибутов, зависящих от других неключевых атрибутов.
Для отношений, где потенциально могут возникнуть проблемы с НФБК (например, справочники, содержащие несколько потенциальных ключей), необходимо убедиться, что каждый детерминант является потенциальным ключом. Использование суррогатных ключей (id_клиент, id_договор) во всех основных таблицах упрощает достижение 3НФ и НФБК, обеспечивая однозначное определение всех неключевых атрибутов.
Глава 4. Реализация, безопасность и интеграционные решения
Сравнительный анализ промышленных СУБД и стратегия импортозамещения
Выбор платформы для реализации РБД является стратегическим решением, которое должно учитывать не только технические характеристики, но и геополитический контекст (импортозамещение).
| Критерий | PostgreSQL / Postgres Pro | Oracle Database | Обоснование выбора в РФ (2025) |
|---|---|---|---|
| Тип лицензии | Открытый исходный код (PostgreSQL), коммерческая (Postgres Pro) | Коммерческая, проприетарная | Низкая TCO, отсутствие санкционных рисков. |
| Совокупная стоимость владения (TCO) | Низкая. Затраты в основном на поддержку и доработку. | Высокая. Стоимость лицензирования может составлять десятки миллионов рублей в год. | PostgreSQL/Postgres Pro позволяет крупным компаниям сократить годовые затраты и избежать рисков. |
| Соответствие РФ | Postgres Pro включена в Единый реестр российского ПО, соответствует ФЗ-152, имеет сертификацию ФСТЭК. | Нет. Уход с рынка, отсутствие поддержки. | Критически важно для всех государственных и крупных финансовых структур. |
| Производительность/Масштабируемость | Высокая. Эффективна для сложных аналитических запросов (OLAP). | Высочайшая. Традиционно сильна в OLTP и масштабировании. | Обеспечивают высокую доступность (HA) за счет механизмов репликации (потоковая репликация в PostgreSQL). |
| Сложность миграции (Oracle $\rightarrow$ Postgres) | Высокая. Требуется конвертация серверного кода (PL/SQL $\rightarrow$ PL/pgSQL). | Неприменимо. | Автоматизированные инструменты (Ora2Pg) обрабатывают около 80% кода, остальное — ручная доработка. |
Обоснование выбора. В контексте актуальной стратегии импортозамещения и требований к сертификации ФСТЭК, PostgreSQL (в лице коммерческой версии Postgres Pro) является оптимальным выбором. Она обеспечивает необходимую производительность, высокую расширяемость и полную юридическую легитимность для хранения чувствительных данных (ПДн) и использования в финансовом секторе РФ.
Обеспечение информационной безопасности и интеграция с внешними системами
Информационная безопасность (ИБ). БД страховой компании содержит сведения, относящиеся к персональным данным (ПДн), и, следовательно, должна соответствовать требованиям Федерального закона № 152-ФЗ.
Меры обеспечения ИБ:
- Шифрование: Использование шифрования данных при хранении (at rest) и при передаче (in transit).
- Управление доступом: Строгое разделение прав доступа (RBAC), предоставление минимально необходимых привилегий.
- Целостность данных: Использование механизма многоверсионности (MVCC), который поддерживается современными СУБД (PostgreSQL), обеспечивает корректную обработку параллельных транзакций.
- Резервное копирование и HA: Регулярное полное и инкрементальное резервное копирование, а также использование механизмов репликации (например, потоковой репликации в PostgreSQL) для обеспечения высокой доступности (High Availability) и быстрого восстановления после сбоев.
Критически важная интеграция. Современная ИС не может существовать в изоляции. Она должна обмениваться данными с государственными и профессиональными системами:
- РСА (Российский Союз Автостраховщиков): Обмен данными по ОСАГО, включая запросы КБМ.
- ЦБ РФ: Регуляторная отчетность и мониторинг финансовой устойчивости.
- Госуслуги: Верификация ПДн клиентов и предоставление электронных сервисов.
Пример критически важного требования: С 1 ноября 2025 года в РФ вступает в силу обновленная система автоматического контроля наличия полиса ОСАГО. Это означает, что БД страховщика должна быть интегрирована с Национальной системой страховой информации (НСИС), являющейся центральным хранилищем РСА, и обеспечивать обмен данными в режиме, близком к реальному времени, для корректного вынесения автоматических штрафов.
Разработка аналитического и CRM-функционала
Data-driven подход требует, чтобы РБД была не только хранилищем транзакций, но и основой для бизнес-аналитики.
CRM-функционал. ИС должна предоставлять инструменты для управления взаимоотношениями с клиентами:
- Сегментация клиентской базы (например, по типу риска, частоте обращений).
- Автоматизация маркетинговых кампаний (пролонгация договоров).
- Хранение истории взаимодействия для повышения качества обслуживания.
Пример сложного SQL-запроса для бизнес-логики (расчет тарифа):
Для получения актуальной страховой премии (с учетом всех коэффициентов) необходимо выполнить сложный запрос с агрегацией и объединением нескольких таблиц:
SELECT
D.id_договор,
D.БазоваяСтавка,
D.БазоваяСтавка * EXP(SUM(LOG(ДК.Значение))) AS ФинальнаяПремия
FROM
Договор D
JOIN
Договор_Коэффициент ДК ON D.id_договор = ДК.id_договор
JOIN
Справочник_Коэффициентов СК ON ДК.id_коэффициент = СК.id_коэффициент
WHERE
D.Статус = 'Действующий' AND СК.Тип = 'ОСАГО'
GROUP BY
D.id_договор, D.БазоваяСтавка;Данный запрос использует логарифмическое преобразование (EXP(SUM(LOG(ДК.Значение)))) для корректного расчета мультипликативной формулы, что демонстрирует необходимость в высокопроизводительном SQL-движке, способном обрабатывать сложные аналитические запросы. Какой важный нюанс здесь упускается? То, что для обеспечения скорости выполнения таких запросов, критически важна правильная индексация внешних ключей и часто используемых столбцов, иначе даже самая идеальная нормализация не спасет от задержек.
Заключение: Выводы и перспективы развития
В рамках проведенного исследования была разработана и обоснована архитектура реляционной базы данных для информационной системы рискового страхования, которая соответствует актуальным требованиям цифровой трансформации и методологическим стандартам проектирования БД.
Достижение целей:
- Теоретическая база: Проанализирована актуальная роль ИТ (ИИ, телематика) на российском рынке и подтверждена стратегическая важность нормализации (до 3НФ/НФБК) для обеспечения целостности данных.
- Функциональные требования: Определены ключевые модули ИС (андеррайтинг, урегулирование убытков, CRM) и детально разобран механизм расчета премии с учетом сложных поправочных коэффициентов (КБМ).
- Проектирование РБД: Построена концептуальная и логическая модель, демонстрирующая нормализованную структуру для хранения сущностей (Клиент, Договор, Риск, Коэффициент) и их связей.
- Реализация и безопасность: Обоснован выбор PostgreSQL/Postgres Pro как оптимальной СУБД в условиях импортозамещения, обеспечивающей низкую TCO и соответствие ФЗ-152. Описаны меры ИБ и критически важные интеграционные требования (РСА, ЦБ РФ), включая новые правила контроля ОСАГО с ноября 2025 года.
Перспективы развития ИС. Дальнейшее развитие информационной системы должно быть направлено на углубление использования технологий искусственного интеллекта. В частности, внедрение генеративного ИИ для автоматизации клиентского сервиса, создания персонализированных коммуникаций и подготовки юридических документов, а также применение продвинутых моделей машинного обучения для более точного прогнозирования мошенничества и оптимизации инвестиционного портфеля страховщика на основе данных БД.
Список использованной литературы
- Бабаев, Ю. А. База данных. Шаг за шагом [Текст] : учебное пособие. М.: Издательский центр «Радуга», 2009. С. 456–607.
- База данных ‘Страховая компания’. Курсовая работа (т).
Информационное обеспечение, программирование. URL: https://bibliofond.ru/ (дата обращения: 07.10.2025).
- Бондарева, Г. А. Информатика [Текст] : методические указания / Г. А. Бондарева, Е. В. Сахарова, Л. Н. Королькова. Ставрополь: СТИС, 2006. 289 с.
- Волков, Б. С. База данных [Текст] : учебное пособие. М.: Издательский центр «Академия», 2010. С. 28–32.
- Гаврилова, А. Н. База данных Access [Текст] : учебное пособие. М.: Издательский центр «Винтаж», 2010. С. 192–200.
- ИТ в страховых компаниях: фактор развития и технологии будущего / Эксперт РА. URL: https://raexpert.ru/ (дата обращения: 07.10.2025).
- Инновации в страховании: скорость, технологии, искусственный интеллект / Эксперт РА. URL: https://raexpert.ru/ (дата обращения: 07.10.2025).
- Информационная безопасность страховых компаний / SearchInform. URL: https://searchinform.ru/ (дата обращения: 07.10.2025).
- Как CRM-система поможет в работе страхового агента. URL: https://polis.online/ (дата обращения: 07.10.2025).
- Кузин, А. В. Информатика [Текст] : учебное пособие. М.: Издательский центр «Академия», 2005. С. 5–14.
- Лекция 6: Нормальные формы отношений. Создание логической модели реляционной базы данных / Intuit. URL: https://intuit.ru/ (дата обращения: 07.10.2025).
- Маренков, Н. Л. Страховое дело [Текст] : учебное пособие для вузов / Н. Л. Маренков, Н. Н. Косаренко ; под ред. Н. Л. Маренкова. М.: Феникс, 2004. 256 с.
- Могилев, А. В. Практикум по информатике [Текст] : учебное пособие. М.: Издательский центр «Виртуоз», 2008. С. 132–147.
- Нормальная форма // Википедия. URL: https://ru.wikipedia.org/wiki/Нормальная_форма (дата обращения: 07.10.2025).
- Об обязательном страховании гражданской ответственности владельцев транспортных средств : Федер. закон от 25.04.2002 № 40-ФЗ (ред. от 14.07.2022).
Доступ из справ.-правовой системы «КонсультантПлюс». URL: https://www.consultant.ru/document/cons_doc_LAW_36551/ (дата обращения: 07.10.2025).
- Oracle vs PostgreSQL: какую СУБД выбрать? / Перфоманс Лаб. URL: https://performance-lab.ru/ (дата обращения: 07.10.2025).
- PostgreSQL vs Oracle: какую СУБД выбрать в зависимости от ваших потребностей и бюджета. URL: https://arsis.ru/ (дата обращения: 07.10.2025).
- PostgreSQL против Oracle: 8 различий, о которых вам следует знать. URL: https://astera.com/ (дата обращения: 07.10.2025).
- Примеры и принципы нормализации реляционных баз данных (БД) / DecoSystems. URL: https://decosystems.ru/ (дата обращения: 07.10.2025).
- Реляционные базы данных | Нормализация. URL: https://metanit.com/ (дата обращения: 07.10.2025).
- Российская Федерация. Законы. Гражданский кодекс Российской Федерации [Текст] : [федер. закон принят Гос. Думой 21 октября 1994 г.: по состоянию на 15 октября 2009 г.]. Н.: Сибирское университетское издательство, 2009. 704 с.
- Симонович, С. В. Специальная информатика [Текст] : учебное пособие / С. В. Симонович, Г. А. Евсеев, А. Г. Алексеев. М.: Аст-пресс, 2000. С. 148–152.
- Страхование информационных рисков и обеспечение информационной безопасности. URL: https://okbsapr.ru/ (дата обращения: 07.10.2025).
- Страхование от А до Я [Текст] / под ред. Л. И. Корчевской, К. Е. Турбиной. М., 2005. 360 с.
- Страховое дело [Текст] : учебник / ред. Л. И. Рейтмана. М., 2002. 285 с.
- Страховой риск — главный параметр в вопросе возмещения ущерба. URL: https://asn-news.ru/ (дата обращения: 07.10.2025).
- Страховой риск: понятие, основные признаки и виды / РСХБ — Страхование жизни. URL: https://rshbins-life.ru/ (дата обращения: 07.10.2025).
- Тренды страховой отрасли в России: цифровизация и новые вызовы. URL: https://korusconsulting.ru/ (дата обращения: 07.10.2025).
- Цифровизация страховых услуг в России: Текущие тренды и перспективы на 2025 год. URL: https://ingos.ru/ (дата обращения: 07.10.2025).
- «Ингосстрах» ускоряет цифровую трансформацию отрасли с помощью «Сколково». URL: https://ng.ru/ (дата обращения: 07.10.2025).
- 12 Правил Кодда. URL: https://studfile.net/preview/9985223/ (дата обращения: 07.10.2025).
- CRM для страховой: зачем и как выбрать. URL: https://bitrix24.ru/ (дата обращения: 07.10.2025).
- CRM-программа для сферы страхования. URL: https://pipedrive.com/ (дата обращения: 07.10.2025).
- CRM-система для страхового агента: что это и зачем нужна. URL: https://polis812.ru/ (дата обращения: 07.10.2025).