{"id":48,"date":"2013-02-03T23:27:55","date_gmt":"2013-02-03T22:27:55","guid":{"rendered":"http:\/\/konsilium.de\/blog\/?p=48"},"modified":"2022-07-07T21:17:24","modified_gmt":"2022-07-07T19:17:24","slug":"erwin-best-practices-in-business-intelligence-umgebungen-teil-1","status":"publish","type":"post","link":"https:\/\/konsilium.de\/blog\/2013\/02\/03\/erwin-best-practices-in-business-intelligence-umgebungen-teil-1\/","title":{"rendered":"ERwin Best Practices in Business Intelligence Umgebungen,Teil 1"},"content":{"rendered":"\n

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

Inhaltliche Kurzfassung<\/strong><\/h2>\n\n\n\n

Vom einzelnen Data Mart bis hin zum mehrschichtigen Enterprise Data Warehouse System \u2013 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\u00e4ftsziele sicherzustellen. Der Artikel zeigt Ihnen, wie ERwin Data Modeler Sie bei typischen Anforderungen im Kontext von Business Intelligence Projekten unterst\u00fctzt.<\/p>\n\n\n\n

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

    1. Multidimensionales Datenmodell einrichten
    (Star- oder Snowflake-Schema)<\/h1>\n\n\n\n
    \n

    Wir bereiten unser ERwin Tool zun\u00e4chst f\u00fcr den Einsatz in einer Data Warehouse Umgebung vor – in dem wir verschiedene Einstellungen optimieren – und zwar auf 4 Ebenen:<\/p>\n<\/div>\n\n\n\n

    Ebene 1<\/strong>: Optionen (globale Einstellungen von ERwin)
    Ebene 2<\/strong>: Modell
    Ebene 3<\/strong>: Subject Area
    Ebene 4<\/strong>: Diagram<\/p>\n\n\n\n

    Ebene 1: <\/strong>Da w\u00e4ren zun\u00e4chst die „Model Naming Options“, Registerkarte „Physical“:<\/div>\n\n\n\n
     <\/div>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n
    <\/div>\n\n\n\n

    Hier sollten Sie die maximale Zeichenl\u00e4nge von Datenbank Objekten festlegen. So stellen
    Sie sicher, dass bereits w\u00e4hrend der Modellierung nicht gegen wesentliche Namenskonventionen versto\u00dfen werden kann. Leider sind diese Einstellungen eine Einstellung der lokalen ERwin Installation. Sie m\u00fcssen also von jedem User einzelen vorgenommen werden. Tipp: Gleichen Sie die Zeichenl\u00e4ngen mit den Anforderungen Ihrer DBA bzw. Ihrer Abteilung ab, die f\u00fcr den Betrieb der Anwendungen verantwortlich ist.<\/p>\n\n\n\n

    N\u00e4chste Registerkarte „Duplicate Names\u201c<\/div>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n
    <\/div>\n\n\n\n
    Anders als man vielleicht vermuten k\u00f6nnte, macht nur die Einstellung „Allow duplicate Names\u201c Sinn. W\u00e4hlen Sie eine andere Option, so m\u00fcssen Spaltennamen modellweit eindeutig sein. Dies w\u00fcrde bedeuten, dass Foreign Key und zugeh\u00f6riger Primary Key nicht namensgleich sein d\u00fcrfen. Genau das will man aber im Sinne eines „selbsterkl\u00e4renden“ Datenmodells haben! Das macht also keinen Sinn. Noch weniger Sinn macht die Tatsache, das ERwin nicht auf Namensgleichheit von Tabellennamen
    pr\u00fcft – egal welche Einstellung Sie w\u00e4hlen. Zumindest gilt das f\u00fcr die mir bekannten Versionen r7 und r8.<\/div>\n\n\n\n
    Nachfolgend ein Screenshot mit zwei angelegten Tabellen mit identlischen Bezeichnungen f\u00fcr Tabellenname und Schema:<\/div>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n
    <\/div>\n\n\n\n
    Auf der Registerkarte „General“ kann der Modellierer die Notationsform einstellen:<\/div>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n
    <\/div>\n\n\n\n
     <\/div>\n\n\n\n
    Die „Data Warehousing“ Notation ist nicht zu empfehlen, da die Verbindungslinien (Relationships) auf dem Diagramm keine „Kr\u00e4henf\u00fc\u00dfe“ anzeigen. Somit l\u00e4sst 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\u00e4re dies auch kein Problem. F\u00fcr die Data Vault Modellierung schon eher, letzten Endes eine Geschmacksfrage …<\/div>\n\n\n\n
     <\/div>\n\n\n\n
    Manchmal vergisst der Modellierer schonmal einer Spalte den korrekten Datentyp zuzuweisen. Durch die Definition eines „auff\u00e4lligen“ Datentyps f\u00e4llt dies direkt auf. Au\u00dferdem 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.<\/div>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Mit Klick auf „Set Default Owners“ im obigen Screenshot,kommt man zum Dialog „Set default Owner“.<\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n

    Auch gebe ich die Empfehlung einen „auff\u00e4lligen“ Default-Owner zu definieren, damit sofort erkennbar auff\u00e4llt, 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\u00fcr das Design Data Warehouse Datenmodellen lautet: Keine Pr\u00fcfung auf referentielle Integrit\u00e4t 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\u00fctzt den Datenbank Optimizer bei der Berechnung seiner Ausf\u00fchrungspl\u00e4ne. Dies ist umso wichtiger, wenn Materialized Views f\u00fcr die Persistierung von Aggregaten eingesetzt werden.<\/p>\n\n\n\n

    \"\"<\/a><\/figure><\/div>\n\n\n\n
     <\/div>\n\n\n\n
    ERwin Dialog mit den Eigenschaften einer Relation.<\/div>\n\n\n\n
    \"\"<\/a><\/figure><\/div>\n\n\n\n
    <\/div>\n\n\n\n
    Die Optionen „NOT ENFORCED“ und „ENABLE QUERY OPTIMIZATION“ sind aktiviert (Empfehlung!).<\/div>\n\n\n\n

    Weiter geht es mit den Empfehlungen zu Einstellungen f\u00fcr die \u201eSubject Area\u201c (Ebene 3<\/strong>).<\/p>\n\n\n\n

    [Fortsetzung folgt in Teil 2 (–> in Arbeit)]<\/div>\n","protected":false},"excerpt":{"rendered":"

    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 \u2013 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… Weiterlesen »ERwin Best Practices in Business Intelligence Umgebungen,Teil 1<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":2318,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[6],"tags":[136,15,77],"_links":{"self":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts\/48"}],"collection":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/comments?post=48"}],"version-history":[{"count":25,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts\/48\/revisions"}],"predecessor-version":[{"id":2666,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/posts\/48\/revisions\/2666"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/media\/2318"}],"wp:attachment":[{"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/media?parent=48"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/categories?post=48"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/konsilium.de\/blog\/wp-json\/wp\/v2\/tags?post=48"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}