Frage, die sich stellt, ist diejenige nach der Quelle der Daten. Woher kommen die zu analysierenden Daten und wo und wie werden sie bereitgestellt? Im Folgenden wird auf diese Datenquellen näher eingegangen. Konkret handelt es sich dabei um:
• Flatfiles
• Relationale Datenbanken
• Data-Warehouses
• NoSQL-Datenbanken
• Hadoop
• Cloud-Datenbanken
2.1 Flatfiles
Die einfachste Form der Datenbereitstellung sind Flatfiles, also Tabellen und strukturierte Textdateien, die man aus operativen Systemen wie z. B. ERP-Systemen exportiert oder über Befragungen gewonnen hat. Die Dateien werden in unterschiedlichen Formaten zur Verfügung gestellt. Die gebräuchlichsten sind:
• csv
• xls
• xml
• produktspezifische Formate (SPSS, SAS, Stata, ARFF, DBase …)
Bei dieser Form der Datenanalyse handelt es sich meist nicht um „Big Data“ (auch wenn die Größe der Files grundsätzlich nahezu unbegrenzt sein kann), aber dennoch spielen Flatfiles nach wie vor eine wichtige Rolle in Data-Science-Projekten. Es muss z.B. kein Zugang zur Datenbank eines Produktivsystems eingerichtet werden, was meist einen höheren Aufwand im Bereich Berechtigungen und Netzwerkzugang bedeutet. Stattdessen werden die Daten aus dem Quellsystem exportiert und dann in das Analysesystem eingelesen, wo die eigentliche Analyse bzw. Modellierung stattfindet. Liegt eine sehr hohe Anzahl an Flatfiles vor, bietet es sich an, den Prozess des Einlesens und Zusammenfassen der Daten z. B. durch ein Programm in Python zu automatisieren.
2.2 Relationale Datenbanksysteme
Relationale Datenbanksysteme dienen der Datenverwaltung und beruhen auf einem tabellenbasierten, relationalen Datenbankmodell. Sie werden auch als RDBMS (Relational Database Management System) bezeichnet. Zum Abfragen und Manipulieren der Daten wird überwiegend die Datenbanksprache SQL (Structured Query Language) eingesetzt.
Relationale Datenbanken folgen einem grundsätzlichen Schema. Daten werden in Tabellen gespeichert, wobei die Spalten die Variablen darstellen und die Zeilen die einzelnen Datensätze. Datenbanken werden dadurch „relational“, wenn es Relationen – also Verbindungen – zwischen den Tabellen gibt. Diese werden eingeführt, um eine redundante Speicherung der gleichen Daten zu vermeiden. Damit werden Speicherplatz gespart und inkonsistente Datenhaltung vermieden. Beispielsweise werden bei einer Datenbank für Kunden nicht für jeden einzelnen Kunden die Unternehmensdaten angegeben, sondern die Kategorie Unternehmen wird als eigenständige Tabelle ausgelagert und über eine Relation den einzelnen Kunden zugeordnet. Ändert sich etwas an der Adresse des Unternehmens, muss dies nur an einer Stelle geändert werden – durch die Relation wird den einzelnen Kunden automatisch das entsprechende Unternehmen zugeordnet.
Trotz neuerer Entwicklung (siehe den folgenden Abschnitt) stellen relationale Datenbanken nach wie vor die große Mehrzahl der Datenspeicher in Unternehmen dar und sind zentraler Bestandteil der meisten operativen Anwendungen (ERP, CRM, HCM, SCM, Fachsysteme …).
Die wichtigsten Anbieter sind:
• Oracle (Marktführer nach Umsatz)
• Microsoft SQL Server (Marktführer in bestimmten Märkten und auf bestimmten Plattformen)
• MySQL (Open Source, von Oracle erworben, höchste Anzahl an Implementierungen)
• PostgreSQL (Open Source)
• IBM DB2
• SAP Adaptive Server / SQL Anywhere / SAP MaxDB
• Amazon RDS (Cloud-Angebot für RDBS)
2.3 Data-Warehouse
Ein Data-Warehouse (DW oder DWH) ist eine zentrale Sammlung von Daten, die sich aus verschiedenen Quellen speist und vor allem für den Zweck der Analyse und der betriebswirtschaftlichen Entscheidungshilfe dauerhaft gespeichert wird.
Meistens wird ein Data-Warehouse aus zwei Gründen aufgebaut:
• Es soll eine Integration von Daten aus verteilten und unterschiedlich strukturierten Datenbeständen erfolgen. Im Data-Warehouse können die Daten konsistent gesichtet und datenquellenübergreifend ausgewertet werden. Die zeitaufwendigen und technisch anspruchsvollen Aufgaben der Datenextraktion und -integration aus verschiedenen Systemen erfolgt damit (im Ideal) einmalig und an zentraler Stelle. Die Daten stehen dann für Analysen und Reporting für die Fachabteilungen „konsumbereit“ zur Verfügung.
• Durch eine Trennung der (oft „sensiblen“) Daten in den operativen Systemen von den für das Reporting genutzten Daten im Data-Warehouse soll sichergestellt werden, dass durch die Datenabfragen für Analysen und Reporting keine operativen Systeme „gestört“ werden. Niemand möchte, dass der Azubi in der Vertriebsabteilung durch eine Abfrage der kompletten, weltweiten Produktverkäufe, nach Wochen und Postleitzahl gegliedert, das Buchhaltungssystem für eine halbe Stunde lahmlegt.
Abbildung 1: Quelle: https://www.pmone.com/blog/wiki/data-warehouse/
Technisch gesehen sind Data-Warehouse-Systeme eine Sammlung von Softwarekomponenten, die die Umsetzung des Data-Warehouse-Konzeptes ermöglichen. Sie bestehen aus:
• ETL-Komponenten, die den ETL-Prozess (also die Extraktion, Transformation und das Loading der Daten) unterstützen,
• dem Core-Data-Warehouse, also einer Sammlung von gemanagten Datenbanksystemen, die auf Parallelisierung und Performance für das Handling riesiger Datenmengen optimiert sind,
• den „vorbereiteten“ Aggregationen (Star-Schemas), die Auswertungen beschleunigen.
• einem User Interface, das die Verwaltung und die Auswertung der Datenbestände ermöglicht.
Die wichtigsten Anbieter von Data-Warehouse-Systemen sind:
• Oracle
• Teradata
• Microsoft
• IBM
Data Lake
In letzter Zeit wird immer häufiger der Begriff „Data Lake“ verwendet. Es handelt sich dabei um ein Konzept, das als eine Erweiterung des Data-Warehouse-Gedankens gesehen werden kann, der dann aber technisch mit Hadoop- oder NoSQL-Mitteln umgesetzt wird (siehe die folgenden zwei Abschnitte).
Im Unterschied zum Data-Warehouse, wo die Daten aus verschiedenen Quellen bezogen und dann so aufbereitet werden, dass sie vergleichbar sind und damit aggregiert werden können (ETL-Prozess), werden beim Data Lake die Daten erst einmal im ursprünglichen Format und unbearbeitet gesammelt. Eine Bearbeitung bzw. Transformation der Daten erfolgt dann erst bei Bedarf vor der eigentlichen Analyse (ELT-Prozess).
