[0:01] Hi, hier ist Stefan. In dieser Podcast-Episode geht es ums Fachgespräch.

[0:05] Wenn du noch mehr Informationen zum Fachgespräch von mir haben willst,

[0:08] dann schau doch mal auf meiner Website vorbei, dasperfektefachgespräch.de.

[0:14] Und jetzt wünsche ich dir viel Spaß mit der Podcast-Episode.

[0:20] Herzlich willkommen zum Anwendungsentwickler-Podcast,

[0:22] dem Podcast rund um die Ausbildung zum Fachinformatiker für Anwendungsentwicklung.

[0:27] In dieser Episode geht es um mein neues Hörbuch zur Vorbereitung auf das Fachgespräch.

[0:31] Viel Spaß!

[0:37] Hallo und herzlich willkommen zur 104. Episode des Anwendungsentwickler-Podcasts.

[0:44] Diese Woche wird die Episode ein bisschen kürzer,

[0:46] denn ich habe die ganze Woche lang ganz was anderes aufgenommen anstatt dieses Podcasts,

[0:51] und zwar mein neues Hörbuch.

[0:53] Und das ist jetzt fertig, und zwar geht es um den Bereich Datenbanken,

[0:57] und damit kannst du dich auf das Fachgespräch vorbereiten.

[1:01] Ich habe vor einiger Zeit ja schon ein anderes Hörbuch zum Thema Programmierung und Objektorientierung veröffentlicht,

[1:07] und jetzt kommt dazu passend der große Bereich der Datenbanken.

[1:11] Und das ist wirklich ein großer Bereich.

[1:13] Ich dachte, ich hätte nicht ganz so viel zu sagen wie zur Programmierung,

[1:16] aber wenn ich jetzt mal so auf das Ergebnis schaue,

[1:18] dann habe ich doch deutlich länger über Datenbanken quatschen können

[1:21] als über Programmierung und Objektorientierung zusammen.

[1:25] Denn insgesamt bin ich jetzt bei fünfeinhalb Stunden Audiomaterial rund um Datenbanken

[1:30] und alles, was damit irgendwie zu tun hat und was man auch im Fachgespräch logischerweise gefragt werden könnte.

[1:35] Also nicht allzu abstruse Sachen, sondern schon natürlich mit Fokus auf die Abschlussprüfung.

[1:41] Und zusätzlich habe ich auch noch mal das Intro überarbeitet,

[1:44] denn ich habe ganz zu Beginn auch bei meinem ersten Hörbuch so ein bisschen locker was erzählt

[1:49] zur Beantwortung der Fragen im Fachgespräch.

[1:51] Also wie sollte man darauf reagieren, wenn man zum Beispiel irgendwie einen Kopf nicken

[1:55] oder einen Kopf schütteln von den Prüfern bekommt oder immer unterbrochen wird?

[1:59] Oder wie antworte ich auf so völlig allgemeine Fragen wie zum Beispiel, was ist denn die Objektorientierung?

[2:04] Und das habe ich jetzt mal etwas formalisiert und ich habe eine ganze Liste an möglichen Fragen aufgestellt,

[2:10] die Prüflinge haben könnten, während sie sich auf das Fachgespräch vorbereiten.

[2:14] Und diese Liste der Fragen, die bin ich jetzt auch der Reihe nach wirklich in dem neuen Hörbuch durchgegangen.

[2:20] Und übrigens habe ich auch diese allgemeinen Fragen in das alte Hörbuch natürlich übernommen.

[2:24] Das heißt, beide, sowohl für die Objektorientierung als auch für die Datenbanken,

[2:28] enthalten jetzt diese Stunde, also es ist wirklich eine Stunde Audioaufnahme jetzt geworden,

[2:34] zur Vorbereitung auf die Fragestellung.

[2:37] Also völlig unabhängig von irgendeinem technischen Hintergrund, sondern wie reagiere ich auf die Fragen,

[2:41] wie antworte ich am besten, wie bereite ich mich aufs Fachgespräch vor und so weiter.

[2:45] Das alles ist also im Paket mit drin.

[2:48] Und die heutige Podcast-Episode besteht jetzt aus einem Kapitel dieses neuen Hörbuchs

[2:53] und ich habe einfach mal, weil ich das Thema hier noch nie besprochen habe, das kurze Kapitel NoSQL ausgewählt.

[3:00] Das sind jetzt 20 Minuten aus dem Hörbuch, wo es halt um den Bereich Not Only Structured Query Language geht, also NoSQL.

[3:08] Und ich hoffe, dass auch für dich noch was Spannendes dabei ist.

[3:11] Wenn dir der folgende Ausschnitt wirklich sehr gut gefällt, dann schau doch einfach mal auf meiner Website vorbei,

[3:17] dasperfektefachgespräch.de

[3:20] Und da findest du dann auch den Download sowohl des ersten als auch des zweiten Hörbuchs.

[3:25] Und wenn du ganz bis zum Ende dieser Episode wartest, gibt es auch noch ein kleines Highlight für dich,

[3:30] denn ich habe noch was zusammengestellt, wo du ein super mega klasses Sonderangebot bekommst,

[3:36] wenn du beide Hörbücher auf einmal dir kaufst.

[3:39] Und das erfährst du am Ende der heutigen Episode.

[3:42] Würde mich freuen, wenn du dran bleibst.

[3:44] Ansonsten erfährst du heute einfach ein bisschen was über NoSQL.

[3:48] Vielleicht ist auch das ja für dich spannend, aber der Aufbau ist jetzt halt so, wie es in meinem Hörbuch ist.

[3:53] Also konkrete Fragen, die der Reihe nach beantwortet werden.

[3:57] Ich lasse das Kapitel jetzt einfach mal ablaufen und freue mich auf dein Feedback

[4:02] und hoffe, dass ein bisschen was Interessantes für dich dabei ist.

[4:16] Was ist NoSQL und wofür braucht man das?

[4:20] NoSQL ist eine Abkürzung für Not Only SQL, also Not Only Structured Query Language,

[4:27] wobei SQL jetzt als Platzhalter für die relationalen Datenbanken steht,

[4:32] die ja mit SQL abgefragt werden.

[4:34] Wichtig ist hier jetzt, dass No steht nicht für No im Sinne von nicht SQL,

[4:40] sondern Not Only, also nicht nur SQL.

[4:43] Und das beschreibt, was man mit dieser Art von Datenbanken machen kann.

[4:47] NoSQL ist eine Art Oberbegriff für etwas modernere Datenbankkonzepte,

[4:52] die eben nicht nur mit SQL arbeiten, sondern ganz andere Möglichkeiten bieten.

[4:58] Häufig werden fünf verschiedene Datenbankmodelle unter dem Oberbegriff NoSQL zusammengefasst

[5:05] und das sind die spaltenorientierten Datenbanken, die objektorientierten Datenbanken,

[5:10] Key-Value-Stores, Dokumenten-Datenbanken und Grafendatenbanken.

[5:14] Und alle diese Datenbanken haben eventuell auch die Möglichkeit, mit SQL abgefragt zu werden.

[5:20] Die meisten haben aber ganz andere Abfragesprachen und auch ganz andere Konzepte,

[5:25] die sich mit dieser relationalen Algebra zum Beispiel gar nicht verstehen

[5:29] und deswegen auch nicht mit SQL abgefragt werden könnten.

[5:33] Grundsätzlich bezieht sich der Begriff aber auch darauf,

[5:35] dass ich in meinem ganzen Unternehmen nicht eben nur SQL-Datenbanken verwenden muss,

[5:41] sondern auch andere, die eben nicht mit SQL arbeiten.

[5:44] Als Beispiel, ich habe eine große relationale Datenbank im Keller, in Anführungszeichen,

[5:49] benutze aber für bestimmte Use Cases einfach andere Datenbankmodelle,

[5:54] weil die dafür besser geeignet sind.

[5:56] Ein schönes Beispiel wäre hier ein Cache, der Benutzeranfragen enthält.

[6:00] Wenn ich zum Beispiel meinen Warenkorb abfrage

[6:03] und dieser Warenkorb in meiner relationalen Datenbank auf zehn verschiedene Tabellen verstreut ist,

[6:08] dann wird eine Select-Abfrage mit einem komplexen Join relativ lange dauern.

[6:12] Wenn ich diese Inhalte jetzt aber ständig auf meiner Website anzeigen will,

[6:15] möchte ich eventuell nicht diese große Last erzeugen.

[6:18] Deswegen könnte ich jetzt die Ergebnisse dieser Abfrage in einem Key-Value-Store zwischenspeichern,

[6:24] wo einfach nur unter einem konkreten Schlüssel der gesamte Inhalt hinterlegt ist.

[6:28] Das ist nicht normalisiert und schön dedupliziert oder was auch immer.

[6:33] Es geht hier dann dabei nur darum, die Geschwindigkeit zu erhöhen,

[6:37] die mir meine SQL-Datenbank halt nicht liefern kann.

[6:40] Ich werde also in den meisten Fällen für meine gesamte Datenbasis

[6:44] immer noch eine relationale Datenbank verwenden,

[6:47] aber an der einen oder anderen Stelle, wo es eben sinnvoll ist,

[6:50] ein anderes Konzept nutzen, um zum Beispiel dem Benutzer eine schnellere Antwort liefern zu können.

[6:56] Es kann aber auch einfach Unternehmen geben,

[6:59] deren Datenbasis sich nicht gut mit relationalen Datenbanken abbilden lässt,

[7:03] wie zum Beispiel die berühmten sozialen Netzwerke.

[7:06] Dort geht es zum Beispiel um Knoten, die miteinander in Beziehung stehen,

[7:10] also bei Facebook zum Beispiel Personen, die andere Personen als Freunde haben.

[7:15] Und diese Datenstrukturen lassen sich in klassischen relationalen Datenbanken gar nicht so gut abbilden,

[7:21] beziehungsweise sie lassen sich abbilden,

[7:23] aber die Abfrage, die ich gegen diese Daten durchführen möchte, ist meistens sehr, sehr imperformant.

[7:29] Und dafür bieten sich dann zum Beispiel Grafendatenbanken an,

[7:32] die genau diese Datenstruktur perfekt abbilden können.

[7:36] Es geht also bei NoSQL nicht darum, einen Kampf mit den relationalen Datenbanken anzufangen,

[7:41] sondern es geht darum, aufzuzeigen, dass es andere Möglichkeiten gibt

[7:45] und wo der Use Case es hergibt, kann man auch von den relationalen Datenbanken abweichen

[7:50] und Teile seiner Daten oder Teile seines Geschäftskonzepts oder wie auch immer in einer anderen Datenbank umsetzen.

[7:57] Ich würde jetzt hier direkt die einzelnen schon genannten Datenbankmodelle weiter erläutern

[8:02] und dann bist du auf jeden Fall schon bei einem langen, langen Monolog,

[8:06] wenn du dafür auch noch Beispiele bringst oder vielleicht interessante Use Cases oder Unternehmen,

[8:10] die das einsetzen und wofür das denn besonders gut geeignet ist und so weiter.

[8:14] Das heißt im Prinzip alle Fragen, die ich jetzt gleich der Reihe nach noch durchgehe,

[8:18] könntest du hier auf diese erste Frage schon zur Antwort bringen.

[8:23] Welche Arten von NoSQL-Datenbanken gibt es?

[8:27] Das hängt ein bisschen davon ab, welche Literatur man heranzieht.

[8:31] Häufig werden aber fünf verschiedene Datenbankkonzepte unter NoSQL zusammengefasst,

[8:36] und zwar spaltenorientierte Datenbanken, objektorientierte Datenbanken, Key-Value-Stores, Dokumenten-Datenbanken und Grafendatenbanken.

[8:45] Bei der Beantwortung dieser Frage würde ich jetzt natürlich der Reihe nach alle diese Datenbankmodelle auch vertiefen,

[8:51] und das machen wir jetzt auch in den nächsten Fragen, sodass ich mir die Antwort hier einmal spare.

[8:56] Ich würde allerdings zu jedem Typ auch immer erwähnen, was denn jetzt die Vorteile sind,

[9:00] also was übliche Use Cases vielleicht sind, die ich mit diesen Datenbanken besonders gut umsetzen kann,

[9:06] und das wirst du jetzt auch in den nächsten Fragen immer hören.

[9:10] Wie funktionieren spaltenorientierte Datenbanken?

[9:14] Spaltenorientierte Datenbanken sind im Vergleich zu den eher zeilenorientierten relationalen Datenbanken intern anders aufgebaut.

[9:23] Spaltenorientierte Datenbanken kann man meistens genauso abfragen wie zeilenorientierte, nämlich einfach mit SQL.

[9:30] Sie sind allerdings intern so aufgebaut, dass bestimmte Abfragen sehr performant durchgeführt werden können.

[9:36] Stellen wir uns einmal vor, eine relationale Datenbank speichert die berühmte Tabelle Personen,

[9:41] und wir überlegen uns jetzt, wie die Datensätze wohl auf der Festplatte abgelegt werden.

[9:46] Wenn ich zwei Personen in meiner Tabelle habe, zum Beispiel Stefan Macke und Bill Gates,

[9:51] dann wird wahrscheinlich auf der Festplatte zunächst der gesamte Datensatz Stefan Macke,

[9:56] also der Vorname Stefan, dann der Nachname Macke, abgelegt, und danach der gesamte Datensatz 2, also Bill und dann Gates.

[10:05] Wenn ich jetzt aber eine Auswertung aller Nachnamen erstellen möchte,

[10:09] muss die Datenbank zunächst den ersten Nachnamen aus dem ersten Datensatz und dann den zweiten Nachnamen aus dem zweiten Datensatz lesen.

[10:16] Die stehen aber nicht direkt hintereinander, sondern die sind auf der Festplatte verteilt,

[10:20] weil ja die ganzen anderen Attribute der Datensätze, in diesem Fall ist es nur der Vorname, dazwischen liegen.

[10:26] Wenn ich die Daten nun intern anders speichere und zum Beispiel alle Vornamen physikalisch hintereinander ablege,

[10:33] dann ist natürlich eine Auswertung aller Vornamen sehr einfach und performant möglich,

[10:38] denn ich muss ja einfach nur einen Speicherbereich, der direkt hintereinander liegt, auf der Festplatte auswerten.

[10:44] Schwieriger wird es dann natürlich, wenn ich den gesamten Datensatz wiederherstellen will,

[10:48] dann muss ich nämlich den Vornamen aus der einen Liste und den Nachnamen aus der anderen Liste lesen.

[10:53] Je nachdem, was ich also mit meinen Daten machen möchte, bietet es sich an, die Sachen entweder zeilenweise oder spaltenweise zu speichern.

[11:01] In einem Data Warehouse, wo ich zum Beispiel viele Durchschnittswerte oder Maxima oder sonstige Sachen suche,

[11:07] bietet es sich vielleicht an, die Sachen eher spaltenweise abzulegen,

[11:11] denn bei den Artikeln interessiert mich wahrscheinlich bei einer Auswertung herzlich wenig der Name, sondern vielmehr der Preis.

[11:18] Und wenn ich jetzt die Durchschnittspreise ermitteln möchte, dann ist es ja viel einfacher,

[11:22] wenn ich alle Preise direkt hintereinander lesen kann, anstatt bei 7000 Artikeln jeweils die Spalte Preis auszulesen.

[11:31] Und das wäre auch schon ein perfekter Use Case, wenn ich also meine Daten nicht wahlweise komplett als Datensatz auslesen möchte,

[11:39] sondern quasi gruppiert über bestimmte komplette Spalten, dann benutze ich eine Spalten-Datenbank.

[11:45] Und der Klassiker dafür ist ebenso ein Data Warehouse.

[11:49] Alternativ bietet sich diese Form der Datenspeicherung eben an, sobald ich Statistiken über meine Daten erstellen möchte,

[11:56] beziehungsweise das mein zentraler Use Case ist.

[12:04] Objektorientierte Datenbanken speichern ihre Daten analog zur Objektorientierung, also dem bekannten Vorgehensmodell bei der Programmierung.

[12:13] Die Vorteile sind, dass der sogenannte Impedance-Mismatch wegfällt,

[12:18] das heißt die Abbildung der objektorientierten Welt auf die relationale Welt.

[12:24] Beispiel, Objektorientierung kennt keine Fremdschlüssel, relationale Datenbanken benötigen diese aber.

[12:30] Wenn ich die Daten jetzt in der Datenbank ablege oder daraus lesen möchte, muss ich immer diese Übersetzung machen.

[12:37] Ich muss also aus den Fremdschlüsseln Objektreferenzen machen und umgekehrt.

[12:41] Und eine objektorientierte Datenbank verhindert das, indem sie direkt die Referenzen ablegt und gar nicht in Fremdschlüssel übersetzt.

[12:49] Das heißt, im Gegensatz zur relationalen Datenbank habe ich keinen Unterschied in beiden Datenmodellen,

[12:55] sondern die Objekte aus meiner objektorientierten Programmiersprache können 1 zu 1 in der Datenbank abgelegt werden,

[13:01] sodass ich es als Entwickler deutlich einfacher habe.

[13:04] Ich muss mich nicht mehr damit auseinandersetzen, wie die Kardinalitäten aussehen und irgendwelche Übersetzungsmechanismen schaffen,

[13:11] sondern die Datenbank übernimmt das einfach für mich und ich kann meinen Objektbaum persistieren und wieder aus der Datenbank auslesen,

[13:19] ohne irgendein Hin und Her-Gemäppe.

[13:22] Diese Datenbanken bieten sich logischerweise dann an, wenn ich auch objektorientiert programmiere.

[13:27] Wenn ich andere Paradigmen nutze, wie die funktionale Programmierung oder die Prozedurale, dann habe ich natürlich nichts gewonnen,

[13:33] weil die objektorientierten Vorurteile dann ja wegfallen, weil meine Sprache sie gar nicht anbietet.

[13:40] Aber wenn ich objektorientiert entwickle, dann spare ich mir viel Arbeit, weil dieses Mapping zur relationalen Ablage der Daten wegfällt

[13:48] und ich kann überspitzt gesagt mit einer Zeile Code meinen gesamten Objektbaum in der Datenbank ablegen bzw. ihn dort wieder auslesen.

[13:59] Wie funktionieren Key-Value-Stores?

[14:02] Key-Value-Stores verhalten sich im Prinzip wie eine riesengroße Hash-Map bzw. aus .NET vielleicht bekannt, ein Dictionary.

[14:10] Es geht hier wirklich um eine Ansammlung von Schlüssel-Wertpaaren und die werden möglichst effizient abgelegt,

[14:17] sodass ich unter Angabe des Schlüssels direkt auf den entsprechend dort hinterlegten Wert zugreifen kann.

[14:23] Ganz häufig werden diese Systeme z.B. für Caches benutzt.

[14:26] Das bedeutet, bestimmte Abfrageergebnisse oder Berechnungsergebnisse werden unter einem eindeutigen Schlüssel in diesem Cache abgelegt,

[14:35] sodass ich später mit einem einzigen Datenbankzugriff auf diesem Cache diesen Wert mir wieder beschaffen kann.

[14:41] Im Vergleich dazu müsste ich vielleicht in anderen Datenbanksystemen, objektorientierte oder relationale oder auch dokumentenorientierte Datenbanken,

[14:49] mehrere Abfragen durchführen, um mein Ergebnis zu bekommen, weil die Daten vielleicht in relationalen Datenbanken normalisiert abgelegt werden.

[14:58] Ein Key-Value-Store ermöglicht es mir wirklich nur, unter einem Schlüssel einen Wert abzulegen,

[15:03] wobei dieser Wert natürlich auch ein komplexes Gebilde sein kann.

[15:06] Ich kann also z.B. ein großes JSON-Dokument dort hinterlegen, was dann einen komplexen Objektbaum aus meiner Programmiersprache abbildet.

[15:14] Es muss also nicht einfach nur ein Integerwert oder Ähnliches sein.

[15:18] Ich kann dort also beliebig komplexe Daten hinterlegen, aber sie sind eben nur über diesen einen Schlüssel zugreifbar.

[15:25] Und genau das ist der Vorteil, weil das natürlich sehr, sehr schnell geht im Vergleich zu komplexen Abfragen in anderen Systemen.

[15:32] Key-Value-Stores werden häufig als Cache eingesetzt und dann auch als sogenannte In-Memory-Datenbank.

[15:39] Das heißt, der Cache oder der Inhalt des Caches liegt komplett im Arbeitsspeicher des Computers und muss nicht langsam von der Festplatte geladen werden.

[15:48] Key-Value-Stores werden eher selten für die persistente Ablage von Daten benutzt, sondern der zentrale Use-Case ist eben genau das.

[15:56] Ein Cache, der In-Memory gehalten wird, um dem Benutzer möglichst schnell Antworten auf häufige Anfragen geben zu können.

[16:04] Wie funktionieren Dokumenten-Datenbanken?

[16:07] Dokumenten-Datenbanken speichern die Daten nicht in Datensätzen, in Tabellen, sondern als Dokumente in etwas, was man je nach konkreter Datenbank zum Beispiel Collection nennt, also Sammlung.

[16:23] Diese Dokumente, die dort abgelegt werden, sind auch nicht normalisiert, sondern enthalten alle Daten, die zu diesem Dokument gehören, in Form zum Beispiel von Schlüsselwertpaaren.

[16:34] Einige Datenbanken, wie zum Beispiel MongoDB, speichern die Daten in Form von JSON-Dokumenten.

[16:40] Das heißt, es wird die JavaScript Object Notation benutzt, um quasi JavaScript-Objekte in dieser Collection abzulegen.

[16:49] Und dann habe ich, wenn ich auf so einen Eintrag zugreife, ein komplexes Dokument, das dann zum Beispiel auch aus Unterdokumenten bestehen kann oder sogar Arrays enthalten kann, also multiple Werte.

[17:02] Es ist also nicht eine flache Tabelle wie bei relationalen Datenbanken, sondern ein möglicherweise hierarchisches und komplexes Dokument, was dort abgelegt wird.

[17:12] Es gibt zwar auch die Möglichkeit, wenn dieses Dokument jetzt Referenzen auf andere Dokumente enthält, da anstelle dieser eingebetteten Dokumente tatsächlich nur Referenzen, also so eine Art Fremdschlüssel, abzulegen.

[17:24] Aber grundsätzlich kann man sich vorstellen, dass wirklich das gesamte Dokument inklusive aller Werte, Unterdokumente, mehrerer Listen und was auch immer dort alles drin ist, in dieser Collection abgelegt wird.

[17:38] Das hat jetzt natürlich insbesondere beim Zugriff einen großen Vorteil. Ich muss nämlich zum Beispiel bei komplexen Daten eben nicht mehrere Tabellen abfragen und die joinen, sondern ich habe eben alle Daten, die zu diesem Dokument gehören, mit einem einzigen Zugriff vorliegen.

[17:54] Des Weiteren müssen die Dokumente in einer Collection nicht immer einem Schema entsprechen. Sie können also durchaus auch unterschiedliche Attribute haben.

[18:02] Das heißt, wenn wir uns eine Collection vom Typ Person vorstellen, dann kann es durchaus sein, dass nur einige dieser Personen einen Vornamen haben.

[18:11] Andere haben dafür aber vielleicht sogar ein Mittelinitial. Andere haben ihre Hobbys abgelegt, aber alle haben zum Beispiel einen Nachnamen.

[18:19] Und all das ist nicht irgendwo festgelegt, sondern die Collection kann das quasi dynamisch handhaben.

[18:25] Und trotzdem kann man über diese ganzen verschiedenen Dokumente nachher zum Beispiel suchen oder man kann sogar einen Index darauf legen, wenn man nach bestimmten Attributen suchen möchte und so weiter.

[18:37] Daher werden Dokumentendatenbanken auch sehr gerne beim Rapid Prototyping eingesetzt.

[18:42] Das heißt, wenn ich noch nicht ganz sicher weiß, wie meine Datenbankstruktur letztendlich aussehen wird, kann ich mit Dokumentendatenbanken, ohne großartig statisch an der Datenbank herum experimentieren zu müssen,

[18:53] einfach Attribute hinzufügen, umbenennen, wegnehmen, ohne dass ich immer den Overhead habe, die Datenbank anpassen zu müssen.

[19:01] Außerdem hatte ich schon gesagt, dass viele dokumentenorientierte Datenbanken, wie zum Beispiel ein berühmter Vertreter, die MongoDB, die Daten im JSON-Format ablegen.

[19:09] Das heißt, ich kann insbesondere mit JavaScript sehr gut auf diese Daten zugreifen, denn ich brauche im Zweifel nur eine Zeile Code, um ein Dokument aus der dokumentenorientierten Datenbank auszulesen.

[19:20] Und ich habe dann sofort ein echtes JavaScript-Objekt, mit dem ich dann in meiner Programmiersprache eben weiterarbeiten kann.

[19:28] Wie funktionieren Grafendatenbanken?

[19:31] Grafendatenbanken speichern die enthaltenen Daten in Form von Grafen.

[19:36] Ein Graf ist eine Datenstruktur, die aus Knoten und Kanten besteht.

[19:42] Ein Knoten, das ist auf Englisch auch Note genannt,

[19:45] eine Information, quasi vergleichbar mit einer Entität, wie zum Beispiel eine Person,

[19:51] und eine Kante, das ist eine Verbindung zwischen zwei Knoten.

[19:55] Und diese Verbindung kann jetzt eine Bezeichnung bekommen, wie zum Beispiel kennt.

[20:00] Und so kann ich zwei Personen, meinetwegen Stefan und Klaus,

[20:04] mit einer Kante, mit der Bezeichnung kennt, verbinden

[20:07] und kann darauf schließen, dass jetzt die Person Stefan die Person Klaus eben kennt.

[20:12] Ich kann also die Beziehung zwischen diesen beiden Knoten mit den Kanten abbilden.

[20:17] Und sowohl die Knoten als auch die Kanten können Attribute, also Eigenschaften, besitzen.

[20:22] Die Person könnte zum Beispiel ein Alter und einen Namen haben

[20:25] und die Beziehung könnte zum Beispiel ein Attribut Kennenlerndatum enthalten.

[20:31] Der Vorteil von Grafendatenbanken ist jetzt, dass man auf dieser Datenstruktur des Grafen

[20:36] bestimmte Algorithmen sehr performant oder einfach umsetzen kann.

[20:41] Wenn ich zum Beispiel, wie üblicherweise in sozialen Netzwerken sehr verbreitet,

[20:45] herausfinden möchte, über wie viele Ecken eine Person eine andere Person kennt,

[20:50] also über welche Beziehungen ich von der einen Person zur anderen quasi navigieren kann,

[20:56] dann kann ich das mit bestimmten Grafenalgorithmen sehr einfach umsetzen.

[21:00] Das heißt, der Algorithmus, um quasi alle Beziehungen zwischen zwei Knoten herauszufinden,

[21:06] ist relativ einfach beziehungsweise auch sehr performant umsetzbar.

[21:10] Wenn ich das gleiche mit relationalen Datenbanken umsetzen möchte

[21:13] und wir stellen uns vor, die Person ist in einer Tabelle abgelegt

[21:17] und meinetwegen mit einer M2N-Zuordnungstabelle mit anderen Personen verknüpft,

[21:22] dann kann man sich überlegen, wie komplex die Abfrage jetzt aussieht,

[21:26] um herauszufinden, wen eine Person über wie viele Ecken kennt.

[21:30] Denn für jede Ebene mehr brauche ich quasi ein weiteres Self-Join auf die Tabelle Person

[21:36] und meine Abfrage wird dann sehr, sehr komplex beziehungsweise eventuell sogar gar nicht lösbar,

[21:41] weil ich Joins zum Beispiel gar nicht dynamisch angeben kann.

[21:45] Jetzt ist die Frage, welche Daten kann man denn in so einer Grafendatenbank gut ablegen?

[21:50] Das sind hauptsächlich die Daten, die eben in irgendeiner Beziehung stehen,

[21:54] die man als Graf modellieren kann.

[21:56] Klassisches Beispiel sind eben die sozialen Netzwerke,

[21:59] wo Knoten sich über bestimmte Beziehungen irgendwie verbinden lassen.

[22:04] Man kann aber auch klassische betriebswirtschaftliche Probleme damit abbilden,

[22:08] wie zum Beispiel in einem Navigationssystem,

[22:10] welche Stadt ist mit welcher anderen Stadt verbunden

[22:13] oder eine technische Fertigungsanlage,

[22:15] wo vielleicht Lackierstationen mit Transportbändern untereinander verbunden sind.

[22:21] Sobald ich in meiner Datenstruktur eben die Form eines Grafens nutzen kann,

[22:26] kann ich, um diese Daten abzulegen, eine Grafendatenbank nutzen

[22:30] und habe dann eben die Vorteile, die mir diese Grafenalgorithmen bieten.

[22:35] Viele Grafendatenbanken bieten auch eine eigene Abfragesprache an.

[22:40] Ein sehr bekannter Vertreter ist zum Beispiel Neo4j

[22:43] und die haben eine separate Abfragesprache entwickelt, die Cypher heißt

[22:48] und die sieht schon fast aus wie gezeichnete Grafen.

[22:52] Da werden zum Beispiel Pfeile mit spitzen Klammern und Minuszeichen nachgebildet,

[22:57] sodass ich auch mit wenig technischem Hintergrundwissen

[23:00] vielleicht nachempfinden kann, welche Abfrage da eigentlich gerade durchgeführt wird.

[23:05] Welche bekannten NoSQL-Datenbanken gibt es

[23:08] und wie heißen gegebenenfalls die Hersteller?

[23:11] Diese Frage ist analog zu sehen zur entsprechenden Frage nach den relationalen Datenbankherstellern.

[23:17] Hier geht es also einfach nur darum, ein paar Namen zu nennen,

[23:20] damit man zeigen kann, dass man auch die am Markt verbreiteten Systeme wenigstens mal gehört hat.

[23:25] Ich gehe jetzt nicht auf die Details der jeweiligen Hersteller oder Produkte ein,

[23:29] das würde ich aber im Fachgespräch natürlich unbedingt tun.

[23:32] Das heißt, nachdem man die Antwort gegeben hat, also kurz die Sachen genannt hat,

[23:36] würde ich auf jeden Fall auf die einzelnen Datenbanksysteme nochmal eingehen,

[23:40] also quasi die Antwort auf die letzten fünf Fragen geben,

[23:44] wie die einzelnen Datenbanksysteme sich unterscheiden

[23:47] und dann würde ich auch vielleicht auf die individuellen Vor- und Nachteile eingehen

[23:51] oder vielleicht auf mögliche Einsatzgebiete und so weiter und so fort.

[23:55] Aber wir gehen jetzt erstmal ein paar dieser Hersteller und Systeme durch,

[23:59] damit du die Frage erstmal beantworten kannst.

[24:01] Wenn wir im Bereich spaltenorientierte Datenbanken schauen,

[24:04] da gibt es zum Beispiel von Apache die Datenbank Cassandra.

[24:08] Auch von Apache ist die HBase. Das sind beides spaltenorientierte Datenbanken.

[24:13] Dann haben wir eine objektorientierte Datenbank.

[24:15] Da gibt es eigentlich sehr bekannt nur die DB4O, also Database for Objects.

[24:21] Da steht es schon im Namen mit drin.

[24:23] Dann haben wir Key-Value-Stores. Davon gibt es ein paar mehr.

[24:25] Zwei sehr bekannte sind zum Beispiel REAC und Redis.

[24:30] Dokumenten-Datenbanken gibt es auch zwei berühmte Vertreter und zwar MongoDB und CouchDB von Apache.

[24:36] Aber die gibt es schon ziemlich lange, denn auch Lotus Notes,

[24:40] das dir vielleicht als E-Mail-Applikation bekannt ist, basiert auf einer Dokumenten-Datenbank

[24:45] beziehungsweise ist eine Dokumenten-Datenbank.

[24:48] Und als letztes gibt es noch eine sehr bekannte Grafen-Datenbank und das ist die Neo4j.

[24:55] Ja, das war es zum Thema NoSQL.

[24:58] Das sind die Fragen, die ich in dem entsprechenden Kapitel meines Hörbuchs für dich beantwortet habe.

[25:04] Das war jetzt für dich natürlich komplett kostenfrei.

[25:07] Du hast es ja gerade schon gehört.

[25:09] Der Rest des Hörbuchs ist dann nicht mehr kostenfrei, denn das hat ganz schön viel Arbeit gemacht.

[25:13] Deswegen ja auch heute die kurze Podcast-Episode, weil ich da wirklich viel Zeit investiert habe.

[25:18] Ich habe insgesamt knapp unter 100 Fragen zu Datenbanken aufgenommen.

[25:22] 97 müssten es sein.

[25:24] Und zusätzlich auch noch ca. 20 Fragen zum allgemeinen Beantworten von Fachgesprächsfragen.

[25:30] Von daher, da habe ich wirklich viel Zeit investiert.

[25:33] Und ich hoffe, es ist auch mit einer entsprechenden Qualität mir gelungen,

[25:37] das Ganze jetzt hier aufzunehmen und rüberzubringen und jetzt auch zum Download anzubieten.

[25:42] Und wenn du diesen Podcast und meine Seite ein bisschen unterstützen möchtest,

[25:45] dann würde ich mich freuen, wenn du mal auf der Website vorbeiguckst.

[25:49] Dasperfektefachgespräch.de

[25:51] Und da kannst du dir dann die beiden Hörbücher herunterladen oder auch eben nur eins von beiden.

[25:56] Ganz wie du möchtest.

[25:58] Und ich hatte ja versprochen, dass es ein besonderes kleines Feature für dich gibt.

[26:02] Als treuen Podcast-Hörer, wie ich hoffe.

[26:05] Ich hoffe, dass es ja heute nicht deine erste Episode ist.

[26:07] Aber mir ist auch egal.

[26:08] Du kriegst trotzdem den Rabatt, den ich dir jetzt vorgegeben habe.

[26:12] Und zwar kosten die Hörbücher einzeln jeweils 19,99.

[26:16] Und ich verkaufe beide zusammen, aber auch im Paketpreis für 29,99.

[26:22] Und weil du mir halt heute hier immerhin schon 26 Minuten lang zuhörst

[26:27] und ich das ja irgendwie wieder gut machen muss,

[26:30] gibt es noch ein super Sonderangebot.

[26:32] Und zwar kannst du bis Ende Mai 2017, also noch ca. zwei Wochen,

[26:39] beide Hörbücher, und das sind fast elf Stunden Prüfungsvorbereitung,

[26:45] für 19,99 Euro kaufen.

[26:48] Also die allgemeinen Tipps zur Beantwortung der Fragen,

[26:51] das komplette Hörbuch zur Programmierung und Objektorientierung

[26:55] und die neuen 5,5 Stunden zum Bereich Datenbanken

[26:59] bekommst du für 19,99, aber nur noch bis zum 31.05.2017.

[27:07] Damit du diesen Nachlass bekommst,

[27:10] musst du allerdings einen Rabattcode eingeben bei der Bestellung.

[27:14] Und dieser Rabattcode lautet Datenbanken mit großem D bitte.

[27:19] Also einfach wie das Thema des Hörbuchs Datenbanken als Rabattcode eingeben

[27:25] und du bekommst beide Hörbücher inklusive den allgemeinen Fragen zum Fachgespräch

[27:30] für 19,99 Euro anstatt 29,99.

[27:36] Also wenn du gerade kurz vor deiner mündlichen Prüfung stehst

[27:39] und es gerade für dich passt, dann schlag zu, denn danach wird es wieder teurer.

[27:45] Du musst auch übrigens nicht die Katze im Sack kaufen,

[27:48] denn alle Fragen, die ich beantworte, stehen komplett auf der Website

[27:52] dasperfektefachgespräch.de.

[27:55] Da kannst du dir alles in Ruhe vorher anschauen, was ich da beantworte.

[27:58] Du hast heute eine Beispielepisode zum Thema NoSQL gehört.

[28:02] Ich habe eine andere Beispielepisode aus dem Hörbuch für Programmierung auch online.

[28:06] Kannst du dir direkt auf der Website anhören.

[28:08] Und als letztes, wenn du dir das Buch kaufst, bekommst du sogar ein 14-tägiges Rückgaberecht.

[28:14] Du kannst also ohne Angabe irgendwelcher Gründe das Ding zurückgeben,

[28:18] wenn es dir dann doch nicht gefällt.

[28:20] Wäre sehr schade, denn wie gesagt, damit finanziere ich hier die Website

[28:25] und den kostenfreien Podcast für alle Prüflinge da draußen.

[28:28] Von daher wäre es schön, wenn du mich da irgendwie unterstützen würdest.

[28:31] Aber wenn du meinst, ich erzähle wirklich nur Müll und es hilft dir nicht weiter,

[28:35] dann kannst du auch ohne irgendwas befürchten zu müssen, das Ding einfach wieder zurückgeben.

[28:41] Und das sind auch wirklich nur ein paar Klicks.

[28:43] Es ist also kein Riesenaufwand.

[28:45] Also, würde mich sehr freuen, wenn du mal auf der Website vorbeischaust.

[28:49] Das Perfekte Fachgespräch.

[28:51] Übrigens kannst du es mit Ä schreiben.

[28:53] Ich habe mir so eine coole Umlautdomain besorgt.

[28:55] Du kannst es aber auch mit AE schreiben.

[28:57] Ganz egal, du kommst auf beiden Domains zu dem Hörbuch.

[29:02] Ja, das würde mich freuen, wenn du einfach mal vorbeischaust.

[29:05] Und natürlich würde es mich noch mehr freuen, wenn du mich hier irgendwie unterstützt.

[29:08] Und ich kann dich aber ja auch unterstützen.

[29:10] Denn wie gesagt, das ist ja jetzt einfach nicht zum Spaß,

[29:12] sondern es sind wirklich insgesamt über 200 Fragen, die im Fachgespräch gestellt werden könnten

[29:19] und eine mögliche Antwort darauf mit Erklärung, warum man das so erklären sollte und nicht anders.

[29:25] Also, ich denke, es ist wirklich eine sehr gute Vorbereitung aufs Fachgespräch.

[29:29] Und wenn du da noch Unterstützung brauchst, ja, dann schau doch einfach mal vorbei

[29:34] und besorg dir vielleicht das Hörbuch.

[29:36] Und ich glaube, jetzt habe ich auch genug zum Hörbuch gequatscht.

[29:40] Außerdem habe ich heute schon mehrere Stunden lang Audioaufnahmen gemacht.

[29:44] Und ich habe jetzt einfach ehrlich gesagt auch mal keine Lust mehr.

[29:48] Deswegen höre ich jetzt hier auch auf zu quatschen und sage für heute vielen Dank fürs Zuhören

[29:53] und bis zum nächsten Mal. Tschüss!