Datová architektura Salesforce

🌐 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)

Obrázek vytvořený pomocí AI

Přeloženo pomocí AI. Komunita překlad zatím nezkontrolovala. Číst anglicky

Studijní průvodce ke kapitole 3 kurzu Data Architect. Nejdřív si přečtěte deset 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.

Tohle je kapitola, kde se model potkává s platformou, a nese velkou část zkoušky. Živí oba největší oddíly, Data Modeling and Database Design a Salesforce Data Management, každý po čtvrtině zkoušky. Čísla platformy se mění: kontrolní seznam uvádí ta, která citují moduly, s datem ověření. Naučte se, k čemu každý limit je, a než se na něj spolehnete, ověřte si aktuální číslo.

Ke zkoušce

Odškrtávejte si je postupně. Každý bod odkazuje na místo, kde se vykládá.

DM-1: návrh datového modelu na platformě

• Vím, že Salesforce je platforma řízená metadaty a multitenantní: objekt jsou metadata, ne nová tabulka, a každý objekt dostane svá API ve chvíli, kdy existuje. (Metadata jsou plán, Vaše API přišlo s objektem)
• Vím, že governor limits existují proto, aby si jeden nájemník nemohl zabrat sdílené zdroje. (Výtah si nemůžete zabrat)
• Umím číst standardní datové modely: převod zájemce na účet, kontakt a příležitost; produkt příležitosti ukazuje na položku ceníku, která ukazuje na Product2; a na servisní straně případ, majetek a nárok. (Prodejní model, Servisní model)
• Vím, co rozhoduje obrazovka New Custom Object: název záznamu Text nebo Auto Number; Object Classification (se zapnutým sdílením, Bulk API a Streaming API je to objekt Enterprise Application, s vypnutými objekt Light Application); a Allow Search, ve výchozím stavu vypnuté. (Obrazovka New Custom Object)
• Umím číst název API: standardní objekty a pole nemají předponu ani příponu; vlastní objekty a pole končí na __c; spravovaný balíček přidává předponu svého oboru názvů (abc__); a pole, které přidáte do objektu balíčku, dostane __c, ale nikdy předponu dodavatele. (Předpony a přípony)
• Umím použít test čistého souladu pro standardní objekt a vím, kdy význam nebo váha ukazují k vlastnímu objektu. (Test čistého souladu)
• Vím, k čemu je Asset a osobní účty, že osobní účet zabírá zhruba dvojnásobné úložiště oproti firemnímu účtu a že jakmile jsou osobní účty povolené, nelze je zakázat. (Majetek je dobrý příklad, Osobní účty, Kdy je osoba účtem?)
• Typ pole volím podle chování, které potřebuji (číslo ve flotile není Number), a vím, že datum/čas se ukládá v GMT a zobrazuje v časovém pásmu každého čtenáře, takže se porovnává rozsahy, ne rovností. (Číslo není vždycky číslo, Date, Date/Time a Time)
• Vím, že text má dva druhy: do 255 znaků na záznamu (indexovatelný, použitelný jako jedinečné pole nebo External ID) a nad tím Long nebo Rich text, bez indexu, bez filtrování ve WHERE a bez vzorců. (Textová rodina)
• Vím, kdy použít Name typu auto number a že to není ID záznamu. (Potřebuje to člověk identifikovat?)
• Vím, jak External ID umožní integraci provést upsert a nahrát podřízené záznamy podle External ID jejich nadřazeného. (External ID)
• Vím, kdy má být hodnota odvozená vzorcem a kdy je to historický fakt, který se musí uložit. (Uložené, nebo odvozené?)
• Znám rozdíl mezi logickým spojovacím objektem (modelovací myšlenka: objekt, který spojuje dva jiné ve vztahu mnoho k mnoha, s vlastními atributy) a spojovacím objektem Salesforce (vlastní objekt se dvěma vztahy master-detail) a vím, že Salesforce myslí ten druhý. (Dva rodiče do šířky)
• Znám hierarchický vztah: zvláštní lookup jen na objektu User, jako standardní pole Manager, který se nemůže vrátit ke stejnému uživateli přímo ani nepřímo a není to hierarchie rolí. (Hierarchický)
• Znám rozdíl mezi lookupem a master-detail: vlastnictví, sdílení, povinný nadřazený záznam, kaskádové mazání, souhrnná pole. (Lookup, Master-detail)
• Vím, že master-detail nelze vytvořit na objektu, který už má data (vytvořit lookup, vyplnit ho, převést), zpět na lookup ho lze převést jen bez souhrnných polí na hlavním záznamu a k přesunu podřízeného záznamu potřebuje Allow reparenting. (Může podřízený záznam změnit nadřazený?)
• Znám tvar platformy pro master-detail: nejvýše tři vlastní podřízené úrovně do hloubky (lookup může řetězec přerušit kdekoli) a dva nadřazení master-detail do šířky. Ve spojovacím objektu Salesforce je jako první vytvořený master-detail primární (vlastník, vzhled, divize), druhý je sekundární a přístup potřebuje oba rodiče: vyhrává to nejpřísnější. (Tři úrovně do hloubky, Dva rodiče do šířky)
• Znám tři volby lookupu při smazání nadřazeného záznamu: vymazat pole (výchozí), zablokovat smazání, nebo kaskádovat, což je vypnuté, dokud to Salesforce nepovolí, a obchází sdílení. (Lookup)
• Vím, že vztah sám na sebe musí být lookup, a znám dva vestavěné: Parent Account u Account a Parent Case u Case. (Vztahy samy na sebe)
• Vím, že přepočet souhrnných polí může chvíli trvat, že souhrnné pole nemůže použít vzorec s NOW(), TODAY() ani odkazem na jiný objekt a že nemám volit master-detail jen kvůli souhrnnému poli: alternativou je uložené pole udržované aktuální přes flow nebo trigger. (Souhrnná pole jsou užitečná, ale nejsou zadarmo)
• Znám limity vztahů, které modul cituje: dva master-detail na objekt; 40 vztahových polí ve výchozím stavu (nejvýše 50); 25 souhrnných polí ve výchozím stavu (nejvýše 40). (I vztahy mají limity)

DM-2: model, který respektuje sdílení a škáluje

• Vím, že podřízený záznam master-detail nemá vlastního vlastníka ani tabulku sdílení: přístup se řídí hlavním záznamem. (Vlastnictví se veze s sebou)
• Znám parent-child skew: doporučení Salesforce je nejvýše zhruba 10 000 podřízených záznamů na jeden nadřazený. (Otázka 10 000 podřízených záznamů)
• Znám ownership skew (jeden uživatel vlastní víc než 10 000 záznamů objektu) a doporučení: rozprostřít vlastnictví, nebo držet toho uživatele mimo hierarchii rolí, případně samotného nahoře, a mimo veřejné skupiny, které používají pravidla sdílení. (Vlastnictví se může stát problémem měřítka)
• Znám tabulku sdílení: objekt sdílení vlastního objektu je Object__Share; podřízený objekt žádný nemá, jeho přístup pochází z hlavního záznamu; a změna vlastníka odstraní ruční sdílení, ale ponechá sdílení v Apexu s vlastním důvodem. (Tabulka sdílení)
• Umím rozhodnout, kdo vlastní záznamy, které vytvářejí integrace a agenti, podle toho, jestli vlastnictví řídí sdílení. (Kdo vlastní záznamy, které vytvářejí systémy?)

DM-4: big objects oproti standardním a vlastním objektům

• Znám tři domovy dat: na core (sObjects, s každodenní prací), odkazovaná (zdrojem pravdy je jiný systém: externí objekty Salesforce Connect, __x, nebo vlastní volání) a archivovaná (na core v big objects, __b, nebo mimo core v datovém skladu). (Na core a mimo core)
• Vím, že externí objekty provedou callout při každém sáhnutí, takže záleží na latenci a dostupnosti zdrojového systému. (Odkazovaná)
• Znám big objects: obrovské objemy, dotazy přes jejich index přesnou shodou nebo rozsahem, žádné standardní rozhraní ani sestavy, jen oprávnění k objektu a polím, žádná automatizace. (Archivovaná)
• Vím, že většina záznamů se počítá zhruba jako 2 KB úložiště dat bez ohledu na pole a že soubory se měří zvlášť v úložišti souborů. (Dva sloupce, nebo dvě stě, Soubory a přílohy)

SDM-1: licence a objekty, které lidé mohou používat

• Znám tři interní licence, Sales Cloud, Service Cloud a Platform, a co každá může používat. (Tři interní licence)
• Vím, že licence jsou součástí datového modelu: uživatelé Salesforce Platform nedostanou zájemce, kampaně, příležitosti ani předpovědi a uživatelé Customer Community nemohou používat Opportunity. (A teď všechno zkomplikuji: licence)
• Znám úrovně externích licencí: Customer Community, Customer Community Plus (sestavy, řídicí panely, standardní sdílení), Partner Community (prodejní objekty); a vím, že Partner Community nelze používat s osobními účty. (Stadion)
• Znám licencování podle členů a podle přihlášení a vím, na jakou skupinu uživatelů které sedí. (Jak platí, mění návrh)
• Vím, že některé licence platformy omezují uživatele na jednu aplikaci s nejvýše deseti vlastními objekty, a znám vzor s typy záznamu, jak se do toho vejít. (Když licence tvaruje model)
• Vím, že licence Salesforce Integration je pro uživatele systém–systém, jen přes API. (Uživateli už nejsou jen lidé)
• Vím, že sestavy SLA potřebují nároky a milníky, které potřebují licence Service. (A teď všechno zkomplikuji: licence)

SDM-2: udržení konzistence dat

• Umím pravidlo umístit na správnou příčku žebříčku konzistence: typ pole a slovník, povinnost a jedinečnost, ověřovací pravidla, pravidla duplicit, automatizace. (Udržení konzistence dat)
• Vím, že omezený výběrový seznam odmítne hodnoty, které nejsou na seznamu, i přes API, a že globální sada hodnot sdílí jeden seznam napříč poli (až 1 000 hodnot). (Příčka první)
• Vím, že požadavek v rozvržení stránky chrání jen tu obrazovku, ne data, a že ověřovací pravidla běží při každém uložení. (Ověření v rozhraní není ověření dat, Příčka třetí)
• Umím omezit ověřovací pravidlo pomocí ISNEW() a ISCHANGED(), vlastního oprávnění nebo data spuštění a vím, která uložení (včetně těch, která nemám pod kontrolou, jako dávková změna vlastníka nebo souhrnné pole) každá volba pořád kontroluje. (Problém starých záznamů)
• Znám pravidla shody a pravidla duplicit, limity, které modul cituje (pět aktivních pravidel duplicit na objekt, v každém tři pravidla shody), a vím, že neřeší identitu napříč systémy. (Příčka čtvrtá: pravidla duplicit)
• Vím, že pravidla duplicit neporovnávají záznamy uložené ve stejnou chvíli, že uložení přes API a import se blokují bez upozornění a že uložení a všechno, co spustí, se vrací zpět jako jedna transakce. (Příčka čtvrtá, Všechno, nebo nic)
• Vím, že Workflow Rules a Process Builder už nejsou podporované; automatizace znamená Flow nebo Apex. (Příčka pátá: automatizace)

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.

• Platforma má tvar. Navrhujte pro platformu, na které jste, ne pro obecnou databázi.
• Dívejte se na mateřskou loď. Podívejte se, jak Salesforce pojem modeluje, než si vymyslíte vlastní.
• Každý objekt je závazek: úložiště, limity, model sdílení, licence a závislosti.
• Ptejte se, kde data žijí, dřív než zvolíte objekt: na core, odkazovaná, nebo archivovaná.
• Přečtěte jakýkoli název API a víte, kdo ho vytvořil, a co můžete měnit.
• Pokud dnes nearchivujete, budete vůbec někdy archivovat?
• Než navrhnete big objects, udělejte prototyp.
• Různé obchodní názvy automaticky neznamenají různé objekty.
• Ptejte se, které identity data potřebují: lidé, zákazníci, partneři, integrace a agenti.
• Každé pole dostane popis, a klasifikaci tam, kde na tom záleží.
• Nejdřív popište chování vztahu; konfigurace ho implementuje. Nedeformujte model kvůli funkci.
• Otázka mazání: co se má stát s podřízenými záznamy, když někdo smaže nadřazený?
• Zvolte, který článek řetězec přeruší: lookup udělejte tam, kde má podřízený záznam opravdu vlastní život.
• Vlastnictví od primárního, přístup od obou: vyhrává to nejpřísnější.
• Oddělte neaktivní od pryč a udělejte z uchovávání obchodní pravidlo.
• Posuňte pravidlo tak nízko, kam správně patří, a legitimní historii dejte výjimku, místo abyste ji přepisovali.
• Diagram není architektura. Umějte každou strukturu vystopovat zpět k obchodnímu důvodu.

Pojmy k zapamatování

Pojem	V jedné větě
Řízený metadaty	Objekty a pole jsou definice, které platforma čte za běhu, ne nové fyzické tabulky
Multitenance	Mnoho orgů sdílí infrastrukturu, každý izolovaný, jako byty v jednom domě
Governor limits	Limity, které brání jednomu nájemníkovi monopolizovat sdílené zdroje
Externí objekt	Data zobrazená v Salesforce přes Salesforce Connect, načítaná ze zdroje při každém sáhnutí
Big object	Úložiště pro velmi velká, málo používaná data, dotazovaná přes index
Osobní účet	Jednotlivec reprezentovaný jako účet, pro modely business-to-consumer
Čistý soulad	Obchodní pojem, který odpovídá zamýšlenému účelu standardního objektu
External ID	Pole, které drží identifikátor jiného systému, používané pro upserty a párování
Upsert	Aktualizovat záznam, pokud existuje, vytvořit ho, pokud ne
Lookup	Vztah, kde si podřízený záznam ponechává vlastního vlastníka a vlastní život
Master-detail	Vztah, kde podřízený záznam patří k nadřazenému: zděděný vlastník a sdílení, kaskádové mazání, souhrnná pole
Logický spojovací objekt	Modelovací myšlenka: objekt, který spojuje dva jiné ve vztahu mnoho k mnoha a nese vlastní atributy, ať je postavený jakkoli
Spojovací objekt Salesforce (Salesforce Junction Object)	Co Salesforce myslí „junction object“: vlastní objekt se dvěma vztahy master-detail
Primární a sekundární hlavní záznam	Jako první vytvořený master-detail spojovacího objektu Salesforce (vlastník, vzhled, divize) a jeho druhý (rozsah sestav; stane se primárním, když se první odstraní)
Hierarchický vztah	Zvláštní lookup jen na objektu User, jako Manager, který se nemůže vrátit ke stejnému uživateli
Předpona oboru názvů	Předpona dodavatele na objektech a polích spravovaného balíčku, třeba abc__Inspection__c
Tabulka sdílení	Objekt sdílení (AccountShare, Truck__Share), který drží většinu sdílení záznamu, jeden řádek na uživatele nebo skupinu, s důvodem
Souhrnné pole (roll-up summary)	Pole na hlavním záznamu, které počítá, sčítá nebo hledá minimum či maximum jeho podřízených záznamů
Data skew	Příliš mnoho záznamů pod jedním nadřazeným nebo jedním vlastníkem, které způsobuje zámky a dlouhé přepočty sdílení
Podle členů / podle přihlášení	Placení za externího uživatele, nebo za přihlášení každý měsíc
Žebříček konzistence	Vrstvy, které vynucují pravidla pro data, od typu pole po automatizaci
Omezený výběrový seznam	Výběrový seznam, který odmítne jakoukoli hodnotu, která není na seznamu, z jakéhokoli zdroje
Klasifikace dat	Metadata pole pro vlastníka, použití, citlivost a kategorii souladu

Otestujte se

Krátké scénáře ve stylu kurzu. Rozhodněte se pro odpověď dřív, než ji otevřete.

1. Uživatelé potřebují vidět podrobnosti objednávek, které vlastní ERP a celý den je aktualizuje. V Salesforce je neupravují. Zkopírovat je dovnitř, nebo ne?

Odkazujte na ně: externí objekty přes Salesforce Connect nechávají ERP zdrojem pravdy bez kopie, kterou by bylo nutné synchronizovat. Počítejte s tím, že každé zobrazení provede callout, takže záleží na latenci a dostupnosti ERP, a že se to hodí spíš pro čtení než pro intenzivní úpravy nebo sestavy. Přečtěte si znovu Odkazovaná.

2. Byznys chce sledovat distributory, dodavatele a maloobchodní partnery. Tři vlastní objekty?

Ne. Všechno jsou to firmy, takže Account čistě sedí; různé názvy jsou role, které nese typ, typ záznamu nebo vztah. Přečtěte si znovu Test čistého souladu.

3. Návrh používá Opportunity, ale většina lidí, kteří data potřebují, má licence Salesforce Platform nebo Customer Community. Co teď?

Tyto licence nemohou Opportunity používat, takže licence je architektonické omezení: koupit jiné licence, přesunout zážitek, nebo přenavrhnout, obvykle směrem k vlastnímu objektu. Přečtěte si znovu A teď všechno zkomplikuji: licence.

4. ERP posílá každou noc aktualizace účtů. Jak má integrace najít správný záznam, aniž by se dotazovala na ID Salesforce?

Uložte zákaznické číslo z ERP do pole External ID a proveďte podle něj upsert: aktualizovat, když se najde, vytvořit, když ne. Podřízené záznamy mohou na nadřazený ukázat také jeho External ID. Přečtěte si znovu External ID.

5. Položka doručení nemůže existovat bez svého doručení, nikdy se nepřesouvá a nepotřebuje vlastního vlastníka. Doručení existuje dřív, než je na trase, a může se přesunout na jinou trasu. Jaký vztah pro každé?

Položka doručení k doručení: master-detail (patří k nadřazenému celý život, dědí přístup, kaskáduje při smazání). Doručení k trase: lookup (vlastní život, zpočátku volitelný, přesunutelný a smazání trasy nikdy nesmí smazat doručení). Přečtěte si znovu Začněte obchodním vztahem.

6. Integrace vytváří 3 300 doručení denně, všechna vlastněná integračním uživatelem, který má roli uprostřed hierarchie. Jaké je riziko a jaká oprava?

Ownership skew: nad 10 000 záznamy spustí přesun toho uživatele nebo změna jeho skupin dlouhé přepočty sdílení. Pokud na vlastnictví záleží kvůli přístupu, rozprostřete ho; jinak držte integračního uživatele mimo hierarchii rolí, případně samotného v roli nahoře, a mimo skupiny, které používají pravidla sdílení. Přečtěte si znovu Vlastnictví se může stát problémem měřítka.

7. Přidáte ověřovací pravidlo a 20 000 starých záznamů ho porušuje. Uživatel na jednom z nich upraví telefonní číslo a uložení selže. Co mělo pravidlo udělat?

Říct, kdy vynucovat, ne jen co musí platit: omezit ho pomocí ISNEW() nebo ISCHANGED() na příslušná pole a dát záznamům starším než pravidlo záměrnou výjimku, místo přepisování jejich historie. Přečtěte si znovu Problém starých záznamů.

8. Byznys chce každou fotku z doručení „v Salesforce“: čtyři až pět milionů ročně, s růstem 30 procent. Co navrhnete?

Oddělte přístup od úložiště. Soubory držte v úložišti postaveném pro takový objem, mimo core org, a v Salesforce si nechte odkaz, počet nebo indexový záznam, aby je uživatelé našli a viděli. Přečtěte si znovu Fotky.

9. Přiřazení posádky má vztahy master-detail na Crew (vytvořený jako první) a Truck. Dispečer vidí posádku, ale ne kamion. Vidí přiřazení posádky?

Ne. Crew je primární, takže dává přiřazení vlastníka a vzhled, ale přístup potřebuje oba rodiče: dispečer potřebuje přístup k posádce i ke kamionu, na úrovni, kterou požaduje Sharing Setting každého pole master-detail. Vyhrává to nejpřísnější. Přečtěte si znovu Dva rodiče do šířky.

10. Partner znovu pošle soubor manifestu a stejný zákazník je v něm dvakrát. Na Account máte pravidlo duplicit nastavené na blokování. Jste v bezpečí?

Samotné pravidlo duplicit vás neochrání. Záznamy uložené ve stejnou chvíli se neporovnávají mezi sebou, jen se záznamy, které už v Salesforce jsou, takže oba řádky mohou projít. Posuňte jedinečnost dolů na pole: jedinečné External ID, které platforma kontroluje při každém uložení, takže vyhraje jen jeden. Přečtěte si znovu Příčka čtvrtá: pravidla duplicit a Všechno, nebo nic.

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.
• Sekce K prozkoumání každého modulu uvádí dokumentaci Salesforce, ze které vycházejí jeho fakta o platformě, s datem ověření.