QUIZ - Texte for Gecko Kapitel 2 light.docx PDF

**WOHIN MIT ALL DEN DATEN?** **"Im 21. Jahrhundert ist die Datenbank der Marktplatz. "** --- Stan Rapp Im letzten Kapitel haben wir uns angesehen, wie umfangreich die Datenmengen sind, die Unternehmen heute erheben. Dabei steigt die Zahl an Datenpunkten, die gesammelt werden, schon bei Kleinbetrie...

**WOHIN MIT ALL DEN DATEN?** **"Im 21. Jahrhundert ist die Datenbank der Marktplatz. "** --- Stan Rapp Im letzten Kapitel haben wir uns angesehen, wie umfangreich die Datenmengen sind, die Unternehmen heute erheben. Dabei steigt die Zahl an Datenpunkten, die gesammelt werden, schon bei Kleinbetrieben schnell in die Tausende, bei Großunternehmen leicht in die Hunderttausende und bei Einsatz von Big Data sogar in die Millionen. Nun stellt sich die Gretchenfrage: Wo geben wir diese Daten hin, damit sie sicher sind und wir sie später ohne Probleme wiederfinden können? Diese zentrale Frage des Datenmanagements beschäftigte schon unsere Vorfahren in der Steinzeit, die sich dafür entschieden, ihre Daten auf Höhlenwänden zu verewigen. Später, zum Beispiel im antiken China und Ägypten, folgten Einträge auf Papyrusrollen und auf Gebäuden. Seit der Erfindung der Gutenberg-Presse speichern wir Daten durch den Buchdruck auf Papier. Und spätestens seit der Einrichtung der ersten Buchhaltungsabteilungen legen wir Daten in schmucklosen grauen Ordnern ab. Der neueste Datenableger in dieser historischen Entwicklung ist die Datenbank. Die Datenbank ist unser ‚digitaler Ordner", der es uns ermöglicht, Informationen nicht nur zu speichern, sondern auch schnell und effizient wieder aufzurufen. In diesem Kapitel widmen wir uns d.h. den Hauptfragen „**Was ist eine Datenbank?**" und „**Wie funktionieren Datenbanken?**" **OHNE DATENBANK WÄRE ES NICHT MOGLICH,...** Die Datenbank ist das Herzstück des modernen Datenmanagements. Ohne Datenbank wäre es unter anderem nicht möglich,... - \... alle Kundendaten zentral und schnell zugänglich zu machen\ (z.B. Kundenkontaktinfos auf einen Klick). - \... Bestände und Bestellungen effizient und fehlerfrei zu verwalten\ (z.B. automatische Nachbestellung bei niedrigem Lagerstand). - \... Markttrends und Entwicklungen frühzeitig zu erkennen\ (z.B. neue Produktkategorien einführen). - \... auf Kundenanfragen schnell und fundiert zu reagieren\ (z.B. sofortige Verfügbarkeitsprüfung für Produkte). - \... Verkaufsdaten in Echtzeit zu analysieren und sofort zu reagieren (z.B. Blitzangebote basierend auf Verkaufstrends). - \... das Lieferkettenmanagement durch genaue Daten zu optimieren (z.B. präzise Lieferzeitvorhersagen).\ \... fundierte Entscheidungen auf Basis historischer Daten zu treffen (z.B. langfristige Geschäftsstrategien entwickeln). - \... Marketing zielgruppengenau und effektiv zu optimieren\ (z.B. personalisierte E-Mail-Kampagnen). - \... Ressourcen basierend auf präzisen Datenanalysen\ zu optimieren (z.B. gezielte Investitionen in erfolgreiche Produktlinien).\ \... Personalverwaltung und -planung zentral und effizient durchzuführen (z.B. schneller Zugriff auf Mitarbeiter-qualifikationen). - \... Risiken durch Analyse historischer Daten effektiv\ zu managen (z.B. durch die Erkennung von Betrugsmustern). - \... eine effektive Kontrolle über Budgets und Finanzplanung zu haben (z.B. Kostenüberwachung in Echtzeit). - \... Betrugsfälle durch Monitoring ungewöhnlicher Aktivitäten zu minimieren (z.B. automatische Alerts bei auffälligen Transaktionen). - \... gesetzliche Vorschriften effizient und korrekt einzuhalten\ (z.B. automatisierte Datenschutzkonformität). - \... Datenintegrität und -sicherheit umfassend zu gewährleisten\ (z.B. verschlüsselte Speicherung sensibler Daten). - \... Routinetätigkeiten wie Berichte automatisiert zu erstellen\ (z.B. monatliche Umsatzberichte ohne manuellen Aufwand). - \... Kundenprobleme schnell und effizient zu lösen (z.B. direkte Bearbeitung von Reklamationen). - \... Geschäftsprozesse effizient zu skalieren (z.B. schnelle Anpassung an Markt-veränderungen). **WELCHE ARTEN VON DATENBANKEN GIBT ES?** Eine Datenbank ist eine [systematisch organisierte Sammlung von Daten, die so strukturiert ist, dass sie schnell durchsucht, abgefragt, aktualisiert und verwaltet werden kann]. Allerdings gibt es nicht nur ‚die eine, einzige' Art von Datenbank. Vielmehr werden Datenbanken in verschiedenen Formen und Größen angeboten. Die Wahl der richtigen Datenbank hängt stark von den spezifischen Anforderungen eines Unternehmens oder Projekts ab. Nachstehend finden Sie Infos zu den aktuellen Grund-Datenbankarten: - **RELATIONALE DATENBANKEN (bzw. ‚MYSQL DATENBANKEN')** - **NOSQL-DATENBANKEN** - **OBJEKTORIENTIERTE DATENBANKEN** - **GRAPHENDATENBANKEN** - **VERTEILTE DATENBANKEN** **DATENMODELLIERUNG: KEIN HAUS OHNE BAUPLAN** **Stellen Sie sich vor, Sie bauen ein Haus. Sie würden nicht einfach anfangen, Ziegel auf Ziegel zu stapeln, ohne einen Plan zu haben, oder? Genauso ist es mit relationalen Datenbanken: Sie können eine Datenbank nicht einfach \"aus dem Bauch heraus\" erstellen -- zumindest keine Gute! Bevor überhaupt der erste Datensatz gespeichert wird, benötigen Sie [einen klaren Plan]. Das ist das Datenmodell.** **Datenmodellierung ist [der Prozess, bei dem dieses Datenmodell erstellt wird]. Es ist vergleichbar mit dem Entwurf eines Bauplans, bevor das eigentliche Haus gebaut wird. Dabei legen Sie fest, (1) welche Daten Sie speichern möchten, (2) wie diese Daten miteinander in Beziehung stehen und (3) welche Regeln für die Daten gelten sollen. Das Ergebnis ist eine strukturierte Übersicht in Form von Tabellen, Attributen und Beziehungen, die zusammen das Fundament Ihrer Datenbank bilden. Häufig wird bei relationalen Datenbanken das Entity-Relationship-Modell verwendet: ein Modellierungstool, das Sie in diesem Kapitel noch kennenlernen werden.** **Ohne diese sorgfältige Planung könnten später gehörige Probleme bei der Nutzung Ihrer Datenbank auftreten. Daher ist es entscheidend, [sich die Zeit für die Datenmodellierung zu nehmen] und so die Weichen für eine robuste Datenbank zu stellen.** **WAS IST EIN ENTITY-RELATIONSHIP-DIAGRAMM?** Wie an anderer Stelle in diesem Kapitel erwähnt, benötigt jede relationale Datenbank einen „Bauplan" in Form eines Datenmodells. Als Modellierungstool wird hierfür häufig **das Entity-Relationship-Modell verwendet.** Bleiben wir beim Bauplan-Vergleich. Ein **Entity-Relationship-Diagramm (ERD)** ist ähnlich wie der Bauplan für ein Haus, nur dass es für den Aufbau einer relationalen Datenbank verwendet wird. Es hilft dabei, die verschiedenen \"Räume\" festzulegen (hier als ‚**Entitäten**' bezeichnet, also z.B. Kunden oder Produkte) und es visualisiert, wie diese miteinander verbunden sind (durch Beziehungen, wie z.B. „ein Kunde kauft ein Produkt"). Ein Entity-Relationship-Diagramm ist essenziell, um zu verstehen, [wie die Daten in einer Datenbank organisiert sind und wie sie miteinander in Verbindung stehen]. Übrigens: jede Entität muss ein Attribut einhalten, das der Datenbank später ermöglicht, jeden Datensatz eindeutig zu erkennen. Solche Attribute, nennt man \"**Schlüsselattribute**\" (bzw. \"**Primary Key Attributes**\"). Picture 4 **VOM DATENLAGERHAUS ZUM DATENSEE** Wie wir im nächsten Kapitel sehen werden, besteht ein entscheidender Grund für modernes Datenmanagement darin, Strategien auf Basis von Business Intelligence (BI) zu entwickeln. Diese BI-Aktivitäten umfassen den Einsatz von Software zur Analyse großer Mengen an rohen, historischen Daten. Die Software erkennt Muster und Trends in diesen Daten und teilt ihre Erkenntnisse -- und manchmal sogar Empfehlungen -- mit Führungskräften. Diese können daraufhin eine datenbasierte Strategie entwickeln. Traditionelle relationale Datenbanken sind jedoch nicht ideal geeignet, um die großen Datenmengen zu bewältigen, die für eine effektive Business Intelligence benötigt werden. Aus diesem Grund richten Organisationen oft ein Data Warehouse ein. Ein **Data Warehouse** ist ebenfalls eine [Datenbank], wurde aber mit dem Hauptzweck entwickelt, [große Mengen an historischen (z.B. Unternehmens-)Daten zu analysieren]. Die Vorteile eines Data Warehouses im Vergleich zu einer „normalen" relationalen Datenbank sind: - **Leistung:** Data Warehouses sind darauf ausgelegt, komplexe, datenintensive Abfragen zu bewältigen, die viel Zeit in Anspruch nehmen können. - **Skalierbarkeit:** Data Warehouses können problemlos „erweitert" werden, um große Datenmengen und Benutzeranfragen zu verarbeiten. - **Datenintegration:** Data Warehouses sind darauf ausgelegt, Daten aus mehreren (internen und externen) Quellen zu integrieren. - **Datenqualität:** Data Warehouses verwenden Datenbereinigungs- und Transformationsprozesse, um die Datenqualität und -konsistenz zu gewährleisten. Zum Beispiel könnte ein Unternehmen ein Data Warehouse verwenden, um Verkaufsdaten aus verschiedenen regionalen Filialen zu sammeln und zu analysieren. Diese Analysen könnten Trends aufzeigen, wie bestimmte Produkte in verschiedenen Regionen zu unterschiedlichen Jahreszeiten verkauft werden, was den Managern helfen würde, zukünftige Marketingstrategien und Lagerbestände besser zu planen. Ein ebenso wesentlicher Trend des Datenmanagements ist das Aufkommen des **Data Lakes**. Ein Data Lake ähnelt in vielen Aspekten einem Data Warehouse. In beiden Fällen nutzen Organisationen diese Systeme, um [große Mengen an Daten zu sammeln]. Der Zweck eines Data Lakes unterscheidet sich jedoch grundlegend von dem eines Data Warehouses. Während Data Warehouses speziell dafür geschaffen werden, damit Führungskräfte Business Intelligence-Analysen durchführen können (d.h. die Analyse großer historischer Datenmengen, um strategische Entscheidungen zu treffen), sind Data Lakes viel „[experimenteller]" in ihrer Zielsetzung: Ein Data Lake [bezieht seine Daten aus vielen verschiedenen Quellen, wie zum Beispiel sozialen Medien, Webseiten, mobilen Apps, IoT-Geräten und Sensoren, Gesundheitsakten, öffentlichen Regierungsdaten und Unternehmensdatenbanken]. Diese Quellen liefern dem Data Lake [massive Mengen an rohen, unstrukturierten Daten]. Diese Daten werden anschließend mit Hilfe von KI-basierter Software gereinigt und gefiltert. Danach werden die Daten durch künstliche Intelligenz analysiert, um neue Erkenntnisse zu gewinnen und zu lernen. Zum Beispiel könnte ein Einzelhandelsunternehmen durch die Analyse von Daten aus sozialen Medien und Kundenfeedback schnell aufkommende Trends erkennen und sein Produktangebot entsprechend anpassen. Ein Gesundheitsunternehmen könnte durch die Analyse von Patientendaten und externen Gesundheitsberichten bessere Behandlungsmethoden entwickeln oder die Ausbreitung von Krankheiten vorhersagen. Dieser Lernprozess ist viel offener als bei Business Intelligence-Analysen (also bei Data Warehouses). In einem Data Lake gibt es keine automatische Regel, dass die KI nur Dinge lernen darf, die direkt die Geschäftsstrategie beeinflussen. Zusammenfassend: - Stellen Sie sich vor, ein Data Warehouse ist wie ein gut sortiertes Archiv, das speziell dafür eingerichtet wurde, um auf Basis von historischen Daten Antworten auf gezielte Fragestellungen zu liefern. - Im Gegensatz dazu ist ein Data Lake ist wie eine riesige, dynamische Bibliothek, die ständig neue Informationen aus verschiedensten Quellen erhält und wo spezielle Algorithmen ständig nach neuen Erkenntnissen suchen, ohne dass sie genau wissen, was sie am Ende finden werden. +-----------------------------------+-----------------------------------+ | **DATA WAREHOUSE** | **DATA LAKE** | | | | |  | | +===================================+===================================+ | **Strukturiert** | **Roh** | | | | | Data Warehouse enthalten stark | Data Lakes enthalten | | strukturierte Daten, die | unstrukturierte, | | bereinigt, vorverarbeitet und | halbstrukturierte und | | verfeinert wurden. Diese Daten | strukturierte Daten mit minimaler | | werden für sehr spezifische | Verarbeitung. Diese Daten | | Anwendungsfälle wie Business | entstehen typischerweise durch | | Intelligence gespeichert. | das Internet of Things (IoT) oder | | | Online-Medien. | | **Viele Daten** | | | | **Noch wesentlich MEHR Daten** | | Data Warehouse enthalten Daten in | | | der Größenordnung von Terabytes. | Data Lakes enthalten riesige | | Um die Qualität der Daten und den | Datenmengen in der Größenordnung | | Zustand des Data Warehouse | von Petabytes. Da die Daten in | | aufrechtzuerhalten, müssen sie | beliebiger Form und Größe | | regelmäßig Bereinigt werden. | vorliegen können, können große | | | Mengen unstrukturierter Daten | | **Relational** | unbegrenzt gespeichert und nur | | | bei Bedarf bereinigt werden. | | Data Warehouse enthalten | | | historische relationale Daten, | **Unbestimmt** | | wie z.B. Transaktionen, | | | Ergebnisse, Kennzahlen, usw. | Daten in Data Lakes können für | | | eine Vielzahl von Anwendungen | | | genutzt werden, z. B. für | | | maschinelles Lernen, | | | Streaming-Analysen und KI. | +-----------------------------------+-----------------------------------+ \-\-\-\-\-\-- DB 1 **WAS IST EINE DATENBANK** Sie haben also die letzten drei Stunden damit verbracht, die beste Drehbuchidee zu schreiben, die Sie je hatten. Der ganze Text steht jetzt auf Ihrem Bildschirm. Aber was passiert, wenn Sie den Computer ausschalten? Oder wenn bei einem Stromausfall der Strom auch nur für eine Minute ausfällt? Wird Ihr Drehbuch noch da sein, wenn Sie Ihren Computer neu starten? Ich denke, wir alle kennen die Antwort darauf. Die meisten von uns haben es auf die harte Art gelernt: Wenn Sie Ihre Daten nach dem Herunterfahren Ihres Computers weiterverwenden wollen, müssen Sie diese irgendwo dauerhaft speichern. Wir haben dies unzählige Male getan, indem wir unsere Daten auf der Festplatte unseres PCs speicherten. Oder auf einem USB-Stick. Oder in der Cloud. Das sind großartige Lösungen für Privatpersonen. Aber sind sie auch ideal für Organisationen? Nehmen wir einmal an, Sie haben einen eigenen Bürobereich in Ihrem Unternehmen und stellen dort einen kleinen privaten Kühlschrank auf, um Ihre Smoothies und Snacks zu kühlen - solange Sie der Einzige sind, der ihn benutzt, ist alles in Ordnung. Aber was ist, wenn Ihr gesamtes Büro davon erfährt und plötzlich alle anderen denken, dass es eine tolle Idee ist, auch IHRE Snacks und Smoothies in Ihrem Kühlschrank zu lagern? Plötzlich ist der \"kleine private Kühlschrank\", keine so tolle Lösung mehr, wenn JEDER Zugang dazu hat, denn: **-** die Leute werden Sie ständig fragen, ob Sie ihnen ihre Smoothies bringen können, oder **-** die Leute jedes Mal den ganzen Weg zu Ihrem Büro laufen müssen, wenn sie ihre Snacks haben wollen, oder **-** die Leute werden ihre Snacks ständig vertauschen, weil der Kühlschrank klein und unorganisiert ist. Was Sie brauchen, ist ein [Gemeinschaftskühlschrank]. Vorzugsweise an einem zentralen Ort und mit einem Schloss, zu dem nur die Mitarbeiter, die Anspruch auf die Snacks haben, einen Schlüssel erhalten. Auf diese Weise kann jeder, der etwas aus dem Kühlschrank haben möchte, einfach zum Kühlschrank gehen, ihn aufschließen und sich das Gewünschte aus einem deutlich gekennzeichneten Regal holen. Wenn es um die effiziente Speicherung und den Zugriff auf DATEN geht, wäre das Äquivalent zu einem Gemeinschaftskühlschrank eine DATENBANK. Und im Gegensatz zu einem Gemeinschaftskühlschrank bleibt alles, was in einer Datenbank gespeichert ist, auf unbestimmte Zeit für jeden verfügbar, und kann von einer unendlichen Anzahl von Nutzern abgerufen werden - sogar gleichzeitig. Wir wissen, wie wir die Lebensmittel in unserem eigenen Kühlschrank am besten organisieren, aber wie organisieren wir Daten in einer Datenbank? Wenn alle Daten in Ihrer Datenbank strukturiert und zentral gespeichert werden (wie Lebensmittel in den Regalen eines Kühlschranks), sprechen wir von einer **relationalen Datenbank**. Sie haben schon mit Tabellenkalkulationsprogrammen wie Excel gearbeitet. Wenn Sie eine neue Excel-Datei öffnen, sehen Sie als erstes eine leere Tabelle. Diese Tabelle besteht aus einer endlosen Anzahl von Spalten und Zeilen. Diese Spalten und Zeilen sind in einzelne Zellen aufgeteilt, in die Sie Daten eingeben. Für einfache Aufgaben reicht normalerweise eine Tabelle aus. Aber manchmal möchten Sie vielleicht Ihre Daten auf mehrere Tabellen aufteilen. In Excel ist das ganz einfach. Wenn Sie auf ein Arbeitsblattregister am unteren Rand des Fensters klicken, können Sie ein anderes Arbeitsblatt - oder eine andere Tabelle - aufrufen. Und noch eine. Und noch eine. Relationale Datenbanken sind nicht genau dasselbe wie Spalten und Zeilen in Excel, aber sie haben viele Gemeinsamkeiten. Im nächsten Video werden wir uns genauer ansehen, wie sie aufgebaut sind. DB 2 **RELATIONALE DATENBANKEN** Wie im vorigen Video erläutert, weist die Struktur von relationalen Datenbanken viele Ähnlichkeiten mit Excel-Tabellen auf. Schauen wir uns jetzt die in Datenbanken verwendeten Tabellen genauer an: Bei relationalen Datenbanken basiert die Struktur auf Tabellen. Genau wie in Excel kann man in einer solchen Datenbank nur eine einzige Tabelle haben. Die meisten Unternehmen haben jedoch weit mehr als nur eine Tabelle - sie unterteilen ihre Daten in der Regel in Kategorien, oder Tabellen, wie z. B. \"Kundendaten\", \"Auftragsdaten\", \"Lieferantendaten\", \"Bestandsdaten\", \"Mitarbeiterdaten\", \"Produktdaten\" usw., die jeweils in einer eigenen Tabelle gespeichert sind. Schauen wir uns an, wie relationale Datenbanktabellen aufgebaut sind: Eine Tabelle in einer relationalen Datenbank ist in Zeilen und Spalten unterteilt. Jede **Zeile** in einer Datenbanktabelle stellt einen einzelnen **Datensatz** (oder eine \"Instanz\") von miteinander verbundenen Daten dar. Jede **Spalte** in einer Datenbanktabelle steht für eine bestimmte Art von Informationen, die gespeichert werden sollen. Lassen Sie uns dies anhand eines Beispiels verdeutlichen: Ein Unternehmen möchte verschiedene Kundendaten speichern. Es erstellt in der Datenbank eine neue Tabelle mit dem Namen \"Kundendaten\". In dieser Tabelle werden die folgenden Spalten erstellt: \"Vorname\", \"Nachname\", \"Adresse\" und \"Telefonnummer\". Jetzt wird ein neuer Datensatz oder eine Zeile für einen Kunden eingegeben. Die Daten in diesem Datensatz sind \"Max\", \"Meier\", die Adresse und die Telefonnummer. Wie Sie sich vorstellen können, gibt eine Organisation für jeden ihrer Kunden Datensätze oder Zeilen ein. Aber Organisationen können Hunderttausende von Kunden haben - können Sie sich da ein mögliches Problem vorstellen? Ganz genau. Was ist, wenn ZWEI Kunden Max Meier heißen, beide unter derselben Adresse wohnen und beide dieselbe Telefonnummer haben? Vielleicht, weil sie Zwillinge mit - seien wir ehrlich - sehr, sehr unkreativen Eltern sind. Und sie leben zusammen, und teilen sich ein Telefon. Wie kann eine Organisation in einem solchen Fall auf den \"richtigen\" Max Meier zugreifen? Es gibt eine Lösung für dieses Problem, und sie ist Bestandteil jeder Tabelle in jeder relationalen Datenbank. Die Organisation erstellt eine Spalte in der Tabelle, die als **Primärschlüssel** dient. Jedes Mal, wenn ein Datensatz eingegeben wird, eine weitere Information (normalerweise eine Zahl, die sich für jede neue Zeile um 1 erhöht) hinzugefügt. Auf diese Weise kann jede Zeile immer eindeutig identifiziert werden. Auch bei zwei Max Meiers. Eine Spalte in jeder Tabelle ist immer für einen Primärschlüssel reserviert , der den Benutzern ermöglicht, auf jede Dateninstanz einzeln zuzugreifen, selbst wenn mehrere Dateninstanzen identische Informationen enthalten. Werfen wir einen Blick auf eine solche Kundentabelle: (Animation) Sobald eine Datenbanktabelle eingerichtet ist, ist die Eingabe von Datensätzen in diese Tabelle so einfach wie die Eingabe von Werten iin Excel. Genauso einfach ist es, auf Datensätze zuzugreifen, sie zu ändern und zu löschen. All dies können die Benutzer mit Hilfe einer Software tun, die als **Datenbankverwaltungssystem** bezeichnet wird. Die meisten Datenbankverwaltungssysteme basieren auf einer einfachen Programmiersprache, die speziell für die Arbeit mit relationalen Datenbanken entwickelt wurde: **SQL**. SQL steht für \"**Structured Query Language**\", oder „**strukturierte Abfragesprache**", und wie der Name schon sagt, \"funktioniert\" SQL nur, weil die Daten in relationalen Datenbanken sehr strukturiert gespeichert sind - in Tabellen, Spalten und Zeilen. Aus diesem Grund bezeichnen wir die Daten in einer relationalen Datenbank als \"**strukturierte Daten**\". DB 3 **NICHT-RELATIONALE DATENBANKEN** Datenwissenschaftlern zufolge wird das weltweite Datenvolumen im Jahr 2025 voraussichtlich 175 Zettabyte erreichen. Das ist genug Platz für etwa 43 Milliarden Filme, also bringen Sie auf jeden Fall reichlich Popcorn mit. Wie wirkt sich aber diese ständig steigende Datenmenge, auch „Big Data" genannt, auf Datenbanken aus? Relationale Datenbanken, die wir bisher besprochen haben, eignen sich sehr gut für die Verarbeitung kleinerer, gut strukturierter Datenmengen. Wenn ein Unternehmen nur Daten speichern möchte, die sich z. B. auf Mitarbeiter- und Kundendaten, Lagerbestände usw. beziehen, dann ist eine relationale Datenbank die ideale Lösung. Immer mehr Unternehmen wollen - oder müssen - jedoch weitaus mehr Daten speichern. Für AI - Künstliche Intelligenz -- ist ein Zugriff auf riesige Datenmengen essenziell. Das „Internet of Things" generiert ebenfalls eine Flut von Daten. Jedes Unternehmen, das digitale Geräte herstellt oder die von diesen Geräten erzeugten Daten nutzt, muss diese Daten irgendwo speichern: aus strategischen, betrieblichen und rechtlichen Gründen. [Die Quintessenz ist:] Die Unternehmen müssen all diese riesigen Datenmengen irgendwie speichern. Relationale Datenbanken eignen sich hervorragend für die Verarbeitung kleinerer Datenmengen, die gut strukturiert sind. Das Problem ist, dass Big Data weder \"klein\" noch \"gut strukturiert\" ist. Und sobald es zu viele Daten gibt, leiden relationale Datenbanken unter vielen Problemen: Leistung, Geschwindigkeit, Kosten und Datenkompatibilität. Aus diesem Grund ist eine neue Art von Datenbank für „Big Data\" entstanden: die \"NoSQL-Datenbank\". NoSQL-Datenbanken, oder \"nicht-relationale Datenbanken\" wurden entwickelt, um sehr große Mengen unstrukturierter Daten zu verarbeiten, d. h. Daten, die aus vielen verschiedenen Quellen stammen und noch nicht sauber in Tabellen, Spalten und Zeilen aufgeteilt wurden. Perfekt für Big Data. Der erste große Unterschied zu relationalen Datenbanken besteht darin, dass NoSQL-Datenbanken NICHT auf einem festen Strukturtyp basieren. Das bedeutet, dass Sie die Art der Daten, die gespeichert werden sollen, nicht durch die Erstellung von Tabellen \"vordefinieren\" müssen. Schauen wir uns ein Beispiel an: Ein Unternehmen möchte die folgenden Daten in einer Datenbank speichern: Kundin 1 möchte ihre Produkte immer an ihre Privatadresse geliefert bekommen. Das Unternehmen kennt ihren Vornamen, ihren Nachnamen, ihre Lieferadresse und ihre Telefonnummer. Außerdem verfügt es über eine Audiodatei mit einer beruhigenden Melodie, die der Zusteller bei jeder Lieferung abspielen muss, um die aufgeregte Katze der Kundin zu beruhigen. Kunde 2 kauft seine Produkte immer direkt in der Filiale. Das Unternehmen kennt seinen Nachnamen, seine E-Mail-Adresse und seine Einkaufspräferenzen im Geschäft. Es verfügt auch über eine Bilddatei mit einem Foto des Kunden, um ihn leichter zu erkennen. Mit Ausnahme des Nachnamens sind die Daten, die dem Unternehmen pro Kunde vorliegen, völlig unterschiedlich. Zu den betroffenen Datentypen gehören Buchstaben, Zahlen, Audio und Bilder. Wenn das Unternehmen eine Tabelle mit vordefinierten Spalten anlegt - wie in einer relationalen Datenbank - dann bleiben 80 % der Datensatzfelder pro Kunde leer. Bei einer nicht-relationalen Datenbank hingegen werden die Daten pro Kunde so hinzugefügt, dass sie nicht in eine vordefinierte Struktur passen müssen. Und wenn die Daten eines zukünftigen Kunden 3 zufällig ein Video und einen akademischen Abschluss enthalten, kann auch DAS flexibel hinzugefügt werden. Der zweite große Unterschied zwischen NoSQL-Datenbanken und relationalen Datenbanken besteht darin, dass die Daten normalerweise nicht auf einem einzigen Server gespeichert werden. Stattdessen werden sie aufgeteilt und auf vielen Servern in der ganzen Welt gespeichert. Dies wird als \"Sharding\" bezeichnet. Beim Sharding sind alle Server weiterhin miteinander verbunden, so dass die Benutzer, die Daten abrufen oder speichern, nicht einmal merken, dass ihre Datenbank \"aufgeteilt\" wurde. Wie Sie weiter unten sehen werden, bietet der dezentrale Ansatz von NoSQL viele Vorteile, wie z. B.: Skalierbarkeit, Geschwindigkeit, Kosteneffizienz und Sicherheit. Zusammenfassend lässt sich also sagen, dass relationale Datenbanken die richtige Wahl sind, wenn ein Unternehmen nur eine Datenbank benötigt, um relativ einfache Daten zu speichern, z. B. Mitarbeiterdaten, Kundendaten, Verkaufstransaktionen, Inventar usw. Aber für jedes Unternehmen, das sich in die Welt von Big Data und des „Internet of Things" wagt, ist eine NoSQL-Datenbank notwendig, um die vorhandene relationale Datenbank zu ersetzen, oder zumindest zu ergänzen. Was ist datenmaodell **WAS IST EIGENTLICH EIN DATENMODELL?** Datenmodelle bilden die Grundlage dafür, wie Unternehmen ihre Daten organisieren und nutzen, um bessere Entscheidungen zu treffen. Beginnen wir daher mit der logischen Frage: Was IST eigentlich ein Datenmodell? Ein Datenmodell ist wie eine ANLEITUNG, die uns hilft, Daten zu sortieren und anzuzeigen. Oder -- hochschulgerechter formuliert -- „Ein Datenmodell ist eine strukturierte Methode, um Daten zu definieren, zu organisieren und darzustellen." Ein kurzes Beispiel, damit Sie das besser verstehen: Stellen Sie sich vor, Sie haben eine große Auswahl an Kleidung und Modeartikeln und möchten diese sinnvoll sortieren. Wenn Sie ein DATENmodell dafür festlegen, dann würde Sie schon VORAB entscheiden, ob Sie Ihre Kleidungsstücke nach ART ordnen -- also zum Beispiel Hosen, T-Shirts, Schuhe -- oder vielleicht nach ANLASS -- also FREIZeit, Geschäft, Party. Oder vielleicht sogar nach FARBE -- also grün, blau, oder STAGES-lilla. Sie würden im Voraus auch festlegen, welche INFORMATIONEN über jedes Kleidungsstück angezeigt werden sollen, wie etwa die GRÖßE, das MateriAL oder vielleicht die PFLEGEhinweise. So wird aus einem unübersichtlichen Kleiderschrank eine strukturierte und gut organisierte Garderobe, die Sie leicht durchsuchen können, um genau das Outfit zu finden, das Sie zur Abschlussprüfung tragen möchten. Besonders wichtig sind für uns zwei Haupttypen von Datenmodellen: das logische und das PHYSISCHE Datenmodell. Das logische Datenmodell beschreibt die Daten und ihre Beziehungen aus einer geschäftlichen Perspektive. Hier geht es nicht um die technischen Details, sondern um das Verständnis, welche Informationen das Unternehmen benötigt und wie diese zusammenhängen. Zum Beispiel: In einem Unternehmen, das Kundendaten verwaltet, könnte ein logisches Datenmodell die Informationen wie Namen, Adressen, Bestellhistorie und Zahlungsmodalitäten sammeln und in Beziehung setzen, um Marketingkampagnen und Kundenservice zu optimieren. Dadurch könnte später analysiert wird, welche Kunden bestimmte Produkte sehr häufig kaufen und - darauf basierend -- genau DIESEN Kunden gezielte Werbeaktionen oder Rabatte anbieten. Das PHYSISCHE Datenmodell beschreibt dagegen, wie diese Daten tatsächlich in der Datenbank gespeichert werden. Als Beispiel: In einer eCommerce-Plattform könnten alle Produktdaten in einer Tabelle gespeichert werden, die vier Spalten für „Produkt-ID", „Beschreibung", „Preis" und „Lagerbestand" enthält. Für SIE als Zielgruppe Betriebswirte ist natürlich das LOGISCHE Modell relevanter, da es dort ja eher um IHREN Kernbereich geht: also der Entscheidung, welche Daten für spätere Geschäftsentscheidungen überhaupt releVANT sind. Trotzdem ist es für eine Führungskraft im 21. Jahrhundert auch essenziell, zu verstehen, wie diese Daten dann später in einer Datenbank repräsentiert werden -- also, wie das PHYSISCHE Datenmodell aussehen wird. Wenn Sie das nämlich NICHT verstehen, dann werden Sie mit Ihren IT-Mitarbeitenden und Zulieferbetrieben erstens NIE auf Augenhöhe kommunizieren können -- Die IT-ler können Ihnen dann quasi zu den Plan-Daten eines CRM- oder ERP-Systems erzählen, whatever they want, und SIE als kommerzielle Führungskraft haben keinen Schimmer, wovon die eigentlich REDEN. Und außerdem: NUR, wenn Sie ein Grundverständnis haben, wie physische Datenmodelle funktionieren, können Sie während des Planungsprozesses überhaupt erkennen, ob die IT SIE richtig verstanden hat und das anlegt, was SIE sich eigentlich vorstellen. Genau so oft, wie SIE als BWL-Fachkraft oft nicht verstehen, was die IT da gerade geredet, kommt es nämlich vor, dass eine IT-Fachkraft nicht versteht, was WIR Betriebswirte da gerade reden. Und deshalb MUSS eine BWL-Führungskraft des 21. Jahrhunderts AUCH in der Lage sein, die Qualität und die Integrität des Datenmodells, das das HERZSTÜCK ihrer tausenden späteren Entscheidungen sein wird, von Anfang an kompetent zu beurteilen. Betrachten Sie dieses Eintauchen in Datenbanken und physische Datenmodelle daher als eine Art „Dialogschulung zwischen Fachbereichen", bei der SIE als BWL-Fachkraft erstens lernen, sich auf eine Weise auszudrücken, die für die IT möglichst eindeutig ist und zweitens lernen, die Architektur und den Datenbestand einer Datenbank SO einschätzen zu können, dass Sie sich dazu eine qualifizierte Meinung bilden können. Data lake **VON DER RELATIONALEN DATENBANK ZUM NON-RELATIONALEN DATA LAKE?** Am Anfang, da war die relationale Datenbank. Die relationale Datenbank ist quasi die Vorarlberger-Version der Datenbanken -- ordentlich, strukturiert, präzise, und zuverlässig in der Verwaltung einer überschaubare Datenmenge. In einer relationalen Datenbank werden Daten in Tabellen organisiert und durch Beziehungen- also durch „RelaTIONEN" -- miteinander verbunden. Für Ihr Verständnis: der Aufbau einer relationalen Datenbank unterscheidet sich nicht SO gewaltig vom Aufbau jener Arbeitsmappen, die Sie in der Spreadsheet-Software ExCEL -- unter Fachexperten der DACH-Region durchaus auch als EXcel bekannt -verwenden. Relationale Datenbanken sind top, wenn es darum geht, strukturierte Daten zu verwalten, die einem klaren Schema folgen und bei denen die Beziehungen ZWISCHEN den Daten von vornherein ziemlich eindeutig festegelegt werden können. Typische Beispiele im Geschäftsleben sind Buchhaltungssysteme, Kundenbeziehungsmanagement -- also CRM - Lagerverwaltungssysteme, Auftragsabwicklungssysteme oder auch Personalverwaltungssysteme. In all diesen Fällen handelt es sich um eine -- RELATIV -- kleine Datenmenge, und die Beziehungen zwischen den Daten sind auch recht klar. Relationale Datenbanken haben aber auch ihre Grenzen, und auf die stoßen wir rasch, wenn es sich um eine sehr GROSSE Menge an Daten handelt, die noch dazu unstrukturiert ist. Zum Beispiel wenn täglich Millionen Instagram-Posts analysiert werden müssen. Oder wenn RIESIGE Mengen an Videoinhalten gespeichert und verarbeitet werden sollen. Jetzt könnte man sagen: das ist vielleicht für oder für eine Social Media Analyseagentur oder für Netflix relevant, aber für mich in meinem Mittelbetrieb ist das eGAL. Wir werden immer nur mit der ERSTEN Kategorie zu tun haben - also mit jenen kleinen, eindeutigen Datenmengen, die wir in einem Personalverwaltungssystem oder einem Lagerverwaltunssystem finden. Bis zu einem GEWISSEN Grad stimmt das auch. Kleinunternehmen und auch mittelgroße Organisationen fahren auch weiterhin mit Relationalen Datenbanken sehr gut. Aber bedenken Sie einmal folgende Szenarien: Es könnte ja sein, dass Ihr Unternehmen im E-Commerce tätig ist und Sie Ihre Kundenbewertungen und das Produktfeedback vorerst einmal möglichst unstrukturiert -- also OHNE fixe Zuordnung zu einer bestimmten Spaltenkategorie wie „Bewertungstext" oder „Feedback-Typ" -- abspeichern wollen, damit Sie diese Daten später möglichst flexibel und sogar experimentell analysieren können. Oder: Sie betreiben ein kleines Restaurant, und möchten ihre Online-Speisekarte möglichst LAUFEND und flexibel auf Basis von gesammelten Daten zu Kundenwünschen und Markttrends anpassen. Oder: Sie sind ein kleiner Reiseveranstalter und möchten laufend anhand verschiedenster Datenarten wie Texte, Bilder und Videos, die Sie online finden, aktuelle Reisetrends analysieren und daraus per KI maßgeschneiderte Angebote entwickeln. DAZU eignen sich nicht-relationale Datenbanken - auch bekannt als NoSQL-Datenbanken - wesentlich besser. BLEIBEN wir beim Beispiel des kleinen Reiseveranstalters. Eine dort tätige Marketing-Führungskraft könnte Texte, Bilder oder Videos, die sie für relevant hält, in der Datenbank abspeichern -- völlig willkürlich und ohne sich vorab auf eine bestimmte Datenstruktur festzulegen. Die Führungskraft könnte das sogar SO automatisieren, dass nicht sie SELBST, sondern eine KI laufend bestimmte Online-Quellen nach relevantem Content durchsucht und diesen in die Datenbank einspeist. Während die RELATIONALE Datenbank nämlich mit dem Arbeitsblatt einer Spreadsheet-Software vergleichbar ist, ähnelt eine NICHT-relationale Datenbank eher einem riesigen, chaotischen Zettelkasten. Diese Daten müssen bereinigt und vorverarbeitet werden. DANN aber wählt die Marketing-Führungskraft eine KI-gestützte Analysesoftware, die diese Daten durchforstet und DARAUS maßgeschneiderte Reiseangebote ableitet, die haargenau auf die individuellen Präferenzen eines jeden Kunden zugeschnitten sind. Wir sehen also: auch Kleinunternehmen können aus nicht-relationalen Datenbanken enormen Nutzen ziehen. In Zusammenhang mit relationalen und nicht-relationalen Datenbanken möchte ich als letztes die beiden Datenmanagement-Systeme „Data Warehouse" und „Data Lake" ansprechen. Wie der englisch Begriff „Warehouse" schon andeutet, ist ein Data Warehouse ein virtuelles Lagerhaus für die historischen Daten Ihrer Organisation. In Ihrer Organisation wird es einige Abteilungen geben, und jede dieser Abteilungen sammelt verschiedene Arten von Informationen. Das Data Warehouse sammelt all diese Informationen zentral. Ein Data Warehouse beruht im Regelfall auf einer relationalen Datenbank. Der wesentliche Unterschied zu einer REGULÄREN relationalen Datenbank liegt im Zweck. Ein Data Warehouse ist nicht für die tägliche Datenverarbeitung gedacht, sondern ist primär dazu da, damit Sie BERICHTE erstellen, ANALYSEN durchführen und -- vor allem - strategische GESCHÄFTSENTSCHEIDUNGEN treffen können. Deshalb enthält ein Data Warehouse in der Regel auch wesentlich mehr Daten als eine für das Tagesgeschäft konzipierte Datenbank. Es enthält historische Daten, die über einen längeren Zeitraum gesammelt wurden, was ja für Trendanalysen und historische Vergleiche wichtig ist. Demgegenüber liegt die Datenpriorität bei regulären relationalen Datenbanken auf den aktuellen, sich oft schnell ändernden Daten, die Du für das Tagesgeschäft benötigst. Während der Data Warehouse in der Regel eben auf einer relatioNALEN Datenbank, basiert, basiert der Data LAKE auf einer NICHT-relationalen Datenbank. Ein Data Lake enthält eine RIESIGE Menge an Daten, also VIEL, viel mehr als ein Data Warehouse. Wenn der Data Warehouse „Österreich" ist, dann ist der Data Lake quasi „China". Diese vielen Daten werden in der Regel nicht manuell eingespeist, sondern automatisiert aus Quellen wie Sensoren, IoT-Geräten (Internet der Dinge), Online-Transaktionen, oder Social-Media-Feeds übernommen. Stellen Sie sich das wie einen riesigen Staubsauger vor, der einfach ständig Rohdaten ansaugt. Dabei ist es völlig egal, ob es sich um Textdateien, Bilder, Videos oder sonstige Datentypen handelt -- es wird einfach einmal unstrukturiert geSAMMELT. Anschließend benutzt die Organisation, die den Data Lake angelegt hat, Big Data- und Machine Learning Technologien, um besser zu verstehen, was Kunden wirklich WOLLEN und dementsprechend die Marketingstrategie anzupassen. Oder um zu Erkennen, wie man eigene Prozesse schneller und kostengünstiger durchführen könnte. Oder, um völlig neue Produkte, Dienstleistungen und sogar Geschäftsmodelle zu entwickeln. Zusammenfassend sehen wir also: Datenbanken bilden das Rückgrat Ihrer Dateninfrastruktur -- und deshalb sehen wir uns die jetzt ein wenig näher an.