Myslet jako datový architekt
Dette innholdet er ikke tilgjengelig på ditt språk.
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)
Studijní průvodce ke kapitole 1 kurzu Data Architect. Nejdřív si přečtěte sedm modulů; tato stránka vám pomůže ověřit, co vám zůstalo v hlavě.
O tomto studijním průvodci. Je sestavený jen z vlastního obsahu tohoto kurzu a ze seznamu cílů v oficiálním průvodci zkouškou od Salesforce. Nikdy nevychází ze skutečných zkouškových otázek a netvrdí, že ví, co u zkoušky bude. Pokud jste zkoušku skládali, prosím, neposílejte mi z ní otázky: certifikační smlouva jejich sdílení zakazuje a učit se odpovědi nazpaměť je stejně špatná cesta, jak se stát architektem.
Tato kapitola obsahuje méně zkouškových faktů, a to záměrně. Je o tom, jak architekt myslí, a žádný cíl zkoušky nepatří jen jí. Zkouška je ale postavená ze scénářů: byznys, nějaká čísla, omezení a několik odpovědí, které by mohly fungovat. Návyky z této kapitoly jsou způsob, jak takové scénáře číst. Kontrolní seznam níže proto uvádí, který cíl každý bod podporuje, místo aby tvrdil, že se testuje přímo.
Ke zkoušce
Section titled “Ke zkoušce ”Odškrtávejte si je postupně. Každý bod odkazuje na místo, kde se vykládá.
Číst scénář jako architekt (podporuje všechny cíle)
- Odděluji skutečný požadavek od návrhu, ve kterém přišel („potřebujeme pole Schvalovatel 2 a Schvalovatel 3“ oproti „potřebujeme sledovat každé schválení“). (Nepřebírejte požadavek jen tak)
- Hledám implicitní požadavky, které nikdo nevyslovil: vlastnictví, čerstvost, selhání, uchovávání, přístup. (Hledejte implicitní požadavky)
- Dávám k tomu čísla: objem za den, za rok, s růstem, a všimnu si, když jedna nula navíc změní odpověď. (Znejte svá čísla)
- Mezi několika fungujícími odpověďmi porovnávám, co každá získává a čeho se vzdává, proti uvedeným požadavkům a omezením. (Vězte, čeho se vzdáváte, Omezení mění odpověď)
- Beru náklady, licence a limity jako součást toho, jestli nástroj sedí, ne jako dodatečnou myšlenku. (Devět otázek)
Datový model (podporuje DM-1)
- Umím model posoudit podle toho, jestli byznys podporuje, dokáže s ním růst a funguje výkonně. (Podporovat. Růst. Fungovat.)
- Poznám model, který je příliš plochý (Pole 1, Pole 2, Pole 3), přehnaně normalizovaný nebo postavený na špatném standardním objektu. (Příliš plochý, příliš složitý, nebo prostě špatný)
- Vím, proč se výběrový seznam hodí pro krátký, stabilní seznam a lookup pro seznam, který pořád roste nebo přichází z integrace. (Mnoho způsobů, jak problém vyřešit)
- Vím, že klíč, který nese význam (třeba část jména), se rozbije, když se ten význam změní. (Některá rozhodnutí se mění levně)
Změny toho, co už existuje (podporuje DM-1 a SDM-2)
- Vím, proč změna typu pole nebo nastavení existujícího pole jako Required může později něco rozbít a proč platforma změnu typu blokuje, dokud na pole odkazuje kód nebo flow. (Pozor na změny kostry)
- Znám vzor přidávejte, neměňte; vyřazujte, nepřekvapujte a vím, že Field Usage umí pole označit jako kandidáta na vyřazení. (Pozor na změny kostry)
- Znám fakta o master-detail, která stojí za testem vratnosti: přístup a vlastnictví podřízeného záznamu se řídí hlavním záznamem, smazání hlavního záznamu smaže i podřízené, souhrnná pole (roll-up summary) potřebují master-detail a lookup se dá převést na master-detail, jen když má každý záznam hodnotu. (Test vratnosti, K prozkoumání)
Licence a sdílení (podporuje SDM-1)
- Vím, že komunitní uživatelé s vysokým objemem (mimo jiné Customer Community) nemají role a nepoužívají model sdílení, takže přístup jim dávají sady sdílení a skupiny sdílení, a sdílení v Apexu na ně nedosáhne. (Příklad z praxe: sdílení v Apexu)
Selhání (podporuje MIG-1 a integrační kapitoly)
- Vím, že „úloha dokončena“ neznamená totéž co data jsou správně, a vím, jak odsouhlasení najde záznamy, které nedorazily. (Částečný úspěch je pořád selhání, kterému musíte rozumět)
Nad rámec zkoušky
Section titled “Nad rámec zkoušky ”Zkouška je podlaha, ne strop. Tohle jsou návyky z této kapitoly, které architekt potřebuje, ať se na ně nějaká otázka zeptá, nebo ne.
- Někdo musí držet plán. Architektura znamená dělat dobrá rozhodnutí s neúplnými informacemi a znát jejich důsledky.
- Datový model je kostra. Všechno ostatní stojí na něm.
- Test vratnosti: jak těžké je to vrátit a kolik na tom bude záviset?
- Architektura vytváří gravitaci. Změnu nedělá drahou změna sama, ale závislosti.
- Myslete na dosah dopadu, uvnitř Salesforce i napříč podnikem. Architektura je obousměrný provoz.
- Zapište si proč: kontext, možnosti, rozhodnutí, důsledky, vlastník, revize. Nahrazujte, nemažte.
- Nejlepší v čem? Neoptimální rozhodnutí může být součástí optimální architektury, pokud víte, že ho děláte.
- Noste v hlavě obraz optima, abyste věděli, kterým směrem se od něj vzdalujete a proč.
- Think Correct. Think Fast. Rychlost pochází z přemýšlení, které proběhlo před tou chvílí.
- Stavějte pro dnešek. Plánujte pro zítřek. Plánujte pro selhání. A když vám nikdo nedá číslo, počítejte s 30procentním růstem.
- Učte se devět otázek, ne jen odpovědi.
- AI je raketový urychlovač. Generování není úsudek, nevratné je pořád nevratné a lidská revize není obřad. Důvěřuj, ale prověřuj.
Pojmy k zapamatování
Section titled “Pojmy k zapamatování ”| Pojem | V jedné větě |
|---|---|
| Architektonické rozhodnutí | Takové, které se těžko vrací a hodně na něm závisí |
| Test vratnosti (Reversibility Test) | Jak těžké je to vrátit a kolik na tom bude záviset? |
| Gravitace | Závislosti, které se kolem rozhodnutí časem nahromadí |
| Dosah dopadu (blast radius) | Všechno ostatní, co se pohne, když se rozhodnutí změní |
| Záznam o rozhodnutí | Kontext, možnosti, rozhodnutí, důsledky, vlastník a bod revize, stručně |
| Kompromis (trade-off) | Co možnost získává a čeho se vzdává, aby to získala |
| Implicitní požadavek | Něco, co byznys očekává, aniž by o to žádal, třeba obnovu, když nahrávání selže |
| Steveův „počet nul“ (Steve’s Number of Zeros) | Jedna nula navíc v objemu může změnit celou architekturu |
| Odsouhlasení | Porovnání toho, co se mělo stát, s tím, co se stalo, záznam po záznamu |
| Vyřadit (deprecate) | Označit něco jako končící a pak to záměrně vyřadit, místo abyste to měnili na místě |
| Uživatel s vysokým objemem (high-volume user) | Komunitní uživatel (mezi licencemi Customer Community) bez role, mimo model sdílení |
| Bující schéma (schema sprawl) | Objekty a pole, které se hromadí, protože se levně vytvářely, až model nikdo nenavrhl |
Otestujte se
Section titled “Otestujte se ”Krátké scénáře ve stylu kurzu. Rozhodněte se pro odpověď dřív, než ji otevřete.
1. Prodejní tým žádá na příležitosti (Opportunity) pole Schvalovatel 2 a Schvalovatel 3, každé s datem. Na co se zeptáte a co byste mohli postavit?
Zeptejte se proč a kolik schválení může být. Pokud jich může být víc než dvě nebo tři, požadavkem je sledovat každé schválení, ne přidat pole: podřízený objekt, jeden záznam na každé schválení. Přečtěte si znovu Nepřebírejte požadavek jen tak.
2. Někdo chce přejmenovat popisek pole a někdo jiný chce změnit formát zákaznického identifikátoru, který už ukládá pět systémů. Co si zaslouží víc vaší pozornosti a proč?
Identifikátor. Popisek se mění levně. Identifikátor neprojde testem vratnosti: těžko se vrací a už na něm hodně závisí. Pozornost věnujte úměrně ceně omylu. Přečtěte si znovu Některá rozhodnutí se mění levně.
3. Textové pole se používá už roky. Byznys chce, aby teď obsahovalo číslo. Jak postupujete?
Neměňte ho na místě. Zjistěte, co na něm závisí (Flow, Apex, sestavy, integrace, agenti) a co se stane se starými daty. Obvykle: přidejte nové pole, záměrně migrujte a staré vyřaďte. Přečtěte si znovu Pozor na změny kostry.
4. 1 200 poboček, 100 schůzek na pobočku denně, zhruba 305 dní v roce, dva záznamy na schůzku, uchovává se pět let, růst 30 procent. Kolik záznamů to zhruba je a proč na tom záleží?
Zhruba 73 milionů záznamů v prvním roce (36,6 milionu schůzek, každá se dvěma záznamy) a přes 650 milionů za pět let s růstem. Stejná funkce, o pár nul víc, úplně jiná architektura. Přečtěte si znovu Znejte svá čísla.
5. Noční nahrávání hlásí u milionu záznamů „dokončeno“. Jak poznáte, že to fungovalo?
Odsouhlasíte to. Přijímající strana potvrdí každý záznam, který uložila; odesílatel porovná, co poslal, s tím, co bylo potvrzeno. Chybějící potvrzení znamenají, že to nefungovalo, ať říká stav úlohy cokoli, a řeknou vám, které záznamy zopakovat, předat člověku nebo u kterých vyvolat výstrahu. Přečtěte si znovu Částečný úspěch je pořád selhání, kterému musíte rozumět.
6. Komunita s 15 miliony uživatelů Customer Community potřebuje složitý přístup k záznamům. Někdo navrhne sdílení v Apexu. Kde je problém?
Jsou to uživatelé s vysokým objemem: bez rolí, mimo model sdílení, takže neexistuje záznam sdílení, který by Apex mohl zapsat. Přístup jim dávají sady sdílení a skupiny sdílení. O tom, které nástroje sdílení existují, rozhodla licence. Přečtěte si znovu Příklad z praxe: sdílení v Apexu.
7. Nástroj AI vygeneruje pro novou aplikaci za pár minut dvacet objektů. Jaký je teď úkol architekta?
Rozhodnout, jestli bychom jich neměli mít pět. Rozumět modelu natolik, abyste ho dokázali obhájit: proč tyto objekty a vztahy, kde jsou klíče a kmenová data, co se stane ve velkém měřítku. Ověřit fakta, o která se opíral. Generování není úsudek. Přečtěte si znovu Levná implementace přesouvá hodnotu.
K prozkoumání
Section titled “K prozkoumání ”- Salesforce Certified Platform Data Architect Exam Guide (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): oficiální seznam cílů a jejich vah. Před přihlášením ke zkoušce si vždy ověřte aktuální verzi.