Tag Archive for: Business Intelligence

Benjamin Aunkofer

Interview mit Prof. Carsten Felden über Artificial Intelligence und Cognitive Computing

/in , , /by

Wird Artificial Intelligence oder Cognitive Computing oder beides zusammen der Standard, den alle haben müssen?

Prof. Dr. Carsten Felden ist Vorsitzender des Vorstandes des TDWI e.V., der größten Community für Analytics und Buisness Intelligence.. Er ist selbst Experte und Consultant für Business Intelligence und für diesen Fachbereich Lehrstuhlinhaber an der TU Bergakademie Freiberg.

Data Science Blog: Herr Prof. Felden, welcher Weg hat Sie bis an die Spitze des erfolgreichsten deutschen Verbandes für Analytics und Business Intelligence geführt?

Ich möchte die Beantwortung gerne umdrehen: Der TDWI ist ein Verein, in dem sich jeder als Mitglied engagieren darf und soll. Und da die Themen mir Freude bereiten und immer wieder neue Facetten zeigen, bin ich auch mit Begeisterung dabei und trage dies gerne in den Verein. Zu diesen Themen bin ich über mein Studium der Wirtschaftswissenschaft gelangt, in dem ich Wirtschaftsinformatik und Logistik vertiefte. Bei Professor Chamoni bot sich mir 2002 die Gelegenheit zur Promotion, in der ich mittels Text Mining ein Analysesystem in Python entwickelte, um Energiemarktentwicklungen zu erklären. Schon während dieser Zeit ergaben sich aber immer wieder Fragestellungen, welche die Entscheidungsfindung an sich betrafen. Dies interessierte mich in den vielen Facetten, so dass ich eine Habilitationsschrift anschloss, um den Entscheidungsprozess näher von der theoretischen Seite zu beleuchten. Dabei nahm ich Datenanalyseprozesse als Grundlage, um deren Wirkung auf menschliche Entscheidungsträger zu betrachten. Mit der Übernahme meiner Professur in 2006 baute ich einen kompetenzcenterorientierten Lehrstuhl auf, der sich zum Ziel setzte zu untersuchen, wie man realistisch mit Daten arbeiten kann, was man mit Daten tun kann. Dies in unterschiedlichen Welten: dem internationalen High-Tech-Konzern, dem Mittelständler als Hidden Champion oder dem kleineren Unternehmen. Insbesondere die Verbindung von Theorie und Praxis hat immer wieder die universitäre Lehre befruchtet und diese wollte ich auch in den Verein tragen. Im Rahmen der Veranstaltungen des TDWI habe ich immer viele neue Dinge oder realistische Einschätzungen aktuell diskutierter Dinge erhalten und wollte letztlich diese auch aus meinen Projekterfahrungen in die dortigen Diskussionen in unterschiedlichen Veranstaltungen zurückbringen. Das ich nun Vorsitzender dieses Vereins sein darf ist aber den Mitgliedern zu verdanken, die Vertrauen in mich setzten, den Weg des Vereins weiter voran zu treiben und meinen Vorstandskollegen, ohne deren Arbeit und Unterstützung meine Tätigkeit nichts wert wäre. Es ist der Verein als Ganzes, der den Mehrwert bietet und nicht einzelne Personen.

Data Science Blog: Wie weit ist die Industrie mittlerweile beim Einsatz von AI, also künstlicher Intelligenz?

Eine eindeutige Antwort ist hier gar nicht möglich. Allein schon die Deutung des Begriffs in der Praxis, macht es manchmal schwer, zwischen echten und unechten AI-Projekten zu unterscheiden. Letztlich kann man aber abgrenzend sagen, dass AI die automatisierte Entscheidung ermöglicht und nicht bei der Entscheidungsunterstützung für einen menschlichen Aufgabenträger endet. Egal, ob es nun ein echte oder ein unechtes AI-Projekt ist, es gilt, dass Daten entsprechend zu identifizieren, zu extrahieren und ggf. zu transformieren und final bereitzustellen sind. Nun soll aber nicht der Manager mit seinem fachlichem Know How (=Bauchgefühl) diese Informationen zur Entscheidung nutzen, sondern die Maschine übernimmt auch diesen Part (ohne Bauchgefühl) basierend auf Algorithmen. Man darf den Begriff der Entscheidung nicht immer mit einer besonderen Tragweite verbinden, da schon das einfache Signal einer Maschine: „Ich bin frei, ich habe Zeit, ich kann das jetzt tun!“ ist eine Entscheidung.
Um auch noch kurz auf die Abgrenzung zu den unechten Projekten einzugehen: hier erlebe ich immer wieder, dass AI mit künstlichen neuronalen Netzen gleichgesetzt wird. Natürlich kann man solche Netze hier nutzen, aber letztlich geht es nur darum, den Entscheidungsprozess in unterschiedlichen Situationen zu automatisieren. Zu diesem Zweck muss man prüfen, wo das sinnhaft möglich ist, da es nicht das Ziel sein kann, alles ohne Wenn und Aber zu automatisieren. In technisch-affinen Unternehmen sehen wir schon einige Umsetzungen, die über den Pilot-Status hinaus sind. Beispielhaft zu nennen sind da vollautomatisierte Fertigungen, insofern der Herstellungsprozess reihenfolgeunabhängig ist oder aber Controllingprozesse. Im Kern sind es aktuell noch Tätigkeiten, die keinen ausgeprägten kreativen Kern beinhalten, aber ein hohes Maß an Kommunikation zwischen den Beteiligten Systemelementen erfordern. In Summe gibt es ein breites Interesse und schon viele Orientierungsbeispiele, die dazu führen werden, dass diese Projekte intensiver zunehmen werden.

Data Science Blog: Wie grenzen Sie eigentlich Artificial Intelligence und Cognitive Computing voneinander ab? Wo liegen die Unterschiede?

Letztlich kann ich hier zum vorherigen ergänzen: beim Cognitive Computing handelt es sich um die Fortführung der wissensbasierten Systeme beziehungsweise der Expertensysteme. Der enorme und damit auch beeindruckende Unterschied zu den Vorläufern ist die Fähigkeit des Lernens im Sinne einer inhaltlichen Weiterentwicklung der vorhandenen Wissensbasis, die nun wesentlich ausgeprägter ist und auch automatisiert in entsprechenden Wissensdomänen stattfinden kann. AI kann einerseits zum Lernen des Systems beitragen, andererseits das gelernte für die automatisierte Entscheidung anwenden. Beide Ansätze nutzen und befruchten sich also gegenseitig.

Data Science Blog: Welche Trends im Bereich Machine Learning bzw. Deep Learning werden Ihrer Meinung nach in den Jahren 2018 und 2019 von Bedeutung werden?

Da möchte ich direkt zu unserer diesjährigen Konferenz in München herüber schwenken. Traditionell finden wir dort die Trends der nächsten Jahre schon in Vorträgen und Diskussionen.
Insgesamt beobachten wir eine starke Entwicklung hin zur Analyse unstrukturierter Daten. Machine Learning wird zunehmend intensiv in textuellen Analysen genutzt, um zum Beispiel eine E-Mail-Kategorisierung beziehungsweise Reaktion auf eine E-Mail zu automatisieren. Darüber hinaus ist die Verarbeitung von Bildern mit Ansätzen des Deep Learning ein zunehmender Trend. Dies in Szenarios wie die Fehlererkennung in der Herstellung oder dem Erkennen des Anwenders und dahingehend automatischen Anpassung seiner vorliegenden Systemlösung mit den passenden Inhalten. Sie sehen also, dass alle Facetten der algorithmischen Datenanalyse bedeutend werden. Dabei stellen wir aber auch fest, dass der klassischen Hausaufgaben, wie Datenintegration, Datenqualitätssicherung, Datenbereitstellung etc. nicht vom Tisch sind, sondern auch immer wieder neu diskutiert werden. Hier kommt aktuell hinzu, Verfahren der künstlichen Intelligenz zu nutzen, um eine dynamische Schemaerzeugung in Zeiten von Data Lakes automatisiert auszuführen, um den Anwendern für die jeweilige Entscheidungssituation Daten bedarfs- und verarbeitungsgerecht zur Verfügung zu stellen. Wir sehen also, dass die Übernahme von Tätigkeiten durch maschinellen Aufgabenträger der treibende Faktor ist, was dann mittels Machine Learning bzw. Deep Learning umsetzbar ist.

Data Science Blog: In wie weit wird der Begriff „Business Intelligence“ Ihrer Meinung nach zukünftig erhalten bleiben? Wie nahtlos ließen sich die neuen Möglichkeiten mit künstlicher Intelligenz in BI-Systeme integrieren?

Nun ja, aktuell werden wir mit Schlagworten überflutet, die darüber hinaus noch oftmals mit unterschiedlichen Verständnissen belegt sind, so dass es mehr Verwirrung als Erkenntnis gibt. Wissenschaftlich betrachtet ist Business Intelligence ein allumfassender Begriff, da er lediglich benennt, dass Daten zu sammeln und zu Entscheidungszwecken aufzubereiten sind. Dies subsummiert also auch AI.
In der Praxis ist BI aber eher das alte, starre Berichtswesen und passt dann so gar nicht zu den dynamischen Analyticsansätzen. Hier muss man aber sagen, dass Self Service Ansätze und die zunehmende Flexibilisierung der Architekturen dabei unterstützt, beide Welten zusammenzubringen. Aktuell ist man noch auf dem Niveau, über Schnittstellen bewusst Code auszutauschen. Beispielsweise lässt sich R-Code in vielen BI-Werkzeugen ausführen. Letztlich erleben wir aber alle, dass Geräte immer einfacher zu steuern sind und dadurch Welten auch zusammenfließen und das wird auch hier geschehen, weil es die Anwender einfach so gewohnt sind.

Data Science Blog: Manchmal hört man, dass Data Scientists gerade an ihrer eigenen Arbeitslosigkeit arbeiten, da zukünftige Verfahren des maschinellen Lernens Data Mining selbstständig durchführen können. Werden Tools Data Scientists bald ersetzen?

Die Wirtschaftsinformatik hat das Postulat der sinnhaften Vollautomation. Daher sehe ich es auch hier so, dass man die Punkte beziehungsweise Stellen im Prozess identifizieren muss, wo die Anwendung der Data Science Sinn macht. Darüber hinaus sehe ich den Data Scientist eigentlich nicht als eine Person, sondern als ein Konglomerat an Fähigkeiten, oftmals verteilt über mehrere Abteilungen und damit auch mehrere Personen, die zusammenarbeiten müssen. Die geforderten Fähigkeiten werden sich sicherlich wandeln, jedoch wird Kommunikationsfähigkeit immer der Schlüssel sein und Tools werden dahingehend das Data Science Team nicht ersetzen, sondern immer Mittel zum Zweck im Rahmen der sinnhaften Vollautomation sein.

Data Science Blog: Für alle Studenten, die demnächst ihren Bachelor, beispielsweise in Informatik, Mathematik oder Wirtschaftswissenschaften, abgeschlossen haben, was würden sie diesen jungen Damen und Herren raten, wie sie gute Data Scientists werden können?

Kommunizieren können und neugierig sein. Sie werden alle viel im Rahmen ihrer Ausbildung an fundamentalen Fähigkeiten gelernt haben, aber lassen sie sich auf die Partner im Projekt ein, interessieren sie sich für all das, was auf der fachlichen Ebene geschieht und wie der technische Fortschritt aussieht. Ich kann immer nur wiederholen, dass offene Kommunikation eine wichtige Fähigkeit in Projekten ist, die nicht hoch genug bewertet werden kann. Die TDWI-Konferenz oder all die anderen Formate des Vereins bieten die Möglichkeit, Wissen aufzunehmen, auszutauschen und sich selber mit anderen zu vernetzen. Ich denke wirklich, dass gute Data Scientist derartiges nutzen, um die eigenen Themen bestmöglich angehen zu können, denn das ist der Schlüssel zum Erfolg!

Prof. Felden wird am 25. Juni die TDWI Konferenz in München eröffnen, die unter dem Slogan „Business Intelligence meets Artificial Intelligence“ die neuen Möglichkeiten unter Einsatz künstlicher Intelligenz in den Fokus stellen wird.

Hoang Tu Nguyen

Datenmodell: Sternschema

/in , , /by

Ob es unsere Schritte während des Sports sind, Klicks auf Websiten oder auch Geschäftszahlen eines Unternehmens – all diese Informationen werden in Form von Daten gespeichert. Dabei fallen große Mengen an Daten an, die in der Regel in einer relationalen Datenbank gespeichert werden, um sie besonders gut administrieren zu können.
Gerade in einem Unternehmen ist es wichtig, dass mehrere Benutzer parallel und mit wenig Verzögerung Anfragen und Änderungen in den Daten durchführen können. Daher werden viele Datenbanken in Unternehmen als OLTP-Datenbank-Systeme ausgelegt. OLTP steht für Online Transaction Processing, auch Echtzeit-Transaktionsverarbeitung ist dafür optimiert, schnelle und parallele Zugriffe auf Daten in der Datenbank zu gewährleisten.
Möchte man hingegen Daten auswerten und analysieren, sind OLTP-Datenbanken-Systeme weniger geeignet, da sie nicht für diese Art von Anfragen konzipiert worden sind. Um effektiv analytische Befehle an eine Datenbank stellen zu können, werden daher Datenbanken genutzt, die mit einer OLAP-Verarbeitung arbeiten. OLAP ist die Abkürzung für Online Analytical Processing. Im Gegensatz zu OLTP, in welchen die Daten in einem zweidimensionalen Modell gespeichert werden, sind Daten in einem OLAP-System in einer multidimensionalen Struktur untergebracht, welche für die Durchführung komplexer Analysebefehle optimiert ist.
Für Analysen werden oft Daten aus mehreren Datenbanken benötigt, weswegen sie in einem Datenlager – oder auch Data Warehouse genannt – zusammengefasst und gespeichert werden. Ein Data Warehouse, welche auf der OLAP-Verarbeitung basiert, ist somit eine für Analysezwecke optimierte Datenbank.
Es gibt verschiedene Datenmodelle um die Daten in einem Data Warehouse anzulegen. Das verbreiteste Datenmodell für diese Zwecke ist das sogenannte Sternen-Schema (Star Schema). Neben dem Sternen-Schema gibt es auch die sogenannten Galaxy- und Snowflake-Schemen, die wiederum eine Erweiterung des zuerst genannten Datenmodells sind. In diesem Artikel werden wir das Sternschema näher beleuchten.

Aufbau und Funktionsweise

Bei einem Sternschema werden die Daten grundlegend in zwei Gruppen unterteilt:

  • Fakten, manchmal auch Metriken, Messwerte oder Kennzahlen genannt, sind die zu verwaltenden bzw. die zu analysierenden Daten und werden fortlaufend in der Faktentabelle gespeichert. Beispielhaft für Fakten sind Umsätze sowie Verkaufszahlen eines Unternehmens. Sie haben stets eine numerische Form.
  • Dimensionen sind die Attribute bzw. Eigenschaften der Fakten und beschreiben sozusagen die Fakten im Detail. Diese werden in Dimensionstabellen gelistet. Jeder Dimensionsdatensatz bzw. jede Zeile einer Dimensionstabelle wird durch Primärschlüssel eindeutig identifiziert. Diese Schlüssel werden in der Faktentabelle als Fremdschlüssel gespeichert und somit sind Dimensions- und Faktentabelle miteinander verknüpft.

Beispiel: Max Mustermann, 25 Jahre alt, wohnhaft in Musterstadt hat eine Kaffeemaschine mit dem Namen ‘Musterpresso’ am 01.01.2018 um 15:00:00 gekauft.

Wie in der Abbildung dargestellt, werden die Details, als Attribute dargestellt, vom Kunden wie Namen, Alter oder Wohnort in der Dimensionstabelle “Kunde” gespeichert und mit dem Primärschlüssel (in diesem Beispiel “1111”) gekennzeichnet. Dieser wird in der Faktentabelle als Fremdschlüssel gespeichert. Analog zu den Daten vom Kunden werden auch Dimensionstabellen für die Größen

  • Bestellung,
  • Produkt,
  • Produktkategorie und
  • Zeit gebildet.

Die Fakten, welche in diesem Beispiel der Umsatz von Max Mustermann ein Fakt wäre, können nun mithilfe der Fremdschlüssel

  • Kunden ID,
  • Bestellung ID,
  • Produkt ID,
  • Produktkategorie ID und
  • Zeit

aus der Faktentabelle aufgerufen werden.

Bei der Bildung von Tabellen ist es möglich, dass identische Werte mehrfach gespeichert werden. Dabei können Redundanzen und Anomalien in der Datenbank enstehen, welche zusätzlich einen erhöhten Speicherbedarf erfordern. Um dies zu verhindern werden Tabellen normalisiert. Bei einer Normalisierung einer Tabelle bzw. einer Tabellenstruktur wird es angestrebt, Redundanzen bis auf ein Maximum zu reduzieren. Je nach Grad der Normalisierung können diese in verschiedene Normalformen (1NF -2NF-3NF-BCNF-4NF-5NF) unterteilt werden.

Die Normalisierung in eine höhere Normalform hat jedoch zur Folge, dass die Abfrage-Performance abnimmt. Da das Sternschema-Modell darauf ausgelegt ist Leseoperationen effizient durchzuführen, sind Faktentabellen in der dritten Normalform (3NF) abgespeichert, da alle Redundanzen in dieser Form beseitigt worden sind und dennoch eine hohe Performance gewährleistet. Dimensionstabellen sind hingegen nur bis zur zweiten Normalform (2NF) optimiert. Es werden also bewusst Redundanzen und ein erhöhter Speicherbedarf in den Dimensionstabellen für eine schnelle Abfrage der Daten in Kauf genommen.

Vor- und Nachteile

Wie bereits erwähnt, sind Dimensionstabellen im Sternschema nicht vollständig normalisiert. Damit nimmt man zugunsten höherer Performance mögliche Anomalien und auch einen erhöhten Speicherbedarf in Kauf. Durch das einfache Modell ist dafür jedoch eine intuitive Bedienung möglich und auch Veränderungen sowie Erweiterungen des Modell sind leicht realisierbar.

Vorteile Nachteile
Einfaches Modell ermöglicht eine intuitive Bedienung. Durch mehrfaches Speichern identischer Werte steigt die Redundanz in den Dimenionstabellen
Veränderungen und Erweiterungen können leicht umgesetzt werden. Bei häufigen Abfragen sehr großer Dimensionstabellen verschlechtern sich die Antwortzeiten
Durch Verzicht der Normalisierung in den Dimensionstabellen ist die hierarchische Beziehung innerhalb einer Dimension leicht darstellbar Erhöhter Speicherbedarf durch Nicht-Normalisierung der Dimensionstabellen

Zusammenfassung

Das Sternschema ist ein Datenmodell, welches für analytische Zwecke im Data Warehouse und bei OLAP-Anwendungen zum Einsatz kommt. Es ist darauf optimiert, effiziente Leseoperationen zu gewährleisten.
Der Name des Modells beruht auf der sternförmigen Anordnung von Dimensionstabellen um die Faktentabelle, wobei die Dimensionstabellen die Attribute der Fakten beinhalten und in den Faktentabellen die zu analysierenden Größen gespeichert sind. Charakteristisch ist dabei, dass die Dimensionstabellen nicht bis zur dritten Normalform normalisiert sind. Der sich daraus ergebende Vorteil ist die schnelle Verarbeitung von Abfragen. Auch ist die intuitive Bedienung ein positiver Aspekt des einfachen Datenmodells. Jedoch können durch den Verzicht der Normalisierung Redundanzen innerhalb der Dimensionstabellen durch mehrfache Speicherung von identischen Werten entstehen. Ebenfalls ist bei häufigen Anfragen von großen Dimensionstabellen ein verschlechtertes Antwortverhalten feststellbar.
Daher sind sie vor allem dann effektiv, wenn

  • schnelle Anfrageverarbeitungen notwendig sind,
  • sich schnell ändernde Datenstrukturen (der Original-Daten) vorliegen,
  • Dimensionstabellen in ihrer Größe überschaubar bleiben,
  • und ein breites Spektrum an Benutzern Zugriff auf die Daten benötigt.
Robert Schmitz

Ständig wachsende Datenflut – Muss nun jeder zum Data Scientist werden?

/in , , , , , , , /by

Weltweit rund 163 Zettabyte – so lautet die Schätzung von IDC für die Datenmenge weltweit im Jahr 2025. Angesichts dieser kaum noch vorstellbaren Zahl ist es kein Wunder, wenn Anwender in Unternehmen sich überfordert fühlen. Denn auch hier muss vieles analysiert werden – eigene Daten aus vielen Bereichen laufen zusammen mit Daten Dritter, seien es Dienstleister, Partner oder gekaufter Content. Und all das wird noch ergänzt um Social Content – und soll dann zu sinnvollen Auswertungen zusammengeführt werden. Das ist schon für ausgesprochene Data Scientists keine leichte Aufgabe, von normalen Usern ganz zu schweigen. Doch es gibt eine gute Nachricht dabei: den Umgang mit Daten kann man lernen.

Echtes Datenverständnis – Was ist das?

Unternehmen versuchen heute, möglichst viel Kapital aus den vorhandenen Daten zu ziehen und erlauben ihren Mitarbeitern kontrollierten, aber recht weit gehenden Zugriff. Das hat denn auch etliche Vorteile, denn nur wer Zugang zu Daten hat, kann Prozesse beurteilen und effizienter gestalten. Er kann mehr Informationen zu Einsichten verwandeln, Entwicklungen an den realen Bedarf anpassen und sogar auf neue Ideen kommen. Natürlich muss der Zugriff auf Informationen gesteuert und kontrolliert sein, denn schließlich muss man nicht nur Regelwerken wie Datenschutzgrundverordnung gehorchen, man will auch nicht mit den eigenen Daten dem Wettbewerb weiterhelfen.

Aber davon abgesehen, liegt in der umfassenden Auswertung auch die Gefahr, von scheinbaren Erkenntnissen aufs Glatteis geführt zu werden. Was ist wahr, was ist Fake, was ein Trugschluss? Es braucht einige Routine um den Unsinn in den Daten erkennen zu können – und es braucht zuverlässige Datenquellen. Überlässt man dies den wenigen Spezialisten im Haus, so steigt das Risiko, dass nicht alles geprüft wird oder auf der anderen Seite Wichtiges in der Datenflut untergeht. Also brauchen auch solche Anwender ein gewisses Maß an Datenkompetenz, die nicht unbedingt Power User oder professionelle Analytiker sind. Aber in welchem Umfang? So weit, dass sie fähig sind, Nützliches von Falschem zu unterscheiden und eine zielführende Systematik auf Datenanalyse anzuwenden.

Leider aber weiß das noch nicht jeder, der mit Daten umgeht: Nur 17 Prozent von über 5.000 Berufstätigen in Europa fühlen sich der Aufgabe gewachsen – das sagt die Data-Equality-Studie von Qlik. Und für Deutschland sieht es sogar noch schlechter aus, hier sind es nur 14 Prozent, die glauben, souverän mit Daten umgehen zu können. Das ist auch nicht wirklich ein Wunder, denn gerade einmal 49 Prozent sind (in Europa) der Ansicht, ausreichenden Zugriff auf Daten zu haben – und das, obwohl 85 Prozent glauben, mit höherem Datenzugriff auch einen besseren Job machen zu können.

Mit Wissens-Hubs die ersten Schritte begleiten

Aber wie lernt man denn nun, mit Daten richtig oder wenigstens besser umzugehen? Den Datenwust mit allen Devices zu beherrschen? An der Uni offensichtlich nicht, denn in der Data-Equality-Studie sehen sich nur 10 Prozent der Absolventen kompetent im Umgang mit Daten. Bis der Gedanke der Datenkompetenz Eingang in die Lehrpläne gefunden hat, bleibt Unternehmen nur die Eigenregie  – ein „Learning by Doing“ mit Unterstützung. Wie viel dabei Eigeninitiative ist oder anders herum, wieviel Weiterbildung notwendig ist, scheint von Unternehmen zu Unternehmen unterschiedlich zu sein. Einige Ansätze haben sich jedoch schon bewährt:

  • Informationsveranstaltungen mit darauf aufbauenden internen und externen Schulungen
  • Die Etablierung von internen Wissens-Hubs: Data Scientists und Power-User, die ihr Know-how gezielt weitergeben: ein einzelne Ansprechpartner in Abteilungen, die wiederum ihren Kollegen helfen können. Dieses Schneeball-Prinzip spart viel Zeit.
  • Eine Dokumentation, die gerne auch informell wie ein Wiki oder ein Tutorial aufgebaut sein darf – mit der Möglichkeit zu kommentieren und zu verlinken. Nützlich ist auch ein Ratgeber, wie man Daten hinterfragt oder wie man Datenquellen hinter einer Grafik bewertet.
  • Management-Support und Daten-Incentives, die eine zusätzliche Motivation schaffen können. Dazu gehört auch, Freiräume zu schaffen, in denen sich Mitarbeiter mit Daten befassen können – Zeit, aber auch die Möglichkeit, mit (Test-)Daten zu spielen.

Darüber hinaus aber braucht es eine Grundhaltung, die sich im Unternehmen etablieren muss: Datenkompetenz muss zur Selbstverständlichkeit werden. Wird sie zudem noch spannend gemacht, so werden sich viele Mitarbeiter auch privat mit der Bewertung und Auswertung von Daten beschäftigen. Denn nützliches Know-how hat keine Nutzungsgrenzen – und Begeisterung steckt an.

Lisa Sagal

OLAP Technology in Business Intelligence

/in , , /by

Data in Business Intelligence
Business processes traditionally comprise three stages of data management: collecting, analyzing, and reporting. First, data should be gathered from all the sources through ETL tools (Extract, Transform, Load). After this, there are often issues occurring connected with data consistency hence the data should be cleaned and structured using the function of metadata. Once the data are provided to the end-user in a readable and transparent way it is ready to be analyzed. There are multiple applications ensuring data analysis including Data Mining, OLAP, BI. In order to carry out in-depth and coherent analysis, the best approach is to initially determine KPI as these are the criteria to assess the progress in relation to the goals set.

OLAP definition
OLAP tool belongs to Business Intelligence concept intended for big data management and is short for Online Analytical Processing. OLAP conducts multidimensional data analysis and enables end-users to perform complicated calculations, trend analysis, ‘what-if’ scenarios and the like. Furthermore, owing to OLAP it’s possible to conduct planning and forecasting, budgeting and financial reporting, analysis, and data modeling which contributes to successful decision making in business.

OLAP Structure
An OLAP cube is composed of dimensions containing aggregated information referred to and measures which include numerical data. Dimensions are arranged in hierarchies which in their turn are indicators to determine the rate of granularity; the rate is called a level. The most common dimensions are location, product, and time. The lowest granularity level of a time dimension may be hours while the highest one can present years. This way when there is a query to be responded the measures contribute to filter out the data and select the right object inside the dimension. In the center of the cube there is a star or a snowflake schema which all the dimensions refer to.

OLAP main characteristics
Here are the main features characterizing the OLAP tool”:

– The data in OLAP is structured as a multidimensional cube.
– The cube structure allows users to see the information from various angles given location, products, demographics, time, etc.
– Rapid data access and analysis due to precalculated aggregations.
– Simple and intuitive interface.
– OLAP doesn’t require IT skills or SQL knowledge (as some other business intelligence software tools). Hence its operation eases the burden of IT department.
– The tool supports complex custom calculations
– The OLAP databases maintain historical data and are updated not constantly but regularly.
– The cube design and building process is the pivotal step on the way to successful data processing.

OLAP requirements
When the OLAP technology was invented there were twelve rules generated to follow so that it complies with the concept of online data processing:

Multidimensional
Not only the OLAP view has to be multidimensional but the data should as well be stored in this way of structure in order to provide the multidimensional analysis.

Transparent
The architecture has to be transparent to let the user see and understand the functionality and the client server of the application.

Accessible
The end user must have an opportunity to access the information in its consistent view without any issues related to the sources where the data come from or the way the data are maintained in OLAP.

Consistent Reporting
The data are regularly upgraded and its volume grows progressively although the user shouldn’t see problems changes in the process of scheduled reporting regarding that.

Client-Server
OLAP application has to manage client-server architecture as it manages vast volumes of data often requiring a core server for storage and maintenance.

Common Dimensionality
The main feature of the dimension structure in OLAP must be the same for all the dimensions to keep the data consistent, accurate, valid, complete, etc. Thus the dimensions have to possess common operation capabilities and be equal in structure.

Dynamic Sparse Matrix Handling
A usual OLAP application must manage to deal with sparse matrices and shouldn’t let the cube expand excessively as a usual OLAP cube is relatively sparse.

Multi-User
OLAP technology is originally supposed to provide an opportunity to access the data for multiple users simultaneously. The process of data management must at the same time be ensured with security and integrity.

Unrestricted Cross-dimensional Operations
A typical OLAP application is meant to handle all calculations and operations (such as slice-and-dice, drill up-down, drill through etc.) without the participation of the user. Commonly the tool delivers a language to exploit while requiring specified information.

Intuitive Data Manipulation
All OLAP operations which handle dimensions, measures, hierarchies, levels etc. have to be user-friendly and easily adopted without requiring additional technical skills. An average employee is considered to cope with the data navigation and management through clear displaying and handy operations.

Flexible Reporting
The main function – reporting must be flexible with a view to organizing all the rows, columns, and page setup containing a requisite number of dimensions and hierarchies from the data. As a result, the user has to gain a report comprising all the needed members and the relations between them.

Unlimited Dimensions and Aggregation Levels
When the technology was designed it was intended to be able to contain up to twenty dimensions in the cube. Each dimension had to provide as many aggregation levels inside a hierarchy as required. The idea was to manage great volumes of data keeping end-users absolutely aware of the performance of the organization.

Advantages of OLAP
Speed
Before OLAP was invented and introduced to the market there hadn’t been a tool to rapidly run the queries and it had taken long to retrieve the required information from the data. Thus the main advantage of the OLAP application is its speed gained due to precomputation of the data aggregations.

MDX designer and ad-hoc reports
MDX Designer is aimed at creating interactive ad-hoc reports. The reports provide a better understanding of the business processes and the organization’s performance in the market.

Visualization
OLAP provides its users with sophisticated data analytics allowing them to see data from different perspectives. There are numerous formats to visualize the requisite data: pie charts, graphs, heat maps, reports, pyramids, etc. Moreover, OLAP includes a number of operations to handle data: rotate, drill up and down, slice and dice, etc. Besides, there’s also an opportunity to apply a ‘what-if’ scenario due to a write-back option. All mentioned above can significantly contribute to decision-making process regarding the ongoing situation.

Flexibility
OLAP table displayed is flexible with column and row labels depending on the requirements of the user. Moreover, the reporting generated is available in multiple dimensions.

Sven Galonska

Self Service Data Preparation mit Microsoft Excel

/in , , , , , , , /by

Get & Transform (vormals Power Query), eine kurze Einführung

 Unter Data Preparation versteht man sinngemäß einen Prozeß der Vorbereitung / Aufbereitung von Rohdaten aus meistens unterschiedlichen Datenquellen und -formaten, verbunden mit dem Ziel, diese effektiv für verschiedene Geschäftszwecke / Analysen (Business Fragen) weiterverwenden/bereitstellen zu können. Rohdaten müssen oft vor ihrem bestimmungsgemäßen Gebrauch transformiert (Datentypen), integriert (Datenkonsistenz, referentielle Integrität), sowie zugeordnet (mapping; Quell- zu Zieldaten) werden.
An diesem neuralgischen Punkt werden bereits die Weichen für Datenqualität gestellt.

Unter Datenqualität soll hier die Beschaffenheit / Geeignetheit von Daten verstanden werden, um konkrete Fragestestellungen beantworten zu können (fitness for use):

Kriterien Datenqualität

  • Eindeutigkeit
  • Vollständigkeit
  • Widerspruchsfreiheit / Konsistenz
  • Aktualität
  • Genauigkeit
  • Verfügbarkeit

Datenqualität bestimmt im Wesentlichen die weitere zielgerichtete Verwendung der Daten in Analysen (Modelle) und Berichten (Reporting). Daten werden in entscheidungsrelevante Kennzahlen (Informationen) überführt. Eine Kennzahl ist gegenüber der Datenqualität immer blind, ihre Aussagekraft (Validität) hängt -neben der Definition – in sehr starkem Maße davon ab:

Gütekriterien von Kennzahlen

  • Objektivität := ist die Interpretation unabhängig vom Beobachter / Verwender?
  • Reliabilität := kann das Ergebnis unter sonst gleichen Bedingungen reproduziert werden ?
  • Validität := sagt die Kennzahl das aus, was sie vorgibt, auszusagen ?

Business Fragen entstehen naturgemäß in den Fachbereichen.Daher ist es nur folgerichtig, Data Preparation als einen ersten Analyseschritt innerhalb des Fachbereichs anzusiedeln (Self Service Data Preparation). Dadurch erhält der Fachbereich einen Teil seiner Autonomie zurück. Welche Teilmenge der Daten relevant für Fragestellungen ist, kann nur der Fachbereich beurteilen; der Anforderer von entscheidungsrelevanten Informationen sollte idealerweiseTeil der Entstehung wertiger Daten sein, das fördert zum einen die Akzeptanz des Ergebnisses, zum anderen wirkt es einem „not-invented-here“ Syndrom frühzeitig entgegen.

Im Folgenden wird anhand 4 Schritten skizziert, wie Microsoft Excel bei dem Thema (Self Service) Data Preparation vor allem den Fachbereich unterstützen kann. Eine Beispieldatei können Sie hier (google drive) einsehen. Sie finden die hierfür verwendete Funktionalität (Get & Transform) in Excel 2016 unter:

Reiter Daten -> Abrufen und Transformieren.

Dem interessierten Leser werden im Text vertiefende Informationen über links zu einzelnen typischen Aufgabenstellungen und Lösungswegen angeboten. Eine kurze Einführung in das Thema finden Sie in diesem Blog Beitrag.

1 Einlesen

Datenquellen anbinden (externe, interne)

Dank der neuen Funktionsgruppe „Abrufen und Transformieren“ ist es in Microsoft Excel möglich, verschiedene externe Datenquellen /-formate anzubinden. Zusätzlich können natürlich auch Tabellen der aktiven / offenen Excel Arbeitsmappe als Datenquelle dienen (interne Datenquellen). Diese Datenquellen werden anschließend als sogenannte Arbeitsmappenabfragen abgebildet.

Praxisbeispiele:

Anbindung mehrerer Dateien, welche in einem Ordner bereitgestellt werden

Anbindung von Webinhalten

2 Transformieren

Daten transformieren (Datentypen, Struktur)

Datentypen (Text, Zahl) können anschließend je Arbeitsmappenabfrage und Spalte(n) geändert werden.
Dies ist zB immer dann notwendig, wenn Abfragen über Schlüsselspalten in Beziehung gesetzt werden sollen (siehe Punkt 3). Gleicher Datentyp (Primär- und Fremdschlüssel) in beiden Tabellen ist hier notwendige Voraussetzung.

Des Weiteren wird in dieser Phase typischerweise festgelegt, welche Zeile der Abfrage die Spaltenbeschriftungen enthält.

Praxisbeispiele:

Fehlerbehandlung

Leere Zellen auffüllen

Umgang mit wechselnden Spaltenbeschriftungen

3 Zusammenführen / Anreichern

Daten zusammenführen (SVERWEIS mal anders)

Um unterschiedliche Tabellen / Abfragen über gemeinsame Schlüsselspalten zusammenzuführen, stellt der Excel Abfrage Editor eine Reihe von JOIN-Operatoren zur Verfügung, welche ohne SQL-Kenntnisse nur durch Anklicken ausgewählt werden können.

Praxisbeispiele

JOIN als Alternative zu Excel Formel SVERWEIS()

Daten anreichern (benutzerdefinierte Spalte anfügen)

Bei Bedarf können weitere Daten, welche sich nicht in der originären Struktur der Datenquelle befinden, abgeleitet werden. Die Sprache Language M stellt einen umfangreichen Katalog an Funktionen zur Verfügung. Wie Sie eine Übersicht über die verfügbaren Funktionen erhalten können erfahren Sie hier.

Praxisbeispiele

Geschäftsjahr aus Datum ableiten

Extraktion Textteil aus Text (Trunkation)

Mehrfache Fallunterscheidung, Datenbereinigung /-harmonisierung

4 Laden

Daten laden

Die einzelnen Arbeitsmappenabfragen können abschließend in eine Exceltabelle, eine Verbindung und / oder in das Power Pivot Datemodell zur weiteren Bearbeitung (Modellierung, Kennzahlenbildung) geladen werden.

Praxisbeispiele

Datenverbindung erstellen

Robert Schmitz

Stichwort Datenkompetenz: Von Big Data zu Big Insights

/in , , , , , /by

Anzeige – Artikel des Data Science Blog Sponsors Qlik.com

Wer in einer Organisation mit Daten arbeiten möchte, sollte dazu befähigt werden – sonst bleiben wertvolle Einblicke unter Umständen verborgen.

Aus der reinen Technologie-Perspektive ist Big Data nahezu grenzenlos: Prozessoren arbeiten immer schneller, die Kosten für Speicherplatz sinken kontinuierlich, Cloud-Dienste stellen ad hoc und flexibel auch riesige Speichervolumen zur Verfügung. Beste Voraussetzungen also für Big-Data-Enthusiasten? Könnte man meinen. Doch Big Data hat nicht von Haus aus Wert, Sinn oder Geschäftsnutzen. Der stellt sich erst ein, wenn die vielen verfügbaren Daten assoziativ und ohne Denk- oder Infrastruktur-Hürden neu kombiniert, analysiert und visualisiert – also wirklich smart – werden. Der Schlüssel dazu liegt in moderner Data Analytics Software, die unterschiedlichste Datenquellen und -formate verarbeiten und in Beziehung setzen kann – und so wertvolle neue Einsichten offenbart, die ohne Data Analytics im (Big-)Data-Lake abtauchen würden.

Reich an Daten – arm an Einsichten?

Entscheidend für den Erfolg von Big-Data-Projekten ist es, aus der Datenfülle die wirklich relevanten Zusammenhänge zu evaluieren – und nicht um des Sammelns willen Daten zu horten, die neue Einsichten eher zu- als aufdecken. Viele Organisationen befinden sich leider nach wie vor an diesem Punkt. Sie sind reich an Daten, aber nicht in der Lage, neue Informationen daraus zu extrahieren, die gute Ideen anstoßen, Innovation fördern und das Unternehmen nachhaltig weiterbringen. Es herrscht weitgehende Überforderung mit dem eigenen Datenschatz.

Wer in Big-Data-Technologien investiert, fragt früher oder später nach dem ROI seiner Investitionen. Dieser wird umso günstiger ausfallen, je leichter und passgenauer der Datennutzen an möglichst vielen Stellen im Unternehmen verfügbar ist. Hier gilt es zu erkennen, dass fast jeder im Unternehmen Daten gut nutzen kann und sich im Umgang mit ihnen sicher fühlen möchte, um seine Arbeit noch erfolgreicher zu machen – eine neue Untersuchung des Business-Intelligence-Experten Qlik beweist das.

88 Prozent sind überzeugt: Mit Daten läuft es besser

Demnach würden 66 Prozent der Befragten gerne mehr Zeit und Energie in ihre Datenkompetenz investieren – wenn es die Gelegenheit dazu gäbe. 88 Prozent der befragten Sachbearbeiter und ausführenden Kräfte sind überzeugt davon, dass sie mit adäquatem Datenzugang sowie mit den nötigen Befugnissen und Kompetenzen bessere Resultate im Job erreichen könnten. Doch nur 55 Prozent fühlen sich tatsächlich demensprechend ausgestattet und befähigt. Ganz anders das Bild unter Führungskräften: Unter diesen sind zwar 83 Prozent überzeugt davon, guten Zugang zu Daten zu haben – allerdings haben nur 26 Prozent der Chefs wirklich einen Ansatz gefunden, wie sie nutzbringend mit den Daten arbeiten können.

Das bedeutet: Zur datengetriebenen Arbeit sowie zur Unternehmenssteuerung und -entwicklung auf der Basis von Daten braucht nicht jeder im Unternehmen die gleichen Daten und Dashboards. Jedoch braucht jeder Mitarbeiter in der Organisation gleichermaßen die Möglichkeiten und Fähigkeiten, unkompliziert in den Daten zu forschen, die ihm persönlich helfen, seine Arbeit zu verbessern. Welche Ideen und Anschlussfragen die assoziative Data Discovery im Selfservice auslöst, ist vorher schwer zu sagen – Assoziation ist spontan. Daher gilt: Die Erkenntnis kommt beim Tun.

Aus diesem Grund verlangt wirkliche Innovation nach schrankenloser und intuitiver Datenarbeit, die Platz lässt für Ideen, für ungewöhnliche Datenkombinationen und für ein erfindungsreiches „Um-die-Ecke-Denken“. Lineare SQL-Abfragen können das nicht leisten – und entsprechen in ihren vordefinierten Pfaden nicht der wertvollen Kombinationskompetenz, die das menschliche Gehirn von Natur aus mitbringt.

Zukunftsweisende Data Analytics und Advanced Analytics versucht nicht, das Denken und Assoziieren zu ersetzen – sondern die kognitiven Prozesse des Anwenders zu unterstützen, sie zu erweitern und in ihren Möglichkeiten zu vervollständigen. So entsteht Augmented Intelligence: die intelligente Verknüpfung von menschlicher Ratio und technologischer Schnelligkeit, bzw. Vollständigkeit.

Zentral gemanagte Governance

Natürlich soll assoziatives und individuelles Daten-Handling nicht zum digitalen Selbstbedienungsladen führen. Um dennoch assoziative Analysen und freies Forschen in relevanten Daten zu gewährleisten, bewährt sich in der Selfservice-Datenanalyse zentral gesteuerte Governance mit rollenbasierter Datenverfügbarkeit und individuellen Zugriffsrechten als ideale Lösung.

Dr. Uwe Schneider

R Data Frames meistern mit dplyr – Teil 2

/in , , , , , , , , , , /by

Dieser Artikel ist Teil 2 von 2 aus der Artikelserie R Data Frames meistern mit dplyr.

Noch mehr Datenbank-Features

Im ersten Teil dieser Artikel-Serie habe ich die Parallelen zwischen Data Frames in R und Relationen in SQL herausgearbeitet und gezeigt, wie das Paket dplyr eine Reihe von SQL-analogen Operationen auf Data Frames standardisiert und optimiert. In diesem Teil möchte ich nun drei weitere Analogien aufzeigen. Es handelt sich um die

  • Window Functions in dplyr als Entsprechung zu analytischen Funktionen in SQL,
  • Joins zwischen Data Frames als Pendant zu Tabellen-Joins
  • Delegation von Data Frame-Operationen zu einer bestehenden SQL-Datenbank

Window Functions

Im letzten Teil habe ich gezeigt, wie durch die Kombination von group_by() und summarise() im Handumdrehen Aggregate entstehen. Das Verb group_by() schafft dabei, wie der Name schon sagt, eine Gruppierung der Zeilen des Data Frame anhand benannter Schlüssel, die oft ordinaler oder kategorialer Natur sind (z.B. Datum, Produkt oder Mitarbeiter).

Ersetzt man die Aggregation mit summarise() durch die Funktion mutate(), um neue Spalten zu bilden, so ist der Effekt des group_by() weiterhin nutzbar, erzeugt aber „Windows“, also Gruppen von Datensätzen des Data Frames mit gleichen Werten der Gruppierungskriterien. Auf diesen Gruppen können nun mittels mutate() beliebige R-Funktionen angewendet werden. Das Ergebnis ist im Gegensatz zu summarise() keine Verdichtung auf einen Datensatz pro Gruppe, sondern eine Erweiterung jeder einzelnen Zeile um neue Werte. Das soll folgendes Beispiel verdeutlichen:

Das group_by() unterteilt den Data Frame nach den 4 gleichen Werten von a. Innerhalb dieser Gruppen berechnen die beispielsweise eingesetzten Funktionen

  • row_number(): Die laufende Nummer in dieser Gruppe
  • n(): Die Gesamtgröße dieser Gruppe
  • n_distinct(b): Die Anzahl verschiedener Werte von b innerhalb der Gruppe
  • rank(desc(b)): Den Rang innerhalb der selben Gruppe, absteigend nach b geordnet
  • lag(b): Den Wert von b der vorherigen Zeile innerhalb derselben Gruppe
  • lead(b): Analog den Wert von b der folgenden Zeile innerhalb derselben Gruppe
  • mean(b): Den Mittelwert von b innerhalb der Gruppe
  • cumsum(b): Die kumulierte Summe der b-Werte innerhalb der Gruppe.

Wichtig ist hierbei, dass die Anwendung dieser Funktionen nicht dazu führt, dass die ursprüngliche Reihenfolge der Datensätze im Data Frame geändert wird. Hier erweist sich ein wesentlicher Unterschied zwischen Data Frames und Datenbank-Relationen von Vorteil: Die Reihenfolge von Datensätzen in Data Frames ist stabil und definiert. Sie resultiert aus der Abfolge der Elemente auf den Vektoren, die die Data Frames bilden. Im Gegensatz dazu haben Tabellen und Views keine Reihenfolge, auf die man sich beim SELECT verlassen kann. Nur mit der ORDER BY-Klausel über eindeutige Schlüsselwerte erreicht man eine definierte, stabile Reihenfolge der resultierenden Datensätze.

Die Wirkungsweise von Window Functions wird noch besser verständlich, wenn in obiger Abfrage das group_by(a) entfernt wird. Dann wirken alle genannten Funktionen auf der einzigen Gruppe, die existiert, nämlich dem gesamten Data Frame:

Anwendbar sind hierbei sämtliche Funktionen, die auf Vektoren wirken. Diese müssen also wie in unserem Beispiel nicht unbedingt aus dplyr stammen. Allerdings komplettiert das Package die Menge der sinnvoll anwendbaren Funktionen um einige wichtige Elemente wie cumany() oder n_distinct().

Data Frames Hand in Hand…

In relationalen Datenbanken wird häufig angestrebt, das Datenmodell zu normalisieren. Dadurch bekommt man die negativen Folgen von Datenredundanz, wie Inkonsistenzen bei Datenmanipulationen und unnötig große Datenvolumina, in den Griff. Dies geschieht unter anderem dadurch, dass tabellarische Datenbestände aufgetrennt werden Stammdaten- und Faktentabellen. Letztere beziehen sich über Fremdschlüsselspalten auf die Primärschlüssel der Stammdatentabellen. Durch Joins, also Abfragen über mehrere Tabellen und Ausnutzen der Fremdschlüsselbeziehungen, werden die normalisierten Tabellen wieder zu einem fachlich kompletten Resultat denormalisiert.

In den Data Frames von R trifft man dieses Modellierungsmuster aus verschiedenen Gründen weit seltener an als in RDBMS. Dennoch gibt es neben der Normalisierung/Denormalisierung andere Fragestellungen, die sich gut durch Joins beantworten lassen. Neben der Zusammenführung von Beobachtungen unterschiedlicher Quellen anhand charakteristischer Schlüssel sind dies bestimmte Mengenoperationen wie Schnitt- und Differenzmengenbildung.

Die traditionelle R-Funktion für den Join zweier Data Frames lautet merge(). dplyr erweitert den Funktionsumfang dieser Funktion und sorgt für sprechendere Funktionsnamen und Konsistenz mit den anderen Operationen.

Hier ein synthetisches Beispiel:

Nun gilt es, die Verkäufe aus dem Data Frame sales mit den Produkten in products zusammenzuführen und auf Basis von Produkten Bilanzen zu erstellen. Diese Denormalisierung geschieht durch das Verb inner_join() auf zweierlei Art und Weise:

Die Ergebnisse sind bis auf die Reihenfolge der Spalten und der Zeilen identisch. Außerdem ist im einen Fall der gemeinsame Schlüssel der Produkt-Id als prod_id, im anderen Fall als id enthalten. dplyr entfernt also die Spalten-Duplikate der Join-Bedingungen. Letzere wird bei Bedarf im by-Argument der Join-Funktion angegeben. R-Experten erkennen hier einen „Named Vector“, also einen Vektor, bei dem jedes Element einen Namen hat. Diese Syntax verwendet dplyr, um elegant die äquivalenten Spalten zu kennzeichnen. Wird das Argument by weggelassen, so verwendet dplyr im Sinne eines „Natural Join“ automatisch alle Spalten, deren Namen in beiden Data Frames vorkommen.

Natürlich können wir dieses Beispiel mit den anderen Verben erweitern, um z.B. eine Umsatzbilanz pro Produkt zu erreichen:

dplyr bringt insgesamt 6 verschiedene Join-Funktionen mit: Neben dem bereits verwendeten Inner Join gibt es die linksseitigen und rechtsseitigen Outer Joins und den Full Join. Diese entsprechen genau der Funktionalität von SQL-Datenbanken. Daneben gibt es die Funktion semi_join(), die in SQL etwa folgendermaßen ausgedrückt würde:

Das Gegenteil, also ein NOT EXISTS, realisiert die sechste Join-Funktion: anti_join(). Im folgenden Beispiel sollen alle Produkte ausgegeben werden, die noch nie verkauft wurden:

… und in der Datenbank

Wir schon mehrfach betont, hat dplyr eine Reihe von Analogien zu SQL-Operationen auf relationalen Datenbanken. R Data Frames entsprechen Tabellen und Views und die dplyr-Operationen den Bausteinen von SELECT-Statements. Daraus ergibt sich die Möglichkeit, dplyr-Funktionen ohne viel Zutun auf eine bestehende Datenbank und deren Relationen zu deligieren.

Mir fallen folgende Szenarien ein, wo dies sinnvoll erscheint:

  • Die zu verarbeitende Datenmenge ist zu groß für das Memory des Rechners, auf dem R läuft.
  • Die interessierenden Daten liegen bereits als Tabellen und Views auf einer Datenbank vor.
  • Die Datenbank hat Features, wie z.B. Parallelverarbeitung oder Bitmap Indexe, die R nicht hat.

In der aktuellen Version 0.5.0 kann dplyr nativ vier Datenbank-Backends ansprechen: SQLite, MySQL, PostgreSQL und Google BigQuery. Ich vermute, unter der Leserschaft des Data Science Blogs dürfte MySQL (oder der Fork MariaDB) die weiteste Verbreitung haben, weshalb ich die folgenden Beispiele darauf zeige. Allerdings muss man beachten, dass MySQL keine Window Funktionen kennt, was sich 1:1 auf die Funktionalität von dplyr auswirkt.

Im folgenden möchte ich zeigen, wie dplyr sich gegen eine bestehende MySQL-Datenbank verbindet und danach einen bestehenden R Data Frame in eine neue Datenbanktabelle wegspeichert:

Die erste Anweisung verbindet R mit einer bestehenden MySQL-Datenbank. Danach lade ich den Data Frame diamonds aus dem Paket ggplot2. Mit str() wird deutlich, dass drei darin enthaltene Variablen vom Typ Factor sind. Damit dplyr damit arbeiten kann, werden sie mit mutate() in Character-Vektoren gewandelt. Dann erzeugt die Funktion copy_to() auf der MySQL-Datenbank eine leere Tabelle namens diamonds, in die die Datensätze kopiert werden. Danach erhält die Tabelle noch drei Indexe (von dem der erste aus drei Segmenten besteht), und zum Schluß führt dplyr noch ein ANALYSE der Tabelle durch, um die Werteverteilungen auf den Spalten für kostenbasierte Optimierung zu bestimmen.

Meistens aber wird bereits eine bestehende Datenbanktabelle die interessierenden Daten enthalten. In diesem Fall lautet die Funktion zum Erstellen des Delegats tbl():

Die Rückgabewerte von copy_to() und von tbl() sind natürlich keine reinrassigen Data Frames, sondern Objekte, auf die die Operationen von dplyr wirken können, indem sie auf die Datenbank deligiert werden. Im folgenden Beispiel sollen alle Diamanten, die ein Gewicht von mindestens 1 Karat haben, pro Cut, Color und Clarity nach Anzahl und mittlerem Preis bilanziert werden:

Die Definition der Variablen bilanz geschieht dabei komplett ohne Interaktion mit der Datenbank. Erst beim Anzeigen von Daten wird das notwendige SQL ermittelt und auf der DB ausgeführt. Die ersten 10 resultierenden Datensätze werden angezeigt. Mittels der mächtigen Funktion explain() erhalten wir das erzeugte SQL-Kommando und sogar den Ausführungsplan auf der Datenbank. SQL-Kundige werden erkennen, dass die verketteten dplyr-Operationen in verschachtelte SELECT-Statements umgesetzt werden.

Zu guter Letzt sollen aber meistens die Ergebnisse der dplyr-Operationen irgendwie gesichert werden. Hier hat der Benutzer die Wahl, ob die Daten auf der Datenbank in einer neuen Tabelle gespeichert werden sollen oder ob sie komplett nach R transferiert werden sollen. Dies erfolgt mit den Funktionen compute() bzw. collect():

Durch diese beiden Operationen wurde eine neue Datenbanktabelle „t_bilanz“ erzeugt und danach der Inhalt der Bilanz als Data Frame zurück in den R-Interpreter geholt. Damit schließt sich der Kreis.

Fazit

Mit dem Paket dplyr von Hadley Wickham wird die Arbeit mit R Data Frames auf eine neue Ebene gehoben. Die Operationen sind konsistent, vollständig und performant. Durch den Verkettungs-Operator %>% erhalten sie auch bei hoher Komplexität eine intuitive Syntax. Viele Aspekte der Funktionalität lehnen sich an Relationale Datenbanken an, sodass Analysten mit SQL-Kenntnissen rasch viele Operationen auf R Data Frames übertragen können.

Zurück zu R Data Frames meistern mit dplyr – Teil 1.

 

Anne Rozinat & Christian W. Günther

Success Criteria Process Mining

/in /by

Process Mining is much more than the automatic drawing of process models.

Process mining is on the rise. By using Process mining, organizations can see how their processes really operate [1]. The results are amazing new insights about these processes that cannot be obtained in any other way. However, there are a few things that can go wrong. In this article, Frank van Geffen and Anne Rozinat give you tips about the pitfalls and advice that will help you to make your first process mining project as successful as it can be. Read more

Mathias Golombek

Data Science on a large scale – can it be done?

/in , , , , , /by

Analytics drives business

In today’s digital world, data has become the crucial success factor for businesses as they seek to maintain a competitive advantage, and there are numerous examples of how companies have found smart ways of monetizing data and deriving value accordingly.

On the one hand, many companies use data analytics to streamline production lines, optimize marketing channels, minimize logistics costs and improve customer retention rates.  These use cases are often described under the umbrella term of operational BI, where decisions are based on data to improve a company’s internal operations, whether that be a company in the manufacturing industry or an e-commerce platform.

On the other hand, over the last few years, a whole range of new service-oriented companies have popped up whose revenue models wholly depend on data analytics.  These Data-Driven Businesses have contributed largely to the ongoing development of new technologies that make it possible to process and analyze large amounts of data to find the right insights.  The better these technologies are leveraged, the better their value-add and the better for their business success.  Indeed, without data and data analytics, they don’t have a business.

Data Science – hype or has it always been around?Druck

In my opinion, there is too much buzz around the new era of data scientists.  Ten years ago, people simply called it data mining, describing similar skills and methods.  What has actually changed is the fact that businesses are now confronted with new types of data sources such as mobile devices and data-driven applications rather than statistical methodologies.  I described that idea in detail in my recent post Let’s replace the Vs of Big Data with a single D.

But, of course, you cannot deny that the importance of these data crunchers has increased significantly. The art of mining data mountains (or perhaps I should say “diving through data lakes”) to find appropriate insights and models and then find the right answers to urgent, business-critical questions has become very popular these days.

The challenge: Data Science with large volumes?

Michael Stonebraker, winner of the Turing Award 2014, has been quoted as saying: “The change will come when business analysts who work with SQL on large amounts of data give way to data EXASOL Pipelinescientists, which will involve more sophisticated analysis, predictive modeling, regressions and Bayesian classification. That stuff at scale doesn’t work well on anyone’s engine right now. If you want to do complex analytics on big data, you have a big problem right now.”

And if you look at the limitations of existing statistical environments out there using R, Python, Java, Julia and other languages, I think he is absolutely right.  Once the data scientists have to handle larger volumes, the tools are just not powerful and scalable enough.  This results in data sampling or aggregation to make statistical algorithms applicable at all.

A new architecture for “Big Data Science”

We at EXASOL have worked hard to develop a smart solution to respond to this challenge.  Imagine that it is possible to use raw data and intelligent statistical models on very large data sets, directly at the place where the data is stored.  Where the data is processed in-memory to achieve optimal performance, all distributed across a powerful MPP cluster of servers, in an environment where you can now “install” the programming language of your choice.

Sounds far-fetched?  If you are not convinced, then I highly recommend you have a look at our brand-new in-database analytic programming platform, which is deeply integrated in our parallel in-memory engine and extensible through using nearly any programming language and statistical library.

For further information on our approach to big data science, go ahead and download a copy of our technical whitepaper:  Big Data Science – The future of analytics.

Tag Archive for: Business Intelligence

Nothing Found

Sorry, no posts matched your criteria