Skip to main content.

Architektur

DataWarehouse

Vor
Weiter

Architektur

top


Prozessverteilung

  • Extraktion und Einfügen
    - Extraktion = Holen der Daten aus den Quellsystemen bzw. Organisieren der Bereitstellung der Daten durch die operationalen Systeme inklusive des File-Transfers.

    - Koordination von verschiedenen solchen Vorgängen.

    - Mapping der Inhalte = Zuordnung der Quellen / Quellfelder zu den Zielbereichen / Zielfelder.

    - Filtern und Prüfen der Daten

    - Einfügen in temporären Speicherbereich



  • Aufbereiten u. Umwandeln
    Die Daten müssen nun dahingehen transformiert werden so daß sie für hohe Abfragegeschwindigkeiten und große Datenmengen geeignet sind.

    - Umwandeln in DW-spezifische Strukturen (Starschema)

    - Prüfen der Daten gegen die bestehende Datenbasis.

    - Laden der Daten in die tiefste Speicherebene entsprechend der innerbetrieblichen Regeln (Aggregationsverhalten)


  • Sichern u. Archivieren
    Sichern von historischen Daten und Strukturen zur schnellen Rückspeicherung.


  • Beschleunigung der Abfrageleistung
    - (Automatisch) Erweitern und Aktualisieren von Zusammenfassungen / Aggregationsstufen

    - Erstellen / Aktualisieren von Indices

    - Erstellen / Aktualisieren / Verteilen von Replikationen (Data-Marts)

    - Erstellen von Abfragestatistiken zur Überprüfung von sich ändernden Abfrageprofilen


  • Steuerung und Verwalten der Abfragen
    - Inhaltliche Steuerung der Anwenderabfragen (Welche Anforderung betrifft welche Tabellen, Aggregationen, Data-Marts ...)

    - Zeitliche Steuerung der Anwenderabfragen (Welche Anforderungen müssen zeitlich verschoben werden z.B. als Batch)

    - Vermeiden von Systemüberlastung einer Abfrage (Killerabfragen)


top


Informationsverteilung



  • Ausführliche Informationen
    Die ausführlichen Informationen beschreiben die tiefste Speicherebene im DataWarehouse und ergeben sich aus den Aktivitäten im Geschäftsablauf, auf die noch in ihren Einzelergebnissen zurückgegriffen werden muß. Um das Datenvolumen bewältigen zu können werden die gesamten Einzelinformationen nur für einen bestimmten Zeitraum vorgehalten und fließen dann in die nächste Ebene der Aggregationsstufen ein.

    Sie können auch bei der Verfolgung einer "wellenförmigen Strategie" bald archiviert werden und bei Bedarf wieder einfließen (z.B. bestimmte Monate des Vorjahres). Diese Strategie ist zwar günstiger für das Speichervolumen, erweist sich wahrscheinlich aber als problematisch, wenn Strukturen und/oder Inhalte des DataWarehouse einer regelmäßigen Änderungsfrequenz unterworfen sind und diese Änderungen auch historisch nachvollzogen werden sollen.

    Welche Methoden existieren die ausführlichen (und andere) Informationen in der Datenbasis abzubilden ist im Abschnitt "Datenmodelle" im Kapitel "OLAP" beschrieben.


  • Aggregationen
    Aggregationen/Verdichtungen sind zusammengefaßte Informationen repliziert aus der tiefsten Speicherebene des DataWarehouse und repräsentieren eine bestimmte vordefinierte Sicht auf das DataWarehouse also z.B. alle Kunden mit ihren Produktgruppen oder man hält tagesaktuelle Daten für 3 Monate, ansonsten aber nur monatsaktuelle Daten vor.

    Eine Aggregation kann auch im Sinne einer logischen Partitionierung 1 1 Die technische Partitionierung / Verteilung von Tabellen, Indices ...(auch nach logischen Gesichtspunkten z.B. je Vertriebsgesellschaft) ist natürlich auch ein notwendiger Bestandteil der DataWarehouse-Architektur. Das unterstützt u.a. auch ein Konzept zur auszugsweisen Datensicherung und -wiederherstellung.eingesetzt werden z.B. alle Kunden mit ihren Produktgruppen einer einzelnen Vertriebsgesellschaft.

    Ziel des Vorgehens Aggregationen einzusetzen ist es die Abfrageleistung bzw. die Antwortzeiten zu erhöhen und die Systembelastung durch Abfragen zu verringern.

    Die Entscheidung für eine bestimmte Aggregation und deren Struktur der zusammengefaßten Information ergibt sich ...

    - aus den zu erwartenden Abfragestrategien der Anwender.

    - aus dem Faktor der Datenverringerung, der sich für eine Aggregationsebene ergibt.


    Da sich sowohl das Anwenderverhalten verändert, als auch sich ändernde Datenkonstellationen sich auf den Verdichtungsfaktor auswirken, unterliegt der Einsatz von Aggregationen einem permanenten Verwaltungsaufwand durch ...

    - technische Aktualisierung der Verdichtungen, wenn sich die Datenbasis ändert / erweitert (Automatisierung über den Warehousemanager)

    - Beobachtung des Anwenderverhaltens und der daraus abgeleiteten Umstrukturierung der Aggregationen und deren Neuaufbau.

    Also:

    - Je mehr Aggregationen desto höhere Abfrageperformanz aber ...

    - Je mehr Aggregationen desto höherer Speicherbedarf, höherer Administrationsaufwand, längere Lade-, Aktualisierungszeit. ...


    1 Die technische Partitionierung / Verteilung von Tabellen, Indices ...(auch nach logischen Gesichtspunkten z.B. je Vertriebsgesellschaft) ist natürlich auch ein notwendiger Bestandteil der DataWarehouse-Architektur. Das unterstützt u.a. auch ein Konzept zur auszugsweisen Datensicherung und -wiederherstellung.


  • Data-Marts
    Data-Marts sind Untergruppen des Informationsgehalts eines DataWarehouse - unabhängig von ihrer physikalischen Größe -, die aggregiert oder ausführlich in einer eigenen Datenbank gespeichert werden.

    Data-Marts sollten so definiert und abgegrenzt sein, daß sie fast das gesamte Anforderungsprofil abdecken können und nur im Einzelfall auf Informationen des restlichen DataWarehouse zurückgegriffen werden muß.

    Data-Marts werden normalerweise eingerichtet ...

    - für funktionale oder Abteilungsbereiche, die evtl. auch geographisch weiter entfernt sind.

    - für den Einsatz bestimmter Werkzeuge, die eine eigene Datenhaltung benötigen z.B. für eine multidimensionale Datenanalyse.

    Die Administration von Data-Marts insbesondere das Füllen bedeutet einen gewissen nicht zu unterschätzenden zeitlichen Aufwand, was evtl. beim Einsatz von mehreren unterschiedlichen Werkzeugen oder mehrfachen Installationen eines Werkzeugs mit eigener Datenbank problematisch werden kann.


    Physikalische Data-Marts im logischen DataWarehouse oder Data-Marts nur aus einem physikalischen DataWarehouse ?

    Der Ansatz "think big start small" könnte zur Schlußfolgerung führen, daß es reicht das DataWarehouse nur im logischen Sinn zu sehen und daß die physikalische Abbildung in den verschiedenen Datenbanken der Data-Marts erfolgt.

    Aber ...

    - es ist schwierig Daten inhaltlich konsistent zu halten, wenn sie nicht physikalisch aus einer Datenbank kommen.

    - es gestaltet das Abfragemanagement aufwendig und schwierig, wenn doch unternehmensweite Zusammenhänge bzw. über die Data-Marts greifende Anforderungen häufiger gefordert sind.


    Bei Hardwareengpässen sollte zumindest das Füllen von Data-Marts über das DataWarehouse erfolgen.


top