Entwerfen von cubebasierten Berichtsmodellen
Berichtsmodelle werden mithilfe des Berichts-Managers oder, wenn die Ausführung im integrierten SharePoint-Modus erfolgt, mit MicrosoftOffice SharePoint Server 2007 aus SQL ServerAnalysis Services (SSAS)-Cubes generiert. Zum Erstellen eines Berichtsmodells aus einem SSAS-Cube müssen Sie Administrator der Analysis Services-Datenbank sein. Nachdem das Modell einmal generiert wurde, kann es nicht verändert werden. Wenn Sie den Inhalt der Datenbank ändern, müssen Sie das Modell erneut generieren, um die Änderungen ins Modell zu übernehmen.
Verbindungszeichenfolgen
Wenn Sie ein Berichtsmodell anhand einer Analysis Services-Datenbank erstellen, wird die Verbindungszeichenfolge in etwa wie folgt angezeigt:
Data Source=<reportserver>;Initial Catalog=<database name>
.gif "Hinweis") Hinweis |
|---|
Wenn die Analysis Services-Datenbank Cubeübersetzungen enthält, können Sie übersetzte Versionen des Berichtsmodells erstellen. Geben Sie zum Erstellen jeweils eines Modells für jede Sprache in der Verbindungszeichenfolge der Datenquelle den Gebietsschemabezeichner (Locale ID, LCID) an. Wenn Sie z. B. ein Modell für Chinesisch erstellen möchten, sollte die Verbindungszeichenfolge in etwa wie folgt aussehen: Data Source=<reportserver>;Initial Catalog=<database name>;LocaleIdentifier=3012. Weitere Informationen zu Cubeübersetzungen finden Sie unter Cubeübersetzungen. |
Regeln für das Generieren von Modellen aus Analysis Service-Datenbanken
Die folgende Liste enthält allgemeine Regeln, die für das Erstellen von Modellen aus Cubes gelten:
Measuregruppen werden Entitäten zugeordnet. Ein einzelnes Berichtsmodell enthält alle Cubes der Analysis Services-Datenbank.
Dimensionen werden Entitäten zugeordnet. Faktendimensionen ergeben keine separaten Entitäten. Angenommen, ein Cube enthält eine Sale-Measuregruppe sowie eine Faktendimension namens Sale Detail. Beim Generieren eines Modells aus diesem Cube wird eine einzelne Entität generiert, die alle Measures von Sale und alle Dimensionsattribute von Sale Detail enthält.
Beziehungen zwischen Measuregruppen und Dimensionen werden in Rollen innerhalb des Modells konvertiert. Referenzierte Beziehungen (für indirekte Beziehungen verwendet) und m:n-Beziehungen werden im Modell als Rollen definiert.
Measures werden in Entitätsattribute konvertiert.
Dimensionsattribute werden in Entitätsattribute konvertiert. Modelle verfügen über keine Hierarchien. Ein Dimensionsattribut wird daher in das Modell eingeschlossen, wenn es sichtbar ist oder eine sichtbare Hierarchie mit einer auf ihm basierenden Ebene vorhanden ist. Das Schlüsselattribut einer Dimension wird immer eingeschlossen, selbst wenn es als unsichtbar markiert ist.
Die Entitätsattribute aus den Measures und Dimensionsattributen sind in Ordnern entsprechend den im Cube definierten Anzeigeordnern organisiert.
Cubeperspektiven werden zu Berichtsmodellperspektiven. Darüber hinaus wird jeder Cube zu einer Perspektive innerhalb des Modells. Benutzer des Berichts-Generators müssen daher eine Perspektive innerhalb des Modells und nicht das Modell oberster Ebene auswählen.
Berechnete Measures (berechnete Elemente) werden zu Attributen der Entität, die der Measuregruppe entspricht, der die Measures zugeordnet sind.
Für Schlüsselattribute einer Dimension definierte benannte Mengen werden in einen Untertyp der Entität konvertiert. Die benannte Menge "Large Customers" ergibt z. B. einen Untertyp von "Customer". Benannte Mengen, die nicht auf einem einzelnen Schlüsselattribut basieren, werden ignoriert.
Key Performance Indicators (KPIs) werden in Attribute der Entität konvertiert, die der Measuregruppe entspricht, der der KPI zugeordnet ist. Für jeden KPI werden mehrere Attribute erstellt, die den unterschiedlichen Komponenten des KPIs (Wert, Ziel, Status und Trend) entsprechen. Außerdem wird jeweils ein Variationsattribut für Status und Trend erstellt, das das StatusGraphic- bzw. das TrendGraphic-Attribut enthält. Bei Verwendung dieser Attribute wird das aktuelle Bild in den Bericht eingefügt.
Nicht in Berichtsmodelle übernommene Analysis Services-Datenbankelemente
Die folgenden SSAS-Elemente werden nicht ins generierte Modell übernommen:
Berechnete Elemente (die sich nicht in der Measuredimension befinden)
Parent-Child-Hierarchien werden nicht in Modellattribute oder Rollen konvertiert. Das Schlüsselattribut wird zwar übernommen, allerdings werden bei der Verwendung dieses Attributs in einem Bericht Werte für das Schlüsselelement und nicht der aggregierte Wert für die Parent-Child-Hierarchie angezeigt. Außerdem wird die Leistung beeinträchtigt.
Aktionen. Das gilt auch für Drillthroughaktionen. Drillthroughfunktionen sind für Aggregatattribute stets aktiviert, unabhängig von den im Cube definierten Drillthroughaktionen. Wenn ein Benutzer einen Berichts-Generator-Bericht für das Modell ausführt und auf ein Aggregat klickt, um einen Bericht mit Durchklicken anzuzeigen, werden leere Tabellen angezeigt.
Attributbeziehungen. Eine Dimension ergibt eine einzelne Entität. Die Beziehungen zwischen den Attributen der Dimensionen werden im Berichtsmodell nicht berücksichtigt.
Beziehungen zwischen einer Measuregruppe und einer Dimension werden ignoriert, wenn sie auf einem anderen Attribut als dem Schlüsselattribut der Dimension basieren. Die Budget-Measuregruppe könnte beispielsweise mit Time auf der Month-Ebene und nicht auf der Day-Ebene verknüpft sein. In diesem Fall würde das Berichtsmodell keine Beziehung zwischen der Budget-Entität und der Time-Entität enthalten.
Überlegungen zum Entwurf von Cubes
Berücksichtigen Sie beim Entwerfen eines Cubes, aus dem Sie ein Berichtsmodell generieren möchten, Folgendes:
Berechnete Measures oder KPIs, die keiner Measuregruppe zugeordnet sind, werden im Berichtsmodell nicht berücksichtigt. Verwenden Sie zum Konfigurieren der zugeordneten Measuregruppe für ein berechnetes Measure das Dialogfeld Berechnungseigenschaften.
Vom Berichts-Generator gesendete Abfragen fordern stets den Elementwert von Dimensionselementen an und verwenden diesen zum Sortieren und Filtern. Wenn ein Attribut über eine Namensbindung verfügt, entspricht in Analysis Services standardmäßig der Elementwert dem Elementnamen, und wenn das Attribut über keine Namensbindung verfügt, entspricht der Elementwert dem Elementschlüssel. Jedes Attribut kann jedoch explizit an eine Spalte gebunden werden, die den Elementwert bereitstellt, wodurch der Wert im "echten" Datentyp zurückgegeben werden kann. Ein Date-Attribut in Analysis Services könnte beispielsweise über einen DateTime-Schlüssel (z. B. "4/25/2008") und einen Namen/eine Beschriftung verfügen, bei dem/der es sich um eine Textbeschreibung ("Friday, 25th April, 2008") handelt. In einem solchen Fall sollte der Cubeentwickler MemberValue auf den Schlüssel festlegen, um eine sinnvolle Sortierung und Filterung sicherzustellen. Zwar sollten Sie erwägen, grundsätzlich bei allen Attributen so vorzugehen, besonders relevant ist es aber für datetime-Attribute. Zu jedem datetime-Attribut enthält das generierte Modell zwei Berichtsmodellattribute: eines, das die Beschriftung enthält, und eine Variante davon, die den tatsächlichen datetime-Wert enthält.
Die Dimensionsattributeigenschaft InstanceSelection wird zum Festlegen der Berichtsmodelleigenschaften InstanceSelection (bei Entitäten) und ValueSelection (bei Attributen) verwendet. Dadurch wird bestimmt, wie ein Benutzer Instanzen im Berichts-Generator auswählen kann (z. B. über eine Dropdownliste).
Die Dimensionsattributeigenschaft GroupingBehavior wird zum Festlegen der Modellattributeigenschaft DiscourageGrouping verwendet.
Für alle Dimensionsattribute, die Bilder sind, muss der Image-Datentyp für die Dimensionsattributbindung festgelegt sein.
Drillthroughfunktionen sind für Attribute, die sich aus Measures ergeben haben, stets aktiviert. Die Standard-Drillthroughberichte enthalten jedoch nur minimale Details. Daher sollten zur Anpassung bei Bedarf benutzerdefinierte Drillthroughberichte hinzugefügt werden.
Wenn Übersetzungen im Cube enthalten sind, muss pro Übersetzung eine Datenquelle erstellt werden, um die Übersetzungen im Berichtsmodell durch entsprechendes Festlegen der LocaleIdentifier-Eigenschaft in der Verbindungszeichenfolge verfügbar zu machen. Für jede Datenquelle wird dann ein Modell generiert, das die Metadaten aus der zugeordneten Übersetzung enthält.