Vom Lehrsaal zur Live-Anbindung: Mein Aha-Erlebnis mit RDBMS

Bildquelle: Pexels

Prolog

Autsch! Mein Körper ist einfach nicht dafür gemacht, stundenlang auf Holzstühlen zu sitzen. Wenn ich mir die anderen so ansehe, ist das vielleicht sogar absichtlich so konzipiert. Damit es sich die Studenten ja nicht zu bequem machen...Dabei ist die Vorlesung hier Grund genug, an Flucht zu denken. War der Deal nicht zu lernen, wie Unternehmen funktionieren? Stattdessen sitze ich hier und klamüsere fiktive Tabellen auseinander. RDBMS, pfft! Der größte Stumpfsinn wirkt professionell, wenn man sich nur einen schweren Begriff dafür überlegt. Man muss wahnsinnig sein, wenn man das hier gerne macht. Dabei sieht der Prof eigentlich gar nicht so aus. Seinen einzigartigen Look muss man ihm jedenfalls lassen. Ein bisschen wie bei Nicolas Cage – so ein Gesicht vergisst man nicht. Da siehst du mal, Sarah: Wärst du doch zum Film gegangen. Jedenfalls verspreche ich mir eines: Wenn ich hier heil herauskomme, schaue ich erstmal nach Stellenanzeigen. Egal, wo ich anfange – das hier tue ich mir nicht mehr an. Nie! Mehr!!

Liebes Tagebuch,

sag niemals nie! Als ich damals in der Vorlesung saß, war ich sicher, dass sich RDBMS nicht mehr auf meine Netzhaut projiziert. Und jetzt bist ausgerechnet du schuld daran, dass genau das passiert!
Als wir auf das Thema Business Intelligence (BI) zu sprechen kamen, wertete ich im Selbstversuch meine Blogarbeiten aus.
Damit ich Erkenntnisse zu meinem Blog visualisieren konnte, musste ich meine Daten von einem Ort zum anderen bringen – am besten durch eine Live-Anbindung zwischen meiner Zeiterfassung in Kimai und Microsoft Power BI als Analysetool.
Dabei kam heraus, dass meine Blogarbeiten in einem relationalen Datenbankmanagementsystem, kurz RDBMS, erfasst sind und ich einen Weg finden musste, wie Power BI die Infos aus der Datenbank abfragen konnte.
Tja, damit war mein Schwur aus der Vorlesung dahin. Aber wenigstens finde ich nun mit ehrlichem Interesse heraus, warum ich so offensichtlich nicht an RDBMS vorbeikam. Eine Rolle wird dabei auch SQL spielen: Die Sprache, mit der wir meine Blogdaten von A nach B transportieren werden.

Einfach erklärt: Wissenswertes zur relationalen Datenbank

Eine relationale Datenbank organisiert Daten in Form von Tabellen, die untereinander in eindeutigen Beziehungen stehen. Informationen werden darin in Zeilen (Datensätze) und Spalten (Attribute) gespeichert.^1.
Um Daten in einer solchen Struktur anzuordnen, greifen relationale Datenbanken auf Normalisierung zurück:
Durch die Aufteilung der Daten in mehrere Tabellen wird verhindert, dass dieselben Informationen mehrfach gespeichert werden.
Beziehungen zwischen den verschiedenen Tabellen werden durch unverwechselbare Schlüssel hergestellt.^2. Dafür markiert eine Tabelle jeden Datensatz mit einem einzigartigen Code, dem Primärschlüssel. Taucht er als Referenz in anderen Tabellen auf, gilt er dort als Fremdschlüssel.^3.
Die Software, mit der sich relationale Datenbanken verwalten lassen, nennt sich relationales Datenbankmanagementsystem, kurz RDBMS.^1.

Kurzes Beispiel: So sieht eine relationale Datenbank aus

Wenn ich meine Blogarbeiten erfasse, teilen sich die Daten also in mehrere Tabellen auf. Der Datenbankzugriff per Terminal erlaubt mir den Einblick, wie diese Aufteilung genau aussieht:

Die Timesheet Tabelle erfasst zum Beispiel Start- und Endzeit meiner Buchungen.
In den Activities steht aufgelistet, wie ich meine Aktivitäten unterscheide (z.B. Beitragserstellung vs. Websitearbeit).
Wiederum eine andere Tabelle enthält Tags, anhand derer ich meine Buchungen zu einem konkreten Beitrag zuordne.
Jeder Datensatz lässt sich über den Primärschlüssel identifizieren. Mit der Activity_ID 1 weiß bspw. jede der Tabellen, dass es sich um die Aktivität „Beitragserstellung“ handelt.
Zum Glück bekomme ich im Normalfall nichts von dieser Schnipselei mit – mein Zeiterfassungstool zeigt mir in der Nutzeroberfläche eine leicht verständliche Verknüpfung dieser Tabellen:

Sieht doch gleich viel besser aus, oder? Als Anwender verstehe ich diese Ansicht definitiv besser. Doch verwaltungstechnisch gewinnt sie nicht zwingend: Wären meine Blogdaten wirklich so abgelegt, wie man sie hier sieht, könnten kleine Änderungen große Mühe machen.
Allein um ein Tag umzubenennen, müsste ich fast jede Zeile überarbeiten. Die relationale Datenbank korrigiert nur eine Stelle in der Tag-Tabelle.
Jetzt haben wir also enträtselt, wo und wie meine Blogdaten gespeichert sind. Nun fehlt uns noch das Puzzlestück, um sie auch in ein fremdes System zu transportieren. Und das trägt den Namen SQL.

Die SQL-Abfrage: Das steckt hinter den drei Buchstaben

SQL (Structured Query Language) ist die Standardsprache, um mit relationalen Datenbanken zu kommunizieren.^4. SQL lässt sich für verschiedene Zwecke einsetzen: Neben dem Verwalten von Rechten und Strukturen der Datenbank auch für Veränderungen wie einfügen, löschen oder abrufen.
Für meine Abfrage musste ich mich mit folgendem SQL-Vokabular vertraut machen:

SELECT: Definiert, welche Angaben die Abfrage abholen soll.
FROM: Definiert, in welcher Tabelle die Angaben zu finden sind und was ihr Primärschlüssel ist.^5.
JOIN: Erlaubt, sich bei der Abfrage auf mehrere Tabellen zu beziehen.^6.
WHERE: Schränkt eine Abfrage auf eine bestimmte Bedingung ein.^7.

Fertig ausformuliert sah meine SQL-Abfrage dann folgendermaßen aus:

select 
	kimai2_timesheet.start_time, 
	kimai2_timesheet.end_time, 
	kimai2_timesheet.duration, 
	kimai2_timesheet.rate, 
	kimai2_users.username, 
	kimai2_customers.name, 
	kimai2_projects.name, 
	kimai2_activities.name, 
	kimai2_timesheet.description, 
	kimai2_tags.name  
from 
	kimai2_timesheet  
		inner join kimai2_users on kimai2_timesheet.user=kimai2_users.id
		inner join kimai2_projects on kimai2_projects.id=kimai2_timesheet.project_id  
		inner join kimai2_customers on kimai2_customers.id=kimai2_projects.customer_id  
		inner join kimai2_timesheet_tags on kimai2_timesheet.id=kimai2_timesheet_tags.timesheet_id  
		inner join kimai2_tags on kimai2_timesheet_tags.tag_id=kimai2_tags.id  
		inner join kimai2_activities on kimai2_timesheet.activity_id=kimai2_activities.id  
where 
	kimai2_projects.name="IT-Blog (itgirlsjournal.de)";

Nun hatte ich meine Abfrage formuliert und konnte damit meine Live-Anbindung in Kraft setzen. Wie genau ich dabei vorgegangen bin, erzähle ich dir nachfolgend.

Let’s go: Die Schritte zur Anbindung in meinem DIY-Projekt

Drei Schritte waren beim Aktivieren der Live-Anbindung erforderlich:

Einen neuen Datenbank-User anlegen
Wenn es zu einer Datenabfrage kommt, braucht es jemanden, der sie stellt. Also legte ich in meiner Zeiterfassung einen neuen Nutzer an, der diese Aufgabe übernahm.
Die Firewall einweihen
Eine Firewall ist dazu da, Unbefugten den Zutritt zu verbieten. Also musste ich sie in Kenntnis setzen, dass mein neuer User seine Daseinsberechtigung hat und Daten aus meinem Tool vom Server abholen darf.
Die SQL-Abfrage ausführen
In meinem Fall machte ich die Abfrage über den MySQL-Connector in Power BI. Nach Installation stellte ich den Bezug zu meinem Datenbankserver und -User her und platzierte meine SQL-Abfrage. Die Datenvorschau ließ mich prüfen, ob die Einstellungen zum gewünschten Ergebnis führten.

Im Anschluss an diese Schritte erschien er endlich: Der langersehnte Button „Laden“. Voll Genugtuung klickte ich darauf – und meine Blogdaten landeten ohne weiteres Zutun in Power BI.

FAZIT

Was ist nun nach meinem großen Visualisierungsprojekt das Resümee zu RDBMS? Vom schlimmsten Feind zum besten Freund? Nicht ganz. Nach wie vor würde ich mich nicht den ganzen Tag damit befassen wollen. Aber ich habe den Zweck relationaler Datenbanken verstanden, und kann davon auch im beruflichen Umfeld profitieren.
Denn normalen Nutzern wie mir ist meist der Zutritt verboten, wenn es um Live-Anbindungen geht. So sensible Einstellungen machen in der Regel ausschließlich IT-Admins und das ist auch gut so. Dennoch blieben mir dadurch Zusammenhänge verborgen, die ich mit diesem Selbstversuch nun verketten konnte. Wie so oft bei meiner IT-Reise: Der Einstieg ist zäh, aber es lohnt sich!

Quellen: