Kategorie: Tabellen entwerfen

Eigentlich geht man davon aus, dass man sich selbst um das Anlagen von Indizes kümmern muss. Indizes sorgen dafür, dass Daten in den betroffenen Feldern indiziert werden und dass wir diese Felder schneller sortieren und filtern können. Aber ist das wirklich so Muss man jeden Index einzeln anlegen Das ist nicht der Fall: Access hat verschiedene Mechanismen, die automatisch Indizes anlegen. Welche das sind und wie wir ihren Einsatz steuern können, beschreiben wir in diesem Artikel.

Bei der Datenmodellierung hat man nicht immer alle Aspekte vom ersten Augenblick an im Blick. Es kann passieren, dass Felder nachträglich hinzugefügt werden müssen, dass wir ihren Datentyp ändern wollen oder dass ein Tabellen- oder Feldname noch angepasst werden soll. Es kommt jedoch auch vor, dass wir Daten erst einmal in ein Textfeld schreiben und dann feststellen, dass dieses Textfeld immer wieder die gleichen Daten aufnimmt. In diesem Fall kommt es leicht dazu, dass eigentlich gleiche Werte mit unterschiedlich Schreibweise eingetragen werden. Will man nach diesen Werten filtern und gibt nur eine Schreibweise ein, erhält man nicht alle Datensätze, die man eigentlich sehen möchte. Um dies zu verhindern, kann man solche Textfelder durch Nachschlagefelder ersetzen, die ihre Werte aus Lookup-Tabellen beziehen. So sieht man bei der Eingabe direkt, dass ein Wert bereits vorhanden ist und kann diesen nutzen, statt weitere Schreibweisen hinzuzufügen. Wie wir eine solche Änderung nachträglich durchführen, zeigen wir in diesem Artikel.

Bei der Datenmodellierung hat man nicht immer alle Aspekte vom ersten Augenblick an im Blick. Es kann passieren, dass Felder nachträglich hinzugefügt werden müssen, dass wir ihren Datentyp ändern wollen oder dass ein Tabellen- oder Feldname noch angepasst werden soll. Es kommt jedoch auch vor, dass wir eine Beziehung nicht von Anfang an so gestalten, dass sie späteren Praxisanforderungen gerecht wird. In diesem Fall wollen wir uns den Fall anschauen, wo wir eingangs dachten, wir kämen mit einer 1:n-Beziehung aus, aber letztendlich stellte sich heraus, dass eine m:n-Beziehung doch sinnvoller ist. Wir schauen uns in diesem Artikel an, wie wir eine solche Beziehung von 1:n auf m:n umstellen können, damit wir anschließend flexibler Daten zuordnen können.

Mit den Unterdatenblättern stellt Microsoft Access eine interessante Möglichkeit zur Darstellung hierarchisch verknüpfter Daten vor. Dabei können wir für einen Datensatz in den üblichen Datenblättern mit einem Plus-Zeichen die Datensätze untergeordneter Tabellen anzeigen. Untergeordnet bedeutet in diesem Fall Daten aus Tabellen, die über ein Fremdschlüsselfeld mit den Daten der eigentlichen Tabelle verknüpft sind. In diesem Artikel schauen wir uns an, wie wir diese Unterdatenblätter konfigurieren und nutzen können.

Wenn man Beziehungen zwischen zwei Tabellen erstellt, kann man dies ohne referenzielle Integrität erledigen oder auch mit. Wir empfehlen dringend, immer referenzielle Integrität zu definieren, außer es ist technisch nicht möglich – beispielsweise, weil die Tabellen nicht in der gleichen Datenbank liegen. Manchmal ist das Kind jedoch bereits in den Brunnen gefallen. Der Entwickler hat für die Tabellen nur eine einfache Beziehung ohne referenzielle Integrität definiert und die Benutzer haben dies unwissend ausgenutzt: So sind Inkonsistenzen im Datenbestand entstanden, die früher oder später zu gravierenden Problemen führen können. Also zeigen wir in diesem Artikel zunächst, wie solche Probleme überhaupt auftreten können und wie wir diese wieder beheben. Und wir schauen uns auch an, welche Rolle Eigenschaften wie Eingabe erforderlich und die Löschweitergabe in dieser Situation spielen.

Eigentlich sind die Textfelder unter Access der perfekte Ort, um Texte zu speichern. Allerdings haben sie eine entscheidende Einschränkung: Sie können nur maximal 255 Zeichen aufnehmen. Damit ist uns natürlich nicht geholfen, wenn wir längere Texte wie beispielsweise Produktbeschreibungen unterbringen wollen. Glücklicherweise gibt es noch einen weiteren Textdatentyp unter Access, der früher Memofeld hieß und der heutzutage im Tabellenentwurf unter dem Namen Langer Text auswählbar ist. Hier können wir weitaus mehr Zeichen speichern (die genaue Zahl ist nicht genau definiert, aber wir können laut offiziellen Angaben maximal 1.048.576 Zeichen darin speichern. Das gelingt jedoch nicht unter allen Umständen. Davon ab bieten Memofelder noch eine Reihe spannender Features, die wir uns ebenfalls in diesem Artikel und in noch einem weiteren Artikel ansehen.

Im Artikel Tabellen [basics]: Mehrwertige Felder (www.access-basics.de/566) haben wir gezeigt, wie man Nachschlagefelder ohne Einrichten einer weiteren Tabelle realisieren kann – und dabei auch noch mehr als einen verknüpften Datensatz aus den verfügbaren Einträgen auswählen kann. Im vorliegenden Artikel schauen wir uns eine Erweiterung dieser Mehrwertigkeit an. Dabei nutzen wir 1:n-Beziehungen mal ein wenig anders als es üblicherweise geschieht und bilden damit prinzipiell den Nutzen einer m:n-Beziehung ab. Welche Vor- und Nachteile dies hat, besprechen wir ebenfalls in diesem Artikel.

Berechnete Felder kennt man sonst nur aus Abfragen, Formularen oder Berichten, wo man in Spalten oder Steuerelementen Ausdrücke verwenden kann, die zum Beispiel Berechnungen auf der Basis des Inhalts anderer Felder durchführen oder Texte aus Feldern auf bestimmte Art und Weise zusammenführen. Mit Access 2010 wurde jedoch ein Felddatentyp namens Berechnete Felder eingeführt. Diesen kann man direkt in der Tabelle definieren und er berechnet jeweils den enthaltenen Ausdruck. Wie man ein solches Feld einrichtet, ob und wann das sinnvoll ist und welche Nachteile dies mit sich bringt, zeigen wir in diesem Artikel.

Wenn wir im Datenmodell Beziehungen zwischen zwei Tabellen definieren, geschieht das meist unter Anwendung der sogenannten referenziellen Integrität. Was das im Detail bedeutet, haben wir bereits im Artikel Tabellen [basics]: 1:n-Beziehungen (www.access-basics.de/571) erläutert. Dort haben wir allerdings den Aspekt etwas stiefmütterlich behandelt, dass ein Fremdschlüsselfeld in einer 1:n-Beziehung mit referenzieller Integrität auch den Wert Null enthalten kann. Was es damit auf sich hat, welche Folgen das haben kann und wie wir darauf reagieren können, erläutern wir im vorliegenden Artikel.

Währungsfelder sind im Grunde Zahlenfelder des Datentyps Dezimal. Nur, dass wir den Datentyp Dezimal über die Benutzeroberfläche nicht direkt angeboten bekommen. Warum aber verwenden wir überhaupt einen anderen Zahlendatentyp als beispielsweise Single oder Double, die auch Nachkommastellen bieten Der Grund ist die Genauigkeit. Single und Double sind Gleitkommazahlen, die bei Rechenoperationen Rundungsfehler produzieren können. Währung beziehungsweise Dezimal nehmen Festkommazahlen auf, bei denen die Position des Kommas für das Feld festgelegt wird. Dieser Artikel zeigt, wie wir Währungsfelder nutzen und was wir noch damit machen können – außer Geldbeträge darin zu speichern.