Der Rohstoff: Daten

Daten, Informationen und Wissen

Eine Unterscheidung

Das Privatleben der Menschen hat sich durch die neuen Technologien, dem Internet, den Mobiltelefonen, den Tablets und den Apps stark geändert. Man kann Wissen einfach im Internet nachschlagen und braucht keine Stadtpläne, Lexika oder Wörterbücher mehr mühsam aufschlagen und durchsuchen. Was früher ganze Bibliotheken gefüllt hat, passt heute auf einen USB-Stick. Auch Unternehmen haben viele Möglichkeiten gefunden, die neuen Technologien zu nutzen. Viele Unternehmen sind inzwischen informationsverarbeitende „Organismen“. Die meisten Angestellten einer Firma sind nicht mehr die traditionellen physikalischen Arbeiter, sondern Wissensarbeiter. Das meiste Geld in Banken ist heute nur noch im Computer in einer Datenbank „vorhanden“. Bei vielen Produkten, wie z. B. bei Autos, gab es früher nur sehr wenige Ausstattungsmerkmale bei einem Modell. Heute kann man sich sein persönliches fast einzigartiges Auto zusammenstellen und konfigurieren.

Die Ursache dieser Änderungen ist die Möglichkeit, Informationen mit „Computern“ zu verarbeiten und mit Netzen zu übertragen. Mit dem Internet ist das Informations- und Wissenszeitalter den Kinderschuhen entwachsen.

Aber was sind eigentlich Daten? Informationen? Und wo ist der Unterschied zu Wissen?

  • Daten
  • Information
  • Wissen
  • Glauben

Diese Begriffe werden im Alltag oft verwendet, ohne dass man sich über die Bedeutung genau im Klaren ist. Es ist hier für das Buch wichtig, die Begriffe ein wenig genauer zu unterscheiden und zu definieren.

Mit Daten bezeichnet man im allgemeinen Fakten, Werte oder Formeln, die z. B. durch Messung oder Eingabe gewonnen wurden. In der Datenverarbeitung bestehen Daten aus Zeichen oder Symbolen. Daten werden auf Computern in Dateien gespeichert.

Der Inhalt der Daten wird Information genannt. Wie in Abschnitt 5.3 bereits erklärt, gibt es eine präzise Informationstheorie. Es gibt die absolute Information, die angibt wieviel Speicherplatz für die Information benötigt wird. Und es gibt die relative Information, die die Reduzierung der Unsicherheit (Entropie) angibt.

Wissen sind die Informationen, die im Allgemeinen von Menschen als wahr oder gültig angenommen werden. Bei Wissen ist man sich ziemlich sicher, dass es wahr ist. Wissen kann bewiesen werden, entweder durch einen Beweis oder durch ein Experiment. Falls der Beweis noch aussteht, handelt es sich um eine Vermutung oder eine Hypothese. Beim Glauben hingegen wird eine Vermutung ausgedrückt, die noch nicht bewiesen wurde oder gar nicht bewiesen werden kann. Christen berufen sich z. B. darauf, dass sie an einen Gott glauben, gerade weil kein Beweis der Existenz des Gottes existiert.

Wichtig: Daten sind der Container, Information der Inhalt und Wissen die Gesamtheit der „wahren“ Informationen.

Daten können Informationen und nützliches Wissen enthalten. Diese Informationen sind aber aus den Daten herauszulesen bzw. zu interpretieren. Für die vollständige Interpretation einer Information ist oft ein Kontext erforderlich. Eine Nachricht mit dem Inhalt „um 10:30 Uhr“ enthält alleine zu wenig Inhalt. Um sie zu verstehen, muss man die vorherigen Nachrichten kennen, ob es z. B. um ein Treffen an einem bestimmten Ort oder um einen Anruf geht.

Aus diesem Grunde wird mit Hilfe der Datenanalyse versucht, das in Daten enthaltene Wissen zu finden. Die etablierte Technik hierfür war die Statistik, die allerdings nur mit kleineren Datenmengen umgehen konnte. Mit Hilfe von Computern wurden neue Verfahren im Data Mining und dem Machine Learning entwickelt, mit denen auch große Datenmengen verarbeitet werden können. Heute werden diese Techniken unter dem Begriff Data Science zusammengefasst.

Verschiedene Formate

Es gibt verschiedene Arten von Daten. Diese Daten können von Menschen oder von Computern erzeugt und verarbeitet werden. Meistens erkennt man die Art an der Endung der Datei: Urlaub1.jpg ist wohl ein Bild aus dem Urlaub im JPEG-Format und Party3.mp3 ist wohl Party-Musik im MP3-Format. Hier noch ein paar weitere Beispiele für Daten:

  • Textdaten in natürlicher Sprache, wie z. B. Englisch oder Japanisch: *.txt
  • Programmcode in der Programmiersprache Java: *.java
  • Daten von Anwendungen und Apps: Textverarbeitung *.doc, Tabellen-Kalkulationen *.xls
  • Audio: *.mp3, *.flac
  • Fotos, Bilder, Zeichnungen, eingescannte Dokumente: *.png, *.jpg
  • Video / Filme: *.mov, *.mkv
  • Komprimierte Daten: *.zip, *.7z

Es gibt noch unzählige mehr. Jede dieser Dateien besteht technisch aus einer Reihe von Bytes, d.h. Zahlen von 0 bis 255 mit 8-Bit Speicherplatz. Wie diese Reihe von Bytes interpretiert wird, ist von App zu App unterschiedlich und muss von den Programmierern der App implementiert werden. Die gleiche Folge von Bytes hat für eine Textverarbeitung eine andere Bedeutung als für den MP3-Player. Das kann man leicht sehen, wenn man mal eine MP3-Datei mit der Textverarbeitung öffnet, aber vorher sicherheitshalber eine Kopie der Datei machen.

Verschiedene Verwendungszwecke

Man kann Daten anhand ihres Verwendungszwecks in die folgenden Gruppen einteilen:

  • Anwendungs-Daten
  • Operative-Daten
  • Gesetzlich notwendige Daten

Anwendungs-Daten werden von den Anwendern selbst angelegt. Beispiele hierfür sind Dokumente für Textverarbeitungen, MP3-Dateien, Videos, usw.

Operative-Daten werden von der Anwendung oder dem Computersystem erzeugt und zur Fehleranalyse und Systemüberwachung (Monitoring) von System-Betreuern oder von Entwicklern zu Rate gezogen.

  • Logging-Daten
  • Transaktionen einer Datenbank
  • Freier Platz im Speicher zu einem bestimmten Zeitpunkt
  • Auslastung der CPU zu einem bestimmten Zeitpunkt

Die Systemüberwachung (Monitoring) bezieht sich auf das System, nicht auf die Benutzer. Es gibt Software-Systeme, die kritisch für das Funktionieren eines Unternehmens sind. Bei einem Online-Händler z. B. darf die Datenbank mit den Produkten und den Bestellungen nicht ausfallen. Beim Monitoring werden viele Parameter des Systems daraufhin überprüft, ob alles in Ordnung ist. Wie ist die Betriebstemperatur der CPUs? Wieviel Platz ist noch auf den Festplatten? Sind die Systeme überlastet?

Gesetzlich notwendige Daten müssen aufgrund gesetzlicher Anforderungen gespeichert werden. Die berühmtesten Auflagen und Regulierungen sind die folgenden [Cor11]:

  • Sarbanes-Oxley Act für alle Unternehmen, die in an einer Börse in den USA gehandelt werden.
  • Basel II und Basel III für Banken in der EU
  • Umweltschutzauflagen der EU und der World Trade Organization

Basel III und Sarbanes-Oxley schreiben den Banken und Firmen explizit vor, welche Daten sie in welchen Reports wie oft abzuliefern haben. Diese Maßnahmen sollen den Finanzsektor sicherer vor Krisen machen. Wenn eine Regulierung neu eingeführt oder geändert wird, müssen die Unternehmen diese umsetzen und ihre bestehenden Systeme und Arbeitsabläufe ändern. Für Unternehmen und Organisationen bestimmen Datenschutzauflagen genau, welche Daten sie wie lange speichern müssen, dürfen, nicht dürfen, usw. Hier gibt es in unterschiedlichen Ländern unterschiedliche Vorgaben.

Verschiedene Arten

Man kann Daten auch anhand ihres Formats kategorisieren: Textdaten enthalten Texte in Sprachen. Das können natürliche Sprachen sein, wie Englisch oder Japanisch, oder formale Sprachen, wie z. B. Programmiersprachen. Unter Binärdaten versteht man Daten, die erst dekodiert werden müssen. Beispiele hierfür sind Audio-Dateien, Fotos, Bilder, Zeichnungen, eingescannte Dokumente, Videos und Filme.

Textdaten kann man wiederum danach unterscheiden, ob ein sog. „Datenmodell“ dahinterliegt:

  • Strukturiert: die Daten sind anhand eines Datenmodells formatiert
  • Semi-strukturiert: es gibt kein explizites Datenmodell, aber dennoch erkennbare Struktur
  • Unstrukturiert: es ist keine einfache Struktur erkennbar, wie z. B. ein Text in natürlicher Sprache

Strukturierte Daten

Strukturierte Daten hängen von einem Datenmodell ab. Das Standard-Beispiel für strukturierte Daten ist die Tabelle. Die Daten der drei „Planeten“ aus Abschnitt 2.3 könnten in einer Tabelle folgendermaßen aussehen.

Das Format der Daten wird durch das Datenmodell, den sog. Metadaten definiert. Ein Datenmodell gibt vor, wie die Daten auszusehen haben, welche Daten vorhanden sein müssen, welche optional sind, welches Format die Daten haben müssen (Zeichenkette oder Zahl). Ein Datenmodell bestimmt daher die zulässigen Datensätze. Das Datenmodell für die obige Tabelle ist:

  • Color: String
  • Mass: Integer (ein Integer ist ein positive oder negative ganze Zahl 0, 1, 2, …, -1, -2, …)
  • Position: 2D-Vektor mit Integern im Format (Integer, Integer)
  • Velocity: 2D-Vektor mit Integern im Format (Integer, Integer)

Metadaten sind eigentlich Daten über Daten. Wenn jetzt jemand Fremdes die obige Tabelle erhält, wüsste er ohne die Metadaten nicht genau, in welchem Format die Daten sind, welche Werte korrekt und welche falsch sind. Die Metadaten legen das Format der Daten fest (Syntax) und nicht die Bedeutung (Semantik). Was die Daten bedeuten, kann nur ein Mensch mit entsprechendem Fachwissen entscheiden.

CSV, JSON und XML

Für die Speicherung von Tabellen haben sich die folgenden drei Dateiformate etabliert: CSV, JSON und XML.

CSV steht für Comma-seperated-values, also für „durch Komma getrennte Werte“. Das Komma wird leider sehr oft in Daten verwendet, wie z. B. bei den Vektoren in der obigen Tabelle. Daher wird oft das Semikolon als Trennzeichen verwendet: also „durch Semikolon getrennte Werte“, wie z. B. in folgendem Beispiel:

blau;3;(4,1);(2,0)

Die einzelnen Werte „blau“, „3“, „(4,1)“ und „(2,0)“ werden durch ein Semikolon voneinander getrennt. Der Vorteil dieser Darstellung ist die knappe Ausdrucksweise und damit der geringe Speicherplatz. Allerdings werden die Metadaten hier nicht automatisch mitgeliefert, so dass CSV nur semi-strukturiert ist.

Die Programmiersprache JavaScript wird häufig in Web-Browsern eingesetzt, um die Webseiten dynamisch zu machen, den Seiten also „Leben einzuhauchen“. Hier wird zum Speichern das JSON-Format verwendet („JavaScript Object Notation“), in der das Beispiel folgendermaßen aussieht:

{
    "color": "blau",
    "mass": 3,
    "position": "(4,1)",
    "velocity": "(2,0)"
}

Hier werden in jeder Zeile der Name des Attributs, ein Doppelpunkt und der Wert des Attributs aufgeschrieben. Bei JSON gibt es keinen automatischen Mechanismus, der sicherstellt, dass die Datensätze auch über alle vier Attribute „color“, „mass“, „position“ und „velocity“ verfügen und dass diese Attribute die richtigen Werte haben. Also nicht das als „mass“ einfach „sehr groß“ angegeben wird, denn es soll ja eine Zahl sein. Daher ist auch JSON semi-strukturiert.

Im Datenformat XML könnten die Daten folgendermaßen aussehen:

<circle>
    <color>blau</color>
    <mass>3</mass>
    <position>(2, 1)</position>
    <velocity>(2, 0)</velocity>
</circle>

Hier werden die Werte zwischen sog. Tags angegeben. Ein Tag hat einen Start-Tag und einen End-Tag . Bei XML gibt es eine Möglichkeit, die Metadaten explizit zu definieren (XML-Schema). Damit kann XML auch zu den strukturierten Datentypen gehören.

Unstrukturierte Daten

Bei unstrukturierten Daten liegt kein Datenmodell vor mit dem die Daten einfach erkannt werden können. Unstrukturierte Daten kann man weiter in zwei Gruppen aufteilen: sich wiederholende Daten und nicht wiederholend [IL14]. Ein Beispiel für sich wiederholende unstrukturierte Daten sind Log-Meldungen eines Programms. Hier ist ein Auszug aus einem Start von Gephi aus Abschnitt 2.3:

[INFO] Heap memory usage: initial 64,0MB maximum 455,5MB
[INFO] Non heap memory usage: initial 2,4MB maximum -1b
[INFO] Garbage collector: PS Scavenge (Collections=8 Total time spent=0s)
[INFO] Garbage collector: PS MarkSweep (Collections=2 Total time spent=0s)
[INFO] Classes: loaded=5729 total loaded=5729 unloaded 0
[INFO] INFO [org.netbeans.core.ui.warmup.DiagnosticTask]: Total memory 17.076.875.264

Dieses ist eine Mischung aus Struktur, wie bei dem Label INFO und dem Doppelpunkt, der in jeder Zeile vorhanden ist, und natürlicher Sprache.

Die Verarbeitung von Texten in natürlicher Sprache hat sich in den letzten Jahren stark verbessert. Die Sprachverarbeitung ist ein Teilbereich der Künstlichen Intelligenz und wird in Kapitel 8 behandelt.

Daten in der Praxis

Anwendungsdaten in der Telekommunikation

Mobilfunkunternehmen bieten oft unterschiedliche Tarif-Optionen an:

  • Flat-Rate: alles inklusiv
  • Eingeschränkte Anzahl: z. B. 50 SMS umsonst
  • Eingeschränkte Zeitdauer: z. B. 2 Stunden pro Monat frei
  • Ziele eingeschränkt: Anrufe ins eigene Netz frei, andere aber kostenpflichtig

Um am Ende des Monats die Rechnung erstellen zu können, muss sich das Mobilfunkunternehmen merken, wie sich der Kunde verhalten hat. Telekommunikationsunternehmen führen dazu eine Datenbank, in der jedes kostenpflichtige Ereignis eines Benutzers aufgezeichnet wird. Typischerweise werden in einem solchen Datensatz, dem sog. Call Detail Record (CDR), mindestens die folgenden Daten gespeichert:

  1. Quelle (A-Teilnehmer)
  2. Ziel (B-Teilnehmer)
  3. Uhrzeit des Verbindungsbeginns in Sekunden
  4. Dauer der Verbindung in Sekunden
  5. Funkzelle (Cell-ID)
  6. Zone des Ziels (bei Ferngesprächen)
  7. International Mobile Equipment Identity (IMEI) des Quell-Geräts

Wenn Teilnehmer A den Teilnehmer B anruft, werden diese Daten aufgezeichnet und in einer Datenbank gespeichert. Diese Datenbanken unterliegen aufgrund von Datenschutzauflagen natürlich der Geheimhaltungspflicht und sind vom Internet aus durch Hacker nicht erreichbar.

Die Datensätze sehen dann in einer CSV-Datei auf dem Computer z. B. folgendermaßen aus …

01790012345;040123456;121034;105;…
01790012345;0179123456;121402;30;…
01790012345;0300123456;165542;310;…

In diesen Daten sind drei Telefonate enthalten. Diese Daten heißen Verbindungsdaten1. Anhand dieser Datensätze wird dann am Monatsende ermittelt wie viele Anrufe ein Benutzer gemacht hat und wie lange diese insgesamt waren, d.h. die Gesamtdauer. Eine solche Rechnung heißt Aggregation. Man sagt auch, die Daten werden „hoch aggregiert“. Man kann hier auf verschiedenen Niveaus aggregieren: pro Stunde, pro Tag, pro Woche, pro Monat, pro Jahr, usw. Dieses heißt das Aggregationsniveau. Diese aggregierten Daten werden dann zur Rechnungserstellung benutzt. Hierzu muss es allerdings auch eine Datenbank mit der Rechnungsanschrift und den Kontoinformationen geben.

Bei der Strafverfolgung von Kriminellen sind diese Verbindungsdaten nützlich, weil man alle Anrufe eines Verdächtigen ermitteln kann. Daher wurden Telekommunikationsunternehmen dazu angewiesen, diese Daten auf „Vorrat“ zu speichern, falls die Polizei oder ein Geheimdienst diese Daten mal benötigen könnte. Diese Vorratsdatenspeicherung wird mit der Terrorismusbekämpfung begründet und ist sehr umstritten. Befürworter sagen, das die Vorratsdatenspeicherung bei der Aufklärung der Anschläge in Madrid 2004 einen wichtigen Beitrag geleistet hätte, Kritiker sehen das als „Massenüberwachung“ [Shn15].

Problematisch sind an diesen Daten aber nur die Teile mit deren Hilfe man auf die beteiligten Personen zurückschließen kann, also die A- und die B-Nummer oder die IMEI des Mobiltelefons. Daher werden diese oft verschlüsselt.

Die restlichen Daten haben für das Telekommunikationsunternehmen einen immensen Wert. Denn es kann damit z. B. die Auslastung des Netzes berechnen und das Netzwerk optimieren. Welche Mobilfunkzellen werden wann und wie stark benutzt? Welche Zellen müssen verbessert und ausgebaut werden? Welche sind überflüssig? Auch für die Erforschung von Kundenwünschen sind diese Daten nützlich. Wie oft telefonieren sie? Welche Services werden genutzt? Gibt es Angebote, die sie nicht nutzen?

Fehlersuche mit Logging-Daten

Computersysteme laufen unbeaufsichtigt. Man kann nicht für jeden Computer einen Aufpasser haben. Auch sind Menschen nicht schnell genug, um mit einem Computer mitzukommen. Ein Webserver beantwortet tausende von Abfragen pro Sekunde.

Was passiert, wenn das System in einem Unternehmen sich nicht so verhält, wie es soll? Wenn ein Fehler auftritt, wenn es einen Bug hat? Stellen Sie sich vor, ein Kunde ruft an und sagt, ihr System hat sich vor einer halben Stunde nicht so verhalten, wie es sollte. Sie erhalten also einen „Bug-Report“. Üblicherweise gibt es von diesen Bugs so viele, dass man ein eigenes Computersystem zu deren Verwaltung und Bearbeitung hat. Der Kundendienst gibt in dieses System dann den beschriebenen Fehler ein und versieht das „Ticket“ mit einer Priorität. Manche Bugs sind so wichtig, dass die Entwickler alles stehen und liegen lassen und sich direkt um den Bug kümmern sollten. Andere sind allerdings nicht so wichtig, so dass ein Ticket ein paar Tage alt sein kann, wenn ein Entwickler es dann bearbeitet.

Jetzt sieht der Entwickler eine Fehlerbeschreibung wie „Am Mittwoch, den 13.10.2015 um 12:45 wollte der Kunde X seine Daten ändern und da passierte der folgende Fehler …“.

Was tun? Das ist doch schon so lange her. Der Entwickler benötigt eine sog. Historie, in der er nachgucken kann, was zum angegebenen Zeitpunkt gerade los war. Aus diesem Grund hat jedes Computersystem ein Logging-System, mit dem die wichtigen Ereignisse aufgezeichnet werden [CSP12]. Diese Logging-Meldungen werden meistens in Dateien gespeichert. Hier ist ein Beispiel für eine solche Datei:

12:32:08.400 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTING
12:32:08.405 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Waiting until process started: command 'C:\Program Files\Java\jdk1.8.0_65\bin\java.exe'.
12:32:08.411 [DEBUG] [org.gradle.process.internal.DefaultExecHandle] Changing state to: STARTED
12:32:08.418 [INFO] [org.gradle.process.internal.DefaultExecHandle] Successfully started process 'command 'C:\Program Files\Java\jdk1.8.0_65\bin\java.exe''
12:32:08.418 [DEBUG] [org.gradle.process.internal.ExecHandleRunner] waiting until streams are handled...

Hier notiert sich das Programm den genauen Zeitpunkt in Millisekunden und was es da gemacht hat.

Der Entwickler, der die Ursache des Fehlers herausfinden will, muss die Log-Dateien durchgehen, den Zustand des Systems zum Zeitpunkt vor dem Fehler rekonstruieren und die Aktionen des Systems nachverfolgen, die zu dem Fehler geführt haben. Das ist nicht immer einfach. Manchmal sind hier tagelange Analysen und Recherchen notwendig, insbesondere bei komplizierten und umfangreichen Systemen.

In den Logging-Daten werden in der Regel keine Anwendungsdaten gespeichert. Wenn jemand in der Datenbank seine Adresse ändert, dann steht im Log „Habe den Datensatz mit der ID 123 geändert“. Die Daten selber sind da nicht enthalten. Andernfalls wäre das eine große Sicherheitslücke.

Das Logging wird auch zur Überprüfung der Sicherheit eingesetzt. Betriebssysteme und Netzwerke protokollieren z. B. die Anmeldungen der Benutzer. Sog. Intrusion Detection Systeme analysieren diese Log-Dateien ständig und versuchen evtl. Einbrüche von Hackern zu verhindern oder diese jedenfalls so früh wie möglich zu entdecken und Alarm auszulösen.

Die Logging-Daten geben auch Auskunft darüber, welche Feature in einem Programm wie häufig genutzt werden. Software-Hersteller benutzen diese Daten, um ihre Programme zu verbessern.

Daten bei einer Internet-Plattform

Bei einer Internet-Anwendung ist es nicht immer einfach zu bestimmen, wo die Daten jetzt genau liegen. In der Regel liegen sie aber bei der Anwendungs-Firma auf dem Web- oder auf dem Datenbankserver. In der folgenden Abbildung ist eine Verbindung zu einer Web-Seite dargestellt. Der Benutzer A möchte die Seite index.html sehen. Der Browser verbindet sich über das Internet (dargestellt als Wolke) zum Webserver der Firma (Web-Server mit Weltkugel), dargestellt durch die grauen Pfeile. Der Web-Server sucht evtl. noch weitere Daten aus der Datenbank (Server mit „Tonne“, denn Datenbanken werden oft als Tonne dargestellt) und schickt dann die fertige Webseite zurück an den Browser, dargestellt durch die gestrichelten Pfeile. Der Browser des Benutzers stellt die Seite dann dar.

Die Daten befinden sich auf den Servern der Firma und werden durch das Internet geschickt. Während die Daten im Internet unterwegs sind, sind sie von allen „Mithörern“ lesbar, wenn sie nicht verschlüsselt sind. Aus diesem Grund ist es wichtig, möglichst oft eine verschlüsselte Internetverbindung mit https zu verwenden.

Aber die eigentlichen Daten befinden sich auf den Rechnern der Firma. Es hängt dann von den Sicherheitsvorkehrungen der Firma ab, ob die Daten in der Datenbank und auf dem Webserver sicher sind. Diese Situation ist bei Diskussion um Facebook und Google zu berücksichtigen. Kritiker äußerten mal empört „was machen die mit meinen Daten?“ Aber der Kritiker hatte „seine“ Daten auf Rechnern des sozialen Netzwerks gespeichert. Waren es noch „seine“? Er hat die Infrastruktur des Dienstes benutzt. Daten, die man nicht teilen will, sollte man auch nicht in soziale Netze hochladen. Bei Cloud-Speicher ist das hingegen anders: hier hat der Anbieter des Cloud-Speichers dafür zu sorgen, dass die Daten geheim bleiben.

Daten in Unternehmen

Arbeit wird heutzutage anhand von Daten und Prozessen organisiert. In modernen Fabriken wird jeder Fertigungsschritt in einer Datenbank festgehalten. Die Informationstechnik ist ein wichtiger Grundbaustein von Unternehmen. Unternehmen sind informationsverarbeitende Organismen. Typischerweise gibt es in Unternehmen die folgenden Bereiche [Dav14, Cor11]:

  • Marketing: Vermarktung
  • Vertrieb, Sales
  • Manufacturing, Produktion
  • Produktentwicklung, Product Development
  • Einkauf, Purchasing
  • Finanzierung, Finance
  • Personal, Human Resources (HR)
  • Unternehmensführung, Management

Jeder dieser Bereiche benötigt unterschiedliche Daten in evtl. unterschiedlichen Formaten. Es kann z. B. sein, dass Finance eine andere Definition für bestimmte Begriffe verwendet als die Produktion. Was ist z. B. ein „guter Kunde“? Hier ist es bei großen Unternehmen wichtig, die Definitionen und Daten zu vereinheitlichen, ein sog. Metadaten-Management und Stammdaten-Management einzuführen. Diese Daten enthalten einheitliche Definitionen, die für das gesamte Unternehmen gelten.

Die verschiedenen Bereiche eines Unternehmens sind Teilsysteme eines komplexen Systems, denn sie interagieren miteinander und bilden mehrere Netzwerke [Por85]. Um diese komplexen Beziehungen zu beschreiben haben sich die Begriffe Lieferkette („supply chain“) und Wertschöpfungskette („value chain“) etabliert. Leider ist der Begriff „Kette“ nicht gut gewählt, denn eine Kette stellt man sich linear vor. Eine bessere Bezeichnung wäre Liefernetz oder Liefernetzwerk.

Die Lieferkette bzw. die Supply-Chain beschreibt die Prozesse und die Daten, die für die Herstellung und Auslieferung von Produkten erforderlich sind. Sie führt von den Rohstoffen und den Zulieferfirmen bis zu den Endkunden durch das gesamte Unternehmen. Die „Supply-Chain“ ist eine wissenschaftliche Version des Netzwerks, das in der Geschichte „Ich, der Bleistift“ in Abschnitt 5.3 beschrieben wurde.

Viele Unternehmen modellieren nicht nur ihre Produktketten, sondern auch die Dienstleistungs-, Finanz- und Informationsketten [Por85, Cor11]. Bei der Wertschöpfungskette werden auch die Kosten berücksichtigt. Mit Hilfe von Wertschöpfungsketten können Unternehmen analysiert und ihre finanzielle Situation bewertet werden. Für die Optimierung von Prozessen sind solche Wertschöpfungsketten eine große Hilfe.

Für die Datenverarbeitung in Unternehmen haben sich traditionellerweise unterschiedliche Computersysteme entwickelt:

  • Supply Chain Management (SCM)
  • Customer-Relationship Management (CRM)
  • Enterprise Resource Planing (ERP) für Produktentwicklung, Produktion und Inventar

Das Supply Chain Management dient zur computerunterstützen Verwaltung der Lieferketten. Customer-Relationship Management ist die moderne Kundenverwaltung und -pflege. Mit dem Enterprise Resource Planing (ERP) werden die Ressourcen des Unternehmens „gemanaged“, also eine Art modernes Inventar.

Supply-Chain

Der Einsatz von neuer Technologie muss sich für ein gewinnorientiertes Unternehmen finanziell lohnen, d.h. mehr einbringen als die Anschaffung kostet. Daher werden neue Technologien in der Regel zuerst in kostenintensiven Industrien eingesetzt, wie z. B. dem Automobilbau.

Der Mensch hat immer versucht, die Herstellung von Waren zu verbessern. Die heutige Massenherstellung von Waren wurde 1904 von Henry Ford begonnen. Seit dieser Zeit hat man nach Techniken gesucht, die Produktion zu optimieren, d.h. bessere Waren mit weniger Einsatz von Ressourcen und Arbeit herzustellen. Die Forschung zur Verbesserung der „Produktivität“ eines Unternehmens war aber eher „ad hoc“, also nicht systematisch und methodisch. Das änderte in den 80er-Jahren als die „Supply Chain“ eingeführt wurde. Daraufhin begann ein regelrechter Supply-Chain-Boom. Man hatte endlich ein konzeptuelles Werkzeug, mit dem man die Prozesse in den Organisationen ausdrücken konnte [Por85, Cor11]. Das „Denken in Netzwerken“ wurde auf Unternehmen angewendet. Das Management der Supply-Chain ist ein Mittel, um ein Unternehmen zu optimieren, effizienter zu werden und Kosten zu reduzieren.

Heutzutage werden die Supply-Chains auch zwischen den Unternehmen ausgetauscht bzw. gegenseitig ergänzt. Ein Automobilproduzent hat meistens sehr viele Zulieferfirmen. Durch die Kombination der eigenen Supply-Chain mit denen der Zulieferfirmen ist es vielen Automobilproduzenten gelungen, die Lagerzeiten möglichst kurz zu halten und „on-demand“ neue Lieferungen zu erhalten. Mit den sog. „demand-driven supply networks“ ist es heutzutage sogar möglich, Produkte zu „customizen“ und in sehr vielen Varianten anzubieten. Heutzutage kann man sich sein persönliches Auto zusammenstellen, weil die Hersteller durch die Verbesserung der Supply-Chain flexibler geworden sind.

Marketing als Wissenschaft

Die Marketing-Abteilung hat u. a. die folgenden Fragen zu beantworten [Cor11].

  • Kunden: Wer sind die Kunden? Was interessiert sie? Welche Produkte würden sie kaufen? Was würden sie dafür ausgeben? Was stört sie an ihren gekauften Produkten?
  • Konkurrenten: Was macht die Konkurrenz? Welche Produkte bietet sie für welchen Preis? Was für Produkte sind geplant?
  • Märkte und deren Regulierung: Wie sieht die allgemeine wirtschaftliche Lage aus? Werden die Produkte als umweltschädigend gesehen? Welche Maßnahmen sind für Umweltschutz und Recycling notwendig?

Die Unsicherheit (Entropie) der Abteilung ist hoch und daher benötigt sie Informationen, um die Unsicherheit zu reduzieren. Hierzu ist sie auf Daten in hoher Qualität angewiesen. Marketing ist zu einer statistischen Wissenschaft geworden. Die Kundendaten können aus dem CRM übernommen werden. Informationen über Konkurrenten, Märkte oder Haushalte werden oft hinzugekauft. Die vorhandenen Daten werden vom Marketing genauestens untersucht, um Wissen über die Marktsituation des Unternehmens zu gewinnen. Je mehr Informationen ein Unternehmen in diesem Bereich hat, desto kleiner ist die Unsicherheit und desto größer die Wahrscheinlichkeit, dass man die richtigen Entscheidungen trifft und den Kunden die richtigen Produkte anbietet.

Verkauf

Die Verkaufs-Abteilung muss u. a. die folgenden Aufgaben erfüllen [Cor11].

  • Reporting: Erstellung von Berichten über die Verkäufe für das Management
  • Sales Tracking: Anzahl der Verkäufe, wie gut Produkte im Markt aufgenommen werden
  • Trade Promotion: die eigenen Produkte bewerben, z. B. in Supermärkten durch Aufbau eines speziellen Stands oder Werbeaktionen
  • Markenwert: den Ruf der Produkte und des Unternehmens untersuchen
  • Ausgaben für die Werbung und das Marketing bestimmen

Hier sind die Daten zur Analyse oft noch schwieriger zu beschaffen als beim Marketing, weil sie z. B. vor Ort in den Supermärkten anfallen, nicht in einer Datenbank vorhanden sind und nicht zugekauft werden können. Die Daten sind auch sehr unterschiedlich, fallen in hohen Mengen an und benötigen das Internet. Oft werden die Daten auch möglichst zeitnah benötigt, also muss die Verarbeitung möglichst schnell erfolgen. Das ist ein typischer Anwendungsfall für „Big Data“, das in Abschnitt 6.6 beschrieben wird. Mit der Industrie 4.0 und dem Internet der Dinge wird sich hier noch viel ändern. Das Internet der Dinge wird später in Kapitel 10 behandelt.

Prozesse als Daten: BPM

Ein Prozess ist ein Ablauf in der Zeit. Man kann Prozesse dokumentieren, in dem man für jeden Zeitschritt aufschreibt, was man gerade tut. Das bekannteste Beispiel ist wohl das Tagebuch bzw. der Blog. Menschen schreiben täglich auf, was ihnen durch den Kopf geht. Damit kann man auch Jahre später nachlesen, wie es einem ging, an was man dachte, welche Musik man hörte usw. Man hat sein Leben in Daten festgehalten. Man hat ein „Gedächtnis“. In vielen industriellen Prozessen ist es auch wichtig, ein „Gedächtnis“ zu haben. Denn viele Produktionsprozesse in der Industrie werden nicht von Menschen überwacht und auch die Prozesse auf Computern laufen automatisch.

Wie kann man aber diese Prozesse selber beschreiben? Oder speichern? Wie kann man die Abläufe in einer Fabrik dokumentieren und evtl. verbessern?

Hier haben sich Prozess-Modellierungs-Werkzeuge und Prozess-Modellierungs-Sprachen etabliert. Ein Beispiel ist „Business Process Model and Notation“ (BPMN). Mit dieser „Sprache“ können wirtschaftliche Prozesse dargestellt und sogar automatisch ausgeführt werden, sofern eine Ablaufsteuerung vorhanden ist. Man bekommt hierdurch „programmierbare“ Fabriken. In der folgenden Abbildung ist ein einfaches Beispiel für ein BPMN-Diagramm dargestellt2:

Ein BPMN-Diagramm ist ein Netzwerk, also ein Graph. Die Knoten können unterschiedliche Typen haben:

  • Ereignisse („events“): runde Kreise
  • Aktivitäten („activity“): gelbe Rechtecke
  • Gateway: Rauten

Die Kanten haben ebenfalls unterschiedliche Typen:

  • Sequenz: durchgezogene Linie
  • Nachricht: gestrichelte Linie
  • Assoziation (nicht in der Abbildung vorhanden)

Im obigen Diagramm wird jeden Freitagabend um 18 Uhr eine Email versendet, solange die Arbeitsgruppe aktiv ist. Diese Diagramme können in einem Unternehmen natürlich sehr umfangreich und komplex werden.

Unter „Prozessorientierung“ versteht man, dass ein Unternehmen in solchen „Prozessen“ denkt. Viele Unternehmen sind in den letzten 15 Jahren auf eine „prozessorientierte“ Sicht auf ihr Unternehmen umgestiegen. Die Verwaltung dieser Prozesse wird „Business Process Management“ (BPM) genannt [Dav14].

Wichtig: Prozesse sind Daten und Prozesse verarbeiten Daten.

Datenbanken

Verschiedene Arten von Datenbanken

Wenn Daten dauerhaft aufbewahrt werden sollen, dann müssen sie in einer Datenbank oder als Datei gespeichert werden. Im Laufe der Zeit wurden verschiedene Arten von Datenbanken entwickelt [SF12]:

  • Relational (RDBMS)
  • Key-Value
  • Dokumentenorientiert
  • Graph-basiert

Jede Art hat verschiedene Vor- und Nachteile. Welche man benutzt hängt einerseits von der Art der Daten aber auch vom Verwendungszweck und den Anforderungen des Systems ab. Zum Beispiel gehen in einem Online-Store viele Leute gleichzeitig einkaufen. Die Verkaufsabwicklung sollte möglichst schnell sein. Somit muss die Bestellung schnell in der Datenbank gespeichert werden. Wenn das Marketing dieses Online-Stores aber für eine Analyse z. B. die Anzahl der verkauften Turnschuhe im letzten Monat pro PLZ-Gebiet berechnen möchte, weil eine neue Verkaufsstrategie geplant wird, dann kann das evtl. schon ein paar Sekunden dauern und es wird ein großer Teil der Datenbank „durchwühlt“. Das könnte die Datenbank wiederum langsam machen und dann würden die obigen Verkäufe länger dauern und die Kunden würden nicht mehr einkaufen können.

Welchen Typ einer Datenbank man einsetzt, muss daher von Fall zu Fall entschieden werden.

Relational

Die relationalen Datenbanken werden seit den 80ern Jahren entwickelt. Sie waren lange Jahre der Standard. Mit ihnen werden die Daten in Tabellenform gespeichert. Zur genauen Definition der Abfragen und Operationen wird die mathematischen Theorie der Relationen benutzt, daher der Name. Eine Tabelle besteht aus Zeilen und Spalten. Eine Zeile wird auch als Datensatz bezeichnet. Hier z. B. ist die Tabelle aus Abschnitt 2.3 mit den drei „Planeten“ 3:

Zur Interaktion mit dem RDBMS wurde die „Structured Query Language“ (SQL) entwickelt [Dat13]. Hier gibt es Abfragen, mit der man Daten aus einer Tabelle auslesen kann. Die folgende Abfrage ermittelt die Position und die Velocity des grauen Kreises.

SELECT position, velocity FROM kreise WHERE color = ’grau’;

Es gibt auch einen Befehl zum Ändern von Daten.

UPDATE kreise SET position = position + velocity;

Und zum Einfügen von neuen Zeilen.

INSERT INTO kreise VALUES (4, ’orange’, 3, (0,0), (1, 1));

Wie ist das bei gleichzeitigen Änderungen von mehreren Benutzern? Was passiert, wenn zwei Benutzer den gleichen Datensatz ändern wollen? Hierzu wurde das sogenannte ACID-Prinzip erfunden. Die Basis dieses Prinzips ist die sog. Transaktion. Damit ist garantiert, dass Änderungen nacheinander durchgeführt werden und die Datenbank in einem „ordentlichem“ Zustand bleibt.

Jetzt können nicht alle Daten in einer Tabelle oder in einer Datei sein. Die folgende Tabelle hat die gleiche Struktur wie die vorherige, aber unterschiedliche Datensätze. Diese beiden Tabellen können einfach aneinandergehängt werden („append“, „konkateniert“).

Um Daten mit unterschiedlicher Struktur zu verbinden, benötigt man mindestens eine Spalte, mit der man die Datensätze verbinden kann. Die folgende Tabelle heiße „rgbs“.

Dann kann man die erste Tabelle mit dieser anhand der Spalte „Color“ verbinden. Diese Verbindung wird als „Join“ bezeichnet.

SELECT kreise.color, kreise.mass, b.rgb FROM kreise, rgbs WHERE kreise.color = rgbs.color;

Das Ergebnis ist die folgende Tabelle:

Mit einem „Join“ kann man also mehrere Tabellen zusammenfügen.

Um Daten in einer relationalen Datenbank speichern zu können, muss man also alles in Tabellen anordnen, die man evtl. miteinander „joinen“ kann. Relationale Datenbanken funktionieren am besten, wenn die Daten in einer sog. Normalform sind [SF12, Dat13]. Das ist für den Anwender der Datenbank nicht immer praktisch, weil sich z. B. Graphen und Netzwerke nicht immer gut in Tabellen zwängen lassen. Für den Entwickler der Datenbank war es aber einfach, weil eine relationale Datenbank einfach zu implementieren ist.

Bei den heutigen großen Mengen von Daten kann man Datenbanken nicht mehr auf einem einzigen Rechner betreiben, sondern möchte ein sog. verteiltes System benutzen. Ein verteiltes System besteht aus mehreren Computern, die zusammen ein einzelnes System bilden. Diese Verteilung ist aber mit dem ACID-Prinzip nicht vereinbar. Das ACID-Prinzip garantiert, dass gleichzeitige Transaktionen von verschiedenen Benutzern immer ordentlich ablaufen, d.h. „konsistent“ sind. Wenn jetzt auch noch mehrere Computer im Spiel sind, geht das nicht mehr. Eine Datenbank kann nicht gleichzeitig konsistent, hochverfügbar und verteilt sein. Diese Erkenntnis wird das CAP-Theorem genannt [SF12, CM16].

Diese Einschränkungen haben zu der Entwicklung von anderen Typen von Datenbanken geführt, die oft auch als NoSQL-Datenbanken bezeichnet werden.

Key-Value

Für manche Anwendungsgebiete sind Tabellen viel zu kompliziert. Man braucht nur eine Art Notizzettel auf dem man sich schnell mal ein paar Werte notiert. Diese Anforderung erfüllen die Key-Value-Datenbanken. Ein Key-Value-Store verfügt im wesentlich nur über eine PUT-Methode, mit der neue Daten geschrieben werden können und eine GET-Methode, mit der Daten gelesen werden können. In der folgenden Beispielsession werden die Daten eines der drei „Planeten“ geschrieben.

C:\>bin\voldemort-shell.bat test tcp://localhost:6789
Established connection to test via tcp://localhost:6789
> put "u:color" "blau"
> put "u:mass" "3"
> put "u:position" "(2, 1)"
> put "u:velocity" "(2,0)"
> get "u:color"
version(0:1) ts:1447771236296: "blau"
> 

Zuerst werden die Daten mit „put“ geschrieben und mit „get“ wird die Farbe ermittelt. Sehr simpel und rudimentär, aber dafür ist die Verarbeitungsgeschwindigkeit sehr viel höher als bei einer relationalen Datenbank. Im Beispiel wird Project Voldemort verwendet4.

Dokumentenorientiert

Für andere Anwendungen wiederum sind Tabellen zu simpel. Dieses betrifft insbesondere Daten, die „ineinander geschachtelt“ sind. Viele Daten befinden sich bereits im JSON- und XML-Format. Da wäre es doch praktisch diese Dokumente direkt zu speichern ohne sie in eine Tabellenform zu überführen. In Abschnitt 6.2 hatten wir schon ein einfaches Beispiel in JSON gesehen. In der Realität sind JSON-Dokumente aber „geschachtelt“: ein Attribut kann wiederrum ein komplexes JSON-Dokument als Element haben. Da wäre es kontraproduktiv diese Daten in Tabellen „quetschen“ zu wollen.

Wir hatten bei den Daten in JSON ein bisschen gemogelt, den die Position und die Velocity hatten wir als Zeichenketten „(4,1)“ und „(2,0)“ gespeichert. Der Computer denkt es wäre Text und weiß nicht, dass es sich um einen Vektor handelt.

{"color":"blau","mass":3,"position":"(4,1)","velocity":"(2,0)"}

Das können wir ändern, in dem wir jetzt mit den geschweiften Klammern ein „Unterdokument“ einfügen:

{
    "color": "blau",
    "mass": 3,
    "position": { "x": 4, "y": 1 },
    "velocity": { "x": 2, "y": 9 }
}

Nach „positition“ folgt ein „Unterdokument“, das wiederum die Attribute „x“ und „y“ enthält.

Als Datenbank verwenden wir Apache CouchDB5. Das Low-Level-API ist HTTP und das Einfügen eines Kreises geschieht folgendermaßen auf der Kommandozeile:

curl -H 'Content-type: application/json' -X POST http://127.0.0.1:5984/model -d '{ "color": "blau", "mass": 3, "position": { "x": 2, "y": 1 }, "velocity": { "x": 2, "y": 0 } }'

Das sieht komplizierter aus, als es ist: mit -H wird der Inhalt des Dokuments angegeben, in diesem Fall ist es „application/json“, mit -X wird gesagt, dass die Nachricht gespeichert werden soll „POST“ und das Dokument selber wird mit -d angegeben. Aber es gibt auch eine Web-Oberfläche. Die Abfrage von CouchDB geschieht anhand des MapReduce-Frameworks. In folgendem Screenshot wird das Ergebnis einer Beispielsabfrage gezeigt.

Die Abfrage-Funktion ist im oberen Fenster links in JavaScript angegeben. Unten in den gelb unterlegten Fenstern sind die drei Kugeln in der Antwort zu sehen. Man kann also direkt auf die x- und y-Koordinaten der geschachtelten Elemente zugreifen mit „doc.position.x“ bzw. „doc.velocity.y“.

Graph-basiert

Auch Graphen lassen sich nur schlecht mit relationalen Datenbanken verarbeiten. Man müsste eine Tabelle für die Knoten und eine Tabelle für die Kanten haben. Hier sind sehr viele Joins notwendig. Daher wurden in den letzten Jahren Graph-Datenbanken entwickelt. Dieses stellen höhere Anforderungen an die Rechenkapazität und den Speicher, benötigen also neuere Rechner, sind aber wesentlich einfacher zu programmieren.

Wir verwenden die Graph-Datenbank Neo4J6 von der es eine „Community-Edition“ gibt, die jeder verwenden kann. Als Beispiel verwenden wir das Beispiel für ein soziales Netz aus Abschnitt 2.3, das die Personen Anton, Berta, Charlie und Dennis und die Städte Berlin und Köln enthält. Die Sprache von Neo4J heißt Cypher und den Graphen kann man mit dem folgenden Statement erstellen.

CREATE
    (A:Person {name: 'Anton'}),
    (B:Person {name: 'Berta'}),
    (C:Person {name: 'Charlie'}),
    (D:Person {name: 'Dennis'}),
    (K:Stadt {name: 'Köln'}),
    (Be:Stadt {name: 'Berlin'}),
    (A)-[:KNOWS]->(B),
    (A)-[:KNOWS]->(C),
    (B)-[:KNOWS]->(A),
    (B)-[:KNOWS]->(C),
    (B)-[:KNOWS]->(D),
    (C)-[:KNOWS]->(A),
    (C)-[:KNOWS]->(B),
    (D)-[:KNOWS]->(B),
    (A)-[:LIVES_IN]->(K)-[:LIVES_IN]->(A),
    (C)-[:LIVES_IN]->(K)-[:LIVES_IN]->(C),
    (B)-[:LIVES_IN]->(Be)-[:LIVES_IN]->(B)

In den ersten Zeilen werden die Knoten angelegt. Die Knoten haben zwei verschiedene Typen Person und Stadt. Daraufhin werden die Knoten mit Kanten verbunden nach dem Schema (Quelle)-[Kantentyp]->(Ziel).

Auch Neo4J verfügt über eine Web-Oberfläche, die den Graphen automatisch zeichnen kann.

Die Abfrage geschieht ein wenig anders als bei SQL. Hier muss man eine neue Abfragesprache lernen. Die benutzte Abfrage …

MATCH (n) RETURN n LIMIT 25

… gibt einfach die ersten 25 Knoten und ihre Kanten zurück. Man kann auch anhand eines Attributs wie dem Namen suchen.

MATCH (p:Person) WHERE p.name = 'Berta' RETURN p

Diese Abfrage gibt nur den einen Knoten für Berta zurück.

Die folgende Abfrage gibt alle Personen zurück, die Anton kennt, nämlich Berta und Charlie:

MATCH (p:Person)-[:KNOWS]->(q) WHERE p.name = 'Anton' RETURN q

Man kann auch kompliziertere Abfragen stellen, wie z. B. „Wer kennt jemanden in Köln?“

MATCH (k:Stadt { name: "Köln"}), p-[:KNOWS]->(q)-[:LIVES_IN]->(k) RETURN p,q

Wer sich weiter mit Graph-Datenbanken beschäftigen möchte, dem sei das Buch „Graph Databases“ von Ian Robinson et al. empfohlen [RWE15].

Das Data-Warehouse

Im Abschnitt 6.2 wurde erklärt, dass es verschiedene Systeme für die unterschiedlichen Abteilungen in den Unternehmen gibt: CRM, SCM, ERP. Für ein Unternehmen ist es aber wichtig, dass es einen zentralen Punkt gibt, an dem alle wichtigen Daten einheitlich gespeichert werden:

  • Daten müssen konsistent sein: gleiche Bezeichnungen, Taxonomien und Definitionen
  • Ein Ort der Wahrheit: wenn mehrere Datenbanken vorhanden sind und sich Werte unterscheiden, hat das Unternehmen ein Problem.

Daher ist es in Unternehmen wichtig, eine Datenbank zu haben, in der alle für das Unternehmen wichtige Daten vorhanden sind. Diese Datenbank wird Data-Warehouse (DWH) genannt. Das Data-Warehouse ist das Zentralorgan eines Unternehmens. Hier befinden sich Informationen zum Zustand des Unternehmens von allen Unternehmensbereichen. Hierzu müssen die Daten aus den einzelnen Systemen, CRM, ERP, usw. in das DWH importiert werden. In der folgenden Abbildung ist der Befüllungsprozess des Data-Warehouse (DWH) vereinfacht abgebildet:

In der Realität gibt es meistens sehr viel mehr als nur die drei im Diagramm dargestellten Systeme: CRM, ERP und SCM. In großen Firmen sind es hunderte bis tausende. Der Grund liegt in den vielen verschiedenen Anwendungen, Web-Services und Micro-Services, die in einem Unternehmen eingesetzt werden. Die meisten von diesen Diensten werden ein eigenes Datenformat haben und unterschiedliche Standards befolgen. Speicherort der Daten ist bei einem Data Warehouse meistens eine relationale Datenbank oder ein verteiltes Dateisystem mit Hadoop. Der Vorteil von Hadoop ist, dass es auch semi-strukturierte und unstrukturierte Daten speichern kann [Dav14].

Wichtig für die Einheitlichkeit des Reportings sind unternehmensweite Stammdaten („master data“). Hier werden alle im Unternehmen benutze Definitionen und Taxonomien gepflegt. Die Metadaten definierten das Format, den Datentyp und den Inhalt der Daten, d.h. der Tabellen und Dateien. Manchmal werden auch die ETL-Prozesse selber als Metadaten gespeichert. Dass ist zur Analyse der Herkunft („provenance“, „lineage“) der Daten wichtig. Denn falls im DWH fehlerhafte Daten entdeckt werden, ist es wichtig, den Fehler in die Quellsysteme zurückverfolgen zu können, um den Fehler dort zu beheben. Da Informationen ein wichtiges Gut in einem Unternehmen sind, ist es auch wichtig, sich über die Qualität und über die Vertrauenswürdigkeit der Daten im Klaren zu sein. Ein großer Teil der Arbeit an einem DWH liegt darin, die Daten aneinander anzupassen und die Qualität sicherzustellen. Es gibt hier das Sprichwort „Garbage in, garbage out“ [IL14, CM16].

Im ETL-Prozess sind hier die folgenden Schritte zu berücksichtigen [IL14, Ols02]:

  • Datenintegration: Entferne Inkonsistenzen, Eingabefehler, falsche Werte, fehlende Werte
  • Datenpflege: Vereinheitliche Taxonomien, Benutzereingaben
  • Aggregation: Hochrechnen von Daten auf Tages, Monats, Quartals oder Jahresebene
  • Anreicherung: Z. B. mit zugekauften Daten
  • Komprimierung: Entfernen von Spalten oder Werte-Reduktion („Binning“)
  • Aktualisierung der Metadaten

Business Intelligence

Das DWH ist die Grundlage für alle Informationen im Unternehmen. Die Analyse der Daten ist für Unternehmen sehr wichtig, so dass manche Unternehmen inzwischen einen Chief Analytics Officer (CAO) haben, der für die Datenanalyse zuständig ist [Dav14, IL14]. Hierbei ist zu berücksichtigen, dass jede Unternehmensabteilung eine unterschiedliche Sicht auf die Daten hat, sie anders interpretiert. Die Finanzabteilung eines Telekommunikationsunternehmens wird eine andere Sicht auf die technische Infrastruktur haben, weil sie sich nur für die Kosten interessiert. Die technische Abteilung aber interessiert sich für die Details, welche technische Standards die Geräte implementieren, usw. Aus diesem Grund gibt es sogenannte „Data Marts“ , die spezifisch für jede Abteilung sind. In der folgenden Abbildung sind als Beispiel zwei Data Marts für Sales und Marketing abgebildet.

Das DWH, die Data Marts und oft auch Hadoop dienen als Grundlage für die „Konsumenten“ des DWHs. Es gibt unterschiedliche Arten von Nutzern: Das Management möchte über den Status des Unternehmens informiert werden. Hier gibt es meistens vorgefertigte Berichte („reports“) mit Key-Performance-Indikatoren (KPIs), die nur abgerufen werden müssen oder zu gewissen Zeiten automatisch erstellt und per Email zugesendet werden. Die Produktentwickler und die Data Scientists hingegen, suchen in den Daten nach neuen Erkenntnissen oder nach Möglichkeiten, neue Reports zu erstellen.

Die Aufgaben sind also (stark vereinfacht) zusammengefasst:

  • Reporting und Berichtswesen
  • Datenanalyse: Ad hoc Abfragen, Dashboards
  • Data Science, Data Mining
  • Daten-Exploration: Erkundung der Daten, was gibt es denn eigentlich? Was könnte man machen?
  • Visualisierung von Daten

Wie man sieht, ist das „Intelligence“ in „Business Intelligence“ nicht unbedingt mit der deutschen “Intelligenz“ also „Klugheit“ zu übersetzen, sondern eher mit „Informationssammlung“, wie bei der amerikanischen „Central Intelligence Agency“ (CIA).

Big Data

Wie das mit vielen technischen Entwicklungen so ist, steigen mit dem Fortschritt auch die Ansprüche. Während früher die Unternehmen zufrieden waren, wenn sie wöchentlich die aktuellen Daten hatten, musste es dann täglich, dann stündlich und heute am liebsten in Echtzeit sein. Auch wurde ein großer Teil der in der Industrie anfallenden Daten nicht analysiert, weil sie unstrukturiert oder nur semi-strukturiert waren [Dav14]. Viele Unternehmen wollen diese Daten aber im DWH haben. Die Ansprüche sind gestiegen und man muss die bisherige Architektur des Data-Warehouse an die neuen Anforderungen anpassen. Und diese neue Technik heißt „Big Data“.

Was macht jetzt aus einem traditionellen DWH-System ein Big-Data-System?

Hier gibt es unterschiedliche Meinungen, in der Regel aber hat man sich auf die 3 V’s geeinigt [Dav14, CM16, Kri13]:

  • Volume (Volumen): Die Menge an Daten muss so groß sein, dass sie nicht mehr auf einem einzelnen Rechner verarbeitet werden kann.
  • Variety (Abwechslung): Die Daten müssen unterschiedliche Formate haben, also semi-strukturiert bzw. unstrukturiert sein.
  • Velocity (Geschwindigkeit): Eine sofortige Verarbeitung ist wünschenswert.

Diese neuen „V“-Anforderungen erfordern jedoch meistens Änderungen am Aufbau des DWH, der ETL-Prozesse und am Betrieb.

Die erste Anforderung „Volume“ führte zur Benutzung von verteilten Systemen. Denn die Daten wurden zu groß, um sie auf nur einem Server zu verarbeiten. Man musste die Daten und die Berechnungen auf mehrere Server verteilen.

Die zweite Anforderung „Variety“ kann unter Umständen hohen Arbeitsaufwand und damit hohe Kosten bedeuten. Semi-Strukturierte Daten können sehr schlecht zu analysieren sein. Audio-Daten müssen in Textform umgewandelt werden. Die automatisierte Erkennung von Videos ist noch nicht weit genug entwickelt. Texte in natürlicher Sprache erfordern ein NLP-Verarbeitung. Die letzten beiden Techniken sind zum jetzigen Zeitpunkt oft noch Forschungsgegenstand und (noch) nicht immer automatisierbar. Eine ordentliche Integration in ein bestehendes DWH erfordert auch Datensäuberungen, Anpassungen an die Stammdaten usw.

Das dritte „V“, die „Velocity“, soll dazu dienen, dass die Daten möglichst schnell analysiert werden können. Dazu ist allerdings manchmal das bisherige DWH zu erweitern und z. B. ein „Speed Layer“ in der sog. Lambda-Architektur einzuführen [MW15]. Man braucht jetzt eine kontinuierliche Verarbeitung der Daten.

Big Data ist also eine Technik mit der mehr Daten und unstrukturierte Daten in einer höheren Geschwindigkeit als vorher verarbeitet werden können. Das klingt auf der einen Seite einfach, ist aber auf der technischen Seite schon kompliziert.

Jetzt gibt es aber sehr viele Bücher, die vor den Gefahren von Big Data warnen. Wo ist denn jetzt die Gefahr? Big Data an sich ist genauso ungefährlich wie eine Datenbank an sich. Mögliche Gefahren liegen darin, wer diese Technik zu welchem Zweck einsetzt.

  1. In den Medien wurden die Verbindungsdaten im Rahmen der NSA-Affäre um Edward Snowden öfters mal „Metadaten“ genannt, was aber eigentlich nicht korrekt ist.

  2. Siehe https://en.wikipedia.org/wiki/File:BPMN-AProcesswithNormalFlow.svg

  3. Diese Darstellung ist ein wenig vereinfacht, weil es die Vektoren (2,1), (2, 0) in SQL so direkt nicht gibt.

  4. http://www.project-voldemort.com

  5. http://couchdb.apache.org/

  6. http://neo4j.com

Kaufen

Unterstützen Sie den Autor, indem Sie das Buch oder das E-Book kaufen:

Diskutieren