A solidDB database can be divided into multiple, independent partitions or catalogs. Each catalog can be divided into multiple independent schemas. The ability to divide a database into catalogs is useful if your database contains multiple topics or is used by more than one application. Typically, each application would have its data stored in a separate database catalog.

In a multi-master environment, the ability to have multiple catalogs enables you to specify multiple databases (master or replica) for synchronization within one database server. For example, the solidDB server for an access router can have two catalogs, one for a replica of a configuration management database and the other catalog for a replica of a subscriber provisioning system.

The solidDB server stores data in a file (or a set of files). These files are known as the physical database. The locations of these files are specified in the solid.ini configuration file. These files can be stored in one user-specified directory or in multiple user-specified directories.

Since each solid.ini configuration file specifies the location of one physical database, a single solidDB program can theoretically operate on different physical databases at different times, simply by starting the server with different solid.ini files. Although you can have more than one physical database (by creating multiple physical files and solid.ini files), one solidDB instance can work with only one physical database at a time.

A physical database file can contain more than one logical database. Each logical database is a complete, independent group of database objects, such as tables, indexes, procedures, triggers, and so on. Each logical database is called a catalog.

As a general rule, the term catalog refers to a logical database and database refers to a physical database.

Catalogs and the objects within them are arranged in a hierarchy. Catalogs can contain database objects known as schema. You can have multiple schemas within each catalog. Each schema, in turn, can have multiple database objects, such as tables, views, sequences, and so on. Catalogs are at the top of the hierarchy and objects such as tables are at the bottom of the hierarchy.

When an object name is preceded by the schema name and the catalog name, the object name is fully qualified, that is, unambiguous. Database object names are qualified in DML statements in the following way:

Within a schema, the name of each object must be unique. For example, you cannot have two tables named TABLE1 inside the same schema. Similarly, within a catalog, the name of each schema must be unique. For example, you cannot have two schemas named SMITH_SCHEMA inside the same catalog.

Although object names within a schema must be unique, different objects in different schemas can have the same name. For example, you can have both of the following object names:

Similarly, although schema names within a catalog must be unique, different catalogs might contain schemas that have the same name. For example, you can have both of the following object names:

By organizing your data appropriately inside catalogs and schemas, you can restrict the context so that users or applications see only those database objects that are relevant to their task. You apply these concepts when creating catalogs and schemas for synchronization.