Es hat sich herumgesprochen, dass relationale Datenbanken geeigneter als Papierstapel sind, um Daten strukturiert aufzubewahren. Doch für moderne Reportinglösungen müssen neue Konzepte her, um die Anforderungen an Geschwindigkeit und den Komfort bei Filterung und Gruppierung erfüllen zu können. Dabei gilt es, ein paar Grundlagen zu beachten und Fallen zu vermeiden. Aus meinen SQL-Sessions kennt man die kleinen Knobeleien, mit denen ich mein Wissen gerne weitergebe. Das geht mit PowerBI & Co genauso spannend. Mitraten erwünscht!

Zielpublikum: Datenarchitekten, Entwickler, Projektleiter, ProductOwner, Datenbankspezialisten
Voraussetzungen: Spaß am Lernen und Mitmachen
Level: Basic

Extended Abstract:
Warum sollte ich dieses "Sternschema" nutzen, wo ich doch erst mühsam die 5. Normalform in meiner relationalen Datenbank erreicht habe? Oder sollte es gleich das "Snowflakeschema" sein? Was ist das überhaupt und wo liegen die Unterschiede? Was genau sind die Anforderungen eines ("Self Service-") Reportingsystems an die Datenbereitstellung? Und dann gibt es doch auch noch diesen "Cube"... Ist das identisch? Fragen über Fragen... und von der "richtigen" Antwort hängt der Erfolg des Projektes ab. In dieser Thematik lässt sich viel Geld sparen oder noch mehr Geld sinnfrei versenken. Tausende Entwickler in Firmen unterschiedlicher Branchen, haben immer wieder dieselben Fehler gemacht... Vermeiden kann man diese, wenn man sich schon im Vorfeld Gedanken macht und sauber plant. Die Kelleretage plant man ja auch nicht erst nach dem Richtfest.