Base
 

Kapitel 3
Tabellen

Copyright

Dieses Dokument unterliegt dem Copyright © 2015. Die Beitragenden sind unten aufgeführt. Sie dürfen dieses Dokument unter den Bedingungen der GNU General Public License (http://www.­gnu.org/licenses/gpl.html), Version 3 oder höher, oder der Creative Commons Attribution License (http://creativecommons.org/licenses/by/3.0/), Version 3.0 oder höher, verändern und/oder weitergeben.

Warennamen werden ohne Gewährleistung der freien Verwendbarkeit benutzt.

Fast alle Hardware- und Softwarebezeichnungen und weitere Stichworte und sonstige Angaben, die in diesem Buch verwendet werden, sind als eingetragene Marken geschützt.

Da es nicht möglich ist, in allen Fällen zeitnah zu ermitteln, ob ein Markenschutz besteht, wird das Symbol (R) in diesem Buch nicht verwendet.

Mitwirkende/Autoren

Robert Großkopf

Jost Lange

Michael Niedermair

Jochen Schiffers

 

 

Rückmeldung (Feedback)

Kommentare oder Vorschläge zu diesem Dokument können Sie in deutscher Sprache an die Adresse discuss@de.libreoffice.org senden.

Vorsicht

Alles, was an eine Mailingliste geschickt wird, inklusive der E-Mail-Adresse und anderer persönlicher Daten, die die E-Mail enthält, wird öffentlich archiviert und kann nicht gelöscht werden. Also, schreiben Sie mit Bedacht!

Datum der Veröffentlichung und Softwareversion

Veröffentlicht am 15.2.2017. Basierend auf der LibreOffice Version 5.3.

Anmerkung für Macintosh Nutzer

Einige Tastenbelegungen (Tastenkürzel) und Menüeinträge unterscheiden sich zwischen der Macintosh Version und denen für Windows- und Linux-Rechnern. Die unten stehende Tabelle gibt Ihnen einige grundlegende Hinweise dazu. Eine ausführlichere Aufstellung dazu finden Sie in der Hilfedatei des jeweiligen Moduls.

Windows/Linux

entspricht am Mac

Effekt

Menü-Auswahl Extras → Optionen

LibreOffice → Einstellungen

Zugriff auf die Programmoptionen

Rechts-Klick

Control+Klick

Öffnen eines Kontextmenüs

Ctrl (Control)

oder Strg (Steuerung)

(Command)

Tastenkürzel in Verbindung mit anderen Tasten

F5

Shift++F5

Öffnen des Dokumentnavigator-Dialogs

F11

+T

Öffnen des Formatvorlagen-Dialogs

 

Inhalt

Allgemeines zu Tabellen

Beziehungen von Tabellen

Beziehungen zwischen Tabellen allgemein

Tabellen und Beziehungen der Beispieldatenbank

Tabellen Medienaufnahme

Tabellen Ausleihe

Tabellen Nutzerverwaltung

Erstellung von Tabellen

Erstellung mit der grafischen Benutzeroberfläche

Primärschlüssel

Formatierung von Feldern

Einstellung eines Indexes

Änderung bestehender Tabellen

Probleme bei der Änderung von Tabellen

Mängel der grafischen Tabellenerstellung

Direkte Eingabe von SQL-Befehlen

Tabellenerstellung

Tabellenänderung

Tabellen löschen

Verknüpfung von Tabellen

Eingabe von Daten in Tabellen

Eingabe über die grafische Benutzeroberfläche der Tabelle

Sortieren von Tabellen

Suchen in Tabellen

Filtern von Tabellen

Eingabemöglichkeiten über SQL direkt

Neue Datensätze einfügen

Bestehende Datensätze ändern

Bestehende Datensätze löschen

Import von Daten aus anderen Datenquellen

Importierte Daten an bestehende Daten einer Tabelle anfügen

Neue Tabelle beim Import erstellen

Daten Aufsplitten beim Import

Mängel dieser Eingabemöglichkeiten

Tabellen verstecken

 

 

Allgemeines zu Tabellen

Daten werden in Datenbanken innerhalb von Tabellen gespeichert. Wesentlicher Unterschied zu Tabellen innerhalb einer einfachen Tabellenkalkulation ist, dass die Felder, in die geschrieben wird, klar vordefiniert werden müssen. Eine Datenbank erwartet innerhalb einer Textspalte keine Zahleneingaben, mit denen sie rechnen kann. Sie stellt die Zahlen dann zwar dar, geht aber von einem Wert «0» für diese Zahlen aus. Auch Bilder lassen sich nicht in jeder Feldform ablegen.

Welche Datentypen es im einzelnen gibt, kann bei der grafischen Benutzeroberfläche dem Tabelleneditor entnommen werden. Details dafür im Anhang dieses Handbuches.

Einfache Datenbanken beruhen lediglich auf einer Tabelle. Hier werden alle Daten unabhängig davon eingegeben, ob eventuell mehrfache Eingaben des gleichen Inhaltes gemacht werden müssen. Eine einfache Adressensammlung für den Privatgebrauch lässt sich so erstellen. Die Adressensammlung einer Schule oder eines Sportvereins würde aber so viele Wiederholungen bei Postleitzahl und Ort aufweisen, dass diese Tabellenfelder in eine oder sogar 2 separate Tabellen ausgelagert würden. Die Auslagerung von Informationen in andere Tabellen hilft:

Bei der Erstellung der Tabellen sollte also immer wieder überlegt werden, ob eventuell viele Wiederholungen vor allem von Texten oder Bildern (hier stecken die Speicherfresser) in den Tabellen vorkommen. Dann empfiehlt sich eine Auslagerung der Tabelle. Wie dies prinzipiell geht ist in der Einführung im Kapitel «Eine einfache Datenbank – Testbeispiel im Detail» beschrieben.

Hinweis

In einer Datenbank, in der mehrere Tabellen in Beziehung zueinander stehen ("relationale Datenbank"), wird angestrebt, möglichst wenige Daten in einer Tabelle doppelt einzugeben. Es sollen «Redundanzen» vermieden werden.

Dies kann erreicht werden,

  • indem Tabellenfelder nicht zu viel Inhalt auf einmal speichern (z.B. nicht eine komplette Adresse mit Straße, Hausnummer, Postleitzahl und Ort), sondern Straße, Hausnummer, Postleitzahl und Ort getrennt, 

  • doppelte Angaben in einem Feld vermieden werden (z.B. Postleitzahl und Ort aus einer Tabelle in eine andere auslagern) 

Dieses Vorgehen wird als Normalisierung von Datenbanken bezeichnet.

Beziehungen von Tabellen

Anhand der Beispieldatenbanken «Medien_ohne_Makros» bzw. «Medien_mit_Makros» werden in diesem Handbuch viele Schritte möglichst detailliert erklärt. Bereits die Tabellenkonstruktion dieser Datenbank ist sehr umfangreich, da sie neben der Aufnahme von Medien in eine Mediothek auch die Ausleihe von Medien abdeckt.

Beziehungen zwischen Tabellen allgemein

Tabellen in der internen Datenbank haben immer ein unverwechselbares, einzigartiges Feld, den Primärschlüssel. Dieses Feld muss definiert sein, bevor überhaupt Daten in die Tabelle geschrieben werden können. Anhand dieses Feldes können bestimmte Datensätze einer Tabelle ermittelt werden.

Nur in Ausnahmefällen wird ein Primärschlüssel auch aus mehreren Feldern zusammen gebildet. Dann müssen diese Felder zusammen einzigartig sein.

Tabelle 2 kann ein Feld besitzen, das auf die Inhalte von Tabelle 1 hinweist. Hier wird der Primärschlüssel aus Tabelle 1 als Wert in das Feld der Tabelle 2 geschrieben. Tabelle 2 hat jetzt ein Feld, das auf ein fremdes Schlüsselfeld verweist, also einen Fremdschlüssel. Dieser Fremdschlüssel existiert in Tabelle 2 neben dem Primärschlüssel.

Je mehr Tabellen in Beziehung zueinander stehen, desto komplexer kann der Entwurf sein. Das folgende Bild zeigt die gesamte Tabellenstruktur der Beispieldatenbank in einer Übersicht, die von der Größe her die Seite dieses Dokuments sprengt:

 

Abbildung 1: Beziehungsentwurf der Beispieldatenbank «Medien_ohne_Makros»

 

Eins-zu-Viele Beziehungen:

Eine Datenbank für Medien listet in einer Tabelle die Titel der Medien auf. Da es für jeden Titel unterschiedlich viele Untertitel gibt (manchmal auch gar keine) werden in einer gesonderten Tabelle diese Untertitel abgespeichert. Dies ist als eine Eins-zu-viele-Beziehung (1:n) bekannt. Einem Medium werden gegebenenfalls viele Untertitel zugeordnet, z.B. bei dem Medium Mu­sik-CD die vielen Musiktitel auf dieser CD. Der Primärschlüssel der Tabelle "Medien" wird als Fremdschlüssel in der Tabelle "Untertitel" abgespeichert. Die meisten Beziehungen zwischen Tabellen in einer Datenbank sind Eins-zu-viele Beziehungen.

 

Abbildung 2: Beispiel 1:n-Beziehung; n:m-Beziehung

 

Viele-zu-Viele Beziehungen:

Eine Datenbank für eine Bibliothek wird eine Tabelle für den Namen der Verfasser und eine Tabelle für die Medien enthalten. Es gibt einen offensichtlichen Zusammenhang zwischen den Verfasser und z.B. Büchern, die sie geschrieben haben. Die Bibliothek kann mehr als ein Buch desselben Verfassers enthalten. Sie kann aber auch Bücher enthalten, die von mehreren Verfassern stammen. Dies ist als eine Viele-zu-viele-Beziehung (n:m) bekannt. Solche Beziehungen werden durch Tabellen gelöst, die als Mittler zwischen den beiden betroffenen Tabellen eingesetzt werden. Dies ist in der obigen Abbildung die Tabelle "rel_Medien_Verfasser".

Praktisch wird also die n:m-Beziehung über zwei 1:n-Beziehungen gelöst. In der Mittlertabelle kann die "Medien_ID" mehrmals erscheinen, ebenso die "Verfasser_ID". Dadurch, dass beide zusammen den Primärschlüssel ergeben ist nur ausgeschlossen, dass zu einem Medium wiederholt der gleiche Verfasser gewählt wird.

Eins-zu-Eins-Beziehung:

 

Abbildung 3: Beispiel 1:1-Beziehung

 

Die bereits angesprochene Bibliotheks-Datenbank enthält eine Tabelle für die Leser. In dieser Tabelle sind erst einmal nur die direkt notwendig erscheinenden Felder vorgesehen. Für eine Datenbank im Bereich von Schulen würde noch die jeweilige Schulklasse benötigt. Über diese Klasse kann gegebenenfalls auch die Adresse erfahren werden. Eine Aufnahme der Adresse in die Datenbank ist also nicht notwendig. Die Klassenbeziehung des Schülers ist aus der Lesertabelle ausgegliedert, weil nicht in allen Bereichen mit der Zuordnung zu Klassen etwas angefangen werden kann. Dadurch entsteht eine 1:1-Beziehung zwischen Leser und seiner Klassenzuweisung über den entsprechenden Fremdschlüssel in "rel_Leser_Schulklasse".

Handelt es sich um eine Datenbank im öffentlichen Bereich, so wird wohl die Adresse der Leser benötigt. Einem Leser wird hier genau eine Adresse zugeordnet. Würde es mehrere Leser mit der gleichen Adresse geben, so müsste das bei dieser Konstruktion zu einer Neueingabe der Adresse führen, denn der Primärschlüssel aus der Tabelle "Leser" wird direkt als Primärschlüssel in die Tabelle "Adresse" eingetragen. Primärschlüssel und Fremdschlüssel sind in der Tabelle "Adresse" eins. Hier besteht also eine 1:1-Beziehung.

Eine 1:1-Beziehung bedeutet nicht, dass automatisch zu jedem Datensatz der einen Tabelle auch ein Datensatz der anderen Tabelle existiert. Es existiert allerdings höchstens ein Datensatz. Durch die 1:1-Beziehung werden also Felder ausgelagert, die vermutlich nur bei einem Teil der Datensätze mit Inhalt gefüllt sein werden.

Tabellen und Beziehungen der Beispieldatenbank

Die Beispieldatenbank muss drei verschiedene Aufgabenbereiche erfüllen. Zuerst einmal müssen Medien in die Datenbank aufgenommen werden. Dies soll so erfolgen, dass auch eine Bibliothek damit arbeiten kann.

Tabellen Medienaufnahme

Zentrale Tabelle der Medienaufnahme ist die Tabelle Medien. In dieser Tabelle werden alle Felder direkt verwaltet, die vermutlich nicht auch von anderen Medien mit dem gleichen Inhalt belegt werden. Doppelungen sollen also vermieden werden.

Aus diesem Grund sind in der Tabelle z.B. der Titel, die ISBN-Nummer, ein Bild des Umschlags oder das Erscheinungsjahr vorgesehen. Die Liste der Felder kann hier entsprechend erweitert werden. So sehen Bibliotheken z.B. Felder für den Umfang (Seitenanzahl), den Reihentitel und ähnlichem vor.

Die Tabelle Untertitel soll dazu dienen, z.B. den Inhalt von CDs im Einzelnen aufzunehmen. Da auf einer CD mehrere Musikstücke (Untertitel) vorhanden sind würde eine Aufnahme der Musikstücke in die Haupttabelle dazu führen, dass entweder viele zusätzliche Felder (Untertitel 1, Untertitel 2 usw.) erstellt werden müssten oder das gleiche Medium mehrmals hintereinander eingegeben werden müsste. Die Tabelle Untertitel steht also in einer n:1-Beziehung zu der Tabelle Medien.

Felder der Tabelle Untertitel sind neben  dem Untertitel selbst die Nummerierung der Reihenfolge der Titel und die Dauer der Untertitel. Das Feld Dauer ist erst einmal als ein Zeitfeld vorgesehen. So kann gegebenenfalls die Gesamtdauer der CD in einer Übersicht berechnet und ausgegeben werden.

Die Verfasser haben zu den Medien eine n:m-Beziehung. Ein Medium kann mehrere Verfasser haben, ein Verfasser kann mehrere Medien herausgebracht haben. Dies wird mit der Tabelle rel_Medien_Verfasser geregelt. Primärschlüssel dieser Verbindungstabelle sind die Fremdschlüssel, die aus der Tabelle Verfasser und Medien ausgegeben werden. In der Tabelle rel_Medien_Verfasser wird zusätzlich noch eine Sortierung der Verfasser vorgenommen (z.B. nach der Reihenfolge, wie sie im Buch genannt werden). Außerdem wird gegebenenfalls ein Zusatz wie «Herausgeber», «Fotograf» o.ä. dem jeweiligen Verfasser beigefügt.

Kategorie, Medienart, Ort und Verlag haben jeweils eine 1:n-Beziehung.

In der Kategorie kann bei kleinen Bibliotheken so etwas stehen wie «Kunst», «Biologie» … Bei größeren Bibliotheken gibt es gängige Systematiken wie z.B. die ASB (allgemeine Systematik für Bibliotheken). Bei dieser Systematik gibt es Kürzel und ausführlichere Beschreibungen. Daher die beiden Felder für die Kategorie.

Die Medienart ist gekoppelt mit der Ausleihzeit. So kann es z.B. sein, dass Video-DVDs grundsätzlich nur eine Ausleihzeit von 1 Woche haben, Bücher aber eine von 3 Wochen. Wird die Ausleihzeit an ein anderes Kriterium gekoppelt, so muss entsprechend anders verfahren werden.

Die Tabelle Ort dient nicht nur dazu, die Ortsbenennungen aus den Medien aufzunehmen. In ihr werden gleichzeitig die Orte gespeichert, die für die Adressen der Nutzer Bedeutung haben.

Da der Verlag vermutlich auch häufiger vorkommt, ist für seine Eingabe ebenfalls eine gesonderte Tabelle vorgesehen.

 

Abbildung 4: Medienaufnahme

 

Die Tabelle Medien hat so insgesamt vier Fremdschlüssel und einen Primärschlüssel, der für 2 Tabellen der Abbildung Medienaufnahme zum Fremdschlüssel wird.

Tabellen Ausleihe

 

Abbildung 5: Ausleihe

 

Zentrale Tabelle ist die Ausleihe. In ihr werden die Tabellen Medien und Leser verknüpft. Da auch später noch nachvollzogen werden soll, wer ein Buch ausgeliehen hat (falls z.B. jemand beim Ausleihen bemerkt, dass das Buch beschädigt ist, oder falls eine Hitliste der Medien erstellt werden soll) wird der Datensatz in der Ausleihe bei der Rückgabe nicht einfach gelöscht. Vielmehr wird ein Rückgabedatum (Rueck_Datum) vermerkt.

Ebenso in die Ausleihe integriert ist das Mahnverfahren. Um die Anzahl der Mahnungen zu erfassen wird jede Mahnung separat in der Tabelle Mahnung eingetragen.

Neben der Verlängerung um einzelne Wochen steht noch ein gesondertes Feld in der Ausleihe, das es ermöglicht, Medien über einen Barcodescanner zu entleihen (Medien_ID_BC). Barcodes enthalten neben der eigentlichen "Medien_ID" auch eine Prüfziffer, mit der das Gerät feststellen kann, ob der eingelesene Wert korrekt ist. Dieses Barcodefeld ist hier nur testweise eingebaut. Besser wäre es, wenn der Primärschlüssel der Tabelle Medien direkt in Barcode-Form eingegeben würde oder per Makro aus der eingelesenen Barcodeziffer einfach die Prüfziffer vor dem Abspeichern entfernt wird.

Schließlich ist noch der Leser mit der Ausleihe in Verbindung zu bringen. In der eigentlichen Lesertabelle wird lediglich der Name, eine eventuelle Sperrung und ein Fremdschlüssel für eine Verbindung zur Tabelle Geschlecht vorgesehen.

Tabellen Nutzerverwaltung

In dieser Tabellenkonstruktion werden gleich zwei Szenarien bedient. Der obere Tabellenstrang ist dabei auf Schulen zugeschnitten. Hier werden keine Adressen benötigt, da die Schüler und Schülerinnen über die Schule selbst ansprechbar sind. Mahnungen müssen nicht postalisch zugestellt werden, sondern auf dem internen Wege weitergegeben werden.

Der Adressstrang ist dagegen bei öffentlichen Bibliotheken notwendig. Hier müssen sämtliche Daten erfasst werden, die zu Erstellung eines Mahnbriefes erforderlich sind.

Die Tabelle Geschlecht dient dazu, die richtige Anrede bei Mahnschreiben zu wählen. Die Mahnschreiben sollen schließlich möglichst automatisiert erfolgen. Außerdem gibt es Vornamen, die sowohl für männliche als auch für weibliche Leser stehen können. Deswegen ist die Abspeicherung des Geschlechts auch bei der Erstellung von handgeschriebenen Mahnungen sinnvoll.

 

Abbildung 6: Leser - ein Schulklassenstrang und ein Adressenstrang

 

Die Tabelle rel_Leser_Schulklasse steht wie die Tabelle Adresse in einer 1:1-Beziehung zu der Tabelle "Leser". Dies ist gewählt worden, weil entweder die eine oder die andere Möglichkeit beschritten werden soll. Sonst könnte die "Schulklasse_ID" direkt in der Tabelle Schüler existieren; gleiches gilt für den gesamten Inhalt der Tabelle Adresse.

Eine Schulklasse wird in der Regel durch eine Jahrgangsbezeichnung und einen Klassenzusatz gekennzeichnet. Bei einer 4-zügigen Schule kann dieser Zusatz z.B. von a bis d gehen. Der Zusatz wird in der Tabelle "Klasse" eingetragen. Der Jahrgang hat eine separate Tabelle. Sollen am Schluss eines Schuljahres die Leser aufgestuft werden, so wird einfach der Jahrgang für alle geändert.

Die Adresse wird ebenfalls sehr differenziert dargestellt. Die Straße ist aus der Adresse ausgelagert, da Straßennahmen innerhalb eines Ortes häufiger wiederholt werden. Postleitzahl und Ort sind voneinander getrennt, da oft mehrere Postleitzahlen für einen Ort gelten. Für die Post sind alle Ortsbezeichnungen, die auf die gleiche Postleitzahl passen, in einem Ort zusammengefasst. Es existieren postalisch also deutlich mehr Postleitzahlen als Orte. So werden von der Tabelle Adresse aus gesehen deutlich weniger Datensätze in der Tabelle Postleitzahl stehen und noch einmal deutlich weniger Datensätze in der Tabelle Ort existieren.

Wie eine derartige Tabellenkonstruktion später sinnvoll zu befüllen ist, wird weiter unten im Kapitel Formulare erläutert.

Erstellung von Tabellen

In der Regel wird sich der LibreOffice-User auf die Erstellung von Tabellen mit der grafischen Benutzeroberfläche beschränken. Die direkte Eingabe von SQL-Befehlen ist dann sinnvoll, wenn z.B. ein Tabellenfeld nachträglich an einer bestimmten Position eingefügt werden soll oder Standardwerte nach Abspeicherung der Tabelle noch gesetzt werden sollen.

Bezeichnungen bei Tabellen:

 

Die obige Skizze zeigt die allgemein übliche Aufteilung von Tabellen in Spalten und Zeilen. Die entsprechenden Datenbankbezeichnungen sind in Klammern hinzugefügt.

Datensätze werden in der Tabelle in einer Zeile gespeichert. Die einzelnen Spalten werden durch das Feld, den Typ und die Festlegung, ob das Feld leer sein darf, weitgehend beschrieben. Je nach Typ kann noch der Umfang an Zeichen festgelegt werden. Außerdem kann ein Standardwert eingegeben werden, der immer dann abgespeichert wird, wenn keine Eingabe erfolgt.

In der grafischen Benutzeroberfläche von Base sind die Begriffe einer Spalte etwas anders umschrieben:

 

Feld wird zu Feldname, Typ wird zu Feldtyp. Feldname und Feldtyp werden im oberen Bereich des Tabelleneditors eingegeben. Im unteren Bereich gibt es dann die Möglichkeit, unter den Feldeigenschaften die anderen Spalteneigenschaften festzulegen, sofern dies durch die GUI festlegbar ist. Grenzen sind hier z.B., den Defaultwert eines Datumsfeldes mit dem bei der Eingabe aktuellen Datum festzulegen. Dies geht nur über eine entsprechende SQL-Eingabe, siehe dazu die Felddefinition im Kapitel Direkte Eingabe von SQL-Befehlen.

Hinweis

Defaultwert: Der Begriff «Defaultwert» in der GUI entspricht nicht dem, was Datenbanknutzer unter Defaultwert verstehen. Die GUI gibt hier einen bestimmten Wert sichtbar vor, der dann mit abgespeichert wird.

Der Defaultwert einer Datenbank wird in der Tabellendefinition gespeichert. Er wird dann in das Feld geschrieben, wenn es bei der neuen Erstellung eines Datensatzes nicht bearbeitet wurde und deshalb nicht im SQL-Code auftaucht. SQL-Defaultwerte erscheinen auch nicht bei der Bearbeitung der Eigenschaften einer Tabelle.

Erstellung mit der grafischen Benutzeroberfläche

Die Erstellung innerhalb der grafischen Benutzeroberfläche wird beispielhaft für die Tabelle Medien Schritt für Schritt erklärt.

 

Durch einen Klick auf Tabelle in der Entwurfsansicht erstellen wird der Tabelleneditor gestartet.

  1. 1.ID-Feld: 

Tipp

Die Erstellung einer Verknüpfung zur Auswahl aus der Auswahlliste Feldtyp: Drücken Sie die Taste für den ersten Buchstaben der Wahl. Sie können die Auswahl durch wiederholtes Drücken des Buchstabens wechseln. Zum Beispiel wechselt das Drücken der Taste D von «Datum» auf «Datum/Zeit» bzw. danach auf «Dezimal».

Hinweis

  1. Der Primärschlüssel dient nur einem Zweck – nämlich zur eindeutigen Identifizierung des Datensatzes. Daher kann ein beliebiger Name für dieses Feld verwendet werden. Im Beispiel wurde die allgemein übliche Bezeichnung ID (Identifikation) verwendet.

 
  1. 2.Das nächste Feld ist das Feld «Titel» 

 
 
  1. 3.Beschreibung kann alles sein, Die Spalte kann auch leer gelassen werden. Die Beschreibung dient nur zur Erklärung des Feldinhaltes für Personen, die sich später einmal den Tabellenentwurf ansehen wollen. 

  2. 4.Für das Feld «E_Jahr» wird der Zahlentyp Small Integer [SMALLINT] gewählt. Dabei handelt es sich um eine maximal fünfstellige ganze Zahl. Mit dem Erscheinungsjahr soll zwar nicht gerechnet werden, es sollte aber zumindest vermieden werden, dass dort Buchstaben auftauchen. 

  3. 5.Für das Feld «Kategorie_ID» wird der Feldtyp Integer [INTEGER] gewählt. Da in der Tabelle «Kategorie» der Primärschlüssel diesen Feldtyp haben soll muss auch der hier eingetragene Fremdschlüssel den gleichen Feldtyp haben.
    Das gilt dann entsprechend auch für die nachfolgenden Fremdschlüssel «Medienart_ID», «Ort_ID» und «Verlag_ID».
     

  4. 6.Für die Wertangabe wird der Feldtyp Zahl [NUMERIC] oder auch Dezimal [DECIMAL] gewählt. Diese beiden Zahlenfelder können Zahlen mit Nachkommastellen speichern. 

  1. 7.Für das Feld «ISBN» wird der Feldtyp Zahl [NUMERIC] gesetzt. Dieser kann genau auf die Feldlänge einer ISBN-Nummer eingestellt werden. ISBN-Nummern sind 10 oder 13 Zeichen lang. Sie werden also später als Zahl ohne Trenner gespeichert.
    Die Länge wird entsprechend auf maximal 13 Zeichen eingestellt. Nachkommastellen bleiben dabei auf 0 gesetzt.
     

  2. 8.Die Tabelle wird mit dem Namen «Medien» abgespeichert. 

Die zentrale Tabelle für die Beispieldatenbank wurde nun erstellt. Mit dem entsprechenden Verfahren können alle weiteren Tabelle ebenfalls erstellt werden. Achten Sie immer darauf, dass der Feldtyp zusammen mit den Feldeigenschaften vorbestimmt, was in dem Feld abgespeichert werden kann. Dies ist anders als in einer Tabellenkalkulation, die vollkommen durchmischte Eingaben in einer Spalte zulassen.

Hinweis

  1. Die Reihenfolge der Felder in der Tabelle kann nur bis zum ersten Abspeichern über die grafische Benutzeroberfläche beeinflusst werden. Sie lässt sich später nur bei der Eingabe der Daten direkt in die Tabelle nicht mehr ändern.

    In Abfragen, Formularen oder Berichten ist die Reihenfolge allerdings weiterhin frei zusammenstellbar.

Primärschlüssel

Wird beim Tabellenentwurf kein Primärschlüssel festgelegt, so erscheint beim Abspeichern eines Tabellenentwurfs die Nachfrage, ob ein Primärschlüssel erstellt werden soll. Dies deutet darauf hin, dass ein wesentliches Feld in der Tabelle fehlt. Ohne einen Primärschlüssel kann die interne Datenbank auf die Tabelle nicht zugreifen. In der Regel wird dieses Feld mit dem Kürzel "ID" bezeichnet, mit dem Zahlentyp INTEGER versehen und als «AutoWert» automatisch mit einer fortlaufenden Nummer versehen. Mit einem Rechtsklick auf das entsprechende Feld kann es zum Primärschlüsselfeld erklärt werden.

Es können ohne weiteres auch mehrere Felder zum gemeinsamen Primärschlüssel erstellt werden. Hierzu müssen nur die entsprechenden Felder gemeinsam markiert werden (Taste Strg oder Shift gedrückt halten). Dann kann über den Rechtsklick der Primärschlüssel allen markierten Feldern zugewiesen werden.

Sollen von einer anderen Tabelle in dieser Tabelle Informationen mitgeführt werden (Beispiel: Adressdatenbank, aber ausgelagert Postleitzahlen und Orte), so ist ein Feld mit dem gleichen Datentyp wie dem des Primärschlüssels der anderen Tabelle in die Tabelle aufzunehmen. Angenommen die Tabelle "PLZ_Ort" hat als Primärschlüssel das Feld "ID", als Datentyp 'Tiny Integer'. In der Tabelle Adressen erscheint jetzt ein Feld "ID_PLZ_Ort" mit dem Datentyp 'Tiny Integer'. Es wird also in der Tabelle Adressen immer nur die Zahl eingetragen, die als Primärschlüssel in der Tabelle "PLZ_Ort" steht. Für die Tabelle "Adresse" heißt das: Sie hat einen Fremdschlüssel zusätzlich zum eigenen Primärschlüssel bekommen.

Grundlage bei der Namenswahl von Feldern in der Tabelle: Keine 2 Felder dürfen gleich heißen. Deswegen darf auch nicht ein zweites Feld mit der Bezeichnung "ID" als Fremdschlüssel in der Tabelle "Adressen" auftauchen.

Die Feldtypen können nur begrenzt geändert werden. Eine Aufstufung (längeres Textfeld, größerer Zahlenumfang) ist ohne weiteres möglich, da alle eventuell schon eingegebenen Werte diesem Feldtyp entsprechen. Eine Abstufung wirft eher Probleme auf. Hier droht gegebenenfalls Datenverlust.

Zeitfelder in Tabellen können nicht als Felder mit Bruchteilen einer Sekunde dargestellt werden. Dies geht nur mit einem Timestamp-Feld. Mit der grafischen Benutzeroberfläche wird allerdings nur ein Timestamp-Feld erzeugt, das Datum, Stunde, Minute und Sekunde abspeichert. Dieses Feld muss über Extras → SQL noch entsprechend verändert werden.

ALTER TABLE "Tabellenname" ALTER COLUMN "Feldname" TIMESTAMP(6)

Mit dem Parameter «6» wird das Timestamp-Feld bei der internen HSQLDB auch für Bruchteile von Sekunden aufnahmefähig.
Die Firebird-Datenbank benötigt diese Parameter nicht, kann zur Zeit aber leider über die GUI noch keine Millisekunden in Zeitfeldern oder Timestampfeldern speichern.

Formatierung von Feldern

Die Formatierung stellt die Werte der Datenbank für den Nutzer dar und erlaubt eine Eingabe von Werten in Abhängigkeit von landesüblichen Eingabeformen. Ohne Formatierung werden Dezimalstellen mit einem Punkt abgetrennt ( 4.21 statt 4,21 ), Datumswerte im Format 2014-12-22 dargestellt. Bei der Einstellung der Formatierung muss deshalb auf die Landeseinstellung geachtet werden.

Die Formatierung zeigt die Inhalte nur an. Eine Datumsdarstellung mit einer zweistelligen Jahreszahl wird dennoch als vierstellige Jahreszahl gespeichert. Wird ein Feld für eine Zahl mit zwei Nachkommastellen erstellt, wie es bei der Überziehungsgebühr in dem folgenden Beispiel der Fall ist, so wird auch eine Zahl mit zwei Nachkommastellen gespeichert, auch wenn irrtümlich die Formatierung vielleicht ohne Nachkommastellen erstellt wurde. Eine Zahl mit zwei Nachkommastellen lässt sich sogar in ein Feld eingeben, das ohne Nachkommastellen formatiert wurde. Die Nachkommastellen verschwinden scheinbar bei der Eingabe, werden aber wieder sichtbar, wenn die Formatierung angepasst wird.

Soll nur eine Zeit, aber kein Datum gespeichert werden, so sollte die Tabelle entsprechend z.B. so formatiert werden, dass nur Minuten, Sekunden und Zehntelsekunden abgefragt werden: MM:SS,00. Eine Formatierung mit Nachkommastellen ist später in Formularen nur über das formatierte Feld, nicht über das Zeitfeld möglich.

Die Formatierung von Feldern wird bei Erstellung der Tabelle oder auch anschließend in den Feldeigenschaften über einen gesonderten Dialog vorgenommen:

 

Über den Button in Feldeigenschaften → Format-Beispiel wird der Dialog zur Änderung des Formates gestartet.

 

Für die Erstellung von Feldern, die eine Währung aufnehmen sollen, ist darauf zu achten, dass die Zahlenfelder zwei Nachkommastellen haben. Die Formatierung kann in der Tabellenerstellung der grafischen Benutzeroberfläche in der gewünschten Währung für die Eingabe in die Tabelle vorgenommen werden. Dies hat allerdings nur Auswirkungen auf die Eingabe in der Tabelle und auf Abfragen, die den Wert ohne Umrechnungen auslesen. In Formularen muss die Währungsbezeichnung gesondert formatiert werden.

Hinweis

Base speichert zur Zeit nur die Formatierungen der Tabelle ab, die entweder beim Erstellen der Tabelle oder bei der Eingabe von Daten über die Spaltenköpfe erfolgt. Dies gilt auch für die Spaltenbreiten bei der Eingabe.

Gesonderte Formatierungen von Abfragen werden dagegen nicht gespeichert.

Bei Feldern, die einen Prozentsatz aufnehmen sollen, ist darauf zu achten, dass 1 % bereits als 0,01 gespeichert werden muss. Die Prozentschreibweise beansprucht also schon standardmäßig 2 Nachkommastellen. Sollen Prozentwerte wie 3,45 % abgespeichert werden, so sind also 4 Nachkommastellen bei dem numerischen Wert notwendig.

Hinweis

Hin und wieder tauchen in Formularen in einem Tabellenkontrollfeld Textfelder auf, die in einer Datenbank plötzlich einheitlich als '0' und nicht mit dem vorgesehenen Inhalt angezeigt werden. Hier hilft manchmal ein Blick in die Formatierung der Tabelle. Steht im Format-Beispiel eines Textfeldes statt einem «@» eine «0», so ist beim Format des Feldes etwas nicht in Ordnung. Lässt sich das Format des Feldes in dem Dialog nicht so ohne weiteres ändern, so kann es hilfreich sein, einen Blick auf die Sprache zu werfen. Hier kann zwischen verschieden Sprachwahlen eingestellt werden. Ein Umstellen der Sprache auf eine andere Sprache und anschließend zurück auf Sprache → Standard (Deutschland) führt dazu, dass anschließend wieder «@» statt «0» in der Formatierung gezeigt wird. Anschließend erscheint auch wieder der Text in den Tabellenkontrollfeldern des Formulars.

Dieser Bug ist ab der Version LibreOffice 4.3.2 behoben.

Einstellung eines Indexes

Manchmal erscheint es sinnvoll, neben dem Primärschlüssel auch andere Felder oder eine Kombination anderer Felder mit einem Index zu versehen. Ein Index dient dazu, Suchergebnisse schneller zu erhalten. Er kann außerdem dazu genutzt werden, Doppeleingaben zu vermeiden.

Jeder Index hat eine fest definierte Sortierreihenfolge. Wird eine Tabelle ohne Sortierung aufgerufen, so richtet sich die Sortierreihenfolge immer nach der Sortierreihenfolge der als Index definierten Felder.

 

Abbildung 7: Zugriff auf den Indexentwurf

 

Zuerst muss die Tabelle mit einem rechten Mausklick über das Kontextmenü zum Bearbeiten geöffnet werden. Der Zugriff auf den Indexentwurf erfolgt dann über Extras → Indexentwurf…  oder direkt über den entsprechenden Button in der Menüleiste des Tabellenentwurfes.

 

Abbildung 8: Erstellen eines neuen Indexes

 

Über «Neuer Index» wird ein Index neben dem des Primärschlüssels erstellt.

 

Abbildung 9: Der Index wird als «Eindeutig» definiert.

 

Dem neuen Index wird automatisch die Bezeichnung «index1» zugewiesen. Diese Bezeichnung kann geändert werden. Im Indexfeld wird ausgewählt, welches Feld bzw. welche Felder über den Index verwaltet werden sollen. Dabei wird gleichzeitig eine Sortierung eingestellt.

Ein Index kann prinzipiell auch über Tabellenfelder erstellt werden, die keine eindeutigen Werte haben. Im obigen Bild ist aber das Index-Detail «Eindeutig» gewählt, so dass in das Feld "Nachname" zusammen mit dem Feld "Vorname" nur Werte eingegeben werden können, die dort in der Kombination noch nicht stehen. So ist z.B. Robert Müller und Robert Maier möglich, ebenso Robert Müller und Eva Müller.

Wird ein Index über ein Feld erstellt, so wird die Eindeutigkeit auf ein Feld bezogen. Ein solcher Index ist in der Regel der Primärschlüssel. In diesem Feld darf jeder Wert nur einmal vorkommen. Beim Primärschlüssel darf allerdings zusätzlich das Feld auf keinen Fall NULL sein.

Eine Sonderstellung für einen eindeutigen Index nimmt in einem Feld das Fehlen eines Eintrages, also NULL, ein. Da NULL alle beliebigen Werte annehmen könnte ist es ohne weiteres erlaubt, bei einem Index über zwei Felder in einem Feld mehrmals hintereinander die gleiche Eingabe zu tätigen, solange in dem anderen Feld keine weitere Angabe gemacht wird.

Hinweis

NULL ist für Datenbanken die Bezeichnung für eine leere Zelle, die nichts enthält. Mit einem Feld, das NULL ist kann also nicht gerechnet werden. Im Gegensatz dazu gehen Tabellenkalkulationen bei leeren Feldern automatisch davon aus, dass der Inhalt «0» ist.

Beispiel: In einer Mediendatenbank wird für die Ausleihe die Mediennummer und das Ausleihdatum eingegeben. Wird das Medium zurückgegeben, so wird dies durch ein Rückgabedatum vermerkt. Nun könnte ein Index über die Felder "Mediennummer" und "Rückgabedatum" doch leicht verhindern, dass das gleiche Medium mehrmals ausgeliehen wird, ohne dass die Rückgabe vermerkt wurde. Dies funktioniert aber leider nicht, da das Rückgabedatum ja noch nicht mit einem Wert versehen ist. Der Index verhindert stattdessen, dass ein Medium zweimal mit dem gleichen Datum zurückgegeben wird – sonst nichts.

Änderung bestehender Tabellen

Nicht alle Tabellen werden bereits beim Erstellen so weit durchgeplant sein, dass keine Änderungen mehr vorzunehmen sind. Mit einem rechten Mausklick auf eine Tabelle wird das folgende Kontextmenü sichtbar:

 

Mit einem Klick auf Bearbeiten öffnet sich der grafische Bearbeitungsmodus. Hier können Feldnamen, Feldtypen und Formate geändert werden. Natürlich können auch weitere Felder hinzugefügt werden.

Die Änderungen sind allerdings nicht völlig problemlos möglich. Soll ein Feldname geändert werden, so ist es angeraten, zuerst den neuen Namen zusätzlich einzutragen und dann die vorherige Benennung zu entfernen. Andernfalls verschwindet das ganze Feld.

Neue Felder können nur am Ende der Liste hinzugefügt werden, auch wenn der Bearbeitungsmodus etwas anderes scheinbar ermöglicht. Das Einfügen eines Feldes mitten in eine Liste ist nicht möglich.

Auch Kommentare zu vorher erstellten Feldern werden bei einer anschließenden Tabellenänderung oft nicht mit abgespeichert.

Sind bereits erst einmal mehrere Tabellen erstellt worden, so können die Beziehungen zwischen den Tabellen eine Änderung von Feldeigenschaften blockieren. Als Beziehungen nimmt die Datenbank sowohl die unter Extras → Beziehungen erstellten Verknüpfungen als auch die in Tabellenansichten erstellten Beziehungen wahr.

Probleme bei der Änderung von Tabellen

Tabellen sollten am besten direkt bei der Erstellung komplett mit allen nötigen Einstellungen versehen werden. Sollen hinterher die Eigenschaften von Feldern verändert werden (Feldname, erforderliche Eingabe usw.), so kann das häufig zu einer Fehlermeldung führen, die nicht Ursache der GUI ist, sondern in der darunterliegenden Datenbank begründet ist.

 

Hier sollte das Feld "Betrag" in der Eigenschaft «Eingabe erforderlich» auf «Ja» umgestellt werden. Das Warnsymbol macht bereits darauf aufmerksam: Die Änderung kann zu einem Verlust von Daten führen. Eine einfache Änderung ist nicht möglich. Bereits vorher ausgeschlossen wurde, dass in dem Feld "Betrag" eventuell ein Datensatz ohne Eingabe existiert.

Ein Klick auf Ja führt zu einer weiteren Fehlermeldung, da die Datenbank die Löschung nicht zulässt. Ein Klick auf Nein bricht den gesamten Vorgang ab. Häufig wird die Frage nach mehr Informationen gar nicht erst gestellt, weil die Informationen nur mit etwas gründlicherem Wissen auch sinnvoll zu einer anderen Handlungsweise und dann zum gewünschten Ziel führen können.

 

Die Fehlermeldung Column is referenced in constraint or view bedeutet:
Auf die Spalte mit dem Feldnamen "Betrag" wird an anderer Stelle der Datenbank bereits Bezug genommen. Dies kann eine
Bedingungsdefinition oder eine Tabellenansicht sein, die nach dem Erstellen der Tabelle von dem Nutzer erstellt wurde. In der obigen Abbildung wird noch darauf hingewiesen, wie der Name der Bedingungsdefinition oder Ansicht heißt: "Ansicht_Kasse_mit_Umbuchungen". Damit ist für den Nutzer klar, an welcher Stelle angesetzt werden muss. Zuerst sollte der SQL-Code der Ansicht z.B. in einer Abfrage gesichert werden, dann die Ansicht gelöscht werden und danach kann ein neuer Versuch starten.

 

Wieder die entsprechende Meldung, nur mit einer umfangreicheren Erklärung. Nur der sinnvollen Benennung der Bedingung «Konto ungleich Umbuchungskonto» ist es zu verdanken, dass die Bedingungsdefinition auch auffindbar ist. Hier ist der Spalte mit dem Feldnamen "Konto_ID" die Bedingung zugeordnet worden, dass eine weitere Spalte in der gleichen Tabelle im gleichen Datensatz nicht den gleichen Wert haben darf. Erst wenn diese Bedingung wieder entfernt wird ist es möglich, einen erneuten Versuch zu starten, die Spalte zu verändern.

Taucht jetzt noch wieder ein Fehler auf, so liegt dieser häufig darin begründet, dass das entsprechende Feld mit einem Feld einer anderen Tabelle in der Beziehungsdefinition verknüpft wurde. Hier muss dann zuerst die Beziehung unter Extras → Beziehungen gelöst werden, bevor die Änderung vorgenommen werden kann.

Mängel der grafischen Tabellenerstellung

Die Reihenfolge der Tabellenfelder kann im Anschluss an den Abspeichervorgang nicht mehr geändert werden. Für eine Darstellung in anderer Reihenfolge ist dann eine Abfrage notwendig. Dies gilt, obwohl die grafische Benutzeroberfläche etwas anderes vortäuscht. Hier kann bei der Tabellenerstellung und bei der Tabellenbearbeitung ein Kontextmenü aufgerufen werden, das z.B. anbietet, Felder auszuschneiden und an anderer Stelle einzufügen. Damit sind dann aber nur die Feldbezeichnungen und die Feldtypen gemeint, nicht aber die Inhalte der Tabelle. Die tauchen nach so einer Änderung mit anderer Feldbezeichnung und eventuell auch anderem Feldtyp wieder auf.1

Nur über direkte SQL-Eingabe kann ein neues Feld an eine bestimmte Position innerhalb der Tabelle rutschen. Bereits erstellte Felder sind aber auch hier nicht beweglich.

Eigenschaften der Tabellen sollten sofort festgelegt werden. Welche Felder sollen nicht NULL sein, welche einen Standardwert (Default) erhalten. Diese Eigenschaft kann hinterher häufig nur unter Berücksichtigung der oben genannten Fehlermeldungen geändert werden.

Die dort abgelegten Default-Werte haben nichts mit den in der Datenbank selbst liegenden De­fault-Werten zu tun. So kann dort z.B. bei einem Datum nicht als Standard das aktuelle Datum vorgegeben werden. Dies ist der direkten Eingabe über SQL vorbehalten.

Direkte Eingabe von SQL-Befehlen

Die direkte Eingabe von SQL-Befehlen ist über das Menü Extras → SQL erreichbar.

 

Hier werden Befehle im oberen Fensterbereich eingegeben; im unteren Bereich wird der Erfolg oder gegebenenfalls die Gründe für den fehlenden Erfolg (auf Englisch) mitgeteilt. Abfragen können hier unter «Ausgabe» dargestellt werden, wenn das Ankreuzfeld markiert wird.

 

Abbildung 10: Fenster für direkte Eingabe von SQL-Befehlen

 

Eine Übersicht der für die eingebaute HSQLDB möglichen Eingaben ist unter http://www.hsqldb.org/doc/1.8/guide/ch09.html zu finden. Die dortigen Inhalte werden in den folgenden Abschnitten erklärt. Einige Befehle machen nur Sinn, wenn es sich dabei um eine externe HSQLDB handelt (Benutzerangaben usw.) Sie werden gegebenenfalls im Abschnitt «Datenbankverbindung zu einer externen HSQLDB» aufgeführt.

Hinweis

LibreOffice liegt die Version 1.8.0 der HSQLDB zugrunde. Die aktuell erhältliche Serverversion hat die Version 2.2. Die Funktionen der neuen Version sind umfangreicher. Sie sind direkt über http://hsqldb.org/web/hsqlDocsFrame.html zu erreichen. Die Beschreibung der Version 1.8 erfolgt jetzt unter http://www.hsqldb.org/doc/1.8/guide/ . Außerdem ist sie in Installationspaketen zur HSQLDB enthalten, die von http://sourceforge.net/projects/hsqldb/files/hsqldb/ heruntergeladen werden können.

Für die interne Firebird-Datenbank wurden die entsprechenden Informationen aus http://www.firebirdsql.org/en/documentation/ herangezogen. Hier liegt zum Erscheinen der Version LO 5.3 allerdings nur eine ausführliche Dokumentation zu Firebird-Version 2.5, nicht zur in LO 5.3 verbauten Firebird-Version 3.0, vor. Auch hier gilt natürlich: Längst nicht alle Funktionen der externen Datenbank haben für die interne Datenbank eine Bedeutung. Manche der intern gut nutzbaren Funktionen sind leider auch noch nicht in LO 5.3 umgesetzt.

Viele Funktionen stehen für beide Datenbanken zur Verfügung. Unterschiede  zwischen der HSQLDB und Firebird werden entsprechend gekennzeichnet. Mit Grün ist gekennzeichnet, wenn eine Funktion für eine Datenbank zur Verfügung steht. Mit Rot und durchgestrichen ist gekennzeichnet, wenn eine Funktion für die entsprechende Datenbank nicht verfügbar ist.

Tabellenerstellung

Ein einfacher Befehl um eine gebrauchstüchtige Tabelle zu erstellen, ist z. B.

CREATE TABLE "Test" ("ID" INT PRIMARY KEY, "Text" VARCHAR(50));

CREATE TABLE "Test": Erschaffe eine Tabelle mit dem Namen "Test".
( ): mit den hierin enthaltenen Feldnamen, Feldtypen und Zusätzen.
"ID" INT PRIMARY KEY, "Text" VARCHAR(50): Feldname "ID" mit dem Zahlentyp «Integer» als Primärschlüssel, Feldname "Text" mit dem Texttyp «variable Textlänge» und der Textbegrenzung auf 50 Zeichen.

CREATE [MEMORY | CACHED | [GLOBAL] TEMPORARY | TEMP | TEXT] TABLE "Tabellenname" ( <Felddefinition> [, ...] [, <Bedingungsdefinition>...] ) [ON COMMIT {DELETE | PRESERVE} ROWS];

[MEMORY | CACHED | [GLOBAL] TEMPORARY | TEMP | TEXT]: (Hsqldb, Firebird)

Die Standardeinstellung ist hier MEMORY. Die HSQLDB erstellt also grundsätzliche alle Tabellen im Arbeitsspeicher. Dies gilt auch für die Tabellen, die über LibreOffice Base in der internen Datenbank geschrieben werden. Eine andere Möglichkeit wäre, die Tabellen auf die Festplatte zu schreiben und nur über den Arbeitsspeicher den Zugriff auf die Festplatte puffern zu lassen (CACHED).

Hinweis

CREATE TEXT TABLE "Text" ("ID" INT PRIMARY KEY, "Text" VARCHAR(50));

Eine Texttabelle wird in der HSQLDB erstellt. Sie muss jetzt mit einer externen Textdatei (z. B. einer *.csv-Datei) verbunden werden:

SET TABLE "Text" SOURCE "Text.csv";

Die Datei "Text.csv" muss jetzt natürlich die entsprechenden Felder in der entsprechenden Reihenfolge enthalten. Es können bei der Erstellung der Verbindung zusätzliche Optionen gewählt werden. Details hierzu: http://hsqldb.org/doc/guide/ch09.html#set_table_source-section

Texttabellen sind nicht gegenüber anderen Programmen schreibgeschützt. Es kann also passieren, dass ein anderes Programm/ein anderer Nutzer gerade die Tabelle ändert, während Base darauf zugreift. Texttabellen taugen in der Hauptsache zum Datenaustausch zwischen verschiedenen Programmen.

Auf TEMPORARY bzw. TEMP kann Base nicht zugreifen. Die SQL-Befehle werden hier wohl abgesetzt, die Tabellen aber nicht in der grafischen Benutzeroberfläche angezeigt (und damit auch nicht über die grafische Benutzeroberfläche löschbar) und die Eingaben (über SQL) auch nicht anzeigbar, es sei denn die automatische Löschung des Inhaltes nach dem endgültigen Abspeichern ist ausgeschaltet. Eine Abfrage ergibt hier eine Tabelle ohne Inhalt.

GLOBAL TEMPORARY ist hier die einzige Zusatzoption, die auch Firebird bietet. Die Tabelle wird in der grafischen Benutzeroberfläche zwar angezeigt, aber Eingaben auch direkt über SQL sind nicht abrufbar. Firebird lässt außerdem auch noch eine Definition als EXTERNAL FILE (direkt nach dem Tabellennamen) zu. Die Tabelle wird erstellt, ist aber für die Nutzung durch den Server gesperrt.

Tabellen, die mit SQL direkt gegründet wurden, werden nicht direkt angezeigt. Hier muss entweder über Ansicht → Tabellen aktualisieren eine Auffrischung erfolgen oder die Datenbank einfach geschlossen und erneut geöffnet werden.

<Felddefinition>:

"Feldname" Datentyp [(Zeichenanzahl[,Nachkommastellen])] [{DEFAULT 'Standardwert' | GENERATED BY DEFAULT AS IDENTITY (START WITH <n>[, INCREMENT BY <m>])}] | [[NOT] NULL] [IDENTITY] [PRIMARY KEY]

Erlaubte Standardwerte innerhalb der Felddefinition:

Für Textfelder kann ein Text in einfachen Anführungsstrichen oder NULL eingegeben werden. Die einzige SQL-Funktion, die erlaubt ist, ist CURRENT_USER. Dies ergibt allerdings nur dann einen Sinn, wenn die HSQLDB als externe Serverdatenbank mit mehreren Nutzern betrieben wird.

Für Datums- und Zeitfelder kann ein Datum, eine Zeit oder eine Kombination aus Datum und Zeit in einfachen Anführungsstrichen oder NULL eingegeben werden. Dabei ist zu beachten, dass das Datum amerikanischen Konventionen entspricht (yyyy-mm-dd), die Zeitangabe das Format hh:mm:ss hat und der Datums_Zeit_Wert das Format yyyy-mm-dd hh:mm:ss.

SQL-Funktionen, die erlaubt sind:
für das aktuelle Datum                                -       
CURRENT_DATE, TODAY (Hsqldb),
                                                                                       
DATE 'NOW' (Firebird)
für die aktuelle Zeit                                        -       
CURRENT_TIME, NOW (Hsqldb),
                                                                                        TIME
'NOW' (Firebird)
für den aktuellen Datums-Zeit-Wert        -       
CURRENT_TIMESTAMP, NOW (Hsqldb),
                                                                                        TIMESTAMP
'NOW' (Firebird).
Zusätzlich bietet Firebird: DATE 'TODAY', DATE 'YESTERDAY' und DATE 'TOMORROW'.

Für boolsche Felder (Ja/Nein) können die Ausdrücke FALSE, TRUE, NULL gesetzt werden. Diese sind ohne einfache Anführungszeichen einzugeben.

Für numerische Felder ist jede in dem Bereich gültige Zahl sowie NULL möglich. Auch hier sind, zumindest bei NULL, keine einfachen Anführungszeichen einzugeben. Bei der Eingabe von Nachkommazahlen ist darauf zu achten, dass die Dezimalstellen durch einen Punkt und nicht durch ein Komma getrennt werden.

Für Binärfelder (Bilder etc.) ist jeder gültige Hexadezimalstring in einfachen Anführungsstrichen sowie NULL möglich. Beispiel für einen Hexadezimalstring: '0004ff' bedeutet 3 Bytes, zuerst 0, als zweites 4 und zum Schluss 255 (0xff). Da Binärfelder in der Praxis nur für Bilder eingesetzt werden müsste also der Binärcode des Bildes bekannt sein, das den Defaultwert bilden soll.

Hinweis

Hexadezimalsystem: Zahlen werden in einem Stellenwertsystem von 16 dargestellt. Die Ziffern 0 bis 9 und die Buchstaben a bis f ergeben pro Spalte 16 Ziffern im Mischsystem. Bei zwei Feldern kommen dann 16*16=256 mögliche Werte dabei zustande. Das entspricht schließlich 1 Byte.

NOT NULL → der Feldwert kann nicht NULL sein. Diese Bedingung kann lediglich in der Felddefinition mit angegeben werden.

Beispiel:

CREATE TABLE "Test" ("ID" INT GENERATED BY DEFAULT AS IDENTITY  (START WITH 10) PRIMARY KEY, "Name" VARCHAR(50) NOT NULL, "Datum" DATE DEFAULT CURRENT_DATE);

Eine Tabelle "Test" wird erstellt. Das Schlüsselfeld "ID" wird als Autowert definiert. Der Autowert soll mit der Zahl 10 beginnen. Für Firebird ist zusätzlich notwendig, dass PRIMARY KEY zusätzlich zur der Definition des generierten Wertes erwähnt wird. Sonst fehlt hier der Primärschlüssel und eine Eingabe ist nur über SQL möglich.
Das Eingabefeld "Name" ist ein Textfeld für maximal 50 Zeichen. Es darf nicht leer sein.
Zuletzt kommt ein Datumsfeld "Datum", das als Standardwert das aktuelle Datum speichert,
wenn nicht ein anderes Datum eingegeben wurde. Dieser Standardwert wird aber nur bei der Erstellung eines neuen Datensatzes wirksam. Wird ein Datum gelöscht, so bleibt der Inhalt anschließend leer.

<Bedingungsdefinition>:

[CONSTRAINT "Name"]

UNIQUE ( "Feldname 1" [,"Feldname 2"...] ) |

PRIMARY KEY ( "Feldname 1" [,"Feldname 2"...] ) |

FOREIGN KEY ( "Feldname 1" [,"Feldname 2"...] ) REFERENCES "anderer Tabellenname" ( "Feldname 1" [,"Feldname 2"...]) [ON {DELETE | UPDATE}

{CASCADE | SET DEFAULT | SET NULL}] |

CHECK(<Suchbedingung>)

Bedingungsdefinitionen (Constraints) definieren Bedingungen, die beim Einfügen der Daten erfüllt sein müssen. Die Constraints können mit einem Namen versehen werden.
UNIQUE ("Feldname") → der Feldwert muss innerhalb des Feldes einzigartig sein
PRIMARY KEY ("Feldname") → der Feldwert muss einzigartig sein und kann nicht NULL sein (Primärschlüssel)
FOREIGN KEY ("Feldname") REFERENCES "anderer Tabellenname" ("Feldname") → Die aufgeführten Felder dieser Tabelle sind mit den Feldern einer anderen Tabelle sind verknüpft. Der Feldwert muss auf «Referentielle Integrität» geprüft werden (Fremdschlüssel), d.h. es muss ein entsprechender Primärschlüssel in der anderen Tabelle existieren, wenn hier ein Wert eingetragen wird.
[ON {DELETE | UPDATE} {CASCADE | SET DEFAULT | SET NULL}] → Wenn ein Fremdschlüssel besteht, so ist hier zu klären, wie damit verfahren werden soll, wenn z.B. der fremde Datensatz gelöscht wird. Z.B. macht es keinen Sinn, in einer Ausleihtabelle einer Bibliothek eine Nutzernummer weiter zu führen, wenn der Nutzer selbst gar nicht mehr existiert. Die entsprechenden Datensätze müssten behandelt werden, so dass die Beziehung zwischen den Tabellen stimmig bleibt. In der Regel würde der entsprechende Datensatz einfach gelöscht. Dies geschieht mit ON DELETE CASCADE.
CHECK(<Suchbedingung>) → Wird wie eine WHERE-Bedingung formuliert, bezieht sich aber nur auf den aktuellen Datensatz. Die Bedingungen sind unter «WHERE-SQL-Expression» im Kapitel «Abfragen» aufgelistet.

CREATE TABLE "Zeitmessung" ("ID" INT PRIMARY KEY, "Startzeit" TIME, "Zielzeit" TIME, CHECK ("Startzeit" <= "Zielzeit"));

Mit der CHECK-Bedingung wird ausgeschlossen, dass eine "Zielzeit" eingegeben wird, die kleiner als die "Startzeit" ist. Wird dies versucht, so erscheint eine englischsprachige Fehlermeldung, die ungefähr folgendermaßen aussieht:

Check constraint violation SYS_CT_357 table: Zeitmessung …

Der Suchbedingung wird hier gleich ein Name zugewiesen, der allerdings nicht sehr aussagekräftig ist. Stattdessen bietet es sich an, direkt bei der Tabellendefinition den Namen zu definieren:

CREATE TABLE "Zeitmessung" ("ID" INT PRIMARY KEY, "Startzeit" TIME, "Zielzeit" TIME, CONSTRAINT "Startzeit<=Zielzeit" CHECK ("Startzeit" <= "Zielzeit"));

Damit wird die Fehlermeldung etwas klarer. Der Name der Bedingung drückt dann wenigstens aus, worauf sie sich bezieht.

Mit Constraints wird vor allem gearbeitet, wenn die Beziehung zwischen Tabellen oder der Index für bestimmte Felder festgelegt werden soll. Die Constraints werden, bis auf die CHECK-Bedingung, in der GUI unter Extras → Beziehungen und als Indexentwurf in dem Tabellenentwurf unter Extras → Indexentwurf festgelegt.

[ON COMMIT {DELETE | PRESERVE} ROWS]: (Hsqldb)

Der Inhalt von Tabellen des Typs TEMPORARY oder TEMP wird nach Beendigung der Arbeit mit dem Datensatz standardmäßig gelöscht (ON COMMIT DELETE ROWS). Hier kann also nur ein flüchtiger Datensatz erstellt werden, der Informationen für andere Aktionen, die gleichzeitig laufen, vorhält.

Sollen diese Tabellentypen Daten für eine ganze Sitzung (Aufruf einer Datenbank und Schließen einer Datenbank) zur Verfügung stehen, so kann hier ON COMMIT PRESERVE ROWS gewählt werden.

Tabellenänderung

Manchmal wünscht sich der User, dass ein zusätzliches Feld an einer bestimmten Stelle in die Tabelle eingebaut wird. Angenommen es gibt die Tabelle "Adresse" mit den Feldern "ID", "Name", "Strasse" usw. Jetzt fällt dem Nutzer auf, dass vielleicht eine Unterscheidung in Name und Vorname sinnvoll wäre:

ALTER TABLE "Adresse" ADD "Vorname" VARCHAR(25) BEFORE "Name";

ALTER TABLE "Adresse": Ändere die Tabelle mit dem Namen "Adresse".
ADD "Vorname" VARCHAR(25): füge das Feld "Vorname" mit einer Länge von 25 Zeichen hinzu.
BEFORE "Name": und zwar vor dem Feld "Name". (Hsqldb)

In Firebird muss der Schritt der Zuordnung nach dem Einfügen des Feldes erfolgen. Dafür ist die Position universell eben auch für alte Felder wählbar:

ALTER TABLE "Adresse" ADD "Vorname" VARCHAR(25);

ALTER TABLE "Adresse" ALTER "Vorname" POSITION 2;

POSITION: Ändere die Position des Feldes zu der entsprechenden Stelle, hier als 2. Feld. Wird die Zahl kleiner 1 gewählt, so erscheint eine Errormeldung. Wird die Zahl größer als die Zahl der Felder gewählt, so wird das Feld als letztes Feld gesetzt.

Die Möglichkeit, die Position nach dem Erstellen einer Tabelle für zusätzliche Felder zu bestimmen, bietet die GUI nicht.

ALTER TABLE "Tabellenname" ADD <Felddefinition> [BEFORE "bereits_existierender_Feldname"];

ALTER TABLE "Tabellenname" DROP "Feldname";

Das Feld "Feldname" wird aus der Tabelle "Tabellenname" gelöscht. Dies wird allerdings unterbunden, wenn das Feld in einem View oder als Fremdschlüssel in einer anderen Tabelle Bedeutung hat.

ALTER TABLE "Tabellenname" ALTER COLUMN "Feldname" RENAME TO "neuer_Feldname";

Dies ändert den Namen eines Feldes. RENAME TO ist bei der Hsqldb erforderlich. Bei Firebird funktioniert die Namensänderung nur mit TO.

ALTER TABLE "Tabellenname" ALTER COLUMN "Feldname" SET DEFAULT <Standardwert>;

Fügt dem Feld einen bestimmten Standardwert hinzu. NULL entfernt einen bestehenden Standardwert.

ALTER TABLE "Tabelle" ALTER COLUMN "Datum" SET DEFAULT CURRENT_DATE;

Dies ändert ein Datumsfeld so, dass das momentane Datum eingefügt wird, wenn des Feld "Datum" leer ist.

ALTER TABLE "Tabellenname" ALTER COLUMN "Feldname" SET [NOT] NULL

Setzt oder entfernt eine NOT NULL Bedingung für ein Feld.

ALTER TABLE "Tabellenname" ALTER COLUMN <Felddefinition>;

Die Felddefinition entspricht der aus der Tabellenerstellung mit den folgenden Einschränkungen:

ALTER TABLE "Tabelle" ADD PRIMARY KEY ("Feldname1", "Feldname2" ...);

Dieser Befehl erstellt im Nachhinein einen Primärschlüssel, auch über mehrere Felder.

ALTER TABLE "Tabellenname"

ALTER COLUMN "Feldname" RESTART WITH <neuer_Feldwert>;

Dieser Befehl wird ausschließlich für ein IDENTITY Feld genutzt. Damit wird der nächste Wert eines Feldes mit Autowert-Funktion festgelegt. Dies kann z.B. genutzt werden, wenn eine Datenbank erst einmal mit Testdaten versehen wurde, bevor sie mit den eigentlichen Daten bestückt wurde. Dann wird der Inhalt der Tabellen gelöscht und der neue Feldwert z.B. als 1 festgelegt. Der neue Feldwert ist dabei ohne einfache Anführungszeichen als Zahl einzugeben.

ALTER TABLE "Tabellenname"

ADD [CONSTRAINT "Bedingungsname"] CHECK (<Suchbedingung>);

Dies fügt eine mit CHECK eingeleitete Suchbedingung hinzu. Solch eine Bedingung wird nicht auf bereits bestehende Datensätze angewandt, sondern bei allen zukünftigen Änderungen und neu erstellten Datensätzen berücksichtigt. Wird kein Bedingungsname definiert, so wird automatisch eine Bezeichnung zugewiesen. Beispiel:

ALTER TABLE "Ausleihe" ADD CHECK (COALESCE("Rueckdatum","Leihdatum")>="Leihdatum")

Die Tabelle "Ausleihe" soll in Bezug auf Fehleingaben abgesichert werden. Es soll vermieden werden, dass ein Rückgabedatum angegeben wird, das vor dem Ausleihdatum liegt. Taucht jetzt bei der Eingabe des Rückgabedatums dieser Fehler auf, so erscheint die Fehlermeldung Check constraint violation …

ALTER TABLE "Tabellenname"

ADD [CONSTRAINT "Bedingungsname"] UNIQUE ("Feldname1", "Feldname2" ...);

Hier wird hinzugefügt, dass die benannten Felder nur jeweils verschiedene Werte beinhalten dürfen. Werden mehrere Felder benannt, so gilt dies für die Kombination von Feldern. NULL wird hierbei nicht berücksichtigt. Ein Feld kann also ohne weiteres mehrmals die gleichen Werte haben, wenn das andere Feld bei den entsprechenden Datensätzen NULL ist.

Der Befehl wird nicht funktionieren, wenn bereits eine UNIQUE – Bedingung für die gleiche Felderkombination existiert.

ALTER TABLE "Tabellenname"

ADD [CONSTRAINT "Bedingungsname"] PRIMARY KEY ("Feldname1", "Feldname2" ...);

Fügt einen Primärschlüssel, gegebenenfalls mit einer Bedingungsdefinition, einer Tabelle hinzu. Die Syntax der Bedingungsdefinition entsprecht der der Erstellung bei einer Tabelle.

ALTER TABLE "Tabellenname"

ADD [CONSTRAINT "Bedingungsname"] FOREIGN KEY ("Feldname1", "Feldname2" ...)

REFERENCES "Tabellenname_der_anderen_Tabelle" ("Feldname1_andere_Tabelle", "Feldname2_andere_Tabelle" ...)

[ON {DELETE | UPDATE} {CASCADE | SET DEFAULT | SET NULL}];

Hiermit wird eine Fremdschlüsselbedingung (FOREIGN KEY) zur Tabelle hinzugefügt. Die Syntax ist die gleiche wie bei der Erstellung einer Tabelle.

Das Verfahren wird mit einer Fehlermeldung beendet, wenn nicht für jeden Wert in der Tabelle ein entsprechender Wert aus der Tabelle mit dem entsprechenden Schlüsselfeld vorhanden ist.

Beispiel: Die Tabellen "Name" und "Adresse" sollen miteinander verbunden werden. In der Tabelle "Name" gibt es ein Feld mit der Bezeichnung "Adresse_ID". Dies soll mit seinen Werte mit dem Feld "ID" der Tabelle "Adresse" verbunden werden. Steht in "Adresse_ID" bereits der Wert 1, in dem "ID" der Tabelle "Adresse" aber nicht, so kann die Verbindung nicht funktionieren. Ebenfalls unmöglich ist es, wenn der Feldtyp in beiden Feldern nicht übereinstimmt.

ALTER TABLE "Tabellenname" DROP CONSTRAINT "Bedingungsname";

Der Befehl entfernt eine mit Namen versehene Bedingung (UNIQUE, CHECK, FOREIGN KEY) aus einer Tabelle.

ALTER TABLE "Tabellenname" RENAME TO "neuer_Tabellenname"; (Hsqldb)

Mit diesem Befehl schließlich wird einfach nur der Name einer Tabelle geändert.
Mit Firebird ist es nicht möglich, einen Tabellennamen zu ändern. Stattdessen muss hier eine neue Tabelle mit neuem Namen und den alten Daten erstellt werden.

Hinweis

Bei der Änderung einer Tabelle über SQL wird die Änderung zwar in der Datenbank übernommen, nicht aber unbedingt sofort überall in der GUI sichtbar und verfügbar. Wird die Datenbank geschlossen und wieder geöffnet, so werden die Änderungen auch in der GUI angezeigt.

Die Änderungen werden auch dann angezeigt, wenn im Tabellencontainer Ansicht → Tabellen aktualisieren aufgerufen wird.

Tabellen löschen

DROP TABLE "Tabellenname" [IF EXISTS] [RESTRICT | CASCADE];

Löscht die Tabelle "Tabellenname".
Firebird kennt hier keine weiteren Optionen. Sobald über Verknüpfungen zu anderen Tabellen oder Ansichten Probleme auftauchen, wird das Löschen mit einer Fehlermeldung abgebrochen.

IF EXISTS schließt aus, dass eine Fehlermeldung erscheint, falls diese Tabelle nicht existiert. (Hsqldb)

RESTRICT ist die Standardeinstellung und muss nicht definitiv gewählt werden, d.h. ein Löschen wird dann nicht ausgeführt, wenn die Tabelle mit irgendeiner anderen Tabelle durch einen Fremdschlüssel verbunden wurde oder auf die Tabelle mit einem View (Ansicht) Bezug genommen wird. Abfragen sind davon nicht berührt, da die innerhalb der HSQLDB nicht gespeichert sind. (Hsqldb)

Wird statt RESTRICT CASCADE gewählt, so werden alle Beziehungen zu der Tabelle "Tabellenname" gelöscht. In den verknüpften Tabellen werden dann alle Fremdschlüsselfelder auf NULL gesetzt. Alle Views, in denen auf die entsprechende Tabelle Bezug genommen wird, werden komplett gelöscht. (Hsqldb)

Verknüpfung von Tabellen

Prinzipiell kommt eine Datenbank auch ohne die Verknüpfung von Tabellen aus. Der Nutzer muss dann bei der Eingabe selbst darauf achten, dass die Beziehungen zwischen den Tabellen stimmig bleiben. In der Regel geschieht dies, indem er sich entsprechende Formulare erstellt, die dies bewerkstelligen sollen.

Das Löschen von Datensätzen bei verknüpften Tabellen ist nicht so einfach möglich. Angenommen  es würde aus der Tabelle "Strasse" in Abbildung 6 eine "Strasse" gelöscht, die aber durch die Verknüpfung mit der Tabelle "Adresse" in der Tabelle "Adresse" noch als Fremdschlüssel vertreten ist. Der Verweis in der Tabelle "Adresse" würde ins Leere gehen. Hiergegen sperrt sich die Datenbank, sobald der Relationenentwurf erstellt wurde. Um die "Strasse" löschen zu können, muss die Vorbedingung erfüllt sein, dass sie nicht mehr in "Adresse" benötigt wird.

Die grundsätzlichen Verknüpfungen werden über Extras → Beziehungen