Page History

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

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

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

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

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

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

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

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

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

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

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

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

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

...

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

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

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

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

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

...

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

...

Award)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Історія ставок протягом аукціону
• Нотифікації, які відображалися на фронті протягом аукціону

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

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

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

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

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

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

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

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

...

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

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

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

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

...

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

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

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

База даних системи реалізована на основі NoSQL (MongoDB, Elasticsearch) для швидкої обробки великих обсягів даних-рішень, таких як 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. Оптимізація бази даних

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

– підвищує швидкість вибірки даних

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

• Розділення БД на модулі

– для масштабованості
• Кешування запитів – через Redis або Memcached
• Логування операцій – для аудиту та безпеки

4. Висновок

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

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

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

• Інформаційна модель системи структурована та охоплює всі бізнес-процеси
• API забезпечує інтеграцію з іншими державними та фінансовими системами
База даних оптимізована для швидкої обробки запитів та забезпечення безпеки