Перейти до вмісту

ER-модель

Матеріал з K2 ERP Wiki


SEO title: ER-модель у K2 ERP — проєктування сутностей, зв’язків і автоматична генерація компонентів SEO description: ER-модель у K2 ERP використовується для опису сутностей, зв’язків, довідників, документів, журналів, форм і бізнес-структур, з яких автоматично створюються YML-структури, ORM-моделі, міграції, код модуля та інтерфейс. SEO keywords: ER-модель, Entity Relationship Model, K2 ERP, YML, ORM, ERP, AI ERP, структура бази даних, автоматична генерація коду, довідники, документи, журнали документів, форми документів, Python, TypeScript, PostgreSQL, українська ERP, альтернатива 1С, альтернатива BAS Alternative to:



ER-модель — це модель сутностей і зв’язків, яка описує структуру даних майбутнього компонента або бізнес-додатка. У K2 ERP ER-модель використовується як архітектурна основа для автоматичного створення YML-структур, ORM-моделей, міграцій бази даних, програмного коду модуля, меню, довідників, журналів документів, форм документів та базового функціоналу.

У класичному розумінні ER-модель показує, які сутності існують у системі та як вони пов’язані між собою. У K2 ERP ця ідея розширюється: ER-модель стає не просто схемою для програміста, а джерелом автоматичної генерації працюючого компонента.

Головне. У K2 ERP ER-модель — це не просто малюнок із таблицями та стрілками. Це архітектурна модель, з якої може автоматично народжуватися YML-структура, ORM-модель, міграції, код модуля, меню, довідники, журнали документів і форми документів.

Для розробників. ER-модель дозволяє бачити систему не як хаос таблиць, а як зрозумілу карту сутностей, зв’язків, документів, довідників і бізнес-логіки.

Для AI-розробки. ШІ може створювати YML-структури, які фактично є текстовим представленням ER-моделі. Людина перевіряє цю модель, уточнює промптами й акцептує автоматичне створення компонента.

Важливо. Без правильної ER-моделі велика ERP-система швидко перетворюється на клубок таблиць, зв’язків і винятків. Правильна модель — це фундамент масштабованості.

Вступ

Будь-яка серйозна ERP-система починається не з красивого інтерфейсу і навіть не з програмного коду.

Вона починається зі структури.

У бізнесі є товари, контрагенти, договори, склади, рахунки, документи, заявки, платежі, підрозділи, співробітники, ролі, маршрути погодження, залишки, рухи, файли, характеристики й звіти.

Якщо все це створювати без єдиної моделі, система швидко починає нагадувати шафу, куди десять років складали документи “тимчасово”. Спочатку начебто працює, потім усе ще начебто працює, а потім ніхто вже не знає, чому один документ пов’язаний із трьома таблицями, а четверта таблиця “історично так склалося”.

Саме для цього потрібна ER-модель.

ER-модель дозволяє побачити систему як карту: які сутності є, які між ними зв’язки, де довідники, де документи, де табличні частини, де залежності, а де майбутні проблеми, які краще побачити до того, як вони стали кодом.

У K2 ERP ця модель має особливе значення, бо вона не просто допомагає думати. Вона запускає механізм автоматичного створення компонентів.

Що таке ER-модель

ER-модель походить від англійського Entity-Relationship Model, тобто модель “сутність-зв’язок”.

Сутність — це об’єкт предметної області, про який система зберігає дані.

Наприклад:

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

Зв’язок — це відношення між сутностями.

Наприклад:

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

ER-модель дозволяє показати ці сутності та зв’язки у зрозумілій формі.

Просто кажучи. ER-модель — це схема, яка відповідає на питання: що існує в системі, які властивості воно має і як усе це пов’язано між собою.

Навіщо ER-модель потрібна в ERP

В ERP усе пов’язано з усім.

Контрагент пов’язаний із договорами. Договір — із рахунками. Рахунок — із оплатами. Замовлення — зі складом. Склад — із залишками. Залишки — з рухами товарів. Документи — з користувачами. Користувачі — з ролями. Ролі — з правами доступу.

Коли система маленька, програміст може тримати все це в голові.

Коли система росте, голова починає подавати заяву на відпустку.

Саме тому потрібна модель.

ER-модель допомагає:

  • зрозуміти структуру майбутнього модуля;
  • уникнути дублювання сутностей;
  • правильно побудувати зв’язки;
  • побачити залежності до початку програмування;
  • спростити генерацію YML;
  • автоматично створювати ORM-моделі;
  • формувати міграції бази даних;
  • створювати меню, довідники, журнали й форми;
  • краще пояснювати структуру інтеграторам і партнерам;
  • давати штучному інтелекту зрозумілий контекст.

ER-модель у K2 ERP

У K2 ERP ER-модель є частиною більшого механізму створення бізнес-додатків.

Класична ER-модель часто закінчується на етапі проєктування бази даних. Її намалювали, обговорили, погодили, а потім програміст пішов писати код.

У K2 ERP підхід інший.

ER-модель стає джерелом для подальшої автоматичної генерації.

Ланцюжок виглядає так:

ER-модель → YML-структура → ORM-модель → міграції → програмний код модуля → меню → довідники → журнали документів → форми документів → базовий функціонал.

Тобто ER-модель у K2 ERP — це не окремий малюнок “для краси”.

Це початок виробничого процесу створення компонента.

Основні елементи ER-моделі

ER-модель складається з кількох ключових частин.

Елемент Пояснення Приклад
Сутність Об’єкт предметної області Контрагент, товар, замовлення
Атрибут Властивість сутності Назва, код, дата, сума
Зв’язок Відношення між сутностями Замовлення має контрагента
Ключ Поле для унікальної ідентифікації запису id
Зовнішній ключ Посилання на іншу сутність contractor_id
Кардинальність Тип кількості зв’язків між сутностями Один-до-багатьох, багато-до-багатьох
Таблична частина Набір рядків усередині документа Товари в замовленні

Приклад простої ER-моделі

Уявімо простий модуль продажів.

У ньому є:

  • контрагенти;
  • товари;
  • склади;
  • замовлення покупців;
  • рядки замовлення.

Логіка така:

  • один контрагент може мати багато замовлень;
  • одне замовлення належить одному контрагенту;
  • одне замовлення може містити багато рядків;
  • кожен рядок замовлення посилається на один товар;
  • замовлення може бути пов’язане зі складом.

У текстовому вигляді це можна подати так: 

Контрагент 1 ─── * Замовлення покупця
Склад      1 ─── * Замовлення покупця
Замовлення 1 ─── * Рядок замовлення
Товар      1 ─── * Рядок замовлення

Це вже проста ER-модель, яка показує основні сутності та зв’язки.

Приклад ER-моделі у вигляді таблиці

Сутність Тип Основні поля Зв’язки
contractor Довідник id, code, name, edrpou, phone, email Використовується в customer_order
product Довідник id, code, name, unit, price Використовується в customer_order_items
warehouse Довідник id, code, name Використовується в customer_order
customer_order Документ id, number, date, contractor_id, warehouse_id Має табличну частину customer_order_items
customer_order_items Таблична частина id, order_id, product_id, quantity, price, amount Належить customer_order, посилається на product

ER-модель і YML

У K2 ERP YML може бути текстовим представленням ER-моделі.

Те, що на діаграмі виглядає як сутність “Контрагент” із полями, у YML може виглядати так: 

entity: contractor
title: "Контрагенти"
type: directory

fields:
  id:
    type: integer
    primary_key: true

  code:
    type: string
    title: "Код"
    required: true

  name:
    type: string
    title: "Назва"
    required: true

  edrpou:
    type: string
    title: "ЄДРПОУ"

  phone:
    type: string
    title: "Телефон"

  email:
    type: string
    title: "E-mail"

А зв’язок документа з контрагентом може бути описаний так: 

contractor_id:
  type: reference
  title: "Контрагент"
  entity: contractor
  required: true

Цей фрагмент означає, що документ має посилання на довідник контрагентів.

Для людини це зрозуміло як бізнес-зв’язок.

Для системи — як структура, з якої можна автоматично створити поле, зовнішній ключ, елемент форми, ORM-зв’язок і логіку вибору з довідника.

ER-модель і ORM

ORM-модель — це програмне представлення сутностей і зв’язків.

Якщо ER-модель описує, що в системі існує сутність “Товар”, то ORM дозволяє працювати з цією сутністю в коді.

Наприклад, з ER-моделі товару може бути створена така умовна Python-модель: 

class Product(BaseModel):
    id: int
    code: str
    name: str
    unit: str
    price: Decimal

А з моделі замовлення: 

class CustomerOrder(BaseModel):
    id: int
    number: str
    date: datetime
    contractor_id: int
    warehouse_id: int | None

У TypeScript це може виглядати так: 

export interface CustomerOrder {
  id: number;
  number: string;
  date: string;
  contractorId: number;
  warehouseId?: number;
}

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

ER-модель через YML може бути джерелом для автоматичного створення ORM-моделей.

ER-модель і міграції бази даних

Міграції потрібні для керованої зміни структури бази даних.

Якщо в ER-моделі з’явилася нова сутність або нове поле, система може створити відповідну міграцію.

Наприклад, до довідника контрагентів додали поле “Податковий номер”.

У YML це може виглядати так: 

tax_number:
  type: string
  title: "Податковий номер"

Система може зрозуміти, що потрібно додати колонку в таблицю контрагентів.

Фундамент системи. У великій ERP структура бази даних не повинна змінюватися випадковими ручними правками. Вона має розвиватися через модель і контрольовані міграції.

ER-модель і довідники

Довідники — це одна з базових частин ERP.

Приклади довідників:

  • контрагенти;
  • товари;
  • склади;
  • підрозділи;
  • співробітники;
  • договори;
  • валюти;
  • одиниці виміру;
  • обладнання;
  • види робіт.

В ER-моделі довідник зазвичай є сутністю, на яку посилаються документи або інші довідники.

Наприклад, документ “Замовлення покупця” посилається на довідник “Контрагенти” і довідник “Склади”. 

Контрагенти 1 ─── * Замовлення покупців
Склади      1 ─── * Замовлення покупців

У K2 ERP із такої моделі може автоматично створюватися довідник, форма списку, форма картки, меню та базові операції.

ER-модель і документи

Документ в ERP — це бізнес-подія.

Документами можуть бути:

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

В ER-моделі документ зазвичай має:

  • шапку документа;
  • табличні частини;
  • зв’язки з довідниками;
  • статуси;
  • службові поля;
  • бізнес-правила.

Наприклад, документ “Замовлення покупця” має шапку:

  • номер;
  • дата;
  • контрагент;
  • склад;
  • коментар.

І табличну частину:

  • товар;
  • кількість;
  • ціна;
  • сума.

Приклад ER-моделі документа

customer_order
  id
  number
  date
  contractor_id → contractor.id
  warehouse_id  → warehouse.id
  comment

customer_order_items
  id
  order_id   → customer_order.id
  product_id → product.id
  quantity
  price
  amount

Така модель показує, що документ має основну таблицю і табличну частину.

З цієї моделі можна автоматично створити:

  • таблицю документа;
  • таблицю табличної частини;
  • зв’язки між ними;
  • ORM-моделі;
  • міграції;
  • журнал документів;
  • форму документа;
  • табличну частину на формі;
  • базові API-операції;
  • пункт меню.

ER-модель і журнали документів

Журнал документів — це список документів певного типу.

Якщо в ER-моделі є документ “Замовлення покупця”, система може автоматично створити журнал “Замовлення покупців”.

У журналі можуть відображатися:

  • номер;
  • дата;
  • контрагент;
  • склад;
  • сума;
  • статус;
  • автор;
  • дата створення;
  • дата зміни.

Приклад YML-опису журналу, який випливає з ER-моделі: 

journal:
  entity: customer_order
  title: "Замовлення покупців"

  columns:
    - field: number
      title: "Номер"

    - field: date
      title: "Дата"

    - field: contractor_id
      title: "Контрагент"

    - field: warehouse_id
      title: "Склад"

    - field: total_amount
      title: "Сума"

    - field: status
      title: "Статус"

ER-модель і форми документів

Форма документа — це те, що бачить користувач.

Якщо ER-модель правильно описує поля документа і табличні частини, форма може бути створена автоматично.

Наприклад: 

form:
  entity: customer_order
  title: "Замовлення покупця"

  layout:
    - row:
        - field: number
        - field: date

    - row:
        - field: contractor_id
        - field: warehouse_id

    - row:
        - field: comment

    - table_part: items
      title: "Товари"

Тобто ER-модель визначає, які дані є в документі, а форма показує, як користувач буде з ними працювати.

ER-модель і меню

Меню в ERP також може створюватися автоматично на основі моделі.

Якщо в компоненті є довідники й документи, система може сформувати відповідні пункти меню.

Наприклад: 

menu:
  section: "Продажі"

  items:
    - title: "Замовлення покупців"
      entity: customer_order
      type: journal

    - title: "Контрагенти"
      entity: contractor
      type: directory

    - title: "Товари"
      entity: product
      type: directory

У результаті користувач отримує меню, пов’язане зі структурою компонента.

Типи зв’язків в ER-моделі

У ER-моделях найчастіше використовуються кілька типів зв’язків.

Тип зв’язку Опис Приклад
Один-до-одного Один запис однієї сутності відповідає одному запису іншої Користувач — профіль користувача
Один-до-багатьох Один запис пов’язаний із багатьма записами іншої сутності Контрагент — замовлення
Багато-до-багатьох Багато записів однієї сутності пов’язані з багатьма записами іншої Користувачі — ролі
Композиція Одна сутність є частиною іншої Замовлення — рядки замовлення
Ієрархія Сутність може посилатися сама на себе Групи товарів, підрозділи

Зв’язок один-до-багатьох

Це найпоширеніший тип зв’язку.

Наприклад, один контрагент може мати багато замовлень. 

contractor 1 ─── * customer_order

У YML це може бути описано так: 

contractor_id:
  type: reference
  title: "Контрагент"
  entity: contractor

Тут кожне замовлення має посилання на одного контрагента.

Зв’язок багато-до-багатьох

Зв’язок багато-до-багатьох зазвичай реалізується через проміжну таблицю.

Наприклад, користувач може мати багато ролей, а одна роль може бути призначена багатьом користувачам. 

user * ─── * role

Технічно це може бути реалізовано так: 

user
role
user_role

Де `user_role` — проміжна сутність.

Приклад YML: 

entity: user_role
title: "Ролі користувачів"
type: link

fields:
  user_id:
    type: reference
    entity: user
    required: true

  role_id:
    type: reference
    entity: role
    required: true

Ієрархічні зв’язки

У бізнес-системах часто потрібні ієрархії.

Наприклад:

  • групи товарів;
  • структура компанії;
  • підрозділи;
  • статті витрат;
  • категорії документів;
  • папки файлів.

Ієрархія означає, що сутність може посилатися сама на себе.

Приклад для груп товарів: 

entity: product_group
title: "Групи товарів"
type: directory

fields:
  id:
    type: integer
    primary_key: true

  parent_id:
    type: reference
    title: "Батьківська група"
    entity: product_group

  name:
    type: string
    title: "Назва"
    required: true

Це дозволяє створювати дерево груп.

ER-модель і характеристики сутностей

Не всі властивості бізнес-об’єктів варто одразу жорстко зашивати в структуру таблиць.

У реальному бізнесі один клієнт хоче для товару зберігати колір і розмір, інший — серійний номер і гарантію, третій — матеріал, бренд, сезонність, країну виробництва.

Якщо кожну таку зміну робити через нове поле в таблиці, система швидко стане важкою.

Тому в K2 ERP важливу роль можуть відігравати характеристики сутностей.

В ER-моделі це можна враховувати окремими універсальними сутностями: 

entity
characteristic
entity_characteristic_value

Це дозволяє доповнювати товари, контрагентів, документи чи обладнання додатковими властивостями без постійного переписування структури.

ER-модель і файли

У реальному бізнесі до сутностей часто потрібно прикладати файли.

Наприклад:

  • договір до контрагента;
  • сертифікат до товару;
  • фото поломки до заявки на ремонт;
  • акт до документа;
  • інструкцію до обладнання.

В ER-моделі це можна описати через універсальну сутність файлів і зв’язків. 

file
entity_file

Де `entity_file` зберігає, до якої сутності й до якого запису прикладено файл.

Такий підхід дозволяє використовувати один механізм файлів у різних модулях.

ER-модель і BP-модель

ER-модель описує дані.

BP-модель описує бізнес-процеси.

Разом вони дають повнішу картину системи.

Наприклад, ER-модель показує, що є документ “Заявка на ремонт”, у якого є клієнт, обладнання, опис проблеми, статус і виконавець.

BP-модель показує, як ця заявка рухається:

  • створена;
  • прийнята в роботу;
  • призначено інженера;
  • виконано роботи;
  • погоджено;
  • закрито.

ER + BP. ER-модель відповідає на питання “що зберігаємо?”, а BP-модель — “як це рухається в бізнес-процесі?”.

ER-модель і AI

Штучний інтелект особливо корисний тоді, коли йому дають чітку структуру.

У K2 ERP людина може описати задачу людською мовою: 

Створи ER-модель для модуля сервісного обслуговування.
Потрібні сутності: обладнання, клієнти, заявки на ремонт,
інженери, виконані роботи, акти виконаних робіт.
Заявка має містити номер, дату, клієнта, обладнання,
опис проблеми, пріоритет, статус і відповідального інженера.

ШІ може сформувати YML-структуру, яка фактично є текстовим представленням ER-моделі.

Після цього людина:

  • перевіряє модель;
  • уточнює промптами;
  • додає поля;
  • змінює зв’язки;
  • прибирає зайве;
  • доводить структуру до потрібного вигляду;
  • акцептує автоматичне створення компонента.

Приклад AI-згенерованої ER-моделі в YML

component:
  name: service_management
  title: "Сервісне обслуговування"

entities:
  equipment:
    title: "Обладнання"
    type: directory

    fields:
      id:
        type: integer
        primary_key: true

      code:
        type: string
        title: "Код"
        required: true

      name:
        type: string
        title: "Назва"
        required: true

      serial_number:
        type: string
        title: "Серійний номер"

      contractor_id:
        type: reference
        title: "Власник"
        entity: contractor

  repair_request:
    title: "Заявка на ремонт"
    type: document

    fields:
      id:
        type: integer
        primary_key: true

      number:
        type: string
        title: "Номер"
        auto: true

      date:
        type: datetime
        title: "Дата"
        required: true

      contractor_id:
        type: reference
        title: "Клієнт"
        entity: contractor
        required: true

      equipment_id:
        type: reference
        title: "Обладнання"
        entity: equipment
        required: true

      problem_description:
        type: text
        title: "Опис проблеми"

      priority:
        type: enum
        title: "Пріоритет"
        values:
          - low
          - normal
          - high
          - critical
        default: normal

      engineer_id:
        type: reference
        title: "Відповідальний інженер"
        entity: employee

      status:
        type: enum
        title: "Статус"
        values:
          - draft
          - in_work
          - completed
          - closed
        default: draft

    table_parts:
      works:
        title: "Виконані роботи"
        fields:
          work_name:
            type: string
            title: "Робота"

          hours:
            type: decimal
            title: "Години"

          rate:
            type: decimal
            title: "Ставка"

          amount:
            type: decimal
            title: "Сума"
            calculated: true

З такої структури K2 ERP може автоматично створити компонент сервісного обслуговування.

Роль людини при роботі з AI та ER-моделлю

ШІ може дуже швидко створити першу версію моделі.

Але це не означає, що людина більше не потрібна.

Навпаки, роль людини стає важливішою.

Людина повинна перевірити:

  • чи правильні сутності;
  • чи немає дублювання;
  • чи правильно побудовані зв’язки;
  • чи не забуті важливі поля;
  • чи не створено зайву складність;
  • чи відповідає модель реальному бізнес-процесу;
  • чи можна цю модель масштабувати;
  • чи не буде проблем із майбутнім рефакторингом.

Роль людини. ШІ може запропонувати модель, але архітектор має її зрозуміти, перевірити, уточнити й акцептувати.

Автоматичне створення компонента з ER-моделі

У K2 ERP після акцепту ER-моделі запускається автоматичне створення компонента.

Етап Що створюється автоматично
ER-модель Архітектурна структура сутностей і зв’язків
YML-структура Текстовий опис моделі
ORM-модель Програмна модель для роботи з базою даних
Міграції Створення або зміна таблиць у базі даних
Код модуля Каркас програмного модуля
Меню Пункти меню компонента
Довідники Списки та картки довідників
Журнали документів Списки документів
Форми документів Інтерфейси введення й перегляду документів
Базовий функціонал Типові операції роботи з даними

Усе це створюється автоматично без ручного дублювання структури програмістом.

Чим ER-модель відрізняється від простої схеми бази даних

Схема бази даних показує таблиці, поля й зв’язки на рівні СУБД.

ER-модель у K2 ERP має ширший сенс.

Вона описує не тільки таблиці, а й бізнес-сутності.

Наприклад, документ “Замовлення покупця” — це не просто таблиця `customer_order`. Це бізнес-об’єкт, який має шапку, табличну частину, статуси, форму, журнал, меню, права доступу, правила розрахунку й інтеграції.

Тому ER-модель у K2 ERP ближча до архітектурної моделі компонента, ніж просто до технічної схеми бази даних.

ER-модель і PostgreSQL

Основною базою даних для K2 ERP є PostgreSQL.

З ER-моделі можуть автоматично створюватися структури для PostgreSQL:

  • таблиці;
  • поля;
  • первинні ключі;
  • зовнішні ключі;
  • індекси;
  • обмеження;
  • міграції.

Приклад опису індексу: 

indexes:
  - name: idx_customer_order_date
    fields:
      - date

  - name: idx_customer_order_contractor
    fields:
      - contractor_id

Індекси особливо важливі для журналів документів, звітів і пошуку.

ER-модель і продуктивність

Правильна ER-модель впливає не тільки на красу архітектури, а й на швидкість роботи системи.

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

У великій ERP це критично.

Правильна ER-модель допомагає:

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

ER-модель і масштабування

K2 ERP створюється як масштабована система.

Масштабування неможливе без правильної моделі даних.

Якщо модель неправильна, то при рості кількості клієнтів, документів, модулів і інтеграцій система починає важчати.

Якщо модель правильна, система може рости частинами.

Масштабування. Легка система — це не система, у якій мало коду. Це система, у якій правильно організовані моделі, зв’язки й модулі.

Типові помилки при побудові ER-моделі

Погана ER-модель часто створює проблеми, які проявляються не одразу.

Типові помилки:

  • дублювання одних і тих самих сутностей;
  • нечіткі назви таблиць і полів;
  • відсутність єдиних правил іменування;
  • занадто багато універсальних полів “на всяк випадок”;
  • змішування довідників і документів;
  • неправильна реалізація табличних частин;
  • зайві зв’язки багато-до-багатьох;
  • відсутність індексів для важливих полів;
  • ігнорування майбутніх звітів;
  • ігнорування прав доступу;
  • спроба описати процеси як поля, а не як BP-модель;
  • створення занадто жорсткої структури там, де краще використати характеристики.

Приклад поганої моделі

Поганий приклад: 

document
  id
  type
  field1
  field2
  field3
  field4
  field5
  text1
  text2
  number1
  number2

На перший погляд здається, що це універсально.

Але на практиці це швидко перетворюється на хаос. Через пів року ніхто не знає, що означає `field3` для одного типу документа і чому `number2` для іншого типу раптом став сумою без ПДВ.

Краще мати зрозумілі сутності та поля.

Приклад кращої моделі

customer_order
  id
  number
  date
  contractor_id
  warehouse_id
  status
  total_amount

customer_order_items
  id
  order_id
  product_id
  quantity
  price
  amount

Така модель значно зрозуміліша.

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

Рекомендації щодо створення ER-моделей

При створенні ER-моделі варто дотримуватися кількох принципів.

Не треба починати з таблиць. Треба починати з бізнес-сенсу.

Спочатку потрібно відповісти на питання:

  • які бізнес-об’єкти існують;
  • які документи створюють користувачі;
  • які довідники потрібні;
  • які зв’язки між ними;
  • які дані будуть часто шукати;
  • які звіти потрібно будувати;
  • які сутності будуть рости найбільше;
  • які частини мають бути незалежними модулями;
  • які дані краще винести в характеристики;
  • які процеси треба описувати через BP-модель.

ER-модель і рефакторинг

Рефакторинг у великих ERP-системах неминучий.

Бізнес змінюється. З’являються нові документи. Старі процеси спрощуються. Деякі сутності об’єднуються. Інші, навпаки, треба розділити.

Якщо структура системи не описана як модель, рефакторинг стає небезпечним.

У K2 ERP наявність ER-моделі дозволяє робити рефакторинг більш керовано.

Можна бачити:

  • де використовується сутність;
  • які документи на неї посилаються;
  • які форми використовують поле;
  • які журнали залежать від моделі;
  • які звіти можуть змінитися;
  • які міграції потрібно створити.

ER-модель і модульність

K2 ERP розвивається як модульна система.

Модуль повинен мати зрозумілі межі.

ER-модель допомагає визначити:

  • які сутності належать модулю;
  • які сутності використовуються з інших модулів;
  • які залежності є обов’язковими;
  • які залежності бажано зробити опціональними;
  • які дані потрібно експортувати через API;
  • які структури можна повторно використовувати.

Приклад опису залежностей модуля: 

module: service
title: "Сервісне обслуговування"

depends_on:
  - crm
  - warehouse
  - contractors

ER-модель і незалежні компоненти

Одна з сильних сторін K2 ERP — можливість створювати незалежні легкі компоненти.

ER-модель допомагає зробити компонент не випадковим набором файлів, а керованою структурою.

Компонент може мати:

  • свої сутності;
  • свої документи;
  • свої довідники;
  • свої журнали;
  • свої форми;
  • свої права;
  • свої залежності;
  • свої точки інтеграції.

Тоді компонент можна встановлювати, оновлювати, переносити й підтримувати окремо.

ER-модель і Git

Якщо ER-модель представлена через YML, її можна зберігати в Git.

Це дозволяє:

  • бачити історію змін;
  • порівнювати версії;
  • робити code review моделей;
  • повертатися до попередніх версій;
  • працювати командою;
  • аналізувати, хто і коли змінив структуру;
  • пов’язувати зміни моделі з релізами.

Наприклад, якщо додали нове поле: 

+  warranty_until:
+    type: date
+    title: "Гарантія до"

Це видно в історії змін.

ER-модель і документація

З ER-моделі можна автоматично створювати документацію.

Наприклад, для сутності “Контрагент” можна сформувати таблицю:

Поле Тип Назва Обов’язкове
id integer Ідентифікатор Так
code string Код Так
name string Назва Так
edrpou string ЄДРПОУ Ні
phone string Телефон Ні

Це корисно для розробників, інтеграторів, аналітиків і тестувальників.

ER-модель і тестування

ER-модель може бути джерелом для автоматичного створення частини тестів.

Наприклад:

  • якщо поле обов’язкове, тест перевіряє, що запис без нього не зберігається;
  • якщо поле є посиланням, тест перевіряє коректність зв’язку;
  • якщо поле має тип `decimal`, тест перевіряє числові значення;
  • якщо документ має табличну частину, тест перевіряє її збереження;
  • якщо є статуси, тест перевіряє допустимі значення.

Це дозволяє краще контролювати якість компонентів.

ER-модель як основа програмування зі швидкістю думки

Коли людина описує ідею, ШІ формує YML-структуру, а K2 ERP автоматично створює компонент, ER-модель стає основою програмування зі швидкістю думки.

Процес виглядає так:

Крок Що відбувається
1 Людина формулює ідею компонента
2 ШІ створює YML-структуру
3 YML фактично описує ER-модель
4 Людина перевіряє модель
5 Людина уточнює промптами потрібні деталі
6 Модель акцептується
7 K2 ERP автоматично створює компонент
8 Програміст дописує складну логіку, яка не була описана в моделі

Формула. Ідея → ШІ → YML → ER-модель → ORM → міграції → код модуля → меню → довідники → журнали → форми → готовий компонент.

Порівняння старого і нового підходу

Старий підхід Підхід K2 ERP з ER-моделями
Програміст вручну створює таблиці Структура формується з ER-моделі
Форми створюються окремо Форми можуть генеруватися з моделі
Меню налаштовується вручну Меню формується автоматично
ORM пишеться вручну ORM-модель генерується з YML
Зв’язки важко відстежувати Зв’язки видно в ER-моделі
AI не має чіткої структури ШІ працює з моделлю та YML
Розробник витрачає час на рутину Розробник контролює архітектуру і складну логіку

Коротко

Питання Відповідь
Що таке ER-модель? Модель сутностей і зв’язків, яка описує структуру даних та бізнес-об’єктів системи.
Для чого вона потрібна в K2 ERP? Для автоматичного створення YML-структур, ORM-моделей, міграцій, коду модуля, меню, довідників, журналів і форм.
Чим ER-модель відрізняється від схеми бази даних? Вона описує не тільки таблиці, а бізнес-сутності, документи, довідники, табличні частини та зв’язки.
Чи може ШІ створювати ER-моделі? Так. ШІ може формувати YML-структури, які фактично описують ER-модель майбутнього компонента.
Яка роль людини? Перевірити модель, уточнити промпти, виправити структуру, акцептувати створення компонента й дописати складну логіку.
Чому ER-модель важлива для масштабування? Вона дозволяє правильно організувати сутності, зв’язки, модулі й уникати хаосу при рості системи.
Як ER-модель пов’язана з YML? YML може бути текстовим представленням ER-моделі, придатним для генерації коду та роботи з ШІ.
Як ER-модель пов’язана з ORM? З ER-моделі через YML можуть автоматично створюватися ORM-моделі для Python, TypeScript та інших мов.

Висновок

ER-модель у K2 ERP — це один із ключових елементів сучасної архітектури розробки бізнес-додатків.

Вона дозволяє описати систему не як набір випадкових таблиць, а як зрозумілу карту бізнес-сутностей, зв’язків, документів, довідників, табличних частин і залежностей.

Завдяки ER-моделі K2 ERP може автоматично створювати YML-структури, ORM-моделі, міграції, програмний код модуля, меню, довідники, журнали документів, форми документів і базовий функціонал.

Коли до цього підключається штучний інтелект, людина може описати задум людською мовою, отримати модель, перевірити її, уточнити промптами й акцептувати автоматичне створення компонента.

Це не скасовує роль програміста.

Навпаки, це піднімає програміста на рівень архітектора.

Він більше не витрачає час на ручне дублювання структур. Він думає про модель, якість, масштабування, бізнес-логіку й майбутній розвиток системи.

ER-модель у K2 ERP — це карта, з якої система може автоматично побудувати цілий цифровий будинок.

Саме через ER-моделі, YML, ORM, генерацію, модульність і ШІ K2 ERP формує новий підхід до створення ERP-систем — швидший, зрозуміліший, легший для розвитку і значно сучасніший за старі закриті технології.

Див. також

Зовнішні посилання

Отримано з https://wiki.erp.kyiv.ua/index.php?title=ER-модель&oldid=1882