Муниципальное бюджетное общеобразовательное учреждение
«Средняя общеобразовательная школа №11» г. Белгорода
Проект
Номинация: инженерный
Тема: Разработка системы управления базами данных (СУБД) для конкретной предметной области
Выполнил:
обучающийся 9 «Б» класса
Юненко М.Е.
Руководитель- консультант
учитель Артемьев Е.А.
2026
Оглавление
Актуальность проекта……………………………………………………………..…..2
Концептуальность проекта………………………………………………………..…..3
Социальная значимость проекта……………………………………….……………….4
Техническая составляющая проекта: технические характеристики объекта (объектов) проекта: чертежи или эскизы, массо-габаритные параметры………….5
− функциональное назначение объектов проекта и возможности применения……6
− технологическая последовательность……………..………………………………6
− описание использованных методик и инструментов ТРИЗ……………………….7
− экономическая часть проекта ……………………………………………………….7
− показатели ресурсной эффективности и актуальность проекта…………………..8
Практическое применение результатов проекта……………………………………..9
Самооценка……………………………………………………………….………….…9
Терминология…………………………………………………………….………..…..10
Библиография…………………………………………. ………………………..…….10
Приложение……………………………………………………………………………11
Актуальность проекта
Современные медицинские учреждения сталкиваются с необходимостью эффективного и безопасного управления огромными массивами чувствительных данных (персональные данные, история болезни, результаты анализов). Существующие системы часто страдают от следующих недостатков:
1. Фрагментация данных: Информация хранится в разрозненных источниках (бумажные карты, локальные Excel-файлы), что затрудняет быстрый поиск и анализ.
2. Нарушение целостности и безопасности: Отсутствие централизованного контроля доступа и аудита повышает риск утечки или несанкционированного изменения медицинских записей.
3. Низкая производительность: Устаревшие СУБД или неоптимизированные структуры данных не справляются с растущей нагрузкой, что замедляет работу врачей и регистратуры.
- Создание надёжного хранилища: Обеспечить целостное и безопасное хранение всех типов амбулаторной информации.
5. Обеспечение масштабируемости: Спроектировать архитектуру, способную обрабатывать до 1000 транзакций в секунду и поддерживать прирост данных в течение 5–10 лет.
6. Реализация строгой безопасности: Внедрение механизмов шифрования, аудита и ролевого контроля доступа (RBAC) на уровне базы данных. - Разработка логической и физической модели данных (ER-диаграмма). Выбор и настройка платформы СУБД (PostgreSQL с кластеризацией).
- Разработка хранимых процедур и функций для обеспечения бизнес-логики и целостности данных.
- Внедрение механизмов резервного копирования и восстановления (RTO и RPO).
Концептуальность проекта
Основная концепция проекта заключается в создании высокопроизводительной, реляционной СУБД, обеспечивающей атомарность, согласованность, изолированность и долговечность (ACID) медицинских данных. СУБД должна быть спроектирована с учетом специфики медицинских процессов (историчность записей, строгая иерархия доступа, поддержка стандартов обмена данными, таких как HL7/FHIR).
Источники информации: интернет, результаты исследований.
- Аналитические возможности: СУБД позволяет проводить агрегацию данных для эпидемиологического анализа и планирования ресурсов.
Социальная значимость проекта
Разработка централизованной СУБД имеет значительный социальный эффект, улучшая качество жизни пациентов и эффективность работы медицинских работников.
Для пациентов: Повышение безопасности данных: Гарантия конфиденциальности и защиты персональных медицинских данных.
Улучшение качества лечения: Врач получает мгновенный доступ к полной и актуальной истории болезни, что исключает ошибки, связанные с потерей или неполнотой информации.
Сокращение времени ожидания: Ускорение работы регистратуры и врачей за счет автоматизации процессов.
Для медицинского персонала: Снижение бюрократии: Переход от бумажного документооборота к электронному.
Удобство работы: Централизованный доступ к расписаниям, результатам анализов и истории приемов через единый интерфейс.
Техническая составляющая проекта
Поскольку объектом проекта является программный комплекс (СУБД), вместо массо-габаритных параметров приводятся ключевые архитектурные и технологические характеристики.
Система будет реализована по трехзвенной архитектуре:
- Уровень представления (Frontend): Пользовательские интерфейсы (рабочее место врача, регистратура).
2. Уровень приложений (Backend/DAL): Серверы приложений, реализующие бизнес-логику и предоставляющие REST API.
3. Уровень данных (СУБД): Кластер PostgreSQL, обеспечивающий хранение и целостность.
Требования к оборудованию (Минимальные для тестового кластера:
| Компонент | Требование |
| Сервер БД (Мастер) | 8 ядер CPU, 64 GB RAM, 1 TB SSD (NVMe) |
| Сервер БД (Реплика) | 8 ядер CPU, 64 GB RAM, 1 TB SSD (NVMe) |
| Сетевой канал | 10 Gbps (для кластера) |
| Хранилище бэкапов | Объектное хранилище (S3-совместим
Функциональное назначение объектов проекта и возможности применения
Объекты проекта — это основные сущности, управляемые СУБД (таблицы и их связи), а также функции, которые они обеспечивают.
Основные объекты данных (Сущности)
- Пациент (Patient): Хранение демографических данных, идентификаторов, контактов, страхового полиса.
2. Врач (Practitioner): Данные о персонале, специализация, расписание.
3. Прием (Appointment): Запись на прием, статус, время, кабинет.
4. Случай лечения (Encounter): Основная медицинская запись, содержащая диагнозы (МКБ-10), жалобы, анамнез, результаты осмотра.
5. Результаты Лаборатории (LabResult): Хранение данных анализов, референсных значений, привязка к случаю лечения.
6. Аудит (AuditLog): Журнал всех операций чтения/записи для обеспечения безопасности
Функциональное назначение
Функция | Описание | Возможности применения |
| CRUD-операции | Создание, чтение, обновление, удаление записей о пациентах, врачах и приемах. | Регистратура, ведение электронной медицинской карты. || Управление расписанием | Хранение и контроль занятости врачей, предотвращение двойной записи. | Онлайн-запись, планирование ресурсов поликлиники. | Историчность данных | Хранение версий медицинских записей и возможность отката к пре
Агрегация данных для формирования статистических и финансовых отчетов. | Администрация, бухгалтерия, государственные органы. |
| Интеграция | Предоставление защищенн
ого API для обмена данными с внешними системами (лаборатории, федеральные регистры). | Взаимодействие с ЕГИСЗ (при необходимо
Технологическая последовательность
Фаза | Этап | Содержание | Срок (Примерно) |
| I. Планирование и анализ | 1. Сбор и формализация требований | Уточнение функциональных и нефункциональных требований, регуляторных ограничений. | 4 недели |
| | 2. Проектирование архитектуры | Выбор стека, разработка логической модели, схемы кластеризации. | 3 недели |
| II. Разработка ядра СУБД | 3. Создание физической модели | Написание DDL-скриптов, настройка индексов, партиционирование. | 4 недели |
| | 4. Разработка DAL и API | Создание сервиса доступа к данным, реализация основных CRUD-операций. | 6 недель |
| III. Реализация функционала | 5. Модуль расписания и записи | Реализация сложной логики бронирования и управления временем. | 4 недели |
| | 6. Модуль амбулаторной карты | Разработка сложных структур данных для хранения истории болезни (использование JSONB). | 6 недель |
| IV. Тестирование и внедрение | 7. Интеграционное и нагрузочное тестирование | Проверка производительности и взаимодействия с МИС. | 4 недели |
| | 8. Пилотное внедрение | Развертывание в тестовой группе пользователей, сбор обратной связи. | 2 недели |
| | 9. Промышленное развертывание | Перенос в продакшн, обучение персонала. | 2 недели
Описание использованных методик и инструментов ТРИЗ
В контексте разработки СУБД, где преобладают абстрактные проблемы (целостность, производительность, безопасность), вместо классического ТРИЗ (теории решения изобретательских задач, применимой к физическим объектам) используются продвинутые методологии проектирования баз данных и паттерны решения архитектурных конфликтов.
Проблема (Противоречие): Медицинские записи требуют как строгой структуры (для отчетности и статистики), так и высокой гибкости (для неформализованных заметок врача).
• Инструмент решения (ТРИЗ-аналог): Использование гибридной модели данных.
• Решение: Применение PostgreSQL с сочетанием:
* Реляционных таблиц: Для строгих данных (Пациент, Прием, Диагноз по МКБ).
* JSONB полей: Для гибких, неструктурированных заметок, аллергий и специфических медицинских данных, которые могут меняться без изменения схемы БД.
Проблема (Противоречие): Полное логирование всех действий (Аудит) замедляет работу СУБД, но без него невозможно обеспечить безопасность и соответствие регулятору.
• Инструмент решения (ТРИЗ-аналог): Разделение функций (Separation of Concerns).
• Решение: Использование асинхронного логирования. Критические транзакции записываются синхронно, но объемные записи аудита (например, чтение данных) выносятся в отдельный асинхронный поток или отдельную БД (например, ClickHouse или Logstash) для снижения нагрузки на основную транзакционную СУБД.
Экономическая часть проекта
Расчет стоимости разработки (Оценка 6 месяцев):
| Статья расходов | Единица измерения | Количество | Стоимость единицы (условно) | Общая стоимость || ФОТ (Фонд оплаты труда) | Архитектор БД (0.5 FTE) | Месяц | 3 | 250 000 руб. | 750 000 руб. |
| Backend/DB Разработчик (2 FTE) | Месяц | 12 | 200 000 руб. | 2 400 000 руб. |
| QA-инженер (1 FTE) | Месяц | 3 | 150 000 руб. | 450 000 руб. |
| ИТОГО ФОТ | | | | 3 600 000 руб.| Инфраструктура (6 мес.) | Аренда серверов (Облако/Colocation) | Месяц | 6 | 50 000 руб. | 300 000 руб. |
| Программное обеспечение | | | | |
| Лицензии (ОС, Мониторинг) | Единовременно | 1 | 50 000 руб. | 50 000 руб. || Прочие расходы | | | | |
| Обучение и консалтинг | Единовременно | 1 | 100 000 руб. | 100 000 руб. |
| Резерв (10%) | | | | 405 000 руб. |
| Общая стоимость проекта | | | | 4 455 000 руб. |
Оценка экономической эффективности:
Экономическая эффективность будет достигнута за счет:
- Снижения операционных расходов: Сокращение времени на обработку документов (до 30%) и уменьшение ошибок, требующих переделки.
2. Увеличения пропускной способности: Возможность обслуживать большее количество пациентов без увеличения штата регистратуры.
3. Штрафы и риски: Снижение риска получения штрафов за нарушение законодательства о ПД за счет внедрения аудита и шифр
Показатели ресурсной эффективности и актуальность проекта
Выделяются следующие показатели ресурсной эффективности (KPI):
Показатель | Целевое значение | Метод измерения || Доступность (Uptime) | 99.9% | Мониторинг кластера БД (Patroni). | Время отклика (Latency) | < 300 мс (для 95% запросов) | Нагрузочное тестирование, Prometheus/Grafana.| Целостность данных | 100% (отсутствие потерянных транзакций) | Проверка журнала WAL, регулярные тесты восстановления. | RTO (Время восстановления) | < 1 час | Проверка процедур аварийного переключения. || RPO (Потеря данных) | < 15 минут | Частота инкрементального резервного копирования. || Пропускная способность | > 1000 транзакций/сек | Нагрузочное тестирование (JMeter). |
Актуальность проекта подтверждается тремя ключевыми факторами:
- Технологическое отставание: Необходимость замены устаревших систем, не способных обеспечить современный уровень безопасности и производительности.
- Регуляторное давление: Постоянно растущие требования к защите персональных данных в сфере здравоохранения.
3. Стратегическое развитие: СУБД является фундаментом для дальнейшей цифровизации поликлиники, включая внедрение телемедицины и систем поддержки принятия врачебных решений (СППВР).
Практическое применение результатов проекта
Внедрение и развертывание:
1. Подготовка инфраструктуры: Настройка кластера PostgreSQL, развертывание среды Kubernetes (или Docker Swarm) для хостинга DAL-сервисов.
2. Миграция данных: Разработка скриптов для переноса данных из старых источников (при их наличии) в новую структуру с обязательной верификацией целостности.
3. Пилотная эксплуатация: Запуск СУБД в одном отделении поликлиники (например, терапевтическом) для сбора реальных данных о нагрузке и выявления ошибок.
4. Поэтапное внедрение (Rollout): Постепенное подключение остальных отделений и пользователей к новой системе, минимизируя простои.
Обучение персонала:
Для успешного применения результатов проекта необходимо провести обучение ключевых групп пользователей:
• Администраторы БД (DBA): Обучение управлению кластером, мониторингу, резервному копированию и восстановлению.
• Разработчики МИС: Обучение работе с новым API и структурой данных.
• Конечные пользователи (Врачи, Регистратура): Обучение работе с новым интерфейсом, который взаимодействует с СУБД.
Самооценка
Достигнутые результаты:
Проект успешно достигнет поставленных целей, предоставив поликлинике современное, безопасное и масштабируемое ядро для хранения данных. Ключевым успехом является переход на архитектуру, способную выдерживать высокий трафик транзакций и обеспечивать строгую целостность медицинских записей.
Выявленные риски и улучшения:
- Риск: Сопротивление персонала при переходе на новую систему.
- Меры: Активное участие пользователей в пилотном тестировании и качественное обучение.
- Риск: Сложность интеграции с устаревшими внешними системами (например, старые лабораторные приборы).
- Меры: Разработка адаптационных шлюзов (middleware) для преобразования форматов данных (например, из HL7v2 в JSON/REST).
Перспективы развития:
В будущем СУБД может быть расширена за счет:
- Внедрения аналитического хранилища данных (DWH) для поддержки BI-отчетности.
- Интеграции машинного обучения для прогнозирования нагрузки и поддержки диагностики.
Терминология
СУБД: Система управления базами данных.
ACID: Атомарность, Согласованность, Изолированность, Долговечность (свойства транзакций). • RBAC: Role-Based Access Control (Ролевая модель доступа). • PII: Personally Identifiable Information (Персонально идентифицируемая информация). • HL7/FHIR: Международные стандарты обмена медицинскими данными. • RTO/RPO: Recovery Time Objective / Recovery Point Objective (Целевое время/точка восстановления). • JSONB: Тип данных в PostgreSQL для эффективного хранения неструктурированных данных.
Библиография
ГОСТ Р 52636-2006 — национальный стандарт Российской Федерации, который устанавливает общие положения для разработки требований к организации создания, сопровождения и использования информационных систем типа «электронная история болезни» (ЭИБ) при оказании медицинской помощь.
Федеральный закон Российской Федерации от 27.07.2006 №152-ФЗ «О персональных данных» создаёт правовую основу обращения с персональными данными физических лиц.
Цель закона — обеспечить защиту прав и свобод человека и гражданина при обработке его персональных данных, в том числе прав на неприкосновенность частной жизни, личную и семейную тайну.
Официальная документация PostgreSQL (версия 16) доступна на следующих ресурсах:
- Сайт postgresql.org — на странице «Release Notes» представлены заметки о выпуске версии 16 (выпущена 14 сентября 2023 года).
- postgrespro.ru — на странице «Документация к PostgreSQL 16.10» представлена русскоязычная документация к этой версии СУБД.
Приложение
