toad data modeler

Herzstück der Analytik – Ist DatenDaten
modellierung für BI wirklich so schwer?
München, 17. Juni 2013, BARCM2, 15:00 – 18:00
y
BI/DWH
Jacqueline Bloemen, Senior Analystin
Abstract
Datenmodellierung spielt vor allem für BI eine fundamentale Rolle. Das Datenmodell
prägt
p
g die Verwendbarkeit in der Analytik,
y
da in vielen BI-Architekturen über eine
semantische Schicht - aber ohne weitere Applikationslogik – auf die Daten zugegriffen
wird. Modellierungsentscheidungen bestimmen auch die Änderungsfreundlichkeit im
Sinne zukünftiger Weiterentwicklungen. Gleichzeitig gilt, dass es in der
Datenmodellierung kein absolut Richtig und Falsch gibt, und so sind Alternativen der
M d lli
Modellierung
wie
i auch
hd
der D
Datenarchitektur
t
hit kt iin d
der P
Praxis
i unter
t E
Experten
t vielfach
i lf h
umstritten.
Aber nicht nur Experten haben mit Modellierung zu tun. Auch Fachanwender müssen
sich mit Datenmodellen auseinandersetzen, sofern sie Anforderungen an BI formulieren
oder selbst Auswertungen erstellen. Die faktisch vorhandene Komplexität der Datenwelt
ist Anwendern aber regelmäßig schwer zu vermitteln. Unternehmens- und BIspezifische
p
Fragestellungen
g
g machen es auch erfahrenen Datenarchitekten schwer,,
richtige Entscheidungen zu treffen und verständlich zu kommunizieren.
Dieser Track gibt einen Überblick der im Data Warehousing und BI verwendeten
Modellierungsmethoden und bringt sie in einen praktischen Verwendungskontext.
Verwendungskontext
28.05.2013
© BARC 2013
2
Agenda
g
• Datenmodellierung für Data Warehouse und BI –
Problemstellung und Lösungskonzepte
• Modellierung in der BI Architektur – Von der Konzeption bis
zur Auswertung
A
t
Pause 16:15-16:45
• BI Anforderungsmanagement und Data Governance –
Schnittstelle Fachbereich / IT
• Referenzdatenmodelle für BI – Überblick, Nutzen und
Grenzen
• Ausblick – hat Datenmodellierung im Zeitalter von Big Data
ausgedient?
28.05.2013
© BARC 2013
3
Architektur und Modelle – Daten,, das Herzstück des BI
Prozesse
Prozessmodell
Daten
Datenmodell
Architektur
•
Business Intelligence
Services
Monitoring
Reporting
Ad‐hoc Analysis
Planning
Legal Consolidation
Advanced Analysis
Visualization
Management
Services
Collaboration
Data Provisioning
Services
Semantic Layer
Caching
Relational Data Storage Dimensional
Data Storage
System & Process Monitoring
Federation/
Virtual Data Stores
Data Modeling
Integration &
Integration & Quality Services
M t Dt M t
Meta Data Mgt.
Data Quality
Data Integration
Enrichment
Master Data
Security
Automation
Operational and other source systems
28.05.2013
•
BI und DWH Prozesse
• Datentransformationsprozesse
ergeben sich aus dem Mapping
von Datenmodellen
• Auswertungsprozesse werden
durch Benutzerinteraktionen und
nicht durch SW gesteuert
• Kein Fokus der Modellierung für BI
und DWH
BI und DWH Daten
• Fokus der Modellierung für BI und
DWH
© BARC 2013
4
„Commodity
„
y Knowhow“ ?
•
•
ANSI-SPARC – 1975
Konzeptionell
p
• ERM – P. Chen et al, seit 1976 ff
• OLAP – E. Codd, 1993
• ADAPT/T-ADAPT – seit 1998/1999
•
Implementierung
Datenmodellierung
Konzeption (fachlich)
Implementierung ( h
(technisch)
h)
• Relationale DBMS
• seit 1970 Theorie
• seit Anfang 80er Praxis
• Multidimensionale DBMS
•
•
•
•
•
Seit 1970 IRI Express
Seit 1983 Applix
pp TM1
Anf. 90er Arbor Essbase
Etc.
BI Datenarchitektur
• Building the Data Warehouse
– W. Inmon, 1991
• The Data Warehouse Toolkit
– R. Kimball,, 1997
28.05.2013
© BARC 2013
5
Ebenen der Unternehmensmodellierung
g
Unternehmen
Meist behandelte Ebenen
der Modellierung, isoliert
nach Applikation
betrachtet
Domäne
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
28.05.2013
Data
W h
Warehouse
BI
A lik ti
Applikation
© BARC 2013
6
Ebenen der Unternehmensmodellierung
g
Meist behandelte Ebenen
der Modellierung, isoliert
nach Applikation
betrachtet
Realität:
•Kein einheitliches Geschäftsmodell vorhanden
•Kein einheitliches Geschäftsmodell vorhanden,
• Fachgebiete
Versuche der 80er und 90er meist gescheitert
Unter(subject areas)
•Keine einheitliche Begriffswelt (Homonyme, Synonyme)
nehmen
•Adaption von Begriffen aus den operativen Systemen
d
ff
d
•Fehlende Wahrnehmung für Heterogenität durch
• Geschäftsmodell
Domäne
Kontext‐spezifische Perspektiven(business model)
• Logisch
• Physisch
Applikation
Operational
28.05.2013
Data
W h
Warehouse
BI
A lik ti
Applikation
© BARC 2013
7
Datenmodellierung
g für Data Warehouse
Entity Relationship Modeling
Dimensionale Modelierung
customer
region
contract
product
customer
shipment
measures
product
payment
time
account
•
•
•
•
28.05.2013
Normalisiert (3.NF)
(3 NF)
Referentielle Integrität
Optimiert für
•
Detaillierte Daten
•
Datenpflege
•
„System of record“
(„System der Aufzeichnung“)
Gut geeignet für technische Experten
•
•
•
Fokussiert
F
k
i t auff fachliche
f hli h Di
Dimensionen
i
und
d
Kennzahlen
Optimiert für dimensionale Analyse
•
Detaillierte und aggregierte Daten
•
Reporting
•
Ad hoc Analyse
•
OLAP
Gut geeignet für Fachanwender
© BARC 2013
8
Datenmodelierung
g – ERM und DM Varianten
ERM – Varianten
•
•
•
•
DM – Varianten
SERM – Structured ERM
UML - Unified Modeling Language
Data Vault
Notationen
•
•
•
•
•
•
•
•
Chen
Bachmann
Martin / IE / Crows Foot
UML
•
Dimensional ERM
DF - Dimensional Fact
ADAPT - Application Design for
Analytical Processing Technologies
UDM – Unified Dimensional Modeling
g
(MS)
BISM - BI Semantic Model (MS)
region
Werkzeuge - Beispiele
customer
contract
shipment
product
payment
account
•
•
•
•
•
•
•
•
•
28.05.2013
CA ErWin
Sybase Powerdesigner
(
(jetzt
S )
SAP)
IBM InfoSphere Data Architect
Embarcadero ER/Studio
Microsoft Visio
rDBMS Werkzeuge
(z.B. Toad Data Modeler)
mDBMS Werkzeuge
UML Werkzeuge
g
Vielfach unzureichend für DWH/BI ausgelegt
customer
measures
product
time
© BARC 2013
9
Beispiele
p
für ERM Notationen
28.05.2013
© BARC 2013
10
Normalierungsregeln
g
g
((für rDBMS))
•
Aufteilung von Attributen (Tabellenspalten) in mehrere Relationen (Tabellen) gemäß den
Normalisierungsregeln, um Redundanzen zu vermeiden
•
Bekanntesten Normalformen sind die erste, zweite und dritte Normalform (1NF, 2NF, 3NF)
•
•
•
1NF – Jedes Attribut der Relation hat einen Atomaren Werteberiech
2NF – 1NF liegt
li
vor und
d kein
k i Ni
Nichtschlüsselattribut
h hlü
l ib ist
i ffunktional
ki
l abhängig
bhä i von einer
i
echten
h
Teilmenge eines Schlüsselkandidaten
3NF – 2NF liegt vor und kein Nichtschlüsselattribut ist von einem anderen Nichtschlüsselattribut
funktional abhängig
Tabelle tbl AuftragAlles
AuftragsID
2
KundenID
1
AdressID
1
LfdAdrNr
2
3
1
1
1
4
2
2
1
KundenID
1
1
2
LfdAdrNr
2
1
1
Tabelle tbl Auftrag
AuftragsID
2
3
4
Tabelle tbl Kunden
KundenID
1
2
28.05.2013
Firma
Meyer & Meyer KG
Alfredo Pasta GmbH
AbwLiefAnschrift
Firma
Ja Meyer Int.S/A
Meyer & Meyer
Nein KG
Alfredo Pasta
Nein GmbH
AbwLiefAnschrift
Ja
Nein
Nein
Tabelle tbl Adressen
ID
KundenID
1
1
2
1
3
2
AuftragsNr
2
3
4
LfdAdrNr
1
2
1
AuftragsNr
2
AuftragsDatum zuAngebotNr SachbearbID AuftragsGesamtWert
12.12.2008
1
1
583,79 €
3
15.12.2008
2
1
78,95 €
4
17 12 2008
17.12.2008
4
2
75 00 €
75,00 €
AuftragsDatum
12.12.2008
15 12 2008
15.12.2008
17.12.2008
zuAngebotNr
1
2
4
SachbearbID
1
1
2
AuftragsGesamtWert
583,79 €
78 95 €
78,95 €
75,00 €
Firmenbezeichnungg
Strasse
Meyer & Meyer KG Münchner Str.
Meyer Int.S/A
Münchner Str.
Alfredo Pasta GmbH Münchner Str.
© BARC 2013
11
((Bi-)) Temporale
p
Datenhaltung
g
•
Festhalten zeitlicher Entwicklungen in der Datenbank
•
•
•
(Bi-) Temporale Betrachtungen
•
•
•
•
In OLTP vielfach unüblich – es wird jjeweils nur der letzte Datenstand erhalten
Im DWH elementare Anforderung
Gültigkeitszeit Zeitraum in dem ein Datenelement in der realen Welt gültig ist
Zeitraum,
Transaktionszeit - Zeitpunkt, an dem ein Datenelement im Datenbestand gespeichert
(hinzugefügt/geändert) wurde
Im DWH kann es zudem 2 verschiedene Transaktionszeiten geben – die des OLTP
Systems
y
und die des DWH
„Welcher Preis wurde einem Kunden am 7. Mai für den Kauf des Artikels genannt,
wobei der Kauf erst am 4. Juni stattfinden sollte?“
1,95 €
…
75
7.5.
14.5.
14
5
21 5
21.5.
28 5
28.5.
Erfassung Preisänderung zum 28.5.
Anfrage Preis für Kauf am 4.6.
2,25 €
46
4.6.
…
Anfrage aktueller Preis
Anfrage Preis zum 7.5.
Bestandteil des neuen SQL Standards SQL:2011 (veröffentlicht Dezember 2011)
28.05.2013
© BARC 2013
12
Datensynchronisation
y
- Delta-Verarbeitung
g
•
Redundant g
gespeicherte
p
Geschäftsdaten müssen im
Lebenszyklus synchron gehalten
werden, hier insbes. Quellsystem
und DWH
•
Grundsätzlich zu unterscheiden:
Daten- und Änderungstypen
• Stammdaten
• Transaktionsdaten (Belegdaten)
• absolute
b l t V
Veränderungen
ä d
(Bestandssicht)
• relative Veränderungen
(Bewegungssicht)
• „Full load“ –
Komplettübertragung von
Quelldaten
• „Delta
D lt load“
l d“ – Übertragung
Üb t
von
Änderungen (alle vs. letzte)
1 95 €
1,95 €
…
7.5.
2 25€ ( b l )
2,25€ (absolut)
14.5.
21.5.
28.5.
g
g
Erfassung Preisänderung zum 28.5.
4.6.
…
1,95 €
…
28.05.2013
7.5.
+0,30€ (relativ)
14.5.
21.5.
28.5.
Erfassung Preisänderung zum 28.5.
4.6.
…
© BARC 2013
13
ERM versus DM – Objekte
j
und Eigenschaften
g
ERM
customer
DM
region
contract
product
customer
shipment
measures
product
payment
time
account
•
Subject Area (Themenbereich)
•
Entity (Entität)
•
•
•
•
•
•
Fundamental
Assoziativ
Typisierungs-Hierarchien
Typisierungs
Hierarchien
Attribute
•
•
Auch Elemente genannt
Bestands- und Transaktionskennzahlen je nach
Entitätentyp
Relationship (Beziehung)
Historisierung auf Entitäten-Ebene
•
•
•
28.05.2013
•
•
Fachliche Historie
Technische Historie
„Bi-temporal“
Dimension(-sentität)
Fakt(-enentität)
•
•
•
•
•
Hierarchie
Attribute
•
•
•
Transaktionsorientiert
Periodisch
Kumulativ
Basisattribut
Kennzahl, Typ nach Fakten-Entität-Typ
Historisierung
•
•
•
Dimensionen
Hierarchien
Fakten mittels Zeitdimension und Typ
© BARC 2013
14
ERM – Objekte,
j
, Beispiele
p
•
Fundamentale Entität, z.B.
•
•
•
•
ERM
contract
product
0:1, 1:1, 0:n, 1:n, m:n
verbindlich, optional, identifizierend
z.B. Kunde <>> Kunden-Adresse
shipment
payment
account
Assoziative Entität
•
•
•
customer
Beziehung
g
•
•
•
•
Kunde
K
d
Kunden-Adresse
Vertrag
m:n Beziehungen instanziiert mittels assoziative Entität
z.B. Kunde <<>> Vertrag wird zu Kunde<<>Kundenrolle<>>Vertrag
Typisierungs-Hierarchien (Super-/Sub-Typisierung)
•
•
•
Entitäten von abstrakt bis spezifisch klassifizieren
Gemeinsame Attribute und Beziehungen definieren
z.B. Versicherungsprodukt
• Leben
• Kranken
• Komposit
•
28.05.2013
Für fundamentale und assoziative Entitäten möglich
© BARC 2013
15
ERM – Auflösen von m:n-Beziehungen
g
• m:n Beziehungen können,
müssen aber nicht fachlich
von Relevanz sein
• Kann im logischen Modell
definiert werden
• m:n Beziehungen können
technisch nicht umgesetzt
werden
• Muss im physischen Modell
aufgelöst werden
28.05.2013
Versich.
V
i h
Vertrag
Kunde
Ein Kunde kann an mehreren Versicherungsverträgen
g
g
beteiligt sein, gleichzeitig können an einem
Versicherungsvertrag mehrere Kunden beteiligt sein.
Kunde
Kundenrolle
Versich.
Vertrag
Die Zuordnung von Kunden zu Versicherungsverträgen wird
mittels einer entsprechenden Rolle präzisiert, etwa
Versicherungsnehmer oder versicherte Person
© BARC 2013
16
ERM und Historie
•
Beziehung zwischen 2 Entitäten drückt
zunächst eine Momentaufnahme aus
•
•
Beispiel:
Ein Vertrag gehört immer genau zu einer
P li
Police
1,1
1,n
Police
Vertrag
Modelliert man Historie im ERM Modell
•
•
•
28.05.2013
Verlieren Beziehungen ihre fachliche
Aussagekraft
Muss dem fachlichen Schlüssel die
Gültigkeit hinzugefügt werden oder ein
künstlicher Schlüssel verwendet werden
Beispiel:
Ändert sich die betreuende Agentur der
Police, muss eine neue Version des
Policensatzes angelegt werden – es gibt
2 Sätze zur gleichen Policennummer;
bei unveränderten Verträgen beziehen
sich diese sowohl auf die alte als auch
die neue Policenversion, je nach
Zeitbetrachtung
1,n
Police
1,n
Vertrag
© BARC 2013
17
ERM und Historie – Ankerkonzept
p
•
•
•
Abbildung fachlicher Beziehungen
mittels „Anker“-Entitäten
• Fachlicher Schlüssel sowie
technische Informationen
Historie mittels eigener
g
Entitäten
• Eindeutigkeit über fachlichen
Schlüssel + Gültigkeit
• Technisch mittels
Surrogatschlüssel umgesetzt
PolicenAnker
1,1
1,n
VertragsAnker
1,n
PolicenPolicen
Historie
1,n
VertragsVertrags
Historie
Meist im logischen oder
physischen Datenmodell, nicht im
Business Modell
28.05.2013
© BARC 2013
18
Datenmodellierung:
g ERM vs. Data Vault
Data Vault
ERM
customer
history
customer
anchor
shipment
contract
product
history
customer
satellite
product
anchor
customer
hub
shipment
link
payment
account
anchor
•
•
28.05.2013
Normalisiert (3NF)
•
Häufig mit Anker-Konzept für
Stammdatenhistorie angewendet
Entitäten
•
Fundamental
•
Anker
•
Beziehungsentität
•
Super-/Subtypisierung
product
satellite
contract
link
product
hub
payment
link
account
hub
•
•
Normalisiert (3NF)
•
Spezielle Regeln für Stammdatenhistorie mittels Satelliten-Entitäten
Entitäten
•
Hub
•
Satellite
Li k
Link
•
© BARC 2013
19
ERM und Typisierungs-Hierarchien
yp
g
Super-/Sub-Typisierung
Partner
•
Natürliche
Person
Generalisierung von Entitäten
• Übergreifende Attribute
• Übergreifende
Ü
Beziehungen
!
VN
VP
Agenturinhaber
•
Juristische
Person
Sollte aber keine
Rollenspezifizierung abbilden
Int.
Organisation
• Versicherungsnehmer als
Rolle gegenüber einem
Versicherungsvertrag
• Organisationshierarchie eines
Unternehmens
28.05.2013
Ext.
Organisation
Natürliche
N
tü li h
Person
VN
Versich.V
i h
vertrag
Int.
Organisation
Hier.
Übergeordnet
Int.
Organisation
© BARC 2013
20
Variationen der Dimensionalen Modellierung
g
Star Schema
Snowflake Schema
product
family
region
region
product
line
profession
customer
measures
product
customer
measures
product
age group
time
28.05.2013
time
© BARC 2013
21
DM – Objekte,
j
, Beispiele
p
•
Dimension, z.B.
•
•
•
•
•
•
region
customer
measures
product
time
Fakten
•
•
•
•
•
Kunde
Prod kt
Produkt
Region
Zeit
Attribute bestimmen Granularität,
diese kann, muss aber nicht höher sein als Entität
Star
Transaktional, z.B. Kontotransaction, Kauftransaction (Einzelposten)
Periodisch, i.S. Stichtags-Betrachtung, z.B. Kontostand zum Monatsende
Kumulativ, i.S. gesamte Gültigkeitsdauer eines Ereignisses, z.B. Prozessüberwachung
Typ beeinflusst zeitliche Granularität und Aggregationsregeln
Hierarchie
•
•
•
Aggregations- und Navigationspfad im Datenraum einer Dimension
z.B. Produktfamilie > Produktlinie > Produkt
z.B. Jahr > Monat > Tag, Jahr > Woche > Tag
product
family
region
product
line
profession
•
Würfel
•
•
•
•
•
28.05.2013
1 Faktenentität
n Dimensionsentitäten
Faktengranularität bestimmt durch Summe der Dimensionsattribute
Star oder Snowflake
Multi-star für Joins verschiedener Würfel
customer
measures
product
age group
time
Snowflake
© BARC 2013
22
Granularität – Eine Definition für DM
•
Was ist Granularität?
•
•
Fakten- und Dimensionsentitäten bestimmten die Granularität eines Würfels und
insbesondere den Detaillierungsgrad der Daten, die in der Faktentabelle gespeichert
werden.
Beispiele für Granularität in DM:
•
•
•
•
•
Einzelposten auf einem Kassenzettel, auf einer Quittung, auf einer Restaurantrechnung,
auf die Rechnung vom Krankenhaus
Kontostand am Monatsende
Wöchentlicher Produktinventurstand im Warenhaus
Einzelnes Flugticket mit einem bestimmten Kaufdatum
Busfahrkarte gekauft und gültig an einem gegebenen Tag
Periodische P
i di h
Fakten
28.05.2013
© BARC 2013
23
Dimensionen modellieren - zusammengefasst
g
•
Dimensionen identifizieren
•
•
•
•
Konforme Dimensionen
Degenerierte Dimensionen
Dimensionale Attribute
Dimensionale Hierarchien
•
•
Datums- und Zeitgranularität identifizieren
•
•
Kennzahlaktualität – bestimmt durch Faktentyp
Dimensionsaktualität
•
•
•
Kaskadierende n:1-Beziehungen:
• Balanced standard
• Unbalanced standard
• Ragged
• Unbalanced recursive
„Slowly
Slowly changing dimensions
dimensions“
„Very fast changing dimensions“ (mit Hilfe Mini-Dimensionen)
Weitere Herausforderungen
•
•
•
•
•
28.05.2013
Garbage dimensions (für Attribute niedriger Kardinalität)
Multi-value dimensions (Fakten beziehen sich auf >1 Dimension(-sattribut), bspw. VP)
Role-playing dimensions (Häufig bei Zeit, z.B. Fälligkeitsdatum vs. Zahlungsdatum)
Heterogeneous dimensions (z.B. Produktdimension)
Hot swappable dimensions (verschiedene Sichten auf eine Dimension bspw. unter Anwendung
von Filter,
Fil
zur Abfragezeit
Abf
i austauschbar
hb
© BARC 2013
24
DM und Historie
Historienanforderungen Grundsätzlich zu unterscheiden nach:
PK=Agtnr
•
Dimensionshistorie – mittels SCDTyp oder Rollendimensionen
•
•
Beispiele:
Agent heiratet, der Nachname ändert
sich
Agent zieht um, Überordnung ändert
sich
VertriebsDimension
Fakten
ZeitDimension
Fakten
ZeitDimension
Fakten
ZeitDimension
PK=Agtnr zzgl. Gültigkeit
VertriebsDimension
PK=Surrogat
VertriebsDimension
Kennzahlhistorie – mittels
Zeitdimension
•
28.05.2013
Beispiele:
Transaktional – häufig keine Historie,
Historie
Momentaufnahme
Periodisch – Zuordnung der
Zeitdimension, Schnappschuss zum
Termin
Kumulativ – Zuordnung der
Zeitdimension, häufig mehrere
Sichten
Transaktionale
T
ki
l
Fakten
Z it TXZeit:
TX
Datum/Zeit
Periodische
Fakten
Zeit: Stichtag
Akkumulierte
Fakten
Zeit: ProzessZeitraum
© BARC 2013
25
Dimensionen und Historie
Dimensionsaktualität
• „Slowly changing dimensions“
• Typ 1 – Historie überschreiben
• Typ 2 – Historie erhalten
mittels Surrogatschlüssel und
Gültigkeit
• Typ 3 – Teilhistorie für
ausgewählte Attribute erhalten
• „Very fast changing
dimensions“
• mit Hilfe Mini-Dimensionen
28.05.2013
© BARC 2013
26
„Role-playing
„
p y g dimensions“
28.05.2013
© BARC 2013
27
Agenda
g
• Datenmodellierung für Data Warehouse und BI –
Problemstellung und Lösungskonzepte
• Modellierung in der BI Architektur – Von der Konzeption bis
zur Auswertung
A
t
• BI Anforderungsmanagement und Data Governance –
Schnittstelle Fachbereich / IT
• Referenzdatenmodelle für BI – Überblick, Nutzen und
Grenzen
• Ausblick – hat Datenmodellierung im Zeitalter von Big Data
ausgedient?
28.05.2013
© BARC 2013
28
Ebenen der Unternehmensmodellierung
g
Unternehmen
„Übersetzung“ im Rahmen der BI Projekte Domäne
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
z.B. Komposit,
L b
Leben,
K
Kranken
k
28.05.2013
Data
W h
Warehouse
z.B.
Police/Vertrag,
Beitrag, Schaden
BI
A lik ti
Applikation
z.B. Schadenstatistik,
Performance der
Schadensbearbeitung
© BARC 2013
29
Ebenen der Unternehmensmodellierung
g
Unternehmen
„Übersetzung“ im Rahmen der BI Projekte Domäne
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
Mapping
• Logisch
• Physisch
Applikation
Operational
z.B. Komposit,
L b
Leben,
K
Kranken
k
28.05.2013
Data
W h
Warehouse
z.B.
Police/Vertrag,
Beitrag, Schaden
BI
A lik ti
Applikation
z.B. Schadenstatistik,
Performance der
Schadensbearbeitung
© BARC 2013
30
Datenmodellierung
g für BI und Data Warehousing
g
Business Intelligence
Services
Meist
diskutiertes
Daten-Modell
Monitoring
Reporting
Ad‐hoc Analysis
Planningg
Legal Consolidation
Legal Consolidation
Advanced Analysis
Visualization
Management
Services
Collaboration
Data Provisioning
Services
Semantic Layer
Caching
Relational Data Storage Dimensional
Data Storage
Federation/
Virtual Data Stores
Integration & Quality Services
System & Process Weitere
M it i
Monitoring
Ebenen der
DatenData Modeling
Modellierung
Meta Data Mgt.
Data Quality
Data Integration
Enrichment
Master Data
Security
Automation
Operational and other source systems
28.05.2013
© BARC 2013
31
Welche Datenarchitektur – welche Architekturebene?
Independent Data Marts,
Independent
Data Marts,
Analytical Applications
BI Services
BI Services
BI Services
Central Data Warehouse
BI Services
Hub & Spoke
Data
Mart
Data
Mart
BI Services
BI Services
Data
M t
Mart
Data
M t
Mart
IQ Services
OLTP
Data
M t
Mart
Data
M t
Mart
Data
M t
Mart
BI Services
Data
M t
Mart
Data
M t
Mart
Data
M t
Mart
Data
M t
Mart
Data
M t
Mart
Data
M t
Mart
Data
Mart
Data
Warehouse
IQ Services
Master Data Management
Data Mart Bus
IQ Services
Data
Warehouse
Conformed
Dimensions
DP Services
DP Services
DP Services
IQ Services
IQ Services
IQ Services (KPIs)
OLTP
OLTP
OLTP
Data
Warehouse
DP Services
IQ Services (MDM)
IQ Services
OLTP
MDM Master
MDM
•
Gängige BI Datenarchitekturen
•
•
•
•
U ab ä g ge Data
Unabhängige
a a Marts
a s
Zentrales Data Warehouse
Hub & Spoke (Inmon)
Data Mart Bus (Kimball)
Besondere Datenarchitekturen
 Master
as e Data
a a Management
a age e
(Stammdatenverwaltung)
 Virtualisierung (Föderation)
 Hybrid Datenarchitekturen
Data
M t
Mart
28.05.2013
• Fachliche und technische Schwächen des zentralistischen Ansatzes
• „Hub & Spoke“
H b&S k “
• Data Warehouse UND Data Marts
Versch. Expertenssichten
• Eine eindeutige, qualitätsgesicher
te Quelle für alle Analysen
• „Zentrales Data W h
Warehouse“
“
Grenzen
n
• Aufgaben‐
orientierte Datenbestände für Analyse
• „Unabhängige D t M t“
Data Marts“
• Problem der Inkonsistenzen und Wartungs‐
aufwände
„Single Point of TTruth“
Historie
e
Evolution der Datenarchitektur für BI und DWH
• fachliche Anforderungen
• methodische Umsetzung
• Heraus‐
forderungen der Unternehmens‐
realität
• „Data Mart Bus“
• „hybride Daten‐
h b id
architektur “
© BARC 2013
33
Datenarchitekturen – Beispiele
p
für Anwendungsfälle
g
I di id ll D
Individuelle
Data
t Marts
M t
Zentrales EDW
Hub & Spoke
Data Mart Bus
Föderiertes EDW
28.05.2013
• Gut integrierte OLTP/ERP-Systeme
• Kein Bedarf an einer gesonderten, integrierten SoR
• Selektive Erweiterung zu anderen Datenarchitekturen
• Umfassende Datenintegrationsanforderungen
g
g
• Bedarf an einer integrierten SoR
• Entweder sehr leistungsstarke EDW Plattform oder weniger komplexe
Analyseanforderungen (oder beides)
•
•
•
•
U f
Umfassende
d D
Datenintegrationsanforderungen
t i t
ti
f d
Bedarf an einer integrierten SoR
Sehr heterogene Analyseanforderungen
Anwendung unterschiedlicher/proprietärer BI Technologie
• Weniger umfassende Datenintegrationsanforderungen
• Keine/niedriger Bedarf an einer integrierten SoR
• Vornehmlich dimensionale Sicht auf Daten in der Analyse
• Wenige, gut integrierte OLTP/ERP-Systeme
• Weniger komplexe Analyseanforderungen, niedrige Daten-/AnwenderVolumen
• Operationales/Echt-Zeit BI
• Vor allem bei KMUs
© BARC 2013
34
Hub & Spoke
p
vs. Data Mart Bus
Unterschiedliche Expertenmeinungen: ERM vs. dimensionale Modellierung, Inmon vs. Kimball
Endanwender Zugriff
Endanwender Zugriff
BI Services
Data
Mart
BI Services
Data
Mart
Data
Mart
Data
Mart
Atomic
Data
Mart
Atomic
Data
Mart
Aggr.
Data
Mart
Aggr.
Data
Mart
Eingeschränkter Zugriff
Conformed
Facts
Atomic Data
Warehouse
DP Services
DP Services
IQ Services
IQ Services
Staging
Area
OLTP
28.05.2013
Conformed
Dimensions
Staging
Area
OLTP
© BARC 2013
35
Hub & Spoke
p
vs. Data Mart Bus – System
y
of Record
BI Serv
vices
BI Serv
vices
Unterschiedliche Lösungen zur Abdeckung von SoR Anforderungen
Data
Mart
Data Distribution
mögliche SoR
Atomic Data
Warehouse
Data Integration
IQ Services
Atomic
Data
Mart
Data
Mart
Staging Area
28.05.2013
Aggr.
Aggr
Data
Mart
Data Distribution
Conformed
Facts
Aggr.
Aggr
Data
Mart
mögliche SoR
Conformed
Dimensions
Data Integration
Staging Area
Extraction
OLTP
Atomic
Data
Mart
DP
P Services
Data
Mart
IQ Services
DP
P Services
Data
Mart
mögliche SoR
Extraction
OLTP
© BARC 2013
36
BI Serv
vices
Hub & Spoke/Data
p
Mart Bus kombiniert
Data
Mart
DP
P Services
Data
Mart
Data
Mart
Data
Mart
Atomic Data
Warehouse
Data Distribution
Data Distribution
Conformed
Facts
IQ Services
Data Integration
Conformed
Dimensions
Mö li h weitere
Mögliche
it
Datenbereiche:
D t b
i h
•
•
•
•
Klassifizierte Quellen
Archivierte Daten
Sensitive Daten
Analytische Ergebnisdaten
Staging Area
Extraction
OLTP
28.05.2013
© BARC 2013
37
Hybride Datenarchitektur –
z.B.
B U
Unabhängige
bhä i DM + H
Hub
b&S
Spoke
k
BI Services
BI Services
Data
Mart
Data
Mart
•
•
•
•
•
Data
Mart
Data
Mart
Data
Warehouse
DP Services
DP Services
IQ Services
IQ Services
IQ Services
OLTP
Stark verbreitet
•
Variationen
•
•
•
Mit zentralem Data Warehouse
mit Föderation
Mit anderen Data Management und BI Lösungen
•
•
•
•
•
IQ Services
MDM
CPM
Operational BI
Finanzkalkulationen
Andere Typen von Standard Software
• Möglicherweise aufgrund
technologischer oder architektureller
Widersprüche, z.B.
•
•
•
28.05.2013
Historisch gewachsen
Migrationsphase alt/neu
Zeitliche oder budgetäre Restriktionen
Fehlende Überlappung der fachlichen
A f d
Anforderungen
SAP BW
SAS
MDBMS
© BARC 2013
38
38
Exkurs: Hub & Spoke
p
basierend auf SAP BW
• SAP BW impliziert eigene
Datenarchitektur
BI Services
SAP BIA
Info
Cube
Info
Cube
Info
Cube
Info
Cube
SAP BW
(DSO)
Quasi Hub & Spoke
A f Basis
Auf
B i “business
“b i
content”
t t”
Über alle Schichten
Optional “in-memory accelerator”
(BIA)
• Quellsystemunterstützung
DP Services
SAP BW
IQ Services
•
•
•
•
3rd Party
IQ Services
•
•
Gut für SAP
Für Andere häufig mttels getrennter
IQ Services
OLTP
• Eingeschränkte Unterstützung
hybrider Umgebungen
28.05.2013
© BARC 2013
39
39
SAP <> non-SAP – Integration?
g
SAP/non‐SAP Integration?
SAP Bex, SAP BO
Non‐SAP BI Tool (?)
SAP BIA
Data
Mart
Info
Cube
Info
Cube
Data
Mart
Data
Mart
Info
Cube
Data Warehouse
SAP BW (DSO)
DP Services
DP Services
SAP BW
IQ Services
3 rd Party
IQ Services
OLTP
40
Sandboxing
g – exemplarisch
p
mit SAS
• Self-service
Self service BI
BI Services
BI Sandbox
• Power User
• Business Analysten
• Abteilungs-/Bereichs-BI
Abteilungs /Bereichs BI
Data
Mart
Data
Mart
Data
Warehouse
Data
Mart
• Erweiterte Flexibilität
Ind.
copy
DP Services
DP Sandbox
IQ Services
IQ Sandbox
OLTP
•
•
•
•
Top-Management-Unterstützung
Forschung
Komplexe Analyse
Nicht im EDW enthaltenen
Informationsquellen
•
•
•
Unternehmen
Extern
Individuell
• Kurz-Frist Anforderungen
• Ausnutzung besonderer
Technologie, z.B. Appliances,
Cloud-Computing
• Governance-Ausrichtung
g
herausfordernd
28.05.2013
© BARC 2013
41
41
Zwischenfazit
• Zwei gängige, etablierte Methoden für BI Datenmodellierung
• weisen jeweils Stärken und Schwächen auf und
• sind jeweils für bestimmte Anwendungsbereiche geeignet.
• Wahrgenommene Komplexität der Datenmodellierung für BI kann
nicht
i ht allein
ll i iin di
diesen zugrunde
d liliegenden
d M
Methoden
th d liliegen.
• Komplexität der Datenmodellierung für BI liegt darüber hinaus
begründet in
• dem Mapping verschiedener, Applikationsspezifischer, meist
technisch orientierter Datenmodelle aufeinander,
• der Notwendigkeit, eine heterogene Datenarchitektur im
U t
Unternehmen
h
b
betreiben
t ib zu müssen
ü
ohne
h wahrhaftige
h h fti Ch
Chance auff
einen physisch etablierten Single Point of Truth und
• dem Fehlen eines übergreifenden Geschäftsdatenmodells als
Fundament für das Applikationsübergreifende Modellmapping.
Modellmapping
• Komplexität der BI Datenwelt ist nicht per se Ursache sondern
mehr Wirkung der genannten Hintergründe.
42
Agenda
g
• Datenmodellierung für Data Warehouse und BI –
Problemstellung und Lösungskonzepte
• Modellierung in der BI Architektur – Von der Konzeption bis
zur Auswertung
A
t
• BI Anforderungsmanagement und Data Governance –
Schnittstelle Fachbereich / IT
• Referenzdatenmodelle für BI – Überblick, Nutzen und
Grenzen
• Ausblick – hat Datenmodellierung im Zeitalter von Big Data
ausgedient?
28.05.2013
© BARC 2013
43
Anforderungsmanagement:
K
Kommunikation
ik ti als
l Herausforderung
H
f d
28.05.2013
© BARC 2013
44
Datenmodellierung für BI und DWH – wichtiges
Bi d li d der
Bindeglied
d FB/IT-Kommunikation
FB/IT K
ik ti
Unternehmen
Domäne
Mapping
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
28.05.2013
Data
W h
Warehouse
BI
A lik ti
Applikation
© BARC 2013
45
Typische
yp
Fachanwendersicht in BI Projekten
j
BI Services
Business Intelligence
Services
Monitoring
Reporting
Ad‐hoc Analysis
Planning
Legal Consolidation
Advanced Analysis
Visualization
Management
Services
Collaboration
Data Provisioning
Services
Semantic Layer
Caching
Relational Data Storage Dimensional
Data Storage
System & Process M it i
Monitoring
Federation/
Virtual Data Stores
Data Modeling
Integration & Quality Services
Meta Data Mgt.
Data Quality
Data Integration
Enrichment
Master Data
Data
Mart
Data
Mart
Data
Mart
Data
Mart
D t
Data
Warehouse
DP Services
IQ Services
Security
Automation
OLTP
Operational and other source systems
28.05.2013
© BARC 2013
46
Datenmodellierung für BI und DWH
–Herausforderung
H
f d
P
Projektj kt versus Gesamtsicht
G
t i ht
Unternehmen
Domäne
Mapping?
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
28.05.2013
Data
W h
Warehouse
BI
A lik i
Applikation
© BARC 2013
47
Anwendungsbeispiel
g
p - Ausgangslage
g g g
Fiktives Beispiel aus der Versicherungsbranche
F hli h A
Fachliche
Anforderung
f d
• Vertriebsstatistik für Außendienst-Mitarbeiter und deren
Führungskräfte
• Monatsanfangsbestand, Stück und Beitrag
• Aufgelaufene Monatsbewegungen (tagesaktuell) nach
Zugang, Mehr-/Mindererlös,
Mehr /Mindererlös, Abgang für Stück und Beitrag
• Aufteilung nach Produkte (Sparten)
• Online-Abruf der Berichte über BI-Portal
Quelldaten
• Kraftfahrt-Bestandssystem
• Leben-Bestandssystem
L b B t d
t
• Stammdaten des
Außendienstes
• Partner-Stammdaten
28.05.2013
Weitere Informationen
 Referenzdaten
 Bewegungsarten
 Produkt
 Produkthierarchie
odu t e a c e
© BARC 2013
48
BI Anforderungen
g verstehen – fachlich und technisch
Fachliche Anforderung verstehen
28.05.2013
Quellsysteme verstehen
Data Warehouse modellieren
Data Marts
modellieren
© BARC 2013
49
Anwendungsbeispiel
g
p - Berichtslayout
y
Bestandsentwicklung zum xx.xx.xxxx / Monatsproduktion yyyyyyyyyyyy xxxx
Agentur: aaaaaaaaa / Agent: bbbbbbbbbb
Sparte
KfZ
Leben
Kranken
Sonstige
Bestandsentwicklung zum xx.xx.xxxx
Bestand Vorjahr
Bestand akt. Jahr
+/- in %
JBG
Anzahl
JBG
Anzahl
JBG
Anzahl
Monatsproduktion yyyyyyyyyyyy xxxx
Mehr
Minder
Zugang
Abgang
JBG
Anzahl
JBG
JBG
JBG
Anzahl
KH
VK
TK
KU
SB
HV
BU
HR
..
..
..
..
..
..
..
..
..
..
Bezirk X-X-3 / Leiter Stefan Schmidt
TDWI Volksversicherung Vertrieb Innendienst / Anton Brunner (ABR)
Legende:
xx.xx.xxxx
yyyyyyyyyyyy xxxx
zz.zz.zzzz um zz:zz
28.05.2013
Erstellt am: zz.zz.zzzz um zz:zz
Seite 1 / 1
München, den zz.zz.zzzz
tt.mm.jjjj - letzter Tag des Vormonats
Monatsbezeichnung laufender Monat, ak tuelles Jahr
tt.mm.jjjj um hh:mm - Tag und Uhrzeit der Berichtserstellung
© BARC 2013
50
Anwendungsbeispiel
g
p - Berichtslayout
y
Vertriebsstammdaten
Periodische Zeitdimension
(MonatsFakten yyyyyyyyyyyy
Bestandsentwicklung zum xx.xx.xxxx / Monatsproduktion
xxxx
Agentur:
aaaaaaaaa / Agent: bbbbbbbbbb
Endbestand)
Produktdimension
Sparte
KfZ
Leben
Kranken
Bestandsentwicklung zum xx.xx.xxxx
Bestand Vorjahr
Bestand akt. Jahr
+/- in %
JBG
Anzahl
JBG
Anzahl
JBG
Anzahl
KH
VK
TK
KU
SB
HV
BU
HR
..
..
..
..
..
..
..
..
..
..
Transaktionale
Zeitdimension
FaktenErstellt am:(aufgelaufener
zz.zz.zzzz um zz:zz
Monat)
Monatsproduktion yyyyyyyyyyyy xxxx
Zugang
Mehr
Minder
Abgang
JBG
Anzahl
JBG
JBG
JBG
Anzahl
BewegungsDimension
Vertriebsstammdaten
Sonstige
Bezirk X-X-3 / Leiter Stefan Schmidt
TDWI Volksversicherung Vertrieb Innendienst / Anton Brunner (ABR)
Legende:
xx xx xxxx
xx.xx.xxxx
yyyyyyyyyyyy xxxx
zz.zz.zzzz um zz:zz
28.05.2013
Seite 1 / 1
München, den zz.zz.zzzz
tt.mm.jjjj
tt
mm jjjj - letzter Tag des Vormonats
Monatsbezeichnung laufender Monat, ak tuelles Jahr
tt.mm.jjjj um hh:mm - Tag und Uhrzeit der Berichtserstellung
© BARC 2013
51
BI Anforderungen
g verstehen – fachlich und technisch
Fachliche Anforderung verstehen
Quellsysteme verstehen
Data Warehouse modellieren
Data Marts
modellieren
Berichtslayouts, Kennzahlen, Dimensionen, Änderungsanford.
Profilieren, modellieren, System‐ vs. Fachspezifika, Stammdaten
Generalisierungen, Spezialisierungen, Beziehungen, Historie Dimensions‐ und Faktentypen, SCD, deg. Dimensionen
28.05.2013
© BARC 2013
52
Ebenen der Unternehmensmodellierung
g
Übergreifendes, vereinfachtes Modell
Unternehmen
Domäne
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
Kraftfahrt Bestand
Leben Bestand
28.05.2013
Data
W h
Warehouse
Versicherungsvertrag,
Vertriebs-/Produktstammdaten
BI
A lik ti
Applikation
Vertriebsstatistik:
Monatsanfangsbestand und
aufgelaufene Monatsbewegungen
(tagesaktuell)
© BARC 2013
53
Anwendungsbeispiel
g
p –g
grober Ablauf
Modelle der Quellsysteme
Dimensionales Modell
ERM Modell
Kraftfahrt
Verträge
Extr
akt
Leben
Verträge
Extr
akt
Vertrieb
Extr
akt
Staging
Staging
Integr
ation
DWH
Data
Mart
BI Tool
Staging
DWH Inhalte:
e s c e u gs e t ag
Versicherungsvertrag
Vertreterstamm
Produktstammdaten
28.05.2013
Ableit
ung
Data Mart Inhalte:
a te ((Bestand,
esta d, Bewegung)
e egu g)
Fakten
Dimensionen
(Zeit, Produkt, Vertrieb, Bewegung)
© BARC 2013
54
BI Anforderungsmanagement
g
g
- Daten-orientierte Rollen
Unternehmen
• Fachgebiete
(subject areas)
Business Architect
Fachbegriffe und
Glossar
entwickeln
Domäne
• Geschäftsmodell
Business(business model)
Analyst
Datenmodelle
entwickeln
• Logisch
• Physisch
Applikation
Operational
Analytische
Anforderungen
definieren
Data
Architect
Data
Analyst
Data
W h
Warehouse
BI
A lik i
Applikation
Analytisches
Modell
entwickeln
Projektübergreifende
und
Erfolgsfaktor
P j ktüb
if d BusinessB i
d Daten-Architekten
D t A hit kt als
l kkritischer
iti h E
f l f kt
28.05.2013
© BARC 2013
55
BI Anforderungen
g verstehen - Rollenverteilung
g
Fachliche Anforderung verstehen
Quellsysteme verstehen
Data Warehouse modellieren
Data Marts
modellieren
Berichtslayouts, Kennzahlen, Dimensionen, Änderungsanford.
Profilieren, modellieren, System‐ vs. Fachspezifika, Stammdaten
Generalisierungen, Spezialisierungen, Beziehungen, Historie Dimensions‐ und Faktentypen, SCD, deg. Dimensionen
Data
Analyst
Business
Analyst
Data
Architect
Business
Architect
28.05.2013
Data
Architect
Business
Architect
Data
Architect
Business
Architect
Data
Analyst
Business
Analyst
Data
Architect
Business
Architect
© BARC 2013
56
Datenmodellierung im Rahmen von
I f
Information
ti Management
M
t und
d Governance
G
Fokus der
klassischen
Daten
Datenmodellierung
28.05.2013
© BARC 2013
57
Daten und Funktionen als Teilaspekte
d IT Governance
des
G
BI Governance
Data Governance
•
•
•
Betrachtet Unternehmensdaten
übergreifend zur Verwendung in operativen
und dispositiven Systemen
Keinen speziellen Fokus auf den
Verwendungskontext
•
28.05.2013
Operative Verwendung von Daten meist im
Rahmen des Software Engineering geregelt
Dispositive Verwendung von Daten stellt
zusätzliche, teils umfangreiche
Anforderungen an das Data Governance –
ohne analytischen Kontext sind diese kaum
b ti
bestimmbar
b
n
Funktionen
BI Governance
Dispositiv
Governance Gegenstand
Information Governance
•
Maßgebliche Maßgebliche
Datenquelle
Funktionen
•
Operativ
Datta Daten
Govern
nance
•
Daten
•
häufig
ä f im Rahmen von BI CC Initiativen
adressiert
Dispositive Daten und deren Verwendung in
den BI Applikationen
G t lt
Gestaltungsgrenzen,
da
d operative
ti Systeme
S t
maßgeblich Datenquelle
Ve rwendungskonttext
•
Governance Gegenstand
V
Verwendungsko
ontext
•
Operativ
Dispositiv
© BARC 2013
58
Aspekte
p
des Information Governance
•
Organisatorisch
•
•
•
•
Organizational
Functional
•
Fachlich-inhaltlich
• Richtlinien und Prinzipien
• Anwendungsfälle
• Checklisten
Technical
•
Information Governance
Zentral versus dezentral
Organisationseinheiten
Prozesse
A f d
Anforderung
>K
Konzeption
ti >
Implementierung > Einsatz
Technisch
•
•
•
•
•
Architektur
Werkzeuge
Richtlinien und Prinzipien
Anwendungsfälle
Checklisten
Ebenen des Information Governance
•
Topmanagement (U-weit)
•
•
•
•
„Data Governance Council“
T ib Zi
Treiber,
Ziele
l
Vision, Charta
Geltungsbereich
T kti h (Subject
Taktisch
(S bj t Area,
A
L B/BU)
LoB/BU)
•
•
•
•
•
Taktisch
Operational
Strategisch (U-weit)
•
•
•
•
Strategisch
„Data
Data Steering Committee
Committee“
„Domain Stewards“ per SA
„Steward Coordinators“ per BU
Themen
Prioritäten
Roadmap
Operational
•
•
•
„Data Definers, Producers, Users“
Prozesse und Berichtswege
Standards und Best Practices
Information Governance:
I t /S ll A l
Ist-/Soll-Analyse
anhand
h d „9-Feld-Analyse“
9 F ld A l
“
Organizational
Functional
Technical
IG‐
IG
Aspekte
Information Governance
IG‐
Ebenen
Strategisch
Taktisch
Operational
• Organisatorisch
• Fachlich
• Technisch
• Strategisch
g
• Taktisch
• Operational
Strategisch
Taktisch
Operational
Organisatorisch
Organisatorisch
Organisatorisch
Fachlich
Fachlich
Fachlich
T h i h
Technisch
T h i h
Technisch
T h i h
Technisch
Detaillierung
Aspekte
p
und Ebenen des Information Governance
Strategisch
Taktisch
Operational
Organisatorisch
Organisatorisch
Organisatorisch
Fachlich
Fachlich
Fachlich
Technisch
Technisch
Technisch
Detaillierung
eta e u g
Agenda
g
• Datenmodellierung für Data Warehouse und BI –
Problemstellung und Lösungskonzepte
• Modellierung in der BI Architektur – Von der Konzeption bis
zur Auswertung
A
t
• BI Anforderungsmanagement und Data Governance –
Schnittstelle Fachbereich / IT
• Referenzdatenmodelle für BI – Überblick, Nutzen und
Grenzen
• Ausblick – hat Datenmodellierung im Zeitalter von Big Data
ausgedient?
28.05.2013
© BARC 2013
63
Referenz Datenmodelle (RDMs)
(
)
• Das Datenmodell ist Kernkomponente und Hauptergebnistyp eines
BI Systems
S
• Vorgefertigte, branchenspezifische Datenmodelle für spezielle
Aufgabenstellungen
• Nutzen für Bau und Betrieb analytischer Systeme erwartet
• Unterschiedliche Typen verfügbar
• Unterstützen verschiedene Datenarchitekturen
Independent
p
Data Marts,,
Analytical Applications
Central Data Warehouse
BI Services
Hub & Spoke
Data Mart Bus
BI Services
Master Data Management
BI Services
BI Services
BI Services
BI Services
BI Services
Data
Mart
Data
Mart
IQ Services
Data
Mart
IQ Services
Data
Warehouse
Data
Mart
Data
Mart
Data
Mart
Data
Mart
Atomic
Data
Mart
Atomic
Data
Mart
Conformed
Facts
Data
Warehouse
Aggr.
Data
Mart
Aggr.
Data
Mart
Data
Mart
Conformed
Dimensions
Data
Mart
Data
Mart
Data
Mart
Data
Warehouse
DP Services
DP Services
DP Services
DP Services
IQ Services
IQ Services
IQ Services
IQ Services
OLTP
OLTP
OLTP
OLTP
IQ Services
MDM Master
OLTP
28.05.2013
MDM
© BARC 2013
64
Welche Datenmodell-Ebene,, welche Methode?
Häufiger Fokus Häufiger
Fokus
von RDMs
Unternehmen
Domäne
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
28.05.2013
65
Data
W h
Warehouse
BI
A lik ti
Applikation
© BARC 2013
65
28.05.2013
X
X
X
X
X
X
X
X
X(#)
X
X
X
X
X
X
X
X
X
X
C (UDM)
Universal Data Models, LLC
(X)
X
X
X
Tibco
X
X
Teradata
X
X
Steve Hob
berman & Associaates
X
SAP inkl. B
BO
X
Microsoft
X
Informaticca
X
Kelly & Associate
es Ltd.
SKA Sean K
Data Mart Datenmodell(e) fokussiert Data
Mart Datenmodell(e) fokussiert
auf Datenanalyse für spezifische Anwendungsfälle
Analytische Applikation basierend auf einem spezifischen Data Mart Datenmodell
Stammdatenmanagement basierend auf ein spezifisches, Domänen‐
orientiertes Datenmodell
Other
((*)) The Data Model Scorecard
The Data Model Scorecard®
(#) virtuelle Data Marts
X
SAS
Data warehouse Datenmodell fokussiert auf Datenanalyse
IBM inkl. C
Cognos
Anwendungsbereich
Data warehouse Datenmodell fokussiert auf Datenintegration
fokussiert auf Datenintegration
ADRM Sofftware
Unterschiedliche
Einsatzzwecke
Oracle inkkl. Hyperion
Übersicht RDMs – Kategorien
g
und Hersteller
X
X(*)
© BARC 2013
66
Welche Ziele,, welche Erwartungen?
g
• “Reference
Reference Data Models:
Market Overview and User Experiences”
• Durchführung 2010, Publizierung 2011
• Geschäftlicher Nutzen von Referenzdatenmodell für BI
• Interviews hinsichtlich Projekterfahrungen
• http://www.barc.de/en/research/reference-data-models.html
Standards
• Anpassbar
• Anwenderunterstützung
(fachlich und technisch)
• Ausgleich fehlender
Ef h
Erfahrung
• Modellierungskonventionen
• Dokumentation
28.05.2013
Wissensanreicherung
• Erfahrungen anderer
Unternehmen, des Herstellers
• Domänen‐Wissenslücken
füllen
• Modellierungs‐Wissenslücken M d lli
Wi
lü k
füllen
• Vollständigkeit sicherstellen
• Ersatz für fachlichen Input
Effizienz
• Wiederverwendbarkeit
• Interative Entwicklung
• Projektbeschleuniger
• fachlich
• technisch
• Objektivierung
© BARC 2013
67
RDMs – Was wird geliefert?
g
Klassisches Datenmodell
Andere Formen
• Für EDW mit/ohne Marts
• Logisches / physisches ERM
Modell
• Entitäten, Attribute und
Beziehungen
• Spezifische
Modellierungsstandards, z.B.
• Generalisierung
g
• Historienabbildung
• Surrogatschlüssel
• Dokumentation
• Für analytische Applikationen
• z.B. dimensional oder flach
• Für MDM
Vendoren
• BI Software Vendoren
• Beratungshäuser
Unterstützung marktführender
Modellierungswerkzeuge
customer
region
contract
product
customer
shipment
measures
product
payment
time
account
28.05.2013
© BARC 2013
68
Governance Prozess:
Abd k
Abdeckungsgrad
d RDM
RDMs und
d andere
d
Lösungen
Lö
X
X
X
X
(X)
X
X
X
Emb
barcadero ER//Studio
(X)
X
X
X
CA EErwin
X
(X)
X
X
X
X
X
X
(X)
X
X
X
X
X
Sybaase Power De
esigner (*)
SAP inkl. BO
Oraccle inkl. Hype
erion
ormatica
Info
Teraadata
X
X
X
X
X
X
X
SAS
Meisten RDMs
Functionale Bereiche
Anforderungsentwicklung
Fachliche Modellierung
LogischeDatenmodellierung
Physische Datenmodellierung
Suche (fachliche Perspektive)
Suche (technische Perspektive)
M t d t
Metadatenmanagement
t
IBM inkl. Cognoss
Spektrum der
Lösungen
X
X
X
X
X
X
(X)
(X)
(X)
(*) nun Teil von SAP
28.05.2013
© BARC 2013
69
Information Management
Industry Models Data Warehouse components consist of a
Vocabulary and a set of Data Models
• Banking
• Insurance
• Financial Markets
• Communications
• Health Plan
• Health Provider
• Retail & Distribution
IIW for InfoSphere
Vocabulary (Infosphere Business Glossary & Infosphere
Business Glossary Client for Eclipse)
Supportive
Glossaries
Business
Terms
Analytical
Requirements
Business
Data Model
Atomic
Warehouse
Model
Dimensional
Warehouse
Model
The Industry Models Data Warehouse
components

Are used as a reference

Are customized
by both business and IT communities to
accelerate the analysis and design
phases of a data warehouse solution
Data Models (Infosphere Data Architect)
70
© 2011 IBM Corporation
Information Management
IIW ist Teil einer ganzheitlichen Versicherungs-Facharchitektur
Versicherungs Facharchitektur IAA
(IAA: Insurance Application Architecture)
IIW hier exemplarisch
© 2011 IBM Corporation
SAS Enterprise BI
• Akademie
• Banken
• Dienstleistungen
• Energieversorger
• Handel
• Healthcare
• Industrie
• Medien
• Öffentliche
• Pharma
• Telekommunikation
• Versicherungen
Quellee: SAS
Hier exemplarisch:
l
h
72
Teradata Unified LDM Framework
•
LDM – Logical Data Model
•
•
•
Shareable LDM modules are useable
across iLDMs:
•
•
•
•
Contains atomic elements of
information
Describes how to assemble useful
molecules of information
Some modules are used in all iLDMs.
Some are used in selected iLDMs
based on relevance.
Industry LDMs continue to have
industry-specific focus for explicit
business needs.
Available modeling for clients in an
industry is increased through access
to more shareable modules:
•
•
•
Standard structure and conventions
make sharing easier
Cross value-chain intersections
Meet growing business needs
•
Quelle: Teradata
New industries/sub-industries
• Financial Services (Banking, Insurance, Brokerage)
• Communications (Telco, Cable, Satellite)
g, Fast Food,, Gasoline))
• Retail ((Merchandise,, Catalog,
• Manufacturing (CPG, Process, Food)
• Health Care (HMO, Hospital, Health Insurance, PBM)
• Travel & Hospitality (Airline, Reservation Service, Casino)
• Media & Entertainment (Movies, Electronic Games)
• Transportation & Logistics (Shipping, 3GL, 4GL Support)
• Utilities (Electric, Gas, Water)
• Life
Lif Sciences
S i
(Ph
(Pharmaceutical,
ti l Research)
R
h)
• State Medicaid (Federal Reimbursement)
EDWr –
The EDW Roadmap was constructed to
show the linkage between the Business
User perspective and the Information
Technology
gy p
perspective
p
of the business.
This provides a visual representation of the
“big picture” of the business plans. It
validates that we are attacking the right
business p
problem ((s).
)
Business
Perspec
ctive
Enterprise Data Warehouse Roadmap
Direction &
Measurement
Opportunities
& ROI
Linkage
Insights &
Knowledge
Information
nology
Techn
Persp
pective
Integrated
Information
74 > March 2008
Data
Residence
Fazit der BARC Studie: Nutzen von RDMs
Effizienz
Nachhaltigkeit
G
Governance
Agilität
28.05.2013
• Bl
Blueprint
i t als
l Projektbescheuniger
P j ktb
h
i
• „Buy“ effizienter als „make“
• Dient der Strukturierung (Kartographie)
• Wiederverwendbarkeit von Projektergebnissen
• Basis für „single point of truth“
• Trägt zur verbesserten Unternehmenssteuerung bei
• Etablierung eines Unternehmensglossars
• Treiber für Data Governance, gleichzeitig kritischer Erfolgsfaktor
• Verkürzte Projektlaufzeiten
• Integrierte Unternehmensinformationen als Wettbewerbsvorteil
• Unterschiedliche Branchen und Einsatzszenarien, gleicher Nutzen
© BARC 2013
75
Fazit der BARC Studie: Grenzen von RDMs
•
•
•
•
Aufgabe
g
Komplex
p
p
per se – unabhängig
g g vom RDM
Keine 100%-Abdeckung (weder Tiefe noch Breite)
Kein Leitfaden für die individuelle Anwendung
Eigene Begrifflichkeit des RDMs
•
•
•
•
Modell ist keine Software, kein Werkzeug
Dient der Strukturierung (Kartographie)
Keine Unterstützung bei der Projektion auf die eigenen Quellsysteme
Keine Unterstützung bei der Projektion auf Kennzahlen und Umsetzung
der BI Strategie
K
Know-how
h
&E
Erfahrung
f h
•
•
•
•
Aufgabe erfordert fachlich wie technisch spezielle Fähigkeiten
RDM ist kein Ersatz für Erfahrung
Kontakt zu anderen Anwendern suchen
Vielschichtige, teils kontroverse Sichtweisen im Unternehmen zu lösen
Normierung und
Prozessintegration
•
•
•
•
Unterstützt Governance, löst sie aber nicht
Ohne Governance kein RDM Erfolg
RDM/Governance Werkzeuge lückenhaft
Kritisch: Managementunterstützung
Komplexität
K
l ität &
Abdeckungsgrad
Landkarte ohne
Reiseplanung
28.05.2013
© BARC 2013
76
RDMs - Zusammenfassung
g
Einsatz RDM für DWH bringt Nutzen
• Beschleuniger und Risikominimierer
Klare, realistische Erwartungen formulieren
• RDMs sind jeweils für unterschiedliche Einsatzbereiche optimiert
• Landkarte ohne Reise
Erfolgsfaktoren
• Data Governance
• Menschen
M
h
Grenzen
RDM
• Unternehmensspezifsche Vollständigkeit
• Datenintegration
• Dateninterpretation
28.05.2013
© BARC 2013
77
Agenda
g
• Datenmodellierung für Data Warehouse und BI –
Problemstellung und Lösungskonzepte
• Modellierung in der BI Architektur – Von der Konzeption bis
zur Auswertung
A
t
• BI Anforderungsmanagement und Data Governance –
Schnittstelle Fachbereich / IT
• Referenzdatenmodelle für BI – Überblick, Nutzen und
Grenzen
• Ausblick – hat Datenmodellierung im Zeitalter von Big Data
ausgedient?
28.05.2013
© BARC 2013
78
Rückblick: Warum logische/physische
D t
Datenmodellierung?
d lli
?
Unternehmen
Domäne
• Daten residieren auf Hardware
• RAM, SSD, HDD - Hardware kennt keine
Semantik
• Datenverwendung benötigt Semantik
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
D t
Data
Warehouse
BI
Applikation
• Trennung von „was“ und „wie“
• Daten einfacher konsumieren
• Daten einfacher verwalten
• Unabhängigkeit Datenabfrage <>
physische Ablage
• Metadaten
• Semantische Beschreibung von Daten
• Verschiedene Schichten möglich
• Vielfach verknüpft mit Datenspeicher,
Zugriffsart, Datenmodellierungs-Methode
28.05.2013
© BARC 2013
79
Datenmodellierung
g und Verwendungszweck
g
• ERM (mit/ohne rDBMS)
einfache
i f h Pflege,
Pfl
größtmögliche
ößt ö li h Wi
Wiederverwendbarkeit
d
db k it
• Dimensional (mit/ohne rDBMS/mDBMS)
einfach Kennzahlanalyse in einem vorgegebenen Kontext
• Proprietär
z.b. Visualisierungswerkzeuge wie Tableau, QlikView, …
• „flache Strukturen“
z.B. komplexe Analyse, Data Mining, Statistik
! Klassische Datenmodellierung, häufig verknüpft mit einer
Datenablage, beschreibt Semantik
Datenablage
Semantik, gibt Struktur
Struktur, stellt
Kontext her – schränkt aber ggfs. die Verwendbarkeit der
konkreten Datenablage auf bestimmte Zwecke ein
28.05.2013
© BARC 2013
80
Orientierung
g – Big
g Data und Datenmodellierung
g
Big Data i.S. D t bl
Datenablage für fü
die Analytik
Unternehmen
Domäne
• Fachgebiete
(subject areas)
• Geschäftsmodell
(business model)
• Logisch
• Physisch
Applikation
Operational
28.05.2013
81
Data
W h
Warehouse
BI
A lik ti
Applikation
© BARC 2013
81
Das Big
g Data Prinzip
p
•
•
•
•
•
Speichern von rohen Daten
Unterstützung poly-strukturierter
Daten (Text, Bild, Logs, …)
„No ETL“-Ansatz liefert initiale
Agilität
g
„Schema-less“ - Datenablage
ohne Datenmodellierung
„Late-binding“ D t
Datenmodellierung
d lli
„on the
th fly“
fl “
28.05.2013
Spezialisierte Datenspeicher
• Filesysteme für Hadoop
• NoSQL (“not only SQL“)
© BARC 2013
82
Big
g Data – Entwicklungen
g im Zugriff
g
auf HDFS
•Java Programmierung
•Struktur, Semantik und Kontext im Code
•Ablaufoptimierung durch Entwickler
•Batch‐orientiert
•Batch
orientiert
•Eingeschränkte Security
MapReduce
28.05.2013
Vereinfachter Zugriff,
z.B. SQL •Import/Export <> rDBMS
•In‐DB MapReduce
•External Tables
•Hive
•Hadoop DBs
•Hybride Systeme
•Proprietäre Zugriffs‐APIs z.B. in NoSQL
P
i ä Z iff API B i N SQL
Lösungen
•BD nicht grundsätzlich „schema‐less“
•Semantik, Struktur, Kontext für Analyse benötigt
•„Modellierung“zum
„Modellierung zum Zeitpunkt der Analyse Zeitpunkt der Analyse
(„late‐binding“) – alt. durch Metadaten
•Erhöhte Flexibilität für explorative
Einsatzszenarien
•Wenige gute Eignung für operative Einsatzszenarien
Modellierung: nicht ob, sondern wann
© BARC 2013
83
Fazit
•
Komplexität der Datenmodellierung für BI wird geprägt durch
•
•
•
•
•
•
Komplexität der BI Datenwelt ist nicht per se Ursache sondern mehr Wirkung der genannten
Hintergründe.
g
Brücken zu schlagen erfordert weitergehende Prozesse, Methoden, Darstellungsmittel und
Werkzeuge
•
•
•
•
zwei gängige, etablierte Methoden für die logische und physische Datenmodellierung im Kern der
BI Datenarchitektur,
D t
hit kt
dem Mapping verschiedener, Applikationsspezifischer, meist technische orientierter Datenmodelle
aufeinander,
der Notwendigkeit, eine heterogene Datenarchitektur im Unternehmen betreiben zu müssen ohne
wahrhaftige Chance auf einen physisch etablierten Single Point of Truth und
dem Fehlen eines übergreifenden Geschäftsdatenmodells als Fundament für das
Applikationsübergreifende Modellmapping.
zur Unterstützung des Anforderungsmanagements und
zur Verbesserung der Kommunikation zwischen Fachbereiche und IT.
Alle Daten, auch Big Data, benötigen Kontext um sinnvoll anwendbar zu werden
• Kontext wird hergestellt durch Struktur (Metadaten, u.A. Datenmodell) und
Analysemethoden
• Kontext kann zum beliebigen Zeitpunkt, persistent oder virtuell, hergestellt werden
• Struktur ist dabei Voraussetzung für Analyse und Anwendung
• Unterschied bei Modellierung und Interpretation für klassische BI Daten und Big Data liegt
im Zeitpunkt
g und Data Governance müssen fachlich,
Herkömmliche Ansätze für Datenmodellierung
technisch und organisatorisch für Big Data erweitert werden.
84
Vielen Dank – noch Fragen?
g
Jacqueline
q
Bloemen
Senior Analyst
BARC GmbH
Steinbachtal 2b
D-97082 Würzburg
28.05.2013
Tel. +49 (0)931/880651-0
Mobil +49 (171) 7565538
H-Office +49 (0)6172/459604
[email protected]
www.barc.de
© BARC 2013
85