Slovník, původ a klasifikace
Esta página aún no está disponible en tu idioma.
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 3 z 6 kapitoly Kvalita dat a správa dat, kapitoly 5 kurzu Data Architect. Každý modul stojí sám o sobě. Předchozí: Nepouštějte dovnitř špatná data · Další: Zákony o ochraně soukromí formují návrh
Otázka, na kterou tento modul odpovídá: Jak zachytit, co data znamenají, odkud přišla a jak jsou citlivá?
Zdědili jste org. Account má 900 polí, mezi nimi Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c a Account_Status__c. Které z nich vám řekne, jestli je někdo skutečně zákazník? Otevřete popisy. Tři jsou prázdné. Jeden říká „Customer Type“. Děkuji. Jeden říká, že přišel z ERP; další vytvořil před šesti lety někdo, kdo je dávno pryč. Teď si představte, že nejste architekt, ale integrace, tým sestav nebo agent. Organizace má spoustu dat. To neznamená, že ví, co data znamenají.
Tady se metadata stávají architekturou, přes tři otázky, které spolu souvisejí, ale nejsou stejné:
- Slovník: co tato data znamenají?
- Původ (lineage): odkud přišla?
- Klasifikace: jak se s nimi musí zacházet?
Dva druhy metadat
Section titled “Dva druhy metadat ”Metadata mají dva druhy a potřebujete oba. Obchodní metadata jsou to, co data znamenají pro byznys: definice, vlastník, pravidla jejich používání, jak jsou citlivá. Technická metadata jsou to, jak jsou postavená a jak se pohybují: objekt a pole, typ a délka, název API, schéma, mapování z jednoho systému do druhého, původ od zdroje k cíli. Název API a typ pole říkají vývojáři, jak ho použít; jeho definice a vlastník říkají všem ostatním, jestli ho použít. Když se neshodnou, nebo jedno chybí, právě tam se kazí integrace a sestavy.
Ke zkoušce. Rozlišujte obchodní metadata (význam, definice, vlastník, pravidla, citlivost: obchodní slovník a klasifikace) od technických metadat (objekty, pole, typy, názvy API, schémata, mapování a původ dat).
Začněte významem
Section titled “Začněte významem ”Kapitola 3 stanovila pravidlo: každé pole dostane popis. Ne „Customer Status“ u pole jménem Customer Status, ale něco jako „Aktuální obchodní vztah partnera se Steve Trucking. Nastavuje se z ERP po aktivaci. Nepoužívejte pro kvalifikaci potenciálních zákazníků.“ Teď vím, co znamená, odkud pochází a k čemu ho nepoužívat. To je začátek obchodního slovníku: společných definic pro data, na kterých záleží. Co je zákazník? Aktivní zákazník? Co znamená Delivered? Co se počítá jako včas? Zní to samozřejmě, dokud nedáte do jedné místnosti pět oddělení: Finance mají jednu definici, obchod druhou, provoz třetí, datový sklad čtvrtou a někdo postavil řídicí panel na páté. Problém není v tom, že by nikdo nemluvil stejnou řečí. Je v tom, že se podnik na významu nedohodl.
Slovník může žít v tabulce nebo v dokumentačním nástroji, ale jeho důležité definice musí sedět blízko místa, kde lidé data používají. Na platformě jsou to popisy polí, nápověda a klasifikační metadata. V analytice na tom záleží ještě víc: „tržby“ nemohou na řídicím panelu vedení znamenat jedno a v dotazu analytika něco jiného. K tomu je sémantická vrstva a sémantické modely Data 360 drží řízené definice, jako jsou metriky, dimenze a vztahy, nad fyzickými daty (Create a Semantic Model in Data 360 (otevře se v nové kartě)). Technologie se mění; požadavek ne: důležitá data potřebují dohodnutý význam.
A začněte významem, ne technologií. Slovník, který začíná objektem, polem, typem a názvem API, dokumentuje implementaci. Slovník, který začíná obchodními pojmy, dokumentuje podnik:
| Obchodní pojem | Význam | Kde je reprezentován |
|---|---|---|
| Maloobchodní partner | Obchodník, pro kterého Steve Trucking doručuje na základě smlouvy | Account v Salesforce; zákazník ve finančním ERP |
| Doručení | Jedno doručení jednomu příjemci, na jednu adresu, v jeden den | Dnes RouteDesk; pracovní příkaz, jakmile se doručení přesunou do Salesforce |
| Příjemce | Osoba, která doručení přebírá | Údaje o příjemci na doručení |
| Delivered | Dokončeno podle dohodnuté provozní definice | Stav doručení |
| Doručení včas | Dokončeno v dohodnutém okně doručení | Odvozená metrika |
Jeden význam, mnoho technických reprezentací.
Pak se zeptejte, odkud data přišla
Section titled “Pak se zeptejte, odkud data přišla ”Jakmile vím, co hodnota znamená, chci vědět, odkud přišla. To je původ (lineage). Oficiální název partnera v Salesforce: napsal ho obchodník, poslalo ho ERP, transformovala ho integrace, sjednotilo ho Data 360, byl vypočítaný, vygenerovala ho AI? To ovlivňuje, jak moc mu věřím a co s ním smím dělat. Vzpomeňte si na prozatímní záznamy z modulu 2: dva účty mohou oba říkat „Keystone“, jeden včera vytvořený obchodníkem, druhý z ERP s autoritativním identifikátorem. Stejný text, jiný původ, jiné zacházení.
Původ není jen diagram tisíce tabulek od datového inženýra. U důležitých dat chci umět odpovědět na praktické otázky: kde začala, který systém je autoritativní, co je transformovalo, které systémy dostaly kopie, co je naposledy změnilo a dokážu odvozenou hodnotu vystopovat zpět k jejím zdrojům? Krajina z kapitoly 4 říká, že systémy jsou propojené. Původ říká, co se s daty cestou stalo.
Část původu dostanete zadarmo: ID z ERP na účtu, Created By a Last Modified By, logy integrací, dokumenty s mapováním. Data 360 přidává do svých datových objektů pole původu, která u každého záznamu zaznamenávají zdroj dat a zdrojový objekt (Data Lineage Fields (otevře se v nové kartě)). Nepředpokládejte ale, že se původ objeví jen proto, že jsou systémy integrované. Někdy je nejužitečnějším původem jedno pole: Source System = Keystone. A pokud na zdroji záleží kvůli správě dat, udělejte ho mechanicky spolehlivým, nastavovaným integrací, ne psaným člověkem.
Původ ze všeho nejvíc potřebují odvozená data. Řekněme, že Steve Trucking počítá riziko pozdního doručení z polohy kamionu, okna doručení a historie trasy a dispečink ho používá ke stanovení priorit. Odkud se vzalo „vysoké“? Přidejte agenta, který příjemci řekne „vaše doručení má zpoždění“, a potřebujete vědět, v čem byl ukotvený a jak čerstvé to bylo. Čím dál se posouváte od uložených hodnot k vypočteným, sjednoceným, předpovězeným a vygenerovaným, tím víc na původu záleží.
Klasifikace odpovídá na jinou otázku
Section titled “Klasifikace odpovídá na jinou otázku ”Teď: jak se s nimi má zacházet? Jméno příjemce, adresa doručení, telefonní číslo, poznámky k doručení, stav doručení, číslo kamionu, distribuční centrum, maloobchodní partner, fotka: nejsou stejně citlivé. „Na cestě“ není telefonní číslo a kód DC není fotka interiéru něčího domova. Salesforce vám umožňuje to zaznamenat u každého pole, standardního i vlastního: Data Owner, Field Usage, Data Sensitivity Level a Compliance Categorization (Data Classification Metadata Fields (otevře se v nové kartě)). Kapitola 3 jim říkala taxonomická pole a vysvětlila, proč na nich záleží: označte pole jako PII nebo GDPR a procesy ho dokážou najít, od nástrojů pro maskování po vrstvu důvěry AI v Salesforce, která dokáže zabránit, aby se označené hodnoty dostaly k velkému jazykovému modelu. Jedno upozornění z kapitoly 3: Salesforce teď toto maskování pro LLM u agentů vypíná, protože může odstranit kontext, který agent potřebuje (Klasifikujte, na čem záleží: taxonomická pole). Klasifikace tedy pořád musí řídit ostatní kontroly.
Můj postoj je tu záměrný: klasifikujte citlivá pole, ne každé pole. Nechci tři měsíce klasifikovat tisíce polí, aby mohl někdo nahlásit „100 % klasifikováno“ a nikdo to nepoužil. Telefonní číslo příjemce: ano. Adresa bydliště: ano. Poznámky k doručení, které mohou obsahovat kódy brány a „pes na zahradě“: ano. Fotky, které mohou ukazovat lidi nebo domov: rozhodně. Interní zobrazovaný popisek? Tam energie správy dat nepatří. To neznamená, že nezdokumentovaná pole jsou přijatelná. Dvě různé práce: dokumentace je široká; klasifikace je záměrná. Díky tomu klasifikace zůstává smysluplná.
Taxonomie, kterou lidé dokážou používat
Section titled “Taxonomie, kterou lidé dokážou používat ”Klasifikace potřebuje slovník, taxonomii. Výchozí hodnoty Salesforce jsou Public, Internal, Confidential, Restricted a MissionCritical; vaše organizace může chtít vlastní popisky. Nepředepisuji je. Udržujte je srozumitelné: pokud je kategorií 47 a nikdo mimo tým ochrany soukromí nerozezná kategorii 31 od 32, nepomáhá to. Dobrá taxonomie spojuje popisek s chováním. Pokud je pole citlivým osobním údajem, kdo ho smí vidět, smí jít do sandboxu, opustit region, objevit se v analytice, jak dlouho se uchovává, smí ho použít agent? Teď klasifikace dělá práci.
Klasifikace bez vynucení je dekorace
Section titled “Klasifikace bez vynucení je dekorace ”Označte telefonní číslo příjemce jako citlivé a nic jiného nezměňte, a napsali jste dokumentaci. Užitečnou, ale správa dat jde dál: klasifikace by měla řídit oprávnění, maskování, šifrování, uchovávání, souhlas, přesun dat, používání sandboxů, audit i přístup AI. Něco z toho je návrhové rozhodnutí architekta; některé platformy dnes používají štítky a klasifikace přímo v pravidlech, jako to dělá správa dat v Data 360 (Data Governance in Data 360 (otevře se v nové kartě)). A označení pole jako Restricted nikomu nezabrání ho číst. Klasifikace říká, jak se má s polem zacházet; zabezpečení to zajistí. Pořadí zní: identifikovat data, porozumět jim, klasifikovat, na čem záleží, a pak použít kontroly, které klasifikace vyžaduje.
Tři otázky o vašich datech, a ta třetí musí něco řídit.
I referenční data potřebují metadata
Section titled “I referenční data potřebují metadata ”Kódy zemí, stavy doručení, kódy DC, identifikátory partnerů, důvody zrušení: vypadají jednoduše, dokud se dva systémy neshodnou. Jeden říká CANCELLED, druhý CANCELED, třetí CNCL, čtvrtý 9. Referenční data potřebují definice, vlastníka, zdroj, životní cyklus pro případy, kdy se hodnoty mění, a mapování, když je systémy reprezentují různě. Malé hodnoty mohou řídit velmi velké procesy. Kapitola 6 jde dál.
Všechny tři dohromady
Section titled “Všechny tři dohromady ”Vezměte telefonní číslo příjemce. Slovník: číslo, na kterém se lze spojit s osobou, která přebírá konkrétní doručení. Původ: z manifestu maloobchodního partnera. Klasifikace: osobní údaj. Teď jsou architektonické otázky možné: smí ho posádka vidět a jak dlouho (zadání říká jen u svých vlastních zastávek, jen v daný den); smí jít do sandboxu; potřebuje ho Snowflake; smí ho použít agent; co se stane, když je doručení hotové?
Teď vezměte stav doručení. Slovník: aktuální provozní stav doručení. Původ: nastavuje ho proces doručování Steve Trucking a posílá se zpět každému partnerovi přes jeho vlastní integraci. Klasifikace: provozní, ne citlivý. Jiná data, jiné zacházení. O to jde.
Metadata neberu jako dokumentaci, která vzniká až po dokončení skutečné architektury. Pokud neumím říct, co pole znamená, nerozumím datovému modelu. Pokud nevím, odkud hodnota přišla, nerozumím integracím. Pokud nevím, jestli je citlivá, nerozumím zabezpečení. Metadata architekturu popisují, a někdy ji i řídí.
Nad rámec zkoušky: co mění AI. Klasifikace se stává vypínačem toho, co smí agent načíst nebo zopakovat, a původ musí sahat až k odpovědi nebo akci agenta. Pokud agent řekne příjemci, že doručení má zpoždění, architektura by měla umět říct, v čem to bylo ukotvené, odkud to přišlo a jestli to agent smel použít. „Někde v Salesforce“ není původ a „zákaznická data“ nejsou klasifikace.
Co tady rozhoduje architekt
Section titled “Co tady rozhoduje architekt ”- Které obchodní pojmy potřebují řízené definice, aby systémy a týmy nedávaly jednomu slovu různé významy.
- Jak si důležité hodnoty uchovají dost původu, aby ukázaly svůj zdroj, autoritu a transformace.
- Která pole nesou význam citlivosti nebo souladu, a proto dostanou výslovnou klasifikaci.
- Jakou taxonomii organizace používá a jestli ji lidé dokážou používat konzistentně.
- Jak klasifikace řídí skutečné kontroly, místo aby ležela nevyužitá.
Než začnete data spravovat, vězte, co máte: co znamenají, odkud přišla, jak se s nimi musí zacházet. Dokumentujte široce, klasifikujte záměrně, uchovávejte původ tam, kde na něm záleží. Jinak data nespravujete. Jen je máte.
K prozkoumání
Section titled “K prozkoumání ”- Salesforce Help, Data Classification Metadata Fields (otevře se v nové kartě), ověřeno 2026-10-17.
- Salesforce Help, Data 360: Data Lineage Fields (otevře se v nové kartě), Data Governance in Data 360 (otevře se v nové kartě) a Create a Semantic Model in Data 360 (otevře se v nové kartě), ověřeno 2026-10-17.