1 / 106

SAS Banking Intelligence Architecture Detail Data Store (SAS BIS DDS)

SAS Banking Intelligence Architecture Detail Data Store (SAS BIS DDS). Einführung für VW FS – 29.04.2014. Agenda. Ziele und Erwartungen – kurze Einführung Datenhaltungskonzepte und Banking DDS Physische Designprinzipien Datenmodellierungsaspekte und Erweiterbarkeit

anika
Download Presentation

SAS Banking Intelligence Architecture Detail Data Store (SAS BIS DDS)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SAS Banking Intelligence ArchitectureDetail Data Store (SAS BIS DDS) Einführungfür VW FS – 29.04.2014

  2. Agenda • Ziele und Erwartungen – kurze Einführung • Datenhaltungskonzepte und Banking DDS • Physische Designprinzipien • Datenmodellierungsaspekte und Erweiterbarkeit • Logische Designprinzipien • Allgemein und anhand eines konkreten Themas: Meldewesen • Banking DDS Betrieb • Installation und Beladung • Diskussion und Verbleib

  3. Kurze einführung SAS BIS DDS

  4. Einführung Muss Kriterien für DWH Strategie • Zusätzlich steigen durch Regulierung und Wettbewerbsfähigkeit die Anforderungen an Datenhaushalte: • Höhere Frequenzen in der Steuerung (z.B.: täglich, untertätig in der Liquiditätssteuerung) • Höhere Datenvolumen (Steuerung auf Cashflow Ebene) • Häufigkeit von Modelländerungen durch Finanzproduktentwicklung • Steigende Anforderungen an Datenqualität und Data Governance (BCBS 239)

  5. DWH Wesentliche Herausforderungen Analysetiefe Grad der fachlichen Abdeckung und Potential für zukünftige Analysen Single-version-of-the-truth als Basis für einheitliches Reporting und Analytics Integrationstiefe Grad der Integration zwischen fachlichen Applikationen / Nutzern des Modells Erreichung durch viele Iterationen bzgl. Gesamtdesign des Modelles Nutzungsflexibilität Qualität der Integration zwischen fachlichen Applikationen Ausreichende Flexibilität in der Nutzung durch richtige Abstraktionen Modellstabilität Grad der Auswirkung einer Änderung auf gekoppelten Bereiche / Module Hohe Modellstabilität ist zentrales Ziel zur Erreichung von Kostensenkungen Standardisierungsbreite Niedrige Standardisierungsbreite deutet auf zu generische Modellierung hin Hohe Standardisierungsbreite ist nicht konkret genug um Mehrwert zu bringen

  6. SAS BIS DDS Drei Schlüsselkriterien zur Auswahl eines Industriedatenmodells Funktionsabdeckung Datenmodell–basierende, fertige Lösungen beweisen Vollständigkeit und Richtigkeit. Praxistauglichkeit Nur nachhaltige Kundenprojekte beweisen Praxistauglichkeit. Vollständige Integration Nur Implementierungen aus einem Guss beweisen die Integration über alle relevanten Aspekte. • Modularität • Durchgängige Metadaten • Einheitliche Technologie • Integrierte Data Integration Tools • Integrierte Data Quality Tools • Durchgängige Dokumentation • Durchgängige Standardisierung • Erprobte Implementierungs-methodologie 300 Referenzen weltweit Banksteuerung Risikosteuerung Kundensteuerung Personal Rechnungswesen Meldewesen • SAS erfüllt alle drei Kriterien!!

  7. SAS BIS DDS „Das Avokado Prinzip“ • Maximale Integrationstiefe bei sinnvoller Standardisierungsbreite • Hohe Integrationstiefe bedeutet gute Modellstabilität • Kostenintensive „movingsource“ Szenarien werden vermieden • Sicherung der Wirtschaftlichkeit der Investition durch hohe Standardisierungsbreite • Beibehaltung der Nutzungsflexibilität durch einfache Erweiterbarkeit SAS BISDDS • Mangelhafte Integrationstiefe • Einsatz eines nicht-integrierten Datenmodelles ist nicht sinnvoll • Hohe Folgekosten durch Designiterationen und Doppelentwicklungen • Mangelhafte Analysetiefe (fachliche Abdeckung) • Keine Mehrwert aufgrund fehlender „Intellectual Property“ • Hohe Folgekosten durch hohe Eigenentwicklung

  8. Datenhaltungskonzepte und Banking DDS Was ist das SAS BIS DDS?

  9. Datenhaltungs-konzepte und Banking DDS Zu unterstützende Prozesse– Warum Halten wir Daten? Management Prozess Umsetzung von Informationen zur Steuerung des täglichen Betriebes Business Intelligence Prozess Analytische Verarbeitung, Informationsgewinnung, Entscheidungshilfe Business Operations Prozess Verarbeitung von Informationen des normalen, täglichen Betriebes

  10. Datenhaltungs-konzepte • Z.B.: Google Big Table • Große Datenmengen – Big Data, Flache aber multidimensionale Tabelle • NoSql (Not onlySql) • Große Cluster Systeme als Hardware • Z.B.: ‚OLAP Cubes‘, Hierarchien • Datenobjekte sind durch hierarchische Dimensionen organisiert – ‚Star Schema‘ • Designet für analytische Anwendungen – Drilldownfähigkeiten • Immer konkrete, begrenzte Anwendungen • In sogenannten „Star Schemes“ umgesetzt Big Table MultidimensionaleSysteme • Basieren auf der Mengentheorie • Entititäten sind überAttribute verbunden durch Relationen • Enstprechen der sogenannten Normalform, werden durch SQL betrieben • Industrie Standard für Datenbanken seit den 1980er Jahren • Technologie unabhängiges Konzept • Z.B.: Teradata, Oracle, DB2, SQL Server, ... Relationale Systeme Differenzierung

  11. Datenhaltungs-konzepte Relational Systeme – ‚Entity/Relationship‘ ModelLe

  12. Datenhaltungs-konzepte Multi-Dimensionale Systeme – ‚Star Schema‘

  13. Datenhaltungs-konzepte und Banking DDS Zu unterstützende Prozesse– Warum Halten wir Daten? Management Prozess Umsetzung von Informationen zur Steuerung des täglichen Betriebes Business Intelligence Prozess Analytische Verarbeitung, Informationsgewinnung, Entscheidungshilfe Business Operations Prozess Verarbeitung von Informationen des normalen, täglichen Betriebes • Decision Support Systeme • DSS • Operationale Systeme • OLTP – Online Transaction Processing

  14. OLPT VS DDS Vergleich der Schwerpunkte Operationale Systeme - OLTP Decision Support Systeme - DSS • Optimiert für: • Hohe Anzahl an Transaktion mit begrenztem Datenvolumen • Genau definierte, hohe Performance-anforderungen • Hochverfügbarkeit – ‚systemismissioncritical‘ • Skalierbar, wenn sich die Muster der Transaktion nicht stark ändern • Konstanter Grad an Hardwareausnutzung • Optimiert für: • Kleine Anzahl an Einzeltransaktionen mit relativ hohen Datenvolumen • Entspannte Anforderungen an Response Zeiten • Integration von Daten unterschiedlicher Quellen • Historische Daten werden gespeichert • Hardwarenutzung erlebt immer wieder Peaks

  15. Vergleich der Daten-manipulationen Vergleich der Schwerpunkte Operationale Systeme - OLTP Decision Support Systeme - DSS • Datenvolumen/Transaktion + • Inserts ++ • Updates +++ • Leseprozesse + • Löschprozesse ++ • Datenvolumen/Transaktion +++ • Inserts ++ • Updates n.a. • Leseprozesse +++ • Löschprozesse n.a. Widersprüchliche Nutzungsmuster!

  16. OLPT VS DsS Schlussfolgerung • Widersprüchliche Nutzungsanforderungen zwischen OLTP- und DSS-Systemen • Trennung der Systeme, hinsichtlich Hardware-, Software- und Datenarchitektur • Unterschiedliche Designs erforderlich

  17. DsS - Systeme Varianten • Data Warehouse (DWH) • Data Mart • Operational Data Store (ODS)

  18. DSS - Systeme DWH • ‘... collection of subject-oriented, integrated, time-variant, nonvolatile data that is designed to support strategic decision-making for the enterprise.’ [Inmon, 2002] • Eine zweite Instanz der Unternehmensdaten, die den operationalen Daten gegenüber gestellt werden • Hält große Mengen an historischen Daten • Integriert Daten verschiedenster Quellsysteme • Zugriff von analytischen und Abfrageprozessen entweder direkt auf das DWH oder abgeleiteten Marts

  19. DSS - Systeme Data mart • Ein Datenstruktur, die ein spezifisches „Subset“ der Unternehmensdaten zu Analyse- und Reportingzwecken hält • Maßgeschneidert für die Nutzung einzelner Abteilungen oder Geschäftsprozesse • Die Daten können in eine nicht generisches Format transformiert werden, um eine eng begrenzten Anforderung Genüge zu tun

  20. DSS - Systeme ODS • Themenorientierte und integrierte Sammlung von Daten die für DSS genutzt werden • Dient zur raschen, unmittelbaren Integration von operationalen Daten unterschiedlicher Vorsysteme • Im Gegensatz zu einem DWH sind die Daten aktuell (nicht historisch) und volatil • Dient oft als Quelle für ein DWH

  21. Was ist das Banking DDS? SAS BIS DDS - DeFinition • Das SAS BIS DDS dient als ‚singleversion of thetruth‘ für SAS Banking Intelligence Solutions und als Basis für Anwendungen im Bereich Banksteuerung. • Es enthält die Detaildaten und historische Informationen, die benötigt werden, um die fachlichen Anwendungs-Data Marts zu befüllen. • Es liefert eine umfassende und integrierte Datenarchitektur. • Es ist ein logisches und physische Datenmodell, das einen sehr weiten Bereich der Daten einer Bank abdeckt. • Es ist ein Datenmodell, das für analytische- und Reportinganforderungen genutzt werden kann. • Es ist nicht als ein operational Data Store gedacht.

  22. SAS BIS DDS Fokus Hoher Reifegrad • Relationales Industrie Datenmodell in der 8. Design Iteration • Ständige Weiterentwicklung durch Fachexperten bei SAS • Drastische Reduzierung der Modellierungsaufwände im Unternehmen • Vermeidung teurer Designiterationen Fokus auf Integration • Löst Komplexität zwischen Quellsystemen und Zielanwendungsbereichen auf • Erzielung von Synergieeffekten bei Datenakquisition gegenüber Insellösungen • Basis für alle Gesamtbanksteuerungslösungen von SAS Fokus auf Standardisierung • Etablierung einer einheitlichen „Sprache“ über Daten • Hoher Abdeckungsgrad Flexibles Deployment • Unterstützt Think Big – Start Focused Ansatz • Deployment für ein oder mehrere SAS forBankingSolutions • Deployment auf SAS Datenhaltung oder allen gängigen RDBMS

  23. SAS BIS DDS Big Picture!

  24. SAS BIS DDS ERWin Modelle als Bestandteil der Dokumentation- Optional PowerDesigner

  25. SAS BIS DDS Integration in Verbindung mit SAS DI Studio

  26. SAS BIS DDS Integration mit SAS Data Quality Komponenten

  27. Physische Designprinzipien Datenmodellierungsaspekte und Erweiterbarkeit

  28. SAS BIS DDS Modellierung und Standardisierung Allgemeines • Relationales Datenmodell in 3. Normalform • Gängige Datenbankplattformen werden unterstützt Schlüsselmanagement • Generierter Surrogatschlüssel und separate Speicherung der Quellsystem ID • Primärschlüssel aus Surrogatschlüssel und Gültigkeitsperioden Entitätsklassen • Kategorisierung von Entitäten aufgrund gemeinsamer Charakteristika • Berücksichtigung in Namenskonvention zur Reduzierung der Komplexität Attributkategorisierung • Kategorisierung der Attribute aufgrund Datentype und Verwendung • Berücksichtigung in Namenskonvention zur Reduzierung der Komplexität Historisierung • Historisierung unter Verwendung von SCD Type 2 Konzept • Optimierung auf rasches Einfügen, Löschen und Gesamtbestandsabfrage

  29. Physische Designprinzipien Surrogatschlüssel • Ein Surrogatschlüssel wird generell als Primärschlüssel einer DDS-Tabelle genutzt(_RK für „Retained Key“) • Ein Surrogatschlüsselist immer numerisch und matscht 1:1 zum natürlichen Schlüssel • Der Primärschlüssel ist ein kombinierter Schlüssel und enthält zusätzlich ein Gültigkeitsdatum oder noch andere Attribute • Für einige Tabellentypen ist der Primärschlüssel der natürliche Schlüssel und nicht der Surrogatschlüssel, z.B. _CD in Referenztabellen

  30. Physische Designprinzipien Typische DDS Tabelle Schlüsselmanagement SurrogatschlüsselfürdieseEntität PrimärschlüsselfürdieseEntität Zeitfelder für Versionierung Fachlicher, natür-licher Schlüssel fürdieseTabelle

  31. Physische Designprinzipien Typische DDS Tabelle – Zusatzattribute Optional “Business Effective” Fremdschlüssel (surrogate) Attribute Columns …_CD Schlüsseleiner... Referenztabelle

  32. Physische Designprinzipien Historisierung • Konzepte • Hinzufügen neuer Datensätze mittels SCD Type 2 • Umsetzung durch Gültigkeitsperiode (Von - Bis) • Durchgängige, lückenlose Zeitscheiben erforderlich • Auch zusätzliche Gültigkeitsperiode für die Historisierung von Korrekturen vorhanden Beispiel Bestehender Datensatz Hinzufügenneuer Information und Anpassen des bestehendenDatensatzes

  33. Physische Designprinzipien Zwei Dimensionale Historisierung Beispiel • Unterscheidung zwischen technischer Gültigkeit und fachlicher Gültigkeit • Erfordert Adaptierung der CDC Logik • Steuerung für nachfolgende Applikationen über Views Bestehender Datensatz Hinzufügenneuer Information und Anpassen des bestehendenDatensatzes

  34. Physische Designprinzipien Zwei Dimensionale Historisierung

  35. Physische Designprinzipien RelationsnotatioN • Das DDS Datenmodel nutzt die EntityRelationship Notation, wie sie im Erwin Data Modeler benutzt wird. • Beispiel einer 1:1 Relation:

  36. Physische Designprinzipien RelationsnotatioN • Beispiele von 1:N Relationen: Optionale Relation zwischen Department und Employee (beideRichtungen) Verpflichtende Relation zwischen Departmentund Employee (beide Richtungen) Employee muss ein Department haben, das Department muss keinen Employee haben

  37. Physische Designprinzipien RelationsnotatioN • Beispiel einer identifizierenden Relation: Die Beziehung zeigt an, dass ein EMPLOYEE nicht außerhalb des Kontext eines Departments existieren kann Identifizierende Relation zwischen Tabellen

  38. Physische Designprinzipien RelationsnotatioN • Beispiel von M:N Relation: • Ein Konto kann mehreren Kunden gehören und einKunde kann • mehrere Konten besitzen • Diese M:N Relation kann durch das Einführen einer Zwischentabelle im physischen Datenmodell aufgelöst werden

  39. GemeinsameTabelle Account Loan Account Tabelle Mortgage Account Tabelle andere Account Tabellen Physische Designprinzipien Modellierung Supertyp/Subtyp Relationen • Immer wenn mehrere Tabellen Informationen gemeinsam haben, werden sie in einer Tabelle gespeichert: • Gemeinsame Informationen in einer Tabelle • Verschiedene Informationen in getrennten Tabellen • Ein Attribut in der Supertyptabelle dient als Diskriminator um die richtige Subtyptabelle zu finden • Beispiel:

  40. Physische Designprinzipien Supertype/Subtypetables Gleiche Surrogatschlüssel Diskriminator Attribut

  41. Account Tabelle Open Date Close Date AnderestatischeAttr. Account Change Tabelle Balance Outstanding Days AndereraschänderndeAttr. Physische Designprinzipien Modellierung: „FrequentlyChangingData“ • Immer wenn eine Tabelle sowohl schnell als auch langsam ändernde Attribute aufweist: • Die schnell ändernden Attribute werden in eine getrennte Tabelle ausgelagert • Beispiel:

  42. Physische Designprinzipien Transaktionstabelle • Transaktionstabellen dienen zum Speichern von Events, die zu einem bestimmten Zeitpunkt passieren. • Eine typische Spalte ist das TRANSACTION_DT, meist kein VALID_FROM – VALID_TO:DT • Zum Beispiel Zahlungen auf einem bestimmten Konto • Beispieltabellen: • LOAN_TRANSACTION • FX_QUOTE • CUSTOMER_ACCOUNT_SCORE

  43. Physische Designprinzipien Referenztabellen • Referenztabellen enthalten Code Definitionen und deren Übersetzung. • Referenztabellen haben immer ein _CD Attribut für den Code ein _DESC Attribut für die Beschreibung der Codebedeutung • Referenztabellen enthalten Attribute zur Historisierung im Falle einer Änderung einer Codebedeutung • Referenztabellen enthalten ein LANGUAGE_CD Attribut, um Bedeutungen von Codes in unterschiedliche Sprachen Übersetzen zu können • Beispiele: • ACCOUNT_STATUS • ASSET_TYPE

  44. Physische Designprinzipien Mastertabellen • Mastertabellen sind Tabellen von zentraler Bedeutung, sie haben meist mehr als 100 Zeilen und sie werden häufig beladen (abgeändert) • Mastertabellen enthalten typischerweise fünf folgende Attribute: • * _RK für den Surrogatschlüssel • VALID_FROM_DTTM und VALID_TO_DTTM für die Historisierung • *_ID für den natürlichen, fachlichen Schlüssel • SOURCE_SYSTEM_CD zu Speicherung des Quellsystems aus dem das *_ID Feld stammt • Beispiele: • FINANCIAL_PRODUCT • FINANCIAL_ACCOUNT • CUSTOMER • COUNTERPARTY

  45. Physische Designprinzipien IntersectionTabellen • Intersection Tabellen werden benötigt, um M:N Beziehungen aufzulösen. • Z.B: Ein Mitarbeiter kann mehr als einer internen Organisationseinheit angehören und eine interne Organisationseinheit hat meist mehr als einenMitarbeiter • Sind an *_X_* im Namen zu erkennen • Beispiele: • EMPLOYEE_X_INTERNAL_ORG • CUSTOMER_X_FINANCIAL_ACCOUNT

  46. Physische Designprinzipien Assoziationstabellen • Assoziationstabellen werden verwendet um Beziehungen zwischen zwei Zeilen einer Tabelle herzustellen • Assoziationstabellen haben ein _ASSOC Suffix. • Alle Assoziationstabellen haben ein ASSOC_TYPE_CD Attribute, um die Art der Beziehung zwischen den beidenZeilen zu definieren • Assoziationstabellen können zum Speichern vonHierarchien verwendet werden • Beispiele: • INTERNAL_ORG_ASSOC • PRODUCT_CATEGORY_ASSOC

  47. Physische Designprinzipien Assoziationstabellen • Assoziationstabellen werden verwendet um Beziehungen zwischen zwei Zeilen einer Tabelle herzustellen • Assoziationstabellen haben ein _ASSOC Suffix. • Alle Assoziationstabellen haben ein ASSOC_TYPE_CD Attribute, um die Art der Beziehung zwischen den beidenZeilen zu definieren • Assoziationstabellen können zum Speichern vonHierarchien verwendet werden • Beispiele: • INTERNAL_ORG_ASSOC • PRODUCT_CATEGORY_ASSOC

  48. ORG 5 ORG4 ORG 3 ORG 2 ORG 1 GEO – Geographische Hierarchie REP – Reportinghierarchie Physische Designprinzipien Hierarchien mit Assoziationstabellen Internal_Org Tabelle • Beispiel: Interne Organisationsstruktur

  49. Physische Designprinzipien Assoziationstabellen Designvorteile: • Bietet Modellierungsmöglichkeiten für: • Multiple Hierarchien • Hierarchien variabler Tiefe • Vermeidet die Notwendigkeit Hierarchie/Levels hart zu codieren • Sehr flexibel verwendbar und reduziert daher die Notwendigkeit individuelle Datenmodellanpassungen vorzunehmen

  50. Physische Designprinzipien Erweiterbarkeit des SAS BIS DDS (Customizing)

More Related