Once you decide what data to export and define the appropriate tables in the schema, you are ready to identify them as export-only tables. As mentioned before, export-only tables are defined in the database schema just like any other table. So in the case of the flight application, we need to add the export tables to our schema. The following example illustrates (in bold) the addition of an export-only table for reservations with a subset of columns from the normal reservation table.

    . . .

CREATE TABLE Reservation (
   ReserveID INTEGER UNIQUE NOT NULL,
   FlightID INTEGER NOT NULL,
   CustomerID INTEGER NOT NULL,
   Seat VARCHAR(5) DEFAULT NULL,
   Confirmed TINYINT DEFAULT '0',
   PRIMARY KEY(ReserveID)
);
CREATE TABLE Reservation_final (
   ReserveID INTEGER UNIQUE NOT NULL,
   FlightID INTEGER NOT NULL,
   CustomerID INTEGER NOT NULL,
   Seat VARCHAR(5) DEFAULT NULL
);
     . . .

Again, it is a good idea to distinguish export-only tables by their table name, so anyone reading the schema understands their purpose. Once you add the necessary tables to the schema, you then need to define them as export-only tables. You do this by adding an EXPORT TABLE statement for each table to the schema tags. For example:

EXPORT TABLE export_customer;
EXPORT TABLE export_flight;
EXPORT TABLE reservation_final;

If a table is not listed in an EXPORT TABLE statement, it is not exported. In the preceding example, the export_customer, export_flight, and reservation_final tables are identified as the tables that will be included in the export. In addition, since they are export-only tables, inserting data into these tables will have no effect if export is disabled in the deployment file.

You can also specify whether the export-only tables are partitioned or not using the PARTITION TABLE statement in the schema. For example, if an export table is a copy of a normal data table, it can be partitioned on the same column. However, partitioning is not necessary for export-only tables. Whether they are partitioned or "replicated", since no storage is associated with the export table, you can INSERT into the table in either a single-partitioned or multi-partitioned stored procedure. In either case, the export connector ensures that at least one copy of the tuple is written to the export stream.