COGNOS(R) 8

COGNOS (R) 8 

FRAMEWORK MANAGER 

Richtlinien für die Erstellung von Metadatenmodellen 

01-08-2005 

Framework Manager 

8.1 

Cognos(R) 8 Business Intelligence Readme 

RICHTLINIEN FÜR DIE ERSTELLUNG VON METADATENMODELLEN 

RICHTLINIEN FÜR DIE 

ERSTELLUNG VON 

METADATENMODELLEN 

THE NEXT LEVEL OF PERFORMANCE TM

Produktinformationen 

Dieses Dokument bezieht sich auf Cognos (R) 

8 Version 8.1 und möglicherweise auch auf zukünftige Versionen. Jüngere Versionen dieses 

Dokuments finden Sie auf der Website des Cognos Support (http://support.cognos.com). 

Copyright 

Copyright (C) 2005 Cognos Incorporated 

Portions of Cognos(R) software products are protected by one or more of the following U.S. Patents: 6,609,123 B1; 6,611,838 B1; 6,662,188 

B1; 6,728,697 B2; 6,741,982 B2; 6,763,520 B1; 6,768,995 B2; 6,782,378 B2; 6,847,973 B2; 6,907,428 B2; 6,853,375 B2. 

Cognos und das Cognos Logo sind Marken von Cognos Incorporated in the Vereinigten Staaten und/oder anderen Ländern. Alle anderen 

genannten Produktnamen sind Marken oder eingetragenen Marken der jeweiligen Firmen. 

Wir haben uns bemüht, sicherzustellen, dass die Informationen in diesem Dokument so genau und vollständig wie möglich sind; trotzdem ist 

nicht auszuschließen, dass vereinzelt Druckfehler oder inhaltliche Ungenauigkeiten auftreten können. Cognos übernimmt keine Verantwortung 

für Verluste, die durch die Verwendung der in diesem Dokument enthaltenen Informationen entstehen. 

Dieses Dokument zeigt das Veröffentlichungsdatum. Bei den in diesem Dokument enthaltenen Informationen sind Änderungen vorbehalten. 

Alle Veränderungen oder Verbesserungen der Software oder des Dokuments werden in zukünftigen Ausgaben dokumentiert. 

Diese Software/dieses Dokument enthält urheberrechtlich geschützte Informationen von Cognos Incorporated. Alle Rechte vorbehalten. Die 

Rückentwicklung dieser Software ist nicht gestattet. Diese Software/dieses Dokument oder Teile davon dürfen ohne die vorherige ausdrückliche, 

schriftliche Zustimmung von Cognos Incorporated nicht kopiert, reproduziert, in einem Datenabrufsystem gespeichert, in einer beliebigen 

Form und mit beliebigen Hilfsmitteln übertragen oder in eine andere Sprache übersetzt werden.

Inhaltsverzeichnis 

Kapitel 1: Richtlinien für die Erstellung von Metadatenmodellen 5 

Szenarien 5 

Neue Objekte in Cognos 8 6 

Determinanten 6 

Reguläre Dimension 7 

Kennzahldimension 7 

Bereichsbeziehung 7 

Dimensionales Modellieren relationaler Datenquellen 7 

Überprüfen importierter Metadaten 8 

Vereinfachen von Modellen anhand von dimensionalen Konzepten 11 

Klären nicht eindeutiger Beziehungen 13 

Definieren von Dimensionen und Determinanten 17 

Erstellen von Sternschemagruppen 24 

Aktualisieren von Best-Practices-Modellen von ReportNet 1.x 25 

Überprüfen des vorhandenen Modells 26 

Aktualisieren des Modells 26 

Kapitel 2: Das von Cognos 8 generierte SQL 33 

Übersicht über dimensionale Abfragen bei der Verwendung von Best Practices 33 

Abfrage einzelner Fakten 33 

Abfrage mehrerer Fakten und mehrerer Ebenen von angepassten Dimensionen 34 

Modellieren von 1-n-Beziehungen als 1-1-Beziehungen 36 

Abfrage mehrerer Fakten und mehrerer Ebenen bei nicht angepassten Dimensionen 37 

Auflösen uneindeutig identifizierter Dimensionen und Fakten 40 

Auflösen von Abfragen, die nicht geteilt werden sollten 40 

Auflösen von Abfragen, die an der falschen Stelle geteilt sind 43 

Index 49 

Richtlinien für die Erstellung von Metadatenmodellen 3

4 Framework Manager

Kapitel 1: Richtlinien für die Erstellung von Metadatenmodellen 

Szenarien 

Framework Manager ist ein Tool zur Erstellung von Metadatenmodellen. Ein Modell ist eine 

unternehmensspezifische Darstellung von Informationen in einer oder mehreren Datenquellen. 

Wenn Sie dieser unternehmensspezifischen Darstellung Zugriffsschutz, mehrsprachige Metadaten 

und dimensionale Metadaten hinzufügen, kann ein Modell die Anforderungen vieler internationaler 

Benutzergruppen an Berichterstellungen, Ad-hoc-Abfragen und Analysen erfüllen. 

Ein wichtiges Ziel bei der Vorbereitung von Metadaten für Business Intelligence ist die Nutzung 

vorhandener Metadaten während des Hinzufügens von Werten, damit Ihre Benutzer die notwendigen 

Informationen finden können. 

Cognos 8 aktiviert Business Intelligence für normalisierte und entnormalisierte relationale Datenquellen 

sowie eine Vielzahl von OLAP-Datenquellen. 

Dieses Dokument behandelt grundlegende Konzepte für die Erstellung von Modellen von relationalen 

Datenquellen in Framework Manager und enthält Herstellerempfehlungen zur Erstellung 

von Metadatenmodellen für die Verwendung bei Berichterstellungen und Analysen in Unternehmen. 

Mit Framework Manager können Sie alle relationalen Datenquellen dimensional modellieren. 

Obwohl ein dimensionales Schema nicht zwangsläufig in Cognos 8 verwendet werden muss, 

wurden viele Funktionen hinzugefügt, damit Sie die Vorzüge dimensionaler Schemen besser nutzen 

und eine logische dimensionale Ansicht nicht dimensionaler Schemen erstellen können. 

Die Struktur der Themen in diesem Dokument richtet sich nach den unterschiedlichen Szenarien. 

Verwenden Sie das Thema, das mit Ihren Zielen übereinstimmt. 

Dimensionales Modellieren relationaler Datenquellen 

Das dimensionale Modellieren relationaler Datenquellen ist eine Funktion, die von Cognos 8 Framework 

Manager bereitgestellt wird. In ReportNet 1.x konnten Abfragen mit mehreren Fakten 

aktiviert und Doppelzählungen vermieden werden. Cognos 8 wiederum führt Funktionen ein, die 

ausdrücklich für das dimensionale Modellieren konzipiert wurden. Jetzt ist es möglich, Modelle 

von Dimensionen mit Hierarchien und Ebenen zu erstellen und Fakten mit mehreren Kennzahlen 

zu besitzen. Anschließend können Sie Beziehungen zwischen Dimensionen und Kennzahlen herstellen, 

indem Sie den Bereich im Modell verwenden. 

Weitere Informationen finden Sie unter "Dimensionales Modellieren relationaler 

Datenquellen" (S. 7). 

Aktualisieren von Best-Practices-Modellen von ReportNet 1.x 

Wenn Ihr Modell anhand von Best Practices (optimalen Verfahren) in ReportNet 1.x erstellt 

wurde, kann ein Großteil der Aktualisierung auf die neuen Funktionen von Cognos 8 in Framework 

Manager durchgeführt werden. Der Befehl Verify Model wurde erweitert, damit Sie Objekte 

im Modell auswählen und automatisch in Cognos 8-Dimensionen konvertieren können. Dadurch 

können die Metadaten genutzt werden, die im vorhandenen Modell bereitstehen. Sie können sich 

weiterhin mit Abfragesubjekten beschäftigen und Dimensionsinformationen in ReportNet 1.x in 

Determinanten übersetzen lassen, oder Sie können mit den Dimensionen fortfahren. Wenn Sie mit 

den Dimensionen fortfahren, werden die vorhandenen Dimensionsinformationen in Ihrem Modell 

zum Erstellen der ersten Hierarchie und der ersten Ebenen verwendet. 

Weitere Informationen finden Sie unter "Aktualisieren von Best-Practices-Modellen von 

ReportNet 1.x" (S. 25). 



Neue Objekte in Cognos 8 

Determinanten 

6 Framework Manager 

In ReportNet 1.x wurden für Dimensionsinformationen die Konzepte von Eindeutigkeit und 

Dimensionshierarchien kombiniert. In Cognos 8 wurde das Konzept der Dimensionsinformationen 

zur Kontrolle von Eindeutigkeit und Granularität aufgeteilt. Diese Kontrolle ist für Abfragesubjekte 

erforderlich, die auf Relationen basieren, sowie für explizit adressierte Konzepte von 

Hierarchien und Ebenen für dimensionale Objekte, selbst auf relationalen Quellen. 

Beim Überprüfen von Dimensionsinformationen müssen Sie verstehen, wie die Dimensionsinformationen 

auf das Abfragesubjekt angewendet werden und wie das Abfragesubjekt im Cognos 8- 

Modell verwendet wird. 

Folgende neue Objekte wurden in Cognos 8 eingeführt: 

• Determinanten für Abfragesubjekte 

• reguläre Dimensionen 

• Kennzahldimensionen 

• Bereichsbeziehungen 

Determinanten sind nicht mit Ebenen und Hierarchien identisch, können aber eng mit einer einzelnen 

Hierarchie verbunden sein. Die Abfragen-Engine wertet Determinanten von der ersten bis zur 

letzten aus. Es können ein oder mehrere Determinanten angegeben werden. 

Wenn eine reguläre Modelldimension auf einem Abfragesubjekt mit angegebenen Determinanten 

basiert, wird empfohlen, dass 

• jeder im Abfragesubjekt vorhandenen Determinante eine Ebene entspricht 

• die Reihenfolge der Ebenen in der Hierarchie die Reihenfolge der Determinanten widerspiegelt 

Das führt zu einem einheitlichen Modell und erleichtert das Aktualisieren des Modells in zukünftigen 

Versionen von Cognos-Produkten. 

Eine Determinante ist ein Satz von Datenbankspalten (Abfrageelementen), der für die eindeutige 

Identifikation eines Datensatzes verwendet werden kann. Determinanten werden auf der Grundlage 

von Schlüssel- und Indexinformationen in der Datenquelle importiert. Es wird empfohlen, die 

importierten Determinanten immer zu überprüfen. 

Mit Determinanten können Sie folgende Aktionen durchführen: 

• Hinzufügen von Informationen über Funktionsabhängigkeiten zwischen den Spalten, um 

Doppelzählungen zu vermeiden. 

• Festlegen der Granularität von entnormalisierten Abfragesubjekten, um bei der Verwendung 

von Modelldimensionen Gruppierungen und Doppelzählungen zu steuern. 

Z. B. stellen einige Fakten eine Verbindung zur Zeit auf der Grundlage von Monaten, andere 

auf der Grundlage von Tagen her. Legen Sie die Zeitdeterminanten fest, um die Funktionsabhängigkeit 

zwischen Monat und Tag als Minimum klar zu erfassen. So können Sie die Doppelzählung 

dieser Fakten verhindern, die eine Verbindung zum Monatsschlüssel herstellen. 

• Eindeutiges Identifizieren der Datenzeile beim Abrufen von Textblob-Daten aus der Datenquelle. 

• Überschreiben der aus der Datenquelle importierten Determinanten, bei denen ein Konflikt 

mit den Beziehungen besteht, die für die Berichterstellung erstellt wurden. 

So sind beispielsweise Determinanten zu zwei Abfragesubjekten für mehrere Spalten vorhanden, 

aber die Beziehung zwischen den Abfragesubjekten verwendet nur eine Untermenge dieser 

Spalten. Ändern Sie die Determinanteninformationen des Abfragesubjekts, wenn es die 

zusätzlichen Spalten in der Beziehung nicht verwenden kann. 

Weitere Informationen finden Sie unter "Definieren von Dimensionen und 

Determinanten" (S. 17).

Reguläre Dimension 

Kennzahldimension 

Bereichsbeziehung 


Eine reguläre Dimension enthält beschreibende und Unternehmensschlüsselinformationen und 

strukturiert die Informationen in einer Hierarchie von der obersten Granularitätsebene zur untersten. 

Sie hat in der Regel mehrere Ebenen und kann über mehrere Schlüsselsegmente für die Definition 

einer Ebene verfügen. Außerdem kann sie mehrere Hierarchien haben. 

Für eine reguläre Dimension der Datenquelle kann nur eine einzige Hierarchie definiert werden. 

Bei angepassten Dimensionen ist die Abfrage mehrerer Fakten möglich. 

Eine Kennzahldimension ist eine Zusammenstellung von Fakten. 

Sie können für ein oder mehrere Abfragesubjekte mit einer gültigen Beziehung zueinander eine 

Kennzahldimension erstellen. 

Bereichsbeziehungen bestehen zwischen Kennzahldimensionen und regulären Dimensionen und 

definieren die Ebene, auf der die Kennzahlen für die Berichterstellung zur Verfügung stehen. 

Bereichsbeziehungen bestimmen die Berichterstellungsgranularität der regulären Dimension für 

eine bestimmte Kennzahldimension. 

Bereichsbeziehungen sind zwischen Kennzahlen und Dimensionen bei der Berichterstellung obligatorisch. 

Wenn keine Bereichsbeziehung vorhanden ist, führt dies zur Laufzeit zu einem Fehler. 

Bereichsbeziehungen dienen der Berichterstellung. Sie sind nicht mit Verbindungen identisch und 

beeinflussen nicht die Where-Klausel. 

Mit Bereichsbeziehungen können Sie die reguläre Dimension in die Sternschemagruppe integrieren 

oder daraus ausschließen. 

Es können keine Verknüpfungen für Bereichsbeziehungen erstellt werden. Bereichsbeziehungen 

können nur zwischen regulären Dimensionen und Kennzahldimensionen vorhanden sein. Außerdem 

können Bereichsbeziehungen für Verknüpfungen zu Dimensionsobjekten erstellt werden. 

Wenn Verknüpfungen zu Dimensionen verwendet werden, wird der Bereich vom Bereich des 

ursprünglichen Objekts abgeleitet, sofern der Bereich nicht ausdrücklich für die Verknüpfungen 

definiert wurde. 

Dimensionales Modellieren relationaler Datenquellen 

Sie müssen eine relationale Datenquelle dimensional modellieren, wenn Sie eine der folgenden 

Aktionen durchführen möchten: 

• Verwenden von Analysis Studio 

• Aktivieren von Drillfunktionen in Berichten 

• Verbessern der Steuermöglichkeiten der Abfragegranularität 

• Zugreifen auf Mitgliederfunktionen in den Berichterstellungstools 

Es wird empfohlen, bei der dimensionalen Modellierung von relationalen Datenquellen dem folgenden 

Workflow zu folgen: 

❑ Importieren Sie die Metadaten. 

❑ Überprüfen Sie die importierten Metadaten (S. 8). 

❑ Passen Sie die Metadaten an. 

❑ Vereinfachen Sie das Modell anhand von dimensionalen Konzepten (S. 11). 

❑ Klären Sie nicht eindeutige Beziehungen (S. 13). 

❑ Definieren Sie Dimensionen und Determinanten (S. 17). 

❑ Strukturieren Sie das Modell durch Erstellen von unternehmensspezifischen Ansichten. 

❑ Erstellen Sie Sternschemagruppen (S. 24). 




❑ Richten Sie Zugriffsschutz ein. 

❑ Erstellen Sie Packages, und publizieren Sie Metadaten. 

Informationen zu den hier nicht behandelten Themen finden Sie unter "Designing a Project", 

"Preparing Relational Metadata for Use in Reports" und "Making Metadata Available to Report 

Authors" im Framework Manager User Guide. 

Alle Beispiele in diesem Dokument verwenden die Datenbankansicht des normalisierten Modells 

"gosales_goretailers" oder die Importansicht des Modells "go_data_warehouse", die in den 

Cognos 8-Beispielen enthalten sind. 

Überprüfen importierter Metadaten 

Nach dem Importieren von Metadaten müssen Sie die importierten Metadaten in den folgenden 

Bereichen überprüfen: 

• Beziehungen und Kardinalität 

• Eigenschaft Usage für Abfrageelemente 

• Eigenschaft Regular Aggregate für Abfrageelemente 

Hier werden Beziehungen in Verbindung mit Kardinalität diskutiert. Informationen zu den Eigenschaften 

Usage und Regular Aggregate finden Sie unter Modifying the Properties of Query Items 

im User Guide von Framework Manager. 

Kardinalität wird mit Dimensionen kombiniert, um die Art der Generierung von Abfragen zu steuern. 

Dadurch können Sie 

• Doppelzählungen vermeiden 

• Schleifenverbindungen automatisch auflösen 

• Faktübergreifende Abfragen für Berichterstellung und Analyse aktivieren 

Sie können Modelldimensionen und Datenquellendimensionen erstellen. Modelldimensionen werden 

auf der Grundlage von Abfragesubjekten erstellt, die Determinanten und Beziehungen mit 

Kardinalität verwenden. Datenquellendimensionen enthalten ihr eigenes SQL und verwenden 

Hierarchie- und Ebeneninformationen sowie Beziehungen mit Kardinalität, um die Abfragegranulariät 

zu definieren. 

Die Kardinalität beeinflusst das Abfrageverhalten, indem sie es ermöglicht, dass Regeln bezüglich 

der Granularität von Daten, die von einem einzelnen Objekt zurückgegeben werden, und der Auswirkungen 

von Verbindungen zwischen Objekten angewendet werden. Die in der Beziehung zwischen 

Abfragesubjekten oder Dimensionen festgelegte Kardinalität gibt an, wie und wann 

Cognos 8 zusammengefügte Abfragen generiert. Zusammengefügte Abfragen werden für die 

Abfrage mehrerer Fakten in angepassten Dimensionen und verschiedenen Granularitätsebenen 

benötigt. 

Erkennen von Kardinalitäten aus Datenquellen 

Beim Importieren aus einer relationalen Datenquelle wird Kardinalität auf der Grundlage einer 

Reihe von Regeln erkannt, die Sie festlegen. Die verfügbaren Optionen sind 

• Verwendung von Primär- und Fremdschlüsseln 

• Verwendung von übereinstimmenden Abfrageelementnamen, die Spalten mit eindeutigem 

Index darstellen 

• Verwendung von übereinstimmenden Abfrageelementnamen 

Am häufigsten werden Primär- und Fremdschlüssel sowie übereinstimmende Abfrageelemente verwendet, 

die Spalten mit eindeutigem Index darstellen. Die Informationen dienen dem Festlegen 

einiger Eigenschaften der Abfrageelemente sowie dem Erstellen von Beziehungen.


Wenn Sie die importierten Index- und Schlüsselinformationen anzeigen möchten, klicken Sie mit 

der rechten Maustaste auf ein Abfragesubjekt oder eine reguläre Dimension und anschließend auf 

Edit Definition. Bei einem Abfragesubjekt können Sie die Informationen in der Registerkarte 

Determinants ändern. Alle regulären Dimensionen sind zunächst Abfragesubjekte. Wenn Sie ein 

Abfragesubjekt in eine reguläre Dimension konvertiert haben, beachten Sie, dass die Determinanteninformationen 

für das Abfragesubjekt als Ausgangspunkt eingesetzt werden, um die Ebenen 

einer einzelnen Hierarchie zu definieren. Es wird empfohlen, die Ebenen und Schlüssel zu prüfen, 

die in der Hierarchie der Dimension erstellt wurden. 

Optionale Beziehungen, vollständige offene Verbindungen und n-zu-n-Beziehungen können aus 

Ihrer Datenquelle importiert werden. Framework Manager führt sie als Abfragen aus. 

Reflexive Beziehungen können aus Ihrer Datenquelle importiert werden und werden im Modell 

angezeigt. Framework Manager führt sie jedoch nicht als Abfragen aus. Auch wenn Sie die Metadaten 

anzeigen können, die die reflexive Beziehung definieren, können Sie eine reflexive Beziehung 

in Framework Manager nicht bearbeiten. 

Weitere Informationen finden Sie unter "Reflexive und rekursive Beziehungen" (S. 16). 

Kardinalitäten in generierten Abfragen 

Framework Manager unterstützt sowohl die minimale/maximale Kardinalität als auch die obligatorische/optionale 

Kardinalität. 

0:1 - 0 ist die minimale Kardinalität, 1 ist die maximale Kardinalität 

1:n - 1 ist die minimale Kardinalität, n ist die maximale Kardinalität 

Eine Beziehung mit der Kardinalität 1-n kann angegeben werden als 1:1 bis 1:n, wenn die maximalen 

Kardinalitäten gelesen werden. Die minimale Kardinalität von 1 ist für optionale Daten auf 

0 festgelegt. Daher kann die 1-n-Beziehung auch als 0:1 bis 0:n, 0:1 bis 1:n oder 1:1 bis 0:n 

angegeben werden. 

Die wichtigsten Regeln für die Verwendung von Kardinalitäten lauten wie folgt: 

• Kardinalität wird im Rahmen einer Abfrage verwendet, d. h., es werden nur die Kardinalitäten 

von explizit in die Abfrage integrierten Elementen ausgewertet. 

• 1-n-Kardinalität bedeutet Fakt auf der Seite n und Dimension auf der Seite 1. 

• Ein Abfragesubjekt kann in einer Abfrage als Dimension und in einer anderen als Fakt fungieren. 

• Abfragen von mehreren Fakten werden zu einer zusammengefügten Abfrage. 

Weitere Informationen finden Sie unter "Abfrage einzelner Fakten" (S. 33) und "Abfrage mehrerer 

Fakten und mehrerer Ebenen von angepassten Dimensionen" (S. 34). 

Modellieren von 1-n-Beziehungen als 1-1-Beziehungen 

Wenn eine 1-n-Beziehung in den Daten vorhanden ist, im Modell jedoch als 1-1-Beziehung dargestellt 

wird, können SQL-Traps nicht vermieden werden, weil die von den Metadaten für die 

Abfrage-Engine bereitgestellten Informationen nicht ausreichen. 

Wenn 1-n-Beziehungen im Modell als 1-1 dargestellt werden, treten sehr häufig folgende Probleme 

auf: 

• Doppelzählung für Abfragen mehrerer Ebenen wird nicht automatisch vermieden. 

Cognos 8 kann keine Fakten finden und anschließend keine zusammengefügte Abfrage erzeugen, 

um die Doppelzählung auszugleichen, was beim Umgang mit hierarchischen Beziehungen 

und verschiedenen Ebenen der Granularitäten in angepassten Dimensionen auftreten kann. 

• Abfragen mehrerer Fakten werden nicht automatisch gefunden. 

Cognos 8 verfügt nicht über ausreichend Informationen, um eine Abfrage mit mehreren Fakten 

zu finden. Bei Abfragen mehrerer Fakten wird eine geschlossene Verbindung durchgeführt, 

und die Schleifenverbindung wird durch Ablegen der letzten ausgewerteten Verbindung 

entfernt. In Abhängigkeit von den Dimensionen und Fakten in der Abfrage kann das Ablegen 

einer Verbindung zu falschen oder unerwarteten Ergebnissen führen. 




In Report Studio können Sie diese Probleme umgehen, indem Sie zwischen den Abfragen eine 

geschlossene oder offene Verbindung erstellen. Dafür benötigt der Berichtsautor detaillierte 

Kenntnisse der Daten. In Query Studio oder Analysis Studio können solche Probleme nicht 

umgangen werden. 

Analysieren von Modellen für Fakten und Dimensionen 

Wenn Sie eine relationale Datenbank für faktübergreifende Abfragen und Analysen dimensional 

modellieren möchten, müssen Sie das zugrunde liegende Schema und die Adressbereiche untersuchen, 

in denen die Rolle eines Objekts als Fakt oder Dimension nicht eindeutig ist. Diese Untersuchung 

kann zur Erstellung einer logischen Schicht führen, um die Daten als Sternschema 

darzustellen. Möglicherweise nehmen Sie aber auch Änderungen an der physischen Datenquelle 

vor, um eine Anwendung mit höherer Leistung bereitzustellen. Physische Änderungen können u. a. 

die Konsolidierung von Tabellen mithilfe von Tools zum Extrahieren/Transformieren/Laden oder 

die Erstellung von konvertierten Ansichten für häufig verwendete Aggregationen umfassen. 

Möglicherweise müssen Sie in einer relationalen Datenquelle, die nicht anhand von Sternschemakonzepten 

entnormalisiert wurde, die Kardinalität der importierten Abfragesubjekte vor der 

Erstellung von Dimensionen oder der Konvertierung von Abfragesubjekten in Dimensionen analysieren. 

Zunächst müssen Sie die Unternehmensanwendungen der zugrunde liegenden Daten sowie 

die Art der Generierung von Abfragen in Cognos 8 verstehen. 

Im Kontext einer Abfrage kann ein Abfragesubjekt mit einer Kardinalität von n in allen seinen 1n-Beziehungen 

mit anderen Abfragesubjekten als Fakt betrachtet werden. Dies bedeutet, dass 

mehr Datenzeilen im Faktabfragesubjekt als im verbundenen Abfragesubjekt auf der Seite 1 der 

Beziehung vorhanden sind. Alle Abfragesubjekte auf der Seite 1 einer 1-n-Beziehung mit einem 

anderen Abfragesubjekt werden als Dimension behandelt. 

In den folgenden Beispielen wird veranschaulicht, wie Schemen interpretiert werden können. 

In den ersten beiden Beispielen wird gezeigt, dass sich "Sales Staff" direkt auf "Sales Fact", aber 

auch über "Sales Branch" auf "Sales Fact" beziehen kann. Mehrere Vertriebsmitarbeiter gehören 

zu einem Vertriebsbüro, und die Mitarbeiter können über einen längeren Zeitraum zu verschiedenen 

Vertriebsbüros gehören. Damit der Umsatz in einem Büro zu einem bestimmten Zeitpunkt 

korrekt bestimmt werden kann, muss "Sales Branch" direkt, und nicht erst über "Sales Staff", mit 

"Sales" verbunden werden. 

Beispiel 1 

In diesem Beispiel sind alle vier Abfragesubjekte in einer Abfrage enthalten. Das Diagramm zeigt, 

dass die Abfragesubjekte als Fakten behandelt werden, die nur n Kardinalitäten besitzen. "Sales 

Staff" und "Order Details" werden als Fakten behandelt. "Order Header" und "Sales Branch" 

werden als Dimensionen behandelt. 

Beispiel 2 

In diesem Beispiel sind nur drei Abfragesubjekte in einer Abfrage enthalten. "Order Details" wird 

in der Abfrage nicht verwendet. "Order Header" wird nun als Fakt behandelt. "Sales Staff" wird 

weiterhin als Fakt behandelt.

Beispiel 3 


In diesem Beispiel werden verschiedene Abfragesubjekte veranschaulicht. Pfeile zeigen auf die 

Abfragesubjekte, deren Kardinalität angibt, dass sie immer Fakten sind. Bereiche, in denen das 

Verhalten vom Kontext der Abfrage abhängt, sind eingekreist. Alle anderen Abfragesubjekte verhalten 

sich als Dimensionen in allen Abfragen. 

Weitere Informationen finden Sie unter "Das von Cognos 8 generierte SQL" (S. 33). 

Vereinfachen von Modellen anhand von dimensionalen Konzepten 

Diese Regeln gelten für die Modellierung mit Abfragesubjekten oder Dimensionen: 

• Erstellen Sie eine reguläre Dimension für Gruppen von Abfragesubjekten mit hierarchischen 

Beziehungen, die ein einzelnes Unternehmenskonzept darstellen (S. 12). 

• Erstellen Sie eine Kennzahldimension für Gruppen von Abfragesubjekten mit Faktdaten, die 

viele reguläre Dimensionen gemeinsam nutzen oder die eine Beziehung vom Typ Master/Detail 

aufweisen (S. 12). 

• Verwenden Sie die Kardinalitätsregeln, um Modellbereiche zu erkennen, in denen die Rolle 

eines Objekts als Fakt oder Dimension unklar ist. Weitere Informationen finden Sie unter 

"Kardinalitäten in generierten Abfragen" (S. 9). 

Das Ergebnis der Vereinfachung des Modells sollte eine Schicht regulärer Dimensionen oder Kennzahldimensionen 

sein, durch die die Daten zu den Unternehmenskonzepten klar dargestellt und 

eine vorhersehbare Abfragengenerierung sichergestellt wird. 

Wenn Ihre Datenquelle Fakt-zu-Fakt-Beziehungen enthält, sollten Sie diese in der Datenquelle verarbeiten. 



Erstellen von regulären Dimensionen 


Normalisierte bzw. "Schneeflocken"-Datenquellen verfügen oft über verschiedene Tabellen, die 

ein einzelnes Unternehmenskonzept beschreiben. Eine normalisierte Darstellung von "Product" 

kann z. B. vier Tabellen enthalten, die mit 1-n-Beziehungen verbunden sind. Jede "Product Line" 

verfügt über einen oder mehrere "Product Types". Jeder "Product Type" verfügt über ein oder 

mehrere "Products". Namen und Beschreibungen von Produkten sind in mehreren Sprachen vorhanden, 

weshalb sie in einer Nachschlagetabelle "Product" aufgeführt werden. 

Ein Endbenutzer kennt möglicherweise nicht die Beziehungen der einzelnen Abfragesubjekte 

untereinander. Zusätzlich ist es für den Endbenutzer aufwändiger, die einzelnen Abfragesubjekte 

oder Dimensionen erweitern und Abfragelemente auswählen zu müssen. 

Bei der dimensionalen Modellierung können Sie eine reguläre Dimension für "Product" erstellen, 

wodurch die Verwendung von "Product" für Ad-hoc-Abfragen und -Berichterstellungen vereinfacht 

wird und wodurch die Ebenen der Hierarchie als visuelle Hervorhebung der Beziehung der 

Ebenen untereinander dargestellt werden. 

Wenn Sie ein ReportNet 1.x-Modell verwalten, können Sie ein Modellabfragesubjekt mit Determinanten 

anstatt einer regulären Dimension erstellen. Sie können den Präsentationseffekt der Ebenen 

mehrfach nutzen, indem Sie Abfrageelementordner verwenden. Das resultierende Modellabfragesubjekt 

kann jederzeit in eine reguläre Dimension konvertiert werden. 

Erstellen von Kennzahldimensionen 

Datenquellen verfügen häufig über Master/Detail-Tabellen, die Fakten enthalten. Beispiele dafür 

sind "Order Header" und "Order Detail". Wenn diese Tabellen zum Einfügen und Aktualisieren 

von Daten verwendet werden, ist diese Struktur vorteilhaft. Wenn diese Tabellen zum Erstellen 

von Berichten und Analysen verwendet werden, kombinieren Sie sie zur Vereinfachung des 

Modells in einem einzigen Unternehmenskonzept. 

Erstellen Sie zur Vereinfachung des Modells in diesem Beispiel ein Modellabfragesubjekt, das die 

Fremdschlüssel von "Order Header" und "Order Detail" miteinander verbindet und alle Kennzahlen 

auf der Ebene "Order Detail" enthält. Sie können eine Kennzahldimension auf der Grundlage 

des Modellabfragesubjekts erstellen.


Nicht eindeutige Dimensionen und Fakten müssen immer aufgelöst werden. Weitere Informationen 

finden Sie unter "Das von Cognos 8 generierte SQL" (S. 33). 

Klären nicht eindeutiger Beziehungen 

Nicht eindeutige Beziehungen treten auf, wenn die von einem Abfragesubjekt oder einer Dimension 

dargestellten Daten in mehreren Kontexten oder Rollen angezeigt werden können. Folgende 

nicht eindeutige Beziehungen kommen am häufigsten vor: 

• mehrere gültige Beziehungen (S. 13) 

• reflexive und rekursive Beziehungen (S. 16) 

Sie können nicht eindeutige Beziehungen in Framework Manager klären, oder der Datenbankadministrator 

kann sie in der Datenquelle korrigieren. Der Datenbankadministrator kann z. B. 

zusätzliche Beziehungen entfernen, auch wenn dies nicht praktisch sein mag. Zur Klärung nicht 

eindeutiger Beziehungen im Modell gehört auch die Festlegung, welcher Abfragepfad verwendet 

werden soll. 

Mehrere gültige Beziehungen 

Eine Tabelle mit mehreren gültigen Beziehungen zu einer weiteren Tabelle wird als Dimension mit 

unterschiedlichen Rollen bezeichnet. Oft bestehen zwischen regulären Dimensionen und Kennzahldimensionen 

mehrere gültige Beziehungen. Dies trifft gewöhnlich für Dimensionen wie 

"Time" und "Customer" zu. 

Der Fakt "Sales" verfügt z. B. über mehrere Beziehungen zur Zeitdimension mit Schlüsseln, wie 

z. B. "Order Day", "Ship Day" und "Close Day". 

Schritte 

1. Lassen Sie alle Beziehungen in der Importansicht unverändert. 

2. Erstellen Sie eine Kennzahldimension für den Fakt. 

3. Erstellen Sie eine reguläre Dimension für jede einzelne Dimension. 

4. Erstellen oder kopieren Sie die reguläre Dimension für die einzelnen Rollen. 

5. Benennen Sie die Dimension, Hierarchie, Ebenen und Attribute entsprechend ihrer Verwendung 

um. 




6. Stellen Sie sicher, dass eine einzige geeignete Beziehung zwischen den einzelnen regulären 

Dimensionen und der Kennzahldimension oder zwischen den zugrunde liegenden Abfragesubjekten 

vorhanden ist. 

7. Stellen Sie sicher, dass für jede Rolle eine entsprechende Bereichsbeziehung vorhanden ist. 

8. Entscheiden Sie, wie Sie diese Rollen mit anderen Fakten verwenden möchten, die nicht dieselben 

Konzepte nutzen. 

Product Forecast verfügt z. B. über nur einen Zeitschlüssel. 

Sie können einen der folgenden Vorgänge ausführen: 

• Kennzeichnen Sie eine bestimmte Zeitdimension als angepasste Zeitdimension. 

Sie können die gängigste Rolle auswählen, die Sie verwenden werden, und sie eindeutig 

als angepasste Dimension bezeichnen. Anschließend können Sie sicherstellen, dass diese 

Version der Dimension mit allen Fakten verbunden wird, für die eine Zeitdimension 

erforderlich ist.


• Sie können "ship day", "order day" und "close day" als austauschbare Zeitdimensionen 

mit dem Fakt "Product Forecast" verwenden. 

In diesem Fall müssen Sie Verbindungen zwischen den Dimensionen mit unterschiedlichen 

Rollen und dem Fakt "Product Forecast" erstellen. Wenn Ihr Bericht Daten enthalten soll, 

sollten Sie bei der Abfrage des Fakts "Product Forecast" nur jeweils eine Zeitdimension 

verwenden. Beispiel: Month_key=Ship Month Key (200401) und Month key=Close 

Month Key (200312). 




Modellobjekte im Vergleich mit Verknüpfungen 

Sie können Modellobjekte auf der Grundlage der ursprünglichen Abfragesubjekte erstellen. Diese 

Modellobjekte können reguläre Modelldimensionen oder Modellabfragesubjekte sein. Sie können 

aber auch Verknüpfungen erstellen. 

Verwenden Sie reguläre Modelldimensionen oder Modellabfragesubjekte, wenn Sie benutzerdefinierte 

Ansichten desselben Abfragesubjekts erstellen möchten. 

Verwenden Sie Verknüpfungen, wenn Sie an mehreren Stellen exakte Kopien einer regulären 

Dimension oder eines Abfragesubjekts erhalten möchten. 

Eine Verknüpfung, die sich in demselben Verzeichnis wie das Ziel befindet, verhält sich wie ein 

Alias oder eine unabhängige Instanz. Eine Verknüpfung, die an anderer Stelle im Modell vorhanden 

ist, verhält sich jedoch als Verweis auf das Original. Dieser Ansatz ist aus Sicht der Präsentation 

insgesamt weniger flexibel, weil die Umbenennung nur auf Objektebene erfolgen kann. 

Reflexive und rekursive Beziehungen 

Reflexive und rekursive Beziehungen besitzen zwei oder mehr Granularitätsebenen. Framework 

Manager importiert reflexive Beziehungen, verwendet sie aber nicht bei der Ausführung von 

Abfragen. Reflexive Beziehungen, die Verbindungen zu sich selbst sind, werden im Modell allein 

zum Zweck der Darstellung angezeigt. 

Wenn Sie eine funktionsfähige reflexive Beziehung erstellen möchten, müssen Sie einen Alias 

erstellen, der entweder eine Verknüpfung zum Abfragesubjekt in demselben Ordner oder ein 

Modellabfragesubjekt auf der Grundlage des Abfragesubjekts verwendet. Anschließend erstellen 

Sie eine Beziehung zwischen dem Abfragesubjekt und dem Alias. Die Verwendung eines Modellabfragesubjekts 

ist dazu tendenziell eher geeignet, weil Sie festlegen können, welche Abfageelemente 

in das Abfragesubjekt integriert werden sollen. 

Das Abfragesubjekt "Staff" verfügt z. B. über eine rekursive Beziehung zwischen "Staff Key" und 

"Manager Key".


Schritte 

1. Erstellen Sie ein Modellabfragesubjekt zum Darstellen der Manager. 

2. Wählen Sie aus, welche Elemente für Manager gelten, und geben Sie ihnen einen neuen, aussagekräftigen 

Namen. 

3. Erstellen Sie eine 1:1- bis 1:n-Beziehung zwischen Mitarbeitern und Manager. 

Bei einer einfachen Struktur auf zwei Ebenen unter Verwendung eines Modellabfragesubjekts 

für Manager, das auf den Mitarbeitern basiert, sieht das Modell folgendermaßen aus: 

4. Wiederholen Sie bei einer rekursiven Hierarchie diese Schritte für jede zusätzliche Ebene in der 

Hierarchie. 

Wie empfehlen bei einer rekursiven Hierarchie mit vielen Ebenen, dass die Ebenen der Hierarchie 

in der Datenquelle reduziert werden und Sie ein Modell dieser reduzierten Hierarchie in 

einer einzigen regulären Dimension erstellen. 

5. Wählen Sie die Abfragesubjekte aus, klicken Sie mit der rechten Maustaste darauf, und klikken 

Sie auf Merge in New Regular Dimension. 

Definieren von Dimensionen und Determinanten 

Verwenden Sie Dimensionen und Determinanten, um zu gewährleisten, dass die Aggregation in 

Berichten korrekt ist und dass Abfragen korrekt generiert werden. 

Verwenden Sie reguläre Dimensionen, um beschreibende Informationen zu organisieren und darzustellen 

und somit die Endbenutzer effektiv durch die Berichterstellungstools zu führen. Hierarchien 

werden von oben nach unten dargestellt, d. h. von der gröbsten Granularitätsebene zur 

feinsten. 

Die regulären Dimensionen der Datenquelle behandeln Hierarchie- und Ebeneninformationen so, 

als wären sie Determinanten. 

Reguläre Modelldimensionen erfordern, dass Determinanten für die zugrunde liegenden Abfragesubjekte 

angegeben werden. 

Verwenden Sie Determinanten, um anzugeben, welche Daten eindeutig sind. 

Wenn eine Determinante Attribute definiert, müssen alle Abfrageelemente im Abfragesubjekt entweder 

als Schlüssel oder als Attribut definiert werden. Die Verwendung einer Determinante ohne 

definierte Attribute ist möglich. Framework Manager verwendet diesen Determinantentyp, um 

anzuzeigen, welche Abfrageelemente indiziert sind. 




Verbindungen und Granularität sind die entscheidenden Faktoren der SQL-Generierung. Geben 

Sie Granularität für die Objekte an, die über Beziehungen verfügen, indem Sie entweder eine Hierarchie 

oder Determinanten für diejenigen Objekte verwenden, zu denen die Verbindung hergestellt 

wird. 

Sie müssen reguläre Dimensionen und Kennzahldimensionen verwenden, um die Analyse Ihrer 

relationalen Datenquelle zu aktivieren. Bei den meisten Datenquellen ist es wahrscheinlich, dass 

die regulären Dimensionen, die die beschreibenden Informationen enthalten, von mehr als einer 

Kennzahldimension gemeinsam verwendet werden. Reguläre Dimensionen werden häufig als 

gemeinsame Dimensionen bezeichnet. Reguläre Dimensionen und Kennzahldimensionen, die als 

Cluster organisiert sind, werden oft als Sternschemagruppe bezeichnet, doch können sie auch als 

funktionale Gruppe oder Subjektbereichsgruppe bezeichnet werden. 

Kennzahldimensionen stehen über die regulären Dimensionen miteinander in Beziehung. Zum 

Erstellen von Berichten, die Funktionsbereiche vollständig vergleichen und einander gegenüberstellen, 

müssen Sie in einem Bericht eventuell mehr als eine Kennzahldimension verwenden. 

Bei der Abfrage in Sternschemata oder Funktionsbereichen müssen Sie die Rolle der Hierarchie bei 

der Abfragegenerierung beachten: 

• Abfrage mehrerer Fakten und mehrerer Ebenen (S. 18) 

• Mehrere Hierarchien (S. 22) 

Abfrage mehrerer Fakten und mehrerer Ebenen 

Abfragen mehrerer Fakten und mehrerer Ebenen treten auf, wenn Dimensionen auf verschiedenen 

Ebenen mit mehreren Faktentabellen verwandt sind. Eine Dimension verfügt normalerweise über 

unterschiedliche Ebenen an Attributdaten mit Unternehmensschlüsseln, zwischen denen eine hierarchische 

Beziehung besteht. Die Berichterstellungstools aggregieren automatisch zur niedrigsten 

gemeinsamen Ebene, die in dem Bericht vorhanden ist. Die hierarchische Beziehung zwischen Ebenenschlüsseln 

wird dazu verwendet, Daten auf der untersten im Bericht enthaltenen Ebene zu 

aggregieren. Die Gefahr der doppelten Zählung tritt auf, wenn die Gesamtsummen der Spalten 

gebildet werden und Daten darin wiederholt vorkommen. Bei korrekter Modellierung der Granularitätsebene 

der Daten lässt sich die doppelte Zählung vermeiden. 

Hinweis: Sie können einen Bericht mit Daten auf einer Hierarchieebene erstellen, unter der diese 

Daten vorhanden sind. Dadurch wiederholen sich zwar die Daten über alle Mitglieder dieser 

Ebene, aber die Gesamtsummen sind nicht betroffen. 

Dieses Beispiel zeigt zwei Kennzahldimensionen für Datenquellen, nämlich "Sales" und "Product 

forecast", die zwei reguläre Dimensionen gemeinsam verwenden: "Time" und "Product".


Die Dimension "Time" ist der Schwerpunkt der Granularitätsproblematik dieses Beispiels. In der 

zugrunde liegenden Datenquelle ist "Sales" mit "Time" am "Day"-Schlüssel verbunden, und 

"Product forecast" ist mit "Time" am "Month"-Schlüssel verbunden. Aufgrund der unterschiedlichen 

Verbindungsschlüssel müssen mindestens zwei Ebenen eindeutig mit Schlüsseln für die 

"Time"-Dimension gekennzeichnet sein. 

Datenquellendimensionen 

Wir empfehlen Ihnen, beim Verwenden von Datenquellendimensionen alle Ebenen zu erstellen, die 

für die Berichterstellung notwendig sein könnten, und nicht nur jene Ebenen, die sofort notwendig 

sind. 

Die Schlüssel der Ebenen "Month" und "Day" wurden z. B. angegeben. "Day" ist die unterste 

Ebene der Hierarchie und das Feld Unique Level ist ausgewählt, weil diese Daten in der zugrunde 

liegenden Datenquelle eindeutig sind. 

Beispielsweise lauten die Ebenendefinitionen für "Month" wie folgt: 

Beispielsweise lauten die Ebenendefinitionen für "Day" wie folgt: 




Die Dimension "Product" hat drei Ebenen: "Product line", "Product type" und "Product". Sie 

steht in Beziehung zu beiden Faktentabellen am "Product"-Schlüssel. Alle Verbindungen in den 

zugrunde liegenden Tabellen erscheinen am "Product"-Schlüssel, sodass es in dieser Dimension 

keine Granularitätsprobleme gibt. Jegliche Hierarchie, die Sie erstellen, dient allein dem Drilling 

und der Aufsummierung. 

Standardmäßig wird ein Bericht aggregiert, um Datensätze aus jeder Faktentabelle auf der untersten 

gemeinsamen Ebene der Granularität abzurufen. Wenn Sie einen Bericht erstellen, der "Quantity" 

aus "Sales" verwendet, "Expected volume" aus "Product forecast", "Month_name" aus der 

Dimension "Time" und "Product_name" aus der Dimension "Product", ruft der Bericht Datensätze 

aus jeder Faktentabelle auf der untersten gemeinsamen Ebene der Granularität ab. In diesem 

Beispiel handelt es sich um die Monats- und Produktebenen. 

Wenn Sie die Ebenen der Hierarchie nicht ordnungsgemäß in der Dimension "Time" angeben, 

kann fehlerhafte Aggregation auftreten. So werden beispielsweise die Werte für "Expected 

volume", die sich auf der Ebene "Month" in "Product forecast" befinden, auf Grundlage der tieferen 

Zeitebene, d. h. "Days" in der Dimension "Time", aufsummiert. Die Werte für "Expected 

volume" werden mit der Anzahl der Tage im Monat multipliziert. 

Um eine doppelte Zählung zu verhindern, wenn Daten auf mehreren Granularitätsebenen vorhanden 

sind, müssen Sie eine Hierarchie für die Dimension "Time" erstellen und die Ebenen mit den 

Schlüsseln korrekt angeben. 

Beachten Sie die unterschiedlichen Zahlen in der Spalte "Expected volume". Eine doppelte Zählung 

wurde verhindert.


Reguläre Modelldimensionen und Abfragesubjekte mit Determinanten 

Determinanten sind nicht mit Ebenen und Hierarchien identisch, können aber eng mit einer einzelnen 

Hierarchie verbunden sein. Die Abfragen-Engine wertet Determinanten von der ersten bis zur 

letzten aus. Es können ein oder mehrere Determinanten angegeben werden. 

Wenn eine reguläre Modelldimension auf einem Abfragesubjekt mit angegebenen Determinanten 

basiert, wird empfohlen, dass 

• jeder im Abfragesubjekt vorhandenen Determinante eine Ebene entspricht 

• die Reihenfolge der Ebenen in der Hierarchie die Reihenfolge der Determinanten widerspiegelt 

Das führt zu einem einheitlichen Modell und erleichtert das Aktualisieren des Modells in zukünftigen 

Versionen von Cognos-Produkten. 

Wenn Sie Modelldimensionen verwenden, beginnen Sie mit den Abfragesubjekten, die die Basis 

der Dimension darstellen. Wir empfehlen, für jede Ebene, die für die Berichterstellung notwendig 

sein könnte, eine Determinante zu erstellen, und nicht nur für die Ebenen, die sofort notwendig 

sind. 

Hier ist z. B. eine Lösung für die Dimension "Time", die eine Alternative zu der weiter oben 

beschriebenen Art des Verwendens von Dimensionen darstellt. Für "Month" und "Day" sind 

Determinanten festgelegt. Beachten Sie, dass "Day" die unterste Ebene der Hierarchie ist. 

Beispielsweise lauten die Determinanten für "Month" wie folgt: 

Beispielsweise lauten die Determinanten für "Day" wie folgt: 



Mehrere Hierarchien 


Das Kontrollkästchen Uniquely Identified ist nur für die unterste Ebene der Hierarchie aktiviert, 

da die Daten in dieser Spalte für jede Zeile in der zugrunde liegenden Datenquelle eindeutig sind. 

Das Kontrollkästchen Group By ist für alle Ebenen aktiviert, deren Daten nicht eindeutig sind. 

Falls eine Aggregation für ein zugehöriges Attribut erforderlich ist, sollte der für die Determinante 

definierte Schlüssel in einer Group By-Klausel in der Abfrage verwendet werden. Ebenso gilt: Falls 

ein Attribut einer Group By-Ebene in einer Abfrage enthalten ist, kann eine Minimum-Aggregatfunktion 

verwendet werden, um zu gewährleisten, dass der Wert in der Abfrage eindeutig ist. 

Die Hierarchie für die reguläre Modelldimension wäre identisch mit der hier gezeigten für die 

Datenquellendimension. 

Informationen über das SQL und die Ergebnisse für dieses Beispiel finden Sie unter "Abfrage mehrerer 

Fakten und mehrerer Ebenen von angepassten Dimensionen" (S. 34). 

Mehrere Hierarchien treten auf, wenn auf dieselben Daten unterschiedliche Strukturansichten 

angewendet werden können. Sie sollten das Modellerstellungsverfahren, das auf einen bestimmten 

Fall angewendet wird, in Abhängigkeit von den Hierarchien und den erforderlichen Berichte 

bewerten. 

In Framework Manager können Sie für reguläre Dimensionen mehrere Hierarchien angeben. 

Mehrere Hierarchien für eine reguläre Dimension verhalten sich wie Ansichten derselben Abfrage. 

Sie können die verschiedenen Hierarchien einer Dimension nicht in einer einzelnen Berichtsabfrage 

verwenden. 

Beispielsweise können Vertriebsmitarbeiter nach Manager oder geografischer Region angezeigt 

werden. In den Tools zur Berichterstellung sind diese Hierarchien getrennte, aber austauschbare 

logische Strukturen, die an dieselbe zugrunde liegende Abfrage gebunden sind. 

Nachfolgend sind die Vertriebsmitarbeiter als einzelne Dimension mit zwei Hierarchien abgebildet:

Die Hierarchien sind in Framework Manager wie folgt definiert. 


Wenn Sie mehrere Hierarchien aus einer Dimension in einem Bericht benötigen, z. B. auf gegenüberliegenden 

Achsen, müssen Sie für jede Hierarchie eine reguläre Dimension erstellen. Jede reguläre 

Dimension muss eine einzelne eindeutige Hierarchie sein. Auf diese Weise können Sie 

denselben oder einen leicht unterschiedlichen SQL-Block mehrere Male ausgeben. 

Nachfolgend sind für jede Hierarchie separate Dimensionen abgebildet. 

Verwenden Sie diesen Ansatz, wenn für jede Hierarchie sehr unterschiedliche Spaltensätze relevant 

sind. Für Endbenutzer ist es leichter zu erfassen, wenn die Hierarchien als separate Dimensionen 

mit separaten und einfacheren Abfragen modelliert sind. 



Erstellen von Sternschemagruppen 


Sternschemagruppen können das Modell für Endbenutzer intuitiver machen, indem sie anzeigen, 

welche regulären Dimensionen und Kennzahldimensionen miteinander verbunden sind. Sternschemagruppen 

können auch das Erstellen von Berichten erleichtern, die mehrere Fakten beinhalten, 

indem sie angeben, wie die regulären Dimensionen, die in vielen Kennzahldimensionen vorhanden 

sind, verwendet werden. Das Erstellen von Berichten, die mehrere Fakten beinhalten, wird auch 

"funktionsübergreifende Berichterstellung" genannt. 

Sternschemagruppen stellen auch einen Kontext für Abfragen mit nicht eindeutigen Verbindungen 

bereit. Durch das Erstellen von Sternschemagruppen in der Geschäftsansicht des Modells können 

Sie klären, welcher Verbindungspfad auszuwählen ist, wenn mehrere Verbindungspfade zur Verfügung 

stehen. Dies ist insbesondere hilfreich für Abfragen ohne Fakten. 

Mehrere angepasste Sternschemata oder Abfragen ohne Fakten 

Es ist sehr wahrscheinlich, dass angepasste reguläre Dimensionen zwischen Kennzahldimensionen 

angezeigt werden. Uneindeutige Verbindungen sind dann ein Problem, wenn Sie einen Bericht mit 

Elementen aus mehreren Dimensionen erstellen, ohne Elemente aus der Kennzahldimension miteinzubeziehen. 

Bei dieser Situation spricht man auch von einer Abfrage ohne Fakten. 

"Product" und "Time" sind beispielsweise reguläre Dimensionen, die mit den Kennzahldimensionen 

"Product forecast" und "Sales" verwandt sind. 

Wie erstellen Sie mithilfe dieser Beziehungen einen Bericht, der lediglich die Elemente "Product" 

und "Year" verwendet? Die betriebswirtschaftliche Fragestellung könnte lauten: Der Verkauf welcher 

Produkte wurde für 2005 prognostiziert? Oder: Welche Produkte wurden 2005 tatsächlich 

verkauft? Obwohl diese Abfrage nur die Dimensionen "Product" und "Time" erfordert, sind die 

Dimensionen dennoch durch mehrere Kennzahldimensionen miteinander verbunden. Es gibt keine 

Möglichkeit, herauszufinden, welche betriebswirtschaftliche Fragestellung gestellt wird. Sie müssen 

den Kontext für die Abfrage ohne Fakten festlegen. 

In Bezug auf dieses Beispiel empfehlen wir, dass Sie zwei Namespaces erstellen, wobei der eine 

"Product", "Time" und "Product forecast" enthält und der andere "Product", "Time" und 

"Sales".


Verwenden Sie zum Erstellen dieser Namespaces den Create Star Schema Grouping-Assistenten, 

um die korrekten Dimensionen für jede Kennzahl auszuwählen, Verknüpfungen für alle Objekte 

zu erstellen und die Verknüpfungen in einen neuen Namespace zu verschieben. 

Wenn Sie diesen Vorgang bei allen Sternschemata durchführen, lösen Sie die uneindeutigen Verbindungen 

durch das Erstellen von Verknüpfungen mit der Kennzahldimension und allen regulären 

Dimensionen in einem einzigen Namespace auf. In jedem Namespace sind die Verknüpfungen 

für angepasste Dimensionen identisch und stellen Verweise auf das ursprüngliche Objekt dar. 

Mit einem Namespace für jedes Sternschema ist dem Endbenutzer nun klar, welche Elemente zu 

verwenden sind. Um einen Bericht "Products Sold in 2005" (die 2005 verkauften Produkte) zu 

erstellen, verwenden die Benutzer "Product" und "Year" aus dem Namespace "Sales". Die einzige 

Beziehung, die in diesem Kontext von Belang ist, ist die Beziehung zwischen "Product", "Time" 

und "Sales", und diese wird zum Zurückgeben der Daten verwendet. 

Aktualisieren von Best-Practices-Modellen von ReportNet 1.x 

Teil der Cognos 8-Installation ist die automatische Aktualisierung aller publizierten Modelle für 

die Verwendung in Cognos 8. Um die Berichterstellung zu starten, müssen Sie diese Modelle nicht 

ändern. Wenn Sie Änderungen in den Daten oder Metadaten übernehmen oder neue Funktionen 

verwenden möchten, müssen Sie das Modell in Framework Manager aktualisieren. Beim Aktualisieren 

müssen Sie entscheiden, wann und wo Sie neue Funktionen verwenden möchten. Mit den 

Tools in Framework Manager wird das Aktualisieren mit neuen Funktionen basierend auf den 

vorhandenen Metadaten im Modell erleichtert. 

Wenn Sie für die Erstellung des ReportNet 1.x-Modells die Empfehlungen in Modeling in 

Framework Manager for Predictable Queries and Results verwendet haben, die Sie auf der Support-Website 

von Cognos (http://support.cognos.com) finden, empfiehlt sich der folgende Workflow: 

❑ Überprüfen Sie das vorhandene Modell (S. 26). 

❑ Aktualisieren Sie das Modell (S. 26). 

❑ Definieren Sie Dimensionen und Determinanten (S. 17). 

❑ Erstellen Sie Kennzahldimensionen, oder konvertieren Sie die Fakten in Kennzahldimensionen. 

❑ Erstellen und testen Sie Sternschemagruppen (S. 24). 

❑ Publizieren Sie die Metadaten neu. 

Informationen zu den hier nicht behandelten Themen finden Sie unter "Preparing Relational 

Metadata for Use in Reports" und "Making Metadata Available to Report Authors" im Framework 

Manager User Guide. 




Alle Beispiele in diesem Dokument verwenden die Datenbankansicht des normalisierten Modells 

"gosales_goretailers" oder die Importansicht des Modells "go_data_warehouse", die in den 

Cognos 8-Beispielen enthalten sind. 

Überprüfen des vorhandenen Modells 









Vor dem Aktualisieren des Modells auf Cognos 8 sollten Sie das ReportNet 1.x-Modell mithilfe 

des Dokuments Modeling in Framework Manager for Predictable Queries and Results überprüfen. 

Sie müssen sicherstellen, dass die Dimensionsinformationen korrekt angegeben wurden. Beim 

Aktualisierungsprozess werden die Dimensionsinformationen für das Erstellen von Dimensionen 

oder Determinanten verwendet. Mit Dimensionen und Determinanten werden in Cognos 8 die 

Granularität und die automatische Aggregation gesteuert und Doppelzählungen vermieden. 

Es wird dringend empfohlen, dass Sie in ReportNet 1.x den Befehl Verify Model ausführen. Beheben 

Sie alle Fehler, und überprüfen Sie alle Warnungen, bevor Sie die Aktualisierung starten. 

Aktualisieren des Modells 

Nach der automatischen Aktualisierung des Modells in Cognos 8 müssen Sie die neuen Funktionen 

manuell überprüfen, da einige das Abfrageverhalten ändern. Die anfängliche automatische 

Aktualisierung auf Cognos 8 erzeugt ein Modell, das auf einem Cognos 8-Berichtsserver publiziert 

werden kann. 

Die meisten Änderungen an Modellkonzepten in Cognos 8 gibt es in den Bereichen von Datentypen, 

Dimensionen und Determinanten. 

Änderungen an Datentypen 

In Cognos 8 wurde die Unterstützung für neue Datentypen hinzugefügt. Dadurch kann es Änderungen 

bei der Verknüpfung von Datentypen zwischen Cognos und den Quelldaten beim Metadaten-Import 

geben. Die wichtigsten Änderungsbereiche sind: 

• nChar 

In einigen Fällen wird der Datentyp char zu nChar. 

• nVarChar 

In einigen Fällen wird der Datentyp varChar zu nVarChar. 

• numeric 

In einigen Fällen wird der Datentyp decimal zu numeric. 

• timestampTZ 

In einigen Fällen wird der Datentyp varChar zu timestampTZ. 

• IntervalTZ 

In einigen Fällen wird der Datentyp varChar zu IntervalTZ. 

Die Verknüpfung dieser Datentypen unterscheidet sich nach dem Hersteller der Datenquelle und 

kann über den Abschnitt für die Datentypunterstützung auf der Support-Website von Cognos 

(http://support.cognos.com) bestätigt werden. 

Der Gouverneur Allow enhanced model portability at runtime wird bei der anfänglichen Aktualisierung 

ausgewählt. Durch diesen Gouverneur wird die rigorose Erzwingung der Datentypen verhindert, 

sodass das Cognos 8-Modell als ReportNet 1.x-Modell verwendet werden kann, bis Sie 

die Datentypen in den Metadaten aktualisieren.


Die neuen Datentypen können nicht basierend auf den vorhandenen, im Modell gespeicherten 

Datentypen automatisch ermittelt werden. Verwenden Sie daher die Befehle Verify Model, Verify 

Selected Objects oder Update Object, um die Verknüpfung der Datentypen zu aktualisieren. 

Dimensionen und Determinanten 









Die zuvor durch Dimensionsinformationen angegebenen Metadaten bleiben im Modell implizit 

erhalten und bestehen für Abfragesubjekte weiter, bis diese Abfragesubjekte repariert werden. Sie 

können diese Dimensionsinformationen nicht ändern. Sie können die Dimensionsinformationen 

auf reguläre Dimensionen oder Determinanten aktualisieren. Bis zur Aktualisierung des Abfragesubjekts 

verwendet die Cognos 8-Abfragegenerierung die zuvor in ReportNet 1.x angegebenen 

Dimensionsinformationen. 

Der Gouverneur Allow dynamic generation of dimension information wird bei der anfänglichen 

Aktualisierung ausgewählt. Mit diesem Gouverneur wird einheitliches Verhalten mit ReportNet 

1.x sichergestellt, indem eine Form von Dimensionsinformationen aus den Beziehungen, Schlüsselinformationen 

und Indexinformationen in der Datenquelle abgeleitet wird. 

Weitere Informationen finden Sie unter "Neue Objekte in Cognos 8" (S. 6). 

Überprüfen und Reparieren des Modells 

Nach der automatischen Aktualisierung der Metadaten werden Sie von Framework Manager zur 

Überprüfung des Modells aufgefordert. Es wird dringend empfohlen, dass Sie diesen Schritt durchführen, 

bevor Sie Änderungen am Modell vornehmen. 

Übersicht über Warnungen 

Beim Überprüfen eines ReportNet 1.x-Modells werden häufig Warnungen mit folgendem Inhalt 

angezeigt: 

• Neubewertung erforderlich 

Diese Meldung bezieht sich meistens auf Änderungen der Datentypen. 

Die Mehrzahl der Elemente mit dieser Warnung kann zum Reparieren ausgewählt werden. 

Die Reparaturoption führt Sie durch die Optionen für die Auswertung und Aktualisierung 

bestimmter Elemente der Metadaten. 

Tipp: Sie können ein Abfragesubjekt auch über den Befehl Evaluate Object im Menü Tools 

auswerten. 

• Der Verbindungsausdruck widerspricht den Determinanteninformationen, die im Abfragesubjekt 

definiert sind. 

In einigen Fällen besitzen Index- und Schlüsselinformationen, die für ein Abfragesubjekt angegeben 

wurden, eine Granularitätsebene, die nicht mit den für ein Abfragesubjekt angegebenen 

Beziehungen übereinstimmt. Weitere Informationen finden Sie unter "Definieren von Dimensionen 

und Determinanten" (S. 17). 

• Für keine Abfrageelemente in dieser Ebene wurde die Caption-Rolle angegeben. 

Beim Definieren von Ebenen müssen Sie sicherstellen, dass ein Unternehmensschlüssel und 

Caption-Rollen angegeben wurden. Diese Rollen sind für Mitgliederfunktionen in den Tools 

zur Berichterstellung wichtig und hilfreich in der mitgliederorientierten Verzeichnisstruktur in 

Analysis Studio. 

• Eine oder mehrere Determinanten, die die Schlüssel und Attribute des Abfragesubjekts 

beschreiben, sollten definiert sein. 




Beim Importieren aus einer relationalen Datenquelle werden Determinanten für alle in der 

Datenquelle vorhandenen Indizes und Schlüssel angegeben. Es ist möglich, dass auf einem von 

ReportNet 1.x aktualisierten Abfragesubjekt, insbesondere für Modellabfragesubjekte, keine 

Determinanten vorhanden sind. Sie sollten Determinanten verwenden, um die Granularität 

der Daten im Abfragesubjekt und die Funktionsabhängigkeiten zwischen den Abfrageelementen 

ausdrücklich anzugeben. Die Angabe von Determinanten für Abfragesubjekte, die für eine 

einzelne Ebene oder Faktdaten stehen, ist jedoch nicht obligatorisch. Determinanten sind 

lediglich für Elemente vom Datentyp BLOB erforderlich. 

Auswählen und Reparieren von Objekten 

Sie können alle Elemente mit Kontrollkästchen auswählen und reparieren. Beim Reparaturprozess 

werden alle ausgewählten Elemente zunächst ausgewertet. Die Auswertung löst automatisch Probleme 

mit neuen Datentypen und fordert Sie zur Behandlung von Dimensionsinformationen im 

Modell auf. Sie sollten die meisten Abfragesubjekte, die Dimensionsinformationen in ReportNet 

1.x verwendet haben, auf Dimensionen aktualisieren. 

Konvertieren von Abfragesubjekten in Dimensionen 

Mithilfe der Dimensionsinformationen im Abfragesubjekt können Sie ein Abfragesubjekt in eine 

Dimension konvertieren. Darüber hinaus können Sie jederzeit nach der Aktualisierung eine 

Dimension mit Determinanten in ein Abfragesubjekt konvertieren. 

Dimensionsinformationen werden wie folgt mit regulären Dimensionen verknüpft. 

Dimensionsinformationen Reguläre Dimension 

Hierarchien Hierarchien 

Ebenen Ebenen 

Die erste Ebene der Hierarchie wird automatisch als Ebene 

"All" definiert. Sie enthält ein einzelnes Root-Mitglied, das die 

oberste Ebene der Hierarchie darstellt. 

Die Ebene "All" kann weder gelöscht noch verschoben werden. 

Sie können jedoch den Namen, die Beschreibung und den Bildschirm-Tipp 

ändern. 

Schlüssel _businessKey-Rolle 

Eindeutiger Schlüssel Eindeutige Ebene 

Erstes Textattribut nach dem 

Alphabet 

_memberCaption-Rolle 

Alle anderen Attribute Können manuell als _memberDescription, benutzerdefinierte 

Rolle oder keine Rolle zugewiesen werden 

Das Abfragesubjekt "Product" in ReportNet 1.x hat beispielsweise folgende Dimensionsinformationen.


Wenn Sie dieses Abfragesubjekt in eine reguläre Dimension konvertieren, werden die Dimensionsinformationen 

für die Erstellung dieser Hierarchien und Ebenen in Cognos 8 verwendet. 

Was Sie überprüfen sollten 

Nach der Konvertierung müssen Sie Folgendes überprüfen: 

• Eindeutige Ebene 

Eine eindeutige Ebene gibt an, dass die Schlüssel der darüber befindlichen Ebenen nicht notwendigerweise 

die Mitglieder in dieser Ebene identifizieren. 

• memberCaption-Rolle 

Um Mitgliederfunktionen zu nutzen und das Ziehen und Ablegen von Ebenen in den 

Berichterstellungstools zu ermöglichen, müssen Sie jeder Ebene in einer Dimension eine memberCaption 

zuweisen. Da diese Rolle in ReportNet 1.x nicht vorhanden ist, wird sie überall, 

wo dies möglich ist, verknüpft. Wenn es für die Ebene keine Attribute gibt, wird das Fehlen 

einer Caption-Rolle beim Überprüfen des Modells hervorgehoben. 

• Attribute 

In der Regel sollten alle anderen Attribute in die Dimension eingefügt und der richtigen Ebene 

zugeordnet werden. Standardmäßig werden sie ohne Rolle eingefügt. Sie können benutzerdefinierte 

Rollen erstellen oder vorhandenen Rollen Attribute zuweisen. 

• Mehrere Hierarchien 




Nur die erste Hierarchie aus einem ReportNet 1.x-Abfragesubjekt wird auf eine Dimension 

aktualisiert. Alle anderen Hierarchien müssen Sie neu erstellen. 

Beispielsweise können Sie das Abfragesubjekt "Product" nach der Aktualisierung auf eine reguläre 

Dimension noch näher festlegen. In diesem Beispiel wird "Product name" jetzt als memberCaption-Rolle 

definiert. 

Konvertieren von Dimensionsinformationen in Determinanten 

Beim Verwalten von Modellen, die nicht vollständig den ReportNet 1.x-Empfehlungen entsprechen, 

sollten Sie Abfragesubjekte beibehalten. Dimensionsinformationen werden dann wie folgt 

mit Determinanten verknüpft. 

Dimensionsinformationen Determinanten 

Hierarchien Reihenfolge der Determinanten 

Ebenen Determinanten 

Uniquely Identified 

Group By 

"Unique Key" wurde nicht ausgewählt 

"Unique Key" wurde ausgewählt 

Schlüsselsegmente aus einer höheren Ebene sind im Schlüssel 

enthalten. 

Nur das Schlüsselsegment bzw. die Segmente für die Ebene 

sind im Schlüssel enthalten. 

Attribute Attribute 

Nicht zugeordnete Attribute werden der letzten Determinante 

zugewiesen, die in der Regel der untersten Ebene entspricht. 

Beispielsweise sieht in ReportNet 1.x das Abfragesubjekt "Product" mit den Dimensionsinformationen 

folgendermaßen aus:


Wenn Sie es in ein Abfragesubjekt mit Determinanten konvertieren, sieht es so aus: 

Was Sie überprüfen sollten 

Nach der Konvertierung müssen Sie Folgendes überprüfen: 

• Eindeutig identifiziert 

Das Kontrollkästchen Uniquely Identified gibt an, dass eine Determinante eine Zeile im 

Datensatz eindeutig identifiziert. 

• Gruppieren nach 

Mit dem Kontrollkästchen Group By wird eine obligatorische Gruppierung für jede Abfrage 

mit dieser Determinanten oder für jedes von ihr ermittelte Element veranlasst. Auf diese Weise 

wird die Doppelzählung vermieden, zu der es kommen kann, wenn Dimensionen auf verschiedenen 

Schlüsseln auf unterschiedlichen Granularitätsebenen miteinander verbunden werden. 

Wenn Attributelemente von einer Determinanten mit ausgewähltem Kontrollkästchen Group 

By ermittelt werden, wird auf sie in der Abfrage die Aggregatfunktion Minimum angewendet. 

• Mehrere Hierarchien 

Determinanten unterstützen nicht explizit das Konzept von Hierarchien und bieten kein Verfahren 

für die Darstellung mehrerer Hierarchien. Sind für ein Abfragesubjekt in ReportNet 

1.x zwei Hierarchien vorhanden, wird nur die erste Hierarchie auf eine Determinante aktualisiert. 

Sie müssen ein zweites Abfragesubjekt erstellen und die Determinanten für die andere 

Hierarchie manuell angeben. 




Beispielsweise können Sie das Abfragesubjekt "Product" nach der Aktualisierung zur Verwendung 

von Determinanten noch näher festlegen. In diesem Beispiel ist "Product key" jetzt die eindeutige 

Indentifizierung und "Product line code" und "Product type code" werden für die Gruppierung 

von Abfrageelementen verwendet. 

Weitere Informationen finden Sie unter "Definieren von Dimensionen und 

Determinanten" (S. 17).

Kapitel 2: Das von Cognos 8 generierte SQL 

Das von Cognos 8 generierte SQL wird häufig missverstanden. Dieses Dokument enthält Erklärungen 

zu SQL, das häufig verwendet wird. 

Übersicht über dimensionale Abfragen bei der Verwendung 

von Best Practices 

Dimensionale Abfragen werden erstellt, um Abfragen mehrerer Fakten durchführen zu können. 

Abfragen mehrerer Fakten haben die folgenden grundlegenden Ziele: 

• Beibehaltung von Daten, wenn Faktdaten nicht genau in allgemeinen Dimensionen übereinstimmen, 

z. B. wenn mehr Zeilen in den Fakten als in den Dimensionen vorhanden sind. 

• Verhindern von Doppelzählungen, wenn Faktdaten auf verschiedenen Granularitätsebenen 

vorhanden sind. Dazu muss sichergestellt werden, dass jeder Fakt in einer einzelnen Abfrage 

mit der entsprechenden Gruppierung dargestellt wird. 

Möglicherweise müssen in manchen Fällen Determinanten für die zugrunde liegenden Abfragesubjekte 

erstellt werden. 

Abfrage einzelner Fakten 

Eine Abfrage in einer Sternschemagruppe führt zu einer Abfrage einzelner Fakten. 

Im vorliegenden Beispiel steht "Sales" im Mittelpunkt aller geschriebenen Abfragen. Die Dimensionen 

stellen Attribute und Beschreibungen bereit, um die Daten in "Sales" aussagekräftiger zu 

gestalten. Alle Beziehungen zwischen Dimensionen und dem Fakt sind 1-n. 

Wenn Sie nach Monat und Produkt filtern, erhalten Sie folgendes Ergebnis: 



Abfrage mehrerer Fakten und mehrerer Ebenen von angepassten Dimensionen 


Eine Abfrage mehrerer Fakten und angepasster Dimensionen berücksichtigt die Kardinalität zwischen 

jeder Faktentabelle und ihren Dimensionen und schreibt SQL, um alle Zeilen der jeweiligen 

Tabelle zurückzugeben. 

Zum Beispiel sind "Sales" und "Product Forecast" Kennzahldimensionen. 

Bitte beachten Sie, dass es sich hier um eine vereinfachte Darstellung handelt und nicht um ein Beispiel 

dafür, wie die Darstellung in einem Modell aussehen würde, das mit Best Practices von 

Cognos erstellt wurde. 

Das Ergebnis 

Mit Einzelabfragen von "Sales" und "Product Forecast" nach "Month" und "Product" erhalten 

Sie folgende Ergebnisse: Die Daten unter "Sales" werden auf Tagesebene gespeichert. 

Eine Abfrage nach "Sales" und "Product Forecast" berücksichtigt die Kardinalität zwischen jeder 

Faktentabelle und ihren Dimensionen und schreibt SQL, um alle Zeilen der jeweiligen Tabelle 

zurückzugeben. Die Faktentabellen werden nach ihren gemeinsamen Schlüsseln, "Month" und 

"Product", in Übereinstimmung gebracht und zur niedrigsten gemeinsamen Granularitätsebene 

aggregiert. In diesem Fall werden Tage zu Monaten aufaddiert. Für diese Abfrage werden oft Nullen 

zurückgegeben, da eine Kombination von dimensionalen Elementen möglicherweise zwar in 

einer Faktentabelle existiert, in einer anderen jedoch nicht.


Beachten Sie, dass es für Februar 2004 zwar eine Prognose für "Course Pro Umbrellas" gab, 

jedoch keine tatsächlichen Umsätze. Die Daten in "Sales" und "Product Forecast" befinden sich 

auf verschiedenen Granularitätsebenen. Die Daten für "Sales" befinden sich auf Tagesebene, die 

für "Product Forecast" auf Monatsebene. 

Das SQL 

Das von Cognos 8 generierte SQL, das auch als zusammengefügte Abfrage bezeichnet wird, wird 

oft missverstanden. Eine zusammengefügte Abfrage verwendet mehrere Unterabfragen, eine für 

jeden Stern, die über eine vollständig offene Verbindung auf Grundlage der gemeinsamen Schlüssel 

zusammengeführt werden. Das Ziel ist, sämtliche Mitglieder einer Dimension, die auf einer der 

beiden Seiten der Abfrage erscheinen, beizubehalten. 

Das folgende Beispiel wurde in der Länge bearbeitet und dient als Beispiel, um die Hauptfunktionen 

zusammengefügter Abfragen darzustellen. 

select 

coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME, 

coalesce(D2.PRODUCT_NAME,D3.PRODUCT_NAME) as PRODUCT_NAME, 

D2.EXPECTED_VOLUME as EXPECTED_VOLUME, 

D3.QUANTITY as QUANTITY 

from (select TIME.MONTH_NAME as MONTH_NAME, 

PRODUCT_LOOKUP.PRODUCT_NAME as PRODUCT_NAME, 

XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for 

TIME.CURRENT_YEAR,TIME.QUARTER_KEY,TIME.MONTH_KEY, 

PRODUCT.PRODUCT_LINE_CODE, PRODUCT.PRODUCT_TYPE_CODE, 

PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUME 

from 

(select TIME.CURRENT_YEAR as CURRENT_YEAR, 

TIME.QUARTER_KEY as QUARTER_KEY, 

TIME.MONTH_KEY as MONTH_KEY, 

XMIN(TIME.MONTH_NAME for TIME.CURRENT_YEAR, 

TIME.QUARTER_KEY,TIME.MONTH_KEY ) as MONTH_NAME 

from TIME_DIMENSION TIME 

group by TIME.MONTH_KEY) TIME 

join PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACT 

on (TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY) 

join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY = 

PRODUCT_FORECAST_FACT.PRODUCT_KEY) 

where 

(PRODUCT.PRODUCT_NAME in ('Aloe Relief','Course Pro Umbrella')) and 

(TIME.MONTH_NAME in ('April 2004','February 2004','February 2006')) 

group by 

TIME.MONTH_NAME, 

PRODUCT_LOOKUP.PRODUCT_NAME 

) D2 

full outer join 

(select TIME.MONTH_NAME as MONTH_NAME, 


XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR, 

TIME.QUARTER_KEY, TIME.MONTH_KEY, 


PRODUCT.PRODUCT_KEY ) as QUANTITY 

from 

select TIME.DAY_KEY,TIME.MONTH_KEY,TIME.QUARTER_KEY, 

TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAME 

from TIME_DIMENSION TIME) TIME 

join SALES_FACT SALES_FACT 




on (TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY) 

join PRODUCT PRODUCT on (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY) 

where 


(TIME.MONTH_NAME in ('April 2004','February 2004','February 2006')) 

group by 


PRODUCT.PRODUCT_NAME 

) D3 

on ((D2.MONTH_NAME = D3.MONTH_NAME) and (D2.PRODUCT_NAME = D3.PRODUCT_NAME)) 

Was ist eine Coalesce-Anweisung? 

Eine Coalesce-Anweisung ist einfach eine effiziente Methode für die Arbeit mit Abfrageelementen 

aus angepassten Dimensionen. Sie wird verwendet, um den ersten Wert ungleich null zu akzeptieren, 

der von einem der Abfragesubjekte zurückgegeben wird. Diese Anweisung ermöglicht eine 

vollständige Schlüsselliste ohne Wiederholungen bei Erstellung einer vollständig offenen Verbindung. 

Warum gibt es eine vollständig offene Verbindung? 

Eine vollständig offene Verbindung ist notwendig, um sicherzustellen, dass alle Daten aus allen 

Faktentabellen abgerufen werden. Eine offene Verbindung gibt nur ein Ergebnis aus, wenn ein 

Artikel aus dem Bestand verkauft wurde. Eine rechte offene Verbindung gibt alle Umsätze aus, bei 

denen die Artikel im Bestand waren. Eine linke offene Verbindung gibt alle Artikel im Bestand aus, 

die tatsächlich umgesetzt wurden. Eine vollständig offene Verbindung ist der einzige Weg, herauszufinden, 

was im Lagerbestand vorhanden war und was verkauft wurde. 

Modellieren von 1-n-Beziehungen als 1-1-Beziehungen 

Wenn die Kardinalität so verändert wurde, dass sie nur 1-1-Beziehungen zwischen Abfragesubjekten 

oder Dimensionen verwendet, erzeugt das Ergebnis einer Abfrage für "Product Forecast" und 

"Sales" nach "Time" oder "Time" und "Product" eine einzige Select-Anweisung, die eine der 

Verbindungen unberücksichtigt lässt, um einen Zirkelbezug zu vermeiden. 

Das untenstehende Beispiel zeigt, dass die Abfrageergebnisse nicht korrekt sind, wenn man sie mit 

den Ergebnissen von Einzelabfragen von "Sales" oder "Product Forecast" vergleicht. 

Die Ergebnisse von Einzelabfragen lauten wie folgt: 

Wenn Sie diese Abfragen in einer einzigen Abfrage kombinieren, erhalten Sie folgende Ergebnisse:

Das SQL 


Bei der Betrachtung von SQL zeigt sich, dass Cognos 8 eine der Beziehungen, die für die Vervollständigung 

des Verbindungspfades nicht notwendig waren, nicht einbezogen hat, da erkannt 

wurde, dass im Modell ein zirkulärer Verbindungspfad vorhanden ist. In diesem Beispiel wurde 

die Beziehung zwischen "Time" und "Product Forecast" nicht berücksichtigt. 

Ein zirkulärer Verbindungspfad führt nur selten zu einer Abfrage mit brauchbaren Ergebnissen. 

select 

TIME_.MONTH_NAME as MONTH_NAME, 


XSUM(SALES_FACT.QUANTITY for 

TIME_.CURRENT_YEAR, TIME_.QUARTER_KEY, TIME_.MONTH_KEY, 


PRODUCT.PRODUCT_KEY ) as QUANTITY, 

XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME_.CURRENT_YEAR, 

TIME_.QUARTER_KEY, TIME_.MONTH_KEY, PRODUCT.PRODUCT_LINE_CODE, 

PRODUCT.PRODUCT_TYPE_CODE, PRODUCT.PRODUCT_KEY ) as EXPECTED_VOLUME 

from 

(select TIME.DAY_KEY,TIME.MONTH_KEY, TIME.QUARTER_KEY, 

TIME.CURRENT_YEAR,TIME.MONTH_EN as MONTH_NAME 

from TIME_DIMENSION TIME) TIME 

join 

SALES_FACT on (TIME_.DAY_KEY = SALES_FACT.ORDER_DAY_KEY) 

join 

PRODUCT_FORECAST_FACT on (TIME_.MONTH_KEY = 

PRODUCT_FORECAST_FACT.MONTH_KEY) 

join 

PRODUCT (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY) 

where 


(TIME_.MONTH_NAME in ('April 2004','February 2004','February 2006')) 

group by 

TIME_.MONTH_NAME, PRODUCT.PRODUCT_NAME 

Abfrage mehrerer Fakten und mehrerer Ebenen bei nicht angepassten Dimensionen 

Wenn der Abfrage eine nicht angepasste Dimension hinzugefügt wird, verändert das die Eigenschaften 

des Ergebnisses, das von der zusammengefügten Abfrage ausgegeben wird. Es ist nicht 

mehr möglich, Datensätze auf eine niedrigste gemeinsame Granularitätsebene zu aggregieren, da 

eine Seite der Abfrage eine Dimensionalität hat, die sie nicht mit der anderen Seite gemeinsam hat. 

Das ausgegebene Ergebnis besteht eigentlich aus zwei zusammengeführten Listen. 



Das Ergebnis 


Die Ergebnisse von Einzelabfragen für die betreffenden Sternschemata sehen folgendermaßen aus: 

Die Abfrage derselben Elemente aus beiden Sternschemata führt zu folgendem Ergebnis:


Bei diesem Ergebnis führt die niedrigere Granularitätsebene für Datensätze aus "Sales" dazu, dass 

für jede Monats- und Produktkombination mehr Datensätze ausgegeben werden. Es gibt nun eine 

1-n-Beziehung zwischen den Zeilen, die aus "Product Forecast" zurückgegeben wurden, und 

denen aus "Sales". 

Wenn Sie diese mit dem Ergebnis vergleichen, das im Beispiel für die Abfrage mehrerer Fakten und 

mehrerer Ebenen von angepassten Dimensionen ausgegeben wurde, können Sie sehen, dass mehr 

Datensätze zurückgegeben wurden und die Ergebnisse für "Expected Volume" über mehrere 

Bestellmethoden hinweg wiederholt verwendet wurden. Das Hinzufügen von "Order Method" 

zur Abfrage verändert die Beziehung zwischen den Daten "Quantity" und "Expected Volume" zu 

einer 1-n-Beziehung. Ein einzelner Wert aus "Expected Volume" kann nicht mehr mit einem einzelnen 

Wert aus "Quantity" in Beziehung gesetzt werden. 

Das Gruppieren nach dem Schlüssel "Month" zeigt, dass das Ergebnis in diesem Beispiel auf demselben 

Datensatz beruht wie das Ergebnis der Abfrage mehrerer Fakten und mehrerer Ebenen, 

jedoch mit einem höheren Grad von Granularität. 

Das SQL 

Das für dieses Beispiel generierte zusammengefügte SQL ist dem SQL sehr ähnlich, das in der 

Abfrage mehrerer Fakten und mehrerer Ebenen generiert wurde (S. 34). Der wichtigste Unterschied 

ist das Hinzufügen von "Order Method". "Order Method" ist keine angepasste Dimension 

und beeinflusst nur die Abfrage aus der "Sales Fact"-Tabelle. 

select 

D2.QUANTITY as QUANTITY, 

D3.EXPECTED_VOLUME as EXPECTED_VOLUME, 


coalesce(D2.MONTH_NAME,D3.MONTH_NAME) as MONTH_NAME, 

D2.ORDER_METHOD as ORDER_METHOD 

from 

(select 

PRODUCT.PRODUCT_NAME as PRODUCT_NAME, 

TIME.MONTH_NAME as MONTH_NAME, 

ORDER_METHOD.ORDER_METHOD as ORDER_METHOD, 

XSUM(SALES_FACT.QUANTITY for TIME.CURRENT_YEAR,TIME.QUARTER_KEY, 

TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT 

.PRODUCT_KEY,ORDER_METHOD_DIMENSION.ORDER_METHOD_KEY ) as QUANTITY 

from 

PRODUCT_DIMENSION PRODUCT 

join 

SALES_FACT SALES_FACT 

on (PRODUCT.PRODUCT_KEY = SALES_FACT.PRODUCT_KEY) 

join 

ORDER_METHOD_DIMENSION ORDER_METHOD 

on (ORDER_METHOD.ORDER_METHOD_KEY = SALES_FACT.ORDER_METHOD_KEY) 

join TIME_DIMENSION TIME 

on ( TIME.DAY_KEY = SALES_FACT.ORDER_DAY_KEY) 




where 


( TIME.MONTH_NAME in ('April 2004','February 2004','February 2006')) 

group by 

PRODUCT.PRODUCT_NAME, 


ORDER_METHOD.ORDER_METHOD 

) D2 


(select 

PRODUCT.PRODUCT_NAME as PRODUCT_NAME, 

TIME.MONTH_NAME as MONTH_NAME, 

XSUM(PRODUCT_FORECAST_FACT.EXPECTED_VOLUME for TIME.CURRENT_YEAR, 

TIME.QUARTER_KEY, 

TIME.MONTH_KEY,PRODUCT.PRODUCT_LINE_CODE,PRODUCT.PRODUCT_TYPE_CODE,PRODUCT 

.PRODUCT_KEY ) as EXPECTED_VOLUME 

from 

PRODUCT_DIMENSION PRODUCT 

join 

PRODUCT_FORECAST_FACT PRODUCT_FORECAST_FACT 

on (PRODUCT.PRODUCT_KEY = PRODUCT_FORECAST_FACT.PRODUCT_KEY) 

join 

(select 

TIME.CURRENT_YEAR as CURRENT_YEAR, 

TIME.QUARTER_KEY as QUARTER_KEY, 

TIME.MONTH_KEY as MONTH_KEY, 

XMIN( TIME.MONTH_NAME for TIME.CURRENT_YEAR, TIME.QUARTER_KEY, 

TIME.MONTH_KEY ) as MONTH_NAME 

from 

TIME_DIMENSION TIME 

group by 

TIME.CURRENT_YEAR, 

TIME.QUARTER_KEY, 

TIME.MONTH_KEY 

) TIME 

on ( TIME.MONTH_KEY = PRODUCT_FORECAST_FACT.MONTH_KEY) 

where 


( TIME.MONTH_NAME in ('April 2004','February 2004','February 2006')) 

group by 

PRODUCT.PRODUCT_NAME, 

TIME.MONTH_NAME 

) D3 

on ((D2.PRODUCT_NAME = D3.PRODUCT_NAME) and (D2.MONTH_NAME = 

D3.MONTH_NAME)) 

Auflösen uneindeutig identifizierter Dimensionen und Fakten 

Wenn für uneindeutig identifizierbare Dimensionen und Fakten keine Auflösung herbeigeführt 

wird, können unvorhersehbare oder fehlerhafte Abfragen die Folge sein. Diese Abfragen können 

zu Ergebnissen führen, die Doppelzählungen von Ergebnissen, falsch zugeordnete Ergebnissätze 

und ineffiziente Abfragen enthalten. Ferner können Sie fehlerhafte Auswertungen von Abfragen 

mit mehreren Fakten enthalten. 

In diesem Beispiel müssen Sie die eingekreisten Bereiche klären.


Sie können die eingekreisten Bereiche klären, indem Sie eine Kombination von Datenquellen- und 

Modellabfragesubjekten verwenden. In einigen Fällen kann die Klärung sogar über das Hinzufügen 

von Filtern zu Abfragesubjekten erfolgen, die die Kardinalität von n auf 1 ändern. Die Abfragesubjekte, 

die Sie erstellen, bilden die Basis eines Dimensionsmodells. 

Auflösen von Abfragen, die nicht geteilt werden sollten 

Wenn Abfragen geteilt wurden, die nicht geteilt werden sollten, müssen Sie diese Abfragen auflösen. 

Abfragesubjekte auf der n-Seite aller Beziehungen werden als Fakten identifiziert. Im folgenden 

Beispiel verhalten sich "Order Header" und "Country Multilingual" wie Fakten. Tatsächlich 

jedoch enthält das Abfragesubjekt "Country Multilingual" nur beschreibende Informationen und 

scheint eine Nachschlagetabelle zu sein. In Hinblick auf die Erstellung eines dimensionalen oder 

eines Geschäftsmodells ist "Country Multilingual" eine Erweiterung von "Country". 

Warum ist es ein Problem, das Modell so zu belassen? 

Testen Sie dieses Modell, indem Sie einen Bericht für die Anzahl von Bestellungen pro Stadt und 

pro Land erstellen. Die Verwendung dieses Modells führt zu einem fehlerhaften Ergebnis. Die 

Zahlen für die Städte sind korrekt, jedoch werden für einige Städte falsche Länder angegeben. 

Hier ist ein Beispiel eines fehlerhaft zugeordneten Ergebnisses. 




Wenn Ihnen etwas derartiges auffällt, sollten Sie normalerweise zuerst im SQL nachsehen. 

Das SQL 

Dies ist ein Beispiel für eine zusammengefügte Abfrage. Eine solche ist sinnvoll, wenn Ihr Modell 

mehrere Fakten enthält. Eine zusammengefügte Abfrage ist im Wesentlichen eine Abfrage, die versucht, 

mehrere Fakten zusammenzufügen. Sie verwendet die Beziehungen, die die Fakten zueinander 

in Bezug setzen, ebenso wie die Determinanten für die angepassten oder allgemeinen, im 

Modell festgelegten Dimensionen. Eine zusammengefügte Abfrage kann durch zwei Abfragen mit 

einer vollständig offenen Verbindung identifiziert werden Die Wrapper-Abfrage muss eine Coalesce-Anweisung 

für die angepassten Dimensionen enthalten. 

Bitte beachten Sie die folgenden Probleme im SQL: 

• Die Abfrage hat keine Coalesce-Anweisung. 

• RSUM zeigt den Versuch an, einen gültigen Schlüssel zu erstellen. 

select 

D3.COUNTRY as COUNTRY, 

D2.CITY as CITY, 

D2.number_of_orders as number_of_orders 

from 

(select 

SALES_BRANCH.CITY as CITY, 

XCOUNT(ORDER_HEADER.ORDER_NUMBER for SALES_BRANCH.CITY ) as 

number_of_orders, 

RSUM(1 at SALES_BRANCH.CITY order by SALES_BRANCH.CITY asc local) as sc 

from 

gosales.gosales.dbo.SALES_BRANCH SALES_BRANCH 

join 

gosales.gosales.dbo.ORDER_HEADER ORDER_HEADER 

on (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE) 

group by 

SALES_BRANCH.CITY 

order by 

CITY asc 

) D2 


(select 

COUNTRY_MULTILINGUAL.COUNTRY as COUNTRY, 

RSUM(1 at COUNTRY_MULTILINGUAL.COUNTRY order by 

COUNTRY_MULTILINGUAL.COUNTRY asc local) as sc 

from 

gosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL 

group by 

COUNTRY_MULTILINGUAL.COUNTRY 

order by 

COUNTRY asc 

) D3 

on (D2.sc = D3.sc) 

Offensichtlich werden die zusammengefügten Spalten bei jeder Abfrage auf der Grundlage von 

Kriterien errechnet, die keinen Bezug zueinander haben. Dies erklärt, weshalb es keinen offensichtlichen 

Zusammenhang zwischen den Ländern und den Städten im Bericht gibt. 

Warum also sehen wir eine zusammengefügte Abfrage? Um diese Frage zu beantworten, müssen 

wir das Modell betrachten.


In diesem Beispiel kamen die im Bericht verwendeten Abfrageelemente aus verschiedenen Abfragesubjekten. 

"Country" kam aus "Country Multilingual", "City" kam aus "Sales Branch", und die 

"Number of Orders" kam aus einem Abfragesubjekt zur Zählung von "Order Number" in 

"Order Header". 

Das Problem ist, dass die Abfrage eine Aufteilung vornimmt, da die Abfrage-Engine dies als eine 

Abfrage nach mehreren Fakten betrachtet. Die Aufteilung hat jedoch keinen gültigen Schlüssel für 

das Zusammenfügen, da es kein Element gibt, das beide Fakten gemeinsam haben. 

Es gibt mehrere Möglichkeiten, dieses Problem zu lösen; ein Verständnis der Daten ist dafür 

jedoch unbedingt erforderlich. 

Lösung 1 

Sie können einen Filter zu "Country Multilingual" hinzufügen, der die Kardinalität der Beziehung 

auf 1-1 ändert. 

Select * 

from [GOSL].COUNTRY_MULTILINGUAL 

Where 

COUNTRY_MULTILINGUAL."LANGUAGE"=’EN’ 

Oder Sie können der Beziehung einen Filter hinzufügen, der die Kardinalität auf 1-1 ändert. 

COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE and 

COUNTRY_MULTILINGUAL.LANGUAGE = ’EN’ 

Beide Wege führen zu einem Modell, das in dieser Abfrage nur einen einzelnen Fakt enthält. 

Lösung 2 

Vereinfachen Sie das Modell durch die Konsolidierung der verbundenen Abfragesubjekte. Dieses 

Vorgehen bietet den größten Vorteil, da so das Modell vereinfacht wird und mögliche Fehlerquellen 

bei der Abfragengenerierung reduziert werden. 

Jede Lösung führt zu einem korrekten Abfrageergebnis. 




Das SQL ist keine zusammengefügte Abfrage mehr. 

select 

Country.c7 as COUNTRY, 

SALES_BRANCH.CITY as CITY, 

XCOUNT(ORDER_HEADER.ORDER_NUMBER for Country.c7,SALES_BRANCH.CITY ) as 

number_of_orders 

from 

(select 

COUNTRY.COUNTRY_CODE as c1, 

COUNTRY_MULTILINGUAL.COUNTRY as c7 

from 

gosales.gosales.dbo.COUNTRY COUNTRY 

join 

gosales.gosales.dbo.COUNTRY_MULTILINGUAL COUNTRY_MULTILINGUAL 

on (COUNTRY.COUNTRY_CODE = COUNTRY_MULTILINGUAL.COUNTRY_CODE) 

where COUNTRY_MULTILINGUAL.LANGUAGE='EN' 

) Country 

join 

gosales.gosales.dbo.SALES_BRANCH SALES_BRANCH 

on (SALES_BRANCH.COUNTRY_CODE = Country.c1) 

join 


on (SALES_BRANCH.SALES_BRANCH_CODE = ORDER_HEADER.SALES_BRANCH_CODE) 

group by 

Country.c7, 

SALES_BRANCH.CITY 

Auflösen von Abfragen, die an der falschen Stelle geteilt sind 

Manchmal löst die Verwendung von 1-n-Kardinalität das Problem zirkulärer Verbindungspfade 

nicht. Es werden weiterhin fehlerhafte Ergebnisse ausgegeben, da die zusammengefügte Abfrage 

nicht korrekt formuliert wurde. 

Das Modell enthält beispielsweise die folgenden Objekte.


Wenn Sie beispielsweise einen Bericht für "Sales Target" und "Actual Sales", gruppiert nach "Product" 

und "Sales Staff", ausführen, ist das Ergebnis fehlerhaft. "Actual Sales" ist etwas zu hoch. 

Um das Ergebnis zu prüfen, fragen Sie jeden Fakt einzeln ab. 

Dies bestätigt, dass der erste Bericht ein viel höheres Ergebnis für "Actual Sales" anzeigt, als er 

sollte. 

Das SQL 

Beachten Sie die folgenden Probleme, wenn Sie sich mit SQL beschäftigen: 

• Nur eine der Dimensionsspalten hat eine Coalesce-Anweisung. Dies zeigt, dass die Abfrage 

nicht richtig geteilt worden ist. 

• Die Gruppierung für die Seite "Sales Target" der Abfrage ist richtig. Dies erklärt, warum 

"Sales Target" korrekt ist. 

• Die Seite "Quantity" der zusammengefügten Abfrage ist nur nach "Product" gruppiert, und 

daher ist "Actual Sales" zu hoch. 

select 


D2.LAST_NAME as LAST_NAME, 

D2.SALES_TARGET as SALES_TARGET, 

D3.Actual_sales as Actual_sales 

from 

(select 

Product.PRODUCT_NAME as PRODUCT_NAME, 




SALES_STAFF.LAST_NAME as LAST_NAME, 

XSUM(SALES_TARGET.SALES_TARGET for 

Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME ) as SALES_TARGET 

from 

(select PRODUCT_MULTILINGUAL.PRODUCT_NAME,PRODUCT.PRODUCT_NUMBER from 

gosales.gosales.dbo.PRODUCT PRODUCT, 

gosales.gosales.dbo.PRODUCT_MULTILINGUAL PRODUCT_MULTILINGUAL where 

PRODUCT.PRODUCT_NUMBER = PRODUCT_MULTILINGUAL.PRODUCT_NUMBER) Product 

join 

gosales.gosales.dbo.SALES_TARGET SALES_TARGET 

on (Product.PRODUCT_NUMBER = SALES_TARGET.PRODUCT_NUMBER) 

join 

gosales.gosales.dbo.SALES_STAFF SALES_STAFF 

on (SALES_STAFF.SALES_STAFF_CODE = SALES_TARGET.SALES_STAFF_CODE) 

group by 

Product.PRODUCT_NAME, 

SALES_STAFF.LAST_NAME 

) D2 


(select 


XSUM(XSUM((ORDER_DETAILS.QUANTITY * ORDER_DETAILS.UNIT_SALE_PRICE) for 

Product.PRODUCT_NAME ) at Product.PRODUCT_NAME for Product.PRODUCT_NAME ) 

as Actual_sales 

from 





join 

gosales.gosales.dbo.ORDER_DETAILS ORDER_DETAILS 

on (Product.PRODUCT_NUMBER = ORDER_DETAILS.PRODUCT_NUMBER) 

group by 

Product.PRODUCT_NAME 

) D3 

on (D2.PRODUCT_NAME = D3.PRODUCT_NAME) 

Der Grund für diese Probleme ist, dass in "Order Header" nichts ausgewählt wurde. Dies war 

nicht in der Abfrage enthalten, sodass es keine Möglichkeit gab, "Sales Staff" zu "Order Details" 

in Beziehung zu setzen. Es war nicht notwendig, "Sales Staff" zu "Order Details" in Beziehung zu 

setzen, um alle Tabellen miteinander zu verbinden, da es bereits eine Beziehung zwischen "Sales 

Staff" und "Sales Target" gab. 

Obwohl Sie dies lösen können, indem Sie ein Element aus "Order Header" in den Bericht übernehmen, 

wissen Ihre Benutzer unter Umständen nicht, wie sie verfahren sollen. Wir empfehlen 

Ihnen, dies Problem im Modell zu beheben. Dies ist die empfohlene Lösung sowohl für die Erstellung 

eines dimensionalen als auch eines Geschäftsmodells. Darüber hinaus ist es mit einem einfacheren 

Modell schwieriger, einen Bericht auszuführen, der schlechtes SQL generiert. 

Konsolidieren Sie Abfragesubjekte, wenn logische Gruppierungen möglich sind. Kombinieren Sie 

in diesem Beispiel die Abfragesubjekte "Order Details" und "Order Header". Die neue Gruppe 

von Abfragesubjekten kann nun für die dimensionale Modellierung verwendet werden.


Wenn Sie diese neue Gruppe von Abfragesubjekten verwenden, sieht Ihr Bericht so aus. 

Wenn Sie das SQL betrachten, sehen Sie Folgendes: 

select 


coalesce(D2.LAST_NAME,D3.LAST_NAME) as LAST_NAME, 

D2.SALES_TARGET as SALES_TARGET, 

D3.Actual_sales as Actual_sales 

from 

(select 



XSUM(SALES_TARGET.SALES_TARGET for 

Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME ) as SALES_TARGET 

from 





join 

gosales.gosales.dbo.SALES_TARGET SALES_TARGET 

on (SALES_TARGET.PRODUCT_NUMBER = Product.PRODUCT_NUMBER) 

join 


on (SALES_STAFF.SALES_STAFF_CODE = SALES_TARGET.SALES_STAFF_CODE) 

group by 



) D2 


(select 



XSUM((ORDER_DETAILS_ORDER_HEADER.c5 * ORDER_DETAILS_ORDER_HEADER.c8) for 

Product.PRODUCT_NAME,SALES_STAFF.LAST_NAME ) as Actual_sales 




from 





join 

(select 

ORDER_DETAILS.PRODUCT_NUMBER as c4, 

ORDER_DETAILS.QUANTITY as c5, 

ORDER_DETAILS.UNIT_SALE_PRICE as c8, 

ORDER_HEADER.SALES_STAFF_CODE as c14 

from 

gosales.gosales.dbo.ORDER_DETAILS ORDER_DETAILS 

join 


on (ORDER_HEADER.ORDER_NUMBER = ORDER_DETAILS.ORDER_NUMBER) 

) ORDER_DETAILS_ORDER_HEADER 

on (ORDER_DETAILS_ORDER_HEADER.c4 = Product.PRODUCT_NUMBER) 

join 


on (SALES_STAFF.SALES_STAFF_CODE = ORDER_DETAILS_ORDER_HEADER.c14) 

group by 



) D3 

on ((D2.PRODUCT_NAME = D3.PRODUCT_NAME) and (D2.LAST_NAME = D3.LAST_NAME)))

Index 

Numerics 

1-zu-1-Beziehungen, 9, 36 

1-zu-n-Beziehungen, 9, 36 

A 

Abfrage ohne Fakten, 24 

Abfragen 

einzelner Fakt, 33 

geteilte, 40, 43 

mehrere Ebenen, 18 

mehrere Fakten, 18, 34, 37 

ohne Fakten, 24 

zusammengefügte, 8 

Abfragen einzelner Fakten, 33 

Abfragen mehrerer Ebenen, 18, 34, 37 

Abfragen mehrerer Fakten, 18, 34, 37 

Abfragesubjekte 

Determinanten, 30 

Dimensionen, 18 

in Dimensionen konvertieren, 28 

Sternschemagruppen, 24 

aktualisieren 

Datentypen, 26 

Aktualisieren von Modellen, 26 

konvertieren, 28, 30 

reparieren, 27 

überprüfen, 26 

von ReportNet 1.x, 25 

Warnungen, 27 

Angepasste Dimensionen 

mehrere Fakten, 34, 37 

angepasste Sternschemagruppen, 24 

Attribute, 28, 30 

Auflösen 

geteilte Abfragen, 40, 43 

uneindeutige Objekte, 40 

B 

Bereichsbeziehungen, 7 

Bezeichner 

eindeutige, 6 

Beziehungen 

1-n, 9, 36 

Bereich, 7 

Granularitätsebenen, 16 

mehrere gültige, 13 

n-zu-n, 8 


C 

Copyright, 2 

D 

Datenquellendimensionen, 18 

Datentypen, 26 

Determinanten, 6 

aktualisieren auf, 27 

aus Dimensionsinformationen konvertieren, 30 

definieren, 17 

Kardinalität, 8 


Dimensionale Abfragen, 33 

einzelner Fakt, 33 

mehrerer Fakten und Ebenen, 34, 37 

Dimensionales Modellieren relationaler Metadaten, 7 

Dimensionen 

Abfragesubjekte, 18 

aktualisieren auf, 27 

aus Abfragesubjekten konvertieren, 28 

Bereichsbeziehungen, 7 

Datenquelle, 18 


Hierarchien, 22 

identifizieren, 10 

Kennzahl, 7, 12, 17 

mit unterschiedlichen Rollen, 13 

Modell, 18 

reguläre, 7, 12, 17, 18 



uneindeutig, 40 

Dimensionen mit unterschiedlichen Rollen, 13 

Dimensionsinformationen, 28, 30 

Dokument 

Version, 2 

Doppelzählung, 6, 9, 36, 40 

E 

Ebenen, 7, 28, 30 

Eindeutige Bezeichner, 6 

Eindeutige Schlüssel, 28, 30 

erstellen 

Kennzahldimensionen, 12 

reguläre Dimensionen, 12 


F 

Fakten, 7, 12 

identifizieren, 10 

uneindeutig, 40 

Faktübergreifende Abfragen, 10 


Index 

G 

Gemeinsame Dimensionen, 17 

Geteilte Abfragen, 40, 43 

Granularität, 16 

Gültige Beziehungen 

mehrere, 13 

H 

Hierarchien, 7, 17, 18, 28, 30 

mehrere, 22 

I 

Importierte Metadaten 


K 

Kardinalität 

1-1, 36 

1-n, 36 

Abfragen, 9 

Datenquelle, 8 

Dimensionen und Fakten, 10 

Regeln, 9 

Typen, 9 


Kardinalitätsregeln, 9 

Kennzahldimensionen, 7 


erstellen, 12 


M 

Master/Detail-Tabellen, 12 

Maximale Kardinalität, 9 

Mehrere gültige Beziehungen, 13 

Mehrere Hierarchien, 22 

Minimale Kardinalität, 9 

Modelldimensionen, 18 

Modelle 

aktualisieren, 26 

reparieren, 27 


N 

n-zu-n-Beziehungen, 8 

O 

Obligatorische Kardinalität, 9 

Offene Verbindungen 

vollständig, 8 

Optionale Beziehungen, 8 

Optionale Kardinalität, 9 

R 

Reflexive Beziehungen, 16 

reguläre Dimensionen, 7, 18 

erstellen, 12 


reguläre Dimensionen (Fortsetzung) 


Rekursive Beziehungen, 16 

Reparieren von Modellen, 27 

S 

Schlüssel, 8, 28, 30 

SQL, 33 

Sternschemagruppen 

erstellen, 24 

mehrere angepasste, 24 

U 

Überprüfen von Modellen, 26, 27 

Uneindeutige Objekte, 40 

V 

Verbindungen 

vollständig offene, 8 

zirkuläre, 43 

Vereinfachen von Modellen, 11 

Version 

Dokument, 2 

Vollständig offene Verbindungen, 8 

W 

Workflows, 7, 25 

Z 

Zirkuläre Verbindungen, 43 

Zusammengefügte Abfragen, 8

COGNOS(R) 8

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?