32 Bit und 64 Felder: Auf dem Atari ST läuft die erste Schachdatenbank der Welt
In welcher Disziplin sind die bundesdeutsche und die englische Nationalmannschaft zu Trainingszwecken mit Atari ST ausgerüstet? Ganz zu schweigen vom amtierenden Weltmeister! Was bewegt ältere russische Emigranten, sich mit Dropdown-Menüs und Dialogboxen auseinander-zusetzen, und warum schwärmen kubanische Bohemiens von einer Harddisk? Die Antwort heißt "ChessBase" und ist eine hochspezialisierte Datenbank für Schachpartien, die in Bonn entwickelt wurde.
Der folgende Artikel kann und will kein herkömmlicher Testbericht dieser Software sein, weil der Entwickler und Programmierer selbst als Autor zeichnet. ChessBase zudem das weltweit erste System seiner Art. so daß mangels Vergleich schwer Qualitätsurteile gefällt werden könnten, hier soll vielmehr beschrieben werden, wie die spezielle Aufgabenstellung, die sich geradezu ideal für den Einsatz von EDV eignet, zur Entwicklung einer möglichst maßgeschneiderten Lösung führte. Damit ist natürlich ein Blick hinter die technischen Kulissen verbunden: Die Algorithmen und Datenstrukturen von ChessBase sind auch für schachliche Laien interessant.
Wer nicht zu den etwa 100000 Bundes-Bürgern gehört, die regelmäßig Wettkampfschach spielen, wird sich fragen, was für einen Sinn es macht, derartigen Aufwand mit der Speicherung von Schachpartien zu betreiben. Die Antwort ist schlicht: Information ist im Schach alles. Das ist der Grund dafür, daß es eine umfangreiche Literatur mit Tausenden von verschiedenen Titeln gibt, daß allein im deutschen Sprachraum über ein Dutzend auflagenstarke Fachzeitschriften erscheinen und jährlich wahrhaft enzyklopädische Wälzer die wichtigsten Partien der Turnierszene veröffentlichen. Wer seriös Schach spielen will, kann nämlich nicht hoffen, in jeder Auseinandersetzung das Rad neu erfinden zu können, sondern greift auf ein Wissen zurück, das er durch die Analyse von fremden Partien erworben hat. Schachliches Training ist für eine Wettkampfsportart recht außergewöhnlich: Niemand würde ernsthaft hoffen. z.B. im Tennis ein wöchentliches Trainingspensum durch Ansicht von Videoaufzeichungen des Wimbledon Finales zu erledigen. Doch gerade das passiert im Schach: Das sorgfältige Studium von Meisterpartien ist die übliche und durchaus recht anstrengende Trainingsform. Auf höherem Niveau kommt noch als wichtiger Faktor die spezielle Vorbereitung auf einen bestimmten Gegner hinzu. Jeder Spieler hat seinen persönlichen Stil, seine Vorlieben und wunden Punkte, die es herauszufinden gilt, um bessere praktische Erfolge gegen ihn erzielen zu können. Bisher unterhielten Amateure und Profis zu diesem Zweck umfangreiche Karteien, die bekanntermaßen aufwendiger Pflege bedürfen. Außerdem muß eine Partie, die als Notation auf einer Karteikarte vorliegt, immer noch recht umständlich mit einem Schachbrett Zug für Zug nachgespielt werden. Hier ist der Vorteil einer Datenbank offenkundig: Gegenüber der Kartei oder einem Schachbuch wird nicht nur der EDV-übliche Komfort im schnelleren Zugriff auf die Information gewonnen, sondern ein moderner Microcomputer vermag es mühelos, ein Schachdiagramm in hochauflösender Graphik darzustellen, auf dem die gesuchte Partie dann unmittelbar nachgespielt werden kann. Für jeden Programmierer wäre es dann eine Selbstverständlichkeit, naheliegende Funktionen zu entwickeln, die mit dem hölzernen Brett schlicht unmöglich sind. Dazu gehört z.B. das beliebige Springen innerhalb einer Partie von der Eröffnung ins Endspiel oder das Rekonstruieren einer bestimmten Ausgangsstellung auf Tastendruck, in der man vielleicht eine eigene Analyse begonnen hatte.
Das beantwortet auch eine Frage, die sich vielleicht mancher schon insgeheim gestellt hatte: Datenbank - gut und schön, aber warum keine Standardlösung, warum kein genormtes Datenformat eines bewährten Systems? Der schachliche Graphikaufsatz ist ein Grund, vielleicht noch wichtiger sind jedoch die Anforderungen, die an die besonderen Zugriffsmethoden und die Effizienz des Aufzeichnungsformats gestellt werden. Darüberhinaus ist folgendes Problem vom ChessBase-Entwickler selbst zunächst völlig unterschätzt worden: Wenn heute, acht Monate nach der Erstveröffentlichung des Programms, z.B. 25% der “Top 100 Men” der schachlichen Weltrangliste einen Atari ST ihr eigen nennen, so waren doch bis auf ein oder zwei Ausnahmen alle diese Spieler mit Computern praktisch völlig unvertraut. Es ist nun offenbar wesentlich einfacher, mißtrauischen PC-Neulingen ein sehr schachspezifisches Programm mit einfach einprägsamen Bedienungsfunktionen nahezubringen, als sie in das Konzept eines relationalen Datenbanksystems einzuweisen. Wenn heute viele Schachgroßmeister und Amateure auf bundesdeutschen “Informationsvorsprung durch Technik” vertrauen, ist dies schließlich sicher auch der GEM-Oberfläche des Atari zu verdanken. 70% aller ChessBase -Anwender haben ihren Rechner zunächst nur für dieses Programm erworben und waren psychologisch als Ersteinsteiger mit der Maus sicher besser bedient als mit einem herkömmlich kommandoorientierten Betriebssystem. Auch bei der gerade fertiggestellten MS-DOS Version von ChessBase wurde Wert darauf gelegt, das gewohnte Bild der Dropdown-Menüs und Dialogboxen ohne Hilfe von GEM-Routinen exakt nachzuempfinden.
Wer über eine Datenstruktur zur Speicherung von Schachpartien nachdenkt, erkennt schnell das wichtigste Problem: Bei der ungeheuren Menge des anfallenden Materials ist eine effiziente Kompression der Daten oberstes Gebot. Niemandem ist mit einer Lösung gedient, die ihm die Speicherung von vielleicht hundert Partien auf einer Diskette erlaubt. Der Haupttrumpf der Datenbank ist die Fülle des angebotenen Partiematerials, sonst kann man getrost zum konventionellen Schachbuch greifen.
Eine zu speichernde Partie besteht zunächst aus den Kenndaten, wie den Namen der Spieler, dem Austragungsort und -jahr, dem Ergebnis etc. Der zweite Block wird durch die Zugnotation selbst dargestellt. Partien können drastisch verschiedene Längen aufweisen: Eine ausgekämpfte Begegnung wird zuweilen bis zu hundert Züge dauern, während sich müde Großmeister schon nach wenigen Zügen auf remis, d.h. unentschieden einigen. Um dem ökonomisch Rechnung zu tragen, darf die Partiendatei keine feste Satzlänge aufweisen - der direkte “random access” scheidet also aus. In ChessBase werden variable Records durch eine Indexdatei gelöst, in der die Zeiger auf den jeweiligen Beginn eines Datensatzes gespeichert sind. Den erfahrenen Programmierer wird diese Zugriffsmethode wenig überraschen; auch die Tatsache, daß innerhalb eines Partie-Datensatzes alle Felder flexible Länge haben, um optimal zu komprimieren, ist eigentlich selbstverständlich. Die Abspeicherung der eigentlichen Züge ist allerdings nicht so trivial. Ein Standarddatenbanksystem würde hier nur ASCII-Formate zulassen und damit einen Halbzug wie“13.Sgl-f3” mit neun Bytes veranschlagen müssen. Zugzahl und Figurenbezeichnungen sind offenbar redundant, so daß die nächste Idee wäre, mit Angabe von Start- und Zielfeld eines Zuges diesen vollständig zu beschreiben. Dabei merkt sich das Programm, welche Figur den betreffenden Zug ausführt, bzw. ob es sich um einen Schlagzug oder ein Schachgebot handelt. Ein Schachbrett hat acht mal acht Felder; die Koordinaten eines Feldes benötigen damit zwei mal drei Bit (23=8). Ein Halbzug fordert dann zwölf Bit, so daß ein kompletter Zug bitkomprimiert in drei Bytes Platz finden könnte.
Dieses Verfahren birgt jedoch immer noch eine Redundanz, da keine Unterscheidung | zwischen legalen, d.h. den Regeln entsprechenden und illegalen Zügen gemacht wurde. Es geht also noch sparsamer, wenn man folgende realistische Annahme vorgibt: In durchschnittlichen Stellungen sind rund 30 legale Züge möglich. Die Anzahl aller legalen Züge überschreitet in der Praxis äußerst selten 80-90. Wenn man also einen Algorithmus findet, der in einer vorgegebenen Stellung eine eindeutige Liste der legalen Züge erzeugt, kann man anstatt des betreffenden Zuges seinen Index in dieser Liste speichern. Weil dieser Index 127 praktisch nie überschreiten wird, reichen sieben Bit zur Darstellung aus ChessBase beansprucht ein Byte pro Halbzug und verwendet das achte Bit als Flag, das eine etwaige Kommentierung anzeigt. Kommentare, die aus ASCII-Text bestehen, werden dann an den Block der Züge angehängt.
Als Fazit ergibt sich für eine realistische Turnierpartie unter diesem Verfahren ein Speicherbedarf von 110-130 Bytes. Damit können auf einer 3,5-Zoll Diskette bis zu 6000 Partien untergebracht werden. Weltmeister Garry Kasparow kennt nachweislich ca. 15000 Partien auswendig, doch kann man diese lebende Datenbank mit drei Disketten bereits quantitativ übertrumpfen Grob geschätzt werden in einem Jahr etwa 10000 relevante Großmeisterpartien gespielt - das beschriebene Aufzeichnungsformat kann das ohne Aufwand bewältigen. Das erklärte Ziel von ChessBase ist die langfristige Erfassung aller publizierten Turnierpartien der Schachgeschichte. Bereits die heutige Harddisktechnologie läßt dies als realistisch erscheinen.
Was nützt einem diese riesige Informationsmenge, wenn man keinen schnellen Zugang zu ihr findet? Auch im Zugriff auf das Material muß die Schachdatenbank neue Wege beschreiten, um sich in der Praxis zu bewähren. Natürlich sind herkömmliche Methoden wie die Suche nach den Partien eines bestimmten Spielers vorgesehen, doch ist die weitaus wichtigste Eigenschaft einer Schachpartie unter dem Gesichtspunkt Datenbank die Eröffnung, d.h. die ersten Züge. In einer Tumierpartie werden bestimmte Eröffnungsvarianten meist auswendig reproduziert, die Eröffnung gibt der Partie ihren Charakter. Das Eröffnungsrepertoire eines Spielers spielt eine große Rolle beim eigenen Training und der Vorbereitung auf bestimmte Gegner. ChessBase legt deshalb einen Index der Eröffnungen an, der im Handumdrehen den Zugriff auf alle Partien einer Variante erlaubt. Hier gilt es folgende Probleme zu bewältigen: Zum einen gibt es keinen allgemeingültigen Eröffnungsschlüssel, der für alle Zeiten in Kraft bleibt, die Varianten sind der Mode unterworfen, und ihre Bewertung durch die Schachwelt ändert sich ständig. Das bedeutet, daß die Eröffnungsklassifikation durch den Benutzer der Datenbank ständig verfeinert und verändert werden können sollte. Zum anderen darf die gewählte Eröffnung nicht einfach aus den bloßen Anfangszügen bestimmt werden, da dieselbe Position auf dem Brett durch verschiedene Zugfolgen erreicht werden kann.
Schachspielern sind Baumstrukturen intuitiv sehr vertraut. Wer in einer praktischen Partie über dem Brett brütet und Varianten berechnet, geht automatisch durch einen Baum der ihm plausibel erscheinenden Fortsetzungen. Dieser Baum entsteht, wenn der Gegner auf einen geplanten Zug mehrere sinnvoll erscheinende Antworten in petto hat, die dann ihrerseits wiederum jeweils mit verschiedenen eigenen Gegenzügen gekontert werden können. Es liegt nahe, die Eröffnungsklassifikation in Form eines Baumes anzubieten, der vom Benutzer selbständig gewartet werden darf. Es werden für ChessBase zwar komplette, fertige Eröffnungsschlüssel angeboten, doch :er Reiz des Systems liegt in der beliebigen Verfeinerbarkeit des Schlüssels nach den eigenen Spielvorlieben. Wer ein begeisterter Anhänger der “Königsindischen Verteidigung” ist, wird diesen Bereich stark ausbauen und dafür “Damengambit” vielleicht völlig vernachlässigen. In seinem Eröffnungsbaum gehen vom königsindischen Knoten die Äste “Sämisch-Variante”, “Fianchetto-System” u.v.a. aus, jeweils gefolgt von einem dichten Variantengeflecht, während in anderen Eröffnungen nur dürre Unterteilungen vorgenommen sind. Wie erreicht ChessBase nun automatisch die richtige Zuordnung einer Partie in einen Eröffnungsschlüssel? Dazu werden, diesmal vom Anwender unbemerkt, alle in der Eröffnungsklassifikation auftretenden Stellungen in einem Binärbaum angeordnet. Bei der Eröffnungsbestimmung wird die Partie dann rückwärts nachgespielt und jede erreichte Stellung mit dem Baum verglichen. Wird eine Klassifikationsstellung erkannt, folgt ChessBase dem dort eingetragenen Zeiger auf den Eröffnungsindex und findet so z.B., daß diese Stellung dem Begriff “Sizilianisch” zugeordnet ist. Ein solcher Klassifikationsvorgang dauert ca. drei Sekunden pro Partie.
Abschließend bleibt noch ein für die Praxis bedeutsames Thema: Der Austausch von Daten. Es wäre einem vielbeschäftigten Großmeister oder beruflich engagierten Amateur nicht zumutbar, selbst Tausende von Partien einzugeben. Deswegen sieht ChessBase die flexible Kommunikation zwischen den einzelnen Datenbanken mit Exportdateien vor. Diese haben folgende Besonderheit: Jede Exportdatei ist im Aufzeichnungsformat mit der Hauptpartiendatei identisch, so daß durch einfaches Umbenennen der Dateinamen aus einer Exportdatei eine neue Datenbank werden kann. Während das ChessBase-Team selbst aktuelle Meisterpartien vertreibt, herrscht zwischen den Anwendern auch ein reger nonkommerzieller Tausch von Daten nach dem Motto: “ Hundert Partien Bobby Fischers gegen hundert Damengambits”, etc. So wachsen die einzelnen Partiensammlungen mit beträchtlicher Geschwindigkeit. Wie jeder Raubkopierer weiß, ist Datentausch ja sehr viel ergiebiger als z.B. Briefmarkentausch, da beliebig viele Doubletten der eigenen Sammlung erzeugt werden können...
M.Wüllenweber