Słownik, pochodzenie i klasyfikacja

🌐 Dostępne także w 28 językach

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

Obraz wygenerowany przez AI

Przetłumaczone przez AI. Jeszcze niesprawdzone przez społeczność. Czytaj po angielsku

Moduł 3 z 6 w rozdziale Jakość danych i ład danych, rozdziale 5 kursu Data Architect. Każdy moduł jest samodzielny. Wstecz: Nie wpuszczaj złych danych · Dalej: Prawo o prywatności kształtuje projekt

Pytanie, na które odpowiada ten moduł: jak zapisać, co dane znaczą, skąd pochodzą i jak bardzo są wrażliwe?

Dostajesz w spadku org. Konto ma 900 pól, a wśród nich Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c i Account_Status__c. Które z nich mówi ci, czy ktoś naprawdę jest klientem? Otwierasz opisy. Trzy są puste. Jeden mówi „Customer Type”. Dziękuję. Jeden mówi, że pole pochodzi z ERP; inne utworzył sześć lat temu ktoś, kogo dawno nie ma. Teraz wyobraź sobie, że nie jesteś architektem, tylko integracją, zespołem raportowym albo agentem. Organizacja ma mnóstwo danych. To nie znaczy, że wie, co one znaczą.

Tu metadane stają się architekturą, przez trzy pytania, które są powiązane, ale nie takie same:

• Słownik: co znaczą te dane?
• Pochodzenie (lineage): skąd się wzięły?
• Klasyfikacja: jak trzeba je traktować?

Dwa rodzaje metadanych

Metadane występują w dwóch rodzajach i potrzebujesz obu. Metadane biznesowe to to, co dane znaczą dla biznesu: definicja, właściciel, zasady korzystania, stopień wrażliwości. Metadane techniczne to to, jak dane są zbudowane i jak się przemieszczają: obiekt i pole, typ i długość, nazwa API, schemat, mapowanie z jednego systemu do drugiego, pochodzenie od źródła do celu. Nazwa API i typ pola mówią programiście, jak go używać; jego definicja i właściciel mówią wszystkim innym, czy w ogóle go używać. Gdy jedne z drugimi się nie zgadzają albo jednych brakuje, właśnie tam integracje i raporty idą w złą stronę.

Wiedza egzaminacyjna. Odróżniaj metadane biznesowe (znaczenie, definicje, właściciel, zasady, wrażliwość: słownik biznesowy i klasyfikacja) od metadanych technicznych (obiekty, pola, typy, nazwy API, schematy, mapowania i pochodzenie danych).

Zacznij od znaczenia

Rozdział 3 ustalił zasadę: każde pole dostaje opis. Nie „Customer Status” dla pola o nazwie Customer Status, ale coś w rodzaju: „Bieżąca relacja handlowa partnera ze Steve Trucking. Ustawiana z ERP po aktywacji. Nie używać do kwalifikowania potencjalnych klientów”. Teraz wiem, co znaczy, skąd pochodzi i do czego go nie używać. To początek słownika biznesowego: wspólnych definicji danych, które mają znaczenie. Kim jest klient? Aktywny klient? Co znaczy Dostarczona? Co liczy się jako na czas? Brzmi to oczywiście, dopóki nie posadzisz pięciu działów w jednej sali: finanse mają jedną definicję, sprzedaż drugą, operacje trzecią, hurtownia czwartą, a ktoś zbudował pulpit na piątej. Problem nie polega na tym, że nikt nie mówi tym samym językiem. Polega na tym, że przedsiębiorstwo nie uzgodniło znaczenia.

Słownik może mieszkać w arkuszu albo w narzędziu do dokumentacji, ale jego ważne definicje muszą być blisko miejsca, w którym ludzie korzystają z danych. Na platformie to opisy pól, tekst pomocy i metadane klasyfikacji. W analityce ma to jeszcze większe znaczenie: „przychód” nie może znaczyć jednego na pulpicie zarządu, a czego innego w zapytaniu analityka. Do tego służy warstwa semantyczna, a modele semantyczne Data 360 przechowują zarządzane definicje, takie jak miary, wymiary i relacje, ponad danymi fizycznymi (Create a Semantic Model in Data 360 (opens in a new tab), po angielsku). Technologia się zmienia; wymaganie nie: ważne dane potrzebują uzgodnionego znaczenia.

I zacznij od znaczenia, a nie od technologii. Słownik, który zaczyna się od obiektu, pola, typu i nazwy API, dokumentuje implementację. Słownik, który zaczyna się od terminów biznesowych, dokumentuje przedsiębiorstwo:

Termin biznesowy	Znaczenie	Gdzie jest odwzorowany
Partner detaliczny	Sieć handlowa, dla której Steve Trucking dostarcza na podstawie umowy	Konto w Salesforce; klient w finansowym ERP
Dostawa	Jedna dostawa do jednego odbiorcy, pod jeden adres, jednego dnia	Dziś RouteDesk; zlecenie pracy, gdy dostawy przejdą do Salesforce
Odbiorca	Osoba odbierająca dostawę	Dane odbiorcy na dostawie
Dostarczona	Zrealizowana zgodnie z uzgodnioną definicją operacyjną	Status dostawy
Dostawa na czas	Zrealizowana w uzgodnionym oknie dostawy	Miara wyliczana

Click to enlarge

Jedno znaczenie, wiele reprezentacji technicznych.

Potem zapytaj, skąd się wzięły

Gdy wiem, co znaczy wartość, chcę wiedzieć, skąd się wzięła. To jest pochodzenie (lineage). Nazwa prawna partnera w Salesforce: czy wpisał ją handlowiec, czy przysłał ją ERP, czy przekształciła ją integracja, czy ujednoliciło ją Data 360, czy została wyliczona, czy wygenerowała ją AI? To wpływa na to, jak bardzo jej ufam i co mogę z nią zrobić. Pamiętaj rekordy tymczasowe z modułu 2: dwa konta mogą mówić „Keystone”, jedno utworzone wczoraj przez handlowca, drugie z ERP z nadrzędnym identyfikatorem. Ten sam tekst, inne pochodzenie, inne traktowanie.

Pochodzenie to nie tylko diagram tysiąca tabel narysowany przez inżyniera danych. Dla ważnych danych chcę odpowiadać na praktyczne pytania: gdzie się zaczęły, który system jest nadrzędny, co je przekształciło, które systemy dostały kopie, co je ostatnio zmieniło i czy potrafię prześledzić wartość wyliczaną wstecz do jej źródeł? Krajobraz z rozdziału 4 mówi, że systemy są połączone. Pochodzenie mówi, co działo się z danymi po drodze.

Część pochodzenia przychodzi za darmo: identyfikator z ERP na koncie, pola Utworzone przez i Ostatnio zmodyfikowane przez, logi integracji, dokumenty mapowania. Data 360 dodaje do swoich obiektów danych pola pochodzenia, które zapisują źródło danych i obiekt źródłowy każdego rekordu (Data Lineage Fields (opens in a new tab), po angielsku). Ale nie zakładaj, że pochodzenie pojawi się dlatego, że systemy są zintegrowane. Czasem najbardziej przydatne pochodzenie to jedno pole: System źródłowy = Keystone. A jeśli źródło ma znaczenie dla ładu danych, spraw, żeby było mechanicznie wiarygodne, ustawiane przez integrację, a nie wpisywane przez człowieka.

Dane wyliczane potrzebują pochodzenia najbardziej. Powiedzmy, że Steve Trucking wylicza ryzyko spóźnienia dostawy z pozycji ciężarówki, okna dostawy i historii trasy, a dyspozycja używa go do ustalania priorytetów. Skąd wzięło się „wysokie”? Dodaj agenta, który mówi odbiorcy „twoja dostawa się spóźnia”, a musisz wiedzieć, na czym to było ugruntowane i jak świeże było. Im dalej odchodzisz od przechowywanych wartości ku wyliczanym, ujednolicanym, przewidywanym i generowanym, tym bardziej liczy się pochodzenie.

Klasyfikacja odpowiada na inne pytanie

Teraz: jak trzeba je traktować? Imię i nazwisko odbiorcy, adres dostawy, numer telefonu, uwagi do dostawy, status dostawy, numer ciężarówki, centrum dystrybucyjne, partner detaliczny, zdjęcie: nie są jednakowo wrażliwe. „W drodze” to nie numer telefonu, a kod CD to nie zdjęcie wnętrza czyjegoś domu. Salesforce pozwala zapisać to przy każdym polu, standardowym i niestandardowym: Data Owner, Field Usage, Data Sensitivity Level i Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), po angielsku). Rozdział 3 nazwał je polami taksonomii i wyjaśnił, dlaczego mają znaczenie: oznacz pole jako PII albo GDPR, a procesy mogą je znaleźć, od narzędzi do maskowania po warstwę zaufania AI w Salesforce, która może nie dopuścić oznaczonych wartości do dużego modelu językowego. Jedna przestroga z rozdziału 3: Salesforce wyłącza teraz to maskowanie dla LLM w przypadku agentów, bo może ono odebrać kontekst, którego agent potrzebuje (Klasyfikuj to, co ważne: pola taksonomii). Klasyfikacja nadal więc musi sterować pozostałymi mechanizmami kontroli.

Moje stanowisko jest tu świadome: klasyfikuj pola wrażliwe, a nie każde pole. Nie chcę, żeby trzy miesiące zeszły na klasyfikowaniu tysięcy pól tylko po to, żeby ktoś mógł zaraportować „100% sklasyfikowane”, a nikt z tego nie korzystał. Numer telefonu odbiorcy: tak. Adres domowy: tak. Uwagi do dostawy, które mogą zawierać kody do bram i „pies na podwórku”: tak. Zdjęcia, które mogą pokazywać ludzi albo dom: zdecydowanie. Wewnętrzna etykieta wyświetlana? Nie tam powinna iść energia ładu danych. To nie czyni nieudokumentowanych pól dopuszczalnymi. To dwa różne zadania: dokumentacja jest szeroka; klasyfikacja jest świadoma. To utrzymuje klasyfikację w sensie.

Taksonomia, z której ludzie mogą korzystać

Klasyfikacja potrzebuje słownictwa, taksonomii. Domyślne wartości Salesforce to Public, Internal, Confidential, Restricted i MissionCritical; twoja organizacja może chcieć własnych etykiet. Nie narzucam ich. Utrzymuj je zrozumiałymi: jeśli jest 47 kategorii i nikt poza zespołem prywatności nie odróżnia kategorii 31 od 32, to nie pomaga. Dobra taksonomia łączy etykietę z zachowaniem. Jeśli pole to wrażliwe dane osobowe, kto może je widzieć, czy może trafić do sandboxa, opuścić region, pojawić się w analityce, jak długo jest przechowywane, czy może go użyć agent? Teraz klasyfikacja wykonuje pracę.

Klasyfikacja bez egzekwowania to dekoracja

Oznacz numer telefonu odbiorcy jako wrażliwy i nie zmieniaj niczego więcej, a powstanie tylko dokumentacja. Przydatną, ale ład danych idzie dalej: klasyfikacja powinna sterować uprawnieniami, maskowaniem, szyfrowaniem, retencją, zgodami, przepływem danych, użyciem w sandboxach, audytem i dostępem AI. Część tego to decyzja projektowa architekta; niektóre platformy stosują teraz tagi i klasyfikacje bezpośrednio w politykach, jak robi to zarządzanie danymi w Data 360 (Data Governance in Data 360 (opens in a new tab), po angielsku). A oznaczenie pola jako Restricted nikogo nie powstrzymuje przed jego odczytaniem. Klasyfikacja mówi, jak pole powinno być traktowane; bezpieczeństwo sprawia, że tak jest. Kolejność: zidentyfikuj dane, zrozum je, sklasyfikuj to, co ważne, a potem zastosuj mechanizmy kontroli, których wymaga ta klasyfikacja.

Click to enlarge

Trzy pytania o twoje dane, a trzecie musi czymś sterować.

Dane referencyjne też potrzebują metadanych

Kody krajów, statusy dostaw, kody CD, identyfikatory partnerów, przyczyny anulowania: wyglądają prosto, dopóki dwa systemy się nie zgadzają. Jeden mówi CANCELLED, drugi CANCELED, trzeci CNCL, czwarty 9. Dane referencyjne potrzebują definicji, właściciela, źródła, cyklu życia, gdy wartości się zmieniają, i mapowań, gdy systemy odwzorowują je inaczej. Małe wartości mogą sterować bardzo dużymi procesami. Rozdział 6 idzie dalej.

Wszystkie trzy razem

Weźmy numer telefonu odbiorcy. Słownik: numer służący do kontaktu z osobą odbierającą konkretną dostawę. Pochodzenie: z manifestu partnera detalicznego. Klasyfikacja: dane osobowe. Teraz możliwe są pytania architektoniczne: czy ekipa może go widzieć i jak długo (opis mówi: tylko dla własnych przystanków, tylko w dniu dostawy); czy może trafić do sandboxa; czy Snowflake go potrzebuje; czy może go użyć agent; co się dzieje, gdy dostawa jest zakończona?

Teraz weźmy status dostawy. Słownik: bieżący stan operacyjny dostawy. Pochodzenie: ustawiany przez proces dostawy Steve Trucking i odsyłany do każdego partnera przez jego własną integrację. Klasyfikacja: operacyjny, niewrażliwy. Inne dane, inne traktowanie. O to chodzi.

Nie traktuję metadanych jako dokumentacji tworzonej po zakończeniu prawdziwej architektury. Jeśli nie potrafię powiedzieć, co znaczy pole, nie rozumiem modelu danych. Jeśli nie wiem, skąd wzięła się wartość, nie rozumiem integracji. Jeśli nie wiem, czy jest wrażliwa, nie rozumiem bezpieczeństwa. Metadane opisują architekturę, a czasem nią sterują.

Poza egzaminem: co zmienia AI. Klasyfikacja staje się przełącznikiem decydującym o tym, co agent może pobrać albo powtórzyć, a pochodzenie musi sięgać aż do odpowiedzi czy działania agenta. Jeśli agent mówi odbiorcy, że dostawa się spóźnia, architektura powinna umieć powiedzieć, na czym to było ugruntowane, skąd pochodziło i czy agentowi wolno było tego użyć. „Gdzieś w Salesforce” to nie pochodzenie, a „dane klienta” to nie klasyfikacja.

Co tu decyduje architekt

• Które terminy biznesowe potrzebują zarządzanych definicji, żeby systemy i zespoły nie nadawały jednemu słowu różnych znaczeń.
• Jak ważne wartości zachowują dość informacji o pochodzeniu, żeby pokazać swoje źródło, autorytet i przekształcenia.
• Które pola niosą znaczenie związane z wrażliwością albo zgodnością i dlatego dostają wyraźną klasyfikację.
• Jakiej taksonomii używa organizacja i czy ludzie potrafią stosować ją spójnie.
• Jak klasyfikacja steruje prawdziwymi mechanizmami kontroli, zamiast leżeć nieużywana.

Zanim zaczniesz zarządzać danymi, wiedz, co masz: co znaczą, skąd się wzięły, jak trzeba je traktować. Dokumentuj szeroko, klasyfikuj świadomie, zachowuj pochodzenie tam, gdzie ma znaczenie. Inaczej nie zarządzasz danymi. Po prostu je masz.

Do zgłębienia

• Pomoc Salesforce, Data Classification Metadata Fields (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.
• Pomoc Salesforce, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) i Create a Semantic Model in Data 360 (opens in a new tab) (po angielsku), sprawdzono 2026-10-14.