Backend
Eine NoSQL Datenbank, zum Beispiel MongoDB, bietet unter anderem den Vorteil, dass sie auf ein dynamisches Schema ausgelegt ist, welches sich neuen Daten flexibel anpassen kann. MongoDB speichert diese Daten in Collections. Jede Collection enthält Dokumente, sogenannte JSON-Files, mit einer ähnlichen Struktur, welche unter sich auch eine unterschiedliche Anzahl von Feldern besitzen können.
Aufgrund dieses Schemas ist es sehr leicht, die Datenstruktur auch nach der Inbetriebnahme des Systems noch oft zu ändern. In unserem Projekt rechnen wir allerdings nicht damit, dass sich die Datenstruktur nach Fertigstellung noch dramatisch verändern wird.
Des Weiteren lässt sich eine MongoDB frei nach oben skalieren, die Datenbank könnte sogar von einem Mehrrechner-Datenbanksystem betrieben werden, sollte dies nötig werden. Dies ist vor allem im Big Data Bereich von großem Vorteil. Bei Prox ist es nun allerdings so, dass die Zunahme an Datenmenge stagnieren wird, sobald alle Professoren/Betreuungspersonen ein Profil erstellt haben.
RDBMS wie zum Beispiel MySQL und Oracle sind bewährte und weit verbreitete Lösungen für Datenstrukturen, welche sich im Nachhinein nicht großartig verändern. Ebenfalls von Vorteil ist die starke Abfragesprache(Queries) der RDBMS, welche, natürlich je nach Komplexität der Anfrage und Datenbestand, zuverlässig und schnell die benötigten Informationen liefern.
Ein weiterer persönlicher Vorteil unseres Teams von RDBMS ist die vorhandene Erfahrung in der Arbeit mit diesen. Zu guter Letzt ist zu erwähnen, dass die weiteren Microservices von Prox ebenfalls ein RDBMS verwenden (Stand Januar 2020). Sollte also in Zukunft jemand aus einem anderen Service Wartungsarbeiten oder Anpassungen durchführen müssen, kommt er in eine vertraute Architektur und muss sich nicht in ein anderes Datenbanksystem einarbeiten.
Die größten Vorteile einer NoSQL Datenbank lassen sich in diesem Projekt nicht nutzen, da eine bekannte, sich nach Fertigstellung des Projektes nicht mehr großartig verändernde Datenstruktur ausgearbeitet wurde. Des Weiteren wird die Menge an Daten nach der Einführungsphase ebenfalls stabil bleiben und nicht höher skaliert oder gar auf ein Mehrrechner-Datenbanksystem skaliert werden müssen.
Aufgrund dessen wurde entschlossen, eine Relationale Datenbank zu verwenden.
Für die Datenbanktabellen der Professoren und Studenten haben wir folgendes Schema herausgearbeitet:
- Die IDs der Beiden Entitäten werden als UUID erzeugt.
- Beide besitzen auch eine Keycloak_ID, welche zur Identifizierung bei der Anmeldung benötigt wird.
- Der Professor hat die Attribute Name, Titel, Adresse, Straße, PLZ, Raum, Telefonnummer, E-Mail, Sprechzeiten und Bild damit man ihn Identifizieren und Kontaktieren kann.
- Beim Studenten sind die Attribute zum Identifizieren und Kontaktieren bloß Name, Telefonnummer und E-Mail
- Beide Entitäten haben zusätzlich noch ein Beschreibungsfeld, mit dem sie sich kurz vorstellen können. Außerdem haben beide TAGs, mit denen man sie fachlich in Verbindung bringen kann.
- Der Student hat zusätzlich noch einige Attribute zur Angabe seiner Person und zum "werben" wie Studiengang, Schwerpunkt, Status, Qualifikation, Erledigte Module und Erledigte Aufgaben.
Leider wird diese Option nicht funktionieren, da wir keinen Zugriff auf die Datenbank erhalten werden. Damit müssen die Dozenten alle Angaben ihrer Person per Hand eingeben und können nicht von der TH Webseite gezogen werden.
Als Erstes wird der Text von uns aufgezeigt.
E-Mail vom 11.12.2019:
"Sehr geehrte Damen und Herren,
im Rahmen unserers Informatikprojekts entwickeln meine Gruppe und ich unter Betreuung von Prof. Bente im Archi - Lab die Projektbörse 'Prox' weiter.
Unsere Aufgabe ist es, diese um die Funktion der Professorenprofile zu erweitern. So soll jedem Professor seine eigene Profilseite zur Verfügung gestellt werden. Bei unseren Umfragen und Befragungen ist uns nun aufgefallen, dass viele Professoren sich wünschen würden einen möglichst geringen Initial- und Pflegeaufwand für die Profile aufzuwenden. Um dies umzusetzen haben wir in Betracht gezogen bereits vorhandene Informationen in unsere Datenbank einzuspeisen. Diese würen wir von den bereits vorhandenen Professorenprofilen von der Homepage der TH - Köln beziehen und somit Redundanz verhindern.
Unsere Frage an dieser Stelle ist, ob und inwieweit es möglich wäre einen Lesezugriff auf die Datenbank zu erhalten, auf der die oben genannten Informationen liegen.
Wenn ja könnten wir uns auf diesem Wege bereits Informationen wie z.B. Name, Foto und Raum besorgen. Des Weiteren stellt sich uns auch die Frage, ob eine Einspeisung dann einmal Initial durchgeführt werden sollte oder ob regelmäßig aktualisiert werden soll. Was diesen Punkt betrifft werden wir weitere Rücksprache mit Prof. Bente halten, sobald uns klar ist ob dieser Ansatz technisch überhaupt möglich ist.
Vielen Dank und liebe Grüße,
Marco Marienhagen"
Untenstehend die Antwort von der zuständigen Behörde (Support).
E-Mail vom 20.12.2019:
"Aus datenschutzrechtlichen Gründen können wir leider keinen Zugriff auf die Datenbank einrichten / erlauben."
Erneute E-Mail von uns.
E-Mail vom 23.12.2019:
"Bezug auf Ticketnummer 1912/0807
Sehr geehrte Damen und Herren,
wir können den Aspekt des Datenschutzes nachvollziehen. Nach genauerer Überlegung kam uns folgende Idee:
Beim initialen Erstellen des Profils, geben wir dem Nutzer (Professoren) die Möglichkeit, selbst zu entscheiden, ob die Daten aus der bereits vorhandenen Datenbank kommen (von der TH-Homepage) oder ob sie diese manuell eingeben möchten.
Bei der Auswahl der ersten Möglichkeit, muss der Nutzer bestätigen, dass er die Datenschutzvereinbarung gelesen hat und akzeptiert (einmaliges bestätigen). Die Datenschutzvereinbarung würden wir dann von Ihnen bekommen, damit dort alle relevanten Punkte abgedeckt sind, die für Sie wichtig sind.
Wir möchten an dieser Stelle erwähnen, dass bis zum Zeitpunkt des GoLive Testdaten ausreichend sind und wir somit keinen Zugriff auf die echten Daten benötigen.
Außerdem stellen wir uns eher vor, eine API von Ihnen zu bekommen und keinen direkten Datenbankzugriff. Leider haben wir dies in der letzten Mail nicht ausreichend kommuniziert.
Gerne würden wir diesbezüglich auch einen Termin für ein persönliches Gespräch mit Ihnen vereinbaren."
Erneute E-Mail vom Support.
E-Mail vom 06.02.2020:
"Das System verfügt leider über keine API. Die Daten werden aus einem Quellsystem in eine Datenbank geschrieben und von dort auf die Webseite ausgespielt.
Leider können wir auch keinen Zugriff auf das Quellsystem (IDM) oder die Zwischendatenbank zur Verfügung stellen."