Datový model Helios Green/Nephrite

Slíbil jsem účastníkům školení SQL datové schéma nejčastějších tabulek Helios Green/Nephrite.

Jako příklad jsem vzal faktury vydané (v Heliosu tzv. třída). Viz schéma níže. Třída se zjistí na záznamu CTRL+SHIFT+DEL (viz obrázek). Třída může mít více pořadačů, což jsou číselné řady. Technicky je to pořád jedna tabulka, jen je v ní cislo_poradace pro rozlišení. Vždy musí existovat alespoň jeden pořadač.

Základní tabulky třídy Faktury vydané:

• lcs.faktura_vydana_hlavicka – hlavní tabulka (hlavička) od dodavatele. Primární klíč je cislo_subjektu.
• lcs.faktura_vydana_polozka – tabulka s položkami (řádky) opět od dodavatele. Obsahuje cislo_subjektu hlavicky. Primární klíč je pak cislo_nonsubjektu.
• lcs.uda_faktura_vydana_hlavicka a lcs.uda_faktura_vydana_polozka – správce může přidat vlastní atributy. Ty jsou v tabulkách, které se jmenují stejně, jen mají na začátku UDA (UživatelskyDefinovanýAtribut). Mají stejné primární klíče! Nemusí existovat.

Vazby na ostatní třídy (číselníky) jsou normální. Prostě sloupeček int. Nepozná se to z názvu (z repozitory). Nepoužívají se cizí klíče, referenční integritu zajišťuje jádro aplikace. Na obrázku je vazba na třídu organizace (tabulka lcs.organizace). Ta má primární klíč cislo_subjektu.

Pak existuje ještě jedna velká tabulka nazvaná lcs.subjekty. To je ten posun do meta. Standardní třídy (subjektové) mají primární klíč duplicitně i v tabulce lcs.subjekty. Takže cislo_subjektu je jednoznačné v celém systému! Když už je cislo_subjektu duplicitně, tak se rovnou přidaly i další společné atributy (=pole=sloupce):

• reference_subjektu – varchar(30)
• nazev_subjektu -varchar(40)
• cislo_poradace -int

Tyto atributy mohou (ale většinou nejsou) i v tabulce třídy. U těch faktur vydaných tomu tak je. Třeba útvar, účet, atd. mají reference_subjektu a nazev_subjektu jen v lcs.subjekty. Pozná se to tak, že se podívám do tabulky, nebo je na třídě zaškrtávátko „kopírovat systémové atributy“.

Na tabulce bývá nazev_subjektu delší! V lcs.subjekty je nazev_subjektu oříznutý na varchar(40) vždy, v lcs.organizace je pak nazev_subjektu varchar(200).

Výhody a nevýhody subjektových tříd z hlediska systému (jak je vidím já):

• 👍Jednoznačnost cislo_subjektu v rámci databáze.
• 👍Subjektové třídy mají v jádru podporu pro sledování změn, kdy naposledy pořídil a kdy.
• 👍Joinuje se pořád dokola jedna (zaindexovaná) tabulka (nemusím joinovat lcs.organizace když potřebuji jen IČO nebo název 40 znaků).
• 👎Složitější na údržbu, pochopení, správu.
• 👎Duplicitní atributy – víc místa a jednou je ořezané.
• 👎Tendence zamykání se tabulky lcs.subjekty (=zaseknutí Heliosu).
• ?

Uživatelsky definované třídy už dělám vždy jako nonsubjektové (díky Honzo). Nonsubjektové třídy nemají záznam v lcs.subjekty. Místo cislo_subjektu mají cislo_nonsubjektu. Jsou to normální tabulky, se kterými se prostě dobře pracuje.

Na atributu (políčku) zjistím jeho databázový název pomocí CTRL+SHIFT+DEL (viz obrázek). Pokud není vyplněný, atribut je buď špatně zavedený v repozitory, nebo je v repozitory vypočítaný výrazem (tomu se u sebe vyhýbám).
Udělat tímto výrazem cenu celkem na položce faktury (lcs.faktura_vydana_polozka.cena_celkem) je podle mě prostě hloupé (lcs.faktura_vydana_polozka.cena_zaklad+lcs.faktura_vydana_polozka.dph_celkem).

Dynamické vztahy jsou uloženy v tabulce lcs.vztahy subjektu (pro položkové lcs.objektsubjekt). Prostě cislo_subjektu zleva, cislo_vztaz_subjektu je cislo_subjektu zprava a cislo_vztahu (zjistí se CTRL+SHIFT+DEL).

Valuace atributů je povedená funkcionalita. V tabulce je třeba sloupec stav char(1), fyzicky je uloženo jen ‚O‘, ‚K‘. Pro každou možnou hodnotu, kterou může uživatel z listboxu vybrat, je záznam v tabulce lcs.attribute_valuation_entry. Ten převádí O na OK , K na KO apod. V databázi to může být i třeba int ale je vhodné používat char(1).

Další tabulky jsou:

• lcs.objekt_hledspec – kategorie. Ty ale moc nepoužívám.
• lcs.editstyles – editační styly. Něco jako valuace, ale natvrdo od dodavatele.
• ?

Kromě standardních tabulek existují v Heliosu ještě tabulky metadat, neboli tzv. repozitory. Ty popisují standardní tabulky (něco jako je na SQL serveru . Třeba když vznikne nová třída, bude o ní záznam v lcs.nis_tridy, musí mít pořadač, takže aspoň jeden záznam v lcs.poradace, musí mít nějaké atributy nebo vztahy (lcs.nis_columns, lcs.vztahy) apod.

• lcs.nis_tridy – třídy
• lcs.poradace – pořadače
• lcs.vztahy – vztahy
• lcs.vztahporadac – kam vztah vede
• lcs.nis_columns – atributy
• atd.

💡 CTRL+SHIFT+S v přehledu se zobrazí aktuální select. Pro zformátování používám online formatter poorsql.com.