IBM Cognos Analytics setzt in der Datenmodellierung voll auf Datenmodule. Diese sind aktuell (bis Version 12.0.4) für relationale Modellierung konzipiert. In unserem CUG Talk am 20.2.205 haben wir uns hierzu ausgetauscht.
Wer schonmal testen und sich so die Frage selbs beantworten möchte: Baut euch eine Kreuztabelle auf Basis eines Datenmoduls in dem in den Spalten die Jahre angezeigt werden. Jetzt möchtet ihr zwei Jahre auswählen und die Differenz berechnen:
Aber fangen wir mal mit ein paar grundlegenden Informationen an:
In Cognos Analytics können sowohl relationale als auch dimensionale Modelle erstellt werden, je nach verwendetem Werkzeug:
1. Datenmodule
- Relational: Ja
- Dimensional: Eingeschränkt
- TM1-Würfel: Ja ? (Direkte Anbindung möglich)
Datenmodule sind primär für relationale Modellierung ausgelegt, unterstützen aber auch TM1-Würfel als Datenquelle. Dabei lassen sich TM1-Hierarchien und -Measures direkt nutzen. Allerdings bietet dieses Modell weniger Anpassungsmöglichkeiten als ein OLAP-optimiertes Modell.
2. Framework Manager (FM)
- Relational: Ja
- Dimensional: Ja
- TM1-Würfel: ? (Nicht direkt unterstützt)
Framework Manager ermöglicht sowohl relationale als auch dimensionale Modelle:
- Relational: Klassisches SQL-basiertes Modell mit Tabellen und Joins.
- Dimensional: Erstellung eines dimensionally modeled relational (DMR) Modells, das sich wie ein Cube verhält.
Allerdings unterstützt FM keine direkte Anbindung an TM1-Würfel. TM1-Daten müssten erst in eine relationale Struktur exportiert werden.
3. Dynamic Cubes (Cube Designer)
- Relational: (Nicht unterstützt)
- Dimensional: Ja
- TM1-Würfel: (Nicht direkt unterstützt)
Dynamic Cubes sind für echte OLAP-Cubes optimiert und nutzen In-Memory-Technologie für schnelle Aggregationen. Sie bieten eine leistungsstarke Alternative zu TM1, unterstützen aber keine direkte Anbindung an TM1-Würfel.
4. TM1-Würfel (Planning Analytics)
- Relational: (Nicht unterstützt)
- Dimensional: Ja
- TM1-Würfel: Ja
TM1-Würfel (Planning Analytics) sind von Natur aus dimensionale Datenmodelle und bieten flexible Hierarchien, Berechnungen und Aggregationen. Sie können direkt in Cognos Analytics Reports und Dashboards eingebunden werden.
Zusammenfassung:
| Tool | Relational | Dimensional | TM1-Würfel als Quelle |
|---|---|---|---|
| Datenmodule | Ja | Eingeschränkt (benutzerdefinierte Navigationspfade) | Ja |
| Framework Manager | Ja | Ja (DMR möglich) | Nein |
| Dynamic Cubes | Nein | Ja (echte OLAP-Cubes) | Nein |
| TM1-Würfel | Nein | Ja | Ja (Native Datenquelle) |
Einsatzempfehlung:
- Datenmodule: Für agile Modellierung mit relationalen Daten oder direkter Anbindung an TM1-Würfel.
- Framework Manager: Für komplexe Unternehmensmodelle, wenn keine direkte TM1-Integration erforderlich ist.
- Dynamic Cubes: Für große relationale Datenmengen, wenn OLAP-Funktionalität benötigt wird.
- TM1-Würfel: Für flexible OLAP-Analysen mit direkter Integration in Cognos Analytics.
Wie schaut es für die Anwender aus? Wie unterscheiden sich Analysen und Reporting auf relationalen Modellen im Vergleich zu dimensionalen Modellen?
Beim Erstellen von Reports und Dashboards in Cognos Analytics gibt es wesentliche Unterschiede zwischen relationalen und dimensionalen Datenquellen. Die Wahl des Modells beeinflusst Performance, Flexibilität und Komplexität.
1. Relationale Datenquellen (SQL-basiert)
Typische Quellen: Datenmodule, Framework Manager (relationales Modell), relationale DBs (z. B. DB2, SQL Server, Oracle).
Vorteile:
Flexibilität bei Abfragen
- Beliebige SQL-gestützte Abfragen möglich.
- Einfache Kombination unterschiedlicher Tabellen durch Joins.
Gut für detaillierte, transaktionsorientierte Berichte
- Ideal für Listenberichte mit Detaildaten (z. B. Rechnungen, Auftragslisten).
Keine vordefinierten Hierarchien notwendig
- Benutzer können eigene Gruppierungen oder Aggregationen erstellen.
Gut für Ad-hoc-Analysen mit dynamischen Abfragen
- Nutzer können frei filtern und kombinieren.
Nachteile:
Langsame Performance bei großen Datenmengen
- Aggregationen werden zur Laufzeit berechnet, was zu langen Ladezeiten führt.
- Jeder Bericht erzeugt eine SQL-Abfrage, die die Datenbank belastet.
Komplexe Abfragen erfordern tiefes SQL-Verständnis
- Berechnungen müssen oft manuell in Query Subjects oder berechneten Spalten umgesetzt werden.
Drill-Down-Funktionalität ist eingeschränkt
- Keine vordefinierten Hierarchien oder automatischen Aggregationen.
- Benutzer müssen Drill-Downs manuell über Filter oder Berechnungen definieren.
2. Dimensionale Datenquellen (OLAP, Cubes, DMR, TM1)
Typische Quellen: Dynamic Cubes, TM1-Würfel, DMR-Modelle aus Framework Manager.
Vorteile:
Schnelle Performance durch vorkalkulierte Aggregationen
- Summen, Durchschnittswerte, Min/Max-Werte sind vorgefertigt und müssen nicht zur Laufzeit berechnet werden.
- OLAP-Datenquellen sind speziell für große Datenmengen optimiert.
Intelligente Drill-Down- und Roll-Up-Funktionalität
- Hierarchien und Ebenen ermöglichen automatische Drill-Downs in Dashboards und Berichten.
- Benutzer können auf untere oder höhere Ebenen wechseln, ohne manuell zu filtern.
Gut für Dashboards & Self-Service-Analysen
- Interaktive Berichte können schnell aktualisiert werden.
- Nutzer brauchen kein SQL, sondern können sich durch Drag & Drop in den Daten bewegen.
Zeitdimensionen und Vergleiche einfacher umsetzbar
- OLAP-Datenquellen haben oft vorgefertigte Zeitdimensionen für Year-over-Year oder Month-over-Month-Vergleiche.
Nachteile:
Weniger flexibel für Ad-hoc-Analysen
- Feste Hierarchien und Aggregationen: Wenn eine benötigte Aggregation nicht vorhanden ist, muss das Modell angepasst werden.
- Kann nur innerhalb der vordefinierten Strukturen genutzt werden.
Höherer Modellierungsaufwand
- Hierarchien und Aggregationen müssen vorab definiert werden.
- Dynamic Cubes oder TM1-Würfel benötigen Zeit für Design, Aufbau und Wartung.
Nicht optimal für Detailberichte mit einzelnen Transaktionen
- Dimensionale Modelle sind für Analysen und Trends gedacht, nicht für detaillierte Listenauswertungen.
- Wenn eine OLAP-Datenquelle zu viele Detailzeilen enthält, kann das die Performance beeinträchtigen.
Zusammenfassung: Relationale vs. Dimensionale Datenquellen
| Kriterium | Relationale Modelle (SQL) | Dimensionale Modelle (OLAP, TM1, DMR) |
|---|---|---|
| Performance | Langsam bei Aggregationen | Schnell durch vorkalkulierte Werte |
| Flexibilität | Sehr hoch (Ad-hoc-Analysen) | Eingeschränkter, basiert auf vordefinierten Hierarchien |
| Drill-Down | Manuell erforderlich | Automatisch durch vordefinierte Hierarchien |
| Aggregation | Zur Laufzeit berechnet | Bereits vorkalkuliert |
| Komplexität der Modellierung | Gering (SQL-basierte Abfragen) | Hoch (Cube- oder TM1-Modell erforderlich) |
| Optimale Nutzung | Detaillierte Listenberichte, operative Analysen | Interaktive Dashboards, analytische Berichte, schnelle Datenanalyse |
| SQL-Kenntnisse nötig? | Ja (zum Erstellen komplexer Abfragen) | Nein (vorgefertigte Strukturen) |
Einsatzempfehlung:
- Relationale Datenquellen: Für operative Berichte, Listenansichten, Detailanalysen mit vielen Transaktionsdaten.
- Dimensionale Datenquellen: Für Dashboards, interaktive Berichte und analytische Auswertungen mit Drill-Downs und schnellen Aggregationen.
Wir halten fest: Gerade Ad-Hoc-Analysen und Reporting ist oft mit einem dimensionalen Modell einfacher.
Eine Kombination beider Modelle kann sinnvoll sein – z. B. relational für Transaktionsdetails und dimensional für Analyse-Dashboards.
