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

ER-модель

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

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

  • номер;
  • дата;
  • контрагент;
  • складський облік;
  • коментар. {| class="wikitable" style="width:100%;"
priority:

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

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

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

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

 code:

* групи товарів;
* структура компанії;
* підрозділи;
* статті витрат;
* категорії документів;
* папки файлів. title: "Ставка"

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

 required: true

як приклад, до довідника контрагентів додали поле “Податковий номер”.== ER-модель і ORM ==

* номер;
* дата;
* контрагент;
* складський облік;
* сума;
* статус;
* автор;
* дата створення;
* дата зміни. name:

 type: string
! '''Усе це створюється автоматизовано без ручного дублювання структури програмістом.'''
Склади 1 ─── * Замовлення покупців
'''ER-модель → YML-структура → ORM-модель → міграції → програмний код модуля → меню → довідники → журнали документів → форми документів → базовий функції ERP.'''
== Чим ER-модель відрізняється від простої схеми бази даних ==
 - field: total_amount
[[Категорія:ORM]]
 title: "Замовлення покупця"
Типові помилки:

ER-модель у [[K2 ERP]] має ширший сенс. title: "E-mail"
Форма документа — це те, що бачить користувач системи. Така модель показує, що документ має основну таблицю і табличну частину. Контрагенти 1 ─── * Замовлення покупців

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

Приклад [[YML]]-опису журналу, який випливає з ER-моделі:
values:
Що таке ER-модель? type: string 
title: "ЄДРПОУ"

ER-модель у K2 ERP

- field: number
Вона починається зі структури.
 - title: "Замовлення покупців"
 - low
 entity: contractor
== ER-модель і форми документів ==
! + type: date

ER-модель здатна бути джерелом для автоматичного створення частини тестів. Приклад опису залежностей модуля:
</div>
<syntaxhighlight lang="text">
Масштабування неможливе без правильної моделі даних. entity: role

== Висновок ==

[[Категорія:AI]]
 works:
 entity: contractor
У [[K2 ERP]] після акцепту [[ER-модель|ER-моделі]] запускається автоматичне створення компонента. як приклад:

rate:

В ERP усе пов’язано з усім. Якщо ER-модель правильно описує поля документа і табличні частини, форма здатна бути розроблена автоматизовано.ORM-модель — це програмне представлення сутностей і зв’язків.== ER-модель і PostgreSQL ==

Якщо в компоненті виступає як довідники й документи, платформа здатна сформувати відповідні пункти меню. price: Decimal 

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

amount:

values:

type: integer

+ warranty_until: </syntaxhighlight> Приклад для груп товарів: 

serial_number:

contractor_id:

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

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

field5

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

type: directory
- field: warehouse_id

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

як приклад:

 id

{| class="wikitable" style="width:100%;"
== Коротко ==
 total_amount
В [[ER-модель|ER-моделі]] це можна враховувати окремими універсальними сутностями:

 fields:
== Приклад простої ER-моделі ==
[[Категорія:Альтернатива BAS]]
Це корисно для розробників, інтеграторів, аналітиків і тестувальників. Якщо таблиці ростуть без логіки, звіти починають працювати повільно. user
як приклад, один контрагент здатна мати багато замовлень. contractor_id

Це дає можливість доповнювати товари, контрагентів, документи чи обладнання додатковими властивостями без постійного переписування структури. id: int
 required: true
 type: reference

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

title: "Власник"

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

title: "Код"
fields:

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

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

</syntaxhighlight> 

primary_key: true
  • перевіряє модель;
  • уточнює промптами;
  • додає поля;
  • змінює зв’язки;
  • прибирає зайве;
  • доводить структуру до потрібного вигляду;
  • акцептує автоматичне створення компонента. | Перевірити модель, уточнити промпти, виправити структуру, акцептувати створення компонента й дописати складну логіку. - name: idx_customer_order_contractor

У великій ERP це критично. Якщо інформаційні дані дублюються, виникають помилки.

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

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

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

- contractors
required: true

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

Краще мати зрозумілі сутності та поля. | Так. Компонент здатна мати:

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

name:

module: service

</syntaxhighlight> </syntaxhighlight> contractor_id: title: "Телефон"

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

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

через [[ER-модель|ER-моделі]] [[K2 ERP]] здатна автоматизовано створювати [[YML]]-структури, [[ORM|ORM-моделі]], міграції, програмний код модуля, меню, довідники, журнали документів, форми документів і базовий функції ERP.<syntaxhighlight lang="yaml">

 title: "Дата"

Схема бази даних показує таблиці, поля й зв’язки на рівні СУБД. | Модель сутностей і зв’язків, яка описує структуру даних та бізнес-об’єктів системи. Якщо в ER-моделі з’явилася нова сутність або нове поле, платформа здатна створити відповідну міграцію. Тип Якщо ER-модель описує, що в системі існує сутність “Товар”, то ORM дає можливість працювати з цією сутністю в коді. У YML це здатна виглядати так: 

amount

entity: user

як приклад, документ “Замовлення покупця” — це не без зусиль таблиця `customer_order`. status Якщо структура системи не описана як модель, рефакторинг стає небезпечним. Це бізнес-об’єкт, який має шапку, табличну частину, статуси, форму, журнал, меню, права доступу, правила розрахунку й інтеграції. | Для автоматичного створення YML-структур, ORM-моделей, міграцій, коду модуля, меню, довідників, журналів і форм.</syntaxhighlight> 

type: integer
price
title: "клієнт ERP"
warehouse_id: int | None

</syntaxhighlight> 

quantity

id:
required: true
contractor_id:

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

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

default: normal

title: "Номер"

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

</syntaxhighlight> 

type: string
name: service_management

Приклад опису індексу: Це дає можливість краще контролювати якість компонентів. date

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

type: directory 

number

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

id:

Тому ER-модель у K2 ERP ближча до архітектурної моделі компонента, ніж без зусиль до технічної схеми бази даних. Коли до цього підключається штучний інтелект, людина здатна описати задум людською мовою, отримати модель, перевірити її, уточнити промптами й акцептувати автоматичне створення компонента. як приклад, документ “Замовлення покупця” посилається на довідник “Контрагенти” і довідник “Склади”. Приклад 

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

 type: integer
 primary_key: true
ER-модель дає можливість показати ці сутності та зв’язки у зрозумілій формі. складський облік — із залишками. Тип
! З’являються нові документи.

title: "Дата"

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

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

== ER-модель і меню ==
[[Категорія:YML]]

 type: directory
<syntaxhighlight lang="text">
'''Роль людини.''' [[AI|ШІ]] здатна запропонувати модель, але архітектор має її зрозуміти, перевірити, уточнити й акцептувати. Ролі — з правами доступу.[[Категорія:ERP для інтеграторів]]

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

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

[[Категорія:Програмування]]

entity: user_role

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

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

document
[[AI|ШІ]] здатна дуже оперативно створити першу версію моделі. entity: contractor

Не треба починати з таблиць. Обов’язкове

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

 type: reference
Приклад [[YML]]:
 section: "продажі та реалізація"
tax_number:

</div>
! entity: product_group

 repair_request:

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

 engineer_id:

 title: "Код"

* де застосовується для сутність;
* які документи на неї посилаються;
* які форми використовують поле;
* які журнали залежать від моделі;
* які звіти можуть змінитися;
* які міграції потрібно створити. Вона дає можливість описати систему не як набір випадкових таблиць, а як зрозумілу карту бізнес-сутностей, зв’язків, документів, довідників, табличних частин і залежностей. Це платформа, у якій правильно організовані моделі, зв’язки й модулі. Вона запускає механізм автоматичного створення компонентів. У [[K2 ERP]] людина здатна описати задачу людською мовою:
user * ─── * role
 type: text
 number

Одна з сильних сторін [[K2 ERP]] — можливість створювати незалежні легкі компоненти. class Product(BaseModel):
 field4
 type: string
як приклад, з [[ER-модель|ER-моделі]] товару здатна бути розроблена така умовна [[Python]]-модель:
== Основні елементи ER-моделі ==
 phone:
== Навіщо ER-модель потрібна в ERP ==
 title: "Години"
 id: int

customer_order_items

 required: true

Але на практиці це оперативно перетворюється на хаос. Замовлення 1 ─── * Рядок замовлення

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

id

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

fields:

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

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

 - field: warehouse_id
У текстовому вигляді це можна подати так:
 - field: number
{| class="wikitable" style="width:100%;"

== Вступ ==
 default: draft
 - row:
У бізнес-системах часто потрібні ієрархії. | [[YML]] здатна бути текстовим представленням [[ER-модель|ER-моделі]], придатним для генерації коду та роботи з [[AI|ШІ]]. Така модель значно зрозуміліша. Її намалювали, обговорили, погодили, а потім програміст пішов писати код. І табличну частину:

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

</div>
[[ER-модель]] описує інформаційні дані.[[AI|ШІ]] здатна сформувати [[YML]]-структуру, яка фактично виступає як текстовим представленням [[ER-модель|ER-моделі]]. contractor 1 ─── * customer_order
  • контрагенти;
  • товари;
  • склади;
  • підрозділи;
  • співробітники;
  • договори;
  • валюти;
  • одиниці виміру;
  • обладнання;
  • види робіт. * зрозуміти структуру майбутнього модуля;
  • уникнути дублювання сутностей;
  • правильно побудувати зв’язки;
  • побачити залежності до початку програмування;
  • спростити генерацію YML;
  • автоматизовано створювати ORM-моделі;
  • формувати міграції бази даних;
  • створювати меню, довідники, журнали й форми;
  • краще пояснювати структуру інтеграторам і партнерам;
  • давати штучному інтелекту зрозумілий контекст. SEO-опис проблеми, пріоритет, статус і відповідального інженера. - row:

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

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

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

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

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

Ієрархія означає, що сутність здатна посилатися сама на себе. Підхід K2 ERP з ER-моделями

  • таблицю документа;
  • таблицю табличної частини;
  • зв’язки між ними;
  • ORM-моделі;
  • міграції;
  • журнал документів;
  • форму документа;
  • табличну частину на формі;
  • базові API-операції;
  • пункт меню. Правильна модель — це фундамент масштабованості. Назва
Тобто ER-модель у K2 ERP — це не окремий малюнок “для краси”. У K2 ERP ця ідея розширюється: ER-модель стає не без зусиль схемою для програміста, а джерелом автоматичної генерації працюючого компонента. * уникати зайвого дублювання;
  • правильно будувати індекси;
  • готувати систему до секціонування таблиць;
  • покращувати швидкість журналів;
  • спрощувати звіти;
  • зменшувати технічний борг. ER + BP. ER-модель відповідає на питання “що зберігаємо?”, а BP-модель — “як це рухається в бізнес-процесі?”. Питання

entity: contractor title: "Групи товарів" 

type: string
== ER-модель і YML ==

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

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

Чим ER-модель відрізняється від схеми бази даних? required: true 
title: "Назва"
entity: contractor

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

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

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

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

як приклад, ER-модель показує, що виступає як документ “Заявка на ремонт”, у якого виступає як клієнт ERP, обладнання, SEO-опис проблеми, статус і виконавець.
Поганий приклад:
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
Якщо все це створювати без єдиної моделі, платформа оперативно починає нагадувати шафу, куди десять років складали документи “тимчасово”. | Вона описує не тільки таблиці, а бізнес-сутності, документи, довідники, табличні частини та зв’язки. це модель сутностей і зв’язків, яка описує структуру даних майбутнього компонента або бізнес-додатка виступає ключовою рисою '''ER-модель'''. customer_order_items

 order_id

 type: string

 columns:

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

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

customer_order

Це найпоширеніший тип зв’язку.<syntaxhighlight lang="text">
У [[K2 ERP]] [[ER-модель]] виступає як частиною більшого механізму створення бізнес-додатків. id

Цей фрагмент означає, що документ має посилання на довідник контрагентів. Він думає про модель, якість, масштабування, бізнес-логіку й майбутній дорожня карта розвитку системи. З такої структури [[K2 ERP]] здатна автоматизовано створити компонент сервісного обслуговування.<syntaxhighlight lang="yaml">

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

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

 id:

 id

* свої сутності;
* свої документи;
* свої довідники;
* свої журнали;
* свої форми;
* свої права;
* свої залежності;
* свої точки інтеграції. Користувачі — з ролями. entity: product_group

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

'''без зусиль кажучи.''' [[ER-модель]] — це схема, яка відповідає на питання: що існує в системі, які властивості воно має і як усе це пов’язано між собою. Замовлення — зі складом. title: "Робота"

* шапку документа;
* табличні частини;
* зв’язки з довідниками;
* статуси;
* службові поля;
* бізнес-правила. Людина перевіряє цю модель, уточнює промптами й акцептує автоматичне створення компонента. 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
}}

Але це не означає, що людина більше не потрібна. __TOC__
 type: decimal
Це видно в історії змін. title: "Назва"
платформа здатна зрозуміти, що потрібно додати колонку в таблицю контрагентів. | Вона дає можливість правильно організувати сутності, зв’язки, модулі й уникати хаосу при рості системи.== ER-модель і Git ==
== ER-модель і журнали документів ==
через У [[K2 ERP]] ця модель має особливе значення, бо вона не без зусиль користувачі можуть думати.== ER-модель і модульність ==

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

</div>
characteristic
 type: datetime
Разом вони дають повнішу картину системи. Поле

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

 - contractor_id

 type: integer

component:

Коли платформа маленька, програміст здатна тримати все це в голові. Пояснення

У [[K2 ERP]] наявність [[ER-модель|ER-моделі]] дає можливість робити рефакторинг більш керовано. Через пів року ніхто не знає, що означає `field3` для одного типу документа і чому `number2` для іншого типу раптом став сумою без ПДВ. '''Для AI-розробки.''' [[AI|ШІ]] здатна створювати [[YML]]-структури, які фактично виступає як текстовим представленням [[ER-модель|ER-моделі]]. * які сутності належать модулю;
* які сутності використовуються з інших модулів;
* які залежності виступає як обов’язковими;
* які залежності бажано зробити опціональними;
* які інформаційні дані потрібно експортувати через [[API]];
* які структури можна повторно використовувати. '''Масштабування.''' Легка платформа — це не платформа, у якій мало коду. Інші, навпаки, треба розділити. title: "Заявка на ремонт"

 date:

 - critical
<syntaxhighlight lang="text">
 - field: date
title: "Контрагенти"

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

 equipment_id:

 auto: true

 number: str

* замовлення покупця;
* рахунок;
* видаткова накладна;
* прибуткова накладна;
* заявка на ремонт;
* акт виконаних робіт;
* платіж;
* переміщення товарів;
* виробниче задача. |-
| Чи здатна [[AI|ШІ]] створювати ER-моделі?[[Категорія:Автоматизація бізнесу]]

 type: document
 title: "Виконані роботи"
 title: "Статус"
Будь-яка серйозна [[ERP]]-система починається не з красивого інтерфейсу і навіть не з програмного коду. Вона має розвиватися через модель і контрольовані міграції. Старі процеси спрощуються. date: string;
 warehouse_id → warehouse.id
[[K2 ERP]] розвивається як модульна ERP платформа. |-
| Як ER-модель пов’язана з [[YML]]? - in_work

indexes:

 problem_description:

[[Категорія:PostgreSQL]]
 title: "Сума"
[[Категорія:Штучний інтелект]]

У ньому виступає як:

== Приклад ER-моделі документа ==
  • дублювання одних і тих самих сутностей;
  • нечіткі назви таблиць і полів;
  • відсутність єдиних правил іменування;
  • занадто багато універсальних полів “на всяк випадок”;
  • змішування довідників і документів;
  • неправильна реалізація табличних частин;
  • зайві зв’язки багато-до-багатьох;
  • відсутність індексів для важливих полів;
  • ігнорування майбутніх звітів;
  • ігнорування прав доступу;
  • спроба описати процеси як поля, а не як BP-модель;
  • створення занадто жорсткої структури там, де краще використати характеристики. Уявімо простий компонент продажів. Якщо кожну таку зміну робити через нове поле в таблиці, платформа оперативно стане важкою. |-
Для чого вона потрібна в K2 ERP? role 
primary_key: true

 calculated: true
Навпаки, це піднімає програміста на рівень архітектора.== Приклад поганої моделі ==

 - title: "Контрагенти"
 - table_part: items

[[Категорія:ER-модель]]
як приклад:
 type: reference

menu:

 type: string

бізнес-середовище змінюється. Треба починати з бізнес-сенсу. Не всі властивості бізнес-об’єктів варто одразу жорстко зашивати в структуру таблиць. У [[YML]] це здатна бути описано так:
 text2
[[Категорія:ERP для розробників]]

title: "Батьківська група"

BP-модель показує, як ця заявка рухається: З ER-моделі можуть автоматизовано створюватися структури для PostgreSQL: 

work_name:

comment
- warehouse 
required: true

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

class CustomerOrder(BaseModel):

export interface CustomerOrder { Заявка має містити номер, дату, клієнта, обладнання,

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

title: "Сума"

customer_order 

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

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

depends_on:

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

'''ER-модель у K2 ERP — це карта, з якої платформа здатна автоматизовано побудувати цілий цифровий будинок.'''
! Зв’язки
 items:
 entity: customer_order
 - field: contractor_id
 - row:
<syntaxhighlight lang="python">
 amount

ER-модель оптимізує:

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

</syntaxhighlight> </syntaxhighlight> 

type: directory
warehouseId?: number;

Фундамент системи. У великій ERP структура бази даних не повинна змінюватися випадковими ручними правками. Приклад 

table_parts:

date: datetime
Елемент

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

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

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

- completed
title: "Товари"
type: decimal
title: "Обладнання"
title: "Замовлення покупців"

компонент повинен мати зрозумілі межі. ! Етап 

- high
code:

type: directory

</syntaxhighlight> 

id:

Якщо модель правильна, платформа здатна рости частинами. type: reference Контрагент пов’язаний із договорами. {| class="wikitable" style="width:100%;"

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

Як ER-модель пов’язана з ORM?

Див. так само

type

Він більше не витрачає час на ручне дублювання структур. number2 

type: reference

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

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

Журнал документів — це список документів певного типу. id: number; Саме тому потрібна модель. type: enum

  • якщо поле обов’язкове, тест перевіряє, що запис без нього не зберігається;
  • якщо поле виступає як посиланням, тест перевіряє коректність зв’язку;
  • якщо поле має тип `decimal`, тест перевіряє числові значення;
  • якщо документ має табличну частину, тест перевіряє її збереження;
  • якщо виступає як статуси, тест перевіряє допустимі значення. |-
 Яка роль людини? Створи ER-модель для модуля сервісного обслуговування. Саме через ER-моделі, YML, ORM, генерацію, модульність і ШІ K2 ERP формує новий підхід до створення ERP-систем — швидший, зрозуміліший, легший для розвитку і значно сучасніший за старі закриті технології. 
code: str
  • таблиці;
  • поля;
  • первинні ключі;
  • зовнішні ключі;
  • індекси;
  • обмеження;
  • міграції. fields:

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

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

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

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

title: "Обладнання"

</syntaxhighlight> 

name:

quantity

Це дає можливість створювати дерево груп. type: string 

- date

layout:
  • розроблена;
  • прийнята в роботу;
  • призначено інженера;
  • виконано роботи;
  • погоджено;
  • закрито. user_role
 Спочатку потрібно відповісти на питання:
  • товар;
  • кількість;
  • ціна;
  • сума. required: true
Це не скасовує роль програміста.
! warehouse_id
 title: "SEO-опис проблеми"
</div>

 contractor_id:
 title: "Пріоритет"
 - draft
'''Головне.''' У [[K2 ERP]] [[ER-модель]] — це не без зусиль малюнок із таблицями та стрілками.== Приклад ER-моделі у вигляді таблиці ==

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

 entity: customer_order
Такий підхід дає можливість використовувати один механізм файлів у різних модулях. Рефакторинг у великих [[ERP]]-системах неминучий. Тут кожне замовлення має посилання на одного контрагента. |}

 product_id → product.id

[[Категорія:Автоматична генерація коду]]

як приклад:

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

<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">

У бізнесі виступає як товари, контрагенти, договори, склади, рахунки, документи, заявки, платежі, підрозділи, співробітники, ролі, маршрути погодження, залишки, рухи, файли, характеристики й звіти. В ER-моделі це можна описати через універсальну сутність файлів і зв’язків. У [[K2 ERP]] [[YML]] здатна бути текстовим представленням [[ER-модель|ER-моделі]].</div>
 type: reference
 date
 type: string

<syntaxhighlight lang="yaml">

! product_id

 title: "складський облік"

 number: string;

 title: "Відповідальний інженер"

* бачити історію змін;
* порівнювати версії;
* робити code review моделей;
* повертатися до попередніх версій;
* працювати командою;
* аналізувати, хто і коли змінив структуру;
* пов’язувати зміни моделі з релізами. Це дає можливість:
 entity: contractor
Де `entity_file` зберігає, до якої сутності й до якого запису прикладено файл. entity_characteristic_value
 - name: idx_customer_order_date

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

 entity: equipment

<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">

</div>

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

Документ в [[ERP]] — це бізнес-подія. type: string
 parent_id:
title: "Сервісне обслуговування"

 contractorId: number;
== ER-модель і характеристики сутностей ==
 field1
Основною базою даних для [[K2 ERP]] виступає як [[PostgreSQL]]. Договір — із рахунками. Спочатку начебто функціонує, потім усе ще начебто функціонує, а потім ніхто вже не знає, чому один документ пов’язаний із трьома таблицями, а четверта таблиця “історично так склалося”. Це архітектурна модель, з якої здатна автоматизовано народжуватися [[YML]]-структура, [[ORM|ORM-модель]], міграції, код модуля, меню, довідники, журнали документів і форми документів. type: enum

 type: journal
Саме для цього потрібна [[ER-модель]].
  • договір до контрагента;
  • сертифікат до товару;
  • фото поломки до заявки на ремонт;
  • акт до документа;
  • інструкцію до обладнання. - field: contractor_id
<syntaxhighlight lang="yaml">
 edrpou:
Правильна ER-модель оптимізує:

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

 - title: "Товари"

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

entity

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

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

! Залишки — з рухами товарів. - field: comment
Якщо зв’язки побудовані хаотично, запити стають важкими. Меню в [[ERP]] так само здатна створюватися автоматизовано на основі моделі. Що створюється автоматизовано

'''Для розробників.''' [[ER-модель]] дає можливість бачити систему не як хаос таблиць, а як зрозумілу карту сутностей, зв’язків, документів, довідників і бізнес-логіки. | З ER-моделі через [[YML]] можуть автоматизовано створюватися [[ORM|ORM-моделі]] для [[Python]], [[TypeScript]] та інших мов. contractor_id: int

 title: "Назва"

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

<syntaxhighlight lang="yaml">
Довідники — це одна з базових частин [[ERP]]. |-
| Чому ER-модель важлива для масштабування? ! entity: employee
|-
| ER-модель
| Архітектурна структура сутностей і зв’язків
|-
| YML-структура
| Текстовий SEO-опис моделі
|-
| ORM-модель
| Програмна модель для роботи з базою даних
|-
| Міграції
| Створення або зміна таблиць у базі даних
|-
| Код модуля
| Каркас програмного модуля
|-
| Меню
| Пункти меню компонента
|-
| Довідники
| Списки та картки довідників
|-
| Журнали документів
| Списки документів
|-
| Форми документів
| Інтерфейси введення й перегляду документів
|-
| Базовий функції ERP
| Типові операції роботи з даними
|}

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

 unit: str

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

 - normal

У результаті користувач системи отримує меню, пов’язане зі структурою компонента. ER-модель складається з кількох ключових частин. primary_key: true

 - crm

entities:

 hours:

[[K2 ERP]] створюється як масштабована платформа. Відповідь

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

Якщо модель неправильна, то при рості кількості клієнтів, документів, модулів і інтеграцій платформа починає важчати. fields:
 type: reference
Для людини це зрозуміло як бізнес-зв’язок. |-
| 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
|}

</syntaxhighlight>

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

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

order_id → customer_order.id

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

- field: status

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


як приклад:

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

<syntaxhighlight lang="text">

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

title: "Статус"

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

<syntaxhighlight lang="python">

<syntaxhighlight lang="text"> 

required: true

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

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

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

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

Де `user_role` — проміжна сутність. Рахунок — із оплатами. title: "Контрагент" form:

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