Datový model je kostra
このコンテンツはまだ日本語訳がありません。
K dispozici také v 29 jazycích
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 2 ze 7 kapitoly Myslet jako datový architekt, první kapitoly kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Myslet jako architekt · Další: Test vratnosti
Otázka, na kterou tento modul odpovídá: Proč na datovém modelu záleží víc než na čemkoli, co je na něm postavené, a jak ho posoudit?
Když učím datovou architekturu, je tu jedna věta, ke které se vracím pořád dokola: datový model je kostra.
Datový model je kostra systému. Všechno ostatní je postavené kolem něj a právě on drží zbytek těla pohromadě. Když se na někoho díváte, kostru nevidíte, ale ta rozhoduje o tom, jak vysoko ten člověk stojí, jak se pohybuje a co unese.
Vezměte si všechno, co v implementaci Salesforce stavíme. Kolem datového modelu stavíme automatizaci. Píšeme proti němu Apex a Flow, které ho čtou a aktualizují. Stavíme integrace, které do něj data posílají a vytahují je z něj. Vytváříme nad ním sestavy a analytiku a kolem něj navrhujeme zabezpečení. A čím dál častěji stavíme AI agenty, kteří musí těm datům rozumět a jednat podle nich. To všechno závisí na struktuře pod tím.
Proto tolik záleží na tom, trefit datový model brzy. Kostru můžete změnit i později. Ale nejspíš to bude bolet.
Začněte u byznysu
Section titled “Začněte u byznysu ”Dobrý datový model začíná jednoduchou otázkou: co byznys doopravdy potřebuje reprezentovat? Ne „jaké objekty Salesforce máme?“ A rozhodně ne „co dokážu rychle postavit?“
Nejdřív se snažíme porozumět byznysu. Jaké jsou v tomto byznysu důležité věci? Jak spolu souvisejí? Kdo je vlastní? Jak se v čase mění? Co je potřeba si pamatovat a co se sdílí napříč obchodními procesy? Teprve když těmto věcem porozumíme, máme je začít převádět na objekty, pole a vztahy.
Zní to samozřejmě. V praxi je ale velmi snadné postupovat obráceně. Někdo pozná něco, co vypadá jako příležitost, případ nebo majetek (Asset), a okamžitě kolem toho začne navrhovat. Někdy je to přesně správně. Někdy se snažíme strčit hranatý kolík do kulaté díry, a jakmile je kolem toho rozhodnutí postaveno dost, je vytažení kolíku velmi drahé.
Tuhle otázku slýchám pořád. Firma zákazníka může mít mnoho míst doručení. Má být každé místo účtem (Account), nebo vlastním objektem? Než odpovíte, všimněte si, co byste potřebovali vědět nejdřív: co místo pro tento byznys znamená a co se s ním děje. To je modelování byznysu před objekty. (Svou odpověď vám dám v kapitole 3.)
Podporovat. Růst. Fungovat.
Section titled “Podporovat. Růst. Fungovat. ”Když se dívám na datový model, chci, aby prošel třemi testy: podporovat byznys, růst s byznysem a fungovat výkonně.
Podporovat. Model musí podporovat to, čeho se byznys doopravdy snaží dosáhnout. Je velký rozdíl mezi modelem, který data technicky dokáže uložit, a modelem, který byznys skutečně dobře reprezentuje. Pokud neustále přidávám podivná pole, zvláštní příznaky, složitou automatizaci a výjimky, protože model úplně nesedí, začnu se ptát, jestli je problém opravdu v automatizaci. Možná je špatně model. Dobrý model by měl byznys dělat srozumitelnějším, ne méně srozumitelným.
Růst. Když říkám růst, nemyslím jen víc záznamů. Na objemu záleží: deset tisíc záznamů a sto milionů vytvářejí velmi odlišné problémy. Byznys ale roste i ve složitosti. Přidává produkty, vstupuje na nové trhy, kupuje firmy, mění procesy, přidává kanály a připojuje nové systémy. Zjistí, že něco, co považoval za jednu věc, je ve skutečnosti pět různých věcí. Model, který dnes funguje nádherně, se může stát pastí, pokud v něm není místo pro zítřek. Proto dávám přednost návrhům, které rostou přidáváním, před návrhy, které neustále mění to, co už existuje. Přidat něco nového je obvykle snazší než předefinovat něco, na čem závisí desítky dalších věcí.
Fungovat. Data jen tak neleží. Zapisujeme je, hledáme je, dotazujeme se na ně, sdílíme je, děláme nad nimi sestavy a integrujeme je, a čím dál častěji si je systémy AI načítají jako kontext, než začnou jednat. Model může na diagramu vypadat krásně, a přesto být v provozu hrozný. Navrhujeme proto pro obojí: jak jsou data uložená i jak se budou používat.
A musí fungovat dál. Musí fungovat ve velkém měřítku: když přibývá uživatelů, když roste objem dat, v reálných podmínkách a ve špičkách, v nejrušnějším dni roku, ne v průměrném. A musí fungovat dál i tehdy, když se stane něco nečekaného.
Podporovat. Růst. Fungovat. K těmto třem testům se budeme v celém kurzu vracet.
Příliš plochý, příliš složitý, nebo prostě špatný
Section titled “Příliš plochý, příliš složitý, nebo prostě špatný ”Viděl jsem datové modely selhat třemi způsoby.
Prvním je zvolit hned na začátku špatnou věc. Použijeme standardní objekt, protože vypadá dost podobně, a pak roky přidáváme výjimky, protože nikdy nesedí. To je ten hranatý kolík.
Druhým je udělat model příliš plochý. Všechno jde do jednoho objektu a zpočátku to vypadá nádherně jednoduše. Pak byznys roste a my zjistíme, že některé z těch věcí mají vlastní životní cyklus, mohou mít více instancí, potřebují vlastní zabezpečení nebo mají vlastní vztahy. Najednou reprezentujeme vztah jedna k mnoha pomocí Pole 1, Pole 2 a Pole 3 nebo čím dál složitějšími příznaky a automatizací. Model nám nenechal kam růst.
Třetí je opačná chyba: přehnaná normalizace. Vytvoříme elegantní diagram s objektem za objektem, každý pojem dokonale oddělený. Technicky krásné, prakticky mizerné. Uživatelé mu těžko rozumějí a rozvržení stránek i stránky Lightning se seznamem souvisejících záznamů za seznamem mohou začít působit nekonečně hluboko. Dotazy jsou složitější, automatizace prochází více vztahy, sestavy jsou těžší a platforma dělá víc práce, aby odpověděla na běžné obchodní otázky.
Co je tedy správně, plochý, nebo normalizovaný? Žádný vzorec neexistuje. V hlavě si držíte obraz optimálního modelu a rozumíte kompromisům, když se od něj vzdalujete. To je umění architektury a vrátíme se k němu v modulu 4 a v další kapitole, kde se naučíme modelovat. Prozatím si uvědomte, že samotná struktura je architektonické rozhodnutí.
Pozor na změny kostry
Section titled “Pozor na změny kostry ”Jakmile systém běží, jsem u zásadních změn datového modelu velmi opatrný.
Dejme tomu, že textové pole existuje už roky a někdo řekne: „Takhle ho už vlastně nepoužíváme. Změňme ho na číslo.“ Zní to jako změna pole. Ale co na tom poli závisí? Flow, Apex, sestavy, integrace, datové pipeline, externí aplikace, AI agenti. A co se stane s historickými daty? Samotná platforma vám nedovolí změnit typ pole, dokud na něj odkazuje kód nebo flow, a to vám napoví, jak daleko taková změna sahá.
Někdy správnou odpovědí není měnit to, co už existuje. Podle toho, jak zásadní změna je, raději vytvořím něco nového, záměrně migruji a starou strukturu vyřadím:
Přidávejte, neměňte. Vyřazujte, nepřekvapujte.
Salesforce vám dokonce dává způsob, jak to říct v metadatech: Field Usage pole lze nastavit na DeprecateCandidate, „planned for deprecation and no longer in use“ (určeno k vyřazení a už se nepoužívá). Tím je pole označené pro každého, kdo objekt čte; pole se tím neskryje, takže jeho vyřazení je pořád rozhodnutí, které musíte provést.
Jakmile totiž na něčem závisejí jiné části architektury, může být změna jeho významu mnohem nebezpečnější než změna jeho názvu. Nejhorší varianta je pole, jehož název zůstane stejný, zatímco se změní jeho obsah: všechno dál po proudu názvu pořád věří.
I něco tak jednoduchého jako zaškrtnutí políčka Required u pole se může stát časovanou bombou. Pokud už máte nasbíraná data, některé záznamy toto pole vyplněné mít nebudou. Pak za dny, týdny nebo měsíce někdo jeden z těch záznamů aktualizuje, uložení selže kvůli povinnému poli a tu hodnotu nikdo nemá. Jednoduchá změna, jako je označení pole jako povinného, může mít nezamýšlené a opožděné důsledky. K Required a k tomu, kdy je hodnota skutečně známá, se vrátíme v kapitole 3.
Nad rámec zkoušky: i AI staví na kostře. Požádejte nástroj AI, aby postavil aplikaci, a za pár minut vygeneruje objekty, pole, Flow, Apex, komponenty i testy. Pokud byl původní datový model špatně, důsledkům špatného rozhodnutí jsme se nevyhnuli; urychlili jsme je, protože každá vygenerovaná vrstva je další věc, která na té struktuře závisí. Proto chci, aby datový model vygenerovaný AI revidoval lidský architekt, rozuměl mu a nesl za něj odpovědnost. Modul 7 jde v tomto ještě dál.
Kostra je na prvním místě
Section titled “Kostra je na prvním místě ”V průběhu kurzu budeme mluvit o spoustě technologií: o objektech a vztazích, velkých objemech dat, dotazech, integraci, migraci, transakcích, zabezpečení, Data 360 a AI. Pod tím vším je datový model.
Pokud model podporuje byznys, dokáže s byznysem růst a funguje výkonně pro způsoby, jakými budeme data používat, postavili jsme pevný základ. Pokud základ pokazíme, všechno potom bude těžší.
Datový model je kostra. Architekti by měli být při navrhování kostry velmi opatrní. Změny existujících struktur mohou mít řetězové důsledky.
Co tady rozhoduje architekt
Section titled “Co tady rozhoduje architekt ”- Zda model podporuje byznys, dokáže s ním růst a funguje výkonně pro způsoby, jakými se data budou používat.
- Zda pojem sedí do standardního objektu, nebo je to hranatý kolík.
- Jak plochý nebo jak normalizovaný model udělat a proč.
- Zda má být změna kostry přidáním, migrací nebo vyřazením, a ne změnou na místě.
K prozkoumání
Section titled “K prozkoumání ”- Considerations for Converting the Field Type of a Custom Field (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): které změny typu mohou vést ke ztrátě dat a proč nelze změnit typ pole, na které odkazuje Apex, flow nebo procesy.
- Data Classification Metadata Fields (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): hodnoty Field Usage (Active, DeprecateCandidate, Hidden) a další klasifikační pole.