FIPS 193 - Section 10
10. Procurement Considerations

This FIPS for SQL Environments may be used to assist in the procurement of any of the following types of products:

This first specification is particularly oriented toward implementation profiles for SQL/ERI Servers, but may be of limited assistance in procurements for each of the other two types of products. The assumptions on each of these product types in an SQL Environment are given in Section 1.2, "SQL environment", Section 2, "Data Integration Architecture", and Section 3, "SQL External Repository Interface (SQL/ERI)". This specification cannot be used as the sole procurement instrument for any one of these product types. Instead, to be effective, it must be supplemented by other requirements and/or complementary schema information as indicated in other parts of this specification. The following subsections offer advice on how best to use this specification when procuring a product to be integrated into an SQL environment from any one of these product types.

10.1 Client-side products

A client-side product in an SQL environment is a product that uses the SQL language to access persistent data on behalf of some end user. The product could be a graphical user interface (GUI) or some other presentation tool interfacing with a human end user, or it could be a value-added, computer-aided software engineering (CASE) productivity tool that is accessed from some other end user tool. The following steps may be helpful:

1. State the functional requirements of the tool itself. This could vary considerably and is beyond the scope of the FIPS PUB for SQL Environments.

2. Case:

a. If the tool interacts directly with a human end user, then state the requirements of the human to computer interface. This interface may depend upon "Human/Computer Interface Services" as discussed in Sections 3.3.2 and 4.8 of the NIST Application Portability Profile (APP) for Open Systems Environments (see [22]).

b. If the tool provides a services interface to other software tools, then state the calling requirements and data types that must pass across this interface. This interface may depend upon the Common Object Request Broker Architecture (CORBA) published by OMG and X/Open, or upon emerging international standards for language independent procedure calling mechanisms.

3. Choose an SQL binding style to be used between the client-side tool and the SQL data repository. See Section 6, "SQL Binding Alternatives", for discussion of the available binding styles. It is expected that the SQL/CLI binding style will be the most popular choice for client-side products within a single local client/server environment and that the Direct Invocation or RDA/SQL binding styles will be the most popular choices when the client-side tool is accessing server data in a remote data repository.

4. Identify all of the SQL data types, and all of the SQL Abstract Data Type (ADT) instances, that may need to be imported into the application tool. Make sure that the functional requirements of the tool include the manipulation and presentation of these application-specific objects.

5. If the client-side tool is going to create and manage its own public persistent data, and thereby be an SQL/ERI Server for other products in the SQL Environment, then follow the steps in Section 10.3 below for procurement of an SQL/ERI Server.

10.2 SQL/ERI Clients

An SQL/ERI Client is a full-function, conforming FIPS SQL data manager that, in addition, supports the SQL/ERI interface described in Section 3. The functional requirements of the client side of this interface must be supplied by an individual procurement since they are beyond the scope of this first specification for SQL/ERI profiles. The following steps may be helpful:

1. If a full-function, conforming FIPS SQL data manager is not already available, then follow the Special Procurement Considerations given in Section 16 of FIPS PUB 127-2 [3] for procurement of an SQL Processor.

2. State the minimum profile of the SQL/ERI Server products that are to be integrated into the SQL Environment by this SQL/ERI Client. Use the profile items identified in Section 7 to determine this minimum profile.

3. Make sure that the SQL Processor supports all of the binding styles identified in the minimum profile for SQL/ERI Servers to be accessed, since a conforming FIPS SQL Processor need only support one such binding style. In particular, if the SQL/CLI or RDA binding styles are specified, make sure that the SQL Processor supports Connection Management statements (a Full SQL feature) and can map those statements to appropriate SQL/CLI service calls or appropriate RDA/SQL-Client protocols.

4. State the functional requirements for "schema federation", that is, the requirements for how the SQL processor is to make the SQL Schemas from an SQL/ERI Server visible as schema elements in some Catalog of the SQL Processor. The end user, be it human or software, should not be expected to have to do its own schema federation; a database administrator should be able to integrate the external schemas from the SQL/ERI Servers and make them appear as if they were part of the local SQL data. Most SQL implementations have the ability to do this, but it is not yet part of the de jure SQL standard, so the procuring authority cannot yet point to this capability in a formal standard and require conformance. This topic will be addressed further in profile specifications for SQL/ERI Clients, a follow-on objective of the FIPS for SQL Environments.

5. Make sure that the SQL Processor can translate full-function SQL DML statements into a module of lower level SQL DML statements (e.g. Minimal DML) that have the same effect. In order to do this, it may be necessary for the SQL Processor to build temporary tables, populate the temporary tables from data retrieved from external SQL/ERI Servers, and then further manipulate the data in the temporary tables before returning the correct result to the end user. For a further discussion of this point see Section 3, which discusses the assumed capabilities of an SQL/ERI Client. This topic will be addressed further in profile specifications for SQL/ERI Clients, a follow-on objective of the FIPS for SQL Environments.

6. If the profile for SQL/ERI Server products to be supported requires SQL/PSM, SQL/MM, ADTs and methods, or Object data management, then make sure that the SQL Processor is able to invoke SQL functions and ADT methods that are defined by an external server.

10.3 SQL/ERI Servers

An SQL/ERI Server is a server-side product in an SQL environment that controls the data that is to be made available to client-side tools. An SQL/ERI Server may be a legacy database, a specialized data manager such as a Geographic Information System or a Full-Text document management system, or an object database management system. With even partial support of the SQL language, such products are able to provide a degree of integration between themselves and other products in the SQL environment. The following steps may be helpful in the procurement of an SQL/ERI Server:

1. Determine if the SQL/ERI Server is to be a Read-Only Server or a Read-Write Server. A read-only server will have a much easier time meeting the conformance requirements specified in Section 7. Failure to specify either Read-Only or Read-Write means that, by default, the SQL/ERI Server is to be a Read-Only Server.

2. Identify any SQL schema definitions that the server shall support. See the discussions in Section 8 for examples of the kinds of schema definitions that might be specified. A procurement may require that a specific schema definition be supported, or alternatively, it may simply require that a proposal in response to a procurement request include an SQL schema for the data that is to be made available. Implicitly, the schema definition determines whether or not a conforming implemenation shall support SQL null values (see item 4 of Section 4.1). Failure to identify any SQL schema definitions to be supported means that, by default, the supported SQL schema definitions are implementation-defined.

3. Specify a base level of SQL data manipulation language (DML) that shall be supported, by choosing exactly one of the following DML alternatives: Minimal DML, Entry DML, Transitional DML, Intermediate DML, or Full DML. See the discussion of each of these alternatives in Section 4 and the "Data Manipulation Rules" in Section 7.1 (Read-Only) or Section 7.2 (Read-Write). Failure to choose a base level of SQL data manipulation language means that, by default, the base level of SQL data manipulation language is Minimal DML.

4. Specify a base level of SQL schema definition language (SDL) that shall be supported, by choosing exactly one of the following SDL alternatives: No SDL, Minimal SDL, Entry SDL, Transitional SDL, Intermediate SDL, or Full SDL. See the discussion of each of these alternatives in Section 4 and the "Schema Definition Rules" in Section 7.1 (Read-Only) or Section 7.2 (Read-Write). Failure to choose a base level of SQL schema definition language means that, by default, the base level of SQL schema definition language is No SDL.

5. Specify a base level of SQL transaction management that shall be supported, by choosing exactly one of the following transaction management alternatives: No Transactions, Commit-Rollback, Transaction Mode, Transaction Isolation, Transaction Diagnostics, or Constraints. See the discussion of each of these alternatives in Section 7 and the "Transaction Management Rules" in Section 7.1 (Read-Only) or Section 7.2 (Read-Write). Failure to choose a base level of SQL transaction management means that, by default, the base level of SQL transaction management is Commit-Rollback.

6. Specify a default isolation level for SQL transaction management that shall be supported, by choosing exactly one of the following default isolation level alternatives: Read Uncommitted, Read Committed, Repeatable Read, or Serializable. See the discussion of each of these alternatives in Section 7 and the "Transaction Management Rules" in Section 7.1 (Read-Only) or Section 7.2 (Read-Write). Failure to choose a default isolation level means that, by default, the default isolation level is Read Committed.

7. Specify the binding styles that shall be supported, by choosing one or more of the following binding style alternatives: Module, Embedded SQL, Direct Invocation, SQL/CLI, or RDA/SQL. See the discussion of each of these alternatives in Section 6 and the effect of each alternative in the rules in Section 7.1 (Read-Only) or Section 7.2 (Read-Write). It is expected that the SQL/CLI binding style will be the most popular choice for SQL/ERI products within a single local client/server environment and that the Direct Invocation or RDA/SQL binding styles will be the most popular when the server data repository is an isolated node in a wide area client/server environment. Failure to choose a binding style means that, by default, an implementation may choose to support either the SQL/CLI binding style (see Section 6.4) or the SQL/RDA binding style (see Section 6.5).

8. For each of the Module, Embedded SQL, or SQL/CLI binding styles chosen above, specify the programming language interface that shall be supported, by choosing one or more of the following programming language alternatives: Ada, C, COBOL, Fortran, MUMPS, Pascal, PL/I, or SAMeDL. Failure to choose a programming language interface means that, by default, the interface for Programming Language C is the only requirement.

9. Specify which SQL Features beyond those required above are to be supported, by choosing "No Extensions" or by identifying features by feature number from FIPS PUB 127-2 (see Section 14 of [3]). See the discussion of SQL Features in Section 5.1. Identify which features are "required" and which are "desirable". Be very careful about requiring individual features (rather than a FIPS specified level of features) as that practice can easily lead to procurement protests. Be sure to declare how desirable features will be scored in the evaluation of responses to the procurement. Note that a Read-Only interface need only support the Read-Only aspects of each feature. Determine if it is a procurement requirement for the implementation to support the SQL_FEATURES table as specified in Section 15 of FIPS PUB 127-2 (required for Intermediate DML and above and also required if the "SQL Features" option is selected in the implementation profile declaration). Failure to specify any additional SQL Features to be supported means that none are required.

10. Specify whether or not the SQL/PSM optional extension shall be supported; if SQL/PSM support is required, then the implementation shall support the Executable SQL/PSM or the Definable SQL/PSM requirements of the SQL/PSM specification. See Section 5.2 and item (8) of Section 7 above for a discussion of SQL/PSM. Note that a Read-Only interface need only support the Read-Only aspects of SQL/PSM. If SQL/PSM is required and if the SQL/ERI Server is a Read-Only server, then specify exactly which functions and abstract data types (ADTs) are to be invokable by supplying the appropriate SQL3 schema definitions for the required functions, modules, and procedures. Failure to specify a requirement for SQL/PSM means that no support for any aspects of SQL/PSM is required.

11. Specify which, if any, conformance alternatives from SQL/MM shall be supported; if SQL/MM support is required, then point to the then current SQL/MM specification (see [13]) and explicitly indicate which Parts, and which conformance alternatives within each Part, are required. See Section 5.3 and item (8) of Section 7 above for a discussion of SQL/MM. Also see the identifiers for various features of SQL/MM in Section 7.3. Note that a Read-Only interface need only support the Read-Only aspects of SQL/MM. To be successful, a Read-Only procurement should include the desired SQL/MM features in the SQL schemas produced in item 2 above. Failure to specify a requirement for any of the SQL/MM Parts, or conformance alternatives within each Part, means that none are required. Keep in mind that at the time of publication of this FIPS for SQL Environments, the SQL/MM specification was very immature; it may change considerably before final adoption of any of its parts as International Standards.

12. Specify which SQL3 features dealing with abstract data types (ADTs), methods, and object data management are to be supported; if any of these SQL3 facilities are to be supported, then point to the appropriate ADT or object management clauses in the then current SQL3 specification (see Sections 5.4 and 5.5 above and [12]) and explicitly indicate which features are required. Note that a Read-Only interface need only support the Read-Only aspects of any indicated SQL3 features. To be successful, a Read-Only procurement should include the desired SQL3 features in the SQL schemas produced in item 2 above. Failure to specify a requirement for any of these SQL3 features means that none are required.

13. Specify whether or not the SQL/ERI Server shall support encompassing transactions or the emerging standard for SQL/XA (see Section 5.6 above and [12]). Note that it may or may not make any sense to require that a Read-Only SQL/ERI Server participate in read-write transactions managed by a global transaction manager. Failure to explicitly specify a requirement for SQL/XA in a procurement means that support for SQL/XA is not required.

14. Specify the minimum requirements for the precision, size, or number of occurrences of any required SQL data types or features. See the discussion of sizing in Section 5.1. Unless otherwise specified in a procurement, the Entry Value sizing limits from Section 16.6 of FIPS PUB 127-2 apply to all Entry SQL or Transitional SQL features and the Intermediate Value sizing limits apply to all Intermediate SQL or Full SQL features. A procurement is responsible for identifying its own sizing limits on all required features, but in the absence of an explicit declaration, the default minimum limits apply for that procurement. Determine if it is a procurement requirement for the implementation to support the SQL_SIZING table as specified in Section 15 of FIPS PUB 127-2 (required for Intermediate DML and above).

15. Specify the minimum requirements for character set support. See the discussion of character sets in Section 16.7 of FIPS PUB 127-2. Failure to indicate explicit character set requirements for an SQL/ERI Server means that support for the representation of the 95-character graphic subset of ASCII (FIPS PUB 1-2), in an implementation defined collating sequence, is by default the minimum requirement for Minimal, Entry, and Transitional profiles. Profiles that require Intermediate DML or above must support the Intermediate SQL character set requirements.

16. Specify any SQL/ERI Server performance requirements. This standard is silent on the topic of performance. The NIST SQL test suite also makes no attempt to test the performance aspects of a conforming system. Whenever performance requirements are known in advance, they may be included as an integral part of the procurement specification.

17. Specify any SQL/ERI Server security requirements. Some environments require "trusted" database access beyond the GRANT and REVOKE privileges and the view definition capabilities specified by the SQL'92 standard. Procurements for systems that operate in these environments should include explicit additional requirements to be supported. For additional information, refer to Trusted Database Management System Criteria (NCSC-TG-021 Version 1), National Computer Security Center, April 1991, and Security Issues in Database Language SQL, NIST Special Publication 800-8, NIST, August 1993.

18. Read Sections 16.8, "DBMS procurement", and 16.11, "System integration", in FIPS PUB 127-2 to see if any of the discussions therein apply to this procurement for an SQL/ERI Server. Section 16.8 lists a number of emerging SQL3 features (see [12]) that might be listed as "desirable" features in an SQL/ERI Server procurement. Remember that a Read-Only interface need only support the Read-Only aspects of any specified features.
Return to FIPS 193