Schema Overview

Schema Terminology

Schemas are described with different terms in StreamBase, depending on context and intended use:

Private Schemas

Private schema is StreamBase Studio's term for unnamed schemas. In Studio, you create a private schema by adding rows directly in the Fields grid of an Edit Schema tab in a component's Properties view (that is, when you do not select a named schema from the drop-down list). You also create a private schema when you add a row of type tuple, and use the Add child button () to add new sub-rows.

Anonymous Schemas

Anonymous schema is StreamSQL's term for unnamed schemas. Private schemas and anonymous schemas are the same concept, seen in different contexts. You can create anonymous schemas in StreamSQL as part of defining a stream, Query Table, or Lock Set with an unnamed schema definition. In the following example, inventory is the name of the stream being created; the stream's schema is defined in parentheses without a name:

CREATE INPUT STREAM inventory (id int, item string, price double);
Named schemas

Named schemas are schemas defined and named in an EventFlow or StreamSQL module, or in a StreamBase interface file. Named schemas can be referenced by name in any component of the module in which they are defined, or in components in modules that import the defining module or interface. When you modify a named schema, all components that reference it automatically inherit those changes.

You create named schemas in the Interface tab of the Interface Editor, in the Definitions tab of the EventFlow Editor, or with the CREATE SCHEMA statement in StreamSQL. Named schemas are further discussed in Using Named Schemas.

Empty schemas

An empty schema is a schema with no fields defined. Empty schemas allow a module to pass typechecking before all schemas have been defined, or to create an input stream that triggers a downstream action without having to enter a dummy input value. See Using Empty Schemas.

Table schemas

A table schema is a named schema for a set of Query Tables that completely defines the structure of those Query Tables, and ensures that all Query Tables in the set are identically defined. A table schema includes the table structure of a Query Table, as well as its primary index and secondary indexes (if any). You can apply a table schema by name to two or more Query Tables to quickly assign the same structure to Query Tables in several modules across a large application. Table schemas are only used with StreamBase Query Tables, and not with JDBC tables or Materialized Windows.

In a table schema, the table's row structure can be defined with a private schema or a named schema. Thus, a table schema with a particular name often includes a named schema with another name.

Parent Schemas

Any schema can extend a parent schema, which must be a named schema in the same module or on the module search path. The child schema inherits all fields from the parent, and can then add more fields appropriate for the context. In the child schema, you cannot subtract or modify parent fields, but you can override an abstract parent field declared with a capture field. See Using Parent Schemas.

Nested schemas

A nested schema is a field of type tuple contained in a schema. In EventFlow applications, both private schemas and named schemas can be used as nested schemas.

In StreamSQL, you can nest schemas with a named schema, or you can use an unnamed schema definition inline. The following examples show both methods:

CREATE STREAM itemprice (item string, price double);
CREATE INPUT STREAM inventory (id int, itemprice);


CREATE INPUT STREAM inventory (id int, (item string, price double) );
Imported and exported schemas

You can import one or more named schemas and table schemas from a StreamBase interface or EventFlow module to another interface or module. In the EventFlow Editor, use the Add Imports button in the Definitions tab. In the Interface Editor, use the Add Imports button in the Imports tab. See Importing Resources from One Module to Another.

Schema Type Comparisons

The following comparisons further clarify the differences between schema types.

Private vs Named Schemas

In StreamBase Studio, use private schemas for components in small EventFlow applications, or for components with a different schema than other components in your application. Defining a private schema does not mean the schema is restricted to the component for which it is defined. As with all schemas in StreamBase, private schemas are automatically inherited by all downstream components.

Use named schemas for three primary reasons:

  • For developer convenience, especially in large EventFlow applications. When editing the schema of a new component, specify the name of a named schema instead of re-typing the same schema definition.

  • For automatic updating of a schema in wide use in your application. When you define new schemas as a named schema, you only need to update the schema in one place. You edit the named schema once, and all instances of that schema are automatically updated.

  • To define a field of type tuple. Certain data streams have hierarchical layers, where the second layer is a schema within the primary schema. You can create a tuple field with individual, private sub-tuple rows, or you can use the name of a named schema as a data type when defining the new field. In the following example, we are defining a three-field schema whose third field is a named schema. Notice that all the named schemas defined in or imported into the current module show up in the drop-down list of data types:

Anonymous vs Named Schemas

The discussion above applies equally well to StreamSQL applications. Use anonymous schemas for streams or tables in simple applications. Use named schemas so you can re-use the name in large applications, for automatic updating of all instances of a named schema, and to define fields of type tuple.

Back to Top ^