conversions between subschema PICTURES and any
schema data type.
Schema DDL and DML
The relationship between a schema DDL and a
DML is the relationship between declaration and
procedure. The DDL declarations impose a discipline
over the executable code and are to some extent
substitutes for procedures written in the DML and the
host language.
To specify the relationship between DDL
declarations and DML commands, a set of basic data
manipulation functions must be defined that is
independent of the DML and the host language.
Specific commands provided by a particular DML must
be resolved into those basic functions. The resolution is
defined by the implementor of the DML.
The basic data manipulation functions assumed in
these specifications include the functions required to:
. Select records
l Present records to the run unit
. Add new records and relationships
. Change existing records and relationships
. Remove existing records and relationships
Schema and Storage Schema
The concept of separate schema and storage schema
allows the separation of the logical description of the
entire database from the storage description of the same.
This concept is significant from the following points of
view:
1. A database administrator may design a schema
structure consisting of logical record relationships that
sensibly match the totality of applications under
implementation or likely to be implemented.
2. Efficiency considerations are separated from
the logical description by specifying the storage
environment and schema to storage schema mappings
in the storage schema. Tuning may be carried out by
changing the storage schema without alteration to the
schema, subschemas, and programs.
The storage schema describes the representation of
stored data in device independent terms. The database
may, therefore, be stored on any combination of storage
media that is supported by a particular implementation.
The database administrator may allocate media and
devices with differing characteristics to suit the
command’s operational requirements, without
alteration to the storage schema.
Database Management System Selection
When selecting a DBMS, the primary consideration
should be to select a technology that will support the
long-term DBMS needs. The work of identifying the
needs of the command should be done in a very careful
and thorough manner. The ultimate goal is to make the
best choice for the command.
One of the best ways of identifying the needs of the
command is to conduct interviews with the users. The
results of the interviews will identify areas of concern to
them, such as:
. How fast can data be accessed?
. How easy is it to retrieve and manipulate the
data?
. How fast and easy is it to develop quality
applications?
l Will the redundancy of data be reduced?
. Will it provide for the management and accurate
identity of all the data elements?
Once the needs of the command have been
identified, it is time to prepare the presentation for
management.
A first step in the preparation of the
presentation is to describe how the needs of the
command will be addressed by the DBMS. Develop
specific examples to illustrate how each item identified
would be handled in the database environment.
After receiving permission from management to
continue, you can start the selection process. Since all
DBMS software is not the same, you must look at the
quality of the product and the ability of the vendor to
continue to enhance the product in the future. All of the
decisions should be based on the features currently
available or in a beta testing environment. The goal is
not to find the perfect DBMS, but to identify and
recommend the best of those available that will meet the
command’s needs.
This selection criteria applies whether the DBMS is
going to be used on a mainframe computer or a
microcomputer system. However, the microcomputer
system has a few added concerns that must be met. The
most important of these concerns are:
3-26
