KDD - Knowledge Discovery in Databases

Der Knowledge Discovery in Databases (KDD*)-Prozess – eine Übersicht

KDD beschreibt den gesamten Prozess der Wissensentdeckung aus Daten. Data Mining (DM) ist ein Teilschritt im übergreifenden KDD-Prozess – KDD ist „höher“ und stärker am Entscheidungsproblem ausgerichtet, während DM Methoden/Algorithmen die Mustererkennung liefern können. (**)

Kerngedanke: KDD ist wissensintensiv und analystenzentriert – in fast jedem Schritt braucht es menschliche Entscheidungen (z.B. Auswahl relevanter Variablen, Qualitätsregeln, Interpretation und Nutzenbewertung).

Im Folgenden möchte ich einen Einblick und Details zum Prozess und der einzelnen Teilschritte geben.

Herkunft - Wer hat den KDD-Prozess „aufgestellt“?

In der Literatur wird der KDD-Rahmen häufig mit Fayyad, Piatetsky-Shapiro & Smyth (1996) verbunden (inkl. bekannter Definition von KDD und Einordnung von DM als Teilprozess). Es wird zudem erwähnt, dass der Begriff „KDD“ bereits beim ersten KDD-Workshop 1989 (IJCAI-Umfeld) geprägt wurde.

Warum ist das BI-relevant?

KDD „spannt“ den Bogen von der Entscheidungsfrage über Datenaufbereitung bis zur Nutzung der Ergebnisse (z.B. Kampagnensteuerung, Risikobewertung, Prozessverbesserung). Ein Data Warehouse unterstützt dabei besonders die vorbereitenden Schritte (Daten sammeln/integrieren) und schafft eine stabile Basis für Analyse & Distribution.

Die Grundidee des KDD-Prozesses

Der KDD-Prozess startet typischerweise mit einem Entscheidungsproblem (z.B. „Warum sinkt die Abschlussquote?“, „Welche Kunden sind abwanderungsgefährdet?“). Danach folgen vorbereitende Schritte (Daten auswählen, bereinigen, transformieren), dann der Schritt Data Mining (Muster/Modelle finden) und anschließend nachbereitende Schritte (Interpretation, Evaluation und Nutzung/Handlung).

In vielen Darstellungen ist KDD iterativ: Erkenntnisse aus Evaluation/Business Feedback führen zurück zu Datenwahl, Feature Engineering oder sogar zur Präzisierung der Fragestellung.

Wir gehen nun nacheinander die einzelnen Schritte durch, bevor sie in der Tabelle mit expliziten Implementierungsbeispielen untermalt werden.

1. Schritt: Developing an Understanding of the Application Domain

In dieser Phase steht die intensive Kommunikation mit der Geschäftsführung im Mittelpunkt. Ziel ist es, die Problemstellung und die strategischen Ziele tiefgreifend zu durchdringen. Nur ein vorab präzise definiertes Erfolgskriterium bietet späteren Mehrwert.

Anwendungsbeispiel: Handel

Ein Unternehmen möchte die Abwanderungsquote senken. Ohne Domänenwissen über Saisonalität würde eine rein technische Analyse Muster finden, die statistisch korrekt, aber geschäftlich irrelevant sind. Erst die Definition, was genau als „Abwanderung“ gilt (z. B. Inaktivität > 6 Monate), macht die Daten nutzbar.

Ein Vergleich

Wer ein Haus baut, muss klären, ob es ein Einfamilienhaus oder ein Bürokomplex wird. Beide stellen völlig unterschiedliche Anforderungen an Statik und Aufteilung. Ohne dieses Verständnis wäre jeder Entwurf reiner Zufall.

2. Schritt: Auswahl der Daten (Target Data)

Nachdem im ersten Schritt das „Warum“ geklärt wurde, folgt nun das „Womit“. In dieser Phase bestimmen wir die exakten Quellen, die unsere Business-Fragen beantworten können. Eine präzise Problemdefinition ist wertlos, wenn wir die falschen Quellen anzapfen. Stoßen wir hierbei auf instabile Quellen wie manuelle Excel-Listen, ist dies ein klares Signal für notwendige Nebenprojekte zur Automatisierung und Konsolidierung.

Wer gehört an den Tisch?

Fachabteilungen: Definieren den inhaltlichen Wert und die Relevanz der Kennzahlen.
IT-Teams: Sichern den physischen Zugriff und die technische Integrität der Systeme (ERP, CRM).
Compliance: Stellen sicher, dass die Datenverwendung datenschutzkonform ist.

Eine exakte Definition der Quellen verhindert den gefürchteten „Garbage In, Garbage Out“-Effekt. Sie schont Rechenressourcen und schafft eine lückenlose Herkunftskette (Data Lineage), was das Vertrauen des Managements in datengetriebene Entscheidungen massiv stärkt.

Ein Vergleich

Wer ein Haus baut, muss jetzt die Verträge mit den richtigen Lieferanten abschließen. Es nützt nichts, den teuersten Marmor zu bestellen, wenn das Ziel ein funktionaler Holzbau ist. Nur wer genau weiß, welches Material an welcher Stelle benötigt wird, verhindert teure Fehlkäufe und sorgt dafür, dass die Statik am Ende hält.

3. Schritt: Datenqualität muss kein Zufall sein – Data Cleaning and Preprocessing

Nachdem wir die strategische Problemdefinition (Schritt 1) abgeschlossen und die relevanten Datenquellen (Schritt 2) identifiziert haben, folgt nun die Phase, die oft über den Erfolg der gesamten BI-Architektur entscheidet. Rohdaten aus operativen Systemen enthalten oft „Rauschen“, Lücken oder Inkonsistenzen – hier veredeln wir diesen Rohstoff zu einem belastbaren Fundament.

Drei Säulen der Datenveredelung

Fehlerfreie Analysen: Gezielter Umgang mit fehlenden Werten und Bereinigung von Ausreißern (z.B. Systemfehler bei Datumsangaben).
Einheitliche Wahrheit: Harmonisierung widersprüchlicher Datensätze. Die „Müller GmbH“ muss systemübergreifend identisch erkannt werden.
Strategische Sicherheit: Hohe Datenintegrität steigert die Akzeptanz im Management – weg vom Bauchgefühl, hin zu validierten Fakten.

Auch hier ist das Zusammenspiel entscheidend: Während die IT und Data Engineers die Pipelines zur Automatisierung bauen, liefert der Fachbereich die Leitplanken. Nur die Experten aus der Praxis wissen, ob ein extremer Ausreißer ein technischer Fehler oder ein seltener, hochrelevanter Geschäftsfall ist.

Ein Vergleich

Das Baumaterial wurde geliefert (Schritt 2), aber es ist noch verschmutzt. Bevor der Maurer beginnt, muss er den Sand sieben, damit keine groben Steine den Mörtel ruinieren, und schadhafte Ziegel aussortieren. Wer dieses „Säubern“ ernst nimmt, sorgt dafür, dass die Wände später absolut gerade stehen und keine Risse im Mauerwerk entstehen – das Haus gewinnt an Stabilität und Wert.

4. Schritt: Die Architektur des Wissens – Datenreduktion und Transformation

Nachdem die Daten akribisch bereinigt wurden, geht es nun darum, die technische Komplexität in ein logisches Modell zu übersetzen. Wir strukturieren Informationen so, dass sie zukunftssicher und blitzschnell nutzbar sind. Hierbei orientieren wir uns an Ralph Kimball, dem Urvater des Dimensional Modeling.

Vorteile des Star-Schemas nach Kimball

Maximale Performance: Trennung von Fakten (Kennzahlen) und Dimensionen (Attribute) ermöglicht Analysen in Lichtgeschwindigkeit.
Zukunftssicherheit: Das Modell ist organisch erweiterbar. Neue Anforderungen können integriert werden, ohne das Fundament einzureißen.
Intuitive Nutzung: Die Datenstruktur spiegelt die reale Geschäftswelt wider und ist für Fachabteilungen sofort verständlich.

Der Bau erfolgt im Team: BI/IT-Architekten implementieren die ETL-Strecken und das Schema, während die Fachabteilungen die entscheidenden Dimensionen definieren. So stellen wir sicher, dass das Grundgerüst auch wirklich die Last trägt, die später darauf gebaut wird.

Ein Vergleich

Die Baustoffe sind bereit – jetzt ziehen wir das Skelett des Hauses hoch. Ralph Kimball ist unser Chef-Architekt und liefert den Bauplan für ein modulares Stahlskelett. Dieses Gerüst ist so stabil, dass es das ganze Haus trägt, aber so flexibel, dass wir später problemlos ein Stockwerk hinzufügen oder einen Raum umbauen können. Das Haus wächst mit, ohne an Stabilität zu verlieren.

5. Schritt: Das Ziel im Visier – Die Auswahl der Data-Mining-Aufgabe

Nachdem durch Ralph Kimball ein stabiles Grundgerüst (Star-Schema) geschaffen wurde, verlassen wir die reine Vorbereitung. Wir biegen auf die Zielgerade zur Erkenntnis ein und fokussieren uns auf die strategische Rückkopplung: Passt die gewählte Aufgabe zur betriebswirtschaftlichen Fragestellung? So stellen wir sicher, dass die Rechenpower dort landet, wo sie den höchsten ROI generiert.

Das „Was“ vor dem „Wie“: Gängige Analyse-Prinzipien

Klassifikation: Gezielte Gruppierung (z. B. „Kündigungsgefährdet“ vs. „Loyal“).
Regression: Vorhersage von Trends und Werten (z. B. Umsatzprognosen).
Clustering: Identifikation verborgener Ähnlichkeiten ohne starre Vorgaben.
Abhängigkeitsanalyse: Aufdecken von Ereignissen, die gemeinsam auftreten.

KDD ist keine Einbahnstraße: Die Kraft der Reflexion

Der KDD-Prozess ist kein starrer Ablauf, sondern ein dynamischer, agiler Kreislauf. In Schritt 5 fragen wir oft: „Fehlt uns noch etwas?“ Diese Reflexion erlaubt es uns, gezielt Schritte zurückzugehen – sei es, um in Schritt 2 neue Quellen anzapfen oder in Schritt 4 das Star-Schema flexibel anzupassen. Iterationen sind der Weg zu präziser Business Intelligence.

Ein Vergleich

Das Skelett des Hauses steht bereits. Jetzt stehen wir im Rohbau und treffen eine Grundsatzentscheidung: Wird dieser Raum ein High-Tech-Serverraum oder eine hochmoderne Küche? Wir legen die Funktion fest. Sollten wir dabei merken, dass für die Küche noch ein Wasseranschluss aus Schritt 2 oder 3 fehlt, legen wir ihn jetzt – bevor die Fliesen verlegt werden.

6. Schritt: Das richtige Werkzeug für die Mission – Die Auswahl des Algorithmus 🛠️

Nachdem in Schritt 5 das Ziel (z. B. eine Umsatzprognose) definiert wurde, klären wir nun das strategische Wie. In Schritt 6 wählen wir das mathematische Präzisionswerkzeug – den Algorithmus. Dies ist der Moment, in dem die Weichen für die spätere Erklärbarkeit und Zuverlässigkeit der Ergebnisse gestellt werden.

Die Wahl der Waffen: Komplexität vs. Transparenz

Entscheidungsbäume (Decision Trees): Hochgradig transparent („Wenn-Dann-Logik“). Ideal, wenn regulatorische Anforderungen oder Akzeptanz im Team eine hohe Interpretierbarkeit erfordern.
Neuronale Netze (Deep Learning): Die Hochleistungsmotoren für riesige, unstrukturierte Datenmengen. Sie agieren jedoch oft als „Black Box“ – mathematisch komplex und schwer zu erklären.
Ensemble-Methoden (z. B. Random Forest): Die Kombination verschiedener Modelle zur Steigerung der Robustheit. Ziel ist ein Modell, das auch bei neuen Marktsituationen stabil funktioniert.

Warum dieser Schritt Ihr Budget schützt

Die Auswahl ist kein rein technisches Thema. Ein falsch gewählter Algorithmus birgt Risiken: Overfitting führt dazu, dass das Modell Daten auswendig lernt, statt Muster zu verstehen (perfekt in der Vergangenheit, versagt in der Zukunft). Eine mangelnde Skalierbarkeit wiederum verbrennt Rechenressourcen ohne proportionalen Geschäftsnutzen.

Ein Vergleich

Die Funktion des Raumes steht fest (Schritt 5: Serverraum). Jetzt wählen wir die spezifische Technologie aus. Nutzen wir eine klassische Klimaanlage oder eine innovative Flüssigkeitskühlung? Die Entscheidung hängt von Kosten, Wartbarkeit und Leistung ab. Wir kaufen nicht das „teuerste“ Gerät, sondern das, das perfekt in unser Stahlskelett (Schritt 4) passt.

7. Schritt: Wenn die Daten das Laufen lernen – Das eigentliche Data Mining ⚡

Nachdem in den ersten sechs Schritten das Fundament gegossen und die Wände hochgezogen wurden, lassen wir nun die Leinen los. In Schritt 7 treffen unser strukturiertes Star-Schema (Schritt 4) und die gewählten Algorithmen (Schritt 6) aufeinander. Es ist die Phase, in der es im „Maschinenraum“ rechnet, um statische Datenfriedhöfe in dynamisches Wissen zu verwandeln.

Die vier Grundaufgaben des Data Minings

Assoziationsanalyse: Suche nach logischen Abhängigkeiten (z. B. „Wer A kauft, kauft auch B“).
Clusteranalyse: Identifikation von homogenen Gruppen innerhalb einer heterogenen Datenmenge (z. B. Kundensegmentierung).
Klassifikation: Zuordnung von Daten zu fest definierten Kategorien (z. B. „Kreditwürdig: Ja/Nein“).
Approximation / Vorhersage: Mathematische Prognose von Werten (z. B. Regression) – ein Verfahren, das wir heute fast täglich unbewusst nutzen.

Auch wenn die Maschine rechnet, bleibt der Mensch der Steuermann. Wir lassen die Technik nicht isoliert agieren. Es ist ein iteratives Experimentieren: Wir müssen Parameter „tunen“, um die Qualität der Ergebnisse zu erhöhen und die wahre „Goldader“ in den Daten freizulegen.

Ein Vergleich

Die Geräte sind installiert und wir drücken den Start-Knopf: Das Haus erwacht zum Leben. Die Sensoren beginnen zu messen, das Smart-Home-System lernt die Gewohnheiten der Bewohner und die Klimaanlage stellt sich auf die ideale Temperatur ein. Das Skelett (Datenmodell) wird lebendig.

8. Schritt: Der Reality Check – Evaluation & Interpretation 🧐⚖️

Nachdem im siebten Schritt die Algorithmen gelaufen sind, stehen wir vor der alles entscheidenden Frage: Ist das wirklich Gold oder nur Katzengold? Nun verlassen wir die Welt der Mathematik und kehren zurück an den Konferenztisch zur Qualitätskontrolle, die über den Erfolg der gesamten BI-Strategie entscheidet.

Korrelation vs. Kausalität: Die Falle der Scheinzusammenhänge

Ein Algorithmus findet mathematische Muster – keine logischen Ursachen.

Das Problem: Nur weil Kurven sich parallel bewegen, bedingt die eine nicht die andere (Beispiel: Speiseeis-Verkäufe und Sonnenbrände korrelieren, Ursache ist aber die Sonne).
Die Management-Aufgabe: Wir müssen prüfen, ob Muster betriebswirtschaftlich logisch erklärbar sind, um Fehlentscheidungen durch Zufallskonstellationen zu vermeiden.

Statistische Signifikanz vs. Betriebswirtschaftliche Relevanz

Nicht alles, was mathematisch „wahr“ ist, ist für Ihr Business auch „wichtig“.

Die Herausforderung: Eine Umsatzsteigerung von 0,001% mag statistisch signifikant sein, aber der Umsetzungsaufwand steht oft in keinem Verhältnis zum Ertrag.
Das Ziel: Wir suchen nach Mustern, die „Interessant“ im Sinne von Fayyad sind – also neu, nützlich und vor allem handlungsrelevant für den ROI.

Ein Vergleich: Die Bauabnahme

Die Smart-Home-Systeme laufen (Schritt 7), nun kommt der Bauherr zur Abnahme:

„Das Licht geht an, wenn ich die Tür öffne. Ist das so gewollt oder ein Fehler in der Schaltung?“ (Kausalität)
„Das System spart mir 2 Euro Heizkosten im Jahr, hat aber 5.000 Euro gekostet. Lohnt sich das?“ (Relevanz)

Erst wenn diese Fragen positiv beantwortet sind, wird das Haus für den Einzug freigegeben.

9. Schritt: Consolidating Discovered Knowledge – Wenn Daten zu echten Taten werden

Wir haben das Fundament gegossen, die Wände hochgezogen, die Technik installiert und die Abnahme bestanden. Jetzt folgt der entscheidende Moment: Der Einzug. In der Phase der Operationalisierung verwandeln wir entdecktes Wissen in messbaren Geschäftserfolg. Für das Management ist dies der Moment, in dem sich die Investition amortisieren muss.

Operationalisierung: Integration statt Schublade

Nahtlose Integration: Erkenntnisse dürfen nicht als PDF verstauben. Sie müssen dort ankommen, wo Entscheidungen fallen – in automatisierten Prozessen oder glasklaren Dashboards für Vertrieb und Logistik.
Der Faktor Mensch: Die größte Hürde ist oft nicht die Technik, sondern das Misstrauen. Wahre BI braucht eine Vertrauenskultur, in der Daten als „Superkraft“ und Unterstützung der eigenen Expertise begriffen werden.

BI bedeutet am Ende nicht die Verwaltung von Daten, sondern die Führung von Menschen durch Klarheit. Ein Haus wird erst zum Zuhause, wenn die Bewohner die Technik beherrschen und sie ihren Alltag verbessert. So wird aus einem abgeschlossenen Projekt ein lebendiges, lernendes Unternehmen.

"To achieve goals you’ve never achieved before, you need to start doing things you’ve never done before."

— Stephen R. Covey

Business Intelligence ist das Werkzeug, aber der Mensch bleibt das Maß der Dinge. Wer den KDD-Prozess bis zum Ende durchläuft, baut keine Datenbanken – er baut eine zukunftsfähige Organisation.

Weitere KDD-Zusammenfassungen nach anderen Autoren

Im Skript werden mehrere vereinfachte oder anders gewichtete KDD-Modelle vorgestellt. Sie unterscheiden sich weniger in den Inhalten als im Fokus.

Ester & Sander

Fokus: algorithmisch-technisch.
Ester & Sander reduzieren KDD auf wenige, klar abgegrenzte Phasen (Datenvorbereitung → Data Mining → Interpretation). Der Schwerpunkt liegt auf der methodischen Durchführung, weniger auf organisationalen oder strategischen Aspekten.

Düsing

Fokus: BI- und entscheidungsorientiert.
Düsing betont besonders die Einbettung in den Entscheidungsprozess sowie die Rolle von Zieldefinition, Nutzung und Feedback. KDD wird hier stark als Bestandteil eines Management- und Steuerungskreislaufs verstanden.

Linoff & Berry

Fokus: pragmatisch-geschäftsorientiert.
Linoff & Berry betrachten KDD aus Sicht konkreter Business-Anwendungen (Marketing, CRM, Risikoanalyse). Der Prozess ist weniger formal, dafür stark auf praktischen Nutzen und schnelle Umsetzbarkeit ausgerichtet.

*)	KDD = „Knowledge Discovery in Databases“ (Wissensentdeckung in Datenbanken). Im Skript wird u.a. die bekannte Definition nach Fayyad et al. (1996) zitiert und KDD zeitlich in die 1990er Jahre eingeordnet (inkl. Hinweis auf den ersten KDD-Workshop 1989).
**)	Wichtige Abgrenzung: Im BI-Kurskontext gilt: DM ist ein Teil des KDD-Prozesses (Methoden/Algorithmen), während KDD den gesamten, nicht vollständig automatisierbaren Prozess beschreibt – inklusive menschlichem Input in jedem Schritt (Domänenwissen, Annahmen, Interpretation).