2014-08-30

Business Analyse: Entscheidender Erfolgsfaktor in BI Projekten

Es ist ein unschätzbarer Vorteil meines Berufs, dass ich viele unterschiedliche BI Projekte erlebe. Interessanterweise sehe ich dabei einige Unternehmen, in denen BI Projekte fast immer sehr erfolgreich sind und andere Unternehmen, wo BI Projekte regelmäßig katastrophenähnliche Zustände annehmen. Unter "erfolgreich" verstehe ich Projekte, die im geplanten Zeitrahmen alle vorgesehenen Berichte und Analysen zur vollen Zufriedenheit der Anwender liefern und dabei mit dem veranschlagten Budget auskommen. Die nicht erfolgreichen Projekte hingegen liefern Ergebnisse nur verspätet und die Anwender sind damit dann auch noch unzufrieden. Wegen der wiederholten Terminverschiebungen und unerwarteten Arbeiten sieht sich der Auftraggeber gezwungen, das Budget immer wieder aufzustocken oder irgendwann das Projekt abzubrechen.

Wenn aber doch alle Verantwortlichen den Erfolg wollen, warum sind dann nicht alle Projekte erfolgreich? Was machen die erfolgreichen Unternehmen besser?

Es gibt eine augenfällige Gemeinsamkeit: Bei allen erfolgreichen  Projekten erhebt ein Business Analyst die Anforderungen und pflegt diese während des gesamten Projektverlaufs. In diesen Unternehmen ist es üblich, dass erst wenn die Anforderungen hinreichend geklärt sind (hinreichend mit Blick auf die Vorgehensweise wie plangesteuert oder agil), mit der Umsetzung begonnen wird. Alle Projektverantworlichen haben diese Regel verinnerlicht.
In den anderen  Unternehmen sind Aussagen wie diese an der Tagesordnung:
  • Für Analysen haben wir jetzt keine Zeit
  • Für Analysen steht kein Budget bereit
  • Wir wissen sowieso, was die Anwender brauchen
  • Das Projekt ist so klein, dass der Aufwand für eine Analyse sich nicht lohnt
  • Wir haben das immer so gemacht
Das Interessante ist, dass bei ALLEN so durchgeführten Projekten der Misserfolg gewiss ist.
 
Inzwischen hat sich in Bezug auf die Business Analyse weltweit bei immer mehr Unternehmen die Erkenntnis durchgesetzt, dass sie ein wesentlicher Erfolgsfaktor bei allen Projekten ist. Das International Institute for Business Analysis (IIBA) hat eine umfassende Herangehensweise erarbeitet mit zwei Zertifizierungen (hier finden Sie mehr) und kürzlich hat das Project Management Institute (PMI) ebenfalls eine entsprechende Zertifizierung herausgegeben (hier mehr).
 
Zum Schluss noch mein Lieblingsargument gegen den Einsatz von Business Analyse in BI Projekten: "Dieses Vorgehen schränkt das Team in seiner Kreativität ein." Seien Sie versichert, das Gegenteil ist der Fall! Immer wenn ich in einem Projekt mitarbeite, das aus dem Krisenmodus nicht herauskommt, sehne ich mich nach den gut analysierten Projekten, in denen wir unsere Energie nicht in die Bewältigung vorhersehbarer Probleme stecken mussten, sondern uns ganz dem Erarbeiten der fachlich, wirtschaftlich und technisch besten Lösung widmen konnten.
 

Webinar-Tipp

Am Donnerstag, den 4. September 2014, biete ich von 10:00 bis 11:00 Uhr ein Webinar "Anforderungsanalyse für Business Intelligence Projekte" an.

2014-06-09

SQL Server Data Tools - die Entwicklungsumgebung für Datenbankentwickler

Mit welchen Werkzeugen haben sie bisher Ihre Datenbanktabellen, Views und Stored Procedures erstellt? Die SQL Server Umgebung bot hier bisher nur wenig Unterstützung, so dass Entwicklerteams auf Produkte von Drittanbietern angewiesen waren. Das ändert sich durch die SQL Server Data Tools (SSDT), die Microsoft lizenzkostenfrei anbietet.

"BI or not BI" - Begriffsklärung

Die Namensgebung ist etwas verwirrend, denn wenn Sie bereits mit SQL Server 2012 arbeiten und die Reporting Services, Integration Services oder Analysis Services einsetzen, dann haben Sie bereits "Data Tools" installiert. Diese heißen jetzt zur Unterscheidung mit vollem Namen "SQL Server Data Tools – Business Intelligence" (SSDT-BI). Darüber habe ich bereits in diesem Blogbeitrag geschrieben.

Hier geht es nun um die Server Data Tools (SSDT) für die Entwicklung von Datenbank-Projekten.

Einsatz

SSDT kommt dem Bedürfnis von Projektteams entgegen, Datenbankprojekte genauso wie BI Projekte in Visual Studio zu entwickeln und dabei eine Quellcodeverwaltung (z.B. Team Foundation Server TFS) einzusetzen. Zu diesem Zweck gibt es neben dem Online-Arbeiten, wo Änderungen direkt auf die Datenbankobjekte angewendet werden, die Offline-Projekte, wo Entwickler auch ohne direkte Verbindung zum SQL Server Objekte wie Tabellen etc. modellieren können. Grafische Editoren für Tabellen, Views, Stored Procedures usw. erleichtern und beschleunigen diese Arbeiten sehr.
Darüber hinaus bietet der Schema-Vergleich die Möglichkeit, ALTER-Skripte zu generieren, mit denen beispielsweise der Stand der Produktionsdatenbank auf den der Test-Datenbank gebracht wird - eine ganz wichtige Arbeitserleichterung. Auch für den Vergleich und das Angleichen von Daten in Tabellen gibt es ein Werkzeug. Und beim Überarbeiten umfangreicher SQL-Skripte, zum Beispiel dem Umbenennen einer Tabellenspalte, identifiziert die Funktion "Refactor" alle Referenzen, die in Folge ebenfalls angepasst werden müssen.
Mein erster Eindruck ist, dass hier kein Wunsch offen bleibt und ich bin gespannt, was nach einigen Wochen Projekterfahrung mit SSDT zu ergänzen ist. SSDT unterstützt als Quell- und Zieldatenbanken die SQL Server Versionen 2005 bis 2014 sowie SQL Azure. 

Eindrücke

Die folgenden Bilder geben einen kleinen Eindruck von der Entwicklungsumgebung. Eine anschauliche Schritt-für-Schritt Anleitung stellt Microsoft hier bereit: Dokumentation zu SSDT 
 
Der Schemavergleich zeigt Unterschiede in den Strukturen zweier Datenbanken und generiert ein passendes ALTER Skript.
 
 
Der Datenvergleich zeigt die unterschiedlichen Daten in zwei Tabellen und generiert ein Skript, um die Inhalte anzugleichen.
Der linke Teil zeigt die grafische und die Skript-Darstellung einer Tabelle, während der rechte Teil die Projektstruktur anzeigt.
 

Installation

Die SQL Server Data Tools können Sie hier herunterladen. Es gibt einen Web-Installer sowie ein ISO-Image, das die Installation ohne Internetzugang ermöglicht. Wenn Sie bereits die Professional, Ultimate oder Premium Edition von Visual Studio 2012 installiert haben, dann ist SSDT bereits darin enthalten. Wenn Sie jedoch noch kein Visual Studio 2012 auf dem Computer installiert haben, dann erhalten Sie bei der Installation die Visual Studio 2012 Shell, die keine Unterstützung für die Programmiersprachen wie C# oder Visual Basic bietet.
Die Visual Studio Shell wird übrigens auch bereitgestellt, wenn Sie die SQL Server Data Tools für BI (SSDT-BI) installieren. Wenn Sie SSDT und SSDT-BI installieren, dann integrieren sie sich in dieselbe Visual Studio Shell.
Fazit: Egal, ob Sie eine Vollversion von Visual Studio haben oder nicht, beide Projekttypen integrieren sich in dieselbe Entwicklungsumgebung.

Alle Links auf einen Blick


Download der SSDT
Dokumentation zu SSDT
Übersicht der SQL Server Data Tools

2014-06-05

Data Tools für Business Intelligence

Die Installations-DVD von SQL Server 2012 enthält - wie die vorherigen Versionen auch - als Entwicklungsumgebung für die BI-Komponenten eine Version von Visual Studio. Diese trägt zwar aus Marketing-Gründen die Bezeichnung "SQL Server Data Tools", ist aber nichts anderes als Visual Studio 2010 mit den Projektvorlagen für Business Intelligence Projekte (Reporting Services, Integration Services, Analysis Services).

Zwei Versionen der SQL Server Data Tools: VS2010 und VS2012

Seit März 2013 ist die Situation etwas komplizierter geworden, da es zusätzlich möglich ist, Visual Studio 2012 als BI Entwicklungsumgebung einzusetzen. Der korrekte Name für diese Version ist "SQL Server Data Tools – Business Intelligence for Visual Studio 2012". Diese neuere Version der Data Tools steht hier zum Herunterladen bereit:
http://www.microsoft.com/en-us/download/details.aspx?id=36843

Wenn zwei Versionen verfügbar sind, welche sollten Sie dann einsetzen? Glücklicherweise vertragen sich beide Versionen sehr gut, so dass ein Projektteam sogar beide gleichzeitig einsetzen kann:
  • Beide Versionen lassen sich nebeneinander auf einem Rechner installieren
  • Projekte können abwechselnd mal mit der neueren und dann wieder mit der älteren Version bearbeitet werden - es findet keine Konvertierung der Dateien statt
Sie haben also die freie Wahl, mit welcher Version Sie arbeiten.

Und was ist mit Visual Studio 2013?

Die Produktzyklen bei Microsoft werden kürzer, so ist bereits Visual Studio 2013 verfügbar und auch SQL Server 2014 ist bereits seit April auf dem Markt. Die gute Nachricht ist: Da es an den BI Komponenten von SQL Server 2014 keine Veränderungen gegenüber SQL Server 2014 gegeben hat, können Sie problemlos mit den "alten" Data Tools für SQL Server 2012 auch für SQL Server 2014 entwickeln.
Falls Sie die letzte verfügbare Entwicklungsumgebung einsetzen möchten, können Sie hier die "Microsoft SQL Server Data Tools - Business Intelligence for Visual Studio 2013 " herunterladen:
http://www.microsoft.com/en-us/download/details.aspx?id=42313

Zusammenfassung

Diese Matrix stellt das vorher Beschriebene in kompakter Form dar:

  Visual Studio 2010 Visual Studio 2012 Visual Studio 2013
SQL Server 2012 auf Installations-DVD SSTD-BI für SQL Server 2012 --
SQL Server 2014 -- SSTD-BI für SQL Server 2012 SSTD-BI für SQL Server 2014

Einfache Installation

Die Installation ist unkompliziert. Nach dem Download und Start der Installationsdatei sollten Sie die Standardeinstellung "Perform a new Installation..." belassen, wie das folgende Bild zeigt (die andere Option führt zu einem Abbruch der Installation).

Diese Standardeinstellung sollten Sie nicht ändern

Danach stehen die Data Tools als Shared Feature für die Installation zur Verfügung.

Außer dem Setzen dieses Hakens gibt es keine weiteren Auswahlmöglichkeiten




Quelle:
http://blogs.msdn.com/b/mattm/archive/2013/03/07/sql-server-data-tools-business-intelligence-for-visual-studio-2012-released-online.aspx

2014-05-20

Freigegebene Datenquellen und Datasets richtig einsetzen

Reporting Services (SSRS) bieten ja die Möglichkeit, zwei unterschiedliche Entwicklungsumgebungen für Berichte zu verwenden:
  • Report Designer in Visual Studio (bzw. "Business Intelligence Studio" oder "Data Tools", wie es aus Marketinggründen heißt, wenn es mit SQL Server installiert wird)
  • Report Builder, den berechtigte Anwender selbst von SharePoint oder vom Report Manager herunterladen und nutzen können
Report Builder mit seiner an Office Anwendungen angelehnten Oberfläche für Fachanwender

Während Report Designer eher das Werkzeug für IT-Profis ist, soll der Office-ähnlich aufgemachte Report Builder Mitarbeitern in den Fachabteilungen die Möglichkeit geben, selbständig Berichte zu erstellen. Eine gute Ergänzung, die gleichermaßen der Forderung nach qualitätsgesicherten Standard-Berichten von der IT-Abteilung und dem Bedürfnis nach hoher Flexibilität für die Fachanwender gerecht wird.

Nun haben IT-Verantwortliche naturgemäß Schwierigkeiten damit, allen Anwender direkten Zugriff auf die Unternehmensdatenbanken zu gewähren. Das ist ja auch nachvollziehbar, denn in diesem Fall könnten einzelne Berichtsautoren durch (ungewollt) massive Datenbankabfragen die Verfügbarkeit für alle Anwender gefährden. Hier kommen freigegebene Datenquellen (shared data sources) und freigegebene Datasets (shared datasets) ins Spiel. Datenquellen enthalten die Verbindungszeichenfolge zu einer Datenbank (Server, Datenbank, Benutzername und Passwort), während Datasets die SQL Abfrage enthalten. Das ermöglicht eine klare Rollenverteilung:
  • Alle Anwender, die direkten Zugriff auf eine Datenbank haben, dürfen freigegebene Datenquellen und freigegebene Datasets hierfür erstellen und modifizieren.
  • Anwender, die keinen Zugriff auf eine Datenbank haben, können dennoch die freigegebenen Datenquellen und die freigegebenen Datasets in eigenen Berichten nutzen.
  • Wenn Anwender ohne Zugriff auf eine Datenbank versuchen, eine Datenquelle oder ein Dataset zu verändern, erhalten sie die Aufforderung, einen Datenbankbenutzer samt Passwort anzugeben.
Auf diese Weise ist sichergestellt, dass nur eingewiesene Programmierer die SQL Abfragen erstellen. Die IT Verantwortlichen behalten so die Kontrolle über die Art des Zugriffs auf die Datenbank. Gleichzeitig können Fachanwender auf Basis dieser Datasets ihre eigenen Berichte erstellen.

Wäre noch zu klären wie es sein kann, dass Fachanwender ohne direkten Datenbankzugriff dennoch über die vorhandenen Datenquellen und Datasets die Berichtsdaten abrufen können. Dazu muss ein Mitglied der Rolle "Content Manager" auf dem Report Manager den Eigenschaften-Dialog der Datenquelle öffnen.

Hier erhält die Datenquelle Zugriff auf die Datenbank

Der Benutzername und das Kennwort des hier angegebenen Benutzerkontos werden verschlüsselt auf dem Berichtsserver gespeichert. Bitte achten Sie darauf, hier einen technischen Benutzer und nicht die Anmeldeinformationen eines echten Mitarbeiters anzugeben, denn wenn dieser sein Kennwort ändert, dann funktioniert die Datenquelle nicht mehr.
Diese Funktionsweise von freigegebenen Datenquellen und Datasets ist unabhängig davon, ob Reporting Services im nativen Modus ("stand-alone") oder im SharePoint integrierten Modus laufen. Einziger Unterschied ist, dass im ersten Fall die Webanwendung "Berichts-Manager" den Speicherort für Quellen, Datasets und Berichte bereitstellt und im zweiten Fall SharePoint Bibliotheken diese Aufgabe übernehmen.

2014-04-22

Kostenloses E-Book zu SQL Server 2014

So wie schon für die letzten beiden Versionen von SQL Server haben nun die beiden Autorinnen Ross Mistry und Stacia Misner ein E-Book zum SQL Server 2014 geschrieben. Es behandelt die Neuerungen gegenüber der Version 2012 und ist dank des anschaulichen Schreibstils, klarer Abbildungen und prägnanter Codebeispiele wieder sehr nützlich für alle, die sich mit den neuen Möglichkeiten vertraut machen möchten.

Dieses E-Book ist kostenfrei bei Microsofts Virtual Academy zum Download erhältlich:
http://www.microsoftvirtualacademy.com/ebooks

Meine Empfehlung an alle, die bereits mit den früheren SQL Server Versionen vertraut sind und die SQL Server 2014 verstehen und einsetzen möchten: Unbedingt lesen!

2014-02-28

Beziehungen zwischen Tabellen dokumentieren

"Herzlichen Glückwunsch - Sie haben eine Datenbank gewonnen!" Mit diesen Worten bekam ich vor einigen Jahren anlässlich der Verabschiedung eines Kollegen die Verantwortung für den Betrieb und die Weiterentwicklung einer Datenbank überreicht. Wie Sie sich vorstellen können, hatte ich daraufhin erst einmal einiges an Arbeit, um mir einen Überblick über Art und Umfang des "Geschenks" zu verschaffen.

Beziehungen automatisch dokumentieren


Insbesondere um die existierenden Abfragen gegen die nicht so gut dokumentierte Datenbank zu verstehen und weiterentwickeln zu können, brauchte ich schnell eine Zusammenstellung der Beziehungen zwischen den Tabellen:
  • von Tabelle
  • nach Tabelle
  • Namen der Primär- und Fremdschlüsselspalten
Die folgende Abfrage auf Basis der Sichten in INFORMATION_SCHEMA hat mir dabei sehr geholfen.


SELECT FKT.TABLE_NAME AS FK_Table -- Fremdschlüssel-Tabelle
,CU.COLUMN_NAME AS FK_Column -- Fremdschlüssel-Spalte
,PKT.TABLE_NAME AS PK_Table -- Primärschlüssel-Tabelle
,PKT1.COLUMN_NAME AS PK_Column -- Primärschlüssel-Spalte
,C.CONSTRAINT_NAME AS Constraint_Name -- Name des Constraints
FROM INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS C
INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS FKT
  ON C.CONSTRAINT_NAME = FKT.CONSTRAINT_NAME
INNER JOIN INFORMATION_SCHEMA.TABLE_CONSTRAINTS PKT
  ON C.UNIQUE_CONSTRAINT_NAME = PKT.CONSTRAINT_NAME
INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE CU
  ON C.CONSTRAINT_NAME = CU.CONSTRAINT_NAME
INNER JOIN (
  SELECT TCI.TABLE_NAME
    ,CUI.COLUMN_NAME
    ,CUI.ORDINAL_POSITION
  FROM INFORMATION_SCHEMA.TABLE_CONSTRAINTS TCI
  INNER JOIN INFORMATION_SCHEMA.KEY_COLUMN_USAGE CUI
    ON TCI.CONSTRAINT_NAME = CUI.CONSTRAINT_NAME
  WHERE TCI.CONSTRAINT_TYPE = 'PRIMARY KEY'
  ) PKT1
  ON PKT1.TABLE_NAME = PKT.TABLE_NAME
    AND PKT1.ORDINAL_POSITION = CU.ORDINAL_POSITION

Aus SQL-Sicht ist daran interessant, dass die Tabellen TABLE_CONSTRAINTS und KEY_COLUMN_USAGE mehrfach vorkommen, aber in unterschiedlichen Rollen. Durch Vergabe unterschiedlicher Alias-Namen für dieselbe Tabelle (FKT, PKT, TCI bzw. CU, CUI) wird das unterschieden. So, als handle es sich jedes Mal um eine andere Tabelle. Eine Technik, die Sie immer dann anwenden können, wenn dieselbe Tabelle in einer Abfrage unterschiedliche Rollen einnimmt.

2014-02-19

Entwurfsmuster für DAX Formeln

Vielen DAX Formeln, die wir in Analysen und Berichten benötigen, liegen immer wieder typische Aufgabenstellungen zugrunde. Zum Beispiel laufende Summen, Lagerbestände, Buchungen und Gegenbuchungen.
Um nicht jedes Mal das Rad neu zu erfinden, ist die Verwendung von Entwurfsmustern ("pattern") eine gute Sache. Sie helfen uns in der jeweiligen Situation schnell einen bewährten Lösungsweg zu finden. Für die noch junge Sprache DAX gab es bisher keine Sammlung solcher Entwurfsmuster. Da ist es ausgesprochen hilfreich, dass die erfahrenen Vorreiter Alberto Ferrari und Marco Russo jetzt diesen Mangel abstellen. Sie stellen unter http://www.daxpatterns.com/  genau solche Muster zur Verfügung.


http://www.daxpatterns.com/
Die Website ist ein Vorbild an Übersichtlichkeit


Die Website ist ausgesprochen übersichtlich, die Texte verständlich geschrieben und mit praxisgerechten Beispielen erklärt.

Fazit: Leider nur auf Englisch verfügbar, aber eine unschätzbare Hilfe!

2014-01-24

Speicherprobleme in PowerPivot verstehen und beheben

PowerPivot erlaubt das blitzschnelle Analysieren von Tabellen mit vielen Millionen Zeilen.
Die Aussage trifft auf jeden Fall zu, wenn Sie die 64-Bit Version von Excel einsetzen und der Rechner über 8GB oder mehr Arbeitsspeicher verfügt. Allerdings sind viele Anwender auf die 32-Bit Version von Excel beschränkt. Ich arbeite gerade in so einer Umgebung, wo auch noch die 32-Bit Version von Windows 7 mit 4GB RAM im Einsatz ist. Unter diesen Umständen kann PowerPivot nach meinen Beobachtungen nur maximal ca. 700MB Arbeitsspeicher verwenden – unabhängig davon, mit wie viel RAM der Rechner ausgestattet ist. Daher wird der Import immer wieder mal mit einer Fehlermeldung wie dieser abgebrochen:
  • "Memory error: Allocation failure : Not enough storage is available to process this command. . If using a 32-bit version of the product, consider upgrading to the 64-bit version or increasing the amount of memory available on the machine."
    (Excel 2010, englisch)
  • "Die Verbindung konnte nicht aktualisiert werden. Rufen Sie die vorhandenen Verbindungen auf, und überprüfen Sie, ob eine Verbindung mit der Datei bzw. dem Server besteht."
    (Excel 2013, deutsch)
Der größte Bedarf an Speicherplatz tritt während des Aktualisierens einer bestehenden Tabelle auf. Dann benötigt Excel ausreichend Arbeitsspeicher
  • für die bestehenden Daten
  • und für alle neu zu importierenden Daten
  • und für das Erstellen der neuen Indexe
Dadurch steigt der Speicherbedarf während des Imports etwa auf das Dreifache an. In 32-Bit Umgebungen ergeben sich daraus schon bei relativ kleinen Datenmengen (je nach Art der Daten ca. 1 Million Zeilen) Probleme.
 

Gewusst wie: den Speicherbedarf verringern


Die beiden nachfolgenden Regeln helfen, den Speicherbedarf von PowerPoint Modellen zu reduzieren. Das ist nicht nur in 32-Bit Umgebungen wichtig; auch wenn in 64-Bit Umgebungen sehr viel mehr Speicher zur Verfügung steht, ist dieser nicht unbegrenzt.


Regel 1: Nur die erforderlichen Spalten aus den Quelltabellen laden


Spalten, deren Inhalt in keiner Auswertung verwendet wird, sollten Sie aus dem PowerPivot Modell löschen. Falls Sie zu einem späteren Zeitpunkt eine gelöschte Spalte wieder hinzufügen möchten, ist das ohne Probleme möglich. Auch aus Gründen der Übersichtlichkeit empfiehlt es sich sowieso, nur mit den nötigsten Spalten zu beginnen und erst bei Bedarf weitere hinzuzufügen.


Regel 2: Keine bzw. wenige Nachkommastellen laden


Für den Speicherbedarf ist die Anzahl unterschiedlicher Werte in einer Spalte entscheidend. PowerPivot erstellt automatisch einen Index auf jede Spalte, der einen Eintrag für jeden unterschiedlichen Wert enthält. Zwei Zeilen, die in einer Spalte  die Werte 12,300 und  12,301 enthalten, brauchen also mehr Speicher als zwei Zeilen, die in dieser Spalte jeweils die Zahl 12,30 enthalten. Da für Auswertungen über große Datenmengen oft nur wenige oder gar keine Nachkommastellen benötigt werden, sollten Sie Fließkommazahlen bereits beim Import (bei einem SQL Befehl z.B. mit der Funktion ROUND) runden.


Ein Experiment


Um den Speicherbedarf unterschiedlicher Daten besser zu verstehen, habe ich einmal eine Tabelle mit 500.000 Datensätzen erzeugt, die folgende Spalten enthält  (SQL Code am Ende des Artikels):

iAufsteigende Ganzzahlen
KonstanterIntimmer 0
Werte0bis9Nur Werte zwischen 0 und 9
KonstanterStringimmer 'abc'
ZufallswerteIntzufällig erzeugte Ganzzahlen
ZufallswerteFloatzufällig erzeugte Fließkommazahlen

Um die Auswirkungen der unterschiedlichen Zahlenverteilung zu sehen, habe ich nach dem Import  mit folgender DAX Abfrage den Speicherbedarf der einzelnen Spalten ermittelt:

select Attribute_Name, Dictionary_Size
from $system.DISCOVER_STORAGE_TABLE_COLUMNS 
where Dictionary_Size > 0

Eine Anleitung, wo Sie diese Abfrage eingeben können, finden Sie hier.

Und das ist das interessante Ergebnis dieses Experiments. Die Tabelle zeigt für jede Spalte den Speicherbedarf im PowerPivot Modell:


Der Speicherbedarf der Spalten ist demnach sehr unterschiedlich:
  • Die Spalten "i" und "RowNumber" (eine interne Spalte) belegen mit 64 Bytes fast gar keinen Speicher – wie auch immer PowerPivot das bewerkstelligt.
  • Wie zu erwarten, belegt die Spalte "KonstanterInt" nur sehr wenig Speicherplatz.
  • Direkt darauf folgt die Spalte "Werte0bis9", die nur 10 unterschiedliche Werte enthält und deren Inhalt daher sehr stark komprimiert werden kann.
  • Die Spalte "KonstanterString" belegt mit etwa 1 MB überraschend viel Platz. Da alle Spalten denselben Wert enthalten, hätte ich mit weniger gerechnet. Anscheinend benötigt PowerPivot für die Verwaltung von Zeichenketten viel mehr Platz als für die Verwaltung von Integer-Zahlen. Dafür verändert sich jedoch der Platzbedarf auch nicht, wenn die Zeichenkette erheblich länger wird.
  • Erheblich mehr Speicher benötigt die Spalte mit den vielen unterschiedlichen Integer-Werten "ZufallsWerteInt", nämlich etwa 10.000-mal so viel Platz wie die Spalte "Werte0bis9", die nur 10 unterschiedliche Werte enthält.
  • Und die Spalte "ZufallswerteFloat" belegt aufgrund der Nachkommastellen noch einmal doppelt so viel Platz wie die zufälligen Integer-Werte.
Kurz gesagt, hat die Anzahl unterschiedlicher Werte in einer Spalte einen erheblich größeren Einfluss auf den Speicherbedarf als der Datentyp.
 

Der SQL Code zum Erzeugen der Tabelle


CREATE TABLE TestData (
       i INT NOT NULL
       ,ZufallsWerteInt INT
       ,ZufallswerteFloat FLOAT
       ,KonstanterInt INT 
       ,KonstanterString VARCHAR(1000)
       ,Werte0bis9 INT
       )
GO

-- Füge 1 Zeile ein
INSERT TestData (i, KonstanterInt, ZufallsWerteInt, ZufallswerteFloat, KonstanterString, Werte0bis9)
VALUES (1, 0, 0, 0.0, 'abc', 0)
GO

-- Füge 2^19 Zeilen ein
INSERT TestData (i, KonstanterInt, ZufallsWerteInt, ZufallswerteFloat, KonstanterString, Werte0bis9)
SELECT (
             SELECT max(i)
             FROM TestData
             ) + row_number() OVER (
             ORDER BY current_timestamp
             ), 0, checksum(newid()), checksum(newid()) / 3.0, 'abc', ABS(checksum(newid())) % 10
FROM TestData
GO 19


Weitere Links zu diesem Thema

http://www.sqlbi.com/articles/checklist-for-memory-optimizations-in-powerpivot-and-tabular-models

http://sqlblog.com/blogs/marco_russo/archive/2010/01/26/memory-considerations-about-powerpivot-for-excel.aspx

http://denglishbi.wordpress.com/2010/06/21/powerpivot-memory-error-%E2%80%93-not-enough-storage/