Schema DDL and Hardware
A schema DDL entry does not include references to
a physical device or media space. Thus, a schema
written using a DDL is a description of a database that is
not affected by the devices or media used to store the
data. The database may, therefore, be stored on any
combination of storage media that is supported in a
particular DBMS. Because of their sequential nature,
some devices, such as magnetic tape, may not take full
advantage of the facilities included in a DDL. Such
devices are not precluded, however, and may be
perfectly adequate for some of the data.
Chances are the DDL you are using will follow the
guidelines created by the Conference on Data Systems
Languages (CODASYL) and their subcommittee, Data
Base Task Group (DBTG). These guidelines have
influenced the development of database systems,
particularly those for the larger computer systems.
Because of space limitations, the format
specifications for a DML and a schema DDL are not
presented. The syntax rules for a data description
language are similar to those for COBOL and are too
technically extensive to include in this chapter. For
example, a DDL has a character set, words
(programmer supplied), reserved words, key words,
names, literal and nonnumeric literal formatting, and
many other qualification rules.
Schema/Subschema Data Conversion
Since data description in the subschema is host
language oriented, the syntax used in the subschema to
describe the characteristics of data items may differ
from that in the schema or storage schema. This means
that data types that turn out to have the same
representation in a given implementation may be
described differently in the schema and storage schema
than in the subschema. Also, there maybe data types
defined in the subschema that have characteristics and
representations different from those of any schema
type, and vice versa.
However, any data item
description is eligible for inclusion in a subschema for a
particular host language subschema data description
entry if one of the following conditions is satisfied in the
implementation involved:
l The data item has the same representation both in
the database and in the UWA in that implementation,
l A conversion procedure has been provided by
the implementor, or
. A conversion procedure has been provided by
the database administrator.
The implementor is responsible for defining the
correspondence between the schema data types and
specifications and the sub schema data types and
specifications, in terms of the representation of these
respective data types in the implementation. An
example of a correspondence that might be established
by an implementor would be correspondence between
coded arithmetic data in the schema and
COMPUTATIONAL data in the COBOL subschema.
The implementor might provide special conversion
procedures in addition to those in the DBMS for
implementing the conversion rules. An example of a
case where the implementor might provide a special
conversion procedure would be in the interface between
the DBMS and database procedures written in
particular host languages. If the DBMS supplies a
standard parameter list to database procedures, the
representation of some of the parameter values might
not match that of any data type in a particular host
language. In this case, the implementor might wish to
provide a standard conversion procedure to allow the
host language to correctly access such values.
Developers of host language database facilities
may provide rules defining the intended
correspondence between data types allowed in their
host language subschema DDL and the data types in the
schema DDL. Such rules may be specified directly,
naming characteristics of subschema data types so that
they can be matched with the characteristics of schema
data types. Different host languages may define their
rules for intended data type correspondence in terms of
the closest schema equivalents; for example,
FORTRAN referring to schema TYPE specifications
and COBOL referring to schema PICTURE
specifications.
In this case, the conversion rules
specified as part of the schema DDL may be used in
determining appropriate conversions involving data
types not explicitly mentioned in the host languages
defined rules. For example, the COBOL database
facility might specify the intended correspondence
between its subschema PICTURE specifications and
schema PICTURE specifications.
With the
correspondence between schema and subschema
PICTURES established, subschema PICTURE
specifications may be interpreted as if they were
schema PICTURE specifications. The schema DDL
defined conversion rules (which define conversions
between schema PICTURES and other schema data
types) can then be used to determine appropriate
3-25