Previous Topic: OverviewNext Topic: Schema and Subschema Compilers


Schemas and Subschemas

CA IDMS/DB needs descriptions of databases to manage those databases. To satisfy this requirement, the database administrator defines two logical components of the non-SQL database:

Schema

The schema is a complete description of a database, including the names and descriptions of all areas, records, elements, and sets. The major purpose of the schema is to provide definitions from which to generate subschemas.

Subschema

A subschema provides a view of the database as seen by an application program. This view is often a subset of the complete schema definition. A subschema is used at runtime to provide the DBMS with a description of those portions of the database that are accessible to the application program.

The subschema can restrict access to the database in the following ways:

Subschemas also allow you to define logical records. Logical records are a view of one or more base records and a set of operations performed on those records.

Other entities defined within the process of schema and subschema definition are records, sets, areas, indexes, and CALC keys.

Note: For a complete discussion of non-SQL database components and how to decide which components and options you will use in your database, see the CA IDMS Database Design Guide.

Storing Schema and Subschema Source

Source descriptions for schemas and subschemas are kept in the DDLDML area of the dictionary.

Many software components need database descriptions that are not in object form. For example, DML compilers need a source from which they can generate record descriptions within user-written programs; the IDMSRPTS utility needs a source from which it can produce database reports, and so on. Source descriptions provide a form that is readable by the software when performing these non-DBMS functions.

Load Modules are Maintained for Subschemas

Load modules are maintained for subschemas. Subschema load modules are kept in the DDLDCLOD area of the dictionary and, optionally, in a load library.

Load modules consist of machine-readable code that CA IDMS/DB uses at runtime to transfer data between the program and the database.