Datenqualität sichern Wenn sich Controlling und Buchhaltung streiten Praxisseminar zu Datenqualitätsanalysen mit der Service GmbH als Fallbeispiel

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

So... ...oder so?

So... ...oder so?

Wer glaubt schon bunten Charts?

Die Kosten der schlechten Daten

Versteckte Kosten durch schlechte Datenqualität Manuelles Nacharbeiten von Daten Beschwerden -> Aufwand in Call Center Erhöhte Projektkosten bei Einführung neuer Systeme Bis 25% gestoppt, bis zu 60% Verzug aufgrund falscher oder fehlender Daten Verspätete Unternehmensberichte Verlorene Kunden durch schlechten Support Produktionsausfälle durch Störung in der Supply Chain

Datenqualität? Was ist das? Unsere Daten sind doch sauber! Bis zu 20% der operativen Daten sind betroffen. Unternehmen finanzieren schlechte Daten mit 30-50% der IT-Ausgaben. Über schlechte Daten redet man nicht, man arrangiert sich.

Ohne Daten kein Business Daten sind der Treibstoff der Prozesse Information Chain Kunde Kunden- betreuer Logistik- system Stamm- daten Marketing Buch- haltung Lager Spedition Bedarf Adresse Kredit- daten Angebot Bestand Bestell- daten KD-Daten Kredit OK Order Adresse Werbung Verkaufs- daten Rechnung Bezahlung Reklamation Mahnung Liefer- schein Im Verlauf der Geschäftsprozesse entstehen ständig Daten. Kunden bestellen beim Kundenbetreuer und teilt eine Order und Adressdaten mit. Der Kundenbetreuer fragt in der Stammdatenhaltung nach der Gültigkeit der Adressdaten und die Kreditwürdigkeit nach. Die Stammdatenverwaltung liefert einen Kundenstammdatensatz. Der Kundenbetreuer fragt in der Logistik und im Lager nach der Verfügbarkeit nach. Bestandsdaten werden geliefert. Der Kunde erhält ein Angebot. Die Order geht in den Orderprozesse an Logistik, Lager und Buchhaltung. Lieferdaten gehen an den Spediteur. Eine Rechnung geht an den Kunden ... ...und eventuell wieder zurück, weil sie falsch ist. Aus den Kundenstamm- und Bestelldaten werden Marketingdaten. Werbeangebote gehen an den Kunden. -> es entsteht eine Informationskette über alle Prozesse hinweg -> Wenn zu Beginn bei der ersten Datenerfassung bereits kleine Fehler gemacht werde, pflanzt sich dieser Fehler in der ganzen Kette fort -> es kommen weitere Fehler hinzu. -> Fehler addieren sich Am Ende sind bis zu 20 % Daten im Unternehmen infiziert. Operative Prozesse

Ohne Daten kein Business Schlechte Daten sind wie Sand im Getriebe der Geschäftsprozesse Information Chain Kunde Kunden- betreuer Logistik- system Stamm- daten Marketing Buch- haltung Lager Spedition Bedarf Adresse Kredit- daten Angebot Bestand Bestell- daten KD-Daten Kredit OK Order Adresse Werbung Verkaufs- daten Rechnung Bezahlung Reklamation Mahnung Liefer- schein Im Verlauf der Geschäftsprozesse entstehen ständig Daten. Kunden bestellen beim Kundenbetreuer und teilt eine Order und Adressdaten mit. Der Kundenbetreuer fragt in der Stammdatenhaltung nach der Gültigkeit der Adressdaten und die Kreditwürdigkeit nach. Die Stammdatenverwaltung liefert einen Kundenstammdatensatz. Der Kundenbetreuer fragt in der Logistik und im Lager nach der Verfügbarkeit nach. Bestandsdaten werden geliefert. Der Kunde erhält ein Angebot. Die Order geht in den Orderprozesse an Logistik, Lager und Buchhaltung. Lieferdaten gehen an den Spediteur. Eine Rechnung geht an den Kunden ... ...und eventuell wieder zurück, weil sie falsch ist. Aus den Kundenstamm- und Bestelldaten werden Marketingdaten. Werbeangebote gehen an den Kunden. -> es entsteht eine Informationskette über alle Prozesse hinweg -> Wenn zu Beginn bei der ersten Datenerfassung bereits kleine Fehler gemacht werde, pflanzt sich dieser Fehler in der ganzen Kette fort -> es kommen weitere Fehler hinzu. -> Fehler addieren sich Am Ende sind bis zu 20 % Daten im Unternehmen infiziert. Operative Prozesse

Der Schnittstellen-Aspekt

Wo findet das Profiling / die Fehlersuche statt? Getrennte Aufbereitung von Daten Einheitliche Wandlung der Daten Einheitliche Wandlung der Daten Unter- schiedliche Daten und Fehlerquellen CRM Pot. Fehler optimal Akzeptabel Aber nicht Potentiell falsch Nicht glaubhaft Verlässlichkeit Data Marts SCM Data Warehouse Bereitstellung Die meisten Synergieeffekte Die geringsten Kosten Die niedrigste Fehlerquote ERP

Wo findet das Profiling / die Fehlersuche statt? Getrennte Aufbereitung von Daten Einheitliche Wandlung der Daten Einheitliche Wandlung der Daten Unter- schiedliche Daten und Fehlerquellen Pot. Fehler CRM BI Tool A Data Marts SCM Data Warehouse Bereitstellung BI Tool B Die meisten Synergieeffekte Die geringsten Kosten Die niedrigste Fehlerquote ERP Konsoli- dierung Konsolidierter Datenbereich BI Tool C

Datenqualität bezogen auf den Warehousing – Prozess Unter- schiedliche Daten und Fehlerquellen Heterogene Datenmodelle / Konsistenz / Homonyme / Synonyme Kontinuität des Ladevorgangs / Vollständigkeit Widerspruchsfreiheit zwischen den Quellen CRM BI Tool A Data Marts SCM Data Warehouse Bereitstellung BI Tool B Die meisten Synergieeffekte Die geringsten Kosten Die niedrigste Fehlerquote ERP Konsoli- dierung Konsolidierter Datenbereich BI Tool C

Datenqualität bezogen auf den Warehousing – Prozess Unter- schiedliche Daten und Fehlerquellen Heterogene Datenmodelle / Konsistenz / Homonyme / Synonyme Kontinuität des Ladevorgangs / Vollständigkeit Widerspruchsfreiheit zwischen den Quellen CRM ++ + - -- Verlässlichkeit BI Tool A Data Marts SCM Data Warehouse Bereitstellung BI Tool B Die meisten Synergieeffekte Die geringsten Kosten Die niedrigste Fehlerquote ERP Konsoli- dierung Konsolidierter Datenbereich Eindeutige Datenobjekte Beschreibungen Homonyme / Synonyme Anwendungsneutral BI Tool C Metadaten

Wo sollten Korrekturen stattfinden Correction Data Warehouse Data Load Operative Anwendung Vorsysteme bzw. Fachabteilungen sind in der Pflicht!

Wo sollten Korrekturen stattfinden Operative Anwendung ? Correction Data Warehouse Operative Anwendung Data Load Operative Anwendung

Die Qualität von Data Warehouse daten wird immer wichtiger MIS Controlling Analytisches CRM Informationsbasis Oracle Data Warehouse Operatives CRM Produkt Management Call Center Internetzugriffe Diversifizierung Marketing-Material Beschwerden

Das „Datenchaos“ historisch gesehen Begriffe? 1980

Das „Datenchaos“ historisch gesehen 1990

Das „Datenchaos“ historisch gesehen und heute?

und heute.... Datenmengen verdoppeln sich jährlich Fast jeder Oracle-Kunde hantiert mit mehr als 1 TB Daten Die Zahl der Anwendungen wächst trotz Standard Software und Daten werden tatsächlich strategische Ressource Datenqualität? Datenmodellierung? Metadatenmanagement?

Warum wächst die Herausforderung der Qualität der Daten Gewachsene Bedeutung des Faktors Information für den Erfolg von Unternehmen. Fehlende Praxis in Datenmanagement Daten- qualität Immer häufigere Prozessänderungen Ausufernde Datenmengen Vermehrtes Inseltum durch Fertig- Anwendungen

Was ist Datenqualität? Aspekte (Dimensionen) der Datenqualität Korrekt Stimmig Vollständig Dokumentiert Redundanzfrei Aktuell Verfügbar (Access) Nützlich (TCO) Handhabbar Vertrauenswürdig Harmonisch Brauchbarkeit der Daten!

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Die SERVICE GmbH Fallbeispiel

Die SERVICE GmbH SERVICE GmbH Vermittlung von Dienstleistungen für Endkunden rund um das Handwerk Handwerksleistung Darlehen Großhandel für Baumärkte und Einzelhandel Haushaltswaren Heimwerker Gartenbedarf KFZ-Zubehoer Elektroartikel Bereich Internet-/Versandhandel Computerteile SERVICE GmbH

Die SERVICE GmbH SERVICE GmbH Unterscheidung Privatkunden Firmenkunden Kundenkarte Entstand aus Zusammenschluss mehrerer Vertriebsgesellschaften Integration der Stammdaten „mit Hindernissen“ SERVICE GmbH

Erwartungen aus dem Unternehmen Buchhaltung: Es fehlen Daten Warum sind die Spediteursrechnungen so hoch? Sind alle Bestellungen korrekt bezahlt worden? Wie hoch sind die Versandkosten pro Lieferung? Was wurde storniert? Controlling: Vergleichbarkeit fehlt Was kosten Produkte im Einkauf? Wie teuer wurden Produkte verkauft? Wie rentabel sind einzelne Produkte? Marketing: Absatzzahlen sind nicht aussagefähig Wie viel Kunden gibt es? Lohnt die Kundekarte? Welche Segmentierung gibt es? SERVICE GmbH Vertrieb: wünscht leichtere Auswertungen Was sind wichtige Produkte? Was sind rentable Sparten? Hat sich der Servicebereich gelohnt? Management: Kennzahlen fehlen Wie hoch sind die liquiden Mittel? Wie hoch sind die Außenstände? Vertrieb Marketing Buchhaltung Management Controlling

Bekannte Probleme: Bestimmte Lieferungen erreichen nie den Adressaten Adressen falsch Die Lieferung wird auch nicht bezahlt Oft Privatkunden Von bestimmten Artikeln werden sehr viele Stückzahlen verkauft In den Statistiken laufen diese Produkte jedoch unter Verlustbringern (Verpackungsmengen stimmen nicht mit denen bei den Lieferanten bezahlten Mengen überein) Was geschieht mit den Retouren? Lieferantenname in Produkte_Stamm passt nicht auf die Lieferantennummer in der Lieferantentabelle Es gibt auch keine passenden Felder

Strategische Fragestellungen Welches sind die wirklich profitablen Produkte/Services? Wo wird am meisten Kapital gebunden? Welche Produkte beschaffen am meisten Kapital? Welche Produkte verursachen den höchsten Aufwand? Wie sind die Trends? Auf welche Bereiche soll man sich künftig stärker fokussieren Einzelhandel? Servicevermittlung? Großkundengeschäft? Kann die verkaufte Menge genau festgestellt werden? Welcher Vertriebsmitarbeiter macht welchen Umsatz? Wie hoch ist die Kapitalrückflussquote Ausstände? Kreditlimits? Liquide Mittel für Neuinvestitionen? Das Analysemodell zeigt oft andere (strategische) Fragestellungen auf, die zunächst nicht auf der operativen Ebene offensichtlich sind.

Die Controlling-Sicht

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-/Verfahrenstechniken Fallbeispiel Service GmbH

„Induktives und deduktives“ Vorgehen Wir wissen, vermuten Dinge die nicht stimmen Wir können sinnvolle Analysen aufgrund bekannter Dinge ableiten Wir lassen uns überraschen, was da noch kommt Wir stöbern in den Daten und entdecken Auffälligkeiten beginnen zu kombinieren stellen Hypothesen auf versuchen Zusammenhänge zu beweisen Vermutungen verifizieren Neues entdecken

Vorgehensweisen / Methoden im Data Profiling . . . Metadaten Data Quality Assessement Erwartungen an die Datenqualität Abgleich Neue Erkenntnisse (Überraschungen) Assertion Testing Metadata Verification Discovery Bottom up Data Profiling Unternehmensdaten

Methoden und Hilfsmittel Datenmodellierung Datenqualitätsprüfmethoden Data Profiling Data Profiling Tool Attribut-Klassifizierung (Namen) Kategorisierung von Qualitätsregeln ETL-Tool Datenbank

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Vorgehensmodell Datenqualitätsanalyse Zieldefinition Erwartungen Geschäftsregeln Bestandsaufnahme Owner User Ressourcen Kosten Modelle Planen Priorisieren Problemkomplexe Strukturanalysen Top Down Bottom Up Felder Objekte Beziehungen Hierarchien Regelanalysen Daten Werte Fach Umsetzung Ergebnisse Abgleich-Alt Neudefinition Monitoring 6 Phasen, 95 Aktivitäten, 16 Ergebnis-Templates, 1 Metamodell, Klassifizierungen

Vorgehensmodell für Datenqualitätsprojekte Geschäftsfelder Data Owner / Daten-Interessenten / Konsumenten DQ-Erwartungen Bekannte Schwachstellen Kosten Prioritäten Erheben der Grunddaten (Ist-Daten, Wahrnehmungen, Ziele) Objektmodell Datenflüsse und – Schnittstellen Bekannte Geschäftsregeln Beschreibung der Geschäftsprozesse (Ist-Daten, Wahrnehmungen, Ziele) Vollständigkeitsbetrachtung Betrachtung der Verständlichkeit Schlüsselanalysen / Beziehungsanalysen Analyse von Hierarchien Suche nach Redundanzen (z. B. Normalisierung) Mengenanalyse / Stammdatenabgleiche Daten-/Modell-Prüfungen Detailanalyse Überprüfen der Geschäftsregeln Analyse der erkannten Schwachstellen Verifizieren der DQ Erwartungen

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

von (Qualitäts-) Regeln im Unternehmen Einordnung von (Qualitäts-) Regeln im Unternehmen Process controles Business Area uses Object_ Model contains controles contains Business _Object Business_ Rule contains Attribut contains is_referenced _by is_referenced_by Logical Area is_realized_as Data Element Entity has controles is_realized_as Organization Area specify controles has Relevance IT_Rule has controles controles controles uses / is used_by controles contains contains Physical_ Model_Area Physical Area Org_Unit Table Column owns / is owned_by reads relates writes contains owns Program Routine File Record reads is_checked_with writes uses / is used_by

Kategorisierung von Qualitätsregeln Kategorie Column Data Rule Type Datumsfolgen Relationship Zeitdauer Data Rule Feldabhängig Value Rule Workflows Abgeleiteter Wert Komplexität Einfach Zeilen- übergreifend Komplex Ausschließende Werte Erwartungen Kardinatität= X Häufigkeit=X Max / Min ....... ...............

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Datenmodellierung Schlüssel Functional Dependencies Beziehungen Ziel: Aufspüren und Minimierung von Redundanzen als eine der Hauptursachen von Datenfehlern Schlüssel Identifizierung von Dingen Functional Dependencies Versteckte Abhängigkeiten Beziehungen Existenzabhängigkeit Orphans Childless Normalisierung One Fact One Place

Normalisierung 1. Normalform 2. Normalform 3. Normalform Eine Entity ist in der 1. Normalform, wenn jedes seiner Attribute genau einen Wert in sich aufnimmt. Sammlungen von Werten in Attributen oder unterschiedliche Verwendungen sind nicht erlaubt. Die Werte sollten nicht weiter teilbar, sondern von granularer Natur sein. 2. Normalform Eine Entität befindet sich in der 2. Normalform, wenn alle Attribute von dem kompletten Schlüssel abhängig sind. 3. Normalform Eine Entität befindet sich in der 3. Normalform, wenn alle Attribute von dem Primary Key abhängen und nicht von Nicht-Schlüssel anderen Attributen mitbestimmt werden (funktionale Abhängigkeit).

1. Normalform

2. Normalform

3. Normalform

3. Normalform

3. Normalform Primary Key Nichtschlüssel- Attribut Nicht von einem Schlüssel Abhängige Attribute

3. Normalform

Funktionale Abhängigkeit Zusätzliche „verborgene“ Functional Dependency Tabelle PRODUKTE_STAMM Artikelnummer (PK) Artikelname Beschreibung Artikelgruppennummer Artikelgruppe Functional Dependency über Primary Key (PK)

Funktionale Abhängigkeit Tabelle ARTIKEL_GRUPPE Artikelgruppennummer Artikelgruppe Beschreibung Redundante Daten mit der Gefahr von fehlerhaften Einträgen Zusätzliche „verborgene“ Functional Dependency Tabelle PRODUKTE_STAMM Artikelnummer (PK) Artikelname Beschreibung Artikelgruppennummer Artikelgruppe Functional Dependency über Primary Key (PK)

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Wortstammanalyse hilft bei der Klassifizierung von Column-Namen Hauptwort Eigenschafts- benennung Basistyp Kunden_Wohnart_Nr Information zu einem Kunden wird beschrieben Die Art und Weise, wie ein Kunde wohnt wird beschrieben unter- schiedliche Wohnungs- arten sind durch- nummeriert Bezugsobjekt Beschreibende Information Charakter des Attributes

Basistypgruppe Feldyp und Art des Wertes Rolle in Ab-hängigkeits-be-ziehung Sind NULLs erlaubt Muss Eindeutigkeit vorliegen Identifikatoren und bezeichnende Begriffe meist numerisch LHS nein ja Beschreibungen, Erzählungen, Texte meist Text , beliebige Zeichen RHS Klassifikatoren alphanumerisch, in Bezug setzende Begriffe, oft wenige Werte eher nicht, eine Klassifizierung sollte für alle Sätze gelten Zustände eher nicht, denn Zustände sollten für alle Sätze gelten, Zeiten Date / Time Sequenzen, Aufzählungen Zählwerte) meist numerisch, oft versteckte Schlüsselkandidaten   Mengen einfache Zahlenwerte ohne weitere Angaben nein, wenn etwas gezählt wird, sollte es immer gezählt warden Operatoren und abgeleitete Größen Werte (brauchen i. d. R. eine relativierende Bezugsgröße z. B. Preis -> Währung) Maße, Bezugsgrößen, Einheiten

Feldliste Über alle Tabellen hinweg select substr(table_name,1,18) Tab, substr(column_name,1,28) Col, substr(data_type,1,8) Typ, substr(data_length,1,3) Len, '| ' Nul, '| ' Basis, '| ' Bus, '| ' Syn_zu, '| ' Hom_zu, '| ' Dom, '| ' Max, '| ' Min From dba_tab_columns where table_name in ('PRODUKTE_STAMM', 'BESTELLUNG', 'LIEFERUNG', 'STORNIERUNG', 'BEST_POSITION', 'Zahlung', 'PRODUKTE_STAMM', 'ARTIKEL_GRUPPE', 'ARTIKELSPARTE', 'KUNDEN_STAMM', 'LIEFERANT', 'LAGER') and owner = 'SG' order by col Über alle Tabellen hinweg Alphabetisch sortiert nach Spaltennamen Hilft beim Erkennen von Homonymen und Synonymen Hilft bei der Bewertung der Tauglichkeit von Spaltennamen Erlaubt Vorahnungen von Schlüsselkandidaten

Feldliste TAB COL TYP LEN NUL BASIS BUS SYN_ZU HOM_ZU DOM MAX MIN ------------------ ---------------------------- -------- --- ------ ------ ------ ------ ------ ------ ------ ----- KUNDEN_STAMM ANREDE VARCHAR2 10 | | | | | | | | LIEFERANT ANSCHRIFT VARCHAR2 40 | | | | | | | | KUNDEN_STAMM ANZ_KINDER NUMBER 22 | | | | | | | | PRODUKTE_STAMM ANZ_STEUCK_PRO_VERPACKUNG NUMBER 22 | | | | | | | | PRODUKTE_STAMM ARTIKELGRUPPE VARCHAR2 50 | | | | | | | | ARTIKEL_GRUPPE ARTIKELGRUPPENNAME VARCHAR2 50 | | | | | | | | PRODUKTE_STAMM ARTIKELGRUPPENNR NUMBER 22 | | | | | | | | ARTIKEL_GRUPPE ARTIKELGRUPPENNR NUMBER 22 | | | | | | | | PRODUKTE_STAMM ARTIKELNAME VARCHAR2 30 | | | | | | | | PRODUKTE_STAMM ARTIKELNR NUMBER 22 | | | | | | | | BEST_POSITION ARTIKELNUMMER VARCHAR2 400 | | | | | | | | ARTIKELSPARTE ARTIKELSPARTENNAME VARCHAR2 18 | | | | | | | | ARTIKEL_GRUPPE ARTIKELSPARTENNR NUMBER 22 | | | | | | | | ARTIKELSPARTE ARTIKELSPARTENNR NUMBER 22 | | | | | | | | KUNDEN_STAMM BERUFSGRUPPE VARCHAR2 30 | | | | | | | | KUNDEN_STAMM BERUFSGRUPPEN_NR VARCHAR2 1 | | | | | | | | PRODUKTE_STAMM BESCHREIBUNG VARCHAR2 400 | | | | | | | | PRODUKTE_STAMM BESTAND NUMBER 22 | | | | | | | | BESTELLUNG BESTELLDATUM DATE 7 | | | | | | | | STORNIERUNG BESTELLDATUM DATE 7 | | | | | | | | LIEFERUNG BESTELLDATUM DATE 7 | | | | | | | | BEST_POSITION BESTELLDATUM DATE 7 | | | | | | | | BEST_POSITION BESTELLMENGE NUMBER 22 | | | | | | | | BESTELLUNG BESTELLNR NUMBER 22 | | | | | | | | BEST_POSITION BESTELLNR NUMBER 22 | | | | | | | | STORNIERUNG BESTELLNR NUMBER 22 | | | | | | | | LIEFERUNG BESTELLNR NUMBER 22 | | | | | | | | LIEFERUNG BESTELL_TOTAL NUMBER 22 | | | | | | | | BESTELLUNG BESTELL_TOTAL NUMBER 22 | | | | | | | | STORNIERUNG BESTELL_TOTAL NUMBER 22 | | | | | | | | LIEFERANT BEVORZUGUNG_KLASSE NUMBER 22 | | | | | | | | KUNDEN_STAMM BILDUNG VARCHAR2 30 | | | | | | | | KUNDEN_STAMM BILDUNGS_NR VARCHAR2 1 | | | | | | | | KUNDEN_STAMM BRANCHE VARCHAR2 30 | | | | | | | | BEST_POSITION POSNUMMER NUMBER 22 | | | | | | | |

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Metadaten-Dokumentation – Data Quality Plan Datenmodellierung – Die Grundlage Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Data Profiling Tool Standardanalysen Rules (Business-/ IT-Rules) Unique Keys Functional Dependencies Relationships Domains Redundant Columns Patterns, Types Statistiken Six Sigma Rules (Business-/ IT-Rules) Generierung von Korrekturen Auditing Eingebettet in ein ETL-Tool hohe Flexibilität beim Bereitstellen von Daten Direktes Anwenden erkannter Regeln für eine spätere Datenaufbereitung und Minitoring Ablaufumgebung ist die Datenbank Datennähe

Data Profiling Tool Methoden Die operativen Daten Feintuning zu den Analyse- methoden selbstredend Proto- kollierung laufende Analysen Drill Down zu den operativen Daten

ETL - Tool SQL-basiert Ablaufumgebung ist die Datenbank wenig Lernaufwand Ablaufumgebung ist die Datenbank hohe Performance Wiederverwendung von DB-Funktionen und Infrastruktur Metadaten- / Modell-gesteuert

Profiling mit OWB Lizenz-Situation Arbeiten mit dem Tool Alternativen

Warum ist ein Tooleinsatz bei Datenqualitätsanalysen sinnvoll? Das meiste geht auch ohne Tool, allerdings mühsam Functional Dependencies

Starten eines Profiling-Laufs Generierung- Rule Starten einer Correction- Mapping-Generierung Die Tabellen, die zu dem Analyse- fukus gehören Auswahl und Ergebnisansicht Methoden Tabellen-Darstellung Chart-Darstellung Feintuning zu den Analyse- methoden Drill-Werte Operative Datensätze Analyse- Job- Protokolle Aktivierbare Business Rules

Analyseumgebung SAP R/3 Source Stage Profiling Stage Siebel CRM Oracle LDAP DBMS_LDAP Meta Daten Repository Gateway / ODBC / FTP non Oracle DB2, SQL Server Informix, Teradata Oracle 9i / 10g / 11g SAP Integrator SAP R/3 Source Stage Profiling Stage Siebel CRM Analyse Datenbank Direct Path DBLink Transportable Modules Oracle eBusiness Text / XML

Eindeutigkeitsanalysen (Unique Key)

Wertebereichsanalysen (Domain)

Funktionale Abhängigkeiten

Beziehungen (Relational)

Wertmustererkennung (Pattern)

Formate (Data Type)

Statistiken (Aggregation)

Individuelle Regeln (Data Rules) Korrekt: Zusammen 100% (Alle Fälle erfasst) Korrekt, muß 0 sein Korrekt: Es kann nur ein Wert gepflegt sein. Korrekt, muß 0 sein Korrekt, muß 0 sein Korrekt, das sind die richtigen Werte Korrekt, das sind richtige Werte Problem: kein Schlüsselfeld ist gepflegt Korrekt, muß 0 sein Korrekt: Zusammen 100%. (Alle Fälle erfasst) Korrekt, muß 0 sein Problem Korrekt

Rule-Varianten

Native PL/SQL Profiling Routinen Können von jedem genutzt werden Können verändert und weiterentwickelt werden Laufen in der Datenbank Decken die wichtigsten Profiling-Funktionen ab Aggregationen (Max/Min, Nulls, Selektivität, Numerisch, alphanumerisch, prozentual Anteile Domain-Analyse Liste der Domains, Anzahl Domain-Werte, prozentuale Anteile Pattern-Analyse Liste der Pattern, Anzahl Pattern-Werte, prozentuale Anteile Functional Dependency LHS-Key,RHS-Attribute, Anzahl DP-Treffer, prozentuale Anteile, Anzahl Fehlerfälle, Orphan-Anzahl, Orphan-Prozent Data Type Analyse Numerisch, alphanumerisch, date, null, Anzahl Werte, prozentuale Werte Unique-Key-Analyse Anzahl Treffer, Anzahl Sätze, prozentualer Anteil

Native PL/SQL Profiling Routinen DATA Viewer SQL Developer sys.dba_tab_columns DQ_Kunde_FD DQ_Kunde_AGGR DQ_Kunde_TYPE DQ_Kunde_PATTERN DQ_Kunde_DOMAIN DQ_Kunde_UNIQUE DQ_CALL_UNIQUE DQ_CALL_DOMAIN DQ_CALL_PATTERN Kunde DQ_CALL_TYPE DQ_CALL_AGGR DQ_CALL_FD Datenschema SYS Schema

Hilfsscripte Alpha_Num_Check.txt Domain_Analyse.txt DQ_Datatype.txt DQ_Datatype_Proc.txt DQ_Domain.txt DQ_Domain_Proc.txt DQ_Feldliste_T300.txt DQ_Statistik.txt FD.txt Feldabhaengigkeit_FD.txt Feldabhaengigkeit_logisch.txt Feldabhaengigkeit_logisch_Wertemengen.txt Feldabhaengigkeit_logisch_Wertereihenfolge.txt Feldstatistik.txt isdate_2.txt isnumber.txt Kardinalitaet.txt Maske.txt Muster_Pattern.txt Orphans_Childless.txt Pattern.txt Redundant.txt Regular_Expression_Syntac.txt strcnt.txt Tabellenuebergreifende_Feldabgaengigkeit.txt Unique_test.txt WITH_Clause_Numeric-Check.txt

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Datenmodellierung – Die Grundlage Metadaten-Dokumentation – Data Quality Plan Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Die wichtigsten Analyse-Techniken Fragebögen / Templates Vollständigkeitsanalyse Schnittstellenanalyse Wo und wie liegen Daten vor? Synonymen / Homonymenanalyse Prüfungen von Datenstrukturen Felder, Tabellen, Beziehungen Originaldaten oder Kopien? Müssen alle Daten analysiert werden? Verfahren Techniken

Prüfungen von Datenstrukturen Attribut – bezogen Not Null / Pflichtfelder Füllgrade Formatangaben Typen, Längen Pattern Check Constraint Wertbereiche (Domains) Ober-/Untergrenzen / Wertelisten Average Satz – bezogen (Tupel) Abhängigkeiten von Werten in anderen Attributen desselben Satzes Satzübergreifend (Relationen) Primary Key / Eindeutigkeit Aggregat – Bedingungen Ober- Untergrenzen von Summen Anzahl Sätze pro Intervall usw. Rekursive Zusammenhänge Verweise auf andere Sätze derselben Tabelle (Relation) Tabellenübergreifende (Interrelational) Foreign Key Aggregat – Bedingungen Ober- Untergrenzen von Summen Anzahl Sätze pro Intervall usw. Rekursive Zusammenhänge Verweise auf Sätze einer anderen Tabelle (Relation) Zeit – bezogen (Tupel) Zeitinvariante Inhalte Umgang mit Ereignisse Zeitabhängige Veränderungen Über die Zeit mit anderen Daten korrelierende Feldinhalte Verteilungs – bezogen Arithmetische Mittel Varianz / Standardabweichungen Qualitätsmerkmale und Mengen

Prüfungen in der Datenbank Viele Prüfungen in der Datenbank An OLTP-Anfordertungen orientiert Oft nicht Massendaten-tauglich Prüfen großer Datenmengen mit mengenbasierter Logik CASE Zwischentabellen WITH Sub-Select

Prüfkonzepte in der Datenbank Prüfungen Statistiken Programmier- aufwendig Kann performance-kritisch sein Erlaubt auch fachliche Prüfungen z. B. mit Table Functions Stage-Tabelle Geprüfte Daten Kopieren Date Number Varchar2() Varchar2()

Prüfkonzepte in der Datenbank Einfach implementierbar Bessere Performance Nur bei aktivierten Constraints Fachliche Prüfungen kaum möglich Eventuell zusätzliche Prüfungen nötig Stage-Tabelle + Geprüfte Daten Statistik Routine Statistiken Date Number Varchar2() Kopieren Check Constraints Bad File Fehlerhafte Sätze DML Error Log

Error Logging Constraints Unique Key / Primary Key Foreign Key Kunde KUNDENNR VORNAME NACHNAME ORTNR STRASSE TELEFON Constraints Unique Key / Primary Key Foreign Key Not Null Check Constraint Insert into Kunde Values (......) Kunde_err KUNDENNR VORNAME NACHNAME ORTNR STRASSE TELEFON ORA_ERR_NUMBER$ ORA_ERR_MESG$ ORA_ERR_ROWID$ ORA_ERR_OPTYP$ ORA_ERR_TAG$

Error Logging: Beispiel 1

Error Logging: Beispiel 2 1 2 SQL> desc T3 Name Type --------------------------------- -------- -------- F1 NUMBER F2 NUMBER exec DBMS_ERRLOG.CREATE_ERROR_LOG ('T3') 3 SQL> desc ERR$_T3; Name Type ----------------------------------------- ------------- ORA_ERR_NUMBER$ NUMBER ORA_ERR_MESG$ VARCHAR2(2000) ORA_ERR_ROWID$ ROWID ORA_ERR_OPTYP$ VARCHAR2(2) ORA_ERR_TAG$ VARCHAR2(2000) F1 VARCHAR2(4000) F2 VARCHAR2(4000) 4 insert into t3 values(1,2) LOG ERRORS INTO err$_T3 1* select substr(ora_err_number$,1,10) Nr,substr(ora_err_mesg$,1,50) Err from ERR$_T3 SQL> / NR ERR ---------- -------------------------------------------------- 1 ORA-00001: unique constraint (DWH4.IDX_T3) violate 5

Einschränkungen + Ausnahmen Direct Path Insert mit Unique-Constraints Update (Merge) mit Unique-Constraints Error Logging verlangsamt den Ladeprozess

Arbeiten ohne Constraints Constraints stören bei Massenaktionen im DWH Ausschalten der Constraints Übernahme der Aufgaben von Constraints durch ETL-Prozess Mengen-basierte Vorgehensweise

Feldprüfungen: Was kann geprüft werden Formatprüfungen Feldtypen Stringformate, Ausdrücke Not Null Eindeutigkeit Wertebereiche Spaltenübergreifende Table_Checks Inhaltliche Regeln

Wichtiges Hilfsmittel: CASE-Anweisung Beispiel 1 select case 1 when 1 then 1 when 2 then 2 else 0 end ergebnis from dual; select case when isnumeric(999) = 1 then 'Numerisch‘‚ else 'nicht numerisch‘‚ end Ergebnis from dual; Beispiel 2 with tab as ( select '123' col1 from dual union all select 'x23d' col1 from dual ) select case when regexp_like(col1,'^[[:digit:]]') then ‘numerisch' else ‘Nicht numerisch' end from tab

Abarbeitungslogik mit CASE Beispiel mit temporärer Tabelle Gepruefte_Daten Stage-Tabelle Temp-Tabelle Insert ALL when Feld_1_is_null =1 into Error_Daten when Feld_1_is_null=0 into Gepruefte_Daten Date Number Varchar2() Varchar2() Varchar2() Insert into temp_table Select case .... From Stage_Table Feld1 Feld2 Feld3 Feld1 Feld2 Feld3 Feld1_is_null Feld1_is_numeric Feld2_is_numeric Kopieren Error_Daten Date Number Varchar2() Temporäre Tabelle ist optional Ist aber damit wesentlich übersichtlicher Erlaubt Kombination von unterschiedlichen Prüfkriterien

Abarbeitungslogik mit CASE Aufbau einer Flag-Tabelle zur besseren Dokumentation TGT_Table Key Feld1 Feld2 Feld3 Feld4 ... SRC_Table Insert into TGT_TABLE ..... Select ..,..,..,.. When SRC_TABLE.key = Prueftable.key and Prueftable.key = 0 Key Feld1 Feld2 Feld3 Feld4 ... Prueftabelle Key Flag Insert into TGT_TABLE ..... When SRC_TABLE.key = Prueftable.key and Prueftable.key != 0 Insert into Prueftabelle Select Key, case when (Feld1 is NULL) then 1 when (Feld2 != 100) then 2 when (Feld3 < 300) then 3 when (Feld4 = 0) then 4 Else 0 end From SRC_TABLE; Err_Table Key Feld1 Feld2 Feld3 Feld4 ... From SRC_TABLE,Prueftabelle

Beispiel mit graphischer Modellierung: Einsatz von CASE und Zwischentabelle

Beispiel mit manuellem SQL: Einsatz von CASE und Zwischentabelle INSERT INTO EL_KUNDE_TMP (KUNDENNR,VORNAME,NACHNAME, KUNDENNR_IS_NUMERIC) (SELECT NUMMER , NAME , NACHNAME , case when is_number ( NUMMER ) = ‘ Y‘ then 1 else 0 end FROM SRC1 ) ; 51002 Zeilen wurden erstellt. Abgelaufen: 00:00:01.45 INSERT ALL WHEN KUNDENNR_IS_NUMERIC = 1 THEN INTO EL_KUNDE (KUNDENNR, VORNAME,NACHNAME) VALUES (KUNDENNR, VORNAME, NACHNAME) WHEN KUNDENNR_IS_NUMERIC = 0 THEN INTO EL_KUNDE_FEHLER (KUNDENNR,VORNAME, NACHNAME,KUNDENNR_IS_NUMERIC) VALUES (KUNDENNR, VORNAME, NACHNAME, KUNDENNR_IS_NUMERIC) (SELECT KUNDENNR,VORNAME ,NACHNAME,ORTNR ,STRASSE ,TELEFON ,KUNDENNR_IS_NUMERIC FROM EL_KUNDE_TMP ); 51002 Zeilen wurden erstellt. Abgelaufen: 00:00:02.67

Abarbeitungslogik mit CASE / WITH Arbeiten mit WITH-Clause ohne Zwischentabelle create table src ( schluessel varchar2(30), Beschreibung varchar2(30), Rechenfeld varchar2(30)) create table tgt ( schluessel number, Beschreibung varchar2(30), Rechenfeld number) SCHLUESSEL BESCHREIBUNG RECHENFELD ---------- --------------- ---------- 1 Wert 8*7 2 xxxx 888 3 yyyy 01 a www 55 SCHLUESSEL BESCHREIBUNG RECHENFELD ---------- --------------- ---------- 2 xxxx 888 3 yyyy 1 Insert into tgt select * from ( with lc as ( select (case when is_number(schluessel) = 'Y' then schluessel else 'BUG' end) schluessel , Beschreibung, (case when is_number(Rechenfeld) = 'Y' then Rechenfeld else 'BUG' end) Rechenfeld from src) select schluessel , Beschreibung, Rechenfeld from lc where schluessel != 'BUG' and Rechenfeld != 'BUG‚)

Prüfungen auf numerisch Hilfsfunktion Is_Number bzw. regexp_like create or replace function is_number(in_var in varchar2) return varchar2 is v_number number; begin select to_number(in_var) into v_number from dual; return 'Y'; -- No exception, so is a number exception when others then return 'N'; -- is not a number end; select case when regexp_like(col1,'^[[:digit:]]') then ‘numerisch' else ‘Nicht numerisch' end from tab Alternative mit REGEXP_LIKE

Hilfsfunktion: Date_Check BEGIN inDate:= trim(str); if dateCheck(inDate, 'mm-dd-yyyy') = 'false' AND dateCheck(inDate, 'mm-dd-yy') = 'false' AND dateCheck(inDate, 'yyyy-mm-dd') = 'false' AND dateCheck(inDate, 'yy-mm-dd') = 'false' AND dateCheck(inDate, 'yyyy-mon-dd') = 'false‚ AND dateCheck(inDate, 'yy-mon-dd') = 'false‚ AND dateCheck(inDate, 'dd-mon-yyyy') = 'false‚ AND dateCheck(inDate, 'dd-mon-yy') = 'false‚ AND dateCheck(inDate, 'mmddyy') = 'false‚ AND dateCheck(inDate, 'mmddyyyy') = 'false‚ AND dateCheck(inDate, 'yyyymmdd') = 'false' AND dateCheck(inDate, 'yymmdd') = 'false‚ AND dateCheck(inDate, 'yymmdd') = 'false' AND dateCheck(inDate, 'yymondd') = 'false‚ AND dateCheck(inDate, 'yyyymondd') = 'false‚ AND dateCheck(inDate, 'mm/dd/yyyy') = 'false' AND dateCheck(inDate, 'yyyy/mm/dd') = 'false‚ AND dateCheck(inDate, 'mm/dd/yy') = 'false' AND dateCheck(inDate, 'yy/mm/dd') = 'false‚ AND dateCheck(inDate, 'mm.dd.yyyy') = 'false' AND dateCheck(inDate, 'mm.dd.yy') = 'false' AND dateCheck(inDate, 'yyyy.mm.dd') = 'false' AND dateCheck(inDate, 'yy.mm.dd') = 'false' then return 'false'; else return 'true'; end if; --exception --when others then return 'false'; END; Hilfsfunktion: Date_Check create or replace function IsDate (str varchar2) return varchar2 is inDate varchar2(40); FUNCTION dateCheck (inputDate varchar2, inputMask varchar2) RETURN varchar2 IS dateVar date; BEGIN dateVar:= to_date(inputDate,inputMask); return 'true'; exception when others then return 'false'; END; In Verbindung mit der Case-Anweisung

Prüfungen auf Feldtypen Variante mit TRANSLATE select schluessel, CASE WHEN LENGTH(TRIM(TRANSLATE(schluessel, ' +-.0123456789',' '))) is null and schluessel is not null THEN 'numerisch' WHEN LENGTH(TRIM(TRANSLATE(schluessel, ' +-.0123456789',' '))) is not null THEN 'alphanumerisch‚ WHEN schluessel is NULL then 'NULL' ELSE 'NULL‚ END Typ from src SCHLUESSEL BESCHREIBUNG RECHENFELD ------------- --------------- -------------- 1 Wert 8*7 2 xxxx 888 3 yyyy 01 a www 55 www 55 SCHLUESSEL TYP ------------- -------------- 1 numerisch 2 numerisch 3 numerisch a alphanumerisch NULL

Satzübergreifende Prüfungen pro Feld Eindeutigkeit

Satzübergreifende Prüfungen Eindeutigkeit Finden von Schluessel-Kandidaten Erfüllung der 2. und 3. Normalform Prüfung ergibt nicht für alle Feldtypen einen Sinn i. d. R. LHS-Kandidaten (siehe Feldlisten-Analyse) Herausfinden von potentiellen ETL-Job-Abbruchgründen Beim Schreiben in Tabellen mit Unique-Constraints Beim Aufbau von Parent-Child-Beziehungen in denen eindeutige Parents gebraucht werden

Eindeutigkeit Anzeigen aller Feldwerte mit ihrer jeweiligen Häufigkeit SQL> select * from unique_test; SCHLUESSEL FELD ---------- ---------- 1 abc 2 abc 32 abc 42 abc select SCHLUESSEL, count(SCHLUESSEL) cnt from unique_test group by SCHLUESSEL SCHLUESSEL CNT ---------- ---------- 1 2 42 1 2 1 32 1 Anzeigen des prozeduralen Grades der Eindeutigkeit select round(nr_values*100/anz,2) Prozent, nr_values,anz from (select count(*) nr_values from (select SCHLUESSEL, count(SCHLUESSEL) cnt from unique_test group by SCHLUESSEL)) , (select count(*) anz from unique_test); PROZENT NR_VALUES ANZ ---------- ---------- ---------- 80 4 5 Anzeigen der Werte, die die Eindeutigkeit verletzen select schluessel, n from (select count(schluessel) n, schluessel from unique_test group by SCHLUESSEL ) where n > 1 SCHLUESSEL N ---------- ---------- 1 2

Prüfung auf Eindeutigkeit: Beispiel graphisch und manuell insert into el_kunde (kundennr,vorname,nachname,ORTNR,strasse,TELEFON) select src2.nummer,src2.name,src2.name,src2.nummer,src2.name,src2.nummer from SRC2, (select nummer from (select count(nummer) n, nummer from src2 group by nummer) where n = 1) doppelte where src2.nummer = doppelte.nummer;

Feldstatistik NULL, MAX/MIN, Prozent, Count, Numeric, Alpanumeric… with lc as ( select SCHLUESSEL , (CASE WHEN SCHLUESSEL is null THEN 1 ELSE 0 END) Ist_Null, (CASE WHEN LENGTH(TRIM(TRANSLATE(SCHLUESSEL , ' +-.0123456789',' '))) is null and SCHLUESSEL is not null THEN 1 ELSE 0 END) Ist_Numeric from unique_test ) Select MAX(SCHLUESSEL ) Max_Wert, MIN(SCHLUESSEL ) Min_Wert, count(distinct(SCHLUESSEL )) Anz_Werte, round(count(distinct SCHLUESSEL )*100 / count(*),2) Selectivitaet, sum(ist_null) ist_null, sum(ist_null)*100/count(*) ist_null_prozent, sum(Ist_Numeric) ist_numeric, sum(Ist_Numeric)*100/count(*) ist_numeric_prozent, count(*)-(sum(ist_null)+sum(Ist_Numeric)) ist_Alphanumeric, (count(*)-(sum(ist_null)+sum(Ist_Numeric)))*100/count(*) ist_Alphanumeric_Prozent from lc; MAX_WERT MIN_WERT ANZ_WERTE SELECTIVITAET IST_NULL IST_NULL_PROZENT -------- -------- --------- ------------- --------- ---------------- 42 1 4 80 0 0 IST_NUMERIC IST_NUMERIC_PROZENT IST_ALPHANUMERIC IST_ALPHANUMERIC_PROZENT ----------- ------------------- ---------------- --------------------- 5 100 0 0

Herausfiltern und Protokollieren Not Null Feldern mit graphischen Mitteln case when F2 is NULL then 1 else 0 end

Prüfen auf Eindeutigkeit der Eingabesätze (Graphik) Es dürfen nur Sätze geladen werden, die einmal im Quell-bestand vorkommen. Select F1 from (Select count(F1) n,F1 from s group by F1) where n > 1;

Mustererkennung (Translate) create table Kunde ( KUNDENNR NUMBER(10), KUNDENNAME VARCHAR2(20), BERUFSGRUPPE VARCHAR2(20), SEGMENT NUMBER(10)); SQL> select * from kunde where rownum < 10; KUNDENNR KUNDENNAME BERUFSGRUPPE SEGMENT -------- ----------- -------------- ------- 705 Meister Angestellte 4 706 Schmidt Rentner 34 707 Meister Angestellte 16 708 Kraemer Beamte 38 709 Schneider Freiberufler 16 710 Schuster Selbstaendige 47 711 Mueller Unbeschaeftigt 2 712 Schneider Angestellte 36 713 Hartmann Rentner 46 digit A upper letter a lower letter B blank {n} n-time repetition column Anzahl format 9999999 column Maske format a30 select sum(nr_value) Anzahl, maske from (with lc as ( select berufsgruppe,count(NVL(berufsgruppe,'NULL')) nr_value from KUNDE group by berufsgruppe) select berufsgruppe, nr_value,strcnt(TRANSLATE(berufsgruppe, ' 0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz', 'b9999999999AAAAAAAAAAAAAAAAAAAAAAAAAAaaaaaaaaaaaaaaaaaaaaaaaaaa')) Maske from lc order by NR_Value DESC) group by maske ANZAHL MASKE ------ -------- 4 Aa{11} 14 Aa{13} 2 Aa{11}b 4 Aa{10} 5 Aa{5} 13 Aa{6} 7 Aa{12}

Mustererkennung (REGEXP_LIKE) create table Kunde ( KUNDENNR NUMBER(10), KUNDENNAME VARCHAR2(20), BERUFSGRUPPE VARCHAR2(20), SEGMENT NUMBER(10)); SQL> select * from kunde where rownum < 10; KUNDENNR KUNDENNAME BERUFSGRUPPE SEGMENT -------- ----------- -------------- ------- 705 Meister Angestellte 4 706 Schmidt Rentner 34 707 Meister Angestellte 16 708 Kraemer Beamte 38 709 Schneider Freiberufler 16 710 Schuster Selbstaendige 47 711 Mueller Unbeschaeftigt 2 712 Schneider Angestellte 36 713 Hartmann Rentner 46 Finde alle Sätze, deren Segment-Wert nur 1-stellig numerisch ist SQL> select * from kunde where REGEXP_LIKE(segment,'^[[:digit:]]{1}$'); KUNDENNR KUNDENNAME BERUFSGRUPPE SEGMENT ---------- -------------------- -------------------- ---------- 705 Meister Angestellte 4 711 Mueller Unbeschaeftigt 2 724 Schuster Student 2 726 Kraemer Rentner 5 728 Mueller Unbeschaeftigt 9 743 Bauer Freiberufler 3

Parameter * Match 0 or more times ? Match 0 or 1 time {m} Match exactly m times {m,} Match at least m times {m, n} Match at least m times but no more than n times \n Cause the previous expression to be repeated n times [:alnum:] Alphanumeric characters [:alpha:] Alphabetic characters [:blank:] Blank Space Characters [:cntrl:] Control characters (nonprinting) [:digit:] Numeric digits [:graph:] Any [:punct:], [:upper:], [:lower:], and [:digit:] chars [:lower:] Lowercase alphabetic characters [:print:] Printable characters [:punct:] Punctuation characters [:space:] Space characters (nonprinting), such as carriage return, newline, vertical tab, and form feed [:upper:] Uppercase alphabetic characters [:xdigit:] Hexidecimal characters  http://www.stanford.edu/dept/itss/docs/oracle/10g/server.101/b10759/ap_posix001.htm

Mustererkennung (REGEXP_LIKE) create table P (PNR number, pruef_wert varchar2(20)); SQL> select * from p; PNR PRUEF_WERT ---------- ------------- 1 8 2 89 3 A89 4 D-25436 5 Eumel 7 A89 6 D-1000 8 D-10003 select count(pattern) Anzahl, pattern Muster from (select PNR, case when REGEXP_LIKE(pruef_wert,'^[[:digit:]]{1}$') then 'einstellig numerisch' when REGEXP_LIKE(pruef_wert,'^[[:digit:]]{2}$') then 'zweistellig numerisch' when REGEXP_LIKE(pruef_wert,'^[[:upper:]]{1}[[:digit:]]{2}$') then '1 Großbuchstabe + 2 Zahlen' when REGEXP_LIKE(pruef_wert,'^[[:upper:]]{1}-[[:digit:]]{5}$') then 'PLZ' else 'falscher Wert' end pattern from P) group by pattern; ANZAHL MUSTER ------- -------------------------- 1 zweistellig numerisch 2 1 Großbuchstabe + 2 Zahlen 2 falscher Wert 1 einstellig numerisch 2 PLZ

Check Constraint mit Regular Expressions CREATE TABLE Check_KUNDE ( KUNDENNR NUMBER, GESCHLECHT NUMBER, VORNAME VARCHAR2(50), NACHNAME VARCHAR2(50), ANREDE VARCHAR2(10), GEBDAT DATE, ORTNR NUMBER, STRASSE VARCHAR2(50), TELEFON VARCHAR2(30) ); Regel: Im Kundennamen müssen Buchstaben vorkommen und keine reine Zahlenkolonne Alter table check_kunde add constraint Ch_KD_Name check(REGEXP_LIKE(NACHNAME, '[^[:digit:]]')); insert into check_kunde (kundennr,Geschlecht, Vorname, Nachname, Anrede,Gebdat,Ortnr,Strasse,Telefon) Values (9,1,'Klaus','123','Herr','01.01.60',2,'Haupstr.',08923456); FEHLER in Zeile 1: ORA-02290: CHECK-Constraint (DWH.CH_KD_NAME) verletzt

Domain-Analysen create table Kunde ( KUNDENNR NUMBER(10), KUNDENNAME VARCHAR2(20), BERUFSGRUPPE VARCHAR2(20), SEGMENT NUMBER(10)); SQL> select * from kunde where rownum < 10; KUNDENNR KUNDENNAME BERUFSGRUPPE SEGMENT -------- ----------- -------------- ------- 705 Meister Angestellte 4 706 Schmidt Rentner 34 707 Meister Angestellte 16 708 Kraemer Beamte 38 709 Schneider Freiberufler 16 710 Schuster Selbstaendige 47 711 Mueller Unbeschaeftigt 2 712 Schneider Angestellte 36 713 Hartmann Rentner 46 variable Anz_Records number; begin select count(*) into :Anz_Records from Kunde; end; / select * from ( select BERUFSGRUPPE Value_name, count(BERUFSGRUPPE) Anzahl_Werte, case when count(BERUFSGRUPPE) = 0 then 0 else round((count(BERUFSGRUPPE)*100)/:Anz_records,2) end Prozent from KUNDE group by BERUFSGRUPPE order by Anzahl_Werte desc) where rownum < 10; VALUE_NAME ANZAHL_WERTE PROZENT --------------- ------------ ------- Unbeschaeftigt 14 28.57 Rentner 8 16.33 Selbstaendige 7 14.29 Student 5 10.2 Beamte 5 10.2 Angestellte 4 8.16 Freiberufler 4 8.16 Freiberufler 2 4.08

Spaltenübergreifende Prüfungen Wertabhängigkeiten Synchrone Wertzuordnung Ableitung 1:1 Formeln Kardinalität Functional Dependencies

Wertabhängigkeiten (asynchron) create table t (F1 varchar2(5), F2 varchar2(5), F3 varchar2(5)); LHS (F1) RHS(F2) a b c d ab am bx ck al dt gh (1:3) (1:2) select count(distinct f1) LHS_Anzahl, f2 RHS_Wert from t group by f2; LHS_ANZAHL RHS_WERT ---------- --------- 1 dt 2 ab 1 bx 1 gh 1 am 1 ck 1 al SQL> select * from t; F1 F2 F3 ----- ----- ----- a ab b a am b b bx x c ck k a al b d dt t d ab t gh with lc as (select count(distinct f1) LHS_Anzahl,f2 from t group by f2) (select LHS_Anzahl,count(LHS_Anzahl) Vorkommen from LC group by LHS_Anzahl) LHS_ANZAHL VORKOMMEN ---------- ---------- 1 6 2 1 Bei 6 RHS-Werten gibt es nur exakt 1 LHS-Wert Bei 1 RHS-Wert gibt es zwei LHS-Werte

Wertabhängigkeiten (synchron) create table t (F1 varchar2(5), F2 varchar2(5), F3 varchar2(5)); LHS (F1) RHS(F3) a b c d x k t (1:1) (1:1) select count(distinct f1) LHS_Anzahl, f3 RHS_Wert from t group by f3; LHS_ANZAHL RHS_WERT ---------- -------- 1 k 1 b 1 t 1 x 1 SQL> select * from t; F1 F2 F3 ----- ----- ----- a ab b a am b b bx x c ck k a al b d dt t d ab t gh with lc as (select count(distinct f1) LHS_Anzahl,f3 from t group by f3) (select LHS_Anzahl,count(LHS_Anzahl) Vorkommen from LC group by LHS_Anzahl) LHS_ANZAHL VORKOMMEN ---------- ---------- 1 5 Bei 5 RHS-Werten gibt es nur exakt 1 LHS-Wert

Wertabhängigkeiten Inhaltliche Abhängigkeit von zwei Feldern Variante 1: Wertereihenfolgen Variante 2: Wertemengen Identifier Zustands- beschreibung Zeitabhängige Information AKTION STATUS AKTIONSDATUM ------ ---------- ------------ 1 10 01-AUG-10 1 20 01-MAY-10 1 20 01-SEP-10 1 30 01-OCT-10 2 10 01-SEP-10 2 20 02-SEP-10 3 10 05-SEP-10 4 10 05-SEP-10 4 20 06-SEP-10 Beispielregel zu Variante 1: Die aufsteigenden Statuswerte 10, 20, 30 pro Aktion müssen in zeitlicher Reihenfolge stattfinden . Beispielregel zu Variante 2: Für jede Aktion müssen immer 3 Statusmeldungen und die dazu passenden Aktionsdatumsangaben folgen.

Wertabhängigkeiten Inhaltliche Abhängigkeit von zwei Feldern Lösung zu Beispielregel 1: Bei korrekten Angaben zu den Aktionen muss eine Sortierung nach Aktion, Status, Aktionsdatum genauso aussehen wie eine Sortierung nach Aktion, Aktionsdatum, Status. Es werden zwei entsprechende Datenmengen mit einer zusätzlichen laufenden Nummer erzeugt. Bei einem Join der beiden Datenmengen und einem Join-Kriterium bestehend aus der Nummer und den Feldern müssten sich alle Sätze „paaren“ lassen, bzw. zu Fehlern führen, wenn die Werte auf ungleich abgefragt werden. (Lösung in Script, hier nur graphisch) Join-Bedingung

Wertabhängigkeiten Inhaltliche Abhängigkeit von zwei Felder, Prüfung auf Wertmengen AKTION STATUS AKTIONSDATUM ------ ---------- ------------ 1 10 01-AUG-10 1 20 01-MAY-10 1 20 01-SEP-10 1 30 01-OCT-10 2 10 01-SEP-10 2 20 02-SEP-10 3 10 05-SEP-10 4 10 05-SEP-10 4 20 06-SEP-10 with lc as (select aktion, count(status) Anz_Status, count(aktionsdatum) Anz_Datum from Statusmeldung group by aktion order by aktion) select aktion, Anz_Status,Anz_Datum from lc where Anz_Status < 3 or Anz_Datum < 3; AKTION ANZ_STATUS ANZ_DATUM ------- ---------- ---------- 2 2 2 3 1 1 4 2 2 Beispielregel zu Variante 2: Für jede Aktion müssen immer 3 Statusmeldungen und die dazu passenden Aktionsdatumsangaben folgen.

Tabellenübergreifende Prüfungen Referenzen Kardinalität Orphans Childless Redundant Columns

Tabellenübergreifende Prüfungen – Kardinalität select artikelgruppennr L_Key,' --> ', count(artikelgruppennr) cnt1 from artikel_gruppe group by artikelgruppennr order by artikelgruppennr; L_KEY '-->' CNT1 ---------- ----- ---------- 1 --> 1 2 --> 1 3 --> 1 4 --> 1 5 --> 1 6 --> 1 7 --> 1 8 --> 1 9 --> 1 10 --> 1 11 --> 1 select artikelgruppennr R_Key,' --> ', count(artikelgruppennr) cnt2 from produkte_stamm group by artikelgruppennr order by artikelgruppennr; R_KEY '-->' CNT2 ---------- ----- ---------- 1 --> 11 2 --> 4 3 --> 14 4 --> 9 5 --> 3 6 --> 3 7 --> 3 10 --> 1 100 --> 6 --> 0 Prüfung innerhalb einer Tabelle Prüfung über 2 Tabellen hinweg select min(l.cnt1), max(l.cnt1), min(R.cnt2), max(R.cnt2) from (select artikelgruppennr L_Key,count(artikelgruppennr) cnt1 from artikel_gruppe group by artikelgruppennr) L, (select artikelgruppennr R_Key,count(artikelgruppennr) cnt2 from produkte_stamm group by artikelgruppennr) R where L.L_Key=R.R_Key; MIN(L.CNT1) MAX(L.CNT1) MIN(R.CNT2) MAX(R.CNT2) ----------- ----------- ----------- ----------- 1 1 1 14 1:n - Beziehung

Tabellenübergreifende Prüfungen – Orphans Artikel_Gruppe Produkte_Stamm SQL> select distinct artikelgruppennr from Artikel_gruppe order by artikelgruppennr; ARTIKELGRUPPENNR ---------------- 1 2 3 4 5 6 7 8 9 10 11 SQL> select distinct artikelgruppennr from produkte_stamm order by artikelgruppennr; ARTIKELGRUPPENNR ---------------- 1 2 3 4 5 6 7 10 100 SQL> select count(artikelgruppennr) Anz_Orphans, artikelgruppennr Wert_Orphans from produkte_stamm 2 where artikelgruppennr not in (select artikelgruppennr from Artikel_gruppe) 3 group by artikelgruppennr ; ANZ_ORPHANS WERT_ORPHANS ----------- ------------ 6 100

Tabellenübergreifende Prüfungen – Childless Artikel_Gruppe Produkte_Stamm SQL> select distinct artikelgruppennr from Artikel_gruppe order by artikelgruppennr; ARTIKELGRUPPENNR ---------------- 1 2 3 4 5 6 7 8 9 10 11 SQL> select distinct artikelgruppennr from produkte_stamm order by artikelgruppennr; ARTIKELGRUPPENNR ---------------- 1 2 3 4 5 6 7 10 100 select distinct artikelgruppennr from Artikel_gruppe MINUS select distinct g.artikelgruppennr from Artikel_gruppe g, produkte_stamm p where g.artikelgruppennr = p.artikelgruppennr; ARTIKELGRUPPENNR ---------------- 8 9 11

Redundant Columns Redundanzen: eine der Hauptfehlerursachen Redundanzen innerhalb einer Tabelle Feststellbar mit Select Count(*) from Tabelle where Feld_X = Feld_Y; Redundanzen in unterschiedlichen Tabellen Parent/Child-Beziehungen Child-redundante Information ist meist aus Parent ableitbar Feststellbar mit select Count(*) from Select Count(*) from T1,T2 where T1.PK = T2.PK MINUS Select Count(*) from T1,T2 where T1.PK = T2.PK and T1.Feld_Y = T2.Feld;

Redundant Columns Parent- Child create table parent (Parent_Key number, Wert_X varchar2(10)); insert into parent values(1,'AUDI'); insert into parent values(2,'VW'); insert into parent values(3,'OPEL'); insert into parent values(4,'BMW'); insert into parent values(5,'Daimler'); create table child (Child_key number, Parent_Key number, Wert_Y varchar2(10)); insert into child values(1,1,'AUDI'); insert into child values(2,1,'AUDI'); insert into child values(1,2,'VW'); insert into child values(2,2,'VW'); insert into child values(1,3,'OPEL'); insert into child values(2,3,'OPEL'); insert into child values(1,'4','BMW'); insert into child values(2,'4','BMW'); insert into child values(3,'4','BMW'); insert into child values(4,'4','BMW'); insert into child values(1,5,'Daimler'); insert into child values(2,5,'Daler'); SQL> select Count(*) from 2 ((Select Count(*) from parent,child 3 where parent.Parent_Key = child.Parent_Key) MINUS 4 (Select Count(*) from parent,child 5 where parent.Parent_Key = child.Parent_Key and 6 parent.Wert_X = child.Wert_Y)) ; COUNT(*) ---------- 1

Tabellenübergreifende Prüfungen – Werte Bestellung Bestellnr (PK) Bestell_Total = Best_position Bestellnr (FK) Gesamt_Pos_Preis select count(*) from (select bestellnr,BESTELL_TOTAL from bestellung) B, (select BESTELLNR, sum(GESAMT_POS_PREIS) ges_Pos_Wert from best_position group by BESTELLNR) P where B.bestellnr = P.BESTELLNR and B.BESTELL_TOTAL != P.ges_Pos_Wert ;

Zugreifbarkeit auf Daten Quell-Umgebung Oracle Oracle 10g / 11g non Oracle Gateway / ODBC / FTP / Golden Gate DB2, SQL Server Informix, Teradata Stage Schema Analyse Schema Sampling SAP Integrator SAP R/3 Analyse Datenbank Siebel CRM Direct Path DBLink Text / XML

Arbeiten mit Datenkopien Entlastung der operativen System Sicherstellen von nicht veränderlichen Daten Verhindern von Seiteneffekten Z. B. von Spacheinstellungen etc. Erleichtert länger dauerndes iteratives Arbeiten Überwinden von technischen Barrieren Z. B. bei SAP-Daten Veränderbarkeit von Daten zu Simulationszwecken Bessere Performance

Sampling von Daten SAMPLE – Schlüsselwort select Kundenname from kunde sample (2); In Klammern Prozentwert select /*+ dynamic_sampling(Kunde 4) */Kundenname from kunde Macht nicht immer Sinn Z. B. nicht bei Eindeutigkeitsprüfungen Aber bei Stichproben auf der Suche nach NULL-Werten Immer nur bedingt, vollständige Sicherheit bringt nur eine Komplettsuche

Wo macht Sampling Sinn? Macht Sinn? Verfahren Patternanalyse Domainanalyse Not Null Messung Typfeststellung Max/Min/Aussreisser Eindeutigkeitsanalyse Functional Dependency Orphan / Childless Redundant Column Kardinalität Bedingt Nein

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Datenmodellierung – Die Grundlage Metadaten-Dokumentation – Data Quality Plan Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Fragebögen und Templates Geben Struktur vor Dokumentieren Verhindern, dass man etwas vergisst Arbeitsgrundlage im Projekt Werden ständig aktualisiert und in allen Phasen verwendet

Sinnvolle Listen und Templates für die Projektarbeit T1.10 Liste Geschäftsfelder (zur Fokussierung) T1.15 Datenbestandsliste (für die Vollständigkeitsanalyse) T1.20 Liste Metadatenbestände T1.35 Liste bekannten Schwachstellen und Erwartungen T1.45 Bekannte Business Rules T1.50 Geschätzte Kosten der bekannten Schwachstellen T2.25 Liste Datenbestände, Geschäftsobjekte und Fehldaten T2.50 Regelliste (Bekannte + abgeleitete Regeln) T3.00 Feldliste T3.25 Liste Missverständliche Objektnamen T3.50 Schlüsselliste T3.55 Funktionale Abhängigkeiten T3.60 Beziehungen T3.70 Normalform-Analysen T3.75 Redundante Felder Die wichtigsten Listen

Vollständigkeitsanalyse Analysemodell Erstellen von Analysemodell ergibt aus der Befragung der Prozess-Kenner Objektmodell ergibt sich aus dem Analysemodell Rückschlüsse auf fehlende Informationen Über Vergleiche des Objektmodells mit der Datenbestandsliste Objektmodell

Schnittstellenanalyse Erstellen von Prozessmodell (Analyse-Modell) Objektmodell Datenbestandsliste Finden von Übergabepunkten als die kritischen Stellen Prozessmodell

Synonymen / Homonymenanalyse Homonyme (leichter Fall) Über Feldliste Kandidaten finden Kandidaten mit Aggregation-, Domain-, Pattern-Analyse auf fachliche Gleichheit überprüfen Synonyme (komplexer Fall) Wortstammanalyse Attributklassifizierung Finden von Kandidaten über Basistypen

Finden von Anomalien 1. NF 2. NF 3. NF Domainanalyse und Sichtprüfung Suche nach Schlüsselkandidaten Feldliste Unique-Key-Prüfung Fokussierung auf zusammengesetzte Schlüssel Functional Dependency Analyse 3. NF Fokussierung auf nicht als Schlüssel genutzte Felder

Finden redundanter Spalten Über Feldliste Kandidaten identifizieren, um den späteren Aufwand zu minimieren Felder finden, die nicht geprüft werden müssen Pools von ähnlichen Feldern bilden Stichproben mit Sampling bzw. Domain-Analysen Innerhalb einer Tabelle Feststellen des Schlüsselfeldes Feldinhaltsvergleiche (alle Spalten müssen mit allen anderen Spalten verglichen werden) Eventuell prozentuale Gleichheit feststellen Bei hohem Übereinstimmungsgrad, die „Nicht-Treffer“ mit Domain- bzw. Patternanalyse genauer betrachten. Tabellenübergreifend Finden des Referenzkriteriums (PK / FK) Überprüfen auf Vollständigkeit der Referenz Feldinhaltsvergleiche mit Hilfe eines Joins (wie oben beschrieben)

Agenda Teurer Datensumpf" oder "Schlechte Daten kosten einfach nur viel Geld" Einweisung in das Planspiel „Service GmbH“ „Wenn Controlling auf die Buchhaltung schimpft“ Eine simulierte Firma mit (einigen) Problemen. Hilfsmittel für die systematische Vorgehensweisen bei Datenqualitätsanalysen Vorgehensmodell – Der rote Faden Datenmodellierung – Die Grundlage Metadaten-Dokumentation – Data Quality Plan Feldliste – Das klassische Hilfe Sonst.: Profiling Tool / ETL Tool / Datenbank Die wichtigsten Analyse-Techniken Die wichtigsten Analyse-Verfahren Fallbeispiel Service GmbH

Zusammenfassen zu Problemkomplexen Problemkomplex 1: Dies sind Schwierigkeiten bei Auswertungen. Diese sind zwar machbar, aber es fehlen offenbar einzelne Produkte und Produktgruppen. Die Daten müssen umständlich zusammengesucht werden. Ob das Ergebnis stimmt ist unklar. Produktgruppen und einzelne Produkte sind nicht richtig messbar. Von den Produktsparten sind offensichtlich keine Auswertungen möglich. Zu untersuchen sind die Produkte-Stamdatenhierarchien. Problemkomplex 2: Die Zusammenhänge zwischen unterschiedlichen Größen (Einkaufsdaten und Verkaufsdaten) sind nicht stimmig. Welche Waren werden zu welchem Preis beschafft und zu welchem Preis und mit welchem Rabatt verkauft. Problemkomplex 3: Verschiedene Kundengruppen können nicht voneinander abgegrenzt werden. Auch das Thema Kundenkarte gehört dazu. Problemkomplex 4: Spediteursrechnungen und Lieferungen. Wo gehen die Waren hin und wie werden sie bezahlt? Gelingt die Kontrolle über Lieferungen und Zahlungen?

Problem- komplex Fragestellungen Benannte Probleme Ergebnis Artikel-, Gruppen-, Spartenberichte Stammdaten (Produkte / Artikel) Auswertbarkeit Messbarkeit für Controlling Stimmen die Einträge Stammdaten Hierarchien? Vergleichbarkeit von Einkaufs- und Verkaufspreisen Welche Produkte lohnen sich Korrekte Zahlen zur Steuerung von Marketingkampagnen und für den Vertrieb Einkaufspreise (fehlerhaft?) Rabatte? Wer hat wieviel gekauft? Stammdaten (Kunden / Identifizierung ) Kunden-Segmentierung Nachvollziehbarkeit von Zahlungen für die Buchhaltung Wo bleibt die gelieferte Ware? Spediteure? Lieferungen (Bestellungen /Stornierungen) Wie korrekt wird gezahlt?

Analysemodell: Was wissen wir über den Prozess? Handwerker Produkte Privat Dienst- leistungen Kunden Firmen bietet an beauftragt bietet an Kunden- karte Lieferanten verkauft bestellt Service GmbH liefert aus storniert Spediteur holt ab beauftragt holt stornierte Ware ab liefert ab beliefert Lager

Geschäftsprozess: Bestellungen Bestellprozess Status Beschaffung Kundendaten prüfen offene Posten Kreditlimit prüfen MAX/MIN Menge Spediteur beauftragen Verfüg- barkeit prüfen Kunden- stamm Liefer-schein Bestellsatz updaten Bestellung anlegen Liefersatz anlegen Kunden- stamm Produkte-stamm Dienstleist- ung be-auftragen Bestellung Bestellung Best_Pos Best_Pos Lieferung Vertrag

Objektmodell: Welche Geschäftsobjekte sind an dem Prozess beteiligt? Bewegungs daten Stornierung Lieferung Spediteur Stamm- daten Zahlung Bestellung Retouren Lager Partner Produkte Kunde Kunden- Karte Beauf- tragung / Order Lieferanten Dienst- leister Artikel Service Firmen- Kunde Privat- Kunde

Vollständigkeitsanalyse Wichtige Daten fehlen! Liefernummer fehlt. Identifizierung nur über Bestellnummer Identifizierung nur über Bestellnummer Keine Untergliederung nach Positionen möglich. Bewegungs daten Stornierung Lieferung Spediteur Stamm- daten Zahlung Bestellung Retouren Lager Partner Produkte Kunde Kunden- Karte Beauf- tragung / Order Lieferung: Liefernummer fehlt: Identifizierung nur über Bestellnummer Problem bei Teillieferungen Stornierung: Identifizierung nur über Bestellnummer Keine ntergliederung nach Positionen möglich. Retouren sind nicht dokumentiert. Was muss der Kunde wirklich zahlen? Beauftragung / Order fehlt. Lieferantendaten können nicht gespeichert werden. Lager: fehlt, es kann nicht dokumentiert werden, was z. B. über Stornierungen wieder zurückgekommen ist. Lieferanten Dienst- leister Artikel Service Firmen- Kunde Privat- Kunde

Zusammenfassung: Vollständigkeitsanalyse Fehlen wichtiger Daten für Buchhaltung und Controlling Stornierungen können nicht korrekt erfasst werden, damit ist der Rückfluss von Waren nicht messbar -> sie verschwinden im Lager -> Tabelle Stornierungen neu strukturieren Wg. Fehlender Liefernummer können Teillieferungen nicht genau gemessen werden -> Liefernummer einführen Unterscheidung zwischen Dienstleister und Waren-Lieferant wäre sinnvoll. Damit wären Einkaufbedingungen leichter messbar -> Feld Lieferantentyp einführen Es fehlt die Möglichkeit die eingekauften Services bzw. Lieferungen genau zu messen -> Tabelle Beauftragung / Order einführen u. a. m.

Verständlichkeit des Datenmodells

Synonym Synonym Synonyme oder nicht? Missver- ständliche Begriffe Homonym Homonym Synonym

Betrachtung von Form und Inhalt einzelner Felder Nummern, bzw. Key-Felder sind alphanumerisch anstatt numerisch wie es der Feldname vermuten lässt: KUNDEN_STAMM ->Firmenrabatt der Grund sind wahrscheinlich einzelnen %-Zeichen -> mit dem Feld kann man nicht mehr rechnen, bzw. muss es zunächst aufbereiten PRODUKTE_STAMM -> Stueckpreis (varchar2) KUNDEN_STAMM -> Bildungsnr (varchar2) Felder enthalten z. T. nicht lesbare Zeichen BEST_POSITION -> Ausfuerhrung (@@@@) Viele Felder sind nicht gefüllt KUNDEN_STAMM -> Firmenrabatt / Kontaktperson / Kundenart

Wertähnlichkeitsprüfungen Begriffe, die dasselbe meinen, sollten standardisiert werden Standardisierungs-Glossar einführen Lookup-Tabelle mit Mapping-Begriffen einführen

Standardisierte Werte Durchgängige Nomenklatur  Patternanalyse Das Bemühen sprechende Werte zu nutzen, ist erkennbar, aber bei der Umsetzung war man nicht konsequent Falsche Werte grundsätzlich ablehnen Standardisierungsregeln festlegen

Wechselseitige Fehler in den Daten Ein bestimmer Fehler taucht in einem anderen Attribut in abgewandelter Form wieder auf Wahrscheinlich maschinelle Ursache Domainanalyse Direkter Vergleich mit SQL SQL> select BERUFSGRUPPEN_NR,BERUFSGRUPPE from kunden_stamm group by BERUFSGRUPPEN_NR,BERUFSGRUPPE order by BERUFSGRUPPEN_NR; B BERUFSGRUPPE - ------------------------------ 1 Arbeiter 2 Angest_Oeff_ 3 Schueler 4 Studenten 5 Arbeitslose 6 Renter 7 Selbststaendige 8 NA A ngestellter B eamter 1 3 KUNDEN_STAMM

Inhaltlich falsche Werte Domainanalyse Augenscheinlich falsche Werte Gleichmäßige Werteverteilung bei Feld für Anzahl Kinder Irritierender Umgang mit NULL bzw. fehelenden Werten KUNDEN_STAMM

Unique Key Analyse PRODUKTE_STAMM : Artikelnr / Produktnummer Beide Felder werden für unterschiedliche Arten verwendet  ein einheitlicher Schlüssel muesste entwickelt werden KUNDEN_STAMM: Kunden_ID / Kundennr Es wird nur Kunden_ID verwendet -> Kundennr muesste gelöscht werden

Funktionale Abhängigkeiten Funktionale Abhängigkeiten sollten nach Möglichkeit in einer 3 NF aufgelöst sein Hier gibt es diese Struktur aber schon und dennoch ist das Feld Artikelgruppe in der Tabelle PRDUKTE_STAMM aufgenommen -> dieses Feld muesste entfernt werden Allerdings offenbar es auch gleichzeitig einen Fehler. „Artikelgruppe“ ist offenbar nicht ganz funktional abhängig -> hier muss eine weitere Analyse folgen Ähnliches gilt für die Tabelle BEST_POSITION

Beziehungsanalyse Artikel_ Lieferung Sparte Stornierung Artikel_ Bestellnr [6, (97%)] Bestrellnr Bestellnr [6, (97%)] Order_ID Artikelspartennnr [1, (90%)] Stornierung Bestrellnr [0, (100%)] Bestrellnr Bestellung Artikel_ Gruppe Lager Order_ID [0, (100%)] Order_ID Zahlung Bestrellnr [0, (100%)] Order_ID Artikelgruppennr [6, (92%)] Produktnummer [0, (100%)] Bestrellnr [213, (90%)] Produkte_ stamm Kundencode [0, (100%)] Kunden_ID Best_ Position Artikelnr [0, (100%)] Lieferant KD_Nummer [1211, (46%)] Kundennr KD_Nummer [0, (100%)] Kunden_ID FK-Column [Orphans, (%-korrekte Sätze) ] UK-Column Legende Kundencode [0, (100%)] Kunden_ID Kunden_ stamm Kundencode [0, (100%)] Kunden_ID

Kreisbeziehungen Die Information Kundennummer kommt in mehreren Tabellen vor Gefahr falscher Dateneintragungen Zudem mutiert der Feldname (Synonyme) Kunden_ID Kundencode KD_Nummer Meist Ergebnis bei dem Zusammenführen von Anwendungen, die unterschiedliche Spalten- namen verwendet haben.

Beziehungsanalysen graphisch

Orphans und Childless Die Artikelstruktur ist fehlerhaft select count(artikelgruppennr) Anz_Orphans, artikelgruppennr Wert_Orphans from produkte_stamm where artikelgruppennr not in (select artikelgruppennr from Artikel_gruppe) group by artikelgruppennr ; ANZ_ORPHANS WERT_ORPHANS ----------- ------------ 6 100 --- Childless --------------------------- select distinct artikelgruppennr from Artikel_gruppe MINUS select distinct g.artikelgruppennr from Artikel_gruppe g, produkte_stamm p where g.artikelgruppennr = p.artikelgruppennr; ARTIKELGRUPPENNR ---------------- 8 9 11 Die Artikelstruktur ist fehlerhaft Es gibt Artikelgruppen , die nicht unter einer Sparte hängen Es gibt Produkte, die nicht Artikel_Gruppen zugeordnet sind

Analyse von Hierarchien Artikelsparte ARTIKELSPARTENNR 1 , 2 ,3 Gerade BI-Werkzeuge haben Drill-Pfade, die auf einem sehr groben Aggragations-Level einsteigen. Bei diesem Fehler wird man Produkte mit einer Produktgruppe 100 nicht finden. Im Fall der Service GmbH sind das ausgerechnet alle Service-Leistungen. Sie sind nachträglich in das Angebot hinzu gekommen und man hat die Pflege der Stammdaten vernachlässigt Artikel_Gruppe ARTIKELSPARTENNR 1,4,3 ARTIKELGRUPPENNR 1,2,3,4,5,6,11,10,9,8,7 Produkte_Stamm ARTIKELGRUPPENNR 100,1,6,2,5,4,7,3,10

Umsätze können nicht festgestellt werden Abfrage über die Hierarchie Artikelgruppe -> Produkte_Stamm -> Best_Position Abfrage über die Hierarchie Produkte_Stamm -> Best_Position ?

Korrekte Business Intelligence Auswertungen? Korrekte Werte für: Umsatz pro Sparte? Umsatz pro Gruppe? Umsatz pro Produkt? Werden korrekte Rechnungen gestellt? Umsatz pro Kunde? Macht die Kundenkarte Sinn? Sparten Fehlerhafte Spartenkennzeichnung von Gruppen Gruppen Orphans Falsche Statuskennzeichnung von Finanzprodukten Produkte Fehlerhafte Verschlüsselung von Artikel- und Produkten Bestellung Position Doppelte Produktnummern Fehlerhafte , nicht rechenbare Einzelpreisbezeichnung Kunden- Stamm Doppelte Wertebelegung von Statuskennzeichnung für Privat- und Firmenkunden.

Wer hat Recht Controlling oder Buchhaltung? Zahlen: Controlling Zahlen: Buchhaltung

Data Quality Management Process Reporting Data Profiling Data Quality Auditing Datenkorrektur

Datenqualitätsreporting Verarbeitete Sätze pro Berichtzeitraum (Anzahl Positionen pro Bestellungen)

Füllstandsanzeige einzelner Werte

Bring up on stage two customers to tell the audience about their experiences. Manpower Associates is a $14.9B global company with 27,000 employees in the temporary staffing business. Manpower runs a combined PeopleSoft Enterprise and JD Edwards EnterpriseOne shop. These experts in human resources use Enterprise HCM for their own staffing and EnterpriseOne Payroll and Service Billing for handling the large volumes of US-based temporary staff. Manpower is very happy with Oracle’s support since purchasing PeopleSoft and is looking forward to a long relationship with Oracle. Spokesperson will be Jay Schaudies, Vice President, Global eCommerce. Welch Foods is the food processing and marketing arm of National Grape Cooperative Association. Organized in 1945, National Grape is a grower-owned agricultural cooperative with 1,461 members. The company, headquartered in Concord, Massachusetts, operates six plants located in Michigan, New York, Pennsylvania and Washington. The company was running a mix of legacy, home grown, and manual systems that failed to provide senior management with accurate and timely cost and production information. Welch’s required a centralized manufacturing and financial information system to improve management decision making. The solution had to be hot-pluggable with existing technologies, for example, Welch’s Plumtree portal. Welch Foods chose Oracle over SAP for this business-critical application. The key to the customer’s business problem was their ability to manage costs. The company’s costs are driven by fruit solid content in each of their products, and they use a specialized technique called BRIX for measuring and calculating the cost of materials. Welch’s compared SAP and Oracle SAP’s software was too rigid and, therefore, unable to include the BRIX calculation in their manufacturing solution. Only Oracle’s OPM could bind this custom cost method into the Quality Management Process. Technology customer yet to be determined. Current possibilities include eBay and FTD Florists.