SQL/MX 3.1 Installation and Management Guide (H06.23+, J06.12+)
Creating an SQL/MX Database
HP NonStop SQL/MX Release 3.1 Installation and Management Guide—663852-001
7-7
Creating Catalogs
SYSTEM_DEFAULTS_SCHEMA schema, which contains the default settings for
options and other attributes used with MXCI commands and SQL/MX statements.
MXCS_SCHEMA schema, which contains the metadata information needed by
MXCS.
SYSTEM_SQLJ_SCHEMA, which contains the stored procedures
VALIDATEROUTINE and VALIDATEROUTINE2.
DEFINITION_SCHEMA_VERSION_version schema, which contains the
definition schema tables used to maintain information about SQL/MX objects. A set
of these tables is created specifically for the system catalog.
SYSTEM_SECURITY_SCHEMA, which contains dedicated tables to support
system administrators and other security-related features.
A set of definition schema tables is also created for each user catalog when you create
the first schema for that catalog. As you add more schemas and objects to the catalog,
these definition schema tables are updated to describe them.
You can use SELECT to view the contents of SQL/MX metadata tables, but only the
super ID user can modify their content. For example, only the super ID user can
perform ALTER, DROP, DELETE, INSERT or UPDATE statements on metadata tables.
For more information about the SQL/MX system and user metadata tables, see the
SQL/MX Reference Manual.
Creating Catalogs
You begin building your SQL/MX database by creating user catalogs. A catalog:
Is the named logical object that contains descriptions of a set of schemas.
Is owned by the authorization ID that creates the catalog, but this authorization ID
has no special capabilities other than the ability to register or unregister the
catalog.
Can contain multiple schemas, each of which can be owned by a different user.
Cannot contain any other catalogs.
Catalog Naming
The catalog name is an SQL identifier that represents the first part of the three-part
ANSI logical name of the form catalog.schema.name. The catalog’s SQL identifier
must be unique among catalogs on the node.
It is permissible for two nodes (for example, nodes \A and \B) in a distributed SQL/MX
environment to have catalogs with the same name. Each node can access its own
catalog and the objects in it by using location-independent ANSI names. However,
node \A cannot access anything in the same-named catalog on node \B, and vice
versa. For this reason, it may be best to avoid naming a catalog with the same name










