Glossar, Datenherkunft und Klassifizierung
Auch in 28 Sprachen
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)
Modul 3 von 6 im Kapitel Datenqualität und Governance, Kapitel 5 des Kurses Data Architect. Jedes Modul steht für sich. Zurück: Schlechte Daten fernhalten · Weiter: Datenschutzgesetze prägen den Entwurf
Die Frage, die dieses Modul beantwortet: Wie halten Sie fest, was Daten bedeuten, woher sie kommen und wie sensibel sie sind?
Sie haben eine Org geerbt. Der Account hat 900 Felder, darunter Customer_Type__c, Customer_Class__c, Customer_Category__c, Customer_Status__c, ERP_Status__c und Account_Status__c. Welches sagt Ihnen, ob jemand tatsächlich Kunde ist? Sie öffnen die Beschreibungen. Drei sind leer. Eine lautet «Customer Type». Danke. Eine sagt, es komme aus dem ERP; ein anderes wurde vor sechs Jahren von jemandem angelegt, der längst weg ist. Stellen Sie sich jetzt vor, Sie sind nicht in der Architektur, sondern eine Integration, ein Berichtsteam oder ein Agent. Die Organisation hat reichlich Daten. Das heisst nicht, dass sie weiss, was die Daten bedeuten.
Hier werden Metadaten zur Architektur, über drei Fragen, die zusammenhängen, aber nicht dieselben sind:
- Glossar: Was bedeuten diese Daten?
- Datenherkunft: Woher kommen sie?
- Klassifizierung: Wie müssen sie behandelt werden?
Zwei Arten von Metadaten
Abschnitt betitelt „Zwei Arten von Metadaten “Metadaten gibt es in zwei Arten, und Sie brauchen beide. Geschäftliche Metadaten sind das, was die Daten für das Geschäft bedeuten: die Definition, die Eigentümer:innen, die Regeln für ihre Nutzung, wie sensibel sie sind. Technische Metadaten sind, wie die Daten gebaut sind und sich bewegen: Objekt und Feld, Typ und Länge, API-Name, Schema, die Zuordnung von einem System zum anderen, die Datenherkunft von der Quelle zum Ziel. API-Name und Typ eines Feldes sagen dem Entwicklungsteam, wie es zu nutzen ist; seine Definition und seine Eigentümer:innen sagen allen anderen, ob es zu nutzen ist. Wo sich die beiden widersprechen oder eines fehlt, gehen Integrationen und Berichte schief.
Prüfungswissen. Unterscheiden Sie geschäftliche Metadaten (Bedeutung, Definitionen, Eigentümer:innen, Regeln, Sensibilität: das Geschäftsglossar und die Klassifizierung) von technischen Metadaten (Objekte, Felder, Typen, API-Namen, Schemas, Zuordnungen und Datenherkunft).
Beginnen Sie mit der Bedeutung
Abschnitt betitelt „Beginnen Sie mit der Bedeutung “Kapitel 3 hat die Regel aufgestellt: Jedes Feld bekommt eine Beschreibung. Nicht «Customer Status» für ein Feld namens Customer Status, sondern etwa «Die aktuelle Geschäftsbeziehung des Partners mit Steve Trucking. Nach der Aktivierung vom ERP gesetzt. Nicht für die Qualifizierung von Interessenten verwenden.» Jetzt weiss ich, was es bedeutet, woher es kommt und wofür ich es nicht verwenden soll. Das ist der Anfang eines Geschäftsglossars: gemeinsame Definitionen für die Daten, die zählen. Was ist ein Kunde? Ein aktiver Kunde? Was bedeutet Geliefert? Was gilt als pünktlich? Das klingt selbstverständlich, bis Sie fünf Abteilungen in einen Raum setzen: Die Finanzabteilung hat eine Definition, der Vertrieb eine andere, der Betrieb eine dritte, das Data Warehouse eine vierte, und jemand hat ein Dashboard auf einer fünften gebaut. Das Problem ist nicht, dass niemand dieselbe Sprache spricht. Es ist, dass das Unternehmen sich nicht auf die Bedeutung geeinigt hat.
Ein Glossar kann in einer Tabelle oder einem Dokumentationswerkzeug leben, aber seine wichtigen Definitionen müssen nah an der Stelle sein, an der Menschen die Daten nutzen. Auf der Plattform sind das Feldbeschreibungen, Hilfetext und die Klassifizierungsmetadaten. In der Analytik zählt es noch mehr: «Umsatz» kann nicht auf dem Dashboard der Geschäftsführung eines bedeuten und in einer Abfrage der Analyse etwas anderes. Dafür ist eine semantische Schicht da, und die semantischen Modelle von Data 360 halten gesteuerte Definitionen wie Kennzahlen, Dimensionen und Beziehungen oberhalb der physischen Daten (Create a Semantic Model in Data 360 (opens in a new tab), auf Englisch). Die Technologie ändert sich; die Anforderung nicht: Wichtige Daten brauchen eine vereinbarte Bedeutung.
Und beginnen Sie mit der Bedeutung, nicht mit der Technologie. Ein Glossar, das mit Objekt, Feld, Typ und API-Name beginnt, dokumentiert die Umsetzung. Eines, das mit Geschäftsbegriffen beginnt, dokumentiert das Unternehmen:
| Geschäftsbegriff | Bedeutung | Wo er abgebildet wird |
|---|---|---|
| Handelspartner | Ein Händler, für den Steve Trucking unter Vertrag liefert | Salesforce-Account; Kunde im Finanz-ERP |
| Lieferung | Eine Lieferung an einen Empfänger, an eine Adresse, an einem Tag | Heute RouteDesk; ein Arbeitsauftrag, sobald die Lieferungen nach Salesforce wechseln |
| Empfänger | Die Person, die eine Lieferung erhält | Empfängerangaben auf der Lieferung |
| Geliefert | Abgeschlossen gemäss der vereinbarten operativen Definition | Lieferstatus |
| Pünktliche Lieferung | Innerhalb des vereinbarten Lieferfensters abgeschlossen | Abgeleitete Kennzahl |
Eine Bedeutung, viele technische Abbildungen.
Dann fragen Sie, woher es kommt
Abschnitt betitelt „Dann fragen Sie, woher es kommt “Sobald ich weiss, was ein Wert bedeutet, will ich wissen, woher er kommt. Das ist die Datenherkunft (Lineage). Der rechtliche Name eines Partners in Salesforce: Hat ihn jemand aus dem Vertrieb getippt, hat das ERP ihn geschickt, hat eine Integration ihn transformiert, hat Data 360 ihn vereinheitlicht, wurde er berechnet, hat KI ihn erzeugt? Davon hängt ab, wie sehr ich ihm vertraue und was ich damit tun darf. Erinnern Sie sich an die vorläufigen Datensätze aus Modul 2: Zwei Accounts können beide «Keystone» heissen, einer gestern im Vertrieb angelegt, der andere aus dem ERP mit einer massgeblichen Kennung. Derselbe Text, andere Herkunft, andere Behandlung.
Datenherkunft ist nicht nur das Diagramm eines Data Engineers mit tausend Tabellen. Für wichtige Daten will ich praktische Fragen beantworten: Wo hat es begonnen, welches System ist massgeblich, was hat es transformiert, welche Systeme haben Kopien bekommen, was hat es zuletzt geändert, und kann ich einen abgeleiteten Wert zu seinen Quellen zurückverfolgen? Die Landschaft aus Kapitel 4 sagt, dass die Systeme verbunden sind. Die Datenherkunft sagt, was unterwegs mit den Daten passiert ist.
Manche Herkunft gibt es umsonst: die ERP-ID auf dem Account, Erstellt von und Zuletzt geändert von, Integrationsprotokolle, Zuordnungsdokumente. Data 360 fügt seinen Datenobjekten Herkunftsfelder hinzu, die für jeden Datensatz Datenquelle und Quellobjekt festhalten (Data Lineage Fields (opens in a new tab), auf Englisch). Aber nehmen Sie nicht an, dass die Herkunft erscheint, weil Systeme integriert sind. Manchmal ist die nützlichste Herkunft ein Feld: Quellsystem = Keystone. Und wenn die Quelle für die Governance zählt, machen Sie sie mechanisch verlässlich, gesetzt von der Integration, nicht von einer Person getippt.
Abgeleitete Daten brauchen die Herkunft am meisten. Angenommen, Steve Trucking berechnet ein Verspätungsrisiko aus Lastwagenposition, Lieferfenster und Tourenhistorie, und die Disposition nutzt es zur Priorisierung. Woher kam «hoch»? Fügen Sie einen Agenten hinzu, der einem Empfänger sagt «Ihre Lieferung verspätet sich», und Sie müssen wissen, worauf das beruhte und wie aktuell es war. Je weiter Sie sich von gespeicherten Werten zu berechneten, vereinheitlichten, vorhergesagten und erzeugten bewegen, desto mehr zählt die Herkunft.
Die Klassifizierung beantwortet eine andere Frage
Abschnitt betitelt „Die Klassifizierung beantwortet eine andere Frage “Jetzt: Wie sollten sie behandelt werden? Name des Empfängers, Lieferadresse, Telefonnummer, Liefernotizen, Lieferstatus, Lastwagennummer, Verteilzentrum, Handelspartner, Foto: Sie sind nicht gleich sensibel. «In Zustellung» ist keine Telefonnummer, und ein Verteilzentrumscode ist kein Foto vom Inneren eines Zuhauses. Salesforce lässt Sie das an jedem Feld festhalten, Standard oder benutzerdefiniert: Data Owner, Field Usage, Data Sensitivity Level und Compliance Categorization (Data Classification Metadata Fields (opens in a new tab), auf Englisch). Kapitel 3 nannte sie die Taxonomiefelder und erklärte, warum sie zählen: Kennzeichnen Sie ein Feld als PII oder GDPR, und Prozesse können es finden, von Maskierungswerkzeugen bis zur KI-Vertrauensschicht von Salesforce (Einstein Trust Layer), die gekennzeichnete Werte davon abhalten kann, ein grosses Sprachmodell zu erreichen. Eine Warnung aus Kapitel 3: Salesforce deaktiviert diese LLM-Maskierung inzwischen für Agenten, weil sie den Kontext entfernen kann, den ein Agent braucht (Klassifizieren Sie, was zählt: die Taxonomiefelder). Die Klassifizierung muss also weiterhin die anderen Kontrollen steuern.
Meine Position ist hier bewusst: Klassifizieren Sie die sensiblen Felder, nicht jedes Feld. Ich will nicht drei Monate damit verbringen, Tausende Felder zu klassifizieren, damit jemand «100 % klassifiziert» melden kann und niemand es nutzt. Die Telefonnummer des Empfängers: ja. Die Wohnadresse: ja. Liefernotizen, die vielleicht Torcodes und «Hund im Garten» enthalten: ja. Fotos, die Menschen oder ein Zuhause zeigen können: unbedingt. Eine interne Anzeigebeschriftung? Dahin gehört die Energie der Governance nicht. Das macht undokumentierte Felder nicht akzeptabel. Zwei verschiedene Aufgaben: Dokumentation ist breit; Klassifizierung ist bewusst. Das hält die Klassifizierung aussagekräftig.
Eine Taxonomie, die Menschen nutzen können
Abschnitt betitelt „Eine Taxonomie, die Menschen nutzen können “Klassifizierung braucht ein Vokabular, eine Taxonomie. Die Standardwerte von Salesforce reichen von Public, Internal, Confidential, Restricted bis MissionCritical; Ihre Organisation will vielleicht eigene Bezeichnungen. Ich schreibe sie nicht vor. Halten Sie sie verständlich: Wenn es 47 Kategorien gibt und niemand ausserhalb des Datenschutzteams Kategorie 31 von 32 unterscheiden kann, hilft es nicht. Eine gute Taxonomie verbindet eine Bezeichnung mit Verhalten. Wenn ein Feld sensible personenbezogene Daten enthält, wer darf es sehen, darf es in eine Sandbox, die Region verlassen, in der Analytik erscheinen, wie lange wird es aufbewahrt, darf ein Agent es nutzen? Jetzt arbeitet die Klassifizierung.
Klassifizierung ohne Durchsetzung ist Dekoration
Abschnitt betitelt „Klassifizierung ohne Durchsetzung ist Dekoration “Kennzeichnen Sie die Telefonnummer des Empfängers als sensibel und ändern Sie sonst nichts, und Sie haben Dokumentation geschrieben. Nützlich, aber Governance geht weiter: Die Klassifizierung sollte Berechtigungen, Maskierung, Verschlüsselung, Aufbewahrung, Einwilligung, Datenbewegung, Sandbox-Nutzung, Prüfung und KI-Zugriff steuern. Manches davon ist eine Entwurfsentscheidung der Architektur; manche Plattformen wenden Tags und Klassifizierungen inzwischen direkt in Richtlinien an, wie es die Governance von Data 360 tut (Data Governance in Data 360 (opens in a new tab), auf Englisch). Und ein Feld als Restricted zu kennzeichnen hält niemanden davon ab, es zu lesen. Die Klassifizierung sagt, wie ein Feld behandelt werden sollte; die Sicherheit sorgt dafür. Die Reihenfolge ist: die Daten identifizieren, sie verstehen, klassifizieren, was zählt, dann die Kontrollen anwenden, die diese Klassifizierung verlangt.
Drei Fragen über Ihre Daten, und die dritte muss etwas steuern.
Auch Referenzdaten brauchen Metadaten
Abschnitt betitelt „Auch Referenzdaten brauchen Metadaten “Ländercodes, Lieferstatus, Verteilzentrumscodes, Partnerkennungen, Stornogründe: Sie sehen einfach aus, bis sich zwei Systeme widersprechen. Eines sagt CANCELLED, ein anderes CANCELED, ein drittes CNCL, ein viertes 9. Referenzdaten brauchen Definitionen, einen Eigentümer, eine Quelle, einen Lebenszyklus, wenn sich Werte ändern, und Zuordnungen, wenn Systeme sie unterschiedlich darstellen. Kleine Werte können sehr grosse Prozesse steuern. Kapitel 6 geht weiter.
Alle drei zusammen
Abschnitt betitelt „Alle drei zusammen “Nehmen Sie die Telefonnummer des Empfängers. Glossar: die Nummer, über die die Person erreicht wird, die eine bestimmte Lieferung erhält. Herkunft: aus der Ladeliste des Handelspartners. Klassifizierung: personenbezogene Daten. Jetzt werden die Architekturfragen möglich: Darf die Crew sie sehen, und wie lange (der Steckbrief sagt: nur für ihre eigenen Stopps, nur am Tag selbst); darf sie in eine Sandbox; braucht Snowflake sie; darf ein Agent sie nutzen; was passiert, wenn die Lieferung erledigt ist?
Nehmen Sie jetzt den Lieferstatus. Glossar: der aktuelle operative Zustand der Lieferung. Herkunft: gesetzt vom Lieferprozess von Steve Trucking und über die jeweilige Integration an jeden Partner zurückgeschickt. Klassifizierung: operativ, nicht sensibel. Andere Daten, andere Behandlung. Darum geht es.
Ich behandle Metadaten nicht als Dokumentation, die entsteht, nachdem die echte Architektur fertig ist. Wenn ich nicht sagen kann, was ein Feld bedeutet, verstehe ich das Datenmodell nicht. Wenn ich nicht weiss, woher ein Wert kommt, verstehe ich die Integrationen nicht. Wenn ich nicht weiss, ob er sensibel ist, verstehe ich die Sicherheit nicht. Metadaten beschreiben die Architektur, und manchmal steuern sie sie.
Über die Prüfung hinaus: Was KI ändert. Die Klassifizierung wird zum Schalter dafür, was ein Agent abrufen oder wiedergeben darf, und die Herkunft muss bis zur Antwort oder Aktion des Agenten reichen. Wenn ein Agent einem Empfänger sagt, die Lieferung verspäte sich, sollte die Architektur sagen können, worauf das beruhte, woher es kam und ob der Agent es nutzen durfte. «Irgendwo in Salesforce» ist keine Herkunft, und «Kundendaten» ist keine Klassifizierung.
Was Architekt:innen hier entscheiden
Abschnitt betitelt „Was Architekt:innen hier entscheiden “- Welche Geschäftsbegriffe gesteuerte Definitionen brauchen, damit Systeme und Teams einem Wort nicht verschiedene Bedeutungen geben.
- Wie wichtige Werte genug Herkunft behalten, um ihre Quelle, Autorität und Transformationen zu zeigen.
- Welche Felder Sensibilitäts- oder Compliance-Bedeutung tragen und daher ausdrücklich klassifiziert werden.
- Welche Taxonomie die Organisation verwendet und ob Menschen sie einheitlich anwenden können.
- Wie die Klassifizierung echte Kontrollen steuert, statt ungenutzt herumzuliegen.
Bevor Sie Daten steuern, wissen Sie, was Sie haben: was es bedeutet, woher es kommt, wie es behandelt werden muss. Breit dokumentieren, bewusst klassifizieren, die Herkunft dort bewahren, wo sie zählt. Sonst steuern Sie die Daten nicht. Sie haben sie nur.
Weiterlesen
Abschnitt betitelt „Weiterlesen “- Salesforce-Hilfe, Data Classification Metadata Fields (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.
- Salesforce-Hilfe, Data 360: Data Lineage Fields (opens in a new tab), Data Governance in Data 360 (opens in a new tab) und Create a Semantic Model in Data 360 (opens in a new tab) (auf Englisch), geprüft am 2026-10-14.