1. Інформаційні моделі

Інформаційні моделі відображають структуру даних, їх зв’язки та логіку обробки у системі.

1.1. Основні інформаційні сутності

У системі «Прозорро.Продажі» визначено ключові сутності:

Процедура (Procedure)

  • Унікальний ідентифікатор обʼєкта

  • Опис та характеристики лоту

  • Характеристики майбутнього аукціону

    • Стартова ціна

    • Мінімальний крок ставки

    • Дата аукціону
    • Окремі правила та вимоги до учасників
    • Метод проведення (англійський, голландський, інші)

  • Статус (активний, завершений, скасований тощо)

Ставка (Bid)

  • Унікальний ідентифікатор ставки

  • Дані учасника (в т.ч. контактні дані)

  • Сума закритої цінової пропозиції

  • Документи учасника щодо аукціону

  • Дата і час подачі ставки

Кваліфікація (Award)

  • Унікальний ідентифікатор обʼєкта кваліфікації

  • Дані учасника (в т.ч. контактні дані)

  • Сума пропозиції за результатами аукціону

  • Документи щодо кваліфікації

  • Опис обʼєкту торгів (items)

  • Інформація щодо підписаного протоколу
  • Статус кваліфікації (успішна/не успішна)

Контрактинг (Contract)

  • Унікальний ідентифікатор обʼєкта контрактингу

  • Дані учасника (в т.ч. контактні дані)

  • Остаточна сума по договору

  • Документи договору
  • Інформація підписаного договору

  • Опис обʼєкту торгів (items)

  • Статус контрактингу (успішний/не успішний)

Скасування (Cancellation)

  • Унікальний ідентифікатор обʼєкта скасування

  • Інформація щодо скасування процедури

  • Документи з описом причин скасування

  • Опис обʼєкту торгів (items)

  • Дата скасування

2. Опис інтерфейсів

Інтерфейси системи забезпечують взаємодію користувачів, зовнішніх сервісів та інших інформаційних систем.

2.1. Інтерфейси користувачів

Веб-платформа (UI)

  • Кабінет адміністратора (управління аукціонами)

  • Кабінет організатора торгів (створення лотів)

  • Кабінет учасника (подання ставок, перегляд статусу)

  • Панель аналітики та звітності

Мобільний інтерфейс

  • Спрощений функціонал для учасників торгів

  • Оповіщення про статус аукціонів

2.2. API-інтерфейси

REST API використовується для інтеграції із зовнішніми системами.

API для взаємодії з державними реєстрами

  • ЄДРПОУ (перевірка учасників)

  • Державний реєстр речових прав (перевірка об’єктів продажу)

  • Податкова служба (перевірка фінансового стану)

API для фінансових операцій

  • Інтеграція з банками та платіжними системами

  • Перевірка депозитів

  • Контроль за транзакціями

API для звітності та аналітики

  • Взаємодія з контролюючими органами

  • Формування автоматизованих звітів

3. Структура бази даних

База даних системи реалізована на основі NoSQL-рішень, таких як MongoDB (для зберігання основних об'єктів системи) та Elasticsearch (для повнотекстового пошуку та аналітики). Обрана архітектура дозволяє ефективно працювати з великими обсягами даних та забезпечує масштабованість, гнучкість і високу швидкодію.

3.1. Основні колекції БД

procedure (MongoDB)Зберігає об’єкти процедур, включаючи метадані, статуси, етапи проведення, тощо.
registry (MongoDB)Містить об’єкти реєстрів оренди, приватизації тощо
jobber (MongoDB)Об’єкти, пов’язані з фоновими задачами, чергами на обробку, планувальниками.
notifications (MongoDB)Події та повідомлення, які надсилаються користувачам або службам.
auction (MongoDB)Дані, що стосуються аукціонів: ставки, учасники, результати, лоти.
swiftStorageСлужба зберігання документів – файлові об’єкти, пов’язані з процедурами.
ElasticsearchІндекси для реалізації повнотекстового пошуку по процедурах, учасниках, документах.

3.2. Зв’язки між колекціями

У MongoDB зв’язки реалізовані через посилання (reference) між об’єктами шляхом зберігання ідентифікаторів:

  • Колекція procedure містить посилання на:

    • пов’язані документи у swiftStorage,

    • події у notifications,

    • об’єкти аукціону з auction.

  • Колекція auction містить посилання на:

    • учасників та ставки, які можуть зберігатись у піддокументах або окремих колекціях.

  • Колекція jobber пов’язана з процедурами або іншими задачами, які вона обслуговує.

  • Колекція notifications може мати поля entity_id та entity_type, які дозволяють пов’язати повідомлення з будь-яким об’єктом у системі (наприклад, процедурою чи аукціоном).

Зв’язки типово реалізуються через ідентифікатори (_id) без застосування вкладених JOIN-запитів, що забезпечує високу продуктивність.

3.3. Оптимізація бази даних

  • Індексація ключових полів:
    Основні поля, за якими здійснюється пошук або фільтрація (наприклад, procedure.status, procedure.createdAt, auction.procedure_id, notifications.user_id), індексуються для прискорення виконання запитів.

  • Розділення БД на модулі (шардінг або окремі бази):
    Для підвищення масштабованості й продуктивності, дані розділяються за логічними модулями (наприклад, registry, auction, notifications), а також можуть бути фізично рознесені між базами/серверами.

  • Кешування запитів:
    Часто використовувані дані (наприклад, списки категорій, типів процедур, попередні пошуки) кешуються у Redis або Memcached, що суттєво зменшує навантаження на основну БД.

  • Логування операцій:
    Усі запити, зміни та критичні події логуються у спеціальну колекцію або зовнішній лог-сервіс. Логи включають інформацію про користувача, час виконання, дію та результат, що забезпечує аудит та інформаційну безпеку.


  • No labels