Převeďte model do 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

Modul 6 z 6 kapitoly Modelování dat podle významu, kapitoly 2 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Navrhujte do třetí normální formy, pak couvněte · Další: studijní průvodce kapitolou, pak další kapitola: Datová architektura Salesforce

Otázka, na kterou tento modul odpovídá: Jak se z logického datového modelu stane fyzický datový model Salesforce?

Konečně budeme mluvit o Salesforce. Pokud jste odolávali nutkání udělat z každé krabice objekt, teď můžete. Všimněte si ale, v jakém pořadí jsme sem došli: porozuměli jsme byznysu, popsali data, dali každý fakt tam, kam patří, a rozhodli, kde to záměrně ohneme. Teprve teď se ptám, jak by to měl Salesforce implementovat. To je postup, který si chci, abyste zapamatovali: konceptuální → logický → fyzický. Konceptuální model popisuje byznys. Logický model popisuje data. Fyzický model popisuje, jak to skutečně postavíme.

Sedni, zůstaň, modeluj

Fyzický krok je nejlépe vidět na něčem malém, takže zvířata jdou první.

Kdo jsou firmy a lidé? Chovatel je firma, takže se z něj stane účet (Account) s typem záznamu Chovatel. Majitel je také účet, nebo osobní účet, s typem záznamu Majitel. Dva druhy téhož standardního objektu, vedle sebe v horní části diagramu, přesně tam, kde jsou od modulu 1.

Co nemá standardní domov? Zvíře, Plemeno, Trik, Trik zvířete a Hodnocení triku se stanou vlastními objekty. A vzpomínáte na druh, který jsme v modulu 5 zkopírovali na zvíře? Tady dostane svou práci: stane se typem záznamu Zvířete, Pes, nebo Kočka. Jeden objekt se dvěma typy záznamu, každý s vlastním rozvržením stránky a hodnotami výběrových seznamů, místo objektu Pes a objektu Kočka.

Které vztahy jsou master-detail? Master-detail používám jen tam, kde podřízený záznam nikdy nedostane jiného rodiče. Trik zvířete patří svému zvířeti na celý život a každé Hodnocení triku patří ke svému Triku zvířete, takže obojí je master-detail. To se vyplatí hned: právě master-detail umožňuje, aby zvíře mělo souhrnné pole (roll-up summary) svých Triků zvířete, takže počet Zvládnuté triky z modulu 5 zůstává v souladu sám. Zvířata ale mění domovy, takže Majitel je lookup.

Které jsou lookupy? Salesforce nedoporučuje víc než 10 000 podřízených záznamů u jednoho nadřazeného. Populární trik jako Sedni, běžné plemeno nebo velký chovatel by to snadno překročili, takže Trik zvířete ukazuje na svůj Trik lookupem a zvíře ukazuje stejně na své Plemeno a Chovatele. A kde můžete, vyhněte se polymorfním vztahům, tedy takovým, kde jedno pole může ukazovat na několik typů objektů. První den jsou pohodlné a později ztěžují život všemu, co je musí číst: sestavám, integracím a teď i agentům.

Co zůstane mimo platformu? Pokud zvíře nosí obojek s GPS, který hlásí, kde je, tu polohu vůbec není potřeba kopírovat dovnitř. Může to být externí objekt, čtený živě ze sledovacího systému obojku.

Kliknutím zvětšíte

Každé rozhodnutí na tom diagramu vede zpět k něčemu, co jsme rozhodli dřív, a o to jde. Teď stejný krok pro Steve Trucking.

Začněte logickým modelem

Náš logický model Steve Trucking teď obsahuje maloobchodního partnera, distribuční centrum, manifest, doručení, položku doručení, příjemce, trasu, zastávku, posádku, kamion a přiřazení posádky. To jsou obchodní pojmy a teď je můžu začít mapovat na Salesforce.

Maloobchodní partner by mohl být účet. Doručení by se mohlo mapovat na něco, co Salesforce už má pro plánovanou práci v terénu, nebo by se mohlo stát vlastním objektem. Pro manifest nic standardního nesedí, takže se nejspíš stane vlastním. A příjemce je opravdu těžká otázka: osobní účet, kontakt, nebo prostě informace na doručení? Na tu pořádně odpovíme v další kapitole.

Důležité slovo je pořád mohl by. Nepředpokládejte implementaci jen proto, že obchodní pojem zní jako objekt Salesforce. Proto jsme nejdřív postavili logický model: dává nám něco, proti čemu můžeme návrh v Salesforce otestovat.

Obchodní entita automaticky neznamená vlastní objekt

Tady je past, které se chci, aby se administrátoři vyhnuli: „Našli jsme jedenáct entit, takže potřebujeme jedenáct vlastních objektů.“ Ne. Logická entita nám říká, že na obchodním pojmu záleží. Nediktuje, jak ho Salesforce musí ukládat. Z pojmu se může stát standardní objekt, vlastní objekt, vztah mezi objekty, pole nebo několik polí, hodnota spravovaná v konfiguraci, nebo data, která žijí úplně mimo Salesforce (fotky doručení ve Steve Trucking jsou pro to dobrý kandidát). Tyto volby se dělají ve fyzickém modelu, a právě proto jsme je nedělali na prvním hovoru.

Z atributů se stávají fyzická pole

Stejný přechod se děje i s atributy. Náš logický kamion má číslo vozidla ve flotile, VIN, značku, model, modelový rok, SPZ a stav. Teď rozhodneme, jak budou fyzicky existovat: který objekt je vlastní, jaké typy polí použijí, která jsou povinná, která musí být jedinečná, která jsou externí identifikátory, která potřebují ověření, která se odvozují, místo aby se ukládala, a která jsou citlivá. Na logické úrovni jsme se ptali, co kamion znamená. Na fyzické úrovni se ptáme, jak bude Salesforce kamion reprezentovat. Různé otázky.

Kliknutím zvětšíte

Ze vztahů se stávají rozhodnutí o platformě

Veškerý čas, který jsme strávili u vztahů, se tady vyplatí. Už víme, jestli je každý z nich jedna k jedné, jedna k mnoha, nebo mnoho k mnoha, povinný, nebo volitelný, a jestli záleží na jeho historii. Teď rozhodneme, jak ho Salesforce implementuje: lookup, master-detail, nebo spojovací objekt Salesforce, a možná spojení s vlastními atributy, protože, jak jsme zjistili, sám vztah může mít obchodní význam.

Vzpomeňte si na přiřazení posádky. Mohli jsme tuto kapitolu začít slovy: „Vytvořme spojovací objekt Salesforce mezi posádkou a kamionem.“ Podívejte se, co bychom přeskočili: proč vztah existuje, jestli potřebuje datum a trasu, jestli má stav a jestli reklamace škody za několik týdnů potřebuje jeho historii. Tyto obchodní otázky nám říkají, co přiřazení posádky je. Teprve pak bychom měli rozhodnout, jak ho Salesforce postaví, a jestli Salesforce už něco, co tu práci dělá, nemá.

Teď nakreslete fyzický model

Diagram se zase změní. Konceptuální model ukazoval obchodní pojmy a jednoduché čáry. Logický model přidal atributy, klíče, kardinalitu a entity skryté ve vztazích. Teď začíná fyzický model vypadat jako Salesforce: standardní objekty, vlastní objekty, pole, typy vztahů a to, co žije mimo platformu.

Kliknutím zvětšíte

Chci, abyste dokázali ty tři diagramy položit vedle sebe a vidět postup: ne tři nesouvisející diagramy, ale stejný byznys na třech úrovních.

Slovo k tomu, jak je kreslím, protože rozvržení je součástí sdělení. Hlavní objekt dávám doprostřed, trochu níž. Pokud má nadřazené objekty, dám je trochu nad něj, takže model čtete shora dolů a zleva doprava, tak jak o něm přemýšlí byznys. Referenční data jdou stranou. I barva něco znamená: Salesforce dělám vždycky modře a pro vlastní systémy firmy volím barvu, obvykle zelenou, protože zelená je pěkná přátelská barva. Červenou nepoužívám a žluté jsou trochu ostré. Když je model takhle rozvržený, zpívá mi. Spousta diagramů, které najdete, je ve skutečnosti správa prostoru: jak zaparkovat všechna auta v přeplněné garáži? Já raději namaluji logický obraz, který mysl dokáže uchopit.

Fyzický model musí respektovat platformu

Salesforce není obecná relační databáze. Má své názory na vztahy, vlastnictví, zabezpečení a sestavy. Má limity, chování dotazů a automatizaci a architekturu, která ovlivňuje, jak se model chová ve velkém měřítku. Logický model, který na tabuli vypadá dokonale, se tedy může muset změnit, když se stane fyzickým. To není Salesforce, který překáží. Znamená to, že platforma má tvar, a dobří architekti tomu tvaru rozumějí. Přesně o tom je další kapitola.

Někdy se také fyzický model bude od čistého logického modelu záměrně lišit kvůli rozhodnutím o denormalizaci, která jsme udělali v modulu 5. To je v pořádku, pokud umíme vysvětlit proč.

Nenavrhujte ze Setupu

Je tu návyk, který chci, abyste se odnaučili, pokud ho máte: začínat datovou architekturu v Setup → Object Manager → New Custom Object a vymýšlet model za pochodu. Salesforce neuvěřitelně usnadňuje vytváření věcí; je to jedna z jeho silných stránek a jeden z důvodů, proč slabé datové modely vznikají tak rychle. Pár kliknutí a máte objekt, pár dalších a máte pole a vztah. Pak přijdou data, postaví se flow, vytvoří se sestavy, závisí na tom integrace a objekt, který jste vytvořili za pět minut, je velmi drahé změnit. To je test vratnosti z kapitoly 1. Než tedy kliknete na New Custom Object, nakreslete model.

Fyzický neznamená trvalý

Je ještě jeden důvod, proč držím tři modely odděleně: technologie se mění. Dnes část dat Steve Trucking žije na core Salesforce. Zítra může jejich část žít v Data 360, v datovém skladu nebo v systému, který jsme ještě nevybrali, a asistent AI potřebuje vlastní reprezentaci. Fyzická architektura se může měnit, zatímco obchodní pojmy zůstávají pozoruhodně stabilní: maloobchodní partneři, doručení a příjemci pořád existují. Právě proto má logický model hodnotu. Je to trvalý popis byznysu, který není svázaný s dnešní implementací.

Co tady rozhoduje architekt

Když převádím logický model na fyzický model Salesforce, rozhoduji:

• Které obchodní entity se mapují na standardní schopnosti Salesforce a které potřebují vlastní objekty nebo jinou reprezentaci.
• Jak se z logických atributů stanou fyzická pole a jak se vztahy na platformě implementují.
• Kam ve fyzickém návrhu patří záměrná denormalizace.
• Která data patří do Salesforce a která jinam.
• Které vlastnosti platformy vyžadují, aby se fyzický model lišil od logického.

A hlavně chci umět každé rozhodnutí vystopovat zpět. Pokud ukážete na něco v mém fyzickém modelu a zeptáte se: „Proč je tohle tady?“, měl bych vás umět provést zpět logickým a konceptuálním modelem k něčemu, co byznys skutečně potřebuje: byznys → konceptuální → logický → fyzický.

Nad rámec zkoušky: co mění AI. AI dnes dokáže vzít dokument s požadavky a jedním skokem dojít až k objektům a polím Salesforce. Tím je pořadí důležitější, ne méně důležité: pokud přeskočí od požadavků ke konfiguraci, požádejte ji, ať ukáže, co se stalo mezi tím: co považovala za entitu, jaké klíče zvolila, jaké vztahy předpokládala a kde denormalizovala. To jsou architektonická rozhodnutí a architekt je pořád potřebuje vidět.

Tuto kapitolu jsme začali na prvním hovoru nasloucháním podstatným jménům a končíme ji fyzickým modelem, který dokážeme vystopovat zpět k byznysu. Teď, když jsme se rozhodli stavět na Salesforce, jde další otázka hlouběji: na jakém druhu datové platformy vlastně stavíme?

K prozkoumání

• Designing Record Access for Enterprise Scale: Parent-Child Data Skew (otevře se v nové kartě), Salesforce Developers, Winter ‘27 (ověřeno 2026-10-17): „configure parent-child relationships with no more than 10,000 children to one parent record“ (nastavte vztahy nadřazený-podřízený s nejvýše 10 000 podřízenými záznamy na jeden nadřazený záznam). Je to doporučení k data skew, ne pevný limit; kapitola 7 jde hlouběji.
• Roll-Up Summary Field (otevře se v nové kartě), Salesforce Help (ověřeno 2026-10-17): souhrnné pole (roll-up summary) počítá nebo sčítá podřízené záznamy přes vztah master-detail.