Zum Inhalt springen

ERwin Best Practices in Business Intelligence Umgebungen,Teil 1

    Best Practices zum Einsatz von ERwin Data Modeler (Version Versionen r7 / r8) in Data Warehouse und Business Intelligence Umgebungen.

    Inhaltliche Kurzfassung

    Vom einzelnen Data Mart bis hin zum mehrschichtigen Enterprise Data Warehouse System – das Datenmodell Ihres Business Intelligence Systems ist ein entscheidendes Artefakt Ihres Entwicklungsprozesses. Auf dieser Grundlage baut die ETL- und Berichtsentwicklung auf. Der Modellierer kann die Datenanforderungen der Fachbereiche visualisieren und auf effiziente Weise definieren, um die Erreichung der Geschäftsziele sicherzustellen. Der Artikel zeigt Ihnen, wie ERwin Data Modeler Sie bei typischen Anforderungen im Kontext von Business Intelligence Projekten unterstützt.

    Themen Serie 1

    1. Multidimensionales Datenmodell einrichten (Star- oder
      Snowflake-Schema)
    2. Organisation der Star-Schemas in einem Galaxy-Schema / BUS Matrix Design.
    3. Dokumentation von Tabellentypen: Dimensionen, Fakttabellen, Bridge-Tables, Outrigger (Snowflakes) – sowie von Dimensionstypen (Standard, Junk), Fakttabellen-Typen (Transaction, Snapshot)
    4. Dokumentation von Historisierungsverfahren (Slowly-Changing-Dim. Type 2, etc.)
    5. Von Granularitäten, Business Keys, Dimensionshierarchien
    6. Mengengerüste und Wachstumsprognosen
    7. Quellsystem und Star-Schema verlinken
    8. Abbildung der Data Linage und Erstellung einer ETL-Spezifikation
    9. Source-To-Target Mapping Generierung: Dokumentation der Data Lineage inkl. Transformationsregeln
    10. Dokumentation der ETL-Bewirtschaftungsverfahren (Data Movement Rules)
    11. Metadaten-Austausch mit ETL-Werkzeug (Bsp. Informatica) und BI-Reportingsystem (Bsp. Cognos)
    12. Performance-Tuning im Data Warehouse Datenmodell
    13. Definition / Dokumentation von Role-Playing Dimensions
    14. Datenmodell Organisation im Enterprise Umfeld: Organisation der Modelle bei mehrschichtigen BI Systemen; Schneidung und Einsatz von Subject
      Areas

    1. Multidimensionales Datenmodell einrichten
    (Star- oder Snowflake-Schema)

    Wir bereiten unser ERwin Tool zunächst für den Einsatz in einer Data Warehouse Umgebung vor – in dem wir verschiedene Einstellungen optimieren – und zwar auf 4 Ebenen:

    Ebene 1: Optionen (globale Einstellungen von ERwin)
    Ebene 2    : Modell
    Ebene 3    : Subject Area
    Ebene 4    : Diagram

    Ebene 1: Da wären zunächst die „Model Naming Options“, Registerkarte „Physical“:
     

    Hier sollten Sie die maximale Zeichenlänge von Datenbank Objekten festlegen. So stellen
    Sie sicher, dass bereits während der Modellierung nicht gegen wesentliche Namenskonventionen verstoßen werden kann. Leider sind diese Einstellungen eine Einstellung der lokalen ERwin Installation. Sie müssen also von jedem User einzelen vorgenommen werden. Tipp: Gleichen Sie die Zeichenlängen mit den Anforderungen Ihrer DBA bzw. Ihrer Abteilung ab, die für den Betrieb der Anwendungen verantwortlich ist.

    Nächste Registerkarte „Duplicate Names“
    Anders als man vielleicht vermuten könnte, macht nur die Einstellung „Allow duplicate Names“ Sinn. Wählen Sie eine andere Option, so müssen Spaltennamen modellweit eindeutig sein. Dies würde bedeuten, dass Foreign Key und zugehöriger Primary Key nicht namensgleich sein dürfen. Genau das will man aber im Sinne eines „selbsterklärenden“ Datenmodells haben! Das macht also keinen Sinn. Noch weniger Sinn macht die Tatsache, das ERwin nicht auf Namensgleichheit von Tabellennamen
    prüft – egal welche Einstellung Sie wählen. Zumindest gilt das für die mir bekannten Versionen r7 und r8.
    Nachfolgend ein Screenshot mit zwei angelegten Tabellen mit identlischen Bezeichnungen für Tabellenname und Schema:
    Auf der Registerkarte „General“ kann der Modellierer die Notationsform einstellen:
     
    Die „Data Warehousing“ Notation ist nicht zu empfehlen, da die Verbindungslinien (Relationships) auf dem Diagramm keine „Krähenfüße“ anzeigen. Somit lässt sich nicht erkennen, ob es sich um eine 1:1 oder um eine 1:n Beziehung handelt. Gut – in einem Star Schema nach der reinen Lehre, wäre dies auch kein Problem. Für die Data Vault Modellierung schon eher, letzten Endes eine Geschmacksfrage …
     
    Manchmal vergisst der Modellierer schonmal einer Spalte den korrekten Datentyp zuzuweisen. Durch die Definition eines „auffälligen“ Datentyps fällt dies direkt auf. Außerdem legt Erwin auch schonmal bei bestimmten Aktionen in Zusammenhang mit Relationen eine Spalte von sich aus an. Im unten stehenden Screenshot ist zum Beispiel ein Datentyp varchar(222) definiert worden.

    Mit Klick auf „Set Default Owners“ im obigen Screenshot,kommt man zum Dialog „Set default Owner“.

    Auch gebe ich die Empfehlung einen „auffälligen“ Default-Owner zu definieren, damit sofort erkennbar auffällt, dass hier vergessen wurde, den Owner -also den Schema Namen – zu definieren. Dies passiert zum Bsp. sehr oft bei der Anlage von Indizes.Eine generelle Empfehlung für das Design Data Warehouse Datenmodellen lautet: Keine Prüfung auf referentielle Integrität durch das Datenbank System! Die Relationen werden trotzdem definiert. Zum einen dient dies der Dokumentation des Datenmodelles. Zum anderen werden die Relationen auch in der Datenbank implementiert – jedoch mit der Option „NOT ENFORCED“. Die Relationen werden ferner mit der Option „ENABLE QUERY OPTIMIZATION“ (z.B. bei IBM DB2) versehen.Beides zusammen unterstützt den Datenbank Optimizer bei der Berechnung seiner Ausführungspläne. Dies ist umso wichtiger, wenn Materialized Views für die Persistierung von Aggregaten eingesetzt werden.

     
    ERwin Dialog mit den Eigenschaften einer Relation.
    Die Optionen „NOT ENFORCED“ und „ENABLE QUERY OPTIMIZATION“ sind aktiviert (Empfehlung!).

    Weiter geht es mit den Empfehlungen zu Einstellungen für die „Subject Area“ (Ebene 3).

    [Fortsetzung folgt in Teil 2 (–> in Arbeit)]
    Schlagwörter: