Registriert seit: 14. Apr 2009
Hash-Indices in Datenbanken
Bestellen wir bei einem Versandhaus, so geben wir unsere Kundennummer an und spezifizieren die bestellten Waren aus dem Katalog mit Warennummern. Hier ist gegen die Verwendung der mehr oder willkürlich vergebenen numerischen Schlüssel nichts einzuwenden, unsere Kundennummer und die Warennummern finden wir mühelos im Katalog.
Bei Bibliothekskatalogen sieht das ganz anders aus. Zu den Stammdaten von Verlagen, Reihen, Autoren, Komponisten, Dirigenten, Orchestern, Interpreten... stehen keine Schlüssel-Nummern in den Büchern, auf Tonträgern... Wer sollte diese vergeben?
Bei der Eingabe der Daten neuer Bücher, Tonträger... müßten wir numerische Indices für Verlag, Reihe, Autoren... in Nachschlagtabellen der entsprechenden Stammdaten suchen. Das ist umso mühsamer je länger diese Tabellen werden (man kommt bald zu einigen 1000 Interpreten) und nahezu unmöglich, sofern diese nicht alphabetisch geordnet sind. Für die Nachschlagtebellen wären daher umfangreiche Sekundärindexe zur alphabetischen Ordnung notwendig.
Für die Auswahl von Autoren, Komponisten, Dirigenten, Interpreten... aber auch von Verlagen, Marken, Reihen.. aus Stammfiles sind daher mnemotechnisch gebildete Indices gefragt, die nach festgelegten möglichst einfachen Regeln gebildet werden.
Da die Regeln für zwei Objekte zum gleichen Index führen können, wird dieser in einen Schlüssel und einem Kollissionsstring zerlegt. Ich bezeichne sie daher als Hash-Indices. Meistens genügt es, bei Kollisionen das letzte Zeichen abzuändern.
Beispiel: Den Index für Komponisten bilden wir aus der ersten beiden Buchstaben seines Nachnamens und dem ersten Buchstaben seines Vornamens. Um die Anzahl der Kollosionen zu verringern, führen wir den Buchstaben '$' für 'Sch' ein:
'BeL ' Bethoven, Ludwig von
'MoW ' Mozart, Wolfgang-Amadeus
'VeG ' Verdi, Guiseppe
'WaR ' Wagner, Richard
'$uF ' Schubert, Franz
Die ersten beiden Buchstaben des Nachnamens (jeder sollte sie kennen!) bilden den Schlüssel, der Anfangs-buchstabe des Vornamens (Ist er Ihnen immer bekannt?) bildet den Kollisionsstring. Halten wir an der Groß- und Kleinschreibung fest, so können wir etwa 263 = 18676 Indices bilden. Kommt es zu einer Kollision, so verwenden wir als Kollisiosstring den nächsten noch nicht belegten Buchstaben. Dieses Verfahren sichert, dasss kollidierende Indices in der Stammdatei aufeinander folgen.
Beim Einfügen von Bernstein, Leonid mit 'BeL ' kam es zu einer Kollision mit Bethoven, Ludwig von, die zum Index 'BeM' für Bernstein, Leonid führt.
Nach der Eingabe eines Hash-Index ist zu bestätigen, dass dieser zu dem gewünschten Objekt führt. Hierzu wird aus einer Liste der zum Schlüssel gehörenden Datensätze das Objekt zum aktuellen Index angezeigt. Entspricht es (infolge einer Kollision) nicht dem gewünschten Objekt, so kann man in der Liste scrollen.
Neben den mit eindeutigen Schlüssel gebildeten Hash-Indices, können auch beliebig mnemotechnisch gebildete (aber eindeutige!) Hash-Indices verwendet werden. Zur Suche nach dem gewünschtem Objekt kann man hier beim Bestätigen durch die ganze Stammfile scrollen.
Verwendet man Hash-Indices zur Eingabe, so muss eine Möglichkeit bestehen, die Stammfile mit einem Datensatz für ein neues Objekt zu erweitern.
Zur Praxis des Verfahrens habe ich ein Demo und meine Kataloge für Videos, Bücher und Tonträger beigefügt.
Für das Demo haben sie einen Alias ’DEMO’ auf …\HashIndex\Data zu setzen.
Für die Kataloge müssen Sie einen Alias VIDEO, BUECHER bzw. TONTRG setzen. Wollen Sie meinen Videokatalog als Demo benutzen, so setzen Sie den Alias auf Data. Wollen sie einen eigenen Katalog einrichten, so setzen Sie den Alias auf Data0.
Der Video-Katalog ist etwas prmitiv, aber auf den Hüllen der DVD's steht meistens nicht mehr.
|
Antwort
Linear-Darstellung
