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. Основні колекції БД

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, що суттєво зменшує навантаження на основну БД.

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