Programmer's ROM - The Computer Language Library/programmersrom.iso/ada/sql/sqlspc.txt

Text File | 1988-05-03 | 137.0 KB | 3,441 lines

                              Proposed Binding

                        Ada to Database Language SQL









                                 March 1986









                                Prepared for

                                WIS JPMO/ADT
                         Washington, D.C. 20330-6600








                                 Prepared by

                        RACOM Computer Professionals
                             7321 Franklin Road
                             Annandale, VA 22003
                               [phone]

                                     and

                       Institute for Defense Analyses
                          1801 N. Beauregard Street
                            Alexandria, VA 22311
                               [phone]

INTRODUCTION

     This  document  defines the Ada procedure language access to  the  draft
proposed  American  National Standard (dpANS) "Database  Language  SQL",  ISO
document  TC97/SC21/WG3-N96 and ANSI document X3H2-86-2,  dated January 1986.
A  native  language approach is used in defining embedded Ada  SQL  programs,
such  that  standard,  validated Ada compilers may be used to  translate  Ada
programs containing embedded SQL.  This is accomplished by slightly adjusting
SQL  syntax  so that the resulting "Ada/SQL" conforms  to  Ada  syntax.   SQL
operations, as well as database names, are subprogram calls in Ada/SQL.  This
document defines how Ada/SQL syntax differs from the dpANS syntax.

     As used herein,  an "implementation" consists of two parts:  (1) a data-
base management system (DBMS) providing the functions required for SQL access
to data, and (2) an interface enabling Ada programs to access data controlled
by the DBMS.

INTRODUCTORY DIFFERENCES

     The  introductory section of the dpANS applies to this Standard as well,
except as noted below (section numbers are from the dpANS):

1.7(2) - An implementation conforming to this Standard must implement  embed-
ded  SQL  Ada  ("<embedded SQL Ada program>") and the Ada  schema  definition
language ("<schema>").

1.7(3) - A MIL-STD implementation conforming to this Standard must conform to
Level 2 of the dpANS.   An ANSI standard implementation may conform to either
Level 1 or Level 2.

1.7(5) - An implementation conforming to this Standard may not allow embedded
SQL Ada options not specified by this Standard or the dpANS.

CONCEPTS

     The  concepts  section  of the dpANS applies to this Standard  as  well,
except as noted below (section numbers are from the dpANS):

2.2(4)  - A non-null value may be of any Ada data type,  other than access or
task,  i.e.,  the  value of any non-access,  non-task program object  may  be
stored  within a database column.   For the purpose of this  definition,  any
composite  type  containing  an access or task type component shall  also  be
considered  an  access or task type.   Types which use pointers to  refer  to
external objects,  such as files,  shall likewise be considered to be  access
types.

2.2.2  - This  section  shall apply to all Ada scalar  types  -- enumeration,
integer, floating point, and fixed point.  The dpANS concept of "exact numer-
ic value" applies to Ada integer types,  while the dpANS concept of "approxi-
mate  numeric value" corresponds to both Ada floating and fixed point  types.
The interface must cause enumeration types to be stored by the DBMS such that
DBMS and Ada comparison operators return consistent results.   Assignment  is
only  permitted between comparable objects.   The Ada/SQL concept of  compar-
ability is defined in section 3.9.

2.2.3  - This  is a new section for Ada record and array types.   Record  and
array objects of the same type are comparable.   SQL operations on array  and
record types are described in sections 4.7(3.6) and 4.7(3.7) of this manual.

2.3(2)  - See  Ada data definition language (section 4) for  column  descrip-
tions.

2.5(2)  - The  UNIQUE_ERROR exception will be raised following  an  operation
violating  a UNIQUE constraint,  and the NULL_ERROR exception will be  raised
following  an operation violating a NOT NULL constraint.   An  implementation
may  select  which exception to raise if more than one error occurs within  a
single operation;  programs relying on any particular exception in this  case
are erroneous.

2.10.1 Status in Ada/SQL is returned by raising the appropriate exception  on
error.   The following exceptions are defined,  based on similar error condi-
tions defined in the dpANS:

     UNIQUE_ERROR    : exception;
     NULL_ERROR      : exception;
     NOT_FOUND_ERROR : exception;

Additional exceptions will be defined in a later version of this standard.

2.11  - This  Standard specifies the actions of Ada/SQL  statements  embedded
within  legal  Ada programs.   A "legal Ada program"  meets  the  conformance
criteria  of  the Ada Programming Language Military  Standard  (ANSI/MIL-STD-
1815A), hereafter referred to as the Language Reference Manual (LRM).

2.12(2)  - The  <module>  concept is not relevant to Ada/SQL,  since  SQL  is
embedded within Ada programs rather than contained within separate <module>s.
A  cursor is created by execution of a <declare cursor>,  and  not  destroyed
until the program defining it terminates.

2.14(1)  - An  <embedded SQL Ada program> uses exact Ada syntax that  may  be
compiled by any standard, validated Ada compiler.  The embedded SQL syntax is
adjusted to conform to Ada syntax.

2.15(4) - A <schema> has a single <authorization identifier>.  It may, howev-
er, be defined within one or more <schema package declaration>s.  Each schema
package  declaration is an Ada package.   The SQL syntax (see 3.4 for  excep-
tions)

     <table name> ::= <authorization identifier> . <table identifier>

may be used to select a specific table, but the Ada syntax of

     <package name> . <subprogram name>

may  also be used,  where <package name> selects the <schema package  declara-
tion> and <subprogram name> selects the table within that package.

2.15(5)  - The applicable <schema package declaration> and corresponding  SQL
<authorization identifier> are selected according to Ada visibility rules for
table  names without an explicitly stated authorization identifier or package
name prefix.

2.16 - Valid execution of any Ada/SQL data manipulation statement other  than
<declare cursor> initiates a transaction for the executing program, if one is
not already in progress.   A transaction in progress upon program termination
is automatically terminated as if a <rollback statement> had been issued.

COMMON ELEMENTS

     The  first  five common elements of the dpANS apply to this Standard  as
well, except as noted below (section numbers are from the dpANS).

3.2 - <literal>s,  since they are compiled by an Ada compiler, must be speci-
fied with Ada syntax (syntactic elements other than <literal> as in LRM):

     <literal> ::= numeric_literal     -- integer, floating and fixed point
                  enumeration_literal -- enumeration                         |
                  string_literal      -- array of character (STRING)         |
                  aggregate           -- record, array                       |

3.3 - Lexical units in Ada/SQL are as in Ada.   Ada reserved words can  obvi-
ously not be used as identifiers (SQL database names),  and Ada/SQL key words
should  also not be used as program and database variables,  to avoid  confu-
sion.   There are,  however, no specific restrictions beyond those imposed by
Ada.

3.4.SR(1)  - In  most  contexts where an <authorization identifier>  is  used
within a <table name>,  the <authorization identifier> is separated from  the
<table  identifier> by a period.   There are,  however,  isolated occurrences
where the separator character is an underscore (see section 3.20) or a hyphen
(see sections 4.5a and 6.7).

3.4.SR(2) - Ada visibility rules determine the <authorization identifier>  of
an unqualified <table name>.

3.4.SR(7)  - <correlation  name>s must be explicitly declared to  pertain  to
specific tables,  as described in section 3.20.   The same <correlation name>
may be reused within different scopes of the same statement, although it must
refer to (different instances of) the same table.

3.4.SR(9) - <module name> is not used for embedded language.

3.4.SR(11) - <procedure name> is not used for embedded language.

3.4.SR(12) - <parameter name> is not used for embedded language.

3.5 Any Ada data type may be declared within a schema,  except for access and
task  types,  and  composite types containing access or  task  subcomponents.
Type  declarations  follow standard Ada syntax.   Expressions  used  in  type
declarations must be static or record discriminants.   Additional description
of data types is provided in Section 4.

REMAINING SYNTACTIC/SEMANTIC DIFFERENCES

The  Ada/SQL  equivalents of the remaining dpANS syntactic/semantic  sections
are now given.  The following aspects are discussed for each section:

FUNCTION  - A  concise description of the function of language  element  dis-
cussed

EXAMPLE  - Examples  of use within Ada/SQL programs.   The data  manipulation
examples use the following table:

  type ANALYST is
    record
      NAME    : ANALYST_NAME_NOT_NULL_UNIQUE;
      SALARY  : ANALYST_SALARY;
      MANAGER : ANALYST_NAME;
    end record;

FORMAT  - BNF and commentary description of the syntactic use of the language
element within Ada/SQL programs

3.6 <value specification>

FUNCTION:

(1)  Indicate values of embedded variables,  (2) indicate whether or not  the
values are null, (3) implement the keyword USER.

EXAMPLE:

  NEW_EMPLOYEE_NAME   : ANALYST_NAME;
  NEW_EMPLOYEE_SALARY : ANALYST_SALARY;
  SALARY_KNOWN        : INDICATOR_VARIABLE;
  CURRENT_MANAGER     : MANAGER_NAME;
  CURSOR              : CURSOR_NAME; -- see section 6.1
  . . .
  INSERT_INTO ( ANALYST ( NAME & SALARY & MANAGER ),
        VALUES <= NEW_EMPLOYEE_NAME                           -- 1
              and INDICATOR(NEW_EMPLOYEE_SALARY,SALARY_KNOWN) -- 2
              and USER );                                     -- 3

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => EQ ( MANAGER , INDICATOR(CURRENT_MANAGER) ) -- 4
    AND      SALARY > 25_000.00 ) );                     -- 5

FORMAT:

<value specification> ::=
     <variable specification>
    <literal>
    USER

<parameter  specification>s  are  not used within Ada/SQL since  an  embedded
language,  rather than a module language, is supported.  The keyword USER may
be specified; it is an Ada function (see example 3).

<variable specification> ::=
      <Ada program expression>
     INDICATOR ( <Ada program expression> [ , <indicator variable> ] )       |

<Ada program expression> ::= program expression of type appropriate for data-
     base column being accessed

<indicator variable> ::= program variable of type  INDICATOR_VARIABLE,  which
     is an enumeration type with values NULL_VALUE and NOT_NULL

Unlike  SQL <embedded variable name>s,  program variables within Ada/SQL  ex-
pressions are not preceded with colons (see example 1).   Also,  general pro-
gram  expressions  may be used as <variable specification>s in  Ada/SQL;  SQL
permits only host variable names.   Where an <indicator variable> is desired,
it is necessary to have a function in order to combine both the value and the
indicator into a single syntactic element.  This function is called INDICATOR
(see example 2).   For convenience in certain contexts,  the <indicator vari-
able>  may be omitted from the call to INDICATOR,  and defaults  to  NOT_NULL
(see  example 4,  where CURRENT_MANAGER could also have been used by  itself,
without the surrounding call to INDICATOR).

<literal> ::= see section 3.2

Ada literals are program expressions,  so no special syntax is required  (see
example 5).

3.7 <column specification>

FUNCTION:

Indicate values of database columns.

EXAMPLE:

  package E is new ANALYST_CORRELATION_NAME; -- employees \ see section 3.20
  package M is new ANALYST_CORRELATION_NAME; -- managers  /

  CURSOR : CURSOR_NAME; -- see section 6.1
  . . .

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => SALARY > 25_000.00 ) );                -- 1

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => ANALYST.SALARY > 25_000.00 ) );        -- 2

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( E.NAME & E.SALARY & M.NAME & M.SALARY, -- 3
     FROM  => E.ANALYST & M.ANALYST, -- see section 3.20
     WHERE => EQ ( E.MANAGER , M.NAME )             -- 3
     AND      E.SALARY > M.SALARY ) );              -- 3

FORMAT:

No syntax changes required.  Example 1 shows a <column specification> without
a  <qualifier>,  example 2 shows a <table name> used as  a  <qualifier>,  and
example 3 shows <correlation name>s used as <qualifier>s.

3.8 <set function specification>

FUNCTION:

Compute aggregate functions on database values.

EXAMPLE:

  NUMBER  : DATABASE.INT; -- see 4.7(3.5.4)
  AVERAGE : ANALYST_SALARY;
  . . .
  SELEC ( COUNT('*'),              -- 1
  FROM => ANALYST );
  INTO(NUMBER);

  SELEC ( COUNT_DISTINCT(MANAGER), -- 2
  FROM => ANALYST );
  INTO(NUMBER);

  SELEC ( AVG(SALARY),             -- 3
  FROM => ANALYST );
  INTO(AVERAGE);

  SELEC ( AVG_ALL(SALARY),         -- 4
  FROM => ANALYST );
  INTO(AVERAGE);

FORMAT:

<set function specification> ::=
     COUNT ( '*' )  <distinct set function> | <all set function>

An  asterisk by itself cannot be used as an argument to an Ada  function,  so
Ada/SQL encloses it in quotes to make it a character literal (see example 1).

<distinct set function> ::=
     { AVG_DISTINCT  MAX_DISTINCT | MIN_DISTINCT | SUM_DISTINCT |
          COUNT_DISTINCT } ( <column specification> )

<column specification> ::= see section 3.7

The DISTINCT cannot stand by itself,  so it is included in the function  name
(see example 2).

<all set function> ::=
     { AVG  MAX | MIN | SUM | AVG_ALL | MAX_ALL | MIN_ALL | SUM_ALL }
        ( <value expression> )

<value expression> ::= see section 3.9

The  ALL can likewise not stand by itself,  and is brought into the  function
name (see examples 3 and 4).

The  value returned by a set function,  other than a count set  function,  is
typed  the same as the <column specification> or <value expression>  argument
of  the set function.   The value returned by a count set function is of type
INT defined in the DATABASE package, as described in section 4.7(3.5.4).

3.9 <value expression>

FUNCTION:

Specify a (possibly) computed value.

EXAMPLE:

  NUMBER : DATABASE.INT; -- see section 4.7(3.5.4)
  . . .
  SELEC  ( COUNT('*') ,
  FROM  => ANALYST ,
  WHERE => ( SALARY + 1000.00 ) / 2080.0 < + 3.85 );
  INTO(NUMBER);

FORMAT:

No syntax changes required; Ada/SQL supports all SQL operators with virtually
the same precedences.  The only difference is that SQL permits monadic "+" or
"-"  operators before any <primary> used within a  <value  expression>.   The
corresponding  Ada  unary_adding_operators may be applied only to  an  entire
simple_expression.   Furthermore,  a leading Ada unary_adding_operator is ap-
plied  to the entire first term within a simple_expression,  while a  leading
SQL  monadic operator in a similar <value expression> would be applied to the
first <factor> within the <term>.  Expressions written in Ada/SQL are  inter-
preted according to Ada rules.  Due to the nature of the operations, however,
the  arithmetic  results will be the same as if SQL interpretation  had  been
applied.   Furthermore, any SQL <value expression> may be equivalently stated
in  Ada,  using parentheses or depending on the properties of the  arithmetic
operators, even though the Ada syntax is more restrictive.

Arithmetic  operators  may be applied only to  scalar  numeric  types.   Both
arguments must be of comparable types.   In Ada/SQL, two database columns are
comparable  if they each contain values of the same Ada type,  and a database
column and a program value are comparable if the Ada program value is of  the
same type as the values contained within the database column.

3.10 <predicate>

FUNCTION:

Specify  a condition that can be evaluated to give a truth value  of  "true",
"false", or "unknown".

EXAMPLE:

See discussions on individual predicate types.

FORMAT:

No syntax changes required; all types of predicate are supported by Ada/SQL.

3.11 <comparison predicate>

FUNCTION:

Specify a comparison of two values.

EXAMPLE:

  package E is new ANALYST_CORRELATION_NAME; -- see section 3.20

  CURSOR : CURSOR_NAME; -- see section 6.1
  . . .

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => E.ANALYST, -- see section 3.20
    WHERE => SALARY >                       -- 1
      SELEC  ( AVG(SALARY),
      FROM  => ANALYST,
      WHERE => EQ(MANAGER,E.MANAGER) ) ) ); -- 2

FORMAT:

<comparison predicate> ::=
     <equality operator> ( <value expression> , <right comparison operand> )
    <value expression> <ordering operator> <right comparison operand>

Although  Ada  supports  all the SQL comparison  operators,  restrictions  on
overloading  =  and /= prevent them from being  used  in  Ada/SQL.   Instead,
functions  EQ and NE are defined for these <equality operator>s.   The  other
<ordering  operator>s  are expressed in their natural  notation.   Example  2
shows  an <equality operator> function;  example 1 shows an <ordering  opera-
tor>.   <equality operators> are available for all user-defined types.   <or-
dering operators> are available for all scalar types and for character arrays
with a single integer index (represented in SQL as strings).

<equality operator> ::=
     EQ  NE

<ordering operator> ::=
     <  > | <= | >=

<value expression> ::= see section 3.9

<right comparison operand> ::=
     <value expression>  <sub-query>

The  right  operand of a comparison predicate may be either a (possibly  com-
puted) value (see example 2) or a <sub-query> (see example 1).

<sub-query> ::= see section 3.24

3.12 <between predicate>

FUNCTION:

Specify a range comparison.

EXAMPLE:

  CURSOR : CURSOR_NAME; -- see section 6.1
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => BETWEEN(SALARY,20_000.00 AND 30_000.00) ) );

             -- variations: NOT BETWEEN

FORMAT:

<between predicate> ::=
     [ NOT ] BETWEEN ( <value expression> ,
                                  <value expression> AND <value expression> )

BETWEEN cannot be written as an infix operator in Ada;  it is instead made  a
function  of two parameters.   The first parameter is the value to be tested,
the second parameter is the range,  with the keyword AND joining the endpoint
<value  expression>s.   No special function is required to implement the  NOT
option, the same overloaded NOT operator used with <search condition>s can be
used  to  negate a BETWEEN test.   The BETWEEN function is only  defined  for
types on which the <ordering operator>s are defined (see section 3.11).

<value expression> ::= see section 3.9

3.13 <in predicate>

FUNCTION:

Specify a quantified comparison.

EXAMPLE:

  PRIMARY_MANAGER,
  ALTERNATE_MANAGER : MANAGER_NAME;
  CURSOR            : CURSOR_NAME; -- see section 6.1
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => IS_IN ( MANAGER , PRIMARY_MANAGER or ALTERNATE_MANAGER ) ) );

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE NOT_IN ( MANAGER ,
      SELEC     ( MANAGER,
      FROM     => ANALYST,
      GROUP_BY => MANAGER,
      HAVING   => AVG(SAL) > 20_000.00 ) ) ) );

FORMAT:

<in predicate> ::=
   { IS_IN  NOT_IN }
      ( <value expression> , { <sub-query>  <in value list> } )

The Ada "in" operator cannot be overloaded,  so IS_IN is used instead of  the
SQL  IN,  and  NOT  IN becomes NOT_IN.   These new operators then  cannot  be
expressed in infix notation, so they become functions of two parameters.  The
first parameter is the <value expression> to be tested for set membership  or
non-membership,  and  the second parameter is the specification of the set to
be tested.   Parentheses are not required around the <in value list>  because
(1) the number of closing parentheses would get cumbersome, since the closing
parenthesis for the function must follow the <in value list> anyway,  and (2)
they  are  not required by Ada syntax,  so the compiler cannot check  whether
they are used or not.

<value expression> ::= see section 3.9

<sub-query> ::= see section 3.24

<in value list> ::=
  <value specification> [ { or <value specification> } ... ]

Items in a value list cannot be separated by commas, so "or" is used instead.
This  corresponds  to the semantics that a record is selected if  its  <value
expression> equals the first <value specification> OR the second one, etc.

<value specification> ::= see section 3.6

3.14 <like predicate>

FUNCTION:

Specify a pattern-match comparison.

EXAMPLE:

  LAST_NAME : ANALYST_NAME;
  CURSOR    : CURSOR_NAME; -- see section 6.1
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => LIKE ( NAME , "%" & LAST_NAME ) ) ); -- variation: NOT LIKE
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => LIKE ( NAME , "%" & LAST_NAME , ESCAPE => "^" ) ) );

FORMAT:

<like predicate> ::=
     [ NOT ] LIKE ( <column specification> , <pattern>
                  [ , ESCAPE => <escape character> ] )

LIKE  cannot  be written as an infix operator in Ada;  it is instead  made  a
function  of three parameters.   The first parameter is the specification  of
the  column  to  be tested,  the second parameter is an array  of  characters
containing the appropriate pattern matching characters.   No special function
is  required to implement the NOT option,  the same overloaded  NOT  operator
used  with  <search condition>s can be used to negate a LIKE test.   LIKE  is
only defined for arrays of characters with a single integer index (represent-
ed in SQL as strings),  with all parameters of the same type.   To be useful,
the  component type must include the pattern matching characters,  which  are
'_' and '%'.

The third parameter to LIKE is named ESCAPE, to implement the SQL keyword for
the escape character.   This parameter is optional, and defaults to no escape
character  specified.   If an escape character is specified,  it must  be  an
array of length 1, of the same type as the pattern.

<column specification> ::= see section 3.7

<pattern> ::= <value specification>

<escape character> ::= <value specification>

<value specification> ::= see section 3.6

3.15 <null predicate>

FUNCTION:

Specify a test for a null value.

EXAMPLE:

  CURSOR : CURSOR_NAME; -- see section 6.1
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => IS_NULL(MANAGER) ) ); -- variation: IS_NOT_NULL

FORMAT:

<null predicate> ::=
   { IS_NULL  IS_NOT_NULL } ( <column specification> )

IS  NULL and IS NOT NULL cannot be written as postfix operators in Ada,  they
are instead made functions IS_NULL and IS_NOT_NULL.    The functions take  as
their parameter the specification of the column to be tested.

<column specification> ::= see section 3.7

3.16 <quantified predicate>

FUNCTION:

Specify a quantified comparison.

EXAMPLE:

  package E is new ANALYST_CORRELATION_NAME; -- see section 3.20

  CURSOR : CURSOR_NAME; -- see section 6.1
  . . .

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => E.ANALYST, -- see section 3.20
    WHERE => SALARY >= ALLL (      -- 1
      SELEC  ( SALARY,
      FROM  => ANALYST,
      WHERE => EQ(MANAGER,E.MANAGER) ) ) ) );

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => EQ ( NAME , ANY (     -- 2      variation: SOME
      SELEC  ( MANAGER,
      FROM  => ANALYST ) ) ) ) );

FORMAT:

<quantified predicate> ::=
     <equality operator> ( <value expression> , <quantified sub-query> )
    <value expression> <ordering operator> <quantified sub-query>

The syntax and considerations for <quantified predicate>s are the same as for
<comparison predicate>s (see section 3.11), where <quantified sub-query>s are
used instead of <sub-queries>.

<equality operator> ::= see section 3.11

<ordering operator> ::= see section 3.11

<value expression> ::= see section 3.9

<quantified sub-query> ::=
     <quantifier> ( <sub-query> )

The  <quantifier> cannot stand by itself in Ada;  it is made into a  function
with the <sub-query> being its parameter.

<quantifier> ::=
     <all>  <some>

<all> ::= ALLL

ALL is an Ada reserved word, ALLL is used instead.

<some> ::= SOME  ANY

<sub-query> ::= see section 3.24

3.17 <exists predicate>

FUNCTION:

Specify a test for an empty set.

EXAMPLE:

  package E is new ANALYST_CORRELATION_NAME; -- see section 3.20

  CURSOR : CURSOR_NAME; -- see section 6.1
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => E.ANALYST, -- see section 3.20
    WHERE => EXISTS (
      SELEC  ( '*',
      FROM  => ANALYST,
      WHERE => EQ(MANAGER,E.NAME) ) ) ) );

FORMAT:

<exists predicate> ::=
     EXISTS ( <sub-query> )

EXISTS is an Ada function, with the <sub-query> being its parameter.

<sub-query> ::= see section 3.24

3.18 <search condition>

FUNCTION:

Specify  a condition that is "true",  "false",  or "unknown" depending on the
result of applying boolean operators to specified conditions.

EXAMPLE:

  PRIMARY_MANAGER,
  ALTERNATE_MANAGER : MANAGER_NAME;
  CURSOR            : CURSOR_NAME; -- see section 6.1
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC  ( '*',
    FROM  => ANALYST,
    WHERE => NOT BETWEEN ( SALARY , 20_000.00 AND 30_000.00 )
    AND    ( EQ(MANAGER,PRIMARY_MANAGER)
    OR       EQ(MANAGER,ALTERNATE_MANAGER) ) ) );

FORMAT:

<search condition> ::=
     <boolean factor> [ { AND <boolean factor> } ... ]
    <boolean factor> [ { OR  <boolean factor> } ... ]

<boolean factor> ::=
     [ NOT ] <boolean primary>

<boolean primary> ::=
     <predicate>  ( <search condition> )

<predicate> ::= see section 3.10

The Ada AND,  OR, and NOT operators correspond to those of SQL.  However, Ada
requires  that combinations of ANDs and ORs be parenthesized to clearly  show
order  of evaluation,  whereas SQL provides precedence of AND over  OR.   The
extra  parentheses  required  by Ada are permitted by SQL,  so  a  legal  Ada
<search  condition>  will still correspond to a valid SQL one,  and  will  be
interpreted in a consistent fashion.

3.19 <table expression>

FUNCTION:

Specify a table or a grouped table.

EXAMPLE:

Examples in other sections include use of <table expression>s.

FORMAT:

<table expression> ::=
     <from clause>
   [ , <where clause> ]
   [ , <group by clause> ]
   [ , <having clause> ]

The  various SQL clauses are parameters to Ada/SQL subprograms.   Each clause
is therefore separated from the one before it with a comma.   The syntax  for
the  <from  clause> does not show the preceding comma because <table  expres-
sion> is preceded with a comma wherever it is used in the grammar.

<from clause> ::= see section 3.20

<where clause> ::= see section 3.21

<group by clause> ::= see section 3.22

<having clause> ::= see section 3.23

3.20 <from clause>

FUNCTION:

Specify a table derived from one or more named tables.

EXAMPLE:

Examples in other sections include use of <from clause>s.

FORMAT:

<from clause> ::=
     FROM => <table reference> [ { & <table reference> } ... ]

The <table reference>s cannot be separated from each other by commas in  Ada,
so ampersands are used instead.  Since the <from clause> is actually a param-
eter  to  a function,  the named parameter association symbol => follows  the
keyword FROM.

<table reference> ::=
     [ <correlation name> . ] <table name>

In Ada/SQL,  <correlation name>s are actually Ada packages.  The <correlation
name>,  if  used,  must therefore precede the <table name>,  with the  <table
name> being a function selected from the <correlation name> package.   Appro-
priate  functions  are also generated so that the <table name> may be  refer-
enced without the optional <correlation name>.

<table  name>  ::= the name of a database table,  defined  as  an  overloaded
     function  within the database-specific portion of the underlying Ada/SQL
     definitions

<correlation name> ::= a package instantiated from the generic package speci-
     fic to each <table name>.   The generic packages are produced by the SQL
     function generator.  In order to define a <correlation name>, the appro-
     priate generic package must be instantiated, in one of the two following
     ways:

          package <correlation name> is new
            <table identifier>_CORRELATION_NAME;

          package <correlation name> is new
            <authorization identifier>_<table identifier>_CORRELATION_NAME;

     Note   that  the  generic  packages  are,   in  general,   named  <table
     name>_CORRELATION_NAME,  except that an <authorization identifier>  used
     within  a  <table name> is separated from the <table identifier>  by  an
     underscore instead of a period as in SQL.  This is an exception; Ada/SQL
     syntax  for  <table  name>s is identical to that of  SQL,  except  where
     otherwise noted.

     Although  <correlation  name>s are specifically declared to  pertain  to
     specific tables,  the same <correlation name> may be reused within  dif-
     ferent scopes of the same statement,  to refer to different instances of
     the same table.

     See section 3.7 for an example of using <correlation name>s.

3.21 <where clause>

FUNCTION:

Specify  a  table derived by the application of a <search condition>  to  the
result of the preceding <from clause>.

EXAMPLE:

Examples in other sections include use of <where clause>s.

FORMAT:

<where clause> ::=
     WHERE => <search condition>

Since  the  <where clause> is actually a parameter to a function,  the  named
parameter association symbol => follows the keyword WHERE.

<search condition> ::= see section 3.18

3.22 <group by clause>

FUNCTION:

Specify  a grouped table derived by the application of the <group by  clause>
to the result of the previously specified clause.

EXAMPLE:

See section 3.13 for an example using a <group by clause>

FORMAT:

<group by clause> ::=
     GROUP_BY => <column specification> [ { & <column specification> } ... ]

Since the <group by clause> is actually a parameter to a function,  the named
parameter association symbol => follows the keyword GROUP_BY,  which requires
the underscore to make it a single lexical symbol to Ada.  <column specifica-
tion>s cannot be separated by commas; ampersands are used instead.

<column specification> ::= see section 3.7

3.23 <having clause>

FUNCTION:

Specify a grouped table derived by the application of the <having clause>  to
the result of the previously specified clause.

EXAMPLE:

See section 3.13 for an example using a <having clause>

FORMAT:

<having clause> ::=
     HAVING => <search condition>

Since  the <having clause> is actually a parameter to a function,  the  named
parameter association symbol => follows the keyword HAVING.

<search condition> ::= see section 3.18

3.24 <sub-query>

FUNCTION:

Specify  a  multi-set of values derived from the result of a  <table  expres-
sion>.

EXAMPLE:

Examples in other sections include use of <sub-query>s.

FORMAT:

<sub-query> ::=
   [ SELEC  SELECT_ALL | SELECT_DISTINCT ]
       ( <sub-query result specification> , <table expression> )

SELECT  used  as  a <sub-query> is an Ada function.   It is not  possible  to
specify  the  ALL or DISTINCT keywords separately,  so they are part  of  the
function name if used.   The name of the function is SELEC if neither keyword
is  used,  since SELECT is an Ada reserved word.   The <sub-query>  functions
have five parameters which must,  of course, be surrounded by parentheses and
separated by commas.  Any or all of the last three parameters may be omitted,
since  named  associations  are used for them and they  have  default  values
indicating  their  omission.   The first parameter is the  <sub-query  result
specification>,  while  the  second through fifth parameters  are  the  FROM,
WHERE,  GROUP BY,  and HAVING clauses from the <table expression>, and so are
named FROM,  WHERE,  GROUP_BY, and HAVING, respectively.  Parentheses are not
required around the <sub-query> because (1) the number of closing parentheses
would get cumbersome,  since the function call itself also provides a closing
parenthesis,  (2)  a  <sub-query> is often an argument to a  function,  which
causes it to be surrounded by parentheses anyway, and (3) parentheses are not
required by Ada syntax, so the compiler cannot check whether they are used or
not.

<sub-query result specification> ::=
     <value expression>
    '*'

An  asterisk cannot stand alone by itself as an argument to an Ada  function,
so it is enclosed in quotes to make it a character literal.

<value expression> ::= see section 3.9

<table expression> ::= see section 3.19

3.25 <query specification>

FUNCTION:

Specify a table derived from the result of a <table expression>.

EXAMPLE:

Examples in other sections include use of <query specification>s.

FORMAT:

<query specification> ::=
   [ SELEC  SELECT_ALL | SELECT_DISTINCT ]
       ( <select list> , <table expression> )

The syntax and interpretation of a <query specification> is the same as for a
<sub-query>,  except that a <sub-query> retrieves only one column of  values,
while a <query specification> may retrieve more than one column.

<select list> ::=
     <value expression> [ { & <value expression> } ... ]
    '*'

The <value expression>s cannot be separated by commas, so ampersands are used
instead.  <value expression>s containing Ada binary_adding_operators may have
to  be  enclosed  in parentheses to enforce the correct precedence  of  their
operators over the Ada/SQL ampersand connectives.   An asterisk cannot  stand
alone  by  itself  as an argument to an Ada function,  so it is  enclosed  in
quotes to make it a character literal.

<value expression> ::= see section 3.9

<table expression> ::= see section 3.19

4.1 <schema>

FUNCTION:

Ada/SQL schemas perform three functions: (1) Provide the Ada type definitions
necessary for programs to declare variables to hold database values, (2) form
input  to a schema translator that converts Ada/SQL schemas into SQL  schemas
for creating database structures, and (3) form input to a SQL function gener-
ator that produces the functions and type definitions necessary to use schema
database names within the Ada/SQL data manipulation language.  The interrela-
tion  and automation of these functions provides program consistency checking
within  Ada/SQL.   Ada/SQL schemas also contain sufficient information to  be
used  as input to a test data generator to produce test data  for  populating
databases defined by them.

EXAMPLE:

- -- This package defines the ADMINISTRATION authorization identifier.
- -- Authorization packages are used for two purposes:
- -- (1) The authorization function defined (ADMINISTRATION in this example) is
- --      referenced from a schema package to indicate the schema authorization
- --      identifier, e.g., a schema package including the definition
- --        SCHEMA_AUTHORIZATION : IDENTIFIER := ADMINISTRATION;
- --      where ADMINISTRATION is the function defined herein, will be
- --      considered part of the ADMINISTRATION schema.
- -- (2) Other schemas reference the authorization function to grant privileges
- --      to that authorization identifier.  The ADMINISTRATION function is
- --      called in the body of COMPANYDB_TABLES_SCHEMA (below) for this
- --      purpose.
- -- Note how the ADMINISTRATION authorization package is independent of any
- --  ADMINISTRATION schema that might be defined.  This is done by design to
- --  minimize the number of recompilations required by changes to schemas.
- --  Suppose, for example, that there were an ADMINISTRATION schema.  If the
- --  schema is changed, must any other schemas granting privileges to
- --  ADMINISTRATION be recompiled?  No, because they "with" only the
- --  ADMINISTRATION authorization package, not any of the schema packages.
- --  (Packages referencing tables within the ADMINISTRATION schema may, of
- --  course, require recompilation.)
- -- AUTHORIZATION_IDENTIFIER is a generic function defined within
- --  SCHEMA_DEFINITION.  IDENTIFIER is a type defined within SCHEMA_-
- --  DEFINITION.
- -- The SCHEMA_DEFINITION package also includes the functions and procedures
- --  necessary to define views and grant privileges.

with SCHEMA_DEFINITION;
  use SCHEMA_DEFINITION;

package ADMINISTRATION_AUTHORIZATION is

  function ADMINISTRATION is new AUTHORIZATION_IDENTIFIER;

end ADMINISTRATION_AUTHORIZATION;
- -----------------------------------------------------------------------------
- -- This is the authorization package for the PERSONNEL authorization
- --  identifier.

with SCHEMA_DEFINITION;
  use SCHEMA_DEFINITION;

package PERSONNEL_AUTHORIZATION is

  function PERSONNEL is new AUTHORIZATION_IDENTIFIER;

end PERSONNEL_AUTHORIZATION;
- -----------------------------------------------------------------------------
- -- This is the authorization package for the COMPANYDB authorization
- --  identifier.
- -- The COMPANYDB schema is the only schema shown in this example.

with SCHEMA_DEFINITION;
  use SCHEMA_DEFINITION;

package COMPANYDB_AUTHORIZATION is

  function COMPANYDB is new AUTHORIZATION_IDENTIFIER;

end COMPANYDB_AUTHORIZATION;
- -----------------------------------------------------------------------------
- -- This package defines the data types used within the COMPANYDB schema.  As
- --  can be seen, data types need not be defined within actual schema pack-
- --  ages.  The ability to "with" definitions from other packages permits all
- --  the Ada flexibilities of program organization.  Also, it is logical to
- --  define types separately from schemas in those instances where some pro-
- --  grams handle data of those types without accessing a database.  Such pro-
- --  grams may then "with" only the type definitions, and not the database
- --  definitions.

package COMPANYDB_TYPES is

  type EMPLOYEE_NAME is new STRING(1..15);
  subtype EMPLOYEE_NAME_NOT_NULL_UNIQUE is EMPLOYEE_NAME;

  type EMPLOYEE_AGE is range 14..100;
    -- many other type definitions would also use SQL NUMERIC(3,0)

  type EMPLOYEE_SAL is delta 0.01 range 0.00..999_999.99;
    -- many other type definitions would also use SQL DECIMAL(8,2)

  type DEPT_NAME is new STRING(1..10);
  subtype DEPT_NAME_NOT_NULL_UNIQUE is DEPT_NAME;

  type DEPT_LOC is new STRING(1..2);
  -- an enumeration type might also be used

end COMPANYDB_TYPES;
- -----------------------------------------------------------------------------
- -- This is the classification package for the COMPANYDB_TABLES schema
- --  package.
- -- For the MIL-STD, every schema package must have a corresponding
- --  classification package.  This is not required for the ANSI standard.  A
- --  classification package defines the security classification of all columns
- --  in each table defined by the corresponding schema package.
- -- The CLASSIFICATION_DEFINITION package defines a type CLASSIFICATION, which
- --  may be adjusted to suit specific environments.  Although not specified
- --  for our simple example, it might be an enumeration type such as
- --    type CLASSIFICATION is (UNCLASSIFIED,CONFIDENTIAL,SECRET,TOP_SECRET);
- --  In more complex environments, CLASSIFICATION might be a record type, with
- --   components indicating releasability, special handling, and sensitive
- --   source caveats as well as the standard four levels shown above.
- -- SECURITY_CLASSIFICATION is a generic function defined in
- --  CLASSIFICATION_DEFINITION, which is instantiated for the most restrictive
- --  classification in the package being declared.  The instantiated function
- --  (COMPANYDB_TABLES in this case) is called from a schema package to
- --  indicate which classification package applies to it.  Thus,
- --  COMPANYDB_TABLES_SCHEMA contains the declaration
- --    SECURITY : CLASSIFICATION := COMPANYDB_TABLES;
- --  By design, the instantiated function returns the classification with
- --  which it was instantiated, so that a program referencing
- --  COMPANYDB_TABLES_SCHEMA.SECURITY can determine the most restrictive
- --  classification applying to the data.
- -- A classification package defines record types paralleling those defining
- --  tables in the corresponding schema -- the records have the same structure
- --  and component names, but components are of type CLASSIFICATION in a
- --  classification package.  Default values for the components are used to
- --  indicate classifications of the columns.  The classification record types
- --  are all limited private to indicate that classifications may not be
- --  arbitrarily adjusted by application programs.
- -- It is by design that classification records parallel database records.  A
- --  system could store an associated classification record with each data
- --  record stored, thereby marking each data value with a classification.
- --  This is not required by the present standard, which assumes that marking
- --  is at the column level; future standards may include syntax for marking
- --  individual data values by setting classification records.

with CLASSIFICATION_DEFINITION;
  use CLASSIFICATION_DEFINITION;

package COMPANYDB_TABLES_CLASSIFICATION is

  function COMPANYDB_TABLES is new SECURITY_CLASSIFICATION(UNCLASSIFIED);

  type EMPLOYEE is limited private;

  type DEPT is limited private;

private

  type EMPLOYEE is
    record
      NAME : CLASSIFICATION := UNCLASSIFIED;
      AGE  : CLASSIFICATION := UNCLASSIFIED;
      SAL  : CLASSIFICATION := UNCLASSIFIED;
      DEPT : CLASSIFICATION := UNCLASSIFIED;
    end record;

  type DEPT is
    record
      NAME : CLASSIFICATION := UNCLASSIFIED;
      LOC  : CLASSIFICATION := UNCLASSIFIED;
    end record;

end COMPANYDB_TABLES_CLASSIFICATION;
- -----------------------------------------------------------------------------
- -- This is one of the two schema packages comprising the COMPANYDB schema.
- -- The two packages together define the single SQL schema given the COMPANYDB
- --  authorization identifier.
- -- By design, several schema packages can be used to define a single SQL
- --  schema.  This minimizes recompilation in that a change to one schema
- --  package may not affect the other schema packages for the same schema.
- --  Programs referencing the schema do not require recompilation unless they
- --  are dependent on the modified schema package.
- -- Record type declarations in schema packages also declare database tables.
- --  The record type name is used for the table name, component names are used
- --  for the column names, and the component data types define the column data
- --  types.
- -- Note the specifications of the schema authorization identifier and securi-
- --  ty classification definition, as discussed in comments on other packages.

with SCHEMA_DEFINITION, COMPANYDB_AUTHORIZATION, COMPANYDB_TYPES,
 CLASSIFICATION_DEFINITION, COMPANYDB_TABLES_CLASSIFICATION;
  use SCHEMA_DEFINITION, COMPANYDB_AUTHORIZATION, COMPANYDB_TYPES,
   CLASSIFICATION_DEFINITION, COMPANYDB_TABLES_CLASSIFICATION;

package COMPANYDB_TABLES_SCHEMA is

  SCHEMA_AUTHORIZATION : IDENTIFIER := COMPANYDB;

  SECURITY : CLASSIFICATION := COMPANYDB_TABLES;

  type EMPLOYEE is
    record
      NAME : EMPLOYEE_NAME_NOT_NULL_UNIQUE;
      AGE  : EMPLOYEE_AGE;
      SAL  : EMPLOYEE_SAL;
      DEPT : DEPT_NAME;
    end record;

  type DEPT is
    record
      NAME : DEPT_NAME_NOT_NULL_UNIQUE;
      LOC  : DEPT_LOC;
    end record;

end COMPANYDB_TABLES_SCHEMA;
- -----------------------------------------------------------------------------
- -- This is the body of the first COMPANYDB schema package.
- -- Views, privileges, and uniqueness constraints may be defined in package
- --  bodies.
- -- This is done by design, to minimize the number of recompilations required
- --  when adjusting privileges or uniqueness constraints, or changing a view
- --  definition without affecting the names or types of the columns returned.
- -- Any of these changes requires that only the affected package body be
- --  recompiled; it is not necessary to recompile the package specification.
- --  Therefore, no other recompilations are required.
- -- COMPANYDB_TABLES is the package created by the SQL function generator from
- --  the package specification of COMPANYDB_TABLES_SCHEMA.  The required
- --  processing order for a schema package is therefore:
- --  (1) Compile the specification
- --  (2) Run the SQL function generator on the specification
- --  (3) Compile the body (one is required only if views and/or privileges are
- --       defined, or if it is desired to define uniqueness constraints there)
- --  (4) Run the schema translator after all specifications and bodies in a
- --       schema have been compiled
- --  Source files must be compiled before being given to the Ada/SQL automated
- --  tools.
- -- Functions for database names are generated in COMPANYDB_TABLES.  The DEPT
- --  and EMPLOYEE functions referenced here are among them.
- -- A schema package must have a name of the form X_SCHEMA, so that the pack-
- --  age generated by the SQL function generator may be named X.  This is the
- --  only package naming restriction imposed by Ada/SQL.  Schema packages are
- --  related to authorization and classification packages by calling the
- --  functions defined in those packages, not by package naming convention.
- --  It is, however, suggested that the example conventions of using
- --  X_AUTHORIZATION and X_CLASSIFICATION as package names be continued.

with SCHEMA_DEFINITION, ADMINISTRATION_AUTHORIZATION,
 PERSONNEL_AUTHORIZATION, COMPANYDB_TABLES;
  use SCHEMA_DEFINITION, ADMINISTRATION_AUTHORIZATION,
   PERSONNEL_AUTHORIZATION, COMPANYDB_TABLES;

package body COMPANYDB_TABLES_SCHEMA is
begin

  GRANT ( SELEC, ON => DEPT,     TO => PUBLIC);
  GRANT ( ALLL,  ON => DEPT,     TO => ADMINSTRATION);
  GRANT ( ALLL,  ON => EMPLOYEE, TO => PERSONNEL);

end COMPANYDB_TABLES_SCHEMA;
- -----------------------------------------------------------------------------
- -- This is the classification package for the second COMPANYDB schema
- --  package.
- -- This particular schema was segmented into a package for the base tables
- --  and a package for the views.  This is not a requirement; as many base
- --  tables and views as desired may be defined within the same schema
- --  package.

with CLASSIFICATION_DEFINITION;
  use CLASSIFICATION_DEFINITION;

package COMPANYDB_VIEWS_CLASSIFICATION is

  function COMPANYDB_VIEWS is new SECURITY_CLASSIFICATION(UNCLASSIFIED);

  type EMPVIEW is limited private;

private

  type EMPVIEW is
    record
      EMP  : CLASSIFICATION := UNCLASSIFIED;
      DEPT : CLASSIFICATION := UNCLASSIFIED;
    end record;

end COMPANYDB_VIEWS_CLASSIFICATION;
- -----------------------------------------------------------------------------
- -- This is the second schema package
- -- Record type definitions are required for views as well as for base tables.
- --  Views, however, are also defined in the bodies of schema packages.

with SCHEMA_DEFINITION, COMPANYDB_AUTHORIZATION, COMPANYDB_TYPES,
 CLASSIFICATION_DEFINITION, COMPANYDB_VIEWS_CLASSIFICATION;
  use SCHEMA_DEFINITION, COMPANYDB_AUTHORIZATION, COMPANYDB_TYPES,
   CLASSIFICATION_DEFINITION, COMPANYDB_VIEWS_CLASSIFICATION;

package COMPANYDB_VIEWS_SCHEMA is

  SCHEMA_AUTHORIZATION : IDENTIFIER := COMPANYDB;

  SECURITY : CLASSIFICATION := COMPANYDB_VIEWS;

  type EMPVIEW is
    record
      EMP  : EMPLOYEE_NAME;
      DEPT : DEPT_NAME;
    end record;

end COMPANYDB_VIEWS_SCHEMA;
- -----------------------------------------------------------------------------
- -- The body of the second COMPANYDB schema package with view and privilege
- --  definitions
- -- COMPANYDB_TABLES is, as discussed before, generated from
- --  COMPANYDB_TABLES_SCHEMA
- -- Likewise, COMPANYDB_VIEWS is generated from the specification of this
- --  package
- -- Table and column names defined in COMPANYDB_TABLES and referenced here are
- --  EMPLOYEE, NAME, and DEPT
- -- Table and column names defined in COMPANYDB_VIEWS and referenced here are
- --  EMPVIEW, EMP, and DEPT
- -- Note that DEPT is defined in both packages, and will produce homographs.
- -- DEPT is not a homograph when used to define the name of an EMPVIEW column,
- --  since only COMPANYDB_VIEWS.DEPT can be used as such.  Using the appro-
- --  priate definitions, Ada/SQL causes the Ada compiler to require that
- --  column names used in a view definition in a package body must have been
- --  declared as view columns in the corresponding package specification.
- -- DEPT is, however, a homograph when used as an element in a SELEC list,
- --  since both EMPVIEW.DEPT (defined in COMPANYDB_VIEWS) and EMPLOYEE.DEPT
- --  (defined in COMPANYDB_TABLES) are valid column names.  Consequently, it
- --  must be qualified when used as such.  This is a hazard of splitting a
- --  single schema into several portions -- homographs will arise if the same
- --  name is defined in more than one schema package.  We have used the SQL-
- --  style qualification -- EMPLOYEE.DEPT actually selects the component named
- --  DEPT from the record returned by the function EMPLOYEE defined in
- --  COMPANYDB_TABLES.  This is a different overloaded version of the EMPLOYEE
- --  table than is called on the next line.  An Ada-style qualification could
- --  have also been used -- COMPANYDB_TABLES.DEPT would select the DEPT column
- --  function from the COMPANYDB_TABLES package.
- -- Duplicate column names within the same schema package do not cause
- --  homographs -- only one column function (actually a set of overloaded
- --  functions) is defined.  Due to the implementation of strong typing,
- --  however, the use of an unqualified column name in the same expression as
- --  a literal, universal, or overloaded value may cause an unresolvable
- --  ambiguity if there exist columns of different types having that same
- --  name.  The ambiguity can be resolved by qualifying the column name with
- --  the appropriate table name.  In this example, NAME is such a potentially
- --  ambiguous column name.  Its use in the SELEC list is, however, not
- --  ambiguous.  (We are here talking about ambiguity to the Ada compiler.
- --  Qualification with the table name may be required only to remove the Ada
- --  ambiguity; the unqualified column name may be unambiguous to SQL.)

with SCHEMA_DEFINITION, COMPANYDB_TABLES, COMPANYDB_VIEWS;
  use SCHEMA_DEFINITION, COMPANYDB_TABLES, COMPANYDB_VIEWS;

package body COMPANYDB_VIEWS_SCHEMA is
begin

  CREATE_VIEW ( EMPVIEW ( EMP  & DEPT ),
          AS => SELEC   ( NAME & EMPLOYEE.DEPT,
                FROM   => EMPLOYEE ) );

  GRANT ( SELEC, ON => EMPVIEW, TO => PUBLIC);

end COMPANYDB_VIEWS_SCHEMA;

Note:  This  example  demonstrates  a  possible  Ada/SQL  definition  of  the
illustrative  database  used  within the paper "Proposed Language  Access  to
Draft Proposed American National Standard Database Language SQL",  ANSC  X3H2
(Database), March 1985, which is defined in SQL as:

SCHEMA
AUTHORIZATION COMPANYDB
TABLE EMPLOYEE
  (NAME  CHARACTER(15)  NOT NULL UNIQUE,
   AGE   NUMERIC(3,0),
   SAL   DECIMAL(8,2),
   DEPT  CHARACTER(10))
TABLE DEPT
  (NAME  CHARACTER(10)  NOT NULL UNIQUE,
   LOC   CHARACTER (2))
VIEW EMPVIEW (EMP, DEPT)
   AS SELECT  NAME, DEPT   FROM  EMPLOYEE
GRANT SELECT  ON  DEPT  TO  PUBLIC
GRANT SELECT  ON  EMPVIEW  TO  PUBLIC
GRANT ALL  ON  DEPT  TO  ADMINISTRATION
GRANT ALL  ON  EMPLOYEE  TO  PERSONNEL

FORMAT:

<schema> ::= <compilation unit> ...

Several  Ada  compilation units,  all packages,  combine together to  form  a
schema.   Building a single schema out of several packages adheres to the Ada
modular program philosophy,  and allows parts of schemas to be modified with-
out necessarily requiring recompilation of all programs using the schema.

<compilation unit> ::=
     <context clause> <library unit>  <context clause> <secondary unit>

<context clause> ::= as in Ada, except that only packages may be named

The  packages  comprising  a schema can "with" and "use"  other  packages  as
required for visibility.

<library unit> ::=
     <authorization package declaration>
    <classification package declaration>
    <schema package declaration>

<secondary unit> ::= <library unit body>

<library unit body> ::= <schema package body>

Four types of compilation units are used within schemas:

(1) Authorization packages declare authorization identifiers,

(2) Classification packages declare the classification of all columns defined
within the corresponding schema package declaration,

(3) Schema packages declare database tables and columns, and

(4) The bodies of schema packages declare views,  grant privileges,  and  may
set uniqueness constraints.

<authorization package declaration> ::= see section 4.1a

<classification package declaration> ::= see section 4.6a

<schema package declaration> ::= see section 4.1b

<schema package body> ::= see section 4.5

4.1a <schema> - <authorization package declaration>

FUNCTION:

Each  authorization  package declares a different  authorization  identifier.
This  authorization identifier may be used as a schema authorization  identi-
fier and/or as a target identifier for granting privileges.

EXAMPLE:

with SCHEMA_DEFINITION;
  use SCHEMA_DEFINITION;

package ADMINISTRATION_AUTHORIZATION is

  function ADMINISTRATION is new AUTHORIZATION_IDENTIFIER;

end ADMINISTRATION_AUTHORIZATION;

FORMAT:

<authorization package declaration> ::=
     <authorization package specification> ;

<authorization package specification> ::=
     package <identifier> is
       function <authorization identifier> is new AUTHORIZATION_IDENTIFIER;
     end [ <package simple name> ]

<identifier> ::= any valid name for a library package

<authorization  identifier> ::= the identifier that will be used for granting
     privileges and/or as a schema authorization identifier

<package simple name> ::= must match the package <identifier> if used

To define the generic function AUTHORIZATION_IDENTIFIER,  the context  clause
of an authorization package must read:

  with SCHEMA_DEFINITION; use SCHEMA_DEFINITION;

The  sole function of an authorization package is to define an  authorization
identifier.  Authorization packages do not have bodies.

4.1b <schema> - <schema package declaration>

FUNCTION:

Schema  package  declarations  define  the table and column  names  within  a
schema.

EXAMPLE:

with SCHEMA_DEFINITION, COMPANYDB_AUTHORIZATION, COMPANYDB_TYPES,
 CLASSIFICATION_DEFINITION, COMPANYDB_VIEWS_CLASSIFICATION;
  use SCHEMA_DEFINITION, COMPANYDB_AUTHORIZATION, COMPANYDB_TYPES,
   CLASSIFICATION_DEFINITION, COMPANYDB_VIEWS_CLASSIFICATION;

package COMPANYDB_VIEWS_SCHEMA is

  SCHEMA_AUTHORIZATION : IDENTIFIER := COMPANYDB;

  SECURITY : CLASSIFICATION := COMPANYDB_VIEWS;

  type EMPVIEW is
    record
      EMP  : EMPLOYEE_NAME;
      DEPT : DEPT_NAME;
    end record;

end COMPANYDB_VIEWS_SCHEMA;

FORMAT:

<schema package declaration> ::= <schema package specification> ;

<schema package specification> ::=
     package <identifier> is
       <schema authorization clause>
     [ <schema classification clause> ]
     [ <schema declaration element> ... ]
     end [ <package simple name> ]

A <schema classification clause> is only required by the MIL-STD,  not by the
ANSI standard.   If all tables declared within the schema package are  views,
then  a  <schema  classification clause> is optional.   In the absence  of  a
classification  specification for a view,  the classification of each  column
defaults to the most restrictive classification on the data used to material-
ize that column.

<identifier> ::= a valid name for a library package, that must be of the form
     X_SCHEMA to permit the package generated from this one to be named X  by
     the SQL function generator

<package simple name> ::= must match the package <identifier> if used

<schema authorization clause> ::=
     SCHEMA_AUTHORIZATION : [ SCHEMA_DEFINITION . ] IDENTIFIER
          := <schema authorization identifier> ;

<schema authorization identifier> ::= <authorization identifier>

<authorization identifier> ::= as defined within an authorization package (see
     section 4.1a)

The  SQL <schema authorization identifier> for the schema is taken to be  the
<authorization identifier> used here.   The appropriate authorization package
must,  of course, be named within the context clause of the schema package in
order  to  make the instantiated function for the <authorization  identifier>
visible.   The  full  name of the <authorization identifier> may be  used  if
visibility  is  desired by selection;  only the simple name is  used  as  the
<authorization identifier>.   SCHEMA_DEFINITION must also be named within the
context clause to make the type IDENTIFIER visible.  As indicated, IDENTIFIER
may  be  visible either directly or by selection.   The  same  <authorization
identifier>  may be referenced from several schema packages;  the tables  de-
clared in those packages are all placed in the same SQL schema.

<schema classification clause> ::=
     SECURITY : [ CLASSIFICATION_DEFINITION . ] CLASSIFICATION
          := <classification identifier> ;

<classification  identifier>  ::= as defined within a classification  package
     (see section 4.6a)

The appropriate classification package must,  of course,  be named within the
context clause of the schema package in order to make the instantiated  func-
tion  for  the  <classification identifier> visible.   The full name  of  the
<classification  identifier> may be used if visibility is desired  by  selec-
tion.  CLASSIFICATION_DEFINITION must also be named within the context clause
to make the type CLASSIFICATION visible.  As indicated, CLASSIFICATION may be
visible either directly or by selection.

<schema declaration element> ::=
     <basic declarative item>  <table definition>

<basic  declarative item> ::= an Ada basic declarative item,  subject to  the
     interpretations and restrictions discussed in section 4.7

<table definition> ::= see section 4.2

Declarations  within  schema  packages are not limited to the  definition  of
database tables; types, etc. may also be defined as required.

4.2 <table definition>

FUNCTION:

Define  the name of a database table,  as well as the column names  and  data
types.   Unlike SQL, table definitions must be given for both base tables and
views.  A view is distinguished from a base table by having a view definition
in the body of the schema package in which the corresponding table definition
appears.

EXAMPLE:

  type EMPVIEW is
    record
      EMP  : EMPLOYEE_NAME;
      DEPT : DEPT_NAME;
   end record;

FORMAT:

<table definition> ::=
     type <table name> [ <discriminant part> ] is
       record
         <component list>
       end record ;

<table name> ::= a valid Ada record type name,  which is also taken to be the
     name of the database table being declared

Within a schema package,  the declaration of a record type that is not refer-
enced  from another record type also declares a database table.   The name of
the table is taken to be the name of the record type,  and the columns of the
table  are given by the components of the record type.   "Columns" may be  of
composite  types,  so lowest level subcomponents become actual database  col-
umns.   Ada/SQL does,  however, permit access to data as logically structured
and  grouped by composite types.   The runtime system will translate  between
Ada composite structures and the simpler underlying database  representation.
Subcolumns  may also be accessed by using indexing or component selection for
array and record columns, respectively.

<discriminant part> ::=
     ( <discriminant table element>
          [ { ; <discriminant table element> } ... ] )

<discriminant table element> ::= <table element>

<component list> ::=
     <table element> ; [ { <table element> ; } ... ]
    [ { <table element> ; } ... ] <variant part>
    null ;

Both  discriminant parts and component lists declare record  components,  and
hence table columns.   In Ada,  a discriminant specification   (<discriminant
table  element> here) looks essentially like a component declaration  (<table
element>  here),  with the following restrictions:  (1) The type/subtype of a
discriminant  may  only be given by a type mark,  not by  a  general  subtype
indication,  and (2) discriminants must be discrete.  These restrictions must
be  remembered  when reading the following discussion of <table element>s  --
they will be enforced by the Ada compiler and by the Ada/SQL automated tools.

No  corresponding  database table is defined for the declaration  of  a  null
record.

<variant part> ::=
     case <discriminant simple name> is
          <variant>
        [ <variant> ... ]
     end case ;

<discriminant simple name> ::= as in Ada

<variant> ::=
     when <choice> [ {  <choice> } ... ] =>
       <component list>

<choice> ::= as in Ada

Accessing a column within a variant part restricts the rows that are  consid-
ered  to  be within the table.   In particular,  only those rows  that  would
contain the column,  based on the Ada meaning of the discriminant value,  are
accessed.

<table element> ::=
     <column definition>
    <single column unique constraint definition>                             |

<column definition> ::= see section 4.3

<single column unique constraint definition> ::= see section 4.4

4.3 <column definition>

FUNCTION:

Define the names,  data types,  null value possibilities,  and uniqueness re-
quirements for database columns.

EXAMPLE:

  NAME : EMPLOYEE_NAME_NOT_NULL_UNIQUE;
  AGE  : EMPLOYEE_AGE;

FORMAT:

<column definition> ::=
     <column name list> : <data type> [ _NOT_NULL [ _UNIQUE ] ]
          [ <constraint> ] [ := <expression> ]

<column  name list> := an Ada identifier list -- the Ada syntax for discrimi-
     nant  specifications and component declarations permits several  columns
     to be defined within the same <column definition>.   The component names
     and data types are used for the column names and data types.

<data type>  ::= an Ada type mark.   The type mark may include  the  suffixes
     _NOT_NULL  or _NOT_NULL_UNIQUE,  which causes the appropriate constraint
     to be defined for the database.

<constraint> ::= an Ada constraint,  permitted only if a component other than
     a discriminant is being defined.   The constraint must be static, unless
     it  depends on a discriminant,  in which case discriminant names may  be
     the only non-static items in the constraint.

<expression>  ::=  an  Ada expression that provides default  values  for  the
     record  components  and also for the database columns.   When  inserting
     rows with unspecified values for columns that have defaults, the default
     values  are stored in the columns.   Null values are stored  in  columns
     with  neither specified values nor defaults,  with an error occurring if
     any of those columns do not permit null values.  The default values used
     for a table are the same as would be used by Ada when creating an object
     of  the  record type corresponding to the table,  at the  point  in  the
     program of the insert operation.   Default expressions must be static in
     Ada/SQL,  since they are processed at compile time, except that the name
     of a discriminant may be used.

4.4 <unique constraint definition>

FUNCTION:

Specify that a column or a group of columns is to contain only unique data.

EXAMPLE:

  NAME : DEPT_NAME_NOT_NULL_UNIQUE; -- 1

  CONSTRAINTS ( EMPLOYEE , UNIQUE ( SAL & DEPT ) ); -- 2

FORMAT:

<unique constraint definition> ::=
     <single column unique constraint definition>
    <multiple column unique constraint definition>                           |

A <single column unique constraint definition> is used to apply a  uniqueness
constraint  to  a  single column,  directly as the column is defined  in  its
enclosing  <table definition> (see section 4.2).   Applying a <single  column
unique  constraint  definition> to a composite column  defines  a  uniqueness
constraint  over  several underlying database columns.   A  <multiple  column
unique  constraint  definition> is used to apply a uniqueness  constraint  on
several Ada/SQL columns.  (It may also be used with single columns.)

<single column unique constraint definition> ::= <column definition>

<column definition> ::= see section 4.3

No special Ada/SQL <single column uniqueness constraint definition> syntax is
required -- Ada/SQL column definitions provide all the capabilities necessary
to  define single column uniqueness constraints.   Suffixing a column's  data
type  with  _NOT_NULL_UNIQUE defines a uniqueness  constraint,  as  shown  in
example 1.  If the column is a composite column, the uniqueness constraint is
actually  over a group of underlying database columns,  which is part of  the
capability  provided by SQL <unique constraint definition>s.   The  remaining
capability provided by SQL <unique constraint definition>s, that of including
the  same  database  column in several <unique  constraint  definition>s,  is
provided by <multiple column unique constraint definition>s in Ada/SQL.

<multiple column unique constraint definition> ::=
     CONSTRAINTS ( <table name> , UNIQUE ( <unique column list> ) ) ;

A <multiple column unique constraint definition>,  as shown in example 2,  is
placed  in  the <schema package body> (see section 4.5) corresponding to  the
<schema package declaration> in which the referenced <table name> is defined.
Its  effect is to cause CONSTRAINTS UNIQUE(<unique column list>) to be  added
to the SQL <table definition> for the <table name>.   Consequently, it may be
applied only to a base table.

<table  name>  ::= the name of a table defined in  the  corresponding  schema
     package  declaration.   The functions for the table name are defined  in
     the  package  produced  by the SQL function generator  from  the  schema
     package declaration, as are the table-specific CONSTRAINTS procedure and
     UNIQUE function.

<unique column list> ::=
     <column name> [ { & <column name> } ... ]

SQL  uses commas to separate the elements of a <unique column list>;  Ada/SQL
uses ampersands.   The ampersand functions are defined specifically for  each
table by the SQL function generator.

<column  name> ::= a name of a column defined for the table.   The  functions
     for the column names are defined by the SQL function generator.

4.5 <schema package body>

FUNCTION:

Views,  privileges,  and  multiple column uniqueness constraints are  defined
within the bodies of schema packages.

EXAMPLE:

package body COMPANYDB_VIEWS_SCHEMA is
begin

  CREATE_VIEW ( EMPVIEW ( EMP  & DEPT ),
          AS => SELEC   ( NAME & EMPLOYEE.DEPT,
                FROM   => EMPLOYEE ) );

  GRANT ( SELEC, ON => EMPVIEW, TO => PUBLIC);

end COMPANYDB_VIEWS_SCHEMA;

FORMAT:

<schema package body> ::=
     package body <package simple name> is
       [ <declarative part> ]
     begin
       <schema body element> ...
     end [ <package simple name> ] ;

<package simple name> ::= the package identifier of the corresponding  schema
     package  declaration.   Schema packages that do not define views,  grant
     privileges,  or  require multiple column uniqueness constraints are  not
     required to have bodies.

<declarative part> ::= as in Ada, except that the only declarations permitted
     are static constant object declarations,  number declarations,  renaming
     declarations,  and use clauses.   In short,  only declarations that will
     add  to  the convenience of defining  views,  privileges,  and  multiple
     column uniqueness constraints are permitted.

<schema body element> ::=
     <view definition>  <privilege definition>
    <multiple column unique constraint definition>                           |

<view definition> ::= see section 4.5a

<privilege definition> ::= see section 4.6

<multiple column unique constraint definition> ::= see section 4.4

For every view definition or multiple column unique constraint definition  in
a schema package body,  there must be a corresponding table definition in the
corresponding schema package declaration.

4.5a <view definition>

FUNCTION:

Define a viewed table.

EXAMPLE:

  CREATE_VIEW ( EMPVIEW ( EMP  & DEPT ),
          AS => SELEC   ( NAME & EMPLOYEE.DEPT,
                FROM   => EMPLOYEE ) );

FORMAT:

<view definition> ::=
     CREATE_VIEW ( <table name> [ ( <view column list> ) ] ,
             AS => <query specification> [ ,
             WITH_CHECK_OPTION => ENABLED ] ) ;

The two SQL keywords CREATE and VIEW are linked into a single Ada  identifier
with an underscore.  The CREATE_VIEW procedure is defined within SCHEMA_DEFI-
NITION.

<table  name>  ::=  the name of a table defined in the  corresponding  schema
     package  declaration.   The functions for the table name are defined  in
     the  package  produced  by the SQL function generator  from  the  schema
     package  declaration.   If  a <view column list> is  included,  and  the
     <table  name> includes an <authorization identifier>,  then  the  <table
     name>  must be expressed as <authorization identifier>-<table  identifi-
     er>,  instead  of as <authorization identifier>.<table  identifier>,  as
     used most elsewhere within Ada/SQL.

<view column list> ::=
     <column name> [ { & <column name> } ... ]

<column name> ::= a name of a column defined for the table.  If a view column
     list is given,  the column names must agree precisely,  in  order,  with
     those  defined  for the table in the schema  package  declaration.   The
     functions  for the column names are also defined in the package produced
     by the SQL function generator from the schema package declaration.

<query  specification> ::= see section 3.25.   The number of columns  defined
     for  the view must be the same as the degree of the table  specified  by
     the <query specification>.  Furthermore, the data type of each column of
     the <query specification> must be capable of being converted, via an Ada
     type  conversion,  to the data type of the corresponding column  defined
     for the view.

4.6 <privilege definition>

FUNCTION:

Define privileges.

EXAMPLE:

  GRANT ( SELEC, ON => EMPVIEW, TO => PUBLIC);
  GRANT ( ALLL,  ON => DEPT,    TO => ADMINISTRATION);

FORMAT;

<privilege definition> ::=
     GRANT ( <privileges> ,
       ON => <table name> ,
       TO => <grantee> [ { & <grantee> } ... ] [ ,
       WITH_GRANT_OPTION => ENABLED ] ) ;

GRANT  procedures and ancillary functions for each table defined in a  schema
package  declaration  are  defined in the package produced from  that  schema
package declaration by the SQL function generator.   Ancillary functions that
are not table-specific are defined in SCHEMA_DEFINITION.   Each clause in the
GRANT  statement  is a parameter to the  GRANT  procedure.   Parameter  names
retain  the SQL keywords.   WITH_GRANT_OPTION differs slightly from SQL to be
more Ada-like, and is an optional last parameter.  The grantee list is linked
together with ampersands; in SQL there are no operators between the grantees.

<privileges> ::=
     ALLL  ALL_PRIVILEGES
    <action> [ { & <action> } ... ]

ALL  is  an Ada reserved word and so cannot be used,  and ALL  PRIVILEGES  is
connected with an underscore.  In SQL the action list is separated by commas,
Ada/SQL uses ampersands as elsewhere.   ALLL and ALL_PRIVILEGES are functions
defined in SCHEMA_DEFINITION.

<action> ::=
     SELEC  INSERT | DELETE
    UPDATE [ ( <grant column list> ) ]

SQL uses SELECT;  Ada/SQL uses SELEC because SELECT is an Ada reserved  word.
The SELEC,  INSERT,  DELETE, and UPDATE functions, as they apply to privilege
definitions, are defined in the appropriate generated package.

<grant column list> ::=
     <column name> [ { & <column name> } ... ]

The  column names are linked together with ampersands rather than commas,  as
is customary within Ada/SQL.

<column name> ::= the name of a column in the table for which privileges  are
     being granted.  Functions defining column names are produced from schema
     package declarations by the SQL function generator.

<grantee> ::=
     PUBLIC  <authorization identifier>

<authorization  identifier>  ::= as defined within an  authorization  package
     (see section 4.1a)

A  function defining PUBLIC is declared in SCHEMA_DEFINITION.   Authorization
identifiers are defined in the applicable authorization packages,  which must
be named within the context clause of the schema package body in order to  be
used.

4.6a <classification package declaration>

FUNCTION:

Classification package declarations are used to define the classifications of
all columns of the database.   Each schema package declaring base tables must
have  a corresponding classification package.   The classification package is
"with"ed into the schema package,  and a <schema classification clause>  (see
section  4.1b) is used to indicate the relation of the classification package
to the schema package.  Classification packages are required only by the MIL-
STD, not by the ANSI standard.

EXAMPLE:

package COMPANYDB_VIEWS_CLASSIFICATION is

  function COMPANYDB_VIEWS is new SECURITY_CLASSIFICATION(UNCLASSIFIED);

  type EMPVIEW is limited private;

private

  type EMPVIEW is
    record
      EMP  : CLASSIFICATION := UNCLASSIFIED;
      DEPT : CLASSIFICATION := UNCLASSIFIED;
    end record;

end COMPANYDB_VIEWS_CLASSIFICATION;

FORMAT:

<classification package declaration> ::=
     <classification package specification> ;

<classification package specification> ::=
     package <identifier> is
       function <classification identifier> is new
         [ CLASSIFICATION_DEFINITION . ] SECURITY_CLASSIFICATION
             ( <classification> ) ;
       <private type declaration> ...
     private
       <table definition> ...
     end [ <package simple name> ]

The  <classification  identifier>  is defined by  instantiating  the  generic
SECURITY_CLASSIFICATION function which is defined within CLASSIFICATION_DEFI-
NITION.   As  indicated,  SECURITY_CLASSIFICATION can be made visible  either
directly or by selection.

<identifier> ::= any valid name for a library package

<package simple name> ::= must match the package <identifier> if used

<classification  identifier>  ::=  the identifier that will be  used  in  the
     <schema classification clause> of a schema package to indicate that this
     classification  package  declaration is applicable to  it  (see  section
     4.1b)

<classification>  ::=  a value of type CLASSIFICATION,  indicating  the  most
     restrictive  classification  applied within this classification  package
     declaration.  Type CLASSIFICATION is defined within CLASSIFICATION_DEFI-
     NITION,  and  may  be tailored for the specific environment  to  include
     basic classification,  releasability,  special handling,  and  sensitive
     source information.

<private type declaration> ::= as in Ada, with a limited private type declar-
     ation for each table definition in the schema package that will use this
     classification package declaration.   The names and discriminants of the
     limited  private types are the same as those of the corresponding record
     types.   (This duplication of record type names is the reason that sepa-
     rate  classification packages are required.)  All discriminants  are  of
     type CLASSIFICATION, however.  An additional discriminant, called TABLE,
     may  be  defined  if it is desired to specify a classification  for  the
     entire table.  In the absence of the special TABLE discriminant, a table
     is  given  the most restrictive classification defined for  all  of  its
     columns.   Each discriminant must be given a default value,  which indi-
     cates the classification of the corresponding column.

<table definition> ::= see section 4.2.  Corresponding full type declarations
     must be provided for all limited private types declared.   The full type
     declarations must have components named the same,  in the same order, as
     the corresponding table definitions to which they apply.  All components
     are  of type CLASSIFICATION,  however.   Default values must be provided
     for all components,  to indicate the classification of the corresponding
     database  columns.   It should be noted that composite columns have  but
     one classification; later versions of this standard may address separate
     classifications for subcolumns.

4.7 Special Considerations

This  section  describes special considerations that apply  to  data  defined
within  Ada/SQL schemas.   Subsections are organized according to the section
numbering and notational conventions of the Ada Programming Language Military
Standard (ANSI/MIL-STD-1815A),  hereafter referred to as the Language  Refer-
ence Manual (LRM).

4.7 Special Considerations - LRM section 2.3 - identifier

FUNCTION:

Identifiers  perform their usual Ada functions within schemas,  but are  also
used to name SQL authorization identifiers, tables, and columns.

EXAMPLE:

CITY                 -- columns of type/subtype CITY may contain null and/or
                     --  duplicate values
CITY_NOT_NULL        -- columns of this type/subtype may not contain null
                     --  values, but may contain duplicate values
CITY_NOT_NULL_UNIQUE -- columns of this type/subtype may not contain nulls
                     --  and also may not contain duplicate values

FORMAT:

identifier ::= as in Ada

Any  legal Ada identifiers may be used within schemas.   Identifiers used  as
SQL authorization identifiers, table names, or column names may not be passed
verbatim to the database management system,  however, because (1) SQL identi-
fiers  may include only upper case characters (case is not significant in Ada
anyway),  (2) SQL identifiers may not be longer than 18 characters,  (3)  SQL
identifiers  may not be identical to SQL key words,  and (4) certain  Ada/SQL
data definitions may cause underlying database tables to have duplicate table
and/or  column  names unless the names are qualified by selection in the  Ada
sense.   Ada/SQL  maps Ada identifiers (and full names,  where  necessary  to
avoid  duplicates) to appropriate underlying SQL identifiers,  with an algor-
ithm  that  attempts  to maintain as much semantic content  within  names  as
possible.

Identifiers used as type and subtype names may include the suffixes _NOT_NULL
or  _NOT_NULL_UNIQUE.   Database columns defined by record  subcomponents  of
types/subtypes  named with these suffixes will be given the corresponding SQL
constraints.

A  restriction  on  the use of the _NOT_NULL  and  _NOT_NULL_UNIQUE  suffixes
ensures  that only closely related types/subtypes have similar simple  names.
Two  identifiers  are considered similar if they differ only in  the  use  or
nonuse  of the _NOT_NULL and _NOT_NULL_UNIQUE suffixes.   If A and B are  two
directly  visible types/subtypes with similar simple names,  then one of  the
following  definitions must hold,  where C is another type,  not  necessarily
directly visible, with simple name similar to those of A and B:

  (1) subtype A is B;       (3) subtype C is A;       (4) subtype C is B;
  (2) subtype B is A;           subtype B is C;           subtype A is C;

4.7 Special Considerations - LRM section 3.1 - declaration

FUNCTION:

Declare the tables and columns of a database, as well as the types of data to
be stored within the database.

EXAMPLE:

  SECURITY_MARKING_LENGTH : constant := 12; -- a number declaration

  type SECURITY_CLASSIFICATION is (U,C,S,T); -- type declarations
  type SECURITY_MARKING is new STRING(1..SECURITY_MARKING_LENGTH);

  MINIMUM_CLASSIFICATION : constant SECURITY_CLASSIFICATION := C;
    -- an object declaration

  MINCLASS : SECURITY_CLASSIFICATION renames MINIMUM_CLASSIFICATION;
    -- a renaming declaration

  subtype CLASSIFICATION_LEVEL is SECURITY_CLASSIFICATION
    range MINIMUM_CLASSIFICATION..SECURITY_CLASSIFICATION'LAST;
      -- a subtype declaration

  type MARKING_TABLE is                -- a record type declaration that also
    record                             --  serves to declare a database table
      CLASS : SECURITY_CLASSIFICATION; --  and its columns (the table in this
      MARK  : SECURITY_MARKING;        --  example is rather trivial and
    end record;                        --  unnecessary)

FORMAT:

basic_declaration ::= as in Ada,  except that the only declarations permitted
     within  schema  packages are object declarations (see LRM section  3.2),
     number  declarations (see LRM section 3.2),  type declarations (see  LRM
     section 3.3.1),  subtype declarations (see LRM section 3.3.2) and renam-
     ing declarations (see LRM section 8.5).

The  only declarations that are permitted within a schema package  are  those
that  apply directly to the data definition function.   Further  restrictions
are  placed  on  the various declarations,  as discussed in  the  appropriate
sections following.   Packages named in the context clause of schema packages
may contain arbitrary declarations, if they are not also schema packages.

4.7 Special Considerations - LRM section 3.2 - constant object
     and named number

FUNCTION:

Define named constants (of arbitrary type) and numbers (of numeric type)

EXAMPLE:

  LIMIT     : constant INTEGER := 10_000;    -- taken from LRM section 3.2.1
  LOW_LIMIT : constant INTEGER := LIMIT/10;  -- in that example, TOLERANCE is
                                             --  not static and hence may not
  PI            : constant := 3.14159_26536; --  be used in a schema
  TWO_PI        : constant := 2.0*PI;        -- number declaration examples
  MAX           : constant := 500;           --  are taken from LRM section
  POWER_16      : constant := 2**16;         --  3.2.2
  ONE, UN, EINS : constant := 1;

FORMAT:

object_declaration ::= as in Ada,  except that only constants may be declared
     in a schema package.  Likewise, objects referenced from schema packages,
     except for discriminants, must be constants.

number_declaration ::= as in Ada

The purpose of a schema package is to declare database objects,  not  program
objects.  Hence, the declaration of arbitrary objects is not permitted within
schema packages.   Constants and named numbers are,  however,  permitted as a
convenience,  to allow meaningful names to be given to important values.  All
entities  used  within expressions in schema packages,  except for  discrimi-
nants,  must  be  static,  because all Ada/SQL automated tool  processing  is
performed at compile time.

4.7 Special Considerations - LRM section 3.3.1 - type declaration

FUNCTION:

Declare  types  of program and database values.   Also,  indicate  names  and
columns of database tables.

EXAMPLE:

  type DIGIT_CHARACTER is ('0','1','2','3','4','5','6','7','8','9');
    -- an enumeration type

  type DIGIT_VALUE is range 0..9; -- an integer type

  type MONEY is delta 0.01 range 0.00..1_000_000.00; -- a real type

  type PHONE_NUMBER is array(1..10) of DIGIT_CHARACTER; -- an array type

  type PHONE_BILL is -- a record type (also a database table in this example)
    record
      NUMBER : PHONE_NUMBER;
      DUE    : MONEY;
    end record;

  type OVERDUE_PHONE_BILL is new PHONE_BILL;
    -- a derived type (also a database table in this example)

FORMAT:

type_declaration  ::= as in Ada,  except that incomplete  type  declarations,
     private type declarations, access type definitions, and task type decla-
     rations  are not permitted within schema packages.   The following types
     may therefore be declared within schema packages:  enumeration (see  LRM
     section 3.5.1),  integer (see LRM section 3.5.4),  real (see LRM section
     3.5.6),  array (see LRM section 3.6),  record (see LRM section 3.7), and
     derived (see LRM sectin 3.4).

Access and task types may not be declared within schema packages.  Subcompon-
ents  of composite types declared or used within schema packages may also not
be of an access or task type.   As a result, incomplete type declarations are
not necessary, and may not be used, within schema packages.

Private types may not be declared within schema packages, since their declar-
ation  would  normally also require the declaration of  subprograms  defining
operations  on  the types.   And subprogram declarations  are  not  permitted
within  schema packages,  in order to restrict package text to that  required
specifically  for the data definition function.   However,  subcomponents  of
record  and  array types may be of a private type (defined in  other  library
units  used by the schema),  providing that the corresponding full type would
be permitted to be used for the subcomponents.

The  Ada/SQL operations available on a database column of a private type  are
limited to the following:

(1) Equality (EQ) and inequality (NE) comparisons,  including within <quanti-
fied predicate>s,

(2) Use as the argument of a COUNT_DISTINCT set function,

(3) IS_IN and NOT_IN comparisons,

(4) IS_NULL and IS_NOT_NULL tests (a composite column is null if and only  if
all subcolumns are null),

(5) Use in a GROUP_BY clause,

(6)  Use  in the SELEC clause of a  <sub-query>,  <query  specification>,  or
<select statement>,

(7) Use in the <insert column list> of an INSERT_INTO statement,

(8)  Use within a <set clause> of either type of UPDATE statement,  as either
the <object column> or the <value expression>,

(9) Use within a <grant column list> of a GRANT statement, and

(10) Selection of components that are discriminants.

Further  restriction  of  SQL operations to develop an  analogue  to  limited
private types is not fruitful;  hence,  limited private types may not be used
for database columns.

There are some other considerations that apply to the various classes of type
declaration within schemas; these are discussed within the referenced section
for  each  class  of type.   Any type that may be declared  within  a  schema
package can be used as the type of a database column,  and no other types may
be so used.

4.7 Special Considerations - LRM section 3.3.2 - subtype declaration

FUNCTION:

Declare  Ada  subtypes.   Subtypes may be used in their  Ada  sense,  and  to
indicate _NOT_NULL and _NOT_NULL_UNIQUE constraints.   Although not a part of
this  standard,  the  way in which subtypes relate to each other can also  be
used to guide test data generation.

EXAMPLE:

  type EMPLOYEE_NUMBER is range 1000..9999;

  subtype EMPLOYEE_NUMBER_NOT_NULL_UNIQUE is EMPLOYEE_NUMBER;

FORMAT:

subtype_declaration  ::= as in Ada,  except that it must be static,  and  may
     only define a subtype that would be permitted for a database column

Because the Ada/SQL automated tools will process schemas at compile time, all
subtypes defined must be static.   Furthermore,  only subtypes that would  be
legal for database columns may be defined within a schema.

A subtype of a _NOT_NULL or _NOT_NULL_UNIQUE type or subtype does not inherit
these properties;  they are determined solely based on the suffix of the type
or subtype name.

4.7 Special Considerations - LRM section 3.4 - derived type definition

FUNCTION:

Define a new type with characteristics derived from another type.

EXAMPLE:

  type PROMOTION_LIST_MEMBER is new EMPLOYEE_NUMBER;
    -- derived from the example on LRM section 3.3.2, above

FORMAT:

derived_type_definition ::= as in Ada, except that it must be static, and may
     only define a subtype that would be permitted for a database column

The  type  mark  in the subtype indication of a derived type  definition  may
include the suffix _NOT_NULL or _NOT_NULL_UNIQUE.   However, these properties
do not carry over to the derived type;  they are only conveyed by the  suffix
on a type or subtype name.

If the derived type is a record type,  then the derived type declaration also
declares  a  database table according to the same rules as for  other  record
types:  The  derived type declaration also declares a database table  if  and
only  if  the name of the derived type (or any subtype with a name  differing
only in the _NOT_NULL or _NOT_NULL_UNIQUE suffix) is not used as the type  of
a  subcomponent  within  another record declaration within  the  same  schema
package.   A  derived  database table is assumed to be a base table unless  a
view definition is given for it.

Type representation clauses, as they affect database representation, apply to
derived types as with Ada:  A type representation clause for the parent  type
applies  to the derived type if and only if it appears before the declaration
of the derived type.

4.7 Special Considerations - LRM section 3.5 - range constraint

FUNCTION:

Specify the legal range of values for a type or subtype

EXAMPLE:

  type COLUMN is range 1..72; -- from LRM section 3.3.1
  subtype RAINBOW is COLOR range RED..BLUE; -- from LRM section 3.3.2
  subtype PROBABILITY is REAL range 0.0..1.0; -- from LRM section 3.5.7
  type VOLT is delta 0.125 range 0.0..255.0; -- from LRM section 3.5.9

  type T is array(POSITIVE range MIN..MAX) of COMPONENT;
    -- from LRM section 3.6

  type DATE is -- from LRM section 3.7
    record
      DAY   : INTEGER range 1..31;
      MONTH : MONTH_NAME;
      YEAR  : INTEGER range 0..4000;
    end record;

FORMAT:

range_constraint ::= as in Ada, except that it must be static

A  database  column  of a type or subtype having a null  range  must  not  be
declared  as _NOT_NULL or _NOT_NULL_UNIQUE -- only null values may be  stored
within it.  (The usefulness of such a column would be extremely limited.)

4.7 Special Considerations - LRM section 3.5.1 - enumeration type definition

FUNCTION:

Define an enumeration type and its values.

EXAMPLE:

  type DAY    is (MON, TUE, WED, THU, FRI, SAT, SUN); -- examples taken from
  type SUIT   is (CLUBS, DIAMONDS, HEARTS, SPADES);   --  LRM sections 3.5.1
  type GENDER is (M, F);                              --  and 3.5.2
  type LEVEL  is (LOW, MEDIUM, URGENT);
  type COLOR  is (WHITE, RED, YELLOW, GREEN, BLUE, BROWN, BLACK);
  type LIGHT  is (RED, AMBER, GREEN);

  type HEXA   is ('A', 'B', 'C', 'D', 'E', 'F');
  type MIXED  is ('A', 'B', '*', B, NONE, '?', '%');

  type ROMAN_DIGIT is ('I', 'V', 'X', 'L', 'C', 'D', 'M');

FORMAT:

enumeration_type_definition ::= as in Ada

The Ada/SQL automated tools will recognize the predefined types CHARACTER and
BOOLEAN.   The  SQL operations available on enumeration types are the same as
are available on strings,  except that LIKE is not available for  enumeration
types.

SQL  does not directly support enumeration types,  so it is necessary to  map
Ada enumeration types into other SQL data types.   The mapping process should
achieve  three objectives:  (1) preserve the ordering of the enumeration val-
ues,  (2) use explicit representations if requested,  and (3) enable enumera-
tion  database  values  to be referenced/retrieved by  their  identifiers  or
character literals, even from non-Ada ways of accessing the database.

For any database type, subtype, or table T, T_NOT_NULL, or T_NOT_NULL_UNIQUE,
the SQL function generator defines a named number T_SIZE, of type universal_-
integer, to be equal to the minimum number of bits that is needed by the DBMS
implementation to hold any possible object of this type or subtype.   This is
defined as in Ada,  except considering DBMS storage units and  representation
instead of those of the host computer.  Values for private types are as would
be given for the underlying full type.

4.7 Special Considerations - LRM section 3.5.4 - integer type definition

FUNCTION:

Define the range of values for an integer type.

EXAMPLE:

  type PAGE_NUM  is range 1..2_000;  -- taken from LRM section 3.5.4
  type LINE_SIZE is range 1..MAX_LINE_SIZE;

  subtype SMALL_INT   is INTEGER   range -10..10;
  subtype COLUMN_PTR  is LINE_SIZE range 1..10;
  subtype BUFFER_SIZE is INTEGER   range 0..MAX;

FORMAT:

integer_type_definition ::= as in Ada, except that it must be static

The  Ada/SQL  automated  tools will recognize the  predefined  type  INTEGER.
Although implementation-specific type names, such as LONG_INTEGER and SHORT_-
INTEGER,  will  not  be recognized,  range constraints can be used to  define
types with the corresponding ranges.

The  range  of integers supported by a database management system may not  be
the same as that supported by the Ada system used to access that  DBMS.   The
package  DATABASE provides information about the DBMS being accessed by Ada/-
SQL.   In particular, the smallest (most negative) integer value supported by
the DBMS through Ada/SQL is the named number DATABASE.MIN_INT and the largest
(most positive) value is DATABASE.MAX_INT.   The type DATABASE.INT is defined
to  encompass  the maximum range of integers supported by  the  DBMS  through
Ada/SQL.

The  DATABASE package also includes the definition of a type  SMALLINT,  with
range  corresponding  to  that supported by the DBMS  type  SMALLINT  through
Ada/SQL.   The Ada/SQL automated tools will convert Ada integer data types to
the  corresponding  DBMS  types as follows:  (1) If the Ada type  or  subtype
declaration  explicitly references (following a chain of references)  INTEGER
or DATABASE.INT, then the SQL INTEGER type is used, (2) if the declaration of
the Ada type or subtype explicitly references SMALLINT, then the SQL SMALLINT
type  is used,  (3) if none of these types is referenced in the Ada  declara-
tions,  then the SQL SMALLINT type is used if the range of values is  compat-
ible with it, otherwise the SQL INTEGER type is used.

If the range of integers supported by the DBMS is smaller than that supported
by Ada,  then the Ada/SQL automated tools will issue warning diagnostics upon
encountering explicitly declared ranges that extend beyond the capability  of
the  DBMS.   The  exception  NUMERIC_ERROR is raised by the execution  of  an
Ada/SQL operation that would require the DBMS to handle an integer beyond its
range.

SQL does not support subtypes,  so database operations may be performed with-
out  range  checking.   (An implementation may perform range  checking  where
practical,  however,  raising  CONSTRAINT_ERROR on database  operations  that
would  violate subtype constraints.)  If range checking is not performed,  it
is possible for an Ada/SQL statement to cause one or more database columns to
contain values outside the ranges defined for those columns.   The  exception
CONSTRAINT_ERROR  will be raised,  however,  when it is attemped to  retrieve
such  values.   If  the value can be legally stored in the variable  used  to
retrieve it, then the value will be stored before CONSTRAINT_ERROR is raised.

4.7 Special Considerations - LRM section 3.5.6 - real type definition

FUNCTION:

Define the range of values and accuracy for real types

EXAMPLE:

  type COEFFICIENT is digits 10 range -1.0..1.0; -- a floating point type
  type VOLT is delta 0.125 range 0.0..255.0; -- a fixed point type
    -- taken from LRM sections 3.5.7 and 3.5.9

FORMAT:

real_type_definition ::= as in Ada, except that it must be static

The  range  and accuracy of real numbers supported by a  database  management
system may not be the same as that supported by the Ada system used to access
that DBMS.  If the range or accuracy of real numbers supported by the DBMS is
smaller  than  that supported by Ada,  then the Ada/SQL automated tools  will
issue warning diagnostics upon encountering explicitly declared  characteris-
tics that extend beyond the capability of the DBMS.   The exception NUMERIC_-
ERROR  is raised by the execution of an Ada/SQL operation that would  require
the DBMS to handle a real number beyond its range.   In general, no exception
is raised if accuracy is lost as a result of database operations.

The  underlying  DBMS  must support the model numbers (according to  the  Ada
definition) for types that are successfully processed by the automated tools,
as  well as safe numbers within the ranges of subtypes.   The DBMS  may  also
support a wider range of safe numbers.

The  comments in the previous section on range checking and CONSTRAINT_ERRORs
for INTEGERs are applicable to real numbers as well.

4.7 Special Considerations - LRM section 3.5.7 - floating point constraint

FUNCTION:

Define the range of values and accuracy for floating point types

EXAMPLE:

  type COEFFICIENT is digits 10 range -1.0..1.0; -- taken from LRM section
                                                 --  3.5.7

  type REAL is digits 8;
  type MASS is digits 7 range 0.0..1.0E35;

  subtype SHORT_COEFF is COEFFICIENT digits 5;
  subtype PROBABILITY is REAL range 0.0..1.0;

FORMAT:

floating_point_constraint ::= as in Ada, except that it must be static

The  Ada/SQL automated tools will recognize the predefined type  FLOAT.   Al-
though  implementation-specific type names,  such as LONG_FLOAT  and  SHORT_-
FLOAT,  are not recognized,  floating point constraints can be used to define
types with the corresponding characteristics.

The DATABASE package defines REAL and DOUBLE_PRECISION types, with ranges and
accuracies corresponding to those supported by the SQL REAL and DOUBLE PRECI-
SION types as available from the underlying DBMS through Ada/SQL.   The Ada/-
SQL  automated tools will convert Ada floating point types to the correspond-
ing DBMS types as follows:  (1) If the Ada type or subtype declaration expli-
citly references (following a chain of references) DOUBLE_PRECISION, then the
SQL DOUBLE PRECISION type is used,  (2) if the declaration of the Ada type or
subtype explicitly references REAL,  then the SQL REAL type is used,  (3)  if
neither DOUBLE_PRECISION nor REAL is referenced in the Ada declarations, then
a SQL FLOAT type with appropriate precision is used if the range and accuracy
of  values is compatible with it,  otherwise the SQL DOUBLE_PRECISION type is
used.   Note that the range and accuracy of the Ada FLOAT type may not corre-
spond to those achievable with the SQL FLOAT type.

The  maximum number of floating point digits that can be handled  by  Ada/SQL
through  the  underlying DBMS is given by the system dependent  named  number
DATABASE.MAX_DIGITS.

For  each floating point database type or subtype T,  T_NOT_NULL,  or T_NOT_-
NULL_UNIQUE  referenced  within a schema,  the SQL  function  generator  will
define named numbers T_SAFE_EMAX, T_SAFE_SMALL, and T_SAFE_LARGE, correspond-
ing to the similarly named attributes of T (or T_NOT_NULL, T_NOT_NULL_UNIQUE,
etc.).   The  attributes  of  T yield information on the range  of  exponents
supported  by the Ada implementation;  the corresponding named numbers  yield
similar information for the DBMS implementation.  The DBMS itself may support
a  wider  or  a  narrower  range,  which  will  be  accurately  reflected  in
T_SAFE_EMAX.   However,  T_SAFE_SMALL  and T_SAFE_LARGE will not  exceed  the
range of the Ada implementation.  As already noted, the DBMS will support all
model  numbers of a type that is successfully processed by the Ada/SQL  auto-
mated tools,  so the values returned by the DIGITS,  MANTISSA, EPSILON, EMAX,
SMALL, and LARGE attributes of T are applicable to the DBMS as well as to the
Ada implementation.  The SQL function generator will also produce the follow-
ing  definitions,  corresponding  to the machine-dependent attributes  of  T,
except with values applicable to the DBMS implementation:

     Type                Generated_Name           Corresponding_Attribute
     constant BOOLEAN    T_DATABASE_ROUNDS        T'MACHINE_ROUNDS
     constant BOOLEAN    T_DATABASE_OVERFLOWS     T'MACHINE_OVERFLOWS
     named number        T_DATABASE_RADIX         T'MACHINE_RADIX
     named number        T_DATABASE_MANTISSA      T'MACHINE_MANTISSA
     named number        T_DATABASE_EMAX          T'MACHINE_EMAX
     named number        T_DATABASE_EMIN          T'MACHINE_EMIN

4.7 Special Considerations - LRM section 3.5.9 - fixed point constraint

FUNCTION:

Define the range of values and accuracy for fixed point types

EXAMPLE:

  type VOLT is delta 0.125 range 0.0..255.0; -- taken from LRM section 3.5.9
  subtype ROUGH_VOLTAGE is VOLT delta 1.0;

  DEL : constant := 1.0/2**(WORD_LENGTH - 1);
  type FRACTION is delta DEL range -1.0..1.0 - DEL;

FORMAT:

fixed_point_constraint ::= as in Ada, except that it must be static

SQL  has no data type directly corresponding to Ada fixed point  types.   The
database  representation used for Ada fixed point values is system dependent,
depending  on the ranges and accuracies desired versus that supported by  the
various  database types,  and the efficiencies of processing  with  different
database  types.   The  database representation of any fixed point type  must
support  the model numbers of that type,  including the required accuracy  of
operations.   The largest possible number of binary digits in the mantissa of
fixed point model numbers that can be handled by Ada/SQL through the underly-
ing DBMS is given by the system dependent named number DATABASE.MAX_MANTISSA.
Likewise,  the  smallest  delta that can be supported in a fixed  point  con-
straint  that has the range constraint -1.0..1.0 is given by  DATABASE.FINE_-
DELTA.

For each fixed point database type or subtype T,  T_NOT_NULL, or T_NOT_NULL_-
UNIQUE,  referenced within a schema,  the SQL function generator will  define
named  numbers T_SAFE_SMALL and T_SAFE_LARGE,  corresponding to the similarly
named attributes of T (or T_NOT_NULL,  T_NOT_NULL_UNIQUE,  etc.).  The attri-
butes  of  T  yield information on the accuracy and range  used  by  the  Ada
implementation; the corresponding named numbers yield similar information for
the  DBMS  implementation.   The DBMS itself may support a greater or  lesser
accuracy and range (for the underlying base type;  it must adequately support
the  accuracy  and range of T),  but the named numbers will  not  exceed  the
accuracy or range of the Ada implementation.  The SQL function generator will
also  produce  the BOOLEAN constants T_DATABASE_ROUNDS  and  T_DATABASE_OVER-
FLOWS,  corresponding  to the attributes T'MACHINE_ROUNDS and T'MACHINE_OVER-
FLOWS, except with values applicable to the DBMS implementation.

4.7 Special Considerations - LRM section 3.6 - array type definition

FUNCTION:

Define array types

EXAMPLE:

  type VECTOR     is array(INTEGER range <>) of REAL; -- taken from LRM 3.6
  type MATRIX     is array(INTEGER range <>, INTEGER range <>) of REAL;
  type BIT_VECTOR is array(POSITIVE range <>) of BOOLEAN;
  type ROMAN      is array(POSITIVE range <>) of ROMAN_DIGIT;

  type TABLE    is array(1..10) of INTEGER;
  type SCHEDULE is array(DAY) of BOOLEAN;
  type LINE     is array(1..MAX_LINE_SIZE) of CHARACTER;

FORMAT:

array_type_definition ::= as in Ada,  except that all subtype indications and
     ranges used must either be static or depend on a discriminant.  Further-
     more,  the component subtype must be permitted as the type of a database
     column.

Two classes of arrays are supported by Ada/SQL:

(1)  Arrays  with  components of a character type (not  necessarily  the  Ada
CHARACTER  type)  that  includes only the ASCII characters  represented  with
their usual codes,  and with a single index of an integer type.   Such arrays
are  represented within the database as SQL strings,  and so  are  considered
scalar by Ada/SQL.  The Ada/SQL automated tools will recognize the predefined
types CHARACTER and STRING.

(2) All other arrays, which are composite objects in both Ada and Ada/SQL.

Ada/SQL  operations  available on string arrays correspond to the SQL  opera-
tions on strings.  Operations available on other arrays are the same as those
available on private types (see LRM section 3.3.1),  except that selection of
discriminants is replaced with indexing.   Slicing is also available on  non-
string arrays with a single index.  Indexing and slicing are not available on
string arrays, since SQL provides no substring capability.

The schema translator will determine the maximum index range of an array used
as  a database column for the purpose of allocating database storage as  fol-
lows:

(1)  For a constrained array type/subtype that does not depend on a discrimi-
nant, the bounds are given by the index constraint.

(2)  An  index constraint must be specified (by Ada semantics) for  a  record
component that is of an unconstrained array type.   If either bound does  not
depend on a discriminant,  then that value is used as the corresponding data-
base bound.   If the lower bound depends on a discriminant of type/subtype D,
then  the  database  lower bound is taken as the maximum of D'FIRST  and  the
lower  bound  of the index type/subtype.   If the upper bound  depends  on  a
discriminant of type/subtype D, then the database upper bound is taken as the
minimum of D'LAST and the upper bound of the index type/subtype.

(3) If a null range is determined from either (1) or (2) above,  as appropri-
ate,  then  the type/subtype of the column must permit null  values,  because
Ada/SQL will only permit nulls to be stored within such a column, which would
not be very useful.

Consideration must be given to the index ranges that will be used to allocate
database storage for arrays.   The Ada/SQL system will determine a mapping of
arrays  onto  the underlying database storage,  and larger index  ranges  may
require  greater database resources.   Excessively large index ranges may not
even be supportable by the underlying DBMS,  in which case the Ada/SQL  auto-
mated  tools  will issue diagnostics.   For example,  the components  in  the
following  declarations  could each contain as many as POSITIVE'LAST  charac-
ters:

  type PHONE_BOOK(NAME_LENGTH   : POSITIVE := 30;
                  NUMBER_LENGTH : POSITIVE := 12) is
    record
      NAME   : STRING(1..NAME_LENGTH);
      NUMBER : STRING(1..NUMBER_LENGTH);
    end record;

Instead,  the definitions should limit the ranges of the discriminants or the
possible bounds of the arrays.   The hybrid example below shows the discrimi-
nant  range limited for the NAME component and the array length  limited  for
the NUMBER component:

  subtype PHONE_NAME_LENGTH is POSITIVE range 1..30;
  subtype PHONE_NUMBER_LENGTH is POSITIVE range 1..12;

  type PHONE_NUMBER is array(PHONE_NUMBER_LENGTH range <>) of CHARACTER;

  type PHONE_BOOK
       (NAME_LENGTH   : PHONE_NAME_LENGTH := PHONE_NAME_LENGTH'LAST;
        NUMBER_LENGTH : POSITIVE := PHONE_NUMBER_LENGTH'LAST) is
    record
      NAME   : STRING(1..NAME_LENGTH);
      NUMBER : PHONE_NUMBER(1..NUMBER_LENGTH);
    end record;

4.7 Special Considerations - LRM section 3.7 - record types

FUNCTION:

Record  type declarations are used within schemas to declare database  tables
and  also to indicate groupings of fields into subrecords for convenience and
uniqueness constraints.

EXAMPLE:

  type DATE is                     -- taken from LRM section 3.7, not a
    record                         --  database table due to its later use
      DAY   : INTEGER range 1..31; --  as a component of another record type
      MONTH : MONTH_NAME;
      YEAR  : INTEGER range 0..4000;
    end record;

  type STOCK_TRANSACTION is         -- a database table that includes the
    record                          --  above subrecord
      TRADE_DATE  : DATE;           -- component types are assumed to be
      ACCOUNT     : ACCOUNT_NUMBER; --  defined appropriately
      COMPANY     : COMPANY_NAME;
      SHARES      : SHARE_COUNT;
      TRANSACTION : BOUGHT_OR_SOLD;
      PRICE       : STOCK_PRICE;
    end record;

FORMAT:

record_type_definition ::= as in Ada,  except that types/subtypes and expres-
     sions  must either be static or depend on a discriminant of the  record.
     Record components must be of types/subtypes that are legal for  database
     columns.

The declaration of a record type also declares a database table,  of the same
name as the record type, if:

(1) It occurs within a schema package, and

(2)  The  record  type name is not used as the type mark of  a  component  of
another  record declared within the same schema package.   For the purpose of
this determination, a subtype name differing only in the use of the _NOT_NULL
or _NOT_NULL_UNIQUE suffixes is considered to be the same name.

Each component of a record declaring a database table defines a column within
that table.   The column names are the same as the component names,  and  the
SQL  types  of the columns are as discussed with each class of type  declara-
tion.   Columns defined as record or array types are composite columns,  with
the underlying database columns being the non-composite subcomponents of  the
types.   Composite  columns may be given the constraints _NOT_NULL or  _NOT_-
NULL_UNIQUE  only if all subcomponents are constrained to prohibit null  val-
ues.   Within  the data manipulation language,  composite columns may be used
wherever  private  types may be used,  as discussed for  LRM  section  3.3.1,
except  that discriminant selection should be replaced with selection of  any
component for record columns and indexing for array columns.

There  is no way to indicate whether subcolumns not depending on a  discrimi-
nant are null when referencing composite columns, although the entire compos-
ite  column  may be specified as null by using an indicator  variable.   When
writing to the database or specifying values for comparison,  such subcolumns
are taken to be non-null unless the entire composite column is null.   A null
value denoted by an indicator variable causes all subcolumns, including those
which would otherwise be non-null based on discriminant values, to be consid-
ered null.   When reading from the database, the indicator variable is set to
indicate null if and only if all subcolumns are null.   If any subcolumns not
depending  on  a  discriminant are null in a composite  column  that  is  not
completely  null,  then the NULL_ERROR exception will be raised as if a  null
value  had  been retrieved without an indicator variable specified (see  com-
ments on dpANS section 6.6).   For program variables of a composite type used
to  retrieve composite columns,  component values not depending on  discrimi-
nants  are  left  undefined if the corresponding subcolumn  contains  a  null
value.  If the individual null status of subcolumns not depending on discrim-
inants is important, then all subcolumns should be referenced individually.

When adding rows to a table with INSERT_INTO statements,  it is not necessary
to  specify  values for all columns.   SQL uses null values  for  unspecified
columns,  but Ada/SQL uses the default expressions given for the record  com-
ponents  used  to define the table,  if such defaults are  provided.   Nested
levels  of subrecords may give rise to conflicting default  expressions;  the
default values used are those that would be used by Ada for an object of  the
record  type whose declaration also declared the database table to which rows
are  being added.   In short,  outer defaults take precedence over inner  de-
faults.   When inserting a new row into a table, null values are used for all
columns without explicit or default values.   It is an SQL error, returned in
the standard fashion of the data manipulation language,  to attempt to insert
a  null  value into a column not permitting null  values.   In  other  words,
INSERT_INTO  statements  must specify values for all non-null columns of  the
table  in question,  either by explicit reference or by  default  expressions
obtained from the declarations of the applicable record types.

4.7 Special Considerations - LRM section 3.7.1 - discriminants

FUNCTION:

As in Ada,  define subrecords containing variable-length arrays.  Also define
variant parts of records.

EXAMPLE:

  type SHIP_NAME_LENGTH is range 1..20;

  type SHIP_NAME_STRING is new STRING;

  type SHIP_NAME(LENGTH : SHIP_NAME_LENGTH := SHIP_NAME_LENGTH'LAST) is
    record
      NAME : SHIP_NAME_STRING(1..LENGTH);
    end record;

FORMAT:

discriminant_part  ::=  as in Ada,  except that all type  marks  and  default
     expressions used must either be static or depend on a discriminant

Null  values  are not permitted in discriminant columns,  regardless  of  the
type/subtype  name of the discriminant.   In keeping with Ada  philosophy,  a
database  discriminant  value may be modified only by  updating  all  columns
defined  by the record type containing the discriminant.   Discriminants  may
also be used to choose variant parts within records.  When updating discrimi-
nant  values,  values need not and may not be specified for variant parts not
chosen by the discriminant values.

4.7 Special Considerations - LRM section 8.5 - renaming declaration

FUNCTION:

Provide alternate names for entities.

EXAMPLE:

  MAXLEN : INTEGER renames SHIP_NAME_MAXIMUM_LENGTH; -- renaming an object
  package SHIPS renames SHIP_DATA_DEFINITION_PACKAGE; -- renaming a package

FORMAT:

renaming_declaration ::= as in Ada,  except that only constants and  packages
     may be renamed within schema packages

Renaming  declarations  permitted  within schema packages are  restricted  to
those that rename entities that may be declared or referenced within schemas.
Hence, only constants and packages may be renamed.

4.7 Special Considerations - LRM section 13.1 - representation clause

FUNCTION:

Within schemas, specify how enumeration types are to be represented.

EXAMPLE:

  type CLASSIFICATION is (UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET);

  for CLASSIFICATION use (1,2,4,8); -- an enumeration representation clause

FORMAT:

representation_clause ::= as in Ada

All types of representation clauses may be used within schemas, as they apply
to the types and objects that may be declared.   The Ada/SQL automated  tools
will  ignore all representation clauses other than enumeration representation
clauses, however.  Enumeration representation clauses will, if possible, have
the effect of changing the database representation for enumeration types.

5.1 - 5.3 Module Language

There  are  no corresponding sections within the Ada/SQL  standard.   Ada/SQL
uses  an embedded language,  and therefore does not require the  module  lan-
guage.

6.1 <close statement>

FUNCTION:

Close a cursor.

EXAMPLE:

  CURSOR : CURSOR_NAME;
  . . .
  CLOSE(CURSOR);

FORMAT:

<close statement> ::=
     CLOSE ( <cursor name> ) ;

The <close statement> is an Ada procedure.

<cursor name> ::= a program variable of type CURSOR_NAME,  which is a private
     type defined by the implementation

6.2 <commit statement>

FUNCTION:

Terminate the current transaction with commit.

EXAMPLE:

  COMMIT_WORK;

FORMAT:

<commit statement> ::=
     COMMIT_WORK ;

The <commit statement> is an Ada procedure.

6.3 <declare cursor>

FUNCTION:

Define a cursor.

EXAMPLE:

  CURSOR : CURSOR_NAME;

  package E is new ANALYST_CORRELATION_NAME; -- employees \ see section 3.20
  package M is new ANALYST_CORRELATION_NAME; -- managers  /
  . . .

  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC     ( NAME & SALARY & MANAGER,
    FROM     => ANALYST ),
    ORDER_BY => MANAGER & DESC(SALARY) );

    -- variations: ORDER_BY => 3 & DESC(2)
    --             ORDER_BY => ASC(3) & DESC(SALARY), etc.

  DECLAR ( CURSOR , CURSOR_FOR =>
        SELEC  ( NAME & SALARY & MANAGER,
        FROM  => ANALYST,
        WHERE => SALARY > 25_000.00 )
    & UNION (
        SELEC  ( E.NAME & E.SALARY & E.MANAGER,
        FROM  => E.ANALYST & M.ANALYST, -- see section 3.20
        WHERE => EQ ( E.MANAGER , M.NAME )
        AND      E.SALARY > M.SALARY ) ) );

      -- variations: UNION_ALL

FORMAT:

<declare cursor> ::=
     DECLAR ( <cursor name> , CURSOR_FOR =>
       <cursor specification> ) ;

The  <declare  cursor>  statement is an Ada procedure named DECLAR  (the  SQL
keyword DECLARE is an Ada reserved word).   Its first parameter is the cursor
to be declared.   Its second parameter is named CURSOR_FOR to retain the  SQL
keyword,  and  is  a  specification of the retrieval to be performed  by  the
cursor.  The third parameter (discussed below as part of the <cursor specifi-
cation>) is named ORDER_BY to handle the <order by clause>.

<cursor name> ::= see section 6.1

<cursor specification> ::=
     <query expression> [ ,
     <order by clause> ]

The  <order  by  clause> is optional.   Since it is the  third  parameter  to
DECLAR, a comma must separate it from the <query expression>.

<query expression> ::=
       <query term>
      <query expression> & { UNION | UNION_ALL } ( <query term> )
      <query expression> & { UNION | UNION_ALL }   <query term>

Since  UNION and UNION_ALL cannot be made infix operators,  the ampersand  is
used to connect the two items being UNIONed.   UNION and UNION_ALL are  func-
tions  on <query term>s that are used to keep the SQL keywords in the  opera-
tion and that return an indication of whether or not the ALL option was used.
Parentheses  are required around UNION and UNION_ALL's parameter by Ada  syn-
tax;  they  are shown as optional here because they may be supplied from  the
next production, which is used within SQL to show precedence of UNIONs.

<query term> ::=
     <query specification>  ( <query expression> )

<query specification> ::= see section 3.25.

<order by clause> ::=
     ORDER_BY => <sort specification> [ { & <sort specification> } ... ]

As noted above,  the third parameter to DECLAR is named ORDER_BY.   The <sort
specification>s cannot be joined by commas in Ada; so ampersands are used.

<sort specification> ::=
              <sort column specification>
      ASC  ( <sort column specification> )
      DESC ( <sort column specification> )

Ascending (default) and descending sorts cannot be indicated by appending the
ASC  or DESC keyword to the column indicator;  ASC and DESC are instead  made
Ada functions.

<sort column specification> ::=
     <column number>  <column specification>

<column number> ::= a positive integer of type COLUMN_NUMBER

Ada's typing is used to define a <column number>.

<column specification> ::= see section 3.7

6.4 <delete statement: positioned>

FUNCTION:

Delete a row of a table based on the current position of a cursor.

EXAMPLE:

  CURSOR : CURSOR_NAME;
  . . .
  DELETE_FROM ( ANALYST,
  WHERE_CURRENT_OF => CURSOR );

FORMAT:

<delete statement: positioned> ::=
     DELETE_FROM ( <table name> ,
     WHERE_CURRENT_OF => <cursor name> ) ;

The <delete statement: positioned> is an Ada procedure.

<table name> ::= see section 3.20

<cursor name> ::= see section 6.1

6.5 <delete statement: searched>

FUNCTION:

Delete rows of a table based on a search criterion.

EXAMPLE:

  DELETE_FROM ( ANALYST,
  WHERE      => SALARY > 25_000.00 );

  DELETE_FROM ( ANALYST );

FORMAT:

<delete statement: searched> ::=
     DELETE_FROM ( <table name> [ ,
     WHERE      => <search condition> ] ) ;

The  <delete  statement:  searched> is an Ada procedure.   The WHERE  keyword
names the second parameter.  The WHERE parameter may be omitted.

<table name> ::= see section 3.20

<search condition> ::= see section 3.18

6.6 <fetch statement>

FUNCTION:

Position a cursor on the next row of a table and assign values in that row to
program variables.

EXAMPLE:

  CURRENT_EMPLOYEE : ANALYST_NAME;
  HIS_SALARY       : ANALYST_SALARY;
  HIS_MANAGER      : MANAGER_NAME;
  CURSOR           : CURSOR_NAME;
  LAST             : NATURAL;
  IND_VAR          : INDICATOR_VARIABLE;
  . . .
  DECLAR ( CURSOR , CURSOR_FOR =>
    SELEC ( NAME & SALARY & MANAGER,
    FROM => ANALYST ) );
  FETCH ( CURSOR );
  INTO ( CURRENT_EMPLOYEE , LAST );
  INTO ( HIS_SALARY , IND_VAR );         -- variation: INTO ( HIS_SALARY );
  INTO ( HIS_MANAGER, LAST, IND_VAR );

FORMAT:

<fetch statement> ::=
     FETCH ( <cursor name> ) ;
     INTO ( <result specification> [ , <cursor name> ] ) ;
 [ { INTO ( <result specification> [ , <cursor name> ] ) ; } ... ]

It  is  not  possible to string the result variables together  as  with  SQL.
Consequently,  a FETCH procedure call is followed by as many calls to INTO as
are  required  to retrieve the values of each column in the row.   Each  INTO
returns one column value.   The NOT_FOUND_ERROR exception will be raised if a
FETCH is performed on a cursor for which all rows (if any) have already  been
returned.   If  several tasks within the same program are simultaneously per-
forming  database  retrievals,  the <cursor name> used in the FETCH  must  be
specified  as  the final parameter to INTO procedures  for  that  FETCH.   If
simultaneous  database retrievals are not being performed,  the <cursor name>
parameter may be omitted from the INTO calls.

<cursor name> ::= see section 6.1

<result specification> ::=
    <result program variable>
      [ , <last variable> ] [ , <indicator variable> ]

<result  program  variable> ::= program variable to obtain column value  from
     database,  which must be of a type comparable with that of the  database
     column  being  retrieved.   Program variables within <result  specifica-
     tion>s may also be expressed as type conversions,  as would be legal for
     any Ada out actual parameter.

<last variable>  ::= program variable to obtain the value of the  last  index
     position  used  in  retrieving array values.   Used when and  only  when
     <result program variable> is of type array.  For one dimensional arrays,
     <last variable> is of the same type as the array index.   For arrays  of
     higher  dimensionality,  <last  variable>  is a record  with  components
     corresponding to each array index type.   The record type, named A_LAST,
     where A, A_NOT_NULL, or A_NOT_NULL_UNIQUE is the name of the array type,
     is  defined by the SQL function generator for all schema  packages  con-
     taining a database column or subcolumn of the array type.  Components of
     the record are named LAST_1, LAST_2, etc.

<indicator  variable> ::= optional program variable of  type  INDICATOR_VARI-
     ABLE, set to NULL_VALUE if the database column retrieved contains a null
     value,  else  set  to NOT_NULL.   If a null value is retrieved from  the
     database but no <indicator variable> is specified, the NULL_ERROR excep-
     tion will be raised.

6.7 <insert statement>

FUNCTION:

Create new rows in a table.

EXAMPLE:

  NEW_EMPLOYEE : ANALYST_NAME;
  HIS_SALARY   : ANALYST_SALARY;
  HIS_MANAGER  : MANAGER_NAME;
  . . .
  INSERT_INTO ( ANALYST ( EMPLOYEE & SALARY & MANAGER ) ,
    VALUES <= NEW_EMPLOYEE and HIS_SALARY and HIS_MANAGER );

  INSERT_INTO ( ANALYST ,
    SELEC ( '*',
    FROM => NEW_ANALYST_FILE ) );

  -- assume NEW_ANALYST_FILE is another database table structured identically
  --   to the ANALYST table

FORMAT:

<insert statement> ::=
     INSERT_INTO ( <table name> [ ( <insert column list> ) ] ,
   { VALUES <= <insert value list> }  <query specification> ) ;              |

The  INSERT  INTO statement is a function with  two  parameters.   The  first
parameter  indicates the table and (optionally) columns to be  affected.   If
the <insert column list> is specified,  then the <table name> is expressed as
a  function with one parameter (the <insert column list>).   The  parentheses
around the Ada function parameter exactly match the SQL parentheses.   If the
<insert  column list> is not specified,  then the <table name> is a  function
with  no  parameters.   A  comma separates the first and second  argument  to
INSERT_INTO.  The second argument can be either an explicit list of values or
a <query specification>.   For the explicit list of values,  the SQL  keyword
VALUES  is  followed  by an Ada/SQL "gets" operator (<=),  then the  list  of
values.   The SQL parenthesis notation is not used.   A <query specification>
is indicated by a call to the SELEC function (see section 3.25).

<table  name> ::= see section 3.20.   If an <insert column list> is used  and
     the <table name> includes an <authorization identifier>, then the syntax
     for  the <table name> is <authorization identifier>-<table  identifier>.
     This  is  one  of the three contexts within Ada/SQL where  <table  name>
     syntax is not the usual <authorization identifier>.<table identifier>.

<insert column list> ::=
     <column name> [ { & <column name> } ... ]

SQL  uses commas to separate the column names,  Ada/SQL uses  ampersands  in-
stead.

<column name> ::= an unqualified column name

<insert value list> ::=
     <insert value> [ { and <insert value> } ... ]

SQL  uses  commas to separate the insert values,  Ada/SQL uses an  overloaded
"and" operator.

<insert value> ::=
     <value specification>  NULL_VALUE

SQL uses NULL, which is an Ada reserved word.

<value specification> ::= see section 3.6

<query specification> ::= see section 3.25

6.8 <open statement>

FUNCTION:

Open a cursor.

EXAMPLE:

  CURSOR : CURSOR_NAME;
  . . .
  OPEN(CURSOR);

FORMAT:

<open statement> ::=
     OPEN ( <cursor name> ) ;

The <open statement> is an Ada procedure.

<cursor name> ::= a program variable of type CURSOR_NAME

Note  that SQL evaluates program variables used to declare a cursor when  the
cursor is opened.  In Ada/SQL, these program variables are evaluated when the
cursor is declared.

6.9 <rollback statement>

FUNCTION:

Terminate the current transaction with rollback.

EXAMPLE:

  ROLLBACK_WORK;

FORMAT:

<rollback statement> ::=
     ROLLBACK_WORK ;

The <rollback statement> is an Ada procedure.

6.10 <select statement>

FUNCTION:

Specify  a  table  and assign the values in the single row of that  table  to
program variables.

EXAMPLE:

  DESIRED_EMPLOYEE : ANALYST_NAME;
  HIS_SALARY       : ANALYST_SALARY;
  HIS_MANAGER      : MANAGER_NAME;
  LAST             : NATURAL;
  . . .
  SELEC  ( SALARY & MANAGER ,           -- variations: SELECT_ALL,
  FROM  => ANALYST,                     --             SELECT_DISTINCT
  WHERE => EQ(NAME,DESIRED_EMPLOYEE) );
  INTO(HIS_SALARY);
  INTO(HIS_MANAGER,LAST);

FORMAT:

<select statement> ::=
   [ SELEC  SELECT_ALL | SELECT_DISTINCT ] ( <select list> ,
     <table expression> ) ;
     INTO ( <result specification> ) ;
 [ { INTO ( <result specification> ) ; } ... ]

The SELECT INTO statement is an Ada procedure.  It is not possible to specify
the  ALL or DISTINCT keywords separately,  so they are part of the  procedure
name if used.  The name of the procedure is SELEC if neither keyword is used,
since SELECT is an Ada reserved word.   The SELECT INTO procedures have three
parameters which must,  of course, be surrounded by parentheses and separated
by  commas.   The first is the <select list>,  as described in section  3.25.
The  second  and  third parameters are the FROM and WHERE  clauses  from  the
<table expression>, and so are named FROM and WHERE, respectively.  (SQL does
not  permit GROUP BY and HAVING clauses in <select statement>s.   <table  ex-
pression>s  are  discussed in section 3.19;  when used within <select  state-
ment>s the optional <group by clause> and <having clause> must be omitted.)

The INTO keyword cannot be embedded within the SELECT INTO statement in  Ada,
nor  can result variables be listed together,  separated by  commas.   Conse-
quently, one INTO call for each column retrieved is made following the SELECT
INTO  statement,  with the exact same format and meaning as described in sec-
tion  6.6  for the FETCH statement,  except that a <cursor name> may  not  be
specified.   Consequently,  tasks within a program must not perform more than
one  simultaneous <select statement>.   If multiple retrievals must  be  per-
formed  simultaneously,  FETCH  statements  must be used to  avoid  erroneous
results.   The  NOT_FOUND_ERROR exception will be raised if the  SELECT  INTO
statement retrieved no rows,  and UNIQUE_ERROR will be raised if it retrieved
more than one.  The values returned by the INTO statements are undefined when
called directly following errors.

<select list> ::= see section 3.25

<table expression> ::= see section 3.19

<result specification> ::= see section 6.6

6.11 <update statement: positioned>

FUNCTION:

Modify a row of a table based on a cursor's current position.

EXAMPLE:

  CURSOR : CURSOR_NAME;
  . . .
  UPDATE ( ANALYST ,
  SET   => SALARY  <= 2.0*SALARY
       and MANAGER <= NULL_VALUE ,
  WHERE_CURRENT_OF => CURSOR );

FORMAT:

<update statement: positioned> ::=
     UPDATE ( <table name> ,
     SET   => <set clause> [ { and <set clause> } ... ] ,
     WHERE_CURRENT_OF => <cursor name> ) ;

The  Ada UPDATE procedure has three parameters:  the name of the table to  be
updated,  a  list  of columns and values to be set,  and the cursor  used  to
determine  the  current row.   Named associations on the last two  parameters
serve  to get the SQL keywords into the Ada program.   The <set clause>s  are
separated by "and"s in Ada/SQL, instead of commas as in SQL.

<table name> ::= see section 3.20

<set clause> ::=
     <object column> <= { <value expression>  NULL_VALUE }                   |

<object column> ::= <column name>

<column name> ::= an unqualified column name

<value expression> ::= see section 3.9

The  = operator cannot be overloaded for use in a <set  clause>,  so  Ada/SQL
uses <= instead, to be indicative of the direction of the assignment.  NULL_-
VALUE is used instead of NULL, which is an Ada reserved word.

<cursor name> ::= see section 6.1

6.12 <update statement: searched>

FUNCTION:

Update rows of a table based on a search condition.

EXAMPLE:

  GENEROUS_BOSS : MANAGER_NAME;
  . . .
  UPDATE ( ANALYST ,
  SET   => SALARY <= 1.2*SALARY ,
  WHERE => EQ(MANAGER,GENEROUS_BOSS) );

  UPDATE ( ANALYST,
  SET   => SALARY <= 1.05*SALARY ); -- cost of living raise

FORMAT:

<update statement: searched> ::=
     UPDATE ( <table name> ,
     SET   => <set clause> [ { and <set clause> } ... ] [ ,
     WHERE => <search condition> ] ) ;

This  version of the Ada UPDATE procedure has three parameters:  the name  of
the  table  to be updated,  a list of columns and values to be set,  and  the
search condition used to determine which rows are to be updated.   The search
condition is optional.   Named associations on the last two parameters  serve
to get the SQL keywords into the Ada program.  The <set clause>s are separat-
ed by "and"s instead of by commas as in SQL.

<table name> ::= see section 3.20

<set clause> ::= see section 6.11

<search condition> ::= see section 3.18

Appendix A. <embedded SQL host program>

The definition is extended to include

     <embedded SQL host program> ::= <embedded SQL Ada program>

An  <embedded  SQL  Ada program> consists of an Ada  program  which  includes
Ada/SQL  data  manipulation statements as defined in  Section  6.   No  other
special embedded notation (such as EXEC SQL, etc., used with other languages)
is  required,  since  an <embedded SQL Ada program> conforms to  precise  Ada
syntax  and  may be directly processed by the Ada compiler rather than  being
precompiled.  This also means that program variables are used directly within
Ada/SQL statements, without the leading colon:

     <embedded variable name> ::= <host identifier>

Program  variables may be of user-defined data types as discussed in  section
2.2.   Operations  on database and program values must be between  comparable
data types, as defined in section 3.9.

Appendix B. <embedded exception declaration>

Error conditions in Ada/SQL always raise exceptions,  that are then processed
in  the  normal Ada manner.   Exceptions may not be  "turned  off",  nor  may
program  control  be  transferred in any manner other than the  standard  Ada
exception handlers.