Page History

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

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

Знаходиться в середині Процедур

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

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

🔹 Лот Процедура (Auction LotProcedure)

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

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

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

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

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

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

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

🔹 Учасник Ставка (BidderBid)

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

• Юридична або фізична особа

• Контактні дані

• Реєстраційна інформація

• Депозит та фінансові зобов’язання

🔹 Ставка (Bid)

• ID учасника

• ID аукціону

• Подана сума

• Час подачі

🔹 Аукціон (Auction Process)

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

• Дата та час старту

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

• Критерії вибору переможця

• Перелік учасників

🔹 Фінансові операції (Payments & Transactions)

• ставки

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• ID платежу

• ID лота

• Сума

• Статус платежу

Дата транзакції

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1. Основні

...

колекції БД

3.2. Зв’язки між

...

📌 Використовується реляційна модель, де основна сутність – аукціон, а всі інші сутності пов’язані через зовнішні ключі (foreign keys).

...

колекціями

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

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

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

  • події у notifications,

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

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

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

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

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

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

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

...

• Індексація ключових полів

...

4. Висновок

...

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

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

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

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