Copyright © 2014, SAS Institute Inc. All rights reserved. SAS BANKING INTELLIGENCE ARCHITECTURE DETAIL DATA STORE (SAS BIS DDS) EINFÜHRUNG FÜR VW FS –

Copyright © 2014, SAS Institute Inc. All r ights reserved.

SAS BANKING INTELLIGENCE ARCHITECTUREDETAIL 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

• Logische Designprinzipien• Allgemein und anhand eines konkreten Themas: Meldewesen

• Banking DDS Betrieb• Installation und Beladung

• Diskussion und Verbleib


KURZE EINFÜHRUNGSAS BIS DDS


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)

Hohe Folgekosten durch nachträgliche ÄnderungenZu nahe an den Quellsystemen orientiert

Vertrauensverlust durch lange ProjektlaufzeitenFehlende Akzeptanz bei Nutzersystemen

Unterschätze Aufwände für Kommunikation und DokumentationVerschiebung der Priorität in der Umsetzung

Verwässung der Standards über ZeitZu ambitionierte einheitliche Sicht auf Daten

0 10 20 30 40 50 60 70 80 90 100

TOP Ursachen für gescheitere DWH Vorhaben


DWH WESENTLICHE HERAUSFORDERUNGEN

AnalysetiefeGrad der fachlichen Abdeckung und Potential für zukünftige Analysen

Single-version-of-the-truth als Basis für einheitliches Reporting und Analytics

IntegrationstiefeGrad der Integration zwischen fachlichen Applikationen / Nutzern des Modells

Erreichung durch viele Iterationen bzgl. Gesamtdesign des Modelles

NutzungsflexibilitätQualität der Integration zwischen fachlichen Applikationen

Ausreichende Flexibilität in der Nutzung durch richtige Abstraktionen

ModellstabilitätGrad der Auswirkung einer Änderung auf gekoppelten Bereiche / Module

Hohe Modellstabilität ist zentrales Ziel zur Erreichung von Kostensenkungen

StandardisierungsbreiteNiedrige Standardisierungsbreite deutet auf zu generische Modellierung hin

Hohe Standardisierungsbreite ist nicht konkret genug um Mehrwert zu bringen


SAS BIS DDSDREI SCHLÜSSELKRITERIEN ZUR AUSWAHL EINES INDUSTRIEDATENMODELLS

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

Funktionsabdeckung

Datenmodell–basierende, fertige Lösungen beweisen Vollständigkeit und Richtigkeit.

Risikosteuerung

Kundensteuerung

Personal

Rechnungswesen

Meldewesen

Banksteuerung

Praxistauglichkeit

Nur nachhaltige Kundenprojekte beweisen Praxistauglichkeit.

300 Referenzen weltweit

SAS erfüllt alle drei Kriterien!!


SAS BIS DDS „DAS AVOKADO PRINZIP“

Maximale Integrationstiefe bei sinnvoller Standardisierungsbreite

• Hohe Integrationstiefe bedeutet gute Modellstabilität

• Kostenintensive „moving source“ Szenarien werden vermieden

• Sicherung der Wirtschaftlichkeit der Investition durch hohe Standardisierungsbreite

• Beibehaltung der Nutzungsflexibilität durch einfache Erweiterbarkeit

Mangelhafte Analysetiefe (fachliche Abdeckung)

• Keine Mehrwert aufgrund fehlender „Intellectual Property“

• Hohe Folgekosten durch hohe Eigenentwicklung

SAS BISDDS

Mangelhafte Integrationstiefe

• Einsatz eines nicht-integrierten Datenmodelles ist nicht sinnvoll

• Hohe Folgekosten durch Designiterationen und Doppelentwicklungen


DATENHALTUNGSKONZEPTE UND BANKING DDSWAS IST DAS SAS BIS DDS?


DATENHALTUNGS-KONZEPTE UND

BANKING DDS

ZU UNTERSTÜTZENDE PROZESSE– WARUM HALTEN WIR DATEN?

Management ProzessUmsetzung von Informationen zurSteuerung des täglichen Betriebes

Business IntelligenceProzessAnalytische Verarbeitung, Informationsgewinnung, Entscheidungshilfe

Business Operations ProzessVerarbeitung von Informationen des normalen, täglichen Betriebes


DATENHALTUNGS-KONZEPTE

• Z.B.: Google Big Table

• Große Datenmengen – Big Data, Flache aber multidimensionale Tabelle

• NoSql (Not only Sql)

• 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 über Attribute 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



RELATIONAL SYSTEME – ‚ENTITY/RELATIONSHIP‘ MODELLE



MULTI-DIMENSIONALE SYSTEME – ‚STAR SCHEMA‘

http://upload.wikimedia.org/wikipedia/de/5/55/Sternschema.png


DATENHALTUNGS-KONZEPTE UND

BANKING DDS

ZU UNTERSTÜTZENDE PROZESSE– WARUM HALTEN WIR DATEN?

Management ProzessUmsetzung von Informationen zurSteuerung des täglichen Betriebes

Business IntelligenceProzessAnalytische Verarbeitung, Informationsgewinnung, Entscheidungshilfe

Business Operations ProzessVerarbeitung von Informationen des normalen, täglichen Betriebes

Decision Support SystemeDSS

Operationale SystemeOLTP – Online Transaction Processing


OLPT VS DDS VERGLEICH DER SCHWERPUNKTE

• Optimiert für:

• Hohe Anzahl an Transaktion mit begrenztem Datenvolumen

• Genau definierte, hohe Performance-anforderungen

• Hochverfügbarkeit – ‚system is mission critical‘

• 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

Operationale Systeme - OLTP Decision Support Systeme - DSS


VERGLEICH DER DATEN-

MANIPULATIONENVERGLEICH DER SCHWERPUNKTE

• Datenvolumen/Transaktion +

• Inserts ++

• Updates +++

• Leseprozesse +

• Löschprozesse ++

• Datenvolumen/Transaktion +++

• Inserts ++

• Updates n.a.

• Leseprozesse +++

• Löschprozesse n.a.

Operationale Systeme - OLTP Decision Support Systeme - DSS

WIDERSPRÜCHLICHE NUTZUNGSMUSTER!


OLPT VS DSS SCHLUSSFOLGERUNG

• Widersprüchliche Nutzungsanforderungen zwischen OLTP- und DSS-Systemen

• Trennung der Systeme, hinsichtlich Hardware-, Software- und Datenarchitektur

• Unterschiedliche Designs erforderlich


DSS - SYSTEME VARIANTEN

• Data Warehouse (DWH)

• Data Mart

• Operational Data Store (ODS)


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


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


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


WAS IST DAS BANKING DDS?

SAS BIS DDS - DEFINITION

• Das SAS BIS DDS dient als ‚single version of the truth‘ 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.


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 for Banking Solutions

Deployment auf SAS Datenhaltung oder allen gängigen RDBMS


SAS BIS DDS BIG PICTURE!


SAS BIS DDSERWIN MODELLE ALS BESTANDTEIL DER DOKUMENTATION- OPTIONAL POWERDESIGNER


SAS BIS DDS INTEGRATION IN VERBINDUNG MIT SAS DI STUDIO


SAS BIS DDS INTEGRATION MIT SAS DATA QUALITY KOMPONENTEN


PHYSISCHE DESIGNPRINZIPIENDATENMODELLIERUNGSASPEKTE UND ERWEITERBARKEIT


SAS BIS DDS MODELLIERUNG UND STANDARDISIERUNG

Allgemeines

Schlüsselmanagement

Entitätsklassen

Attributkategorisierung

Historisierung

Relationales Datenmodell in 3. Normalform

Gängige Datenbankplattformen werden unterstützt

Generierter Surrogatschlüssel und separate Speicherung der Quellsystem ID

Primärschlüssel aus Surrogatschlüssel und Gültigkeitsperioden

Kategorisierung von Entitäten aufgrund gemeinsamer Charakteristika

Berücksichtigung in Namenskonvention zur Reduzierung der Komplexität

Kategorisierung der Attribute aufgrund Datentype und Verwendung

Berücksichtigung in Namenskonvention zur Reduzierung der Komplexität

Historisierung unter Verwendung von SCD Type 2 Konzept

Optimierung auf rasches Einfügen, Löschen und Gesamtbestandsabfrage


PHYSISCHE DESIGNPRINZIPIEN

SURROGATSCHLÜSSEL

• Ein Surrogatschlüssel wird generell als Primärschlüssel einer DDS-Tabelle genutzt(_RK für „Retained Key“)

• Ein Surrogatschlüssel ist 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



TYPISCHE DDS TABELLE SCHLÜSSELMANAGEMENT

Fachlicher, natür-licher Schlüsselfür diese Tabelle

Surrogatschlüssel für diese Entität

Primärschlüssel für diese Entität

Zeitfelder für Versionierung

CUSTOMER

CUST_RK: SurrogateKey (AK1.1,AK2.1)VALID_FROM_DTTM: ValidFrom

VALID_TO_DTTM: ValidToEFFECTIVE_FROM_DTTM: EffectiveFromEFFECTIVE_TO_DTTM: EffectiveToCUST_ID: BusinessKeyLong (AK3.1)MASTER_CUST_ID: BusinessKeyLongINDV_CUST_RK: SurrogateKey (FK)EXTERNAL_ORG_RK: SurrogateKey (FK)INTERNAL_ORG_RK: SurrogateKey (FK)MANAGING_CHANNEL_CD: DefaultCode (FK)SOURCE_CHANNEL_CD: DefaultCode (FK)SOURCE_SYSTEM_CD: DefaultCodeLAST_MOVED_DT: DateTimePREFERRED_CHANNEL_CD: DefaultCodeCUST_LIFECYCLE_CD: DefaultCodeCUST_TYPE_CD: DefaultCodeSOURCE_CD: DefaultCodeFIRST_BECAME_CUST_DT: DateTimeLAST_PURCHASE_DT: DateTimeSERVICE_PROVIDER_CD: DefaultCodePROMOTION_ID: BusinessKeyShortCURRENCY_CD: DefaultCode



TYPISCHE DDS TABELLE – ZUSATZATTRIBUTE

Optional “Business Effective”

Fremdschlüssel (surrogate)

…_CD Schlüssel einer ... Referenztabelle

AttributeColumns

CUSTOMER

CUST_RK: SurrogateKey (AK1.1,AK2.1)VALID_FROM_DTTM: ValidFrom

VALID_TO_DTTM: ValidToEFFECTIVE_FROM_DTTM: EffectiveFromEFFECTIVE_TO_DTTM: EffectiveToCUST_ID: BusinessKeyLong (AK3.1)MASTER_CUST_ID: BusinessKeyLongINDV_CUST_RK: SurrogateKey (FK)EXTERNAL_ORG_RK: SurrogateKey (FK)INTERNAL_ORG_RK: SurrogateKey (FK)MANAGING_CHANNEL_CD: DefaultCode (FK)SOURCE_CHANNEL_CD: DefaultCode (FK)SOURCE_SYSTEM_CD: DefaultCodeLAST_MOVED_DT: DateTimePREFERRED_CHANNEL_CD: DefaultCodeCUST_LIFECYCLE_CD: DefaultCodeCUST_TYPE_CD: DefaultCodeSOURCE_CD: DefaultCodeFIRST_BECAME_CUST_DT: DateTimeLAST_PURCHASE_DT: DateTimeSERVICE_PROVIDER_CD: DefaultCodePROMOTION_ID: BusinessKeyShortCURRENCY_CD: DefaultCode



HISTORISIERUNG

Beispiel

Hinzufügen neuer Information und Anpassen des bestehenden Datensatzes

INTERNAL_ORG_RKVALID_FROM_DTTM VALID_TO_DTTM ORGANIZATION_NM

100 01-JAN-1999 12:00:00 31-DEC-2000 23:59:59 Marketing

100 01-JAN-2001 00:00:00 01-JAN-5999 00:00:00 World Wide Marketing

INTERNAL_ORG_RKVALID_FROM_DTTM VALID_TO_DTTM ORGANIZATION_NM

100 01-JAN-1999 12:00:00 01-JAN-5999 00:00:00 Marketing

Bestehender Datensatz

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



ZWEI DIMENSIONALE HISTORISIERUNG

Beispiel

Hinzufügen neuer Information und Anpassen des bestehenden Datensatzes

INTERNAL_ORG_RK

VALID_FROM_DTTM

VALID_TO_DTTM

Effective_From Effective_To ORGANIZATION_NM

100 01-JAN-1999 12:00:00

31-DEC-2000 23:59:59

Marketing

100 01-JAN-2001 00:00:00

01-JAN-5999 00:00:00

World Wide Marketing

INTERNAL_ORG_RK

VALID_FROM_DTTM

VALID_TO_DTTM

Effective_From Effective_To ORGANIZATION_NM

100 01-JAN-1999 12:00:00

01-JAN-5999 00:00:00

Marketing

Bestehender Datensatz

Unterscheidung zwischen technischer Gültigkeit und fachlicher Gültigkeit Erfordert Adaptierung der CDC Logik Steuerung für nachfolgende Applikationen über Views



ZWEI DIMENSIONALE HISTORISIERUNG

Domäne Namens-konvention Kommentar / Beispiel

Identifier _ID z.B. ID in Quellsystemen (CUSTOMER_ID)

Small Code _CD z.B. ADRESS_TYPE_CD

Medium Code _CD z.B. EXCHANGE_SYMBOL_CD

Large Code _CD z.B. POSTAL_CD

Count Code _CNT z.B. AUTHORIZED_USER_CNT

Name _NM z.B. FIRST_NM

Short Length Text _TXT Beliebige Verwendung

Medium Length Text _TXT, _DESC Beliebige Verwendung, z.B. code table desc.

Indicator Field _FLG Binärindicator, z.B. DEFAULT_FLG

Surrogate Key _RK, _SK Generierte Surrogatschlüssel

Currency Amount _AMT Standard Währungsbetrag, z.B. LIMIT_AMT

Rates _PCT, _RT z.B. exchange rates

Date / Time _DT, _DTTM Datum und Uhrzeit, z.B. DEFAULT_DATE



RELATIONSNOTATION

• Das DDS Datenmodel nutzt die Entity Relationship

Notation, wie sie im Erwin Data Modeler benutzt wird.

• Beispiel einer 1:1 Relation:



RELATIONSNOTATION

• Beispiele von 1:N Relationen:

Optionale Relation zwischen Department und Employee (beide Richtungen)

Verpflichtende Relation zwischen Departmentund Employee(beide Richtungen)

Employee muss ein Department haben, das Department muss keinen Employee haben



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



RELATIONSNOTATION

• Ein Konto kann mehreren Kunden

gehören und ein

Kunde kann• mehrere Konten besitzen

• Diese M:N Relation kann durch das

Einführen einer Zwischentabelle im

physischen Datenmodell aufgelöst

werden

• Beispiel von M:N Relation:



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:

Gemeinsame Tabelle Account

Loan Account Tabelle

Mortgage Account Tabelle

andere Account Tabellen



SUPERTYPE/SUBTYPE TABLES

Gleiche Surrogatschlüssel

Diskriminator Attribut



MODELLIERUNG: „FREQUENTLY CHANGING DATA“

Immer wenn eine Tabelle sowohl schnell als auch langsam ändernde Attribute aufweist:• Die schnell ändernden Attribute werden in eine getrennte

Tabelle ausgelagert

Beispiel:

Account Tabelle

Open DateClose DateAndere statische Attr.

Account Change Tabelle

BalanceOutstanding DaysAndere rasch ändernde Attr.



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



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



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



INTERSECTION TABELLEN

• 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 einen

Mitarbeiter• Sind an *_X_* im Namen zu erkennen• Beispiele:

• EMPLOYEE_X_INTERNAL_ORG• CUSTOMER_X_FINANCIAL_ACCOUNT



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 beiden

Zeilen zu definieren• Assoziationstabellen können zum Speichern von

Hierarchien verwendet werden• Beispiele:

• INTERNAL_ORG_ASSOC• PRODUCT_CATEGORY_ASSOC




• 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 beiden

Zeilen zu definieren• Assoziationstabellen können zum Speichern von

Hierarchien verwendet werden• Beispiele:

• INTERNAL_ORG_ASSOC• PRODUCT_CATEGORY_ASSOC



HIERARCHIEN MIT ASSOZIATIONSTABELLEN

ORG 5

ORG 3 ORG4

ORG 1 ORG 2

GEO – Geographische Hierarchie

REP – Reportinghierarchie

• Beispiel: Interne Organisationsstruktur INTERNAL_ORG_RK ORG_NM INTERNAL_ORG_REFERENCE_NO

3001 ORG1 IT1

3002 ORG2 IT2

4001 ORG3 T2

4002 ORG4 T3

5001 ORG5 AT3

Internal_Org Tabelle




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


PHYSISCHE DESIGNPRINZIPIENERWEITERBARKEIT DES SAS BIS DDS (CUSTOMIZING)



CUSTOMIZATION

• Adding Tables• You can add tables to support a new business area or to enhance

the functionality of an existing business area that is not in the

current banking DDS. New tables should be added with a prefix (for

example, X_) to distinguish them from tables that are provided in

the current banking DDS.

• Adding Columns• You can add columns to existing tables in the banking DDS to

support a new business area or to enhance the functionality of an

existing business area that is not in the current banking DDS. New

columns should be added with a prefix (for example, X_) to

distinguish them from columns that are provided in the current

banking DDS.



CUSTOMIZATION

• Expanding Column Length• You can expand the column length to accommodate the data from upstream applications. You

should perform an impact analysis before expanding the length of a column to avoid truncation in

tables in downstream applications.

• Changing Formats and Informats• You can change the formats and informats to address the local language requirements.

• Storing Descriptions in Different Languages• Reference tables allow descriptions to be stored in multiple languages. Use the LANGUAGE_CD

column in the reference table to specify the language for the description. Remember the

downstream processing impact if you store a description in more than one language.



MODIFICATIONS TO AVOID

• Avoid changing column names.

They have significant impact on already implemented downstream processing .

• Avoid changing data types for columns.

This can also have significant impact on already implemented downstream processing.

• Deletion of columns is not recommended.

Columns that are not required by the client can hold missing values.

• Avoid changing the intended content of columns.

Add a new column instead.



PROCESS FOR MODEL MODIFICATIONS

• Goal is:- Create new/modified physical data structures- Update the SAS metadata structures

• End product:- Updated DDL saved to source management- Updated documentation (ERWin file, data dictionary, pdfs)



PROCESS FOR MODEL MODIFICATIONS

1. Make addition in ERWin file or update DDL scripts directly

2. Create Physical tables by running DDL

3. Update Metadata definitions

For tables - “Register Tables”

For columns - “Update Metadata”

4. Store updated collateral/code in source management

DDL, ERWin file, Data Dictionary


LOGISCHE DESIGNPRINZIPIENALLGEMEIN UND ANHAND EINES KONKRETEN THEMAS: MELDEWESEN


LOGISCHE DESIGNPRINZIPIEN

MODELL DESIGN

Grobe EinteilungDas SAS BIS DDS kann auf einer groben Ebene in sogenannte „Subject Areas“ eingeteilt werden

„Subject Areas“„Subject Areas“ kann man als oberste Ebene von Geschäftsobjekten verstehen.

GeschäftsobjekteDiese Geschäftsobjekte stehen in einer logischen Verbindung zueinander



„SUBJECT AREAS“



ÜBERBLICK FACHLICHE INHALTE UND „SUBJECT AREAS“



VIER WESENTLICHE „SUBJECT AREAS“IM DETAIL

• Parties

• Financial Accounts(Financial Instruments,Financial Postions)

• Credit Facility

• Credit Risk Mitigant



„SUBJECT AREA“: „PARTIES“



„SUBJECT AREA“: „PARTIES“

Kernkonzept• Eine COUNTERPARTY kann ein CUSTOMER sein oder auch nicht

• Eine COUNTERPARTY wird genauer spezifiziert durch:• CUSTOMER, oder• EXTERNAL_ORGANISATIONON, oder • EXTERNAL_INDIVIDUAL, oder• INTERNAL_ORGANISATION, oder• EMPLOYEE …

• Ein Kunde ist entweder ein INDIVIDUAL_CUSTOMER oder ein CORPORATE CUSTOMER



COUNTERPARTY

Counterparty

Customer

External Individual

Internal Org

External Org

Employee



CUSTOMER

Customer

EmployeeExternal

OrganizationOwners

Individual Customer

Corporate Customer



„SUBJECT AREA“: „FINANCIAL ACCOUNTS”






„SUBJECT AREA“: „FINANCIAL ACCOUNT”

Account Typen des SAS BIS DDS:• Savings

• Checking / Current

• Loan

• Mortgage

• Credit Card

• Investment

• Core Banking Account

• Lease Account

• Life Insurance

• Motor Insurance

• Travel Insurance

• Property Insurance

• Protection Insurance

• Retirement / Pension




Financial Accounts

Account TypesSpecific

ProvisionsCredit

Assessments

Transactions

Credit Facilitie

Counterparties

Customers

Credit Risk Mitigants



„SUBJECT AREA“: „FINANCIAL INSTRUMENTS“



„SUBJECT AREA“: „FINANCIAL INSTRUMENTS“

Kernkonzept• Alle gehandelten Wertpapiere werden in diesen Entitäten gespeichert.

• Es gibt eine Beziehung zu den RISK_FACTOR TABELLEN.

• FINANCIAL_POSITION nimmt Daten zu einzelnen Positionen und Transaktionen auf.

• Es gibt eine Verbindung zu COUNTERPARTY.

• Es gibt eine Verbindung zu CREDIT_RISK_MITIGANT Daten.

• Es gibt eine Verbindung zu Ratings.

• Es gibt eine Verbindung zu Ausfällen und Verzügen.



„SUBJECT AREA“: „FINANCIAL POSITION“



FOLGENDE WERTPAPIERTYPEN WERDEN UNTERSTÜTZT

• Cash Instruments

• Funds

• Equities

• Bonds

• Commodities

• Currency Swaps

• Credit Derivatives

• Warrants

• Convertible Bonds

• Swaps

• Options

• Swaptions

• Forward Rate Agreements (FRA’s)

• Receivables

• Repurchase Agreements (Repos)

• Securitization

• Exotic Options

• Cash flow Options and Forwards



INSTRUMENT QUOTES

Financial Instrument

Financial Instrument Calc. Spec.

Financial Instrument Association

Financial Position

Financial Instrument

CHNG

EquityDerivative

Option Bond

…

Quote Tables



„SUBJECT AREA“: „CREDIT FACILITY“

ToDo: Andreas




Kernkonzept• Eine Credit Facility speichert jede Art von Off Balance Exposure

• Eine Credit Facility kann zu einem oder mehreren Fianncial Accounts gehören

• Es können auch verschachtelte Beziehungen zwischen Credit Facilities gespeichert werden




Credit Facilities

GroupsSpecific

ProvisionsCredit

Assessments

Transactions

Financial Accounts

Credit Risk Mitigants

Counterparties



„SUBJECT AREA“: „CREDIT RISK MITIGANT“



„SUBJECT AREA“: „ CREDIT RISK MITIGANT“

Kernkonzept

• CRADIT_RISK_MITIGANT ist die zentrale Tabelle für alle Sicherheiten

• Details werden in Subtabellen abgebildet:PHYSICAL_COLLATERALLS, FINANCIAL_COLLATERALS, GUARANTEES, RECEIVEABLES

• Es gibt Verbindungen zu:COUNTERPARTY, FINANCIAL_ACCOUNT, FINANCIAL_POSITION und CREDIT_FACILITY, CREDIT_DERIVATIVES



„SUBJECT AREA“: „ CREDIT RISK MITIGANT“

Credit Risk Mitigant

Financial Position

Financial Account

ReceivablesPhysical Collateral

GuaranteesFinancial Collateral

Credit Cerivatives

Mitigant

Credit Facility

Counterparty



VERTIEFUNG IM HINBLICK AUF VW FS MELDEWESEN


VERTIEFUNG MELDEWESEN QUELLSYSTEME DER VW FS

• LAM - Finanzierungsanfragen für KREDIS. Anträgen, nur bestätigte Anträge sind für MW relevant

• CIC – Claim Management

• EWB - Einzelwertberichtigungen

• LX - Large Exposures -> für Meldewesen Barsicherheiten

• ABS - Asset backed Securities

• Risk - Ausfälle, Scorings, Verzüge

• VOKUS - Konzernkonsolidierung, Konsolidierungskreise etc.

• BCA - Bankingdaten, Girokonten und Direct Banking

• KREDIS - Kredite und Finanzierungen

• LEASIS – Leasingverträge

• CML - Darlehen an die Händler und Tochtergesellschaften

• CFM - Treasury

• ZGP - zentraler Geschäftspartner

• HF - Händlerfinanzierungen, als Unterstruktur zu BCA zu verstehen.

• FI - Debitoren und Kreditorenbuchhaltung, nur Teile des Hauptbuches

• FS-CD - Debitorenbuchhaltung auf Leasingforderungen


MELDEWESEN QUELLSYSTEME

VW FSMAPPING ZU RELEVANTEN SAS BIS DDS ENTITÄTEN

• FINANCIAL_ACCOUNT

• CREDIT_FACILITY

• LOAN ACCOUNT

• LEASE_ACCOUNT

• CORE_BANKING_ACCOUNT

• FINANCIAL_ACCOUNT_CHNG

• COUNTERPARTY

• CUSTOMER

• INDIVIDUAL_CUSTOMER

• CORPORATE_CUSTOMER

• CREDIT_RISK_MITIGANT

• BCA - Bankingdaten, Girokonten und Direct Banking

• KREDIS - Kredite und Finanzierungen

• LEASIS – Leasingverträge

• CML - Darlehen an die Händler und Tochtergesellschaften

• HF - Händlerfinanzierungen, als Unterstruktur zu BCA zu verstehen.

• CIC – Claim Management




• CFM - Treasury • FINANCIAL_INSTRUMENTS

• FINANCIAL_POSITION

• BOND_INSTRUMENT

• EQUITY_INSTRUMENT

• OPTION_INSTRUMENT

• FINANCIAL_INSTRUMENT_ASSOC

• CREDIT_RISK_MITIGANT




• ZGP - zentraler Geschäftspartner • COUNTERPARTY

• CUSTOMER

• INDIVIDUAL_CUSTOMER

• CORPORATE_CUSTOMER

• EXTERNAL_ORGANISATION




• FI - Debitoren und Kreditorenbuchhaltung, nur Teile des Hauptbuches

• FS-CD - Debitorenbuchhaltung auf Leasingforderungen

• LAM - Finanzierungsanfragen für KREDIS. Anträgen, nur bestätigte Anträge sind für MW relevant

• EWB – Einzelwertberichtigungen

• GENERAL_LEDGER

• FINACIAL_ACCOUN_APPLICATION

• SPECIFIC_PROVISION




• ABS - Asset backed Securities

• Risk - Ausfälle, Scorings, Verzüge

• FINANCIAL_INSTRUMENT

• SECURITISATION_INSTRUMENT

• DEFAULT_EVENT

• RATING_GRADE

• ACCOUNT_X_RATING_GRADE

• INSTRUMENT_RATING_GRADE

• CUSTOMER_XRATING_GRADE




• VOKUS - Konzernkonsolidierung, Konsolidierungskreise etc.

• INTERNAL_ORG

• INTERNAL_ORG_ASSOC

• EXTERNAL_ORG

• EXTERNAL_ORG_ASSOC


LOGISCHELOGISCHE DESIGNPRINZIPIENAUSGEWÄHLTE PRODUKTABBILDUNGEN IM SAS BIS DDS


AUSGEWÄHLTE PRODUKT-

ABBILDUNGENOPTIONAL: DARSTELLUNG KONKRETER BEISPIELE

Siehe Beispiele in Excel Darstellung


BANKING DDS BETRIEBINSTALLATION UND BELADUNG DES SAS BIS DDS


SAS BIS DDS INSTALLATIONSERFORDERNISSE

• SAS Foundation 9.4

• SAS Data Integration Studio

• SAS Metadata Server und ein Metadaten Repository

• Banking DDS:• DDL Scripts• Metadaten Package (SPK files)• Dokumentation• Erwin Data Model

* Bereits für SAS Credit Scoring for Banking bei VW FS im Einsatz


SAS BIS DDS INSTALLATIONSPROCESS


SAS BIS DDS BELADUNG

• Schritt 1: Definition der zu beladenden Daten• Das Banking DDS ist designt um mehrere Lösungen zu unterstützen, obwohl nicht

alle Solution gleichzeitig implementiert werden müssen.Das BANKING DDS muss also nicht komplett befüllt werden.

• Eine genaue Liste der zu befüllenden Entitäten sollte erstellt werden

• Schritt 2: Daten aus den Quellsystemen extrahieren

• Schritt 3: Daten Konsolidierung und Data-Cleansing• Dabei sollten die Daten bereits in die DDS Struktur gebracht werden

• Schritt 4: Beladung der Reference Tables

• Schritt 5: Beladung und Validierung der restlichen Tabellen• Die korrekte Beladungssequenz muss eingehalten werden. Zum Beispiel kann einen ACCOUNT_TRANSACTION

erst beladen werden, wenn der zugehörige ACCOUNT bereits existiert.

• Die Loading-Stage hat bereist die gleiche Struktur wie das DDS, mit der Ausnahme, dass noch keine *_RK- Felder und keine Gültigkeitsdatums existieren müssen

• Die Beladung erfolgt mittels des SDD II Loader-Plug-In des SAS DI Studio


MEHRWERTE VON SAS BIS DDSINDUSTRIE STANDARD DATENMODELL VS. EIGENTWICKLUNG


ZUSAMMENFASSUNG ARGUMENTEN FÜR EIN INDUSTRIE STANDARD DATENMODELL

Analystenaussagen u.a. Für Industrie Standard DM spricht: Kosteneffektiv (nicht kurzfristig, aber langfristig)

Deckt aktuelle Marktanforderungen ab und ist zukunftsorientiert (wird fachlich kontinuierlich erweitert)

Weitreichende Automatisierung und Standardisierung

Best Practices aus einer Vielzahl von Implementierungen

Stabile Basis für schnellen Projektstart

Hohe Agilität und Flexibilität

Fördert zentrale „Information Governance“ und den Kulturwandel im Sinne eines unternehmensweiten „single point of truth“ (inkl. Rückfluss von Ergebnisinformationen aus unterschiedl. FBen)

Fördert die Kommunikation und das Verständnis für IT und Buiness Sicht > Zusammenarbeit von IT und FB durch Konzentration auf die fachlichen Inhalte und definierte Prozesse und vorgegebener Modellsicht

Ist dafür ausgelegt, schnell die richtigen Informationen bereitzustellen (auswertungsorientiert)


MAKE VS. BUY ZWEI WESENTLICHE VORTEILE VON BUY-VARIANTE

Einsparung der Modellierungsphase Reduzierung des Diskussions- und

Abstimmungsaufwandes Sofortiger „Zielorientierter“ Start Komplexitätsreduktion durch 80/20 Ansatz

(Kerndatenmodell)

► Bessere „Time to Intelligence“ bei höherem Lernaufwand und ca. gleichen Einführungskosten

Höhere Modellstabilität in den Kernentitäten führt zu deutlich reduzierten Change-Aufwänden am Daten-Modell

Einsatz in der Praxis erzeugt Investitionssicherheit

Make

Buy

Zeit

Kosten

Buy

Make

Zeit

Ergebnisse

Deutliche schnellere Ergebnisse

Geringere Folgekosten


SAS BIS DDSZENTRALER HEBEL FÜR KOSTENSENKUNG UND QUALITÄTSVERBESSERUNG IN DER STEUERUNG


SAS BIS DDS MEHRWERTE FÜR VW FS

Kürzere Implementierungszeiten durch Industriedatenmodell und vorgefertigte Komponenten

Wirtschaftlichkeit im Betrieb

Klare Strukturen durch Vorgaben und Reduzierung der Komplexität(Keine Work-Arounds, Historisierung, fachliche Definitionen, Erweiterbarkeit etc.)

Bewerte Integration in bestehende IT Landschaft

Fachliche Vorzüge(Analytics, vorkonfigurierte Lösungen etc.)

Verfügbarkeit(Daten, IT-Performance, Time to Market)

Bestehendes Know How und Praxis Erfahrungen bei VW FS

Erfüllung von BCBS 239 Anforderungen(Integrierte Datenhaushalt, Data Governance, Transparenz, etc.)

Copyright © 2014, SAS Institute Inc. All r ights reserved. www.SAS.com

VIELEN DANK FÜR IHRE AUFMERKSAMKEIT

http://www.sas.com/


BACKUP


IMPLEMENTATIONSAS BIS DDS


VORGEHENS-WEISE

UMSETZUNG AUF BASIS SAS INTELLIGENCE SOLUTIONS IMPLEMENTATION METHODOLOGY


VORGEHENS-WEISE

AGILE METHODOLOGIE MIT KURZEN ITERATIONEN NACH PHASEN, SUBJECT AREA‘S UND FINANZPRODUKTEN

Counterparties

Financial Products

Risk Mitigants

Models & Scores

…2

3 Entity Mapping

Field Mapping

Transformation Rules

Check with Target

System

1 Infrastruktur Mapping CodierungQualitäts-sicherung

Zeitleiste

…


VORGEHENS-WEISE

STANDARDISIERTE MAPPING TEMPLATES ZUR EFFIZIENTEN DOKUMENTATION DER ANFORDERUNGEN


VORGEHENS-WEISE

VORGEFERTIGTE BUSINESS SZENARIEN ALS UNTERSTÜTZUNG IM MAPPING PROZESS


VORGEHENS-WEISE

VORGEFERTIGTE BUSINESS SZENARIEN ALS UNTERSTÜTZUNG IM MAPPING PROZESS

Data Delivery

Data Management

Data AcquisitionLoad Strategies CDC Historisierung

Job Templates Dev. Guidelines Staging Design

Archivierung

Recovery

Korrekturen

Key Management

Entity Types

Nameskonvention

Access & Security

Mart Transform.

Views

De-Normalization

ABT Creation

…

Documents

Copyright © 2014, SAS Institute Inc. All rights reserved. SAS BANKING INTELLIGENCE ARCHITECTURE DETAIL DATA STORE (SAS BIS DDS) EINFÜHRUNG FÜR VW FS –