Everything in a NuoDB database is ultimately stored as an atom. Different types of atom store different database 'objects' such as rows from a table, part of an index and so on.

An atom is a serializable representation that can be written to and read from disk; and can also be passed from one process to another. The SM is mostly unconcerned with different types of atoms, it simply saves and retrieves them from disk. A TE will unpack the contents of atoms to build the relational data structures it uses to execute SQL. When data is changed, a 'diff' is created containing just the changes to the atom and the diff is passed over the network, not complete atoms.

The major exception to this is that SMs perform index maintenance, so they do "know" about index atoms.
Atom Hierarchy
Figure 1. Atom Hierarchy

Every TE and SM starts up by fetching and caching the Transaction Manager atom and the Master Catalog atom, the root atom for the whole Domain. The Master Catalog, in turn, provides access to all the other atoms.

Atom Usage

The Master Catalog atom is the way into the Domain and allows a TE or SM to find schemas, databases, sequences and tables.

Master Catalog Atom
Figure 2. Master Catalog Atom

The Database Catalog atom allows a TE or SM to find every 'object' in a database - its records, blobs and indexes.

Database Catalog Atom
Figure 3. Database Catalog Atom

In normal circumstances you don’t need to worry about atoms, but it is sometimes useful to monitor how many atoms are being moved around the system. It may indicate poor caching (atoms continually evicted and refetched).