Chess Assistant employs a browser pane to help the user work with his or her chess data. This browser contains a number of things I will call “objects” each object represents a collection of chess data. This short article will explain the differences between the various types of objects, and attempt to give a fairly simple explanation of what each type of object is used for.

In the explanation that follows, numbers are used to reference the graphic shown below: Databases (1) Databases contain chess data and games. When a database is opened, its name appears in the object browser pane on the left hand side of the screen. As you work with a database, say by searching for a game, you will notice that small icons appear underneath the database. These icons represent one of several things: individual games, trees, subsets of games within the database (called datasets), or classifiers. CA employs the concept of a reference database, which is the main database that is used to find model games and the like. In CA, this is called hugebase. Datasets (2) Every time you open a database, or execute a search on a previously opened database, a dataset is created. Datasets represent temporary subsets of games in the database. As such, datasets contain only pointers to games within the database, rather than the games themselves. While this may not mean much to the casual user, it does make many operations faster to perform.

When CA was first developed, datasets were used as a very fast means of working with games, and you could perform logical operations on them. CA still maintains backward compatibility with these earlier functions, but they can be complicated to use when the contents of a database is updated frequently. This gave rise (In version 6) to the creation of classifiers; more on this later.

One very important thing to know about datasets, is that any time you want to perform an operation on more than one game at a time (for instance printing a game collection, or checking multiple games for blunders), you need to first create a dataset that contains the games you want to process.

Trees (3)

Trees are complex data structures that present chess game data in a move tree format. This particular approach has been discussed many times in the chess literature, and is hardly a new idea (for an explanation of a move tree, see the books by Kotov or Tisdall). The beauty of this approach is that it allows statistics to be compiled for each move. If there is enough data, then this information can be used to gauge the strength of a particular move.

Within CA, there are actually multiple types of trees. I won’t go into a long discussion of these now, but you should understand that each database automatically has a tree built and associated with it. Obviously, as long as the contents of the database stay the same, the contents of the tree stays the same also. However, if a new game is added to a database, then the tree will be out of date, and will need to be rebuilt.

CA also has things called direct trees. This latter type of tree is used to construct opening books and the like. These trees are extremely fast, but they are not explicitly linked to a database. Thus, as new games are added to a database, the data in a direct tree is not updated.

Classifiers (4)

Classifiers allow access to database contents via a explorer-like structure. Classifiers came about because they allow access to games within the database using a book-like format. For instance, Chess Assistant opening programs use classifiers to organize material in a coherent fashion for teaching purposes. CA provides the facility for the individual user to build classifiers as well. These can be used to organize games in just about any arbitrary fashion, as you can see in this article. One important feature of classifiers is that their contents can be quickly updated if new games are added to a database.

The openings200X database includes a classifier that automatically opens when the database is opened. This classifier allows fast access to individual theoretical articles in the database.

Libraries (5)

Libraries store the names of player, places, tournaments/places and sources. They are used to keep the spelling of names and locations consistent. Every game that is stored in the database will have corresponding entries for players, tournaments, and sources in the libraries. Because of this, searches are performed very quickly in CA, and changes to things like player names can be done one time in the library, and corresponding entries in the database games will be made automatically.

Let’s look at the example of the player library, which contains all the possible player names that can be used in a database. Whenever games are copied to a database, the library for that particular database is updated, and any new player names are added. Some of you may already realize that there is a potential problem when new games are added to an existing database. Simply put, there may be multiple ways to spell a player’s name. So for example, if we look in hugebase, Alekhine, Alexander A is used consistently. Yet, if you simply add one of the many free Alekhine collections on the web, you may find that his name is spelled slightly differently (Alekhin for instance, or no first name used at all). It is for this reason that the “multichange” function exists. CA uses this function to ensure that player names are consistent. So in the example that I just mentioned, if you add a bunch of games to hugebase, and then realize that the names are inconsistent, you can use the multichange function, which will go into the game library, and ensure the consistency of the player names for you.

Robert Pawlak