Denodo-Pilot: Quellen, Sichten, Namensgebung und Datenvertrag

Quellen- und Prüfstand: 24.10.2026 · Denodo Platform 9.5. Tatsächliche Updates, Treiber, Bundle und Deployment mit der passenden Herstellerhilfe abgleichen. Menüs und Funktionen können sich ändern. Redaktionelle Pilotanleitung; kein ausgeführter Kundensystemtest.

Was die Sichten voneinander trennt

Eine Basissicht bildet importierte Quellmetadaten ab. Eine abgeleitete Sicht verbindet oder verändert Daten über eine definierte Abfrage. Eine Interface View stellt eine vereinbarte Schnittstelle bereit und kann Implementierungsdetails von Konsumenten entkoppeln; sie ersetzt keine Rechteprüfung. Für den Pilot verwenden wir die Projektkonvention bv_ für quellnahe Basissichten, iv_ für Integration und cv_ für Konsumsichten. Diese Präfixe sind keine Denodo-Pflicht und weisen keine Rechte zu.

Namen sollen Umgebung und Aufgabe erkennbar machen. Beispiel: Datenbank pilot, Ordner sales, Sichten bv_orders, bv_customers, iv_order_customer und cv_sales_monthly. Das Kürzel sales bedeutet Vertrieb. Ein fachlich deutschsprachiges Team kann ebenso vertrieb vereinbaren. Groß-/Kleinschreibung und Quoting mit der vorhandenen Projektkonvention abstimmen.

Synthetische Eingangsdaten

Keine echten Kontakte verwenden. Die folgenden beiden Tabellen in der genehmigten Testquelle bereitstellen, beispielsweise als freigegebene Datenbanktabellen oder über einen unterstützten Dateiadapter.

Soll: Nord 150, Süd 30, insgesamt 180. Die Bestellung ist die Zeileneinheit der quellnahen Bestellsicht. Die Ausgabe der Konsumsicht hat eine Zeile je Monat und Region.

Einrichtung und Kontrolle

1. Tatsächliche Denodo-, Treiber- und Bundle-Stände im Steckbrief erfassen. Unterstützten Adapter und Voraussetzungen anhand der 9.5-Hilfe und des vorhandenen Updates prüfen. Quellen-ID und Netzwerkfreigabe im Formular verknüpfen.
2. In Design Studio die erlaubte Datenquelle mit geschützter Credential-Referenz konfigurieren. Verbindungsprüfung unter der tatsächlich geplanten Quellidentität durchführen. Ein erfolgreicher Test belegt noch nicht alle späteren Objektprivilegien.
3. Nur die beiden freigegebenen Testobjekte importieren. Spaltennamen, numerischen Betragstyp, Schlüssel, Zeichensätze und NULL-Verhalten mit der Quelle vergleichen. Keine automatische Schlüsselerkennung ungeprüft übernehmen.
4. Integration über customer_id erstellen. Vor der Aggregation Anzahl der Bestellzeilen und Gesamtsumme vergleichen. Drei Eingaben dürfen durch den Join nicht zu sechs werden. Eine doppelte Kundenzeile als separate Fehlerprobe hinzufügen und anschließend wieder entfernen.
5. In der Konsumsicht nach Monat und Region aggregieren. Nur month_key, region und revenue veröffentlichen. Kundenkennungen und Kontaktfelder gehören für diesen Auftrag nicht zur Ausgabe.
6. Mit Konsumentenrolle prüfen; einen zweiten Test mit einer Rolle ohne Ausführungsrecht durchführen. Metadaten-Sichtbarkeit und Datennutzung getrennt protokollieren. Testwerte und Beobachtungen im Abnahmeformular erfassen.

Prüf-Abfrage über eine genehmigte Verbindung

Die Sicht muss vorher gemäß genehmigtem Projektentwurf existieren. Dieser Ausschnitt erstellt keine Quelle oder Sicht und vergibt keine Rechte.

-- Nur die vereinbarte Konsumsicht prüfen; Sichtname bei Bedarf anpassen.
SELECT month_key, region, revenue
FROM cv_sales_monthly
ORDER BY month_key, region;

Die fachliche Vereinbarung im Beispiel

Die folgende Tabelle erklärt den konkreten Beispielfall. Eigene Angaben erfasst du einmal in der Projektwerkstatt.

Grenze: Drei richtige Beispielwerte belegen keine allgemeine Datenqualität. NULL-Kunden, fehlende Zuordnungen, Stornierungen, Währung und historische Regionswechsel müssen aus dem tatsächlichen Kundenbedarf ergänzt werden.

Herstellerquellen

• Denodo 9.5: neue Funktionen
• Administration
• Globale Sicherheitsregeln
• Cache und Materialisierung
• LDAP-Anmeldung
• Data Marketplace: Umbenennung