Kapitel 12 MySQL und PostgreSQL

MySQL und PostgreSQL bringen eine interessante Schnittstelle zur Programmierung eigener Clientanwendungen mit. In diesem Kapitel bekommen Sie einen umfangreichen Überblick.

Das Thema der Datenbankprogrammierung mit der API (Application Programmer Interface = eine Schnittstelle für Programmierer) von MySQL und PostgreSQL stellt einen gewissen Reiz dar. Dass man recht selten etwas dazu in der Literatur findet, liegt an der recht ungemütlichen Hürde, auch Hintergrundwissen zu Datenbanken – sprich SQL – mitzubringen. Und gerade bei einem Buch zur Programmierung kann logischerweise nicht auch noch eine umfassende Einführung zu MySQL oder PostgreSQL gemacht werden. Was allerdings dann eine gewisse Leserschaft ausschließt – da nicht jeder Kenntnisse zu Datenbanken besitzt. Ich versuche dennoch, auf dem schmalen Pfad zu wandern und Ihnen die Programmierung mit der MySQL C-API und der PostgreSQL-API etwas näher zu bringen, ohne dass Sie unbedingt Vorkenntnisse zu den Datenbanken benötigen. Natürlich dürfen Sie dabei nicht erwarten, dass ich Sie damit zu einem Datenbank-Guru mache, sondern ich erkläre Ihnen lediglich, was zum Verständnis für die Programmierung nötig ist. Sollten Sie sich also ernsthaft mit MySQL und/oder PostgreSQL beschäftigen wollen/müssen, so stellt dieses Buch keinen Ersatz für eine entsprechende Fachliteratur dar. Kenner der Datenbank können die ersten Seiten überspringen und gleich mit dem Abschnitt zur Programmierung der jeweiligen API anfangen. Ich muss noch anmerken, dass es mir sehr schwer gefallen ist, auf das eine oder andere zu verzichten, was noch erwähnenswert gewesen wäre.

12.1 Relationales Datenbanksystem 

Um sich mit einer relationalen Datenbank zu befassen, sollten Sie einige grundlegende Kenntnisse darüber besitzen, was es damit auf sich hat.

Zuerst die einfachere Ausführung. Eine relationale Datenbank ist erst einmal nichts anderes als eine Sammlung von Tabellen. In dieser Tabelle sind mehrere Zeilen vorhanden. Eine Zeile ist dabei ein Datensatz. Dieser Datensatz kann wiederum aus mehreren Spalten bestehen, die als Felder bezeichnet werden. Bis hierhin könnte man meinen, ich würde Ihnen das Prinzip einer Tabellenkalkulation erklären. Jedes dieser Felder einer Tabelle besitzt einen bestimmten Datentypen, was ein String, ein Datum oder eine Zahl sein kann. Je nach Datenbanksystem gibt es hierbei erheblich mehr Datentypen, als Sie dies z. B. von C her kennen. Aber – um es gleich von vornherein klarzustellen – so hat ein Integer-Datentyp nichts mit einem int von C zu tun etc.! Es gibt auch so genannte untypisierte Felder für große Binärdaten. Einigen Feldern kommt eine besondere Bedeutung zu: den so genannten Schlüsselfeldern.

So weit, so gut, wenn Sie jetzt allerdings mit einem SQL-Guru über Felder und Spalten reden wollen, dann müssen Sie wohl einige Fachbegriffe lernen. Auch hier sei mir die etwas nüchterne Erklärung verziehen.

Relation – Als Relation wird all das bezeichnet, was ich Ihnen oben in der einfachen Ausführung beschrieben habe – die Tabelle. Eine Relation (Tabelle) kann also wie folgt aufgeteilt werden:

Entität – Mit Entität wird der einzelne Datensatz (Zeile) der Tabelle beschrieben – also der Tabellenname.

Attribut und Attributname – Als Attribut bezeichnet man schlichtweg die Spalte, von der es mindestens eine gibt (so, wie es mindestens eine Zeile gibt). Der Attributname ist die Überschrift der Spalte.

Tupel – Tupel steht für die Zeile bei einer Datenbank. Es ist zwar nicht einfach eine Zeile – aber für das Verständnis sollte dies hier ausreichen. Der Tupel ist ein »Kunstbegriff« der Mathematik.

Grad der Relation – Hiermit ist die Anzahl der Spalten gemeint.

Kardinalität – Hiermit wird die Zeilenanzahl beschrieben.

Domäne – Die Anzahl aller Felder in einer Spalte.

Die einzelnen Entitäten (Tabellennamen) können auch in Beziehungen zueinander stehen. Dabei sind im relationalen Datenbankmodell drei Formen von Beziehungstypen präsent:

1:1-Beziehung – Dabei besteht eine eindeutige Beziehung zwischen zwei Tabellen. Jeder Datensatz einer Tabelle besitzt dabei einen verbundenen Datensatz einer anderen Tabelle. Diese Beziehung lässt sich allerdings auch mit einer einzigen Tabelle darstellen. Beispiel aus dem echten Leben: Der Autor isst einen Donut.

1:n-Beziehung – Dabei sind mit einem Datensatz einer Tabelle mehrere Datensätze einer anderen Tabelle verbunden. Im echten Leben hieße dies: Der Autor isst beliebig viele und unterschiedliche Donuts.

n:m-Beziehung – Hierbei kann ein Datensatz, der einer Tabelle zugeordnet ist, mehreren Datensätzen einer anderen Tabelle zugeordnet sein und umgekehrt. Im Leben hieße dies: Der Autor isst beliebig viele und unterschiedliche Donut-Typen, und (umgekehrt) ein Donut kann auch von mehreren Autoren gegessen werden. Also einfach: Multiple Autoren essen multiple Donuts.

Stricken wir weiter. Die Definition der einzelnen Tabellen und die Beziehung, in der diese zueinander stehen, werden als Datenbankschema bezeichnet. Bei geringen Kenntnissen und einer übertriebenen Befolgung solcher Regeln kann dies allerdings auch zum Nachteil werden. Was bringt es denn, wenn Sie Ihre Datenbank in zehn verschiedene Tabellen aufteilen, weil sie um einen Prozent schneller läuft, und Sie dasselbe mit zwei Tabellen hätten realisieren können? Spätestens wenn Sie Ihre Tabelle warten bzw. erweitern wollen, sehen Sie die Probleme vor sich stehen. Sie stehen vor einem Haufen von Tabellen, wo vielleicht jede Tabelle eine bestimmte Beziehung zu einer anderen hat. Wird dabei eine solche Beziehung vergessen, erhalten Sie, wenn Sie Glück haben, eine Fehlermeldung, und wenn Sie Pech haben, befinden sich zwar die Daten in der Datenbank, werden aber nie berücksichtigt.

Um (bei den Beziehungen) einigen Problemen aus dem Weg zu gehen, gibt es die Normalisierungstheorie. Hier existieren sechs Formen, wovon in der Praxis gewöhnlich nur die ersten drei verwendet werden:

Erste Normalform (1NF) – Jedes Datenfeld (Spalte) beinhaltet nur einen einzigen untrennbaren Wert.

Zweite Normalform (2NF) – Die Relation befindet sich in der ersten Normalform, und jedes Nicht-Schlüsselattribut ist voll funktional von jedem Schlüssel abhängig.

Dritte Normalform (3NF) – Die Relation befindet sich in der zweiten Normalform, und jedes Nicht-Schlüsselattribut ist voll funktional und unabhängig.

Ich möchte es hiermit beim Thema »Datenbankdesign« belassen, weil eine genauere Beschreibung nur zu ein paar mehr Seiten führen würde, was wiederum weniger Seiten zur Programmierung (dem eigentlichen Sinn des Kapitels) bedeuten würde. Es ist hierbei jetzt nicht so wichtig, dass Sie das Prinzip der zweiten oder dritten Normalform verstanden haben – da Sie diese im Buch ohnehin nicht verwenden. (Sie können ausatmen und entspannt weiterlesen!) Sie sollten ohnehin nicht den Sinn einer Datenbank aus den Augen verlieren, denn häufig ist die einfachste Methode die beste. Sofern Sie also kein Datenbank-Guru sind, empfehle ich Ihnen, sich erst mit der ersten Normalform zu befassen, da diese einfacher und schneller zu erstellen und zu pflegen ist.