Leitfaden für budgetfreundliches Data Mining

Im Gegensatz zur traditionellen Anwendungsprogrammierung, bei der sich API-Funktionen täglich ändern, bleibt die Datenbankprogrammierung im Wesentlichen gleich. Die erste Version von Microsoft Visual Studio .NET wurde im Februar 2002 veröffentlicht, wobei etwa alle zwei Jahre eine neue Version veröffentlicht wurde, ohne Service Pack-Versionen. Dieses schnelle Tempo des Wandels zwingt IT-Personal dazu, die Anwendungen ihres Unternehmens alle paar Jahre zu evaluieren und die Funktionalität ihrer Anwendung intakt zu lassen, aber mit einem völlig anderen Quellcode, um mit den neuesten Techniken und Technologien auf dem Laufenden zu bleiben.

Dasselbe gilt nicht für Ihren Datenbank-Quellcode. Eine Standardabfrage von SELECT / FROM / WHERE / GROUP BY , die in den frühen Tagen von SQL geschrieben wurde, funktioniert auch heute noch. Das bedeutet natürlich nicht, dass es keine Fortschritte in der relationalen Datenbankprogrammierung gegeben hat; es gab, und sie waren eher logisch als technisch .

Beginnend mit den Tagen, als Bill Inmon und Ralph Kimball ihre Theorien zum Data-Warehouse-Design veröffentlichten, konzentrierten sich die Fortschritte in der Datenbankprogrammierung darauf, den Verlust wertvoller Informationen zu verhindern und alle wertvollen Informationen aus den Daten zu extrahieren. Nachdem Inmon und Kimball die Datenbankwelt in Data Warehousing eingeführt hatten, wurden große Änderungen an ETL-Tools (Extract/Transform/Load) vorgenommen, die Datenbankentwicklern einen einfachen Zugriff auf Metadaten und Daten aus nicht relationalen Datenbankquellen ermöglichten, mit denen nur schwer zu arbeiten war in der Vergangenheit. Dadurch erhöhte sich die verfügbare Datenmenge, aus der wertvolle Informationen extrahiert werden konnten, und diese Zunahme verfügbarer Daten führte zu Fortschritten bei der Datenverarbeitung durch OLAP-Würfel und Data-Mining-Algorithmen.

Das Hinzufügen eines Data Warehouse, von OLAP-Cubes und Data-Mining-Algorithmen zu Ihrer Datenbankarchitektur kann Geschäftsprozesse erheblich rationalisieren und Muster in Ihren Daten aufdecken, von denen Sie sonst nie gewusst hätten, dass sie existieren. Die Automatisierung kann auch tiefgreifende Auswirkungen auf die Business-Intelligence-Funktionen haben.

Bevor Sie jedoch neue Tools und Technologien hinzufügen, sollten Sie sicherstellen, dass die Transaktionsdatenbank ordnungsgemäß erstellt wurde.

Transaktionsdatenbank

Die Transaktionsdatenbank ist die Grundlage, und wenn Ihre Transaktionsdatenbank nicht zuverlässig und genau ist, dann ist das Hinzufügen von irgendetwas darüber ein Rezept für eine Katastrophe.

Ein wichtiger Punkt, den Sie beim Hinzufügen zusätzlicher Schichten zu Ihrer Datenbank beachten sollten, ist, dass alle Projekte einen Return on Investment aufweisen müssen, weshalb es am besten ist, das Beste aus Ihrer aktuellen Architektur herauszuholen, bevor Sie weitere Schichten hinzufügen. Alle diese Schichten verwenden Daten, die aus einer Transaktionsdatenbank stammen. In vielen Situationen können Sie die gleiche Ausgabe erhalten, indem Sie einfach Ihre Transaktionsdatenbank abfragen. Natürlich ist es die ideale Methode, alle Ihre Berichte aus einem Data Warehouse oder OLAP-Cube lesen zu lassen, aber wenn eine Organisation für dieses Maß an Komplexität nicht bereit ist, ist es wichtiger, dass ihre Berichtsanforderungen zuerst erfüllt werden. Sobald die grundlegenden Anforderungen an die Berichterstellung erfüllt sind, ist es viel einfacher, eine Diskussion darüber zu beginnen, wie ein geeignetes Data Warehouse und möglicherweise ein OLAP-Cube dem Unternehmen zugute kommen können.

Fast jeder Programmierer kennt die drei Regeln der Datenbanknormalisierung. Die gespeicherten Prozeduren, die aus der Transaktionsdatenbank lesen, sind der Weg zur Optimierung. Die Probleme, nach denen gesucht werden muss, sind Lesbarkeit, mehrfache Aufrufe derselben Datenbanktabelle und unnötige Verwendung von Variablen.

Alle Elite-Datenbankprogrammierer sind wählerisch in Bezug auf die Lesbarkeit ihrer gespeicherten Prozeduren. Es gibt einige Gemeinsamkeiten in der Art und Weise, wie Datenbankprofis ihre Abfragen formatieren, die sich von denen eines Anwendungsentwicklers unterscheidet. Typischerweise werden Schlüsselwörter und Aggregatfunktionen in Großbuchstaben geschrieben, während Tabellen- und Feldnamen entweder Camelcase oder Unterstriche verwenden. Tabellenaliase haben eine gewisse Korrelation mit dem tatsächlichen Tabellennamen. Die Ausrichtung der Abschnitte der gespeicherten Prozedur hat eine Art Blockmuster.

Nachfolgend finden Sie ein Beispiel für eine Abfrage, die ein lesbares Format verwendet.

 SELECT c.customer_id, c.name, SUM (po.purchase_amount) total_purchase_amount FROM customer c JOIN purchase_orders po ON c.customer_id = po.customer_id GROUP BY c.customer_id, c.name

Als Nächstes müssen Sie suchen, ob eine Abfrage mehr als einmal auf eine Tabelle trifft. In den meisten Abfragen muss nur einmal auf eine Tabelle zugegriffen werden, mit Ausnahme der seltenen Fälle, in denen Sie eine andere Aggregatfunktion aggregieren müssen. Dies ist ein weiterer Fehler, den einige Anwendungsprogrammierer machen, vielleicht weil ein Anwendungsprogrammierer in Begriffen von objektorientiertem Design denkt.

Objektorientiertes Design erstellt separate Objekte für jedes eindeutige Datenelement, aber ein Datenbankprogrammierer muss in Begriffen der Mengenlogik denken. Nur weil eine Abfrage öfter als nötig auf eine Tabelle zugreift, bedeutet das nicht, dass die Abfrage ungenaue Daten erzeugt, jedoch wird die Leistung der Abfrage beeinträchtigt.

Ein weiteres Problem besteht darin, dass Datensätze bei jeder Verknüpfung gelöscht oder dupliziert werden, wodurch die Genauigkeit Ihrer Abfrage beeinträchtigt wird. Die unnötige Verwendung von Variablen ist ein weiteres Zeichen dafür, dass eine Abfrage von einem Anwendungsentwickler entwickelt wurde. Anwendungsentwickler verwenden Variablen in ihrem gesamten Code, während eine Abfrage sehr selten Variablen verwenden muss, außer wenn sie als Parameter für die gespeicherte Prozedur deklariert wird. Wieder einmal ist es ein Zeichen dafür, dass der Entwickler nicht in Mengenlogik gedacht hat.

ETL (Extract Transform Load) und Berichterstattung

Sobald die Transaktionsdatenbank eines Kunden über ordnungsgemäß funktionierende Abfragen verfügt, besteht der nächste Schritt darin, Geschäftsprozesse zu rationalisieren.

Der einfachste Weg, den Bedarf eines Unternehmens an ETL-Prozessen oder automatisierter Berichterstellung zu ermitteln, besteht darin, herauszufinden, wer Daten aus einer Transaktionsdatenbank liest und die Daten dann mithilfe einer Tabellenkalkulation bearbeitet. Eine Tabellenkalkulation ist die gleiche Struktur wie eine Datenbanktabelle. Beide enthalten Zeilen und Spalten. Wenn Ihre Endbenutzer Daten selbst manipulieren, sollten Sie sich fragen: „Warum kann dieser Prozess nicht automatisiert werden?“

Die Automatisierung von Geschäftsprozessen bietet einen sofortigen Return on Investment und sollte immer in Betracht gezogen werden, bevor Sie zu teureren Projekten wie Data Warehousing übergehen. Das Identifizieren von Endbenutzern, die Daten über eine Tabellenkalkulation manipulieren, mag einfach klingen, aber es gibt einen Vorbehalt bei diesem Prozess.

Entwickler automatisieren gerne Prozesse; es ist, was sie tun. Endbenutzer mögen nicht unbedingt automatisierte Prozesse, insbesondere wenn sie ihren Arbeitsplatz gefährden. Seien Sie also nicht naiv und glauben Sie, dass Endbenutzer auf Sie zukommen und tägliche Aufgaben identifizieren werden, die automatisiert werden können. Sie müssen wirklich die Führung übernehmen, wenn es darum geht, Rationalisierungsmöglichkeiten zu identifizieren.

Ein gut aufgebautes ETL-System sollte auch die Möglichkeit bieten, alle in eine Transaktionsdatenbank geladenen Daten bis zur ursprünglichen Quelldatei zurückzuverfolgen. Dies ist ein kritischer Teil der Datenbankarchitektur. Wenn Sie nicht das genaue Datum/die genaue Uhrzeit kennen, wann jeder Datensatz hinzugefügt wurde, zusammen mit dem Namen der Quelle (Benutzername oder Dateiname), die die Datensätze hinzugefügt hat, dann sind Sie nicht darauf vorbereitet, mit fehlerhaften Daten umzugehen, die in Ihre Transaktionsdatenbank geladen wurden. Sie sollten sich fragen: „Was ist, wenn uns jemand eine fehlerhafte Datei schickt?“ Wie lange würden Sie brauchen, um die daraus entstandenen Aufzeichnungen zu identifizieren?

Datenlager

Es gibt zwei Theorien zum Data-Warehouse-Design. Der Unterschied zwischen der Inmon- und der Kimball-Theorie lässt sich wie folgt zusammenfassen:

Die Inmon-Theorie besteht darin, zuerst ein Data Warehouse zu entwickeln und dann dimensionale Data Marts für die Berichterstattung aus dem Data Warehouse zu erstellen. Die Kimball-Theorie besteht darin, zunächst dimensionale Data Marts für die Berichterstellung zu entwickeln und sie dann zusammenzuführen, um das Data Warehouse zu erstellen.

Sie möchten Ihren Kunden immer den schnellsten Return on Investment bieten. Das Erstellen von Data Marts ist ein einfacher Prozess. Sie beginnen damit, die Abfragen hinter Ihren Berichten zu nehmen und sie von der Rückgabe von Ergebnismengen auf das Speichern der Ergebnismengen in permanenten Tabellen umzustellen. Sie fügen einfach TRUNCATE TRUNCATE TABLE Tabellenname hinzu; INSERT INTO Tabellenname vor dem ursprünglichen Schlüsselwort SELECT . Sobald Sie über einige funktionsfähige Data Mart-Tabellen verfügen, sollten Möglichkeiten zum Zusammenführen der Data Marts identifiziert werden. Suchen Sie nach Berichtsabfragen, die dieselbe Tabellenliste verwenden, und führen Sie dann die Liste der Felder zusammen. Dies erfordert eine kompliziertere Abfrage, insbesondere wenn die Liste der Tabellen zunimmt. Solange Sie die Abfrage jedoch gründlich testen, kann jede inkrementelle Änderung ohne Unterbrechung der normalen Geschäftsprozesse vorgenommen werden.

Jedes Mal, wenn Sie eine Verbesserung an einem Kimball-Data-Warehouse-Design vornehmen, haben Sie die Möglichkeit, dem Kunden einen ROI zu zeigen. Das liegt daran, dass das Data Warehouse zuerst erstellt wird und die Berichts-Data Marts aus einem statischen Data Warehouse erstellt werden. Daher entstehen Ihnen die meisten Kosten schon früh im Data-Warehouse-Projekt.

OLAP-Würfel

Ein OLAP-Cube kann einer Organisation zugute kommen, indem er aggregierte Daten mit einer schnellen Reaktionszeit, Ad-hoc-Drilldown-Funktionen für Endbenutzer und Data Mining bereitstellt. Wenn Sie über einen geeigneten OLAP-Würfel verfügen, können Sie jeden Wert aus Ihren Daten extrahieren. Ein OLAP-Cube baut auf einem Data Warehouse auf, verwendet jedoch eine andere Sprache, MDX, als eine Standard-Datenbank-SQL. Es erfordert auch einen aufwendigeren Konfigurationsaufwand als ein Datenbankserver. Diese Komplexität macht ein OLAP-Projekt teuer, außerdem ist es schwierig, erfahrene MDX-Entwickler zu finden.

Datenarchitekten sehen manchmal vorhandene OLAP-Cubes mit nichts anderem als einem einfachen Dashboard, das den Cube verwendet, ohne einen einzigen Prozess, der nicht durch eine SQL-Abfrage, ein Data Warehouse oder einen vorgefertigten Bericht ersetzt werden könnte. Ein OLAP-Würfel kann eine schnellere Reaktionszeit bieten als ein vorgefertigter Bericht, aber in den meisten Situationen ist der Unterschied vernachlässigbar. Sie können auch von den Drilldown-Funktionen profitieren, aber bevor Sie den Endbenutzern Drilldown-Funktionen zur Verfügung stellen, ist es eine gute Idee, vorgefertigte Berichte zu verwenden, die eine ähnliche Ad-hoc-Schnittstelle bieten.

Auf diese Weise können Sie die von Endbenutzern ausgeführten Ad-hoc-Abfragen aufzeichnen und dann neue vorgefertigte Berichte identifizieren, von denen die Endbenutzer nicht wussten, dass sie erstellt werden können. Da sowohl die Reaktionszeit als auch Drilldown-Verbesserungen bei der Entwicklung eines OLAP-Würfels normalerweise minimal sind, ist es nicht erforderlich, ihn einem Kunden vorzuschlagen, bis er eine Datenbankarchitektur benötigt, die das damit verbundene Data Mining handhaben kann. Dann können Sie Kunden wirklich beeindrucken und ihnen etwas über ihr Geschäft zeigen, das sie ohne eine robuste Datenbankarchitektur vielleicht nie gewusst hätten.

Wie bereits erwähnt, kann das Erstellen eines OLAP-Würfels eine Herausforderung darstellen. Es empfiehlt sich, einen hybriden OLAP-Cube in Erwägung zu ziehen. PowerPivot von Microsoft Excel bietet benutzerfreundliche Data-Mining-Tools ohne die Komplexität eines vollständigen OLAP-Cubes. Der Hauptnachteil eines Hybrids besteht darin, dass er nicht die gleiche Reaktionszeit hat. Ein großer Vorteil ist jedoch, dass Data-Mining-Berichte mit Excel einfacher erstellt werden können als mit MDX. Beim Data Mining gibt es drei nützliche Berichte. Wir können uns einige Beispiele aus der realen Welt ansehen und wie man sie interpretiert.

Alle diese Berichte stammen aus einer vom Autor erstellten automatisierten Daytrading-Anwendung.

Visuelle Berichterstattung

Scatterplot-Bericht

Ein Streudiagrammbericht ist ein Bericht auf Detailebene, der zwei Variablen vergleicht. Das Hinzufügen von Farbe und Größe zu den tatsächlichen Punkten hilft, die tatsächlichen Ergebnisse in Bezug auf diese Variablen zu visualisieren.

Box-and-Whiskers-Bericht

Dieser Bericht fasst die x- und y-Werte aus dem Streudiagrammbericht zusammen. Die x-Achsenwerte werden in einen Satz von Buckets diskretisiert.

Die Enden jedes Whiskers (Linie) repräsentieren die Ausreißer. Die gelben und hellblauen Balken repräsentieren die oberen und unteren Standardabweichungsbereiche.

Lineares Regressionsmodell

Dieser Bericht zeigt die Korrelation zwischen den x- und y-Achsenwerten zusammen mit einer Glättung der Linie, die durch eine mathematische Formel dargestellt werden kann. Der R-Quadrat-Wert ist enthalten, um zu zeigen, wie zuverlässig die Korrelation ist.

Fazit

Wenn Ihr Unternehmen wächst, wächst normalerweise auch Ihre Datenbank.

Die meisten Organisationen benötigen zunächst keinen Datenbankfachmann oder ein dediziertes Data-Science-Unternehmen, das sich um ihre Anforderungen kümmert. Stattdessen lassen sie ihre IT-Mitarbeiter mehrere Verantwortlichkeiten übernehmen oder, wie das Sprichwort sagt, „viele Hüte tragen“. Das funktioniert bis zu einem gewissen Punkt, aber irgendwann müssen Sie Spezialisten hinzuziehen.

Die in diesem Dokument aufgeführten Elemente sind eine schnelle und einfache Möglichkeit, Datenbankprobleme zu identifizieren, die Ihnen möglicherweise nicht bekannt waren. Hoffentlich wurde auch behandelt, wie Sie erstklassige Data-Mining-Tools erstellen können, ohne viel für teure Softwarelizenzen auszugeben. Auf diese Weise erhalten Sie eine bessere Vorstellung davon, wie sehr Ihr Unternehmen davon profitieren könnte, wenn Sie Ihrem IT-Personal einen Datenbankfachmann hinzufügen.