Datenprodukte gestalten
Datenprodukte sind fachlich strukturierte und standardisierte Datenobjekte, die aus einer oder mehreren Datenquellen erzeugt werden. Sie bilden eine verlässliche Grundlage für Visualisierung, Analyse und fachliche Auswertungen.
Datenprodukte entstehen durch die Integration und Harmonisierung von Rohdaten. Dabei werden Daten aus einer oder mehreren Quellen strukturiert aufbereitet, Attribute vereinheitlicht und zeitliche oder räumliche Unterschiede ausgeglichen. Das Ergebnis ist ein konsistenter Datenstand, dessen Inhalt und Herkunft eindeutig nachvollziehbar sind.
Ein Beispiel ist das Datenprodukt „Parkraumbelegung Straßenparken Aalen“: Die Zustände von 70 Sensoren werden zu einem gemeinsamen fachlichen Datenobjekt mit Zeitreihen, Geolokation und Auslastungswerten zusammengeführt. Auf dieser Ebene werden Metadaten, Zuständigkeit und Freigabe auf den gesamten nutzbaren Bestand angewendet.
Datenprodukte enthalten fachliche Messwerte und Zustände. Fachliche Bewertungen, KPI-Berechnungen oder weitergehende analytische Verdichtungen gehören nicht in das Datenprodukt, sondern in nachgelagerte Analyse- und Visualisierungsschritte. Eine definierte zeitliche, räumliche oder sachliche Aggregation kann ein Datenprodukt bilden, solange sie den fachlichen Datenbestand strukturiert und nicht bereits eine anwendungsspezifische Bewertung vorwegnimmt.
Woran ein Datenprodukt erkennbar ist
Fachlich abgegrenzt
Der Zweck ist verständlich beschrieben und der Anwendungsbezug eindeutig eingegrenzt.
Quellen nachvollziehbar
Die Herkunft aus einer oder mehreren Datenquellen bleibt eindeutig erkennbar.
Transformation definiert
Bereinigung, Harmonisierung, Filterung, Anreicherung und Aggregation sind produktspezifisch ausgewiesen.
Datenraum zugeordnet
Das Datenprodukt gehört zu genau einem vorgesehenen Datenraum und dessen Zugriffsgrenze.
Zuständigkeit geklärt
Die zuständige Stelle für Inhalt, Änderung und Freigabe ist benannt.
Nutzung beschrieben
Aktualität, Beschreibung, Nutzungsrahmen und verfügbare Schnittstellen sind dokumentiert.
Damit wird das Datenprodukt zur zentralen Einheit für nachvollziehbare Herkunft, kontrollierte Bereitstellung und den praktischen Umgang mit Daten innerhalb eines Datenraums. Eine Tabelle, API-Antwort oder Datei ist nicht allein durch ihre technische Existenz ein Datenprodukt. Ebenso ist ein Dashboard eine Nutzung des Datenprodukts und nicht das Produkt selbst.
Drei Verarbeitungsgrade
Basis-Datenprodukt
Stellt Daten bereinigt und vereinheitlicht bereit, bleibt aber eng an der ursprünglichen Datenquelle.
Erweitertes Datenprodukt
Ergänzt ein Basis-Datenprodukt um Attribute oder Kontextinformationen, beispielsweise aus weiteren Quellen oder Sensorsystemen.
Aggregiertes Datenprodukt
Entsteht durch eine definierte Verdichtung vorhandener Daten und weist diese Transformation ausdrücklich aus.
Die Typisierung dient der groben Einordnung. Die konkrete Ausgestaltung ergibt sich aus den Transformationen des jeweiligen Produkts. Dazu zählen die strukturierte Aufbereitung von Datenpunkten, zeitliche Aggregationen, Filterungen sowie die Anreicherung oder Zusammenführung unterschiedlicher Quellen. Ein Produkt wird deshalb nicht allein durch die Bezeichnung „aggregiert“ oder „erweitert“ nachvollziehbar.
Ein Datenprodukt in vier Schritten festlegen
Fachliche Frage benennen
Zielgruppe, Entscheidung und erwartete Nutzung in einem klaren Satz festhalten.
Inhalt festlegen
Entitäten, Felder, Einheiten, Zeitbezug und Pflichtattribute eindeutig beschreiben.
Erzeugung dokumentieren
Quellen, Transformationen, Qualitätsregeln und Abhängigkeiten nachvollziehbar verbinden.
Zugang freigeben
Datenraum, Schnittstelle, Aktualität und vorgesehene Zugriffsgrenze festlegen und prüfen.
Das Produktprofil
Ein kompaktes Produktprofil verhindert, dass die eigentliche Bedeutung nur im Integrationsflow oder in einem Dashboard verborgen bleibt.
Angaben für ein Datenprodukt
Die Leitfragen sind nach fachlicher Bedeutung gruppiert. Beantworten Sie jede Gruppe gemeinsam mit den Personen, die Quelle, Verarbeitung und spätere Nutzung kennen.
Identität und Zweck
Das Produkt fachlich eindeutig benennen und abgrenzen.
- Name
- Wie lässt sich das Produkt fachlich eindeutig benennen?
- Zweck
- Welche konkrete Nutzung unterstützt das Produkt?
- Verarbeitungsgrad
- Ist es ein Basis-, erweitertes oder aggregiertes Datenprodukt?
- Datenraum
- In welchem fachlichen und technischen Bereich liegt es?
Inhalt und Modell
Struktur, Bedeutung und Verbindlichkeit der Attribute festlegen.
- Zielmodell
- Nach welchem vereinbarten fachlichen Modell ist der Bestand strukturiert?
- Struktur
- Welche Entitäten, Felder, Typen, Einheiten und Beziehungen werden bereitgestellt?
- Pflichtattribute
- Welche Angaben müssen in jeder fachlich gültigen Beobachtung vorhanden sein?
- Optionale Attribute
- Welche zusätzlichen Kontextinformationen werden mitgeführt, sofern sie verfügbar sind?
Herkunft und Qualität
Entstehung, Datenstand und gültige Verarbeitung sichtbar machen.
- Quellen
- Aus welchen Datenquellen oder bestehenden Datenprodukten entsteht es?
- Transformation
- Welche Bereinigung, Harmonisierung, Anreicherung oder Aggregation wird angewendet?
- Aktualität
- Wie häufig wird aktualisiert und woran ist der Datenstand erkennbar?
- Qualitätsregeln
- Wann gilt ein Datensatz als gültig, verspätet oder unvollständig?
Zugang und Verantwortung
Nutzung, Freigabe und Pflege des Produkts verbindlich zuordnen.
- Zugang
- Über welche API, View, Datei oder andere Schnittstelle wird es genutzt?
- Freigabe
- Für welchen Nutzungskontext und welche Zugriffsgruppe ist es vorgesehen?
- Zuständige Stelle
- Wer entscheidet über Inhalt, Änderung und Freigabe?
Ausgefülltes Beispiel
Parkraumbelegung Straßenparken Aalen
Die Zustände von 70 Parkplatzsensoren werden zu einem einheitlichen fachlichen Datenbestand mit Zeitbezug und Geolokation zusammengeführt.
ds_parking_managementAktualisierungAlle fünf MinutenIdentität und Zweck
Ein gemeinsamer fachlicher Bestand für Parkraumbelegung.
- Name
- Parkraumbelegung Straßenparken Aalen
- Zweck
- Sensorzustände für Visualisierung und fachliche Analyse einheitlich bereitstellen.
- Verarbeitungsgrad
- Aggregiertes Datenprodukt
- Datenraum
ds_parking_management
Inhalt und Modell
Stabile Identitäten und einheitliche Parkraumattribute.
- Zielmodell
- Vereinbartes Modell für Parkraumbelegung mit stabilen IDs und einheitlichen Attributen.
- Struktur
- Parkbereich, Beobachtungszeitpunkt, Belegungszustand, Kapazität, Geolokation und Datenstatus.
- Pflichtattribute
- Parkbereich, Beobachtungszeitpunkt und Belegungszustand.
- Optionale Attribute
- Sensortyp und zusätzliche Qualitätskennzeichen, sofern die Quelle sie liefert.
Herkunft und Qualität
70 Sensoren werden kontrolliert zu einem Datenstand verbunden.
- Quellen
- Standardisierte Belegungszustände von 70 Parkplatzsensoren und räumliche Stammdaten.
- Transformation
- Sensorzustände vereinheitlichen, räumlich zuordnen und zu einem gemeinsamen Datenstand zusammenführen.
- Aktualität
- Alle fünf Minuten; der Beobachtungszeitpunkt weist den Datenstand aus.
- Qualitätsregeln
- Datensätze ohne Sensor-ID, Beobachtungszeitpunkt oder gültigen Belegungszustand werden nicht übernommen.
Zugang und Verantwortung
Das Produkt wird kontrolliert für Anwendungen freigegeben.
- Zugang
- Lesender NGSI-LD-Zugang und freigegebene Dashboard-Datenquelle.
- Freigabe
- Interne Nutzung durch die vorgesehenen Fachanwendungen; eine öffentliche Freigabe wird getrennt geprüft.
- Zuständige Stelle
- Im Vorhaben benannte Fachstelle für Parkraummanagement.
Das Datenprodukt stellt Messwerte, Zustände, Zeitbezug und räumlichen Kontext bereit. Ein Dashboard darf daraus Diagramme, Vergleiche und Zeiträume ableiten. Fachliche Bewertungen, anwendungsspezifische KPIs und Darstellungsregeln bleiben dabei bewusst außerhalb des Datenprodukts.
Pflichtattribute und optionale Attribute trennen
Pflichtattribute definieren die minimal erforderliche Datenstruktur des Produkts und müssen für jede fachlich gültige Beobachtung vorhanden sein. Fehlen sie, erfüllt der Datensatz den vereinbarten Produktvertrag nicht. Beim Beispiel wären Beobachtungszeitpunkt, Parkbereich und Belegungszustand typische Pflichtattribute.
Optionale Attribute ergänzen kontextuelle Informationen und ermöglichen eine vertiefte Analyse oder fachliche Einordnung. Nicht jede Quelle muss sie liefern können, etwa Sensortyp, zusätzliche Qualitätskennzeichen oder eine Beschreibung des Parkbereichs. Ihre Abwesenheit darf nicht stillschweigend wie der Wert 0 oder false behandelt werden.
Dokumentieren Sie daher für jedes Attribut:
- fachliche Bedeutung und technischer Name,
- Datentyp und Einheit,
- Pflicht oder optional,
- zulässige Werte beziehungsweise Wertebereiche,
- Herkunft oder Berechnungsregel und
- Verhalten bei fehlenden oder ungültigen Werten.
Governance und Nachvollziehbarkeit
Für ein Datenprodukt müssen Herkunft und Verarbeitung nachvollziehbar bleiben. Führen Sie deshalb mindestens:
- Quellsystem oder Ursprung der Daten,
- Zeitpunkt der letzten Aktualisierung,
- verwendetes Zielmodell,
- wesentliche Transformations- und Harmonisierungsschritte,
- zuständige Stelle beziehungsweise eine etablierte Produktverantwortung sowie
- Freigabestatus und Nutzungskontext.
Auf dieser Ebene kann ein Datenprodukt kontrolliert für interne Nutzung, APIs, Dashboards oder Open Data freigegeben werden. Die konkrete Oberfläche oder Visualisierung bleibt eine nachgelagerte Nutzung desselben Produkts.
Sensorzustände
Ursprüngliche Meldungen mit Quellkennung und Zeitbezug.
Standardisierte Belegung
Einheitliche IDs, Typen und Zeitangaben.
Parkbereich zuordnen
Stammdaten und räumlicher Kontext ergänzen.
Gesamtbild erzeugen
Sensorzustände räumlich und zeitlich zu einem einheitlichen Datenstand verbinden.
Produkt freigeben
Datenraum und Schnittstelle kontrolliert zugänglich machen.
Die Dokumentation muss nicht jede technische Node oder SQL-Zeile wiederholen. Sie muss aber erkennen lassen, welche fachlich wirksamen Schritte zwischen Quelle und Produkt liegen und wo deren ausführbare Definition versioniert ist.
Vor der Freigabe prüfen
- Name und Zweck sind ohne Kenntnis des Projekts verständlich.
- Datenraum, Zielgruppe und vorgesehener Zugang sind festgelegt.
- Pflichtattribute, optionale Attribute, Typen und Einheiten sind beschrieben.
- Quellen und wesentliche Transformationen sind nachvollziehbar.
- Aktualisierungsrhythmus und sichtbarer Datenstand sind definiert.
- Ein bekannter Beispieldatensatz lässt sich über den vorgesehenen Zugang prüfen.
- Nicht vorgesehene Daten und Aktionen bleiben gesperrt.
- Zuständige Stelle und Änderungsweg sind dokumentiert.
Ändert sich die Bedeutung eines Felds, eine Berechnungsregel oder der Nutzungsrahmen, genügt eine Anpassung des Flows allein nicht. Aktualisieren und prüfen Sie Produktprofil, Datenmodell, ausführbare Transformation und abhängige Schnittstellen gemeinsam.