Ordbog, oprindelse og klassifikation
Findes også på 28 sprog
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 · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 3 af 6 i kapitlet Datakvalitet og styring, kapitel 5 i kurset Data Architect. Hvert modul står på egne ben. Forrige: Hold dårlige data ude · Næste: Privatlivslove former designet
Spørgsmålet, dette modul besvarer: Hvordan registrerer du, hvad data betyder, hvor de kom fra, og hvor følsomme de er?
Du har arvet en org. Konto (Account) har 900 felter, blandt dem Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c og Account_Status__c. Hvilket af dem fortæller dig, om nogen faktisk er kunde? Du åbner beskrivelserne. Tre er tomme. Én siger »Customer Type«. Tak for det. Én siger, at feltet kom fra ERP’et; et andet blev oprettet for seks år siden af en, der for længst er væk. Forestil dig nu, at du ikke er arkitekten, men en integration, et rapporteringsteam eller en agent. Organisationen har masser af data. Det betyder ikke, at den ved, hvad dataene betyder.
Det er dér, metadata bliver til arkitektur, gennem tre spørgsmål, der hænger sammen, men ikke er de samme:
- Ordbog: Hvad betyder disse data?
- Oprindelse (lineage): Hvor kom de fra?
- Klassifikation: Hvordan skal de behandles?
To slags metadata
Sektion kaldt “To slags metadata ”Metadata findes i to slags, og du har brug for begge. Forretningsmetadata er det, dataene betyder for forretningen: definitionen, ejeren, reglerne for brugen, hvor følsomme de er. Tekniske metadata er, hvordan dataene er bygget og bevæger sig: objektet og feltet, typen og længden, API-navnet, skemaet, mappingen fra ét system til et andet, oprindelsen fra kilde til mål. Et felts API-navn og type fortæller en udvikler, hvordan feltet skal bruges; dets definition og ejer fortæller alle andre, om det skal. Når de er uenige, eller den ene mangler, er det dér, integrationer og rapporter går galt.
Eksamensviden. Kend forskel på forretningsmetadata (betydning, definitioner, ejer, regler, følsomhed: forretningsordbogen og klassifikationen) og tekniske metadata (objekter, felter, typer, API-navne, skemaer, mappings og dataoprindelse).
Start med betydningen
Sektion kaldt “Start med betydningen ”Kapitel 3 fastsatte reglen: Hvert felt får en beskrivelse. Ikke »Customer Status« for et felt, der hedder Customer Status, men noget i retning af »Partnerens aktuelle kommercielle relation til Steve Trucking. Sættes fra ERP’et efter aktivering. Må ikke bruges til kvalificering af emner.« Nu ved jeg, hvad det betyder, hvor det kommer fra, og hvad det ikke skal bruges til. Det er starten på en forretningsordbog: fælles definitioner for de data, der betyder noget. Hvad er en kunde? En aktiv kunde? Hvad betyder Delivered? Hvad tæller som til tiden? Det lyder indlysende, indtil du sætter fem afdelinger i et lokale: Økonomi har én definition, salg en anden, drift en tredje, datavarehuset en fjerde, og nogen har bygget et dashboard på en femte. Problemet er ikke, at ingen taler samme sprog. Det er, at virksomheden ikke er blevet enig om betydningen.
En ordbog kan ligge i et regneark eller et dokumentationsværktøj, men dens vigtige definitioner skal være tæt på der, hvor folk bruger dataene. På platformen er det feltbeskrivelser, hjælpetekst og klassifikationsmetadata. I analyser betyder det endnu mere: »Omsætning« kan ikke betyde én ting på direktionens dashboard og noget andet i en analytikers forespørgsel. Det er det, et semantisk lag er til, og de semantiske modeller i Data 360 rummer styrede definitioner som målinger, dimensioner og relationer oven over de fysiske data (Create a Semantic Model in Data 360 (opens in a new tab), på engelsk). Teknologien ændrer sig; kravet gør ikke: Vigtige data har brug for en aftalt betydning.
Og start med betydningen, ikke teknologien. En ordbog, der begynder med objekt, felt, type og API-navn, dokumenterer implementeringen. En, der begynder med forretningsbegreber, dokumenterer virksomheden:
| Forretningsbegreb | Betydning | Hvor det er repræsenteret |
|---|---|---|
| Detailpartner (Retail Partner) | En forhandler, som Steve Trucking leverer for, under kontrakt | Konto (Account) i Salesforce; kunde i økonomiafdelingens ERP |
| Levering (Delivery) | Én levering til én modtager, på én adresse, på én dag | RouteDesk i dag; en arbejdsordre, når leveringerne flytter ind i Salesforce |
| Modtager (Recipient) | Personen, der modtager en levering | Modtageroplysninger på leveringen |
| Delivered (leveret) | Gennemført i henhold til den aftalte operationelle definition | Leveringsstatus |
| Levering til tiden | Gennemført inden for det aftalte leveringsvindue | Afledt måling |
Én betydning, mange tekniske repræsentationer.
Spørg så, hvor det kom fra
Sektion kaldt “Spørg så, hvor det kom fra ”Når jeg ved, hvad en værdi betyder, vil jeg vide, hvor den kom fra. Det er dataoprindelse (lineage). En partners juridiske navn i Salesforce: Skrev en sælger det, sendte ERP’et det, transformerede en integration det, samlede Data 360 det, blev det beregnet, genererede AI det? Det påvirker, hvor meget jeg stoler på det, og hvad jeg må gøre med det. Husk de foreløbige poster fra modul 2: To konti kan begge sige »Keystone«, den ene oprettet af en sælger i går, den anden fra ERP’et med et autoritativt id. Samme tekst, forskellig oprindelse, forskellig behandling.
Dataoprindelse er ikke kun en dataingeniørs diagram over tusind tabeller. For vigtige data vil jeg kunne svare på praktiske spørgsmål: Hvor startede de, hvilket system er autoritativt, hvad transformerede dem, hvilke systemer fik kopier, hvad ændrede dem sidst, og kan jeg spore en afledt værdi tilbage til dens kilder? Landskabet fra kapitel 4 siger, at systemerne er forbundet. Dataoprindelsen siger, hvad der skete med dataene på vejen.
Noget dataoprindelse får du gratis: ERP-id’et på kontoen, Created By og Last Modified By, integrationslogs, mappingdokumenter. Data 360 tilføjer oprindelsesfelter til sine dataobjekter, som registrerer datakilden og kildeobjektet for hver post (Data Lineage Fields (opens in a new tab), på engelsk). Men gå ikke ud fra, at dataoprindelse dukker op, fordi systemerne er integreret. Nogle gange er den mest nyttige dataoprindelse ét felt: Source System = Keystone. Og hvis kilden betyder noget for styringen, så gør den mekanisk pålidelig, sat af integrationen, ikke indtastet af et menneske.
Afledte data har allermest brug for dataoprindelse. Lad os sige, at Steve Trucking beregner en risiko for forsinket levering ud fra lastbilens position, leveringsvinduet og rutehistorikken, og at dispatch bruger den til at prioritere. Hvor kom »høj« fra? Tilføj en agent, der fortæller en modtager, at »din levering er forsinket«, og du skal vide, hvad der var grundlaget for det, og hvor friske dataene var. Jo længere du bevæger dig fra lagrede værdier til beregnede, samlede, forudsagte og genererede værdier, jo mere betyder dataoprindelsen.
Klassifikation besvarer et andet spørgsmål
Sektion kaldt “Klassifikation besvarer et andet spørgsmål ”Nu: Hvordan skal dataene behandles? Modtagerens navn, leveringsadresse, telefonnummer, leveringsnoter, leveringsstatus, lastbilnummer, distributionscenter, detailpartner, foto: De er ikke lige følsomme. »Ude til levering« er ikke et telefonnummer, og en DC-kode er ikke et foto af indersiden af nogens hjem. Salesforce lader dig registrere det på hvert felt, standard eller brugerdefineret: Data Owner, Field Usage, Data Sensitivity Level og Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), på engelsk). Kapitel 3 kaldte dem taksonomifelterne og forklarede, hvorfor de betyder noget: Markér et felt som PII eller GDPR, og processer kan finde det, fra maskeringsværktøjer til Salesforces AI-tillidslag (trust layer), som kan forhindre markerede værdier i at nå en stor sprogmodel. En advarsel fra kapitel 3: Salesforce slår nu den LLM-maskering fra for agenter, fordi den kan fjerne den kontekst, en agent har brug for (Klassificér det, der betyder noget: taksonomifelterne). Så klassifikationen skal stadig styre de andre kontroller.
Min holdning her er bevidst: Klassificér de følsomme felter, ikke alle felter. Jeg vil ikke have, at der bruges tre måneder på at klassificere tusindvis af felter, så nogen kan rapportere »100 % klassificeret«, og ingen bruger det. Modtagerens telefonnummer: ja. Hjemmeadresse: ja. Leveringsnoter, der kan indeholde lågekoder og »hund i haven«: ja. Fotos, der kan vise mennesker eller et hjem: absolut. En intern visningsetiket? Det er ikke der, styringsenergien skal bruges. Det gør ikke udokumenterede felter acceptable. To forskellige opgaver: Dokumentation er bred; klassifikation er bevidst. Det er det, der holder klassifikationen meningsfuld.
En taksonomi, folk kan bruge
Sektion kaldt “En taksonomi, folk kan bruge ”Klassifikation har brug for et ordforråd, en taksonomi. Salesforces standardværdier er Public, Internal, Confidential, Restricted og MissionCritical; din organisation vil måske have sine egne betegnelser. Jeg foreskriver dem ikke. Hold dem forståelige: Hvis der er 47 kategorier, og ingen uden for privacy-teamet kan skelne kategori 31 fra 32, hjælper det ikke. En god taksonomi forbinder en betegnelse med en adfærd. Hvis et felt er følsomme personoplysninger, hvem kan så se det, må det komme i en sandbox, forlade regionen, optræde i analyser, hvor længe opbevares det, og må en agent bruge det? Nu gør klassifikationen noget.
Klassifikation uden håndhævelse er pynt
Sektion kaldt “Klassifikation uden håndhævelse er pynt ”Markér modtagerens telefonnummer som følsomt og lad alt andet være, og du har skrevet dokumentation. Nyttigt, men styring går videre: Klassifikationen skal styre tilladelser, maskering, kryptering, opbevaring, samtykke, dataflytning, brug af sandboxes, revision og AI-adgang. Noget af det er arkitektens designbeslutning; nogle platforme anvender nu tags og klassifikationer direkte i politikker, sådan som styringen i Data 360 gør (Data Governance in Data 360 (opens in a new tab), på engelsk). Og at markere et felt som Restricted forhindrer ingen i at læse det. Klassifikationen siger, hvordan et felt skal behandles; sikkerheden gør det sådan. Rækkefølgen er: Identificér dataene, forstå dem, klassificér det, der betyder noget, og anvend så de kontroller, klassifikationen kræver.
Tre spørgsmål om dine data, og det tredje skal styre noget.
Referencedata har også brug for metadata
Sektion kaldt “Referencedata har også brug for metadata ”Landekoder, leveringsstatusser, DC-koder, partner-id’er, annulleringsårsager: De ser enkle ud, indtil to systemer er uenige. Ét siger CANCELLED, et andet CANCELED, et tredje CNCL, et fjerde 9. Referencedata har brug for definitioner, en ejer, en kilde, en livscyklus, hvor værdierne ændrer sig, og mappings, når systemerne repræsenterer dem forskelligt. Små værdier kan styre meget store processer. Kapitel 6 går videre.
Alle tre sammen
Sektion kaldt “Alle tre sammen ”Tag modtagerens telefonnummer. Ordbog: nummeret, der bruges til at nå den person, der modtager en bestemt levering. Oprindelse: fra detailpartnerens manifest. Klassifikation: personoplysninger. Nu kan arkitekturspørgsmålene stilles: Må teamet se det, og hvor længe (briefen siger kun for deres egne stop og kun på dagen); må det komme i en sandbox; har Snowflake brug for det; må en agent bruge det; hvad sker der, når leveringen er gennemført?
Tag så leveringsstatus. Ordbog: leveringens aktuelle operationelle tilstand. Oprindelse: sat af Steve Truckings leveringsproces og sendt tilbage til hver partner via partnerens egen integration. Klassifikation: operationel, ikke følsom. Forskellige data, forskellig behandling. Det er pointen.
Jeg behandler ikke metadata som dokumentation, der laves, efter den rigtige arkitektur er færdig. Hvis jeg ikke kan sige, hvad et felt betyder, forstår jeg ikke datamodellen. Hvis jeg ikke ved, hvor en værdi kom fra, forstår jeg ikke integrationerne. Hvis jeg ikke ved, om den er følsom, forstår jeg ikke sikkerheden. Metadata beskriver arkitekturen, og nogle gange styrer de den.
Ud over eksamen: hvad AI ændrer. Klassifikation er ved at blive kontakten for, hvad en agent må hente eller gentage, og dataoprindelsen skal række hele vejen ud til agentens svar eller handling. Hvis en agent fortæller en modtager, at leveringen er forsinket, skal arkitekturen kunne sige, hvad der var grundlaget for det, hvor det kom fra, og om agenten havde lov til at bruge det. »Et sted i Salesforce« er ikke dataoprindelse, og »kundedata« er ikke en klassifikation.
Hvad en arkitekt beslutter her
Sektion kaldt “Hvad en arkitekt beslutter her ”- Hvilke forretningsbegreber der har brug for styrede definitioner, så systemer og teams ikke giver ét ord forskellige betydninger.
- Hvordan vigtige værdier bevarer nok dataoprindelse til at vise deres kilde, autoritet og transformationer.
- Hvilke felter der bærer en følsomheds- eller compliance-betydning og derfor får eksplicit klassifikation.
- Hvilken taksonomi organisationen bruger, og om folk kan anvende den konsekvent.
- Hvordan klassifikationen styrer rigtige kontroller i stedet for at ligge ubrugt hen.
Før du styrer data, så kend det, du har: hvad det betyder, hvor det kom fra, hvordan det skal behandles. Dokumentér bredt, klassificér bevidst, bevar dataoprindelsen, hvor den betyder noget. Ellers styrer du ikke dataene. Du har dem bare.
Læs mere
Sektion kaldt “Læs mere ”- Salesforce Help, Data Classification Metadata Fields (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).
- Salesforce Help, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) og Create a Semantic Model in Data 360 (opens in a new tab) (på engelsk, kontrolleret 2026-10-14).