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

ER-модель

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

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

name:



type: decimal

!; У YML це має змогу виглядати так:

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

customer_order_items Сутність — це об’єкт предметної області, про який платформа зберігає інформаційні дані.; | Вона надає можливість правильно організувати сутності, зв’язки, модулі й уникати хаосу при рості системи.;== Коротко ==

Потрібні сутності: обладнання, клієнти, заявки на ремонт, 

title: "Робота"

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

Окремо варто відзначити яка описує структуру даних майбутнього компонента або бізнес-додатка виступає ключовою рисою автоматичного створення YML-структур забезпечується через ER-модель.; | Перевірити модель, уточнити промпти, виправити структуру, акцептувати створення компонента й дописати складну логіку.; Тобто ER-модель визначає, які інформаційні дані є собою в документі, а форма показує, як користувач системи буде з ними працювати.; У K2 ERP YML має змогу бути текстовим представленням ER-моделі.; entity_file

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

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

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

entity: equipment

number:

Видно, що це замовлення покупця, у нього є собою контрагент, складський облік, статус, сума і таблична частина з товарами.; Правильна модель — це фундамент масштабованості.; бізнес-середовище змінюється.; Саме для цього потрібна ER-модель.; contractor_id: </syntaxhighlight>

компонент повинен мати зрозумілі межі.; У K2 ERP із такої моделі має змогу автономно створюватися довідник, форма списку, форма картки, меню та базові операції.; Це платформа, у якій правильно організовані моделі, зв’язки й модулі.; * шапку документа;

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

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

Суть у з цієї причини, що програміст не повинен дублювати структуру вручну в різних місцях.; Для AI-розробки. ШІ має змогу створювати YML-структури, які фактично є собою текстовим представленням ER-моделі.;== Висновок == Довідники — це одна з базових частин ERP.; required: true характеристика проблеми, пріоритет, статус і відповідального інженера.; Якщо все це створювати без єдиної моделі, платформа оперативно починає нагадувати шафу, куди десять років складали документи “тимчасово”.; * контрагенти;

  • товари;
  • склади;
  • підрозділи;
  • співробітники;
  • договори;
  • валюти;
  • одиниці виміру;
  • обладнання;
  • види робіт.;
    Можна бачити:
<syntaxhighlight lang="yaml">
Якщо [[ER-модель]] описує, що в системі існує сутність “Товар”, то [[ORM]] надає можливість працювати з цією сутністю в коді.; required: true

 work_name:

 type: string

entity

 - in_work

 comment

[[Категорія:Python]]

 field5

 id

 - field: comment

!; Що створюється автономно

* договір до контрагента;
* сертифікат до товару;
* фото поломки до заявки на ремонт;
* акт до документа;
* інструкцію до обладнання.;== Навіщо ER-модель потрібна в ERP ==

 unit: str

title: "Години"
table_parts:

text2
entity: product
product_id
equipment_id:

У ER-моделях найчастіше використовуються кілька типів зв’язків.; field2 Приклад YML: </syntaxhighlight>

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

  • номер;
  • дата;
  • контрагент;
  • складський облік;
  • коментар.; Після цього людина:

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

</syntaxhighlight> 

serial_number:
type: string

</syntaxhighlight>

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

 field1

* бачити історію змін;
* порівнювати версії;
* робити code review моделей;
* повертатися до попередніх версій;
* працювати командою;
* аналізувати, хто і коли змінив структуру;
* пов’язувати зміни моделі з релізами.; required: true
У великій [[ERP]] це критично.;[[ORM|ORM-модель]] — це програмне представлення сутностей і зв’язків.; title: "Обладнання"
!; |}

 type: integer

 contractor_id:

 id:

 title: "Виконані роботи"

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

У [[K2 ERP]] після акцепту [[ER-модель|ER-моделі]] запускається автоматичне створення компонента.; | Вона описує не тільки таблиці, а бізнес-сутності, документи, довідники, табличні частини та зв’язки.;{{SEO
|title=ER-модель у K2 ERP — проєктування сутностей, зв’язків і автоматична генерація компонентів
|description=ER-модель у K2 ERP використовується для опису сутностей, зв’язків, довідників, документів, журналів, форм і бізнес-структур, з яких автоматично створюються YML-структури, ORM-моделі, міграції, код модуля та інтерфейс.
|keywords=ER-модель, Entity Relationship Model, K2 ERP, YML, ORM, ERP, AI ERP, структура бази даних, автоматична генерація коду, довідники, документи, журнали документів, форми документів, Python, TypeScript, PostgreSQL, українська ERP, альтернатива 1С, альтернатива BAS
|image=https://erp.kyiv.ua
}}

 - field: number

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

* [[K2]]
* [[K2 ERP]]
* [[K2 Update]]
* [[ERP]]
* [[ER-модель]]
* [[BP-модель]]
* [[YML]]
* [[YAML]]
* [[ORM]]
* [[API]]
* [[Python]]
* [[TypeScript]]
* [[PostgreSQL]]
* [[SQLite]]
* [[MySQL]]
* [[SQL]]
* [[Git]]
* [[AI]]
* [[Штучний інтелект]]
* [[Low-code]]
* [[No-code]]
* [[RAD]]
* [[IDE]]
* [[Автоматична генерація коду]]
* [[Автоматизація бізнесу]]
* [[Українське програмне забезпечення]]
* [[Альтернатива 1С]]
* [[Альтернатива BAS]]

з цієї причини в [[K2 ERP]] важливу роль можуть відігравати характеристики сутностей.;[[Категорія:YML]]

<syntaxhighlight lang="text">
 - field: contractor_id

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

total_amount
type

date:

</syntaxhighlight> 

user_role
 id
 type: decimal
|-
| 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
|}

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

[[AI|Штучний інтелект]] особливо корисний тоді, коли йому дають чітку структуру.; це модель сутностей і зв’язків.;<syntaxhighlight lang="yaml">
 - crm
Навпаки, це піднімає програміста на рівень архітектора.; * чи правильні сутності;
* чи немає дублювання;
* чи правильно побудовані зв’язки;
* чи не забуті важливі поля;
* чи не створено зайву складність;
* чи відповідає модель реальному бізнес-процесу;
* чи можна цю модель масштабувати;
* чи не буде проблем із майбутнім рефакторингом.; У [[K2 ERP]] [[ER-модель]] застосовують, коли потрібно як архітектурна основа; додатково реалізовано [[ORM|ORM-моделей]], міграцій бази даних, програмного коду модуля, меню, довідників, журналів документів, форм документів і базового функціоналу.; number1

 - field: warehouse_id

<syntaxhighlight lang="typescript">

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

* які сутності належать модулю;
* які сутності використовуються з інших модулів;
* які залежності є собою обов’язковими;
* які залежності бажано зробити опціональними;
* які інформаційні дані потрібно експортувати через [[API]];
* які структури можна повторно використовувати.; order_id → customer_order.id
ER-модель має змогу бути джерелом для автоматичного створення частини тестів.;== Основні елементи ER-моделі ==
З [[ER-модель|ER-моделі]] можуть автономно створюватися структури для [[PostgreSQL]]:
</div>

 fields:
 id:
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
 type: reference

menu:

 title: "Номер"

 repair_request:

type: enum

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

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

У реальному бізнесі до сутностей часто потрібно прикладати файли.; У текстовому вигляді це можна подати так: Фундамент системи. У великій ERP структура бази даних не повинна змінюватися випадковими ручними правками.; quantity 

date
amount
title: "Власник"
entity: role

columns:
title: "Назва"

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

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

- contractor_id
priority:
id: int

без ускладнень кажучи. ER-модель — це схема, яка відповідає на питання: що існує в системі, які властивості воно має і як усе це пов’язано між собою.; Старі процеси спрощуються.; title: "E-mail" type: directory |- | Сутність | Об’єкт предметної області | Контрагент, товар, замовлення |- | Атрибут | Властивість сутності | Назва, код, дата, сума |- | Зв’язок | Відношення між сутностями | Замовлення має контрагента |- | Ключ | Поле для унікальної ідентифікації запису | id |- | Зовнішній ключ | Посилання на іншу сутність | contractor_id |- | Кардинальність | Тип кількості зв’язків між сутностями | Один-до-багатьох, багато-до-багатьох |- | Таблична частина | Набір рядків усередині документа | Товари в замовленні |}

Будь-яка серйозна ERP-система починається не з красивого інтерфейсу і навіть не з програмного коду.; Людина перевіряє цю модель, уточнює промптами й акцептує автоматичне створення компонента.; Залишки — з рухами товарів.; component: 

default: normal

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

- field: contractor_id
- field: date
auto: true

warehouseId?: number;

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

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

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

entity: customer_order

</syntaxhighlight> 

required: true

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

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

type: decimal

warehouse_id: int | None

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

+ type: date

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

document

export interface CustomerOrder {

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

default: draft

</syntaxhighlight> Технічно це має змогу бути реалізовано так:

як ілюстрація:

завдяки наявності У K2 ERP ця модель має особливе значення, бо вона не без ускладнень користувачі можуть думати.; |-

| Чим ER-модель відрізняється від схеми бази даних?; Це архітектурна модель, з якої має змогу автономно народжуватися YML-структура, ORM-модель, міграції, код модуля, меню, довідники, журнали документів і форми документів.; | Модель сутностей і зв’язків, яка описує структуру даних та бізнес-об’єктів системи.; Якщо інформаційні дані дублюються, виникають помилки.;

!; складський облік — із залишками.; Документи — з користувачами.; title: "Замовлення покупців"

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

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

type: reference

У K2 ERP наявність ER-моделі надає можливість робити рефакторинг більш керовано.; type: text </syntaxhighlight> ER + BP. ER-модель відповідає на питання “що зберігаємо?”, а BP-модель — “як це рухається в бізнес-процесі?”.; У результаті користувач системи отримує меню, пов’язане зі структурою компонента.; user * ─── * role

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

!; !; Пояснення

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

fields: Навпаки, роль людини стає важливішою.;</syntaxhighlight> 

fields:
title: "Ставка"

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

title: "Контрагент"

customer_order як ілюстрація:

</syntaxhighlight> 

text1

Це не скасовує роль програміста.; |- | id | integer | Ідентифікатор | Так |- | code | string | Код | Так |- | name | string | Назва | Так |- | edrpou | string | ЄДРПОУ | Ні |- | phone | string | Телефон | Ні |} 

values:

module: service

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

  • якщо поле обов’язкове, тест перевіряє, що запис без нього не зберігається;
  • якщо поле є собою посиланням, тест перевіряє коректність зв’язку;
  • якщо поле має тип `decimal`, тест перевіряє числові значення;
  • якщо документ має табличну частину, тест перевіряє її збереження;
  • якщо є собою статуси, тест перевіряє допустимі значення.; Через пів року ніхто не знає, що означає `field3` для одного типу документа і чому `number2` для іншого типу раптом став сумою без ПДВ.; як ілюстрація, з ER-моделі товару має змогу бути розроблена така умовна Python-модель:

ER-модель і YML

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

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

</syntaxhighlight> !; status 

type: reference

</syntaxhighlight>

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

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

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

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

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

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

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

price: Decimal

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

type: string
id

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

role

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

- date
primary_key: true

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

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

title: "Групи товарів" Рефакторинг у великих ERP-системах неминучий.; |- | Як ER-модель пов’язана з YML?; * де застосовується сутність;

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

При створенні ER-моделі варто дотримуватися кількох принципів.; title: "Обладнання" !; Ролі — з правами доступу.; Зв’язки 

role_id:
entity: contractor
id:

code:

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

  • таблицю документа;
  • таблицю табличної частини;
  • зв’язки між ними;
  • ORM-моделі;
  • міграції;
  • журнал документів;
  • форму документа;
  • табличну частину на формі;
  • базові API-операції;
  • пункт меню.; Її намалювали, обговорили, погодили, а потім програміст пішов писати код.; entity: product_group
number2
title: "Заявка на ремонт"

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

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

hours:

З ER-моделі можна автономно створювати документацію.; title: "характеристика проблеми"

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

- field: status

id

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

title: "Код"
!;
!; Типові помилки:
 - title: "Замовлення покупців"
ER-модель сприяє зробити компонент не випадковим набором файлів, а керованою структурою.;== Типові помилки при побудові ER-моделі ==
Контрагент 1 ─── * Замовлення покупця

завдяки наявності [[ER-модель|ER-моделі]] [[K2 ERP]] має змогу автономно створювати [[YML]]-структури, [[ORM|ORM-моделі]], міграції, програмний код модуля, меню, довідники, журнали документів, форми документів і базовий функціональні можливості.; type: reference

 user_id:

Тобто [[ER-модель]] у [[K2 ERP]] — це не окремий малюнок “для краси”.;[[Категорія:Штучний інтелект]]
|-
| 1
| Людина формулює ідею компонента
|-
| 2
| [[AI|ШІ]] створює [[YML]]-структуру
|-
| 3
| [[YML]] фактично описує [[ER-модель]]
|-
| 4
| Людина перевіряє модель
|-
| 5
| Людина уточнює промптами потрібні деталі
|-
| 6
| Модель акцептується
|-
| 7
| [[K2 ERP]] автономно створює компонент
|-
| 8
| Програміст дописує складну логіку, яка не була описана в моделі
|}

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

ER-модель складається з кількох ключових частин.; | Для автоматичного створення [[YML]]-структур, [[ORM|ORM-моделей]], міграцій, коду модуля, меню, довідників, журналів і форм.; Питання
<syntaxhighlight lang="python">
 name:
 - row:

== Див.; додатково ==

<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
Коли людина описує ідею, [[AI|ШІ]] формує [[YML]]-структуру, а [[K2 ERP]] автономно створює компонент, ER-модель стає основою програмування зі швидкістю думки.; amount:
Але на практиці це оперативно перетворюється на хаос.;[[AI|ШІ]] має змогу дуже оперативно створити першу версію моделі.; Тип
== ER-модель і форми документів ==

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

<syntaxhighlight lang="yaml">

У [[YML]] це має змогу бути описано так:

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

Тут кожне замовлення має посилання на одного контрагента.;<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

'''Масштабування.''' Легка платформа — це не платформа, у якій мало коду.; Спочатку начебто функціонує, потім усе ще начебто функціонує, а потім ніхто вже не знає, чому один документ пов’язаний із трьома таблицями, а четверта таблиця “історично так склалося”.;== Ієрархічні зв’язки ==
|-
| Один-до-одного
| Один запис однієї сутності відповідає одному запису іншої
| користувач системи — профіль користувача
|-
| Один-до-багатьох
| Один запис пов’язаний із багатьма записами іншої сутності
| Контрагент — замовлення
|-
| Багато-до-багатьох
| Багато записів однієї сутності пов’язані з багатьма записами іншої
| Користувачі — ролі
|-
| Композиція
| Одна сутність є собою частиною іншої
| Замовлення — рядки замовлення
|-
| Ієрархія
| Сутність має змогу посилатися сама на себе
| Групи товарів, підрозділи
|}

{| class="wikitable" style="width:100%;"

!; title: "Назва"
 entity: contractor

У [[TypeScript]] це має змогу виглядати так:

Така модель значно зрозуміліша.; - title: "Контрагенти"

Не треба починати з таблиць.; problem_description:

indexes:
'''ER-модель у K2 ERP — це карта, з якої платформа має змогу автономно побудувати цілий цифровий будинок.'''
== ER-модель і документи ==
<syntaxhighlight lang="yaml">
 email:

 values:
 contractor_id:
інженери, виконані роботи, акти виконаних робіт.; Етап
Індекси особливо важливі для журналів документів, звітів і пошуку.; як ілюстрація:
 title: "Податковий номер"

 price
Правильна ER-модель сприяє:
[[Категорія:ERP]]
== ER-модель і продуктивність ==

type: directory

depends_on: Якщо модель правильна, платформа має змогу рости частинами.; Те, що на діаграмі виглядає як сутність “Контрагент” із полями, у YML має змогу виглядати так: Цей фрагмент означає, що документ має посилання на довідник контрагентів.; - name: idx_customer_order_date 

works:

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

number

Уявімо простий компонент продажів.; !; Це корисно для розробників, інтеграторів, аналітиків і тестувальників.; file 

 title: "Пріоритет"
Приклад [[YML]]-опису журналу, який випливає з ER-моделі:
як ілюстрація:
!; !; fields:
 title: "Статус"
== Приклад поганої моделі ==
</div>
У класичному розумінні [[ER-модель]] показує, які сутності існують у системі та як вони пов’язані між собою.; Краще мати зрозумілі сутності та поля.; Ланцюжок виглядає так:

contractor_id:

customer_order

[[AI|ШІ]] має змогу сформувати [[YML]]-структуру, яка фактично є собою текстовим представленням [[ER-модель|ER-моделі]].; fields:

 contractor_id: int

 entity: contractor
 title: "Назва"
Це надає можливість:
Якщо в [[ER-модель|ER-моделі]] є собою документ “Замовлення покупця”, платформа має змогу автономно створити журнал “Замовлення покупців”.; | Так.; Деякі сутності об’єднуються.;[[Категорія:Цифрова незалежність України]]
як ілюстрація, користувач системи має змогу мати багато ролей, а одна роль має змогу бути призначена багатьом користувачам.; contractor_id

* товар;
* кількість;
* ціна;
* сума.; як ілюстрація, до довідника контрагентів додали поле “Податковий номер”.; Обов’язкове

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

як ілюстрація, якщо додали нове поле:
<syntaxhighlight lang="text">
Де `user_role` — проміжна сутність.; Компонент має змогу мати:
Коли платформа росте, голова починає подавати заяву на відпустку.;</div>

 entity: employee
 entity: contractor

Коли платформа маленька, програміст має змогу тримати все це в голові.; ER-модель у [[K2 ERP]] має ширший сенс.; fields:

== ER-модель і AI ==

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

  • номер;
  • дата;
  • контрагент;
  • складський облік;
  • сума;
  • статус;
  • автор;
  • дата створення;
  • дата зміни.; Треба починати з бізнес-сенсу.; date: datetime

class Product(BaseModel):

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

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

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

[[ER-модель]] через [[YML]] має змогу бути джерелом для автоматичного створення [[ORM|ORM-моделей]].; type: string

Людина повинна перевірити:
 section: "продажі та реалізація"
title: "Сервісне обслуговування"

Це надає можливість краще контролювати якість компонентів.; |- | Для чого вона потрібна в K2 ERP?; * свої сутності;

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

Вступ

title: "Контрагент"

бізнес-процес виглядає так: 

 type: journal

Товар 1 ─── * Рядок замовлення 

- field: warehouse_id

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

characteristic

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

id: number;

ER-модель описує інформаційні дані.; Сутність + warranty_until: 

- title: "Товари"

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

ER-модель походить від англійського Entity-Relationship Model, тобто модель “сутність-зв’язок”.; title: "Контрагенти" У бізнесі є собою товари, контрагенти, договори, склади, рахунки, документи, заявки, платежі, підрозділи, співробітники, ролі, маршрути погодження, залишки, рухи, файли, характеристики й звіти.; як ілюстрація: 

Саме з цієї причини потрібна модель.;
journal: form: Форма документа — це те, що бачить користувач системи.; | З ER-моделі через YML можуть автономно створюватися ORM-моделі для Python, TypeScript та інших мов.; product_id → product.id Це найпоширеніший тип зв’язку.; Контрагент пов’язаний із договорами.; В ERP усе пов’язано з усім.; title: "Ролі користувачів" 
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">

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

 primary_key: true

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

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

type: enum

engineer_id:

type: reference

Меню в ERP додатково має змогу створюватися автономно на основі моделі.; Інші, навпаки, треба розділити.; Якщо таблиці ростуть без логіки, звіти починають працювати повільно.; |-

Яка роль людини?; layout:

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

equipment:

- critical

entity: user

customer_order_items

  • розроблена;
  • прийнята в роботу;
  • призначено інженера;
  • виконано роботи;
  • погоджено;
  • закрито.;
     contractor_id → contractor.id
{| class="wikitable" style="width:100%;"

title: "Контрагент"
contractorId: number;

type: link 

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

Вона починається зі структури.;== ER-модель і характеристики сутностей ==

{{DISPLAYTITLE:ER-модель}}

як ілюстрація, ER-модель показує, що є собою документ “Заявка на ремонт”, у якого є собою замовник, обладнання, характеристика проблеми, статус і виконавець.; title: "Відповідальний інженер"
 code:
Такий підхід надає можливість використовувати один механізм файлів у різних модулях.; Замовлення 1 ─── * Рядок замовлення

як ілюстрація, документ “Замовлення покупця” — це не без ускладнень таблиця `customer_order`.; Він думає про модель, якість, масштабування, бізнес-логіку й майбутній еволюція системи.; Разом вони дають повнішу картину системи.; |-
| Чи має змогу [[AI|ШІ]] створювати ER-моделі?; !; Масштабування неможливе без правильної моделі даних.; Вона має розвиватися через модель і контрольовані міграції.; type: string

 type: reference

<syntaxhighlight lang="text">

Тоді компонент можна встановлювати, оновлювати, переносити й підтримувати окремо.;<syntaxhighlight lang="text">
 id:

<syntaxhighlight lang="text">

<syntaxhighlight lang="text">

 title: "Сума"

!;[[AI|ШІ]] має змогу формувати [[YML]]-структури, які фактично описують [[ER-модель]] майбутнього компонента.; calculated: true

 type: directory

[[Категорія:TypeScript]]

 phone:

складський облік 1 ─── * Замовлення покупця

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

 items:

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

K2 ERP створюється як масштабована платформа.; type: integer У реальному бізнесі один замовник хоче для товару зберігати колір і розмір, інший — серійний номер і гарантію, третій — матеріал, бренд, сезонність, країну виробництва.; Логіка така: 

code: str
date

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

number

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

user
 order_id
== ER-модель і Git ==
 type: string

rate:

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

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

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

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

 title: "Код"
 title: "Номер"
!; З’являються нові документи.; field4

У [[K2 ERP]] людина має змогу описати задачу людською мовою:
[[Категорія:Українське програмне забезпечення]]
як ілюстрація, один контрагент має змогу мати багато замовлень.; type: directory
'''Саме через [[ER-модель|ER-моделі]], [[YML]], [[ORM]], генерацію, модульність і [[AI|ШІ]] [[K2 ERP]] формує новий підхід до створення [[ERP]]-систем — швидший, зрозуміліший, легший для розвитку і значно сучасніший за старі закриті технології.'''

 date: string;
ER-модель сприяє визначити:
!; name: str

 parent_id:
'''істотно.''' Без правильної [[ER-модель|ER-моделі]] велика [[ERP]]-система оперативно перетворюється на клубок таблиць, зв’язків і винятків.; |-
| ER-модель
| Архітектурна структура сутностей і зв’язків
|-
| YML-структура
| Текстовий характеристика моделі
|-
| ORM-модель
| Програмна модель для роботи з базою даних
|-
| Міграції
| Створення або зміна таблиць у базі даних
|-
| Код модуля
| Каркас програмного модуля
|-
| Меню
| Пункти меню компонента
|-
| Довідники
| Списки та картки довідників
|-
| Журнали документів
| Списки документів
|-
| Форми документів
| Інтерфейси введення й перегляду документів
|-
| Базовий функціональні можливості
| Типові операції роботи з даними
|}

Класична ER-модель часто закінчується на етапі проєктування бази даних.; required: true
Він більше не витрачає час на ручне дублювання структур.; - high

 - table_part: items
 name: service_management
== ER-модель і PostgreSQL ==

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

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

== ER-модель і журнали документів ==
 name:
 required: true

<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
 title: "Товари"
'''Усе це створюється автономно без ручного дублювання структури програмістом.'''

!; Користувачі — з ролями.; '''Головне.''' У [[K2 ERP]] [[ER-модель]] — це не без ускладнень малюнок із таблицями та стрілками.; id: int

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

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

class CustomerOrder(BaseModel):

 warehouse_id → warehouse.id

 - row:

У [[K2 ERP]] підхід інший.; з цієї причини [[ER-модель]] у [[K2 ERP]] ближча до архітектурної моделі компонента, ніж без ускладнень до технічної схеми бази даних.;<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
|-
| Що таке [[ER-модель]]?; required: true

{| class="wikitable" style="width:100%;"

 primary_key: true

[[K2 ERP]] розвивається як компонентна платформа.; Приклад
 type: string

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

 title: "Телефон"

 id

Де `entity_file` зберігає, до якої сутності й до якого запису прикладено файл.; |-
| Чому ER-модель важлива для масштабування?; title: "Батьківська група"

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

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

 type: string

* групи товарів;
* структура компанії;
* підрозділи;
* статті витрат;
* категорії документів;
* папки файлів.; У [[K2 ERP]] ця ідея розширюється: [[ER-модель]] стає не без ускладнень схемою для програміста, а джерелом автоматичної генерації працюючого компонента.; type: document
entity: user_role
 entity: contractor
{| class="wikitable" style="width:100%;"

Вона описує не тільки таблиці, а й бізнес-сутності.; Підхід K2 ERP з ER-моделями
Приклад опису індексу:
== ER-модель і ORM ==

Це надає можливість створювати дерево груп.; * [https://erp.kyiv.ua Сайт K2 ERP]
* [https://wiki.erp.kyiv.ua Wiki K2 ERP]
* [https://cloud.corp2.eu хмарна інфраструктура K2 ERP]
* [https://t.me/+uIdWI1W6vndkMTAy Telegram-канал K2 ERP]
* [https://t.me/+6jFwAZM6TQliNTdi Група обговорення функціоналу та пропозицій]
* [https://www.linkedin.com/company/k2erp/ LinkedIn K2]

платформа має змогу зрозуміти, що потрібно додати колонку в таблицю контрагентів.; Поле

Якщо кожну таку зміну робити через нове поле в таблиці, платформа оперативно стане важкою.; number: str

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

tax_number: 

title: "Статус"

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

 - field: total_amount
Якщо ER-модель представлена через [[YML]], її можна зберігати в [[Git]].; Основною базою даних для [[K2 ERP]] є собою [[PostgreSQL]].; amount
{| class="wikitable" style="width:100%;"
 title: "Дата"
fields:
ER-модель надає можливість показати ці сутності та зв’язки у зрозумілій формі.; Це бізнес-об’єкт, який має шапку, табличну частину, статуси, форму, журнал, меню, права доступу, правила розрахунку й інтеграції.; | [[YML]] має змогу бути текстовим представленням [[ER-модель|ER-моделі]], придатним для генерації коду та роботи з [[AI|ШІ]].;<syntaxhighlight lang="text">
 - field: date
}
</div>
!; З такої структури [[K2 ERP]] має змогу автономно створити компонент сервісного обслуговування.; Що відбувається
'''Формула.''' Ідея → [[AI|ШІ]] → [[YML]] → [[ER-модель]] → [[ORM]] → міграції → код модуля → меню → довідники → журнали → форми → готовий компонент.; |-
| Як ER-модель пов’язана з [[ORM]]?; type: string

 type: datetime

У ньому є собою:
+ title: "Гарантія до"
Правильна ER-модель впливає не тільки на красу архітектури, а й на швидкість роботи системи.; Це вже проста [[ER-модель]], яка показує основні сутності та зв’язки.; як ілюстрація, для сутності “Контрагент” можна сформувати таблицю:

 title: "Дата"

 - normal

quantity

Для розробників. ER-модель надає можливість бачити систему не як хаос таблиць, а як зрозумілу карту сутностей, зв’язків, документів, довідників і бізнес-логіки.; entity: customer_order Документ в ERP — це бізнес-подія.; - low 

fields:

contractor 1 ─── * customer_order

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

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

number: string;

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

ER-модель сприяє: як ілюстрація:

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