Modelování dat podle významu
이 콘텐츠는 아직 번역되지 않았습니다.
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 2 kurzu Data Architect. Nejdřív si přečtěte šest 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 je základem pro oddíl zkoušky Data Modeling and Database Design, který tvoří čtvrtinu zkoušky. Pokrývá způsob myšlení; další kapitola, Datová architektura Salesforce, pokrývá, jak to staví platforma. Většina toho, co se testuje o objektech, polích a vztazích, tedy potřebuje obě kapitoly.
Ke zkoušce
Section titled “Ke zkoušce ”Body z této kapitoly, na kterých u zkoušky nejspíš bude záležet. Každý je navázaný na svůj cíl zkoušky a odkazuje na místo, kde se vykládá. Odškrtávejte si je postupně.
DM-1: porovnání technik návrhu datového modelu Salesforce
- Umím vysvětlit rozdíl mezi konceptuálním, logickým a fyzickým datovým modelem a k čemu každý slouží. (Převeďte model do Salesforce)
- Umím v požadavku najít kandidátní entity a rozlišit člověka, který dělá práci, od kusu dat. (Podstatná jména vám dávají kandidátní entity)
- Umím číst a kreslit notaci vraní nohy (crow’s foot): jeden, mnoho a druhou značku pro volitelný nebo povinný vztah. (Čtěte čáry, Záleží i na volitelnosti)
- Umím pojmenovat kardinalitu vztahu: jedna k jedné, jedna k mnoha, mnoho k mnoha. (Ptejte se „jeden, nebo mnoho?“)
- Vím, že ze vztahu mnoho k mnoha se stává samostatná entita a v Salesforce obvykle spojovací objekt se dvěma rodiči. (Ze vztahů se mohou stát věci)
- Vím, kdy vztah potřebuje historii (záznam s datem začátku a konce), a ne pole, které se přepisuje. (Čas mění vztahy)
- Umím zvolit dobré jedinečné ID a vím, proč je přirozený klíč nebo cokoli s osobními údaji riskantní volba. (Pak musíme mluvit o jedinečných ID)
- Znám rozdíl mezi přirozeným klíčem a náhradním klíčem a vím, že jeden záznam může nést několik externích identifikátorů. (Přirozené a náhradní klíče)
- Vím, že pole Auto Number je čitelné číslo, ne ID záznamu v Salesforce. (Vztahy závisejí na jedinečných ID)
- Umím použít první, druhou a třetí normální formu a poznat pole, které obsahuje více hodnot nebo opakuje fakt o něčem jiném. (Jednoduchý způsob, jak myslet o 1NF, 2NF a 3NF)
- Umím vysvětlit, kdy záměrně denormalizovat (uživatelé, sestavy, měřítko) a co to stojí. (Navrhujte do třetí normální formy, pak couvněte)
- Umím se pro seznam hodnot rozhodnout mezi výběrovým seznamem a lookupem na objekt. (Lookup, nebo výběrový seznam?)
- Vím, že vlastní typ sestavy dovoluje nejvýše čtyři vztahy mezi objekty, a proč na tom u hlubokých modelů záleží. (Lookup, nebo výběrový seznam?)
- Vím, kdy se hodí master-detail (podřízený záznam nikdy nedostane jiného rodiče) a kdy je bezpečnější lookup, včetně doporučení Salesforce mít nejvýše 10 000 podřízených záznamů u jednoho nadřazeného. (Ze vztahů se stávají rozhodnutí o platformě)
- Vím, proč se tam, kde to jde, vyhýbat polymorfním vztahům. (Ze vztahů se stávají rozhodnutí o platformě)
- Vím, že obchodní entita automaticky neznamená vlastní objekt: může to být standardní objekt, pole, konfigurace nebo data, která žijí mimo Salesforce. (Obchodní entita automaticky neznamená vlastní objekt)
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.
- Na chvíli zapomeňte na Salesforce. Namodelujte byznys dřív, než ho namapujete na účet a kontakt.
- Poslouchejte slovo, které skrývá dvě věci. Ve Steve Trucking byl „zákazník“ maloobchodní partner i příjemce.
- Model je součástí rozhovoru. Váš první model nemá mít pravdu; má vám ukázat, kde se mýlíte.
- Pojmenujte čáry. Dva modely se stejnými krabicemi mohou znamenat různé věci.
- U každého vztahu se ptejte „teď, nebo v čase?“
- Jedinečný, neměnný, bez významu, nikdy osobní údaje.
- Dejte fakt tam, kam patří, pak záměrně couvněte a zapište si proč.
- Denormalizace složitost neodstraní; přesune ji. Vězte, kdo vlastní pravdu.
- Jeden zdroj pravdy, mnoho tvarů: obrazovky, sestavy, datový sklad a AI.
- Nenavrhujte ze Setupu. Nakreslete model dřív, než kliknete na New Custom Object.
- Každé fyzické rozhodnutí vystopujte zpět k něčemu, co byznys potřebuje.
Pojmy k zapamatování
Section titled “Pojmy k zapamatování ”| Pojem | V jedné větě |
|---|---|
| Entita | Věc, na které byznysu záleží a o které vede data |
| Kandidátní entita | Podstatné jméno, ze kterého se může stát entita, až se na něj zeptáte |
| Atribut | Fakt, který popisuje entitu |
| Vztah | Jak jsou dvě entity propojené, pojmenované jazykem byznysu |
| Kardinalita | Kolik jedněch se váže ke kolika druhým |
| Volitelnost | Zda je vztah povinný, nebo může být nulový |
| Vraní noha (crow’s foot) | Značka pro „mnoho“ na konci čáry |
| Spojovací objekt (junction object) | Způsob, jak Salesforce staví vztah mnoho k mnoha: potomek obou rodičů |
| Konceptuální model | Co v byznysu existuje a jak to spolu souvisí; bez Salesforce |
| Logický model | Data: atributy, jedinečná ID a vztahy, stále nevázané na platformu |
| Fyzický model | Jak to platforma postaví: objekty, pole a typy vztahů |
| Přirozený klíč | Identifikátor, který už v byznysu existuje, třeba VIN kamionu |
| Náhradní klíč (surrogate key) | Identifikátor vytvořený jen k identifikaci záznamu |
| Externí identifikátor | ID stejného záznamu v jiném systému, uchované a namapované |
| Normalizace (1NF, 2NF, 3NF) | Dát každý fakt tam, kam patří: jedna hodnota v poli, fakta o celém klíči, žádná fakta o jiných faktech |
| Denormalizace | Záměrné kopírování nebo zplošťování dat z důvodu, který umíte pojmenovat |
| Anomálie při aktualizaci | Stejný fakt uložený na mnoha místech, takže jedna změna nechá některé kopie špatně |
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. Byznys vám řekne, že posádka jezdí s kamionem. O šest týdnů později se někdo zeptá, která posádka měla v určitý den kamion 117. Co měl model obsahovat?
Přiřazení posádky: vztah mezi posádkou a kamionem jako samostatný záznam s datem začátku, datem konce a trasou. Posádky a kamiony jsou v čase mnoho k mnoha a byznysu na historii záleží. Pole na kamionu by se přepsalo. Přečtěte si znovu Čas mění vztahy.
2. Tým navrhne použít jako jedinečné ID telefonní číslo každého příjemce, „protože je jedinečné“. Co řeknete?
Neprojde testy: telefonní čísla se mění a sdílejí, takže není neměnné ani spolehlivě jedinečné, a jsou to osobní údaje, které by se zkopírovaly do každého systému, který se na záznam odkazuje. Použijte vygenerované ID bez významu a telefonní číslo si nechte jako atribut. Přečtěte si znovu Pak musíme mluvit o jedinečných ID.
3. Doručení má pole Položka 1, Položka 2 a Položka 3. Přijde doručení se čtyřmi položkami. V čem je skutečný problém a jaká je oprava?
Model schoval opakující se strukturu do polí (problém první normální formy). Opravou není pole Položka 4; je to entita položka doručení, potomek doručení, takže každá položka je záznam. Přečtěte si znovu První normální forma.
4. Každé doručení ukládá jméno vedoucího distribučního centra. Vedoucí se změní. Co se pokazilo?
Fakt o něčem jiném (o distribučním centru) byl uložený na doručení: problém třetí normální formy a teď anomálie při aktualizaci napříč stovkami záznamů. Vedoucí patří k distribučnímu centru; doručení ukazuje na distribuční centrum. Přečtěte si znovu Třetí normální forma.
5. Druh zastávky (jen doručení, s instalací, s odvozem) potřebuje dobu trvání, dovednosti posádky a kontrolní seznam. Výběrový seznam, nebo objekt?
Objekt. Má víc než jeden sloupec informací, spravuje ho byznys a mění se podle vlastního harmonogramu. Stav doručení, krátký stabilní seznam popisků, zůstane výběrovým seznamem. Přečtěte si znovu Lookup, nebo výběrový seznam?.
6. Partneři chtějí hodnoticí přehled doručení včas podle regionu a region žije na distribučním centru. Zkopírujete region na každé doručení. Co musíte rozhodnout?
Kdo vlastní pravdu, jak kopie zůstane synchronizovaná a jestli si stará doručení mají ponechat region, který platil, když se uskutečnila, nebo se řídit distribučním centrem, když se přesune. Denormalizace složitost přesunula; neodstranila ji. Přečtěte si znovu Někdy vyhrají sestavy.
7. Trik jako Sedni může být propojený se stovkami tisíc zvířat. Master-detail, nebo lookup z Triku zvířete na Trik?
Lookup. Salesforce doporučuje nejvýše 10 000 podřízených záznamů u jednoho nadřazeného a populární trik by to překročil. Master-detail se hodí mezi Trikem zvířete a Zvířetem, protože trik zvířete nikdy nedostane jiného rodiče a jedno zvíře umí jen pár triků; právě to také umožňuje, aby zvíře mělo souhrnný počet Zvládnuté triky. Přečtěte si znovu Sedni, zůstaň, modeluj.
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.