= Interaktives SQL E-Learning Module :author: Jan Klemkow, Benjamin Franzke :lang: de == Einleitung E-Learning ist heute mehr als nur die reine Zusammenstellung von Texten mit Bildern und Videos. Interaktive Inhalte mit denen der Student experimentieren kann, sind fuer das praktische Lernerfolg von elementarer Bedeutung. Der Bereich der Datenbanken ist ein gutes Beispiel, welches verdeutlicht, wie wichtig das praktische Anwenden von Wissen fuer den Lernerfolg ist. Fuer Datenbanken gibt eine grosse Menge von Lehrbuechern welche alle Aspekte dieses Bereichs erlaeutern. Diese Lehrbuecher und die Vorlesungen bilden im Presentsstudium die theoretische Grundlage. Um den Umgang mit Datenbanken zu erlehrnen werden zusaetzlich Praktika gegeben, in denen die Studenten eigene Datenbanken erstellen, Daten einpflegen und wieder abfragen. Den Fernstudenten bieten sich solche Moeglichkeiten leider nicht. Ihnen bleiben nur die Moeglichkeiten Anhand von Anleitungen eigenen Test-Umgebungen aufzubauen, um mit dieses praktische Erfahrungen sammeln zu koennen. Diese Arbeit beschreibt die Integration von realen Datenbanken in einen E-Learning-Kurs. == Grundlagen Im Fachbereich EuI an der Hochschule Wismar werden zwei verschiedene Systeme -- ILIAS und Moodle -- fuer Online-Kurse genutzt. Diese Lernplattformen sind beide webbasiert und in PHP geschrieben. Inhalte fuer verschiedene Kurse der Praesentsstudiengaenge sind dort zu finden. Die Lerninhalte des Fachs Datenbanken werden als Kurse des Moodle-Systems bereit gestellt. Zudem gibt es interaktives Online-Tutorial fuer eine Oracle-Datenbank. Dieses System wurde von Niels Weber im Rahmen einer Diplomarbeit realisiert. === Oracle-Tutorial Das Oracle-Tutorial ist ein eigenstaendiges webbasiertes System welches nicht mit den anderen Lernplattformen verknuepft ist. Es bietet den Studenten die Moeglichkeit anhand eines konstruiten Szenarios, auf einer realen Datenbank SQL-Abfragen zu stellen. Den Studenten werden dabei verschieden Aufgaben gestellt zu dessen Beantwortung sie SQL-Abfragen formulieren muessen. Diese werden dann auf der Beispieldatenbank ausgefuehrt und das Ergebnis intern mit einer vorgegebenen Loesung verglichen. Die Aufgaben sind dabei so gewaehlt, dass der Student moeglichst mit alle Arten und alle Aspekte einer SQL-Anfrage konfrontiert wird. Somit bekommt der Student einen umfassenden Einblick in die Moeglichkeiten, die sich einem mit SQL-Datenbanken ergeben. === Moodle Moodle ist eine modulare Open-Source Lernplattform. Sie ist webbasiert und in der Programmiersprache PHP geschrieben. === Moodle-Module Moodle-Module. === Videos einbinden Für Moodle ist ein integriertes Video-Plugin verfügbar. == SQLBox ``SQLBox'' ist ein Moodle-Modul, welches im Rahmen des Mulimedia-Projekts entstanden ist. Mit diesem Modul lassen sich Aufgaben fuer Datenbanken Anhand eines Beispiels formulieren. Der Tutor, welcher einen Lernkurs fuer Datenbanken verwaltet, gibt dabei eine Aufgabenstellung in Textform und eine Musterloesung inform eines SQL-Strings an. Der Student muss Anhand des Aufgabentextes einen SQL-Anfrage formulieren welche diese Aufgabe loest. Der die SQL-Anfrage der Muterloesung sowie die des Studenten werden beide nacheinander auf einer Realen PostgreSQL-Datenbank ausgefuert. Die dabei entstehenden Antworten werden verglichen und bei Uebereinstimmung gilt gilt diese Aufgabe fuer den Studenten als Bestanden. Der Tutor kann den Lernsoftschritt aller Studenten Anhand einer Uebersichtstabelle verfolgen. In dieser Tabelle werden alle SQLBox-Aufgaben sowie alle Bentzer einander gegenueber gestellt. === Das Test-Szenario Alle SQLBoxen finden im selben Beispiel-Szenario statt. Dieses Szanario ist in der Datenbank ``sqlbox'' abgebildet. Im Rahmen dieser Arbeit wurde das von Niels Weber entwickelte KAPV-Beispiel uebernommen. Es ist moeglich dieses Szenario zu erweitern oder auch ein vollkommen anderes zu erstellen, in man die Datenbank ``sqlbox'' anpasst. In einer Moodle-Instanz ist es momentan nicht moeglich mehrere verschiedene Beispielumgebungen fuer verschiedene SQLBoxen zu erstellen. === Separierung von Benutzern Der Benutzer der SQLBox muss bei jedem Aufruf einen konsistenen Datenbestand vorfinden. Da es dieses System einem Benutzer gestattet reale Anfragen an eine reale Datenbank zu stellen, koennte dieser den Bestand der Datenbank veraendern oder beschaedigen. Zudem koennen Aufgaben welche das Erstellen oder gezielte Veraendern von Tabellen nur einem einem Benutzer erfuellt werden. Aus diesem Grund ist es notwendig, dass Anfrage von der verschiedenen Benutzer von einander trennen werden. In den Folgenden Abschnitten werden verschieden Moeglichkeiten diskutiert und bewertet, die Trennung der Benutzer erlauben. ==== Transactions Eine Idee ist es, die Eingaben des Nutzers durch Transaktionen zu schützen, indem vor dem Ausführen der Nutzeranfrage eine Transaktion gestartet wird, und danach diese immer zurückgerollt (=ROLLBACK) wird: [source,sql] ---- # sqlbox instruction BEGIN TRANSACTION; # User Input: SELECT * FROM blub; # sqlbox instruction ROLLBACK TRANSACTION; ---- Ein Nutzer könnte aber aus dieser Sandbox ausbrechen, in dem er die gestartet Transaktion beendet, den Datensatz manipuliert und dann eine neue Transaktion startet: [source,sql] ---- # sqlbox instruction BEGIN TRANSACTION; # User Input: INSET INTO blub VALUES (1,'foo') COMMIT TRANSACTION; BEGIN TRANSACTION; SELECT * FROM blub; # sqlbox instruction ROLLBACK TRANSACTION; ---- Dieses Verfahren wuerden einen normalen Betrieb ermoeglichen, indem Fehlerhafte SQL-Anfragen wieder behoben werden. Es biete aber die Moeglichkeit der gezielten Stoerung durch boeswillige Benutzer. Diese koennte alle Tests unbrauchbar machen und damit einen normalen Lernbetrieb verhindern. ==== Separate Datenbank Um die Anfragen der Nutzer von einander zu trennen, gibt es ebenfalls die Moeglichkeit jedem Nutzer eine eigene Datenbank zur Verfuegung zu stellen. Somit koennte der Nutzer in den Test-Szenarien umfassende Aenderungen an der Datenbank vornehmen, ohne andere Nutzer dabei zu beeintraechtigen. Die Uebungen koennen dann nach einander so konstruiert werden, dass der Nutzer die Datenbank in eine bestimmte Richtung hin veraendert. Der groesste Nachteil liegt im erheblichen Verwaltungsaufwand. Es muss bestimmt werden fuer welche Moodle-Nutzer eine Datenbank angelegt wird. Zudem muss es Moeglichkeiten geben, die Datenbanken wieder zurueckzusetzen, sollte ein Nutzer die Datenbank in einen Zustand bringen, der keine erfolgreichen Test mehr erlaubt. Dabei muesste geklaert sein, in welchem Zustand diese geschehen muesste. Entweder in einen Zustand indem der Nutzer an der naechsten noch offenen Aufgabe weiter arbeiten kann, oder in eine Grundzustand, bei dem der Nutzer alle Aufgaben von neuem erfuellen muss. Alle diese Massnahmen wuerden den Entwicklungsaufwand enorm steigern. ==== Keine Schreibrechte Im einfachsten Fall, bekommen die Nutzer nur Lese-Rechte auf die Datenbank. Dieses hat den Vorteil, dass der Verwaltungsaufwand fuer das Modul, sowie der Speicherbedarf der Datenbank verringert wird. Mit dieser Variante, lassen sich hingegen nur +SELECT+-Anfragen stellen. Andere wichtige Anfragen, wie +UPDATE+, +DELETE+, +CREATE+ und +ALTER+ koennten dann nicht innerhalb mit der SQLBox erprobt werden. Dazu wird mit einem priviligierten Account ein Nutzer angelegt, der für die Datenbank nur Leserechte, also für +SELECT+, besitzt: [source,sql] ---- sqlbox=# create user sqlbox_read with password 'XXXXXX'; CREATE ROLE sqlbox=# GRANT SELECT ON ALL TABLES IN SCHEMA public TO sqlbox_read; GRANT ---- ==== Fazit Transaktionen koennten das Risiko von fehlerhafen Anfragen fuer die Datenbank stark reduzieren. Da dieser Mechanismuss aber keinen Schutz vor gezielten Manipulationen bietet, ist er fuer eine Lernplattform mit vielen unbekannten Nutzern ungeeignet. Separate Datenbanken fuer Benutzer bieten eine sehr gute Trennung und verhindern eine direkte gegenseitige Beeinflussung. Der Entwicklungsaufwand des Moodle-Moduls und die genutzten Ressourcen der Datenbank im Betrieb sind zu hoch im Verhaeltniss der anderen Loesungen. Aus disem Grund kommt diese Loesung unter den Umstaenden dieses Projekte nicht in Betracht. Eine Read-Only-Loesung indem es den Benutzern nur erlaubt wird +SELECT+-Anfragen zustellen schraenkt die Vielfalt der Aufgabenmoeglichkeiten ein, aber bietet sichere Trennung der Benutzer sowie einen geringen Entwicklungsaufwand fuer das Modul. Da er Hautpfokus beim Erlernen der SQL-Sprache auf den verschiedensten Moeglichkeiten von Anfragen liegt und das Anlegen von Tabelle und Spalten im Vergleich eher nebensaechlich zubetrachten ist, stellt sich diese Loesung am geeignetsten fuer das Problem der Benutzertrennung unter den aktuellen Umstaenden da. == Literatur * Niels Weber, Diplomarbeit // vim: syntax=asciidoc textwidth=80 :