Skip to main content.

Grundsätze für Datawarehouse Projekte

Imagemap
Grundsätze für Data Warehouse Projekte Unterschiede zum traditionellen Vorgehen Warum eine Info-Bedarfsanalyse durchführen Sammeln der Anforderungen Typische Fragen an den Endbenutzer Typische Fragen für die Modellierung Schritt 1 Schritt 2 Modellierung multidimensionaler Datenstrukturen Beschreibungselemente multidimensionaler Modellierung Betriebswirtschaftliche Variablen Grundsätze bei multidimensionaler Modellierung Schritt 3 Schritt 4 Schritt 5 Schritt 6 Buchtipps OLAP - Multidimensionale Datenbanken . Produkte, Markt, Funktionsweisen und Implementierung OLAP - Grundlagen, Modellierung und betriebswirtschaftliche Lösungen. SQL Server 2000 Analysis Services Andere Bücher über OLAP

Titel: Grundsätze für Datawarehouse Projekte
Autor: Thomas Troidl
Beschreibung: Grundsätze für Datawarehouse Projekte


Grundsätze für Data Warehouse Projekte

  • Integration unterschiedlicher Know-how-Facetten
  • Ausrichtung an dem wirtschaftlich Optimalen und nicht am technisch Maximalen
  • frühzeitiges und interaktives Prototyping
  • kontinuierlicher Ausbau des Data Warehouse (horizontal und vertikal)
  • Think Big - Start Small

Unterschiede zum traditionellen Vorgehen

Traditionelles Vorgehen:

  • geprägt durch bestehende betriebliche Abläufe
  • eindeutige Definition der Anforderungen vor Umsetzung des Konzeptes
  • Anforderungen bei der Entwicklung von Informationssystemen:
  • Orientierung des Konzeptes am zukünftigen Informationsbedarf der Anwender
  • Vollständiger Informationsbedarf ist zum Zeitpunkt der Realisierung noch nicht bekannt
  • Der Informationsbedarf ändert sich im Zeitablauf
    Folgerung:
    • Entwicklung und Aufbau des Data Warehouse in mehreren kurzfristig aufeinanderfolgenden Zyklen.
    • Jeder Zyklus wird genau mit den Entscheidungsträgern abgestimmt

Warum eine Info-Bedarfsanalyse durchführen

  • sie gewährleistet die Entwicklung eines Informationsproduktes mit und für den Fachbereich anstatt an dem Fachbereich vorbei
  • sie gibt dem Anwender die Möglichkeit, seine Wünsche zu äußern und Einfluß auf das Ergebnis zu nehmen
  • sie liefert wichtige Ergebnisse für das richtige Datenbankdesign
  • sie gibt wichtige Anhaltspunkte für die spätere Realisierung der Data-Warehouse-Anwendung

Sammeln der Anforderungen

  • Geschäftsanalyse (Kunden, Produkte, Geschäft)
  • Prozeßanalyse des Anwenders (Wie erledigt der Anwender sein Geschäft)
  • Informationsanalyse (Kritische Erfolgsfaktoren,Kennzahlen, Informationsfluss, Verantwortung)
  • Berichtsanalayse (Häufigkeit,Wichtigkeit,Verwendung)
  • Berichte empfangen
  • Berichte erstellen
  • Ad Hoc Analysen
  • Wunschliste
    (Welche Informationen hätten sie gerne als erstes, ohne Berücksichtigung der finanziellen, zeitlichen und technischen Einschränkungen?)

Typische Fragen an den Endbenutzer

  • Was sind Ihre kritischen Erfolgsfaktoren?
  • Welche Reports erhalten Sie? (Häufigkeit, Weiterverwendung, wichtige Informationen etc.)
  • Welche Reports erstellen Sie selbst? (wieviel Aufwand, für wen, woher bekommen Sie die Informationen?)
  • Welche Ad-Hoc-Analysen und Business-Analysen führen Sie durch?
  • Fragen zur Datenherkunft, Detaillierungsgrad, Verantwortlichkeit.
  • Welche zusätzlichen Informationen hätten Sie gern?

Typische Fragen für die Modellierung

  • Auf welchem Detaillierungsgrad führen Sie hauptsächlich Ihre Analysen durch?
  • Was ist der tiefste Detaillierungsgrad für Ihre Analysen?
  • Wie ist die Struktur der Hierarchien die Sie benötigen?
  • Gibt es multiple Hierarchien?
  • Wie oft verändern sich die Hierarchien? Wie sollen die Veränderungen behandelt werden?

Schritt 1

  • Wähle den richtigen Prozeß
  • Angehen des dringendsten Problems, verknüpft mit einem guten Verständnis des Geschäftes und den am besten zur Verfügung stehenden Daten (Think big, start small)
  • Welcher fachliche Problembereich bzw. Geschäftsaspekt soll abgedeckt werden?

Schritt 2

  • Bestimmung der Dimensionen( = betriebswirtschaftliche Objekte) mit all ihren Attributen und impliziten Hierarchien. (Grundlage für Browsing / zulässige Werte / Prüfungen)
  • Dimensionen stellen Spaltenköpfe in den Berichten dar.
  • Dimensionen geben die Begriffswelt der Anwender wieder. (z.B. Kunde; Produkt; Region ...).
  • Modellierung multidimensionaler Datenstrukturen
  • Multidimensionalität

    • Die logische Anordnung quantitativer Größen (Umsatz,Ergebnis ..), die durch mehrere sachliche Kriterien (Kunden, Produkte, Verkaufsort ...) beschrieben sind, in mehrdimensionalen Datenwürfeln
    • Multidimensionale Datenmodelle werden aufgebaut, um den entscheidungstreffenden Anwendern eine natürliche realitätsgetreue Sichtweise auf ihr Arbeitsfeld zu gewähren.
  • Beschreibungselemente multidimensionaler Modellierung
  • Dimensionen:

    • Liste von Elementen, die aus dem Verständnis des Benutzers unter einem Begriff zusammengefaßt werden können.(z.B. Dimension Kunde: Kundenname, Adresse, Branche, Konzern .. Dimension Produkt: Materialnummer, Geschäftsfeld ..)
    • Die Dimensionen bilden die Kanten des n-dimensionalen Würfels
      Kennzahlen / Measures / Variable: Sie bilden die Zellen des Würfels (z.B. Umsatz, Absatz, Auftragskosten ...) Dabei handelt es sich um numerische Werte, die für alle Dimensionen vorliegen sollen und über gewisse Vorschriften zusammengefaßt werden können.

    Hierarchien:

    • Die Dimensionen weisen oft hierarchische Strukturen auf in denen zusammengehörige Werte konsolidiert werden können (Drill)
  • Betriebswirtschaftliche Variablen
    • Abstecken des Untersuchungsfeldes (fachlicher Problembereich bzw. Geschäftsaspekt)
    • Aussage über Kriterien, die den Erfolg oder Mißerfolg der Geschäftstätigkeit in dem betrachteten Problembereich bestimmen (kritische Erfolgsfaktoren)
    • Welche Meßgröße (= betriebswirtschaftliche Variablen) charakterisieren den Untersuchungsgegenstand angemessen?
  • Grundsätze bei multidimensionaler Modellierung
    • Fokussierung auf Benutzerorientierung der abgelegten Informationseinheiten sowie deren Inhalt und Qualität
    • Datenmodell unabhängig von der konkreten Implementierung
      Grundlage für Diskussionen zwischen Fach- und IT-Abteilung und für die späteren Metadaten

Schritt 3

Was soll ein Satz der Fact-Tabelle abbilden (z.B. Umsatz eines Kunden mit einem Produkt an einem Tag in einer Vertriebsregion)?
Fakten und Werte stehen an den Schnittpunkten von Dimensionen Dabei wird über die Granularität der Zeit auch der Aktualisierungzyklus festgelegt.
Die Werte in den FACT-Tabellen sollten numerisch und evtl. additiv sein (Granularität = tiefste Ebene der Dimension Fact-Tabelle = Kennzahlen und Werte)


Schritt 4

Verfeinerung der Dimensionen
In Schritt 3 wurde die tiefste Ebene jeder Dimension festgelegt. In diesem Schritt geht es nun darum, jede Dimension mit allen sinnvollen Attributen (gute Textbeschreibungen und keine Abkürzungen) zu versehen, bzw. eindeutige Hierarchien innerhalb einer Dimension festzulegen.
Dabei muß die tiefste Ebene einer jeden Hierarchie der eindeutige Schlüssel der Dimension sein.(Granularität = tiefste Ebene der Dimension)


Schritt 5

Die Abdeckung des zeitlichen Rahmens in der Datenbank bestimmen

  • Wie Lange werden die Daten in der Datenbank gehalten (Historie)?
  • In welcher Form halte ich Vergangenheitsdaten in der Datenbank (Aggregation)?
  • Wann und wie entferne ich Vergangenheitsdaten aus der Datenbank (Archiv)?

Schritt 6

Behandlung von sich ändernden Dimensionen:

  • Wie muß ich historische Daten behandeln?
  • Muß ich sie "Vergleichbar rechnen" (bei Organisationsänderungen)?
  • Muß ich den Zeitpunkt der Dimensionsveränderung festhalten?

Buchtipps