<\/p>\n
Erst nach Fertigstellung eines Datenbankprojekts fällt Ihrem Auftraggeber plötzlich noch ein, dass er noch ein unentbehrliches Feature benötigt: Er will alle Tabellen der Datenbank global nach bestimmten Stichwörtern durchsuchen können, etwa indem er den Namen „Meyer“ in ein Suchfeld eingibt und schnell sämtliche Vorkommen in einer Ergebnisliste erhält. Hieraus will er die entsprechenden Stellen anschließend aufrufen. Einfach, denken Sie, und signalisieren Ihrem Kunden: „O.K., alles kein Problem!“ Doch bei näherer Betrachtung fällt Ihnen auf, dass es da mehr zu bedenken gibt, als zunächst vermutet …<\/b><\/p>\n<\/p><\/div>\n Schwache Leistung<\/b><\/p>\n Die Idee, die Sie vielleicht haben, ist, einfach alle Tabellen der Datenbank anhand der TableDefs<\/b>-Auflistung zu ermitteln, jede mit einem Recordset zu öffnen und in allen Feldern nach dem Begriff zu suchen. Welche Felder der Tabellen in die Suche mit einbezogen werden sollen, entscheidet der Datentyp: Nur Textfelder müssen nach den Wünschen des Auftraggebers durchsucht werden und diese ergeben sich aus den Type<\/b>-Eigenschaften der Field<\/b>-Objekte des Recordsets. Sie dürfen den DAO-Typ dbText <\/b>oder dbMemo <\/b>aufweisen. Der Inhalt der so gefilterten Felder wird dann Datensatz für Datensatz ausgelesen. Dabei wird mit der VBA-Funktion InStr() <\/b>ermittelt, ob darin der Suchbegriff vorkommt.<\/p>\n Das würde sicherlich funktionieren, doch dann kommen Ihnen berechtigte Zweifel, ob diese Art der Suche nicht mit Performance-Schwierigkeiten zu kämpfen hätte. Schließlich müsste die Anwendung alle Datensätze aller Textfelder aller Tabellen durchlaufen, was bei dem erwarteten Datenaufkommen und der Tatsache, dass viele Benutzer auf die Datenbank zugreifen werden, nicht zu einem Resultat führt, dem man das Prädikat „schnell“ anheften könnte. Ein Produkt mit schlechter Performance möchten Sie aber nicht abliefern und deshalb muss eine andere Lösung her.<\/p>\n Suchmaschine<\/b><\/p>\n Suchmaschinen wie Google suchen ja auch nicht jeweils im gesamten Terabyte-schweren Bestand von Webseiten, die ihre Robots aus dem Netz gefischt haben, wenn Sie einen Suchbegriff eingeben.<\/p>\n Stattdessen besitzen sie einen eindeutigen Index aller Begriffe, die irgendwo auf den Seiten vorkommen. Etwas ähnliches sollte auch unsere Volltextsuche enthalten. In Bild 1 sehen Sie einen Vorschlag für den Aufbau der zum Volltextindex gehörenden Tabellen.<\/p>\n Bild 1: Tabellenaufbau des Volltextsuchindex<\/span><\/b><\/p>\n<\/p><\/div>\n Die Angelegenheit teilt sich in zwei Vorgänge auf: Zuerst werden alle Tabellen der Datenbank ermittelt und iher Namen sowie Primärschlüsselnamen in der Tabelle tblFulltextTables <\/b>abgelegt.<\/p>\n Außerdem wird die Tabelle tblFulltextFields <\/b>mit den zu den Tabellen gehörenden Feldnamen gefüllt – aber nur für jene Felder, die Texte enthalten. Diese beiden Tabellen stellen die Grundlage für die anschließende Indizierung dar. Die Tabellen enthalten zusätzlich je ein Boolean<\/b>-Feld namens bScan<\/b>, das mitteilt, ob die Tabelle oder das Feld überhaupt für die Indizierung relevant sind.<\/p>\n Nur wenn bScan <\/b>den Wert True <\/b>hat, wird das Feld oder die Tabelle in die Indizierung mit einbezogen.<\/p>\n Im zweiten Schritt werden dann die Feldinhalte der nun ermittelten Textfelder ausgelesen, in Worte gesplittet und diese werden in die Tabelle tblFulltextWords <\/b>aufgenommen.<\/p>\n Dabei ist das Feld Word <\/b>eindeutig indiziert, sodass jeder Begriff nur einmal in der Tabelle vorkommen kann. ID <\/b>ist ein Autowert. Die wichtigste Tabelle des Systems ist nun tblFulltextFind<\/b>. Dort werden die folgenden Informationen zusammengefasst: <\/p>\n Das macht auch schon eines deutlich: Um einen Feldinhalt wiederzufinden, ist es praktisch unumgänglich, dass die Tabellen einen eindeutigen Primärschlüssel aufweisen. Ohne diesen kann ein Datensatz später nicht identifiziert werden. Sie sollten es sich daher zur Angewohnheit machen, jede auch noch so kleine Tabelle mit einem Primärschlüssel zu versehen. Das lässt sich auch noch nachträglich erledigen, indem Sie Tabellen ohne Schlüssel ein zusätzliches Autowert-Feld spendieren.<\/p>\n Suchen<\/b><\/p>\n Wie erfolgt nun die Suche nach einem Begriff Zunächst schaut die Anwendung im Feld Word <\/b>der Tabelle tblFulltextWords <\/b>nach, ob der Begriff vorhanden ist. Falls nicht, kommt also das Wort nirgendwo vor. Falls ja, wird die Tabelle tblFulltextFind <\/b>zu Rate gezogen und nach Datensätzen gefiltert, die den richtigen Wert für IDWord <\/b>enthalten. Und schon haben wir die Ergebnisliste mit Datensätzen, die auf Tabellen, Felder und Primärschlüssel verweisen.<\/p>\n Da geschieht also nicht viel und das genau ist der Vorteil der indizierten Volltextsuche. Sie läuft schnell ab. Das Suchen ist einfach, das Indizieren allerdings relativ aufwändig und Zeit raubend.<\/p>\n Modul zur Volltextindizierung<\/b><\/p>\n Ich erspare Ihnen, die Routinen zur Indizierung selbst zu programmieren. Im Modul mdlVolltextindex <\/b>der Beispieldatenbank finden Sie alles Notwendige. Die Erläuterung einzelner Code-Stellen folgt weiter unten. Die Datenbank enthält neben den notwendigen Tabellen zur Indizierung (siehe Bild 1) als Beispiel noch die Tabellen aus der Südsturm-Datenbank [1] sowie ein Suchformular frmVolltextsuche <\/b>(siehe Bild 3), das die Funktionalität demonstrieren soll.<\/p>\n Das Formular enthält eine Schaltfläche Suchindex neu aufbauen<\/b>, deren Betätigung die Routinen zur Neuindizierung aller Tabellen der Datenbank anstößt. Dabei wird in einem Zwischenschritt die Tabelle tblFulltextTables <\/b>geöffnet, die mit der als Unterdatenblatt eingeblendeten Tabelle tblFulltextFields <\/b>verknüpft ist. Das gibt Ihnen die Gelegenheit, für jede Tabelle und jedes Feld festzulegen, ob es bei der Indizierung berücksichtigt werden soll.<\/p>\n Dazu müssen Häkchen in die Verwenden<\/b>-Checkboxen gesetzt werden (siehe Bild 2).<\/p>\n Bild 2: Tabellen und Felder mit Textinhalten<\/span><\/b><\/p>\n<\/p><\/div>\n Ich würde hier anregen, das Feld PLZ <\/b>zu deaktivieren, denn es macht wenig Sinn, Postleitzahlen in eine Volltextsuche zu integrieren.<\/p>\n Nach dem Schließen der Tabelle fährt die Routine automatisch fort und indiziert den gesamten Datenbestand.<\/p>\n Sie meldet sich nach Vollzug schließlich mit einer Ausgabe der benötigten Zeit. Das wird ungefähr eine Sekunde dauern.In Datenbanken mit Zigtausenden von Datensätzen wird die Sache allerdings anders aussehen. Hier kann die Indizierung ohne Weiteres mehrere Minuten beanspruchen.<\/p>\n Nach der Indizierung können Sie einen Suchbegriff in das Formular eingeben, auf Suchen!<\/b> klicken und Sie erhalten eine Ergebnisliste wie in Bild 3.<\/p>\n Bild 3: Suchformular der Beispieldatenbank<\/span><\/b><\/p>\n<\/p><\/div>\n <\/p>\n Ein Doppelklick auf einen Eintrag öffnet dann das entsprechende Formular und markiert außerdem das Textfeld, in dem der Begriff enthalten ist.<\/p>\n Die Spalte „Inhalt“ der Ergebnisliste enthält übrigens nur einen Ausschnitt des Textinhalts, falls dieser länger als 50 Zeichen sein sollte.<\/p>\n Behind the curtain<\/b><\/p>\n Schauen wir uns auszugsweise an, wie der Code des Moduls mdlVolltextindex <\/b>gestrickt ist.<\/p>\n ScanMyTables<\/b><\/p>\n Diese Prozedur listet die Tabellen und Felder auf, die in die Volltextsuche einbezogen werden können, und speichert das Ergebnis in den Tabellen tblFulltextTables <\/b>und tblFulltextFields<\/b>. Dazu wird die TableDefs<\/b>-Auflistung der Datenbank enumeriert:<\/p>\n Welche Tabellen und Felder für die Indizierung in Frage kommen, hängt von drei Bedingungen ab:<\/p>\n Ob eine Tabelle eine Systemtabelle ist, lässt sich anhand ihrer Attributes<\/b>-Eigenschaft feststellen:<\/p>\n Hier wird der Wert von Attributes<\/b> mit dem Bit-Operator AND <\/b>und der Konstanten dbSystemObject <\/b>verknüpft. Heraus kommt also die Kombination beider Bit-Werte, die 0<\/b> beträgt, wenn die Werte nicht übereinstimmen – es handelt sich dann nicht um eine Systemtabelle.<\/p>\n Nicht ganz so einfach ist zu ermitteln, wie der Primärschlüssel einer Tabelle lautet. Es gibt keine entsprechende Eigenschaft eines TableDefs<\/b>-Objekts. Stattdessen enthält es eine Indexes<\/b>-Auflistung, die durchlaufen werden muss, wobei Sie jeden einzelnen enthaltenen Index auf die Eigenschaft Primary <\/b>überprüfen müssen: <\/p>\n Wenn die Primary<\/b>-Eigenschaft den Wert True <\/b>hat, dann handelt es sich bei dem Index um den Primärschlüssel und die Schleife wird verlassen. Davor wird noch das Flag bIndex <\/b>auf True <\/b>gesetzt, damit der weitere Code weiß, dass überhaupt ein Primarschlüssel gefunden wurde. Nur, wenn das der Fall ist, darf die Tabelle in die Indizierung mit aufgenommen werden.<\/p>\n Den Namen des Index erhält man übrigens über seine Fields<\/b>-Auflistung. Es ist ihr erstes Feld:<\/p>\n Schließlich müssen noch alle Felder aussortiert werden, die nicht den Datentyp Text<\/b> oder Memo<\/b> haben. Für jede Tabelle wird dazu eine innere Schleife für die Fields<\/b>-Auflistung durchlaufen:<\/p>\n Die Informationen über die Tabellennamen (tdf.Name<\/b>), Feldnamen (fld.Name<\/b>) und Primär-schlüssel werden in den Schleifen über Recordsets in die Tabellen tblFulltextTables <\/b>und tblFulltextFields <\/b>geschrieben. Damit ist der erste – und einfachere (!) – Schritt der Indizierung bewältigt.<\/p>\n CreateFulltextWords<\/b><\/p>\n Diese Prozedur übernimmt die eigentliche Aufgabe: das Erstellen des Wortindex (tblFulltextWords<\/b>) und der Verweise auf Fundstellen in den Tabellen (tblFulltextFind<\/b>).<\/p>\n Man kann ihr zwei Parameter übergeben: Minwordlength <\/b>gibt an, wie lang ein Wort mindes-tens sein muss, damit es indiziert werden kann.<\/p>\n Es ist sicher nachvollziehbar, dass ein Begriff, der aus nur zwei Zeichen besteht (etwa „da“), nicht unbedingt in den Index aufgenommen werden muss. Es gäbe zu viele Fundstellen, was den Index unnötig aufblähen würde.<\/p>\n Der Vorgabewert ist deshalb auf vier Zeichen eingestellt. Das Pendant zu diesem Parameter ist maxwordlength<\/b>, in dem die maximal erlaubte Wortlänge übergeben werden kann. Dieser Parameter ist weniger kritisch, denn je länger ein Wort ist, desto seltener kommt es üblicherweise vor. Der Vorgabewert ist 40 Zeichen.<\/p>\n Die Prozedur durchläuft nun alle Datensätze eines Recordsets auf Basis der Abfrage qry_FulltextTablesFields<\/b>, die die zu durchsuchenden Tabellen und Felder kombiniert. Das Ergebnis der Abfrage sieht etwa wie in Bild 4 aus.<\/p>\n Bild 4: Datensätze der Tabellen tblFulltextTables und tblFulltextFields in einer Abfrage zusammengefasst<\/span><\/b><\/p>\n<\/p><\/div>\n Aus den Feldern dieser Abfrage werden wiederum in der Datensatzschleife dynamisch SQL-Strings erzeugt.<\/p>\n Pro Tabellenname entsteht daraus ein Ausdruck, der den zu indizierenden Feldern entspricht – etwa so:<\/p>\n Neben den Textfeldern Artikelname <\/b>und Liefereinheit <\/b>enthält der SQL-String auch den Pri-märschlüssel ArtikelID<\/b>, der benötigt wird, damit die Fundstellen anschließend eindeutig identifiziert werden können.<\/p>\n Dieser SQL-String wird zur Weiterverarbeitung an die Prozedur ScanWordsSQL <\/b>übergeben. Man hätte diese Routine auch innerhalb der Schleife von CreateFulltextIndex() <\/b>unterbringen können. Sie wäre dann aber wahrhaft zu einem Ungetüm von verschachtelten Schleifen und Einrückungen geworden. Der besseren Strukturierung wegen wurde dieser Teil also in eine separate Prozedur ausgelagert.<\/p>\n ScanWordsSQL<\/b><\/p>\n Diese Routine durchläuft nun alle Datensätze eines Recordsets, das auf dem SQL-String aufbaut, und liest dabei alle Textfeldinhalte aus:<\/p>\n Der Feldinhalt steht nun jeweils in der String-Variablen sText<\/b>.<\/p>\n Wie aber erhält man aus diesem String die einzelnen Wörter <\/p>\n Ab VBA 6 steht zum Trennen einzelner Wörter eines Strings die Funktion Split() <\/b>zur Verfügung, der man als Parameter ein bestimmtes Trennzeichen übergeben kann. Als Ergebnis erhält man ein Array mit den einzelnen Wörtern.<\/p>\n Nur reicht das für unseren Fall leider nicht aus. Wenn das Leerzeichen als Trenner benutzt wird, dann wird etwa aus „ein hübscher, netter Code-Teil.“ die Folge „ein“, „hübscher,“, „netter“, „Code-Teil.“ Die einzelnen Wörter sind nicht korrekt, weil sie teilweise Satzzeichen eingebaut haben. <\/p>\n Aus „Code-Teil.“ soll „Code“, „Teil“ werden. Um solche Trennungen zu realisieren, brauchen Sie eine zusätzliche Hilfsfunktion, die in der Prozedur SplitMult() <\/b>ausprogrammiert ist.<\/p>\n Sie trennt die Begriffe anhand einer Liste von Trennzeichen, die in der String-Variablen DelimitChars <\/b>untergebracht ist. Im Modul wird diese Variable so gefüllt:<\/p>\n Nachdem sich die Wörter des Textfelds nun im String-Array arrText <\/b>befinden, werden sie der Tabelle tblFulltextWords <\/b>hinzugefügt – aber nur, wenn sie sich noch nicht darin befinden. Deshalb wird per Recordset.FindFirst <\/b>erst nachgeschaut, ob ein Begriff bereits existiert.<\/p>\n Egal, ob dieser neu hinzugefügt wurde oder auch nicht, wird anschließend die ID des Wortes festgestellt, die damit einem neuen Datensatz der Tabelle tblFulltextFind <\/b>zugewiesen werden kann, für den Sie jetzt alle Informationen zusammen haben:<\/p>\n Den Primärschlüssel erhalten Sie über rstText.Fields(0).Value<\/b>, weil im SELECT<\/b>-Statement des SQL-Strings sSQL <\/b>das Primärschlüsselfeld (> ArtikelID<\/b>) immer an die erste Stelle gesetzt ist. <\/p>\n Da es sein kann, dass ein Suchbegriff mehrmals in einem Textinhalt vorkommt, es aber wenig nützlich ist, mehrfach auf dieses Feld zu verweisen, könnte man die Tabelle tblFulltextFind <\/b>mit einem eindeutigen zusammengesetzten Index versehen, der alle ihre Felder enthielte.<\/p>\n Hier gilt es allerdings abzuwägen: Da die Tabelle sehr viele Datensätze enthält, würde eine solche Indizierung stark auf Kosten der Performance beim Aufbau des Volltextindex gehen.<\/p>\n Und die Wahrscheinlichkeit, dass ein Suchbegriff zwei- oder mehrmals in einem Textinhalt vorkommt, ist so groß auch wieder nicht. In der Beispieldatenbank ist die Tabelle tblFulltextFind <\/b>daher nicht mit einem zusammengesetzten Index ausgestattet.<\/p>\n FindWord<\/b><\/p>\n Nach aufgebautem Wortindex können Sie mit dem Formular frmVolltextsuche <\/b>und der Proze-dur FindWord <\/b>schließlich nach Begriffen suchen. Je nach Suchoption – ganzes Wort, Wortanfang oder Teil – wird ein anderes SQL-Statement auf Basis der Tabelle tblFulltextWords <\/b>generiert. Soll der Begriff als Teil eines Wortes vorkommen, dann sieht das Statement so aus:<\/p>\n Die IDs der passenden Wörter werden dann in einer Schleife weiterverarbeitet, wobei für jede ID wiederum ein Recordset auf die Tabelle tblFulltextFind <\/b>geöffnet wird, das nach dieser Wort-ID gefiltert ist.<\/p>\n Dessen Datensätze werden durchlaufen und über die bereits erwähnte Abfrage qry_FulltextTablesFields <\/b>werden die zu den gelieferten Feld- und Tabellen-IDs gehörigen Namen ermittelt. Damit im Ergebnislistenfeld auch noch ein Teil der Fundstelle angezeigt werden kann, wird mit Dlookup <\/b>jeweils der Feldinhalt ausgelesen. <\/p>\n Es sprengte den Rahmen, wollte man die Prozedur genauer erläutern, denn sie ist reichlich komplex. Ein Hinweis sollte jedoch nicht fehlen: Die Ergebnisse werden dem Listenfeld als Werteliste übergeben.<\/p>\n Dieser String darf aber nicht mehr als 2.048 Zeichen lang sein. Wenn diese Limitierung und damit die Zahl der möglichen Fundstellen aufgehoben werden sollte, dann müsste man die Ergebniszeilen in eine temporäre Tabelle schreiben, die dann als Ergebnisunterformular verwendet werden könnte. <\/p>\n Unzulänglichkeiten<\/b><\/p>\n Die hier vorgestellte Lösung hat einige Nachteile, die sich durch zusätzliche Programmierung beheben ließen:<\/p>\n Zusammenfassung<\/b><\/p>\n Ein Volltextindex ermöglicht es sehr schnell, beliebige Begriffe im gesamten Datenbestand einer Datenbank zu finden. Der Programmieraufwand dafür ist, wie Sie gesehen haben, nicht unerheblich. Dabei präsentieren die dargestellten Routinen lediglich das Notwendigste.<\/p>\n Immerhin haben Sie nun ansatzweise eine Vorstellung davon, wie professionelle Suchmaschinen zu Werke gehen. Wenn Sie die Limitierungen der vorgestellten Lösung billigen, dann können Sie das Modul mdlVolltextindex <\/b>sowie die vier zugehörigen Tabellen sofort in Ihrer Datenbank einsetzen.<\/p>\n Quellen<\/p>\n [1] Südsturm – die bessere Beispieldatenbank, Ausgabe 6\/2006, Shortlink 411<\/p>\n Enthaltene Beispieldateien:<\/p>\n volltext.mdb<\/p>\n\n\n ![\"relations.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/Volltextindex-web-images\/relations_opt.jpeg\")
\n <\/div>\n\n\n
\n ![\"datenblatt.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/Volltextindex-web-images\/datenblatt_opt.jpeg\")
\n <\/div>\n\n\n ![\"formular.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/Volltextindex-web-images\/formular_opt.jpeg\")
\n <\/div>\n\nDim dbs As Database\r\nDim tdf As TableDef\r\nSet dbs = CurrentDb\r\nFor Each tdf In dbs.TableDefs\r\n tdf.MacheIrgendWas\r\nNext tdf<\/pre>\n
\n
If (tdf.Attributes AND dbSystemObject) = 0 Then \r\n ...<\/pre>\n
Dim Index As DAO.Index\r\nDim bIndex As Boolean\r\nFor Each idx In tdf.Indexes\r\n If idx.Primary = True Then\r\n bIndex = True\r\n Exit For\r\n End If\r\nNext idx\r\nIf bIndex Then\r\n ...<\/pre>\n
PrimärIndexName = idx.Fields(0).Name<\/pre>\n
Dim fld As DAO.Field\r\nFor Each fld In tdf.Fields\r\n If fld.Type = dbText Or fld.Type = dbMemo Then\r\n ...\r\n End If\r\nNext fld<\/pre>\n
\n ![\"qry.tif\"](\"..\/fileadmin\/_temp_\/2007_01\/Volltextindex-web-images\/qry_opt.jpeg\")
\n <\/div>\n\nSELECT [ArtikelID],[Artikelname],[Liefereinheit] FROM [tblArtikel]<\/pre>\n
Set rstText = dbs.OpenRecordset(sSQL)\r\nn = rstText.Fields.Count\r\nDo While Not rstText.EOF\r\n For i = 1 To n - 1\r\n Set fld = rstText.Fields(i)\r\n sText = Nz(fld.Value)\r\n If Len(sText) > 0 Then\r\n arrText = SplitMult(sText)<\/pre>\n
DelimitChars = " ,;.:!<>\/()[]{}\\+*='" & _\r\n vbCr & vbLf & vbTab & Chr$(34) & Chr$(11)<\/pre>\n\n
"SELECT ID FROM tblFulltextWords WHERE Word LIKE "'*" & sWord & "*'"<\/pre>\n
\n
Downloads zu diesem Beitrag<\/h3>\n