Mehrwertige Felder sind eine Erfindung von Microsoft, um den Umgang mit Datenkonstrukten, bei denen für ein Feld mehrere Werte ausgewählt werden können, zu vereinfachen. In einem mehrwertigen Feld können wir aus einer Liste von Werten, die entweder aus einer Wertliste oder aus einer anderen Tabelle stammen, keinen, einen oder mehrere Einträge auswählen. Aus einer verknüpfen Tabelle mehrere Werte zuordnen? Das hört sich ja eigentlich nach dem Einsatzzweck einer m:n-Beziehung an. Genau das bildet Microsoft intern ab. Allerdings funktioniert das nur innerhalb des Access-Biotops. Sollen die Daten einmal zum SQL Server oder einer anderen Datenbank wandern, wird es kompliziert. Hier können wir solche Konstrukte nämlich nicht mehr einfach abbilden – wir müssen diese also ersetzen. Wie wir die mehrwertigen Felder loswerden, zeigen wir in diesem Beitrag.
Microsoft hat in Access 2010 einige Neuerungen geliefert, die in Zusammenhang mit den gleichzeitig veröffentlichen sogenannten Webdaten standen. Neben den mehrwertigen Feldern sind das zum Beispiel die Anlagefelder. Wobei die Anlagefelder, wenn man sie richtig nutzt, zumindest noch einigermaßen sinnvoll sind. 1:1 zum SQL Server übertragen können wir diese jedoch ebenfalls nicht. Das ist allerdings Thema eines anderen Beitrags.
In diesem Beitrag wollen wir uns die mehrwertigen Felder ansehen. Davon gibt es grob zwei Ausführungen:
- Als Erstes mehrwertige Felder, die ihre Daten aus einer Wertliste beziehen und nicht aus einer Tabelle oder Abfrage. Das heißt, dass eine per Semikolon getrennte Liste von Einträgen vorliegt, aus denen der Benutzer keinen, einen oder mehrere Einträge auswählen kann.
- Als Zweites sehen wir die mehrwertigen Verknüpfungen, bei denen ein Nachschlagefeld auf Basis einer anderen Tabelle oder Abfrage erstellt wurde, für das wir keinen, einen oder mehrere Einträge je Datensatz auswählen können. Wir haben also prinzipiell eine 1:n-Beziehung, bei der Access intern eine m:n-Beziehung zwischenschaltet.
Beide sind praktisch, bis man mal einen der Einträge aus der Liste entfernt – diese bleiben nämlich in der Auswahl erhalten. In diesem Beitrag schauen wir uns zunächst an, was geschieht, wenn wir erstgenannten Felder zum SQL Server migrieren wollen und wie wir das Datenmodell und die enthaltenen Daten korrekt zum SQL Server migrieren.
Probleme bei Verwendung in SQL Server und Co.
Richtig problematisch wird es jedoch, wenn wir Tabellen mit solchen Feldern zum SQL Server migrieren wollen. Warum das der Fall ist, zeigen wir gleich nach dem Erstellen der Beispiele für diesen Beitrag.
Beispiel mehrwertige Wertliste: Produkte und Kategorien
Zu Beispielzwecken legen wir eine Tabelle namens tblProdukte an, welche die folgenden drei Felder enthält:
- ProduktID: Primärschüsselfeld der Tabelle
- Produktname: Name des Produkts
- Kategorien: Feld mit den Kategorien des Produkts
Für den Datentyp des dritten Feldes wählen wir Nachschlage-Assistent… aus (siehe Bild 1).
Bild 1: Anlegen eines Nachschlagefeldes
Im Assistenten führen wir folgende Schritte durch:
- Schritt 1: Auswahl von Ich möchte selbst Werte in die Liste eingeben
- Schritt 2: Anzahl der Spalten bleibt 1
- Schritt 3: Beschriftung beibehalten, Option Nur Listeneinträge aktivieren, Option Mehrere Werte zulassen aktivieren (siehe Bild 2).
Bild 2: Einstellen der Nachschlagefeld-Eigenschaften
Danach können wir für das Feld Kategorien in den Eigenschaften unter Nachschlagen die gewünschten Kategorien durch Semikola separiert für die Eigenschaft Datensatzherkunft eingeben (siehe Bild 3).
Bild 3: Hinzufügen der Einträge
Wenn wir wollen, dass der Benutzer die Werte selbst ändern kann, stellen wir noch die Eigenschaft Wertlistenbearbeitung zulassen auf den Wert Ja ein.
Mehrwertige Wertliste im Formular
Wenn wir ein neues Formular mit dieser Tabelle als Datensatzquelle ausstatten und die drei Felder hinzufügen, sehen wir das Ergebnis aus Bild 4. In diesem Fall ist die Wertlistenbearbeitung aktiviert, was wir an der Schaltfläche erkennen, die beim Öffnen der Liste eingeblendet wird.
Bild 4: Einsatz der mehrwertigen Wertliste im Formular
Analyse der Daten
Bevor wir prüfen, was beim Migrieren der mehrwertigen Wertliste zum SQL Server passiert, schauen wir uns an, was diese Felder eigentlich speichern. Zunächst einmal betrachten wir den im Feld Kategorien des ersten Datensatzes gespeicherten Wert. Dazu nutzen wir die DLookup-Funktion, die folgendes Ergebnis liefert:
Debug.Print DLookup("Kategorien", "tblProdukte")
Kategorie 1; Kategorie 3
Außerdem schauen wir uns noch an, wie die zugrunde liegenden Daten aussehen. Dazu lesen wir die Eigenschaft RowSource des Kombinationsfeldes aus:
Debug.Print CurrentDb.TableDefs("tblProdukte").Fields("Kategorien").Properties("RowSource")
"Kategorie 1";"Kategorie 2";"Kategorie 3";"Kategorie 4"
Wir erhalten also zwei Listen, von denen die erste nur die selektierten Einträge enthält.
Migration dieser Tabelle zum SQL Server
Nun migrieren wir diese Tabelle mit dem SQL Server Migration Assistant in eine neue Datenbank im SQL Server – mehr dazu im Beitrag Access und SQL Server: Der Migrations-Assistent (www.access-im-unternehmen.de/18).
Dazu gehen wir nach dem Starten des SSMA wie folgt vor:
- Wir legen mit File|New Project… ein neues Projekt namens MehrwertigeWertlisten an.
- Wir wählen mit dem Befehl Add Databases die Beispieldatenbank dieses Beitrags aus.
- Im Bereich Access Metadata Explorer selektieren wir die zu migrierende Tabelle tblProdukte (siehe Bild 5).
- Nun klicken wir auf Connect to SQL Server und verbinden uns mit der SQL Server-Instanz, auf der wir die Datenbank anlegen wollen. Für Database geben wir den Namen der zu erstellenden Datenbank an, hier MehrwertigeWertlisten (siehe Bild 6). Gegebenenfalls erscheint eine Meldung, dass die Datenbank noch nicht vorhanden ist und die fragt, ob die Datenbank angelegt werden soll. Dies bestätigen wir.
- Damit wird die Datenbank bereits angelegt, wovon wir uns im SQL Server Management Studio überzeugen können (siehe Bild 7).
- Dann markieren wir den Eintrag mit dem Namen der zu migrierenden Datenbank im Bereich Access Metadata Explorer.
- Schließlich rufen wir den Befehl Convert, Load and Migrate auf.
- Die Migration beginnt und es erscheint der Dialog Synchronize with the Database. Diesen Dialog können wir mit Ok direkt wieder schließen.
- Danach folgt der Dialog Convert, Load and Migrate. Dieser weist auf einen Fehler bei der Konvertierung hin (siehe Bild 8).
- Ein Klick auf diesen Link zeigt Details zum Fehler an. Der Datentyp Complex Text wird nicht unterstützt (siehe Bild 9).
- Schließlich können wir uns im SQL Server Management Studio das Ergebnis anschauen.
Bild 5: Zu migrierende Tabelle auswählen
Bild 6: Verbinden mit der noch anzulegenden Datenbank
Bild 7: Die neue Datenbank ist bereits erstellt.
Bild 8: Es gibt einen Fehler.
Bild 9: Ein Datentyp wird nicht unterstützt.
In diesem Fall sehen wir, dass das Feld Kategorien zwar migriert wurde.
Allerdings finden wir hier ein Feld mit dem Datentyp varchar(8000) vor. Das Feld enthält lediglich die für die jeweiligen Produkte ausgewählten Kategorien. Die verfügbaren Kategorien sind hier nicht mehr zu sehen (siehe Bild 10).
Bild 10: Das Ergebnis der Migration
Und da die meisten Tabelleneigenschaften, vor allem aber die zum Thema Nachschlagefelder, nicht zum SQL Server übertragen werden, können wir nicht damit rechnen, dass die vollständige Liste der verfügbaren Kategorien irgendwo im SQL Server zu finden ist.
Wenn wir die zum SQL Server migrierte Tabelle tblProdukte nun per ODBC-Verknüpfung in die Beispieldatenbank einbinden, sehen wir dort im Feld Kategorien zwar noch die gleichen Werte, die auch in der ursprünglichen Tabelle enthalten waren, aber wir können diese nicht mehr selektieren.
Auch wenn wir eine Kopie des Beispielformulars von oben anlegen und dieses mit der verknüpften Tabelle dbo_tblProdukte versehen, sehen wir dort zwar die Liste der markierten Einträge. Wenn wir die Liste jedoch öffnen, finden wir keine Möglichkeit mehr, mehr als einen Eintrag auszuwählen (siehe Bild 11).
Bild 11: Bei der migrierten und neu verknüpften Tabelle werden die Kontrollkästchen für die Kategorien nicht mehr angezeigt.
Mehrwertige Wertlisten korrekt migrieren
Nun schauen wir uns an, wie wir diese mehrwertigen Wertlisten so migrieren können, dass die gewünschten Daten vom SQL Server bereitgestellt werden und auch zugewiesen werden können. Es führt dabei kein Weg daran vorbei, die Daten, die sich im Feld Kategorien der Tabelle tblProdukte befinden, in eine eigene Tabelle namens tblKategorien auszulagern. Diese weisen wir allerdings nicht der Eigenschaft Datensatzherkunft des Feldes Kategorien der Tabelle tblProdukte zu.
Dies wäre nur sinnvoll, wenn nur eine Kategorie je Produkt ausgewählt werden soll. Die Ausgangssituation ist jedoch, dass wir jedem Produkt eine, keine oder mehrere Kategorien zuweisen können. Um dies zu realisieren, benötigen wir also auch noch eine Verknüpfungstabelle zum Herstellen einer m:n-Beziehung. Diese nennen wir tblProdukteKategorien.
In weiteren Schritten sind zunächst die Einträge der Wertliste des Feldes Kategorien in die Tabelle tblKategorien zu übertragen. Und zu guter Letzt übertragen wir noch die ausgewählten Werte in die Verknüpfungstabelle tblProdukteKategorien.
Damit sind wir leider noch nicht am Ende der Migrationsarbeiten angelangt. Die einfache Darstellung aus dem mehrwertigen Feld mit der Anzeige aller Einträge, die man einfach per Kontrollkästchen selektieren kann, gibt es so für m:n-Beziehungen leider nicht.
Also werden wir in weiteren Beiträgen Alternativen dazu vorstellen – siehe m:n-Daten wie im mehrwertigen Feld selektieren (www.access-im-unternehmen.de/1424).
Von der mehrwertigen Wertliste zur m:n-Beziehung
Wir gehen in diesen Schritten vor:
- Tabelle für die Kategorien erstellen
- Verknüpfungstabelle erstellen
- Wertliste in Tabelle für Kategorien übertrage
- Gewählte Werte in Verknüpfungstabelle schreiben
- Mehrwertiges Feld Kategorien löschen
Erstellen der Tabelle tblKategorien
Diese Tabelle enthält nur zwei Felder – das Primärschlüsselfeld KategorieID und das Feld Kategorie. Für dieses legen wir einen eindeutigen Index fest, damit jede Kategorie nur einmal eingetragen werden kann (siehe Bild 12).
Bild 12: Tabelle zum Speichern der Kategorien
Erstellen der Tabelle tblProdukteKategorien
Die Tabelle tblProdukteKategorien soll die Verknüpfung jedes Eintrags der Tabelle tblProdukte mit jedem Eintrag der Tabelle tblKategorien erlauben.
Dazu fügen wir dieser Tabelle zunächst ein Primärschlüsselfeld namens ProduktKategorieID hinzu. Außerdem legen wir zwei Fremdschlüsselfelder an. Das erste heißt ProduktID und ermöglicht die Angabe des Produkts eines Datensatzes, das zweite heißt KategorieID und soll das Zuweisen einer Kategorie erlauben.
Für die beiden Felder ProduktID und KategorieID legen wir außerdem einen zusammengesetzten, eindeutigen Index an (siehe Bild 13).
Bild 13: Verknüpfungstabelle zwischen den Tabellen tblProdukte und tblKategorien
Da diese Tabelle direkt zum SQL Server migriert werden soll, der bekanntermaßen solche Eigenschaften wie die zum Realisieren von Nachschlagefeldern in Access nicht erlaubt, brauchen wir uns gar nicht erst die Mühe zu machen, die Fremdschlüsselfelder als Nachschlagefelder einzurichten.
Einrichten der Beziehungen
Damit kommen wir zu den Beziehungen, die wir über das Beziehungen-Fenster anlegen. Dazu ziehen wir die drei Tabellen tblProdukte, tblProdukteKategorien und tblKategorien in das Beziehungen-Fenster. Die Beziehung zwischen der Tabelle tblProdukte und tblProdukteKategorien erzeugen wir, indem wir das Feld ProduktID von der Tabelle tblProdukte auf das gleichnamige Feld der Tabelle tblProdukteKategorien ziehen. Im nun erscheinenden Dialog Beziehungen bearbeiten aktivieren wir die Option Mit referentieller Integrität. Außerdem aktivieren wir die Option Löschweitergabe an verwandte Datensätze.
Damit sorgen wir dafür, dass wenn wir ein Produkt löschen, auch die Verknüpfungen zu den jeweiligen Kategorien aus der Tabelle tblProdukteKategorien entfernt werden.
Den gleichen Schritt führen wir für die Beziehung zwischen den Tabellen tblKategorien und tblProdukteKategorien durch. Hier ziehen wir das Feld KategorieID von tblKategorien auf das Feld KategorieID der Tabelle tblProdukteKategorien.
Neben der Option Mit referentieller Integrität aktivieren keine weitere Option – insbesondere nicht die Option Löschweitergabe an verwandte Datensätze.
So verhindern wir, dass Kategorien aus der Tabelle tblKategorien gelöscht werden können, die bereits einem Produkt zugeordnet sind (siehe Bild 14).
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo