Ordbok, opphav og klassifisering
Finnes også på 28 språk
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 · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
Modul 3 av 6 i kapitlet Datakvalitet og styring, kapittel 5 i kurset Data Architect. Hver modul står på egne ben. Forrige: Hold dårlige data ute · Neste: Personvernlover former designet
Spørsmålet denne modulen besvarer: Hvordan fanger du opp hva data betyr, hvor de kom fra, og hvor sensitive de er?
Du har arvet en org. Konto (Account) har 900 felt, blant dem Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c og Account_Status__c. Hvilket av dem forteller deg om noen faktisk er kunde? Du åpner beskrivelsene. Tre er tomme. Én sier «Customer Type». Takk skal du ha. Én sier at feltet kom fra ERP-et; et annet ble opprettet for seks år siden av noen som for lengst har sluttet. Tenk deg nå at du ikke er arkitekten, men en integrasjon, et rapporteringsteam eller en agent. Organisasjonen har masse data. Det betyr ikke at den vet hva dataene betyr.
Det er der metadata blir arkitektur, gjennom tre spørsmål som henger sammen, men ikke er de samme:
- Ordbok: hva betyr disse dataene?
- Opphav (lineage): hvor kom de fra?
- Klassifisering: hvordan må de behandles?
To typer metadata
Section titled “To typer metadata ”Metadata finnes i to typer, og du trenger begge. Forretningsmetadata er hva dataene betyr for virksomheten: definisjonen, eieren, reglene for bruk, hvor sensitive de er. Teknisk metadata er hvordan dataene er bygd og hvordan de beveger seg: objektet og feltet, typen og lengden, API-navnet, skjemaet, tilordningen fra ett system til et annet, opphavet fra kilde til mål. API-navnet og typen til et felt forteller en utvikler hvordan feltet skal brukes; definisjonen og eieren forteller alle andre om det skal brukes. Når de er uenige, eller én av dem mangler, er det der integrasjoner og rapporter går galt.
Eksamenskunnskap. Skill mellom forretningsmetadata (betydning, definisjoner, eier, regler, sensitivitet: forretningsordboken og klassifiseringen) og teknisk metadata (objekter, felt, typer, API-navn, skjemaer, tilordninger og opphav).
Start med betydningen
Section titled “Start med betydningen ”Kapittel 3 satte regelen: hvert felt får en beskrivelse. Ikke «Customer Status» for et felt som heter Customer Status, men noe som «Partnerens nåværende kommersielle forhold til Steve Trucking. Settes fra ERP-et etter aktivering. Ikke bruk til kvalifisering av prospekter.» Nå vet jeg hva feltet betyr, hvor det kommer fra og hva det ikke skal brukes til. Det er starten på en forretningsordbok: felles definisjoner for dataene som betyr noe. Hva er en kunde? En aktiv kunde? Hva betyr Levert? Hva regnes som i tide? Dette høres opplagt ut helt til du setter fem avdelinger i et rom: økonomi har én definisjon, salg en annen, drift en tredje, datavarehuset en fjerde, og noen har bygd et dashbord på en femte. Problemet er ikke at ingen snakker samme språk. Det er at virksomheten ikke er blitt enige om betydningen.
En ordbok kan bo i et regneark eller et dokumentasjonsverktøy, men de viktige definisjonene må ligge nær der folk bruker dataene. På plattformen er det feltbeskrivelser, hjelpetekst og klassifiseringsmetadataene. I analyse betyr det enda mer: «omsetning» kan ikke bety én ting på ledelsens dashbord og noe annet i en analytikers spørring. Det er det et semantisk lag er til for, og de semantiske modellene i Data 360 holder styrte definisjoner som måltall, dimensjoner og relasjoner over de fysiske dataene (Create a Semantic Model in Data 360 (opens in a new tab)). Teknologien endrer seg; kravet gjør det ikke: viktige data trenger en omforent betydning.
Og start med betydningen, ikke teknologien. En ordbok som begynner med objekt, felt, type og API-navn, dokumenterer implementeringen. En som begynner med forretningsbegreper, dokumenterer virksomheten:
| Forretningsbegrep | Betydning | Hvor det er representert |
|---|---|---|
| Detaljhandelspartner (Retail Partner) | En forhandler Steve Trucking leverer for, under kontrakt | Konto (Account) i Salesforce; kunde i økonomisystemet (ERP) |
| Levering (Delivery) | Én levering til én mottaker, på én adresse, på én dag | RouteDesk i dag; en arbeidsordre når leveringene flyttes inn i Salesforce |
| Mottaker (Recipient) | Personen som mottar en levering | Mottakeropplysninger på leveringen |
| Levert (Delivered) | Fullført i henhold til den avtalte operative definisjonen | Leveringsstatus |
| Levering i tide | Fullført innenfor det avtalte leveringsvinduet | Avledet måltall |
Én betydning, mange tekniske representasjoner.
Spør så hvor det kom fra
Section titled “Spør så hvor det kom fra ”Når jeg vet hva en verdi betyr, vil jeg vite hvor den kom fra. Det er opphav (lineage). En partners juridiske navn i Salesforce: skrev en selger det inn, sendte ERP-et det, transformerte en integrasjon det, samlet Data 360 det, ble det beregnet, genererte KI det? Det påvirker hvor mye jeg stoler på det og hva jeg kan gjøre med det. Husk de foreløpige postene fra modul 2: to kontoer kan begge si «Keystone», den ene opprettet av en selger i går, den andre fra ERP-et med en autoritativ identifikator. Samme tekst, forskjellig opphav, forskjellig behandling.
Opphav er ikke bare en dataingeniørs diagram over tusen tabeller. For viktige data vil jeg svare på praktiske spørsmål: hvor startet de, hvilket system er autoritativt, hva transformerte dem, hvilke systemer fikk kopier, hva endret dem sist, og kan jeg spore en avledet verdi tilbake til kildene? Landskapet i kapittel 4 sier at systemene er koblet sammen. Opphavet sier hva som skjedde med dataene på veien.
Noe opphav får du gratis: ERP-ID-en på kontoen, Created By og Last Modified By, integrasjonslogger, tilordningsdokumenter. Data 360 legger til opphavsfelt på dataobjektene sine som registrerer datakilden og kildeobjektet for hver post (Data Lineage Fields (opens in a new tab)). Men ikke anta at opphavet dukker opp fordi systemene er integrert. Noen ganger er det mest nyttige opphavet ett felt: Source System = Keystone. Og hvis kilden betyr noe for styringen, gjør den mekanisk pålitelig, satt av integrasjonen, ikke skrevet inn av et menneske.
Avledede data trenger opphav mer enn noe annet. La oss si at Steve Trucking beregner en risiko for forsinket levering ut fra lastebilens posisjon, leveringsvinduet og rutehistorikken, og at utkjøringen bruker den til å prioritere. Hvor kom «høy» fra? Legg til en agent som forteller en mottaker at «leveringen din er forsinket», og du må vite hva som var grunnlaget for det, og hvor ferskt det var. Jo lenger du beveger deg fra lagrede verdier til beregnede, samlede, forutsagte og genererte verdier, desto mer betyr opphavet.
Klassifisering svarer på et annet spørsmål
Section titled “Klassifisering svarer på et annet spørsmål ”Nå: hvordan skal dataene behandles? Mottakerens navn, leveringsadresse, telefonnummer, leveringsnotater, leveringsstatus, lastebilnummer, distribusjonssenter, detaljhandelspartner, bilde: de er ikke like sensitive. «Ute for levering» er ikke et telefonnummer, og en DC-kode er ikke et bilde av innsiden av noens hjem. Salesforce lar deg registrere dette på hvert felt, standard eller egendefinert: Data Owner, Field Usage, Data Sensitivity Level og Compliance Categorization (Data Classification Metadata Fields (opens in a new tab)). Kapittel 3 kalte dem taksonomifeltene, og forklarte hvorfor de betyr noe: merk et felt PII eller GDPR, og prosesser kan finne det, fra maskeringsverktøy til KI-tillitslaget i Salesforce, som kan hindre at merkede verdier når en stor språkmodell. En advarsel fra kapittel 3: Salesforce slår nå av den LLM-maskeringen for agenter, fordi den kan fjerne konteksten en agent trenger (Klassifiser det som betyr noe: taksonomifeltene). Så klassifiseringen må fortsatt styre de andre kontrollene.
Standpunktet mitt her er bevisst: klassifiser de sensitive feltene, ikke hvert felt. Jeg vil ikke at noen skal bruke tre måneder på å klassifisere tusenvis av felt, slik at noen kan rapportere «100 % klassifisert» og ingen bruker det. Mottakerens telefonnummer: ja. Hjemmeadresse: ja. Leveringsnotater som kan inneholde portkoder og «hund i hagen»: ja. Bilder som kan vise mennesker eller et hjem: absolutt. En intern visningsetikett? Ikke der styringsenergien bør gå. Det gjør ikke udokumenterte felt akseptable. To forskjellige jobber: dokumentasjon er bred; klassifisering er bevisst. Det er det som holder klassifiseringen meningsfull.
En taksonomi folk kan bruke
Section titled “En taksonomi folk kan bruke ”Klassifisering trenger et vokabular, en taksonomi. Standardverdiene i Salesforce er Public, Internal, Confidential, Restricted og MissionCritical; organisasjonen din vil kanskje ha sine egne etiketter. Jeg foreskriver dem ikke. Hold dem forståelige: hvis det finnes 47 kategorier og ingen utenfor personvernteamet kan skille kategori 31 fra 32, hjelper det ikke. En god taksonomi kobler en etikett til atferd. Hvis et felt er sensitive personopplysninger, hvem kan se det, kan det gå til en sandkasse, forlate regionen, dukke opp i analyse, hvor lenge oppbevares det, kan en agent bruke det? Nå gjør klassifiseringen en jobb.
Klassifisering uten håndheving er pynt
Section titled “Klassifisering uten håndheving er pynt ”Merk mottakerens telefonnummer som sensitivt og endre ingenting annet, og du har skrevet dokumentasjon. Nyttig, men styring går lenger: klassifisering bør styre tillatelser, maskering, kryptering, oppbevaring, samtykke, dataflyt, bruk i sandkasser, revisjon og KI-tilgang. Noe av det er arkitektens designbeslutning; noen plattformer bruker nå merkelapper og klassifiseringer direkte i policyer, slik styringen i Data 360 gjør (Data Governance in Data 360 (opens in a new tab)). Og å merke et felt Restricted hindrer ingen i å lese det. Klassifisering sier hvordan et felt bør behandles; sikkerheten gjør det slik. Rekkefølgen er: identifiser dataene, forstå dem, klassifiser det som betyr noe, og bruk så kontrollene klassifiseringen krever.
Tre spørsmål om dataene dine, og det tredje må styre noe.
Referansedata trenger også metadata
Section titled “Referansedata trenger også metadata ”Landkoder, leveringsstatuser, DC-koder, partneridentifikatorer, årsaker til kansellering: de ser enkle ut helt til to systemer er uenige. Ett sier CANCELLED, et annet CANCELED, et tredje CNCL, et fjerde 9. Referansedata trenger definisjoner, en eier, en kilde, en livssyklus der verdiene endres, og tilordninger når systemene representerer dem forskjellig. Små verdier kan styre svært store prosesser. Kapittel 6 går videre.
Alle tre sammen
Section titled “Alle tre sammen ”Ta mottakerens telefonnummer. Ordbok: nummeret som brukes for å nå personen som mottar en bestemt levering. Opphav: fra detaljhandelspartnerens manifest. Klassifisering: personopplysninger. Nå blir arkitekturspørsmålene mulige: kan teamet se det, og hvor lenge (briefen sier bare for egne stopp, bare den dagen); kan det gå til en sandkasse; trenger Snowflake det; kan en agent bruke det; hva skjer når leveringen er gjennomført?
Ta så leveringsstatus. Ordbok: leveringens nåværende operative tilstand. Opphav: satt av leveringsprosessen til Steve Trucking og sendt tilbake til hver partner gjennom partnerens egen integrasjon. Klassifisering: operativ, ikke sensitiv. Forskjellige data, forskjellig behandling. Det er poenget.
Jeg behandler ikke metadata som dokumentasjon som lages etter at den egentlige arkitekturen er ferdig. Hvis jeg ikke kan si hva et felt betyr, forstår jeg ikke datamodellen. Hvis jeg ikke vet hvor en verdi kom fra, forstår jeg ikke integrasjonene. Hvis jeg ikke vet om den er sensitiv, forstår jeg ikke sikkerheten. Metadata beskriver arkitekturen, og styrer den noen ganger.
Utover eksamen: hva KI endrer. Klassifisering er i ferd med å bli bryteren for hva en agent kan hente eller gjenta, og opphavet må nå helt fram til agentens svar eller handling. Hvis en agent forteller en mottaker at leveringen er forsinket, bør arkitekturen kunne si hva som var grunnlaget, hvor det kom fra, og om agenten hadde lov til å bruke det. «Et sted i Salesforce» er ikke opphav, og «kundedata» er ikke en klassifisering.
Hva en arkitekt bestemmer her
Section titled “Hva en arkitekt bestemmer her ”- Hvilke forretningsbegreper som trenger styrte definisjoner, slik at systemer og team ikke gir ett ord forskjellige betydninger.
- Hvordan viktige verdier beholder nok opphav til å vise kilde, autoritet og transformasjoner.
- Hvilke felt som har sensitivitets- eller compliance-betydning og derfor får eksplisitt klassifisering.
- Hvilken taksonomi organisasjonen bruker, og om folk kan bruke den konsekvent.
- Hvordan klassifisering styrer ekte kontroller i stedet for å ligge ubrukt.
Før du styrer data, må du vite hva du har: hva det betyr, hvor det kom fra, hvordan det må behandles. Dokumenter bredt, klassifiser bevisst, ta vare på opphavet der det betyr noe. Ellers styrer du ikke dataene. Du bare har dem.
Les mer
Section titled “Les mer ”- Salesforce Help, Data Classification Metadata Fields (opens in a new tab), på engelsk, kontrollert 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, kontrollert 2026-10-14.