Discovery in Unity Catalog: Wie ein großer Tabellenbestand wirklich nutzbar wird
Die Kernaussagen auf einen Blick.
- Unity Catalog bündelt mit Catalog Explorer, Suche, Beschreibungen, Tags, AI-generierten Kommentaren, BROWSE und Genie die zentralen Funktionen für Data Discovery.
- Diese Funktionen entfalten ihren Nutzen nur, wenn die Datenprodukte mit verlässlichen Metadaten gepflegt werden. Beschreibungen, Tags, klare Ownership und ein geregelter Umgang mit Beispieldaten sind dafür grundlegende Voraussetzungen.
- Externe Datenkataloge sind nur selten ein vollständiger Ersatz für die Discovery-Funktionen von Unity Catalog und ergänzen sie nur dort, wo Datenflüsse Databricks verlassen.
- Beschreibungen, Tags und klare Ownership sollten als verbindliche Kriterien für die Freigabe eines Datenprodukts gelten. AI-generierte Kommentare können die Erstbefüllung beschleunigen, sollten aber immer fachlich geprüft werden. BROWSE für interne Nutzergruppen möglichst breit vergeben, Genie ausschließlich auf kuratierten Datenbeständen einsetzen, externe Kataloge nur ergänzen, wenn eine systemübergreifende Sicht benötigt wird.
Inhaltsverzeichnis
Daten, die keiner findet, nutzt keiner
Vier Jahre nach Einführung des Lakehouse umfasst der Catalog inzwischen 4.000 Tabellen. Im Sales-Catalog existieren siebzehn unterschiedlich benannte Varianten einer Kundentabelle, im Marketing-Bereich finden sich mehrere Tabellen mit Namen wie _final_v2, im Data-Science-Bereich besteht weiterhin ein historisches temporäres Schema mit personenbezogenem Namen. Für Konsumenten ist nicht eindeutig erkennbar, welche Tabelle als verbindliche Quelle gilt. Eine Analystin sucht im Catalog Explorer nach mehreren naheliegenden Begriffen, findet drei Treffer ohne Beschreibung und am Ende fragt sie im gemeinsamen Datenkanal nach der richtigen Tabelle. Die Antwort kommt erst einige Tage später von dem Kollegen, der die Tabelle ursprünglich erstellt hat.
Eine ähnliche Situation entsteht in vielen gewachsenen Datenplattformen, wo Unity Catalog produktiv läuft und niemand die Discovery-Schicht gepflegt hat. Tabellen, Berechtigungen und Lineage sind technisch vorhanden. Auffindbarkeit, Verständnis und Vertrauen hängen jedoch von Metadaten ab, die häufig nicht konsequent gepflegt werden: Kommentaren, Tags, einem klaren Owner, einem kontrollierten Zugriff auf Beispieldaten, kuratierten Genie Spaces. Fehlen diese Eigenschaften, kann die Discovery-Schicht ihre Aufgabe nicht vollständig erfüllen und Genie liefert entsprechend ungenaue oder unvollständige Antworten, weil fachlicher und semantischer Kontext fehlt.
Discovery sollte als fester Bestandteil der Qualitätsanforderungen eines Datenprodukts verstanden werden. Wer Discovery ausschließlich als Werkzeugfrage betrachtet, führt häufig zusätzlich einen externen Datenkatalog ein. Ohne dass damit die zugrunde liegenden Pflege- und Ownership-Probleme gelöst werden.
Was ist Data Discovery in Unity Catalog?
Unity Catalog stellt sieben zentrale Funktionen für Discovery und Self-Service bereit. Gemeinsam bilden sie die Sicht der Datenkonsumenten auf den Lakehouse-Katalog.
| Baustein | Was er leistet | Mess-Größe für Reife |
|---|---|---|
| Catalog Explorer | Zentrale Benutzeroberfläche für Catalogs, Schemas, Tabellen, Volumes, Funktionen und Modelle | Nutzung pro Konsumenten-Gruppe |
| Volltext-Suche | Suche über Namen, Kommentare, Tags, Beschreibungen | Anteil relevanter Tabellen unter den wichtigsten Suchergebnissen |
| Beschreibungen () | Tabellen- und Spalten-Erklärung | Anteil dokumentierter Tabellen und Spalten je Catalog |
| Tags | Klassifizierung (PII, Domain, Quality, Sensitivity) | Anteil der Tags, die der verbindlichen Taxonomie entsprechen |
| AI-generierte Kommentare | KI-Vorschlag für leere Kommentare, manuell zu bestätigen | Bestätigungsquote, Stichprobenprüfung auf fachlich falsche Beschreibungen |
| BROWSE-Privileg | Objekt taucht in Discovery auf, auch ohne SELECT | Anteil auffindbarer Objekte ohne direkten Datenzugriff |
| Genie und Business Semantics | NL-Abfragen auf kuratierte Catalogs und Metric-Layer | Anteil verwertbarer Antworten auf typische Fachfragen |
Diese Funktionen decken die wesentlichen Anforderungen der Konsumentensicht ab. Lineage, Berechtigungen und Zugriffskontrollen ergänzen diese Sicht auf einer darunterliegenden Governance-Ebene. Den Gesamtbauplan und das Verhältnis der Geschwister-Schichten zeigen wir im Überblick zu Unity Catalog.
Die Qualität der Discovery hängt unmittelbar von gepflegten Metadaten ab. Entscheidend ist, ob diese Pflege Teil des Datenproduktprozesses oder eine nachgelagerte Dokumentationsaufgabe bleibt.
Data & AI Beratung mit ruhrdot
Als offizieller Databricks-Partner begleiten wir dich von der Datenstrategie bis zur produktiven KI-Lösung.
Wie spielen Catalog Explorer und Suche zusammen?
Der Catalog Explorer ist der zentrale Einstiegspunkt für die Suche und Erkundung von Datenobjekten. Konsumenten navigieren dort durch die für sie sichtbaren Catalogs und Schemas, prüfen Tabellen, Spalten und Metadaten, lesen Kommentare und sehen Ownership, Tags und weitere Kontextinformationen ein. Wie hilfreich diese Sicht ist, hängt von drei Voraussetzungen ab.
Erstens: Welche Objekte dürfen für den Konsumenten sichtbar sein? Ohne ausreichende Sichtbarkeitsrechte erscheint ein Objekt weder im Explorer noch in der Suche. Mit BROWSE kann die Auffindbarkeit erweitert werden, ohne zugleich den Zugriff auf die Daten freizugeben. Konsumenten finden eine Tabelle, sehen Beschreibung und Tags und anschließend können Nutzer gezielt Zugriff auf das relevante Objekt beantragen.
Zweitens: Welche Metadaten stehen für die Suche zur Verfügung? Die Volltext-Suche im Catalog Explorer durchsucht Tabellen- und Spalten-Namen, Beschreibungen und Tag-Werte. Eine Suche nach einem fachlichen Begriff kann auch technisch anders benannte Tabellen finden, sofern dieser Begriff in Beschreibung oder Tags enthalten ist. Fehlen solche Metadaten, bleibt die Suche weitgehend auf technische Bezeichnungen beschränkt.
Drittens: Welche Informationen helfen dem Nutzer nach dem Auffinden bei der Bewertung? Die Datenvorschau steht nur bei entsprechendem Zugriff und zulässiger Konfiguration zur Verfügung. Ohne Vorschau und fachliche Beschreibung lässt sich die Eignung einer Tabelle nur schwer beurteilen.
Suche, Explorer und Metadaten bilden gemeinsam die Discovery-Erfahrung: die Sichtbarkeit kommt von BROWSE, die Qualität der Suchergebnisse hängt von Beschreibungen, Tags und Benennungen ab, das Verständnis entsteht durch Beschreibung, Klassifikation, Ownership und gegebenenfalls Beispieldaten. Fehlen die Metadaten, bleibt der Explorer im Wesentlichen eine technische Objektübersicht.
Der COMMENT gehört zu den wichtigsten Metadaten für eine funktionierende Discovery. Ohne Kommentar lässt sich eine Tabelle meist nur über ihre technische Bezeichnung finden. Fachliche Suchbegriffe führen dann häufig nicht zum richtigen Objekt. Fehlt die Spaltenbeschreibung, muss ihre fachliche Bedeutung häufig separat geklärt werden. Auch die Qualität von Genie-Antworten sinkt, weil fachliche Definitionen und Zusammenhänge fehlen.
Eine hilfreiche Tabellenbeschreibung beantwortet vier Fragen pro Tabelle in zwei bis vier Sätzen:
- Was ist der Geschäftszweck der Tabelle? (Welche Frage beantwortet sie?)
- Was steht in einer Zeile? (Welche fachliche Granularität besitzt eine Zeile?)
- In welchem Rhythmus werden die Daten aktualisiert? (Stündlich, täglich, monatlich)
- Welches Team ist verantwortlich und auf welchen wesentlichen Quellen basiert die Tabelle?
Für Spalten genügt meist eine kurze und eindeutige fachliche Beschreibung. Sie sollte jedoch nicht lediglich Name oder Datentyp wiederholen. Auch Views und Materialized Views sollten konsequent dokumentiert werden: dort gehört der COMMENT nicht weniger streng. Diese Beschreibungen fließen ebenfalls in die Interpretation durch Genie ein. Ohne sie orientiert sich das Modell zu stark an technischen Objekt- und Spaltennamen.
In reifen Plattformen ist eine vollständige Beschreibung Voraussetzung für die produktive Freigabe. Tabellen ohne fachliche Beschreibung sollten nicht als vollständig produktionsreif gelten. Für produktive Catalogs sollte ein verbindlicher Zielwert für die Beschreibungsabdeckung festgelegt werden. Die Abdeckung kann über das Information Schema gemessen und regelmäßig ausgewertet werden über INFORMATION_SCHEMA.tables und INFORMATION_SCHEMA.columns.
Tags bilden neben Beschreibungen eine zweite zentrale Grundlage für Discovery. Sie machen strukturierte Klassifikationen unabhängig von frei formulierten Beschreibungen auswertbar. Vier Tag-Kategorien decken viele typische Discovery-Anforderungen ab.
Domain-Tags
Ordnen eine Tabelle einem Geschäftsbereich zu (domain=sales, domain=marketing, domain=finance) und unterstützen die Zuordnung zu verantwortlichen Teams.
Sensitivity-Tags
Klassifizieren Schutzbedarf (pii=true, sensitivity=internal|confidential|secret) als Grundlage für Maskierungs- und Zugriffsrichtlinien.
Qualitäts- und Lifecycle-Tags
Beschreiben den Reife- und Nutzungsstand (tier=bronze|silver|gold, freshness_sla=1h), produktiv nutzbar oder technischer Zwischenstand.
Fachspezifische Klassifikationen
Produkt-Familien, Kunden-Segmente oder Region ergänzen die Einordnung, wenn Objekt- und Spaltennamen dafür nicht ausreichen.
Sensitivity-Tags sind zugleich Voraussetzung für die gezielte Nachverfolgung personenbezogener Spalten über Lineage.
Damit Tags nicht zu einem uneinheitlichen Metadatenbestand werden, braucht es drei Regeln: zentrale Schlüssel und Werte, automatisierte Vergabe im Deployment- oder Datenproduktprozess und regelmäßige Prüfungen auf fehlende oder ungültige Tags. Abweichungen sollten an die verantwortlichen Teams zurückgespielt werden.
Wie Tags als Klassifizierungs- und Steuerungsschicht in Unity Catalog genutzt werden können, ordnen wir im Überblick zu Tags in Unity Catalog ein.
Was AI-generierte Kommentare leisten
AI-generierte Kommentare können die Dokumentation großer Catalogs deutlich beschleunigen. Unity Catalog kann für Tabellen und Spalten Kommentar-Vorschläge erzeugen, die anschließend von einem verantwortlichen Nutzer geprüft und freigegeben werden müssen. Die Vorschläge basieren auf Schema, Daten-Samples und vorhandenen Metadaten. Die Databricks-Doku zu AI-Generated Comments beschreibt Verhalten und Voraussetzungen.
Der größte Nutzen liegt bei großen Beständen mit vielen leeren Kommentaren. Statt jede Beschreibung manuell einzusammeln, entsteht zunächst ein brauchbarer Entwurf. Die fachliche Prüfung bleibt aber Aufgabe der verantwortlichen Teams.
Problematisch wird es, wenn Vorschläge ungeprüft übernommen werden. Drei Grenzen sind wichtig:
Falsche Sicherheit
Unklare Tabellen wie tmp_ml_features_v17 können plausibel klingende, aber fachlich falsche Beschreibungen bekommen, mit falschen Annahmen in Analysen als Folge.
Veraltete Beschreibungen
AI-Kommentare ersetzen keine fachliche Verantwortung. Ändert sich Schema oder Bedeutung einer Tabelle, muss die Beschreibung mitgeprüft werden.
Uneinheitliche Sprache
Generierte Texte klingen oft generisch oder technisch und treffen nicht immer die Geschäftssprache, nach der Fachbereiche wirklich suchen.
Ein belastbares Vorgehen ist deshalb: AI-Kommentare als ersten Entwurf nutzen, danach durch den Datenprodukt-Owner bestätigen lassen und regelmäßig stichprobenartig prüfen. Eine hohe Vorschlagsquote allein reicht nicht. Entscheidend ist, wie viele Kommentare fachlich bestätigt wurden.
Was ändert das BROWSE-Privileg?
BROWSE sorgt dafür, dass Nutzer Datenobjekte finden können, ohne die Daten selbst lesen zu dürfen. Ein Objekt erscheint dann im Catalog Explorer und in der Suche. Der Inhalt bleibt aber geschützt. Die Databricks-Doku zum BROWSE Privilege beschreibt das Verhalten je Objekt-Typ.
Für Self-Service ist das wichtig. Ohne BROWSE sehen Nutzer oft nur die Tabellen, auf die sie bereits Zugriff haben. Viele vorhandene Daten bleiben dadurch unsichtbar. Mit BROWSE können sie den Datenbestand erkunden, Beschreibungen und Tags lesen, den Owner erkennen und gezielt Zugriff anfragen.
Damit das funktioniert, braucht es klare Regeln: BROWSE sollte eher auf Catalog- oder Schema-Ebene vergeben werden, nicht über viele Einzelobjekte. Sichtbare Datenobjekte müssen gut beschrieben und klassifiziert sein. Besonders sensible Bereiche, etwa HR- oder Vorstandsdaten, sollten separat geregelt oder von der allgemeinen Sichtbarkeit ausgenommen werden.
Wie BROWSE in ein sauberes Berechtigungsmodell passt, klären wir im Überblick zu Permissions in Unity Catalog.
Gute Discovery braucht klare Owner
Discovery funktioniert nur, wenn Nutzer nicht nur eine Tabelle finden, sondern auch wissen, wer dafür verantwortlich ist. Unity Catalog zeigt pro Objekt einen Owner. In der Praxis steht dort aber oft noch ein technischer Account, ein Service Principal oder ein persönliches Benutzerkonto aus der ursprünglichen Einrichtung. Für Konsumenten ist das wenig hilfreich, weil daraus kein klarer fachlicher Ansprechpartner entsteht.
Drei Regeln helfen:
Owner sollte eine Gruppe sein. Persönliche Owner werden schnell zum Problem, wenn jemand das Team wechselt oder das Unternehmen verlässt. Besser ist eine Account-Gruppe, zum Beispiel team-sales-data-engineering.
Owner sollte zum Datenprodukt passen. Service Principals sind gut für Deployment und technische Ausführung. Sie ersetzen aber keine fachliche Verantwortung. Nutzer brauchen ein Team, an das sie Fragen zu Inhalt, Qualität und Nutzung der Daten richten können.
Ownership sollte regelmäßig geprüft werden. Über INFORMATION_SCHEMA lässt sich auswerten, wie viele Tabellen einen Gruppen-Owner haben und wie viele noch an Personen oder technische Accounts hängen. Ein hoher Anteil technischer oder persönlicher Owner ist ein Hinweis darauf, dass Datenprodukte organisatorisch nicht sauber zugeordnet sind.
Ohne klare Ownership bleibt Discovery unvollständig. Nutzer finden zwar Tabellen, Beschreibungen und Tags, wissen aber nicht, wen sie bei Fragen ansprechen sollen. Dann entstehen wieder manuelle Kontaktlisten, genau das, was ein Data Catalog eigentlich vermeiden soll.
Wie ermöglichen Genie und Business Semantics Self-Service?
Genie erweitert Discovery um natürlichsprachliche Fragen. Nutzer müssen nicht jede Tabelle, Spalte oder SQL-Struktur kennen, sondern können fachliche Fragen stellen. Genie übersetzt diese Fragen in SQL und nutzt dafür einen Genie Space: eine kuratierte Auswahl aus Tabellen, Beispielabfragen und Kontext.
Damit daraus echter Self-Service wird, reicht Genie allein nicht aus. Der Space braucht eine saubere fachliche Grundlage. Entscheidend sind vor allem vier Punkte:
- Gute Tabellen- und Spaltenbeschreibungen. Ohne Kontext steigt das Risiko, dass Genie die falschen Tabellen oder Spalten auswählt.
- Beispielabfragen für typische Fragen. Sie zeigen, wie fachliche Fragen im jeweiligen Bereich normalerweise beantwortet werden.
- Klare Business Semantics. Metriken, Dimensionen und Geschäftsregeln sollten einheitlich definiert sein, damit Begriffe wie Umsatz, Kunde oder aktive Bestellung nicht je nach Tabelle anders ausgelegt werden.
- Eine bewusst ausgewählte Tabellenbasis. Ein Genie Space sollte nicht einfach auf den gesamten Catalog zeigen. Testtabellen, Bronze-Schichten oder Zwischenstände erhöhen das Risiko falscher Antworten.
Business Semantics ergänzt dabei das, was Kommentare und Tags allein nicht leisten. Eine Kennzahl wie Umsatz wird als eigene fachliche Definition gepflegt und kann über mehrere Tabellen hinweg wiederverwendet werden. Wie diese semantische Schicht aufgebaut wird, ordnen wir im Überblick zu Business Semantics in Unity Catalog ein.
Ein Genie Space sollte erst produktiv genutzt werden, wenn typische Fragen zuverlässig beantwortet werden. Wenn viele Antworten falsch, unvollständig oder stark nachbearbeitungsbedürftig sind, fehlt meist noch Kontext, Semantik oder Kuratierung. Gute Discovery endet deshalb nicht bei der Suche nach Tabellen. Sie schafft die Grundlage dafür, dass Nutzer auf kuratierten Daten eigenständig zu belastbaren Antworten kommen.
Wann ergänzen externe Datenkataloge?
Viele Unternehmen nutzen Atlan, Collibra oder Microsoft Purview bereits vor Unity Catalog. Die Frage ist deshalb nicht: Unity Catalog oder externer Katalog? Wichtiger ist: Welche Aufgaben sollen direkt in Databricks bleiben, und wo braucht es eine Sicht über mehrere Systeme hinweg?
| Frage | Unity Catalog reicht meist | Externer Katalog ergänzt |
|---|---|---|
| Geht es nur um Databricks-Objekte? | ja | eher nein |
| Sollen auch Salesforce, ERP, externe Datenbanken oder andere Plattformen sichtbar werden? | nein | ja |
| Werden übergreifende Glossar-, Stewardship- oder Freigabeprozesse gebraucht? | nur begrenzt | ja, wenn mehrere Systeme beteiligt sind |
| Müssen Compliance-Workflows systemübergreifend dokumentiert werden? | nur für Databricks | ja, wenn der Prozess über Databricks hinausgeht |
Ein externer Katalog kann sinnvoll sein, wenn Daten aus mehreren Systemen gemeinsam auffindbar werden sollen, zum Beispiel Salesforce, SAP, Databricks und Snowflake in einer Suche. Unity Catalog bleibt dabei die führende Quelle für Databricks-Metadaten. Der externe Katalog übernimmt eher die übergreifende Sicht und zieht UC-Metadaten über Schnittstellen ein. Eine externe Anbieterperspektive dazu liefert der Atlan-Artikel zu Databricks Data Discovery.
Wichtig ist, doppelte Pflege zu vermeiden. Wenn Beschreibungen, Tags und Owner parallel in Unity Catalog und im externen Katalog gepflegt werden, entstehen schnell widersprüchliche oder veraltete Metadaten. Die klare Regel sollte deshalb lauten: Unity Catalog ist die Pflege-Schicht für Databricks-Objekte. Der externe Katalog bündelt Metadaten über Systemgrenzen hinweg.
Grenzen von Data Discovery in Unity Catalog
Unity Catalog bringt viele Funktionen für Data Discovery mit. Ob sie wirklich helfen, hängt aber weniger am Tool selbst als an Pflege, Verantwortung und klaren Regeln.
Metadaten brauchen Verantwortung
Beschreibungen, Tags und Owner müssen gepflegt werden. Ohne klare Zuständigkeiten bleibt Discovery unzuverlässig.
AI-Kommentare brauchen Review
AI-Vorschläge beschleunigen die Erstbefüllung, aber ohne fachliche Bestätigung können Beschreibungen falsch oder veraltet sein.
Suche braucht die richtige Sprache
Wer nach „Kundenstammdaten“ sucht, findet customer_master nur, wenn Beschreibungen und Tags diese Sprache aufnehmen.
Sensible Bereiche brauchen eigene Regeln
HR-Daten, Vorstands-Reporting oder Compliance-Daten brauchen oft eine strengere Sichtbarkeit als normale Fachbereichsdaten.
Genie ersetzt nicht alle Zugangswege
Genie hilft bei typischen Geschäftsfragen auf kuratierten Daten. Für spezielle Analysen bleiben Catalog Explorer, SQL und BI-Modelle wichtig.
Externe Kataloge lösen keine Pflegeprobleme
Atlan, Collibra oder Purview ergänzen eine systemübergreifende Sicht, ersetzen aber nicht die Metadaten-Pflege in Unity Catalog.
Die Grenze liegt also nicht nur in einzelnen Funktionen. Data Discovery wird erst belastbar, wenn Metadaten, Owner, Sichtbarkeit und Self-Service-Prozesse verbindlich gepflegt werden.
Fazit
Unity Catalog kann die Grundlage für eine leistungsfähige Self-Service- und Discovery-Plattform bilden, wenn ihr sie als Datenprodukt-Disziplin behandelt und nicht als UI-Feature.
Voraussetzung ist, dass Discovery-Anforderungen verbindlich in den Datenproduktprozess integriert werden. Catalog Explorer, Volltext-Suche, COMMENT, Tags, AI-generierte Kommentare, BROWSE-Privileg, Genie und Business Semantics decken gemeinsam die wesentlichen Funktionen für Auffindbarkeit, Einordnung und natürlichsprachlichen Zugriff ab. Die fachliche Pflege und organisatorische Verantwortung bleiben jedoch Aufgabe der jeweiligen Teams.
Externe Datenkataloge sind vor allem für eine systemübergreifende Sicht sinnvoll, wo Datenflüsse über Databricks hinausreichen oder ein Cross-System-Aggregator gefordert ist. Ohne klare Führungsrolle für Unity Catalog entstehen jedoch doppelte Metadaten und Verantwortlichkeiten.
AI-generierte Kommentare können die Dokumentation großer Bestände beschleunigen, wenn ihr sie als Erst-Vorschlag behandelt und durch Owner-Bestätigung absichert. Ohne fachliche Prüfung können jedoch überzeugend formulierte, aber falsche Beschreibungen veröffentlicht werden.
Mein Vorschlag: Beschreibungen, standardisierte Tags und gruppenbasierte Ownership als verbindliche Datenproduktanforderungen festlegen und die Einhaltung über regelmäßige Coverage-Auswertungen überwachen. AI-Kommentare als Beschleuniger mit verpflichtendem Owner-Review nutzen, ergänzt um regelmäßige Stichproben zur fachlichen Richtigkeit der AI-Kommentare. BROWSE für interne Konsumentengruppen möglichst auf Catalog- oder Schema-Ebene vergeben, besonders sensible Catalogs und Schemas separat behandeln. Genie nur auf fachlich kuratierten Spaces mit klar ausgewählten Datenobjekten einsetzen, mit gepflegten Kommentaren, Business Semantics und Beispiel-Abfragen. Externe Datenkataloge auf Anforderungen beschränken, die eine systemübergreifende Discovery oder formale Stewardship-Prozesse benötigen. Unity Catalog sollte dabei die führende Metadatenquelle für Databricks bleiben, während das externe Werkzeug die systemübergreifende Sicht bereitstellt.
FAQ
Discovery in Unity Catalog umfasst Catalog Explorer, Volltext-Suche, Beschreibungen über , Tags, AI-generierte Kommentare, BROWSE-Privileg, Sample Data, Owner-Anzeige sowie Genie und Business Semantics als kuratierte Frage-Antwort-Schicht. Zusammen bilden diese Bausteine die Konsumenten-Sicht auf den Lakehouse-Katalog. Lineage und Permissions liegen eine Schicht darunter und regeln Datenfluss und Zugriff.
COMMENT ist die Discovery-Pflicht