This standard is applicable in any situation where it is desirable to integrate a client-side productivity tool or a server-side data repository into an SQL environment. It is a non-mandatory standard that may be invoked on a case-by-case basis subject to the integration objectives of the procuring department or agency. It is particularly suitable for specifying limited SQL interfaces to legacy databases or to specialized data repositories not under the control of a full-function SQL database management system. It can be used along with other procurement information to specify SQL interface requirements for a wide range of data management procurements.

One special area of application envisioned for this standard is Electronic Commerce, a National Challenge Application area of the National Information Infrastructure. The primary objective of Electronic Commerce is to integrate communications, data management, and security services in a distributed processing environment, thereby allowing business applications within different organizations to interoperate and exchange information without human intervention. At the data management level, electronic commerce requires a logically integrated database of diverse data stored in geographically separated data banks under the management and control of heterogeneous database management systems. An over-riding requirement is that these diverse data managers be able to communicate with one another and provide shared access to data and data operations and methods under appropriate security, integrity, and access control mechanisms. FIPS SQL provides a powerful database language for data definition, data manipulation, and integrity management to satisfy many of these requirements. It is unrealistic to expect that every data manager involved in electronic commerce will conform to even the Entry SQL level of the FIPS SQL standard; however, it is not unrealistic to require that they support a limited SQL interface, even a read-only interface, provided by one of the SQL/ERI Server profiles. New procurements to add components to the National Information Infrastructure, or to upgrade existing components, can define the necessary SQL schemas and point to appropriate SQL/ERI Server profiles as procurement requirements.

This standard may also be applicable, on a case-by-case basis, in many of the following areas.

8.1 Legacy databases. A legacy database is an already installed database managed by a non-standard database management system (DBMS). This may include hierarchical and network databases popular in the 1970 to 1990 timeframe, non-standard relational databases, other non-standard data repositories, or even home-grown databases developed by Federal departments and agencies over the past three decades as enhancements to proprietary file access mechanisms. A Federal procurement might solicit development of a new interface to a legacy database that supports one of the SQL/ERI Server profiles. Modern applications could then access the legacy data using standard SQL statements.

8.2 Full-Text document databases. A document database is a database specialized to optimize the handling of text and text operations. Traditional SQL systems have been weak in this area because the SQL 1986 and 1989 standards had very minimal requirements for text management. The SQL 1992 standard has enhanced requirements for character sets and character string operations, but still falls short of the text handling requirements of text-intensive applications. An emerging standard for SQL/MM Part 2: Full-Text [13], expected sometime after 1996, is addressing more sophisticated user requirements for SQL management of text. In the meantime, some SQL vendors are offering Full-Text extensions and some Full-Text document database vendors are offering limited SQL interfaces. A Federal procurement for a Full-Text document database management system may stipulate, in addition to its requirements for text management, conformance to one of the SQL/ERI Server profiles as either a mandatory or a desirable requirement of that procurement.

8.3 Geographic Information Systems. A geographic information database is a database structured to optimize the handling of spatial data and spatial operations, especially traditional earth science information such as maps or physical topography, as well as any social, economic, or demographic data that is spatially referenced. Traditional SQL systems have been weak in this area because the existing SQL 1992 standard does not require support for constructor data types such as lists, sets, and arrays, often required as the basis of definition for more complex spatial data structures. An emerging standard for SQL/MM Part 3: Spatial [13], expected sometime after 1996, is addressing more sophisticated user requirements for SQL definition and management of spatial data types and spatial operations. In the meantime, some SQL vendors are offering Spatial extensions and some Geographic Information System (GIS) vendors are offering limited SQL interfaces. Since many Federal applications require integration of traditional government data (e.g. Census, Labor statistics, Economic Indicators, Meteorological, Health Care) with Geographic Information Systems, a Federal procurement for a Geographic Information System (GIS) may stipulate requirements for two-way integration capabilities, both to read data from an SQL database into the GIS for incorporation into spatial objects and to provide SQL application access to the value-added result. The first of these requirements is discussed in Section 10.1 below, the second could be addressed in a GIS procurement by specifying mandatory support for application access via one of the SQL/ERI Server profiles specified herein.

8.4 Bibliographic information retrieval. A bibliographic database is a database that supports the requirements of American National Standard Z39.50-1992, a standard for information retrieval developed by the National Information Standards Organization (NISO). Appendix C of that standard specifies a list of approximately 75 attributes for each database of documents. Each attribute assumes an ASCII character string value. The 1992 version of Z39.50 specifies application layer protocols for read-only queries over one or more databases each supporting the listed attributes. The results of a query are returned to the user using a NISO Record Syntax specified by other NISO standards. Annex E of Z39.50 identifies 19 possible formats for Record Syntax. If it is desirable to integrate such bibliographic databases into an SQL environment, then a procurement might solicit development of a new interface to the bibliographic database that supports one of the SQL/ERI Read-Only Server profiles, probably with an RDA/SQL binding style to take advantage of the underlying communications protocols already specified by Z39.50. Each NISO database would map to an SQL table and each bibliographic attribute would map to a column of the table. Each NISO supported Record Syntax would also map to an SQL Table with each field of the record equivalent to a column of the table. SQL applications could then access the bibliographic data using standard SQL statements.

8.5 Object database interfaces. An object database is a database managed by an object database management system (ODBMS). Object database management systems may implement non-relational data models and thus may have difficulty supporting full-function SQL requirements for nested subqueries, multi-table joins, Group-By set functions, derived columns in a Select list, value-based referential integrity, or other relational model features. On the other hand, ODBMS's may offer advanced features of object models that are rarely supported by relational implementations. These features might include user-defined abstract data types (ADTs), object identifiers, methods, inheritance, polymorphism, encapsulation, and other object-oriented enhancements. Because of their close relationship with an object-oriented programming language (e.g., C++ or Smalltalk), ODBMS's often make it easy to integrate user-written routines into database operations. Often object DBMS's are used for specialized applications with complex data structures and application-specific methods on those structures. The next version of the SQL standard, expected sometime after 1996 (see [12]), will likely incorporate many of these object database features into the SQL language. In the meantime, some SQL vendors are enhancing their products to support user-defined ADT's and other object capabilities and some object database vendors are supporting robust SQL interfaces to their products. The ODMG-93 specification sponsored by the Object Database Management Group, an informal consortium of approximately ten object database vendors, points to an Object Query Language that has many of the same features as SQL. Thus it makes sense to support an SQL interface, at least a Read Only SQL interface, to these products. The specialized methods appropriate to each object could be viewed as callable SQL functions and procedures. If it is desirable to integrate an object database into an SQL environment, then an original procurement for ODBMS software, or a follow-on new procurement for an SQL interface, could point to one of the SQL/ERI Server profiles as a mandatory or desirable procurement requirement. The vendor of an object database product may automatically support SQL views of its collection types, or a procurement could specify an exact mapping from object collection types to tables that must be supported as a procurement requirement. In either case, the result is that an SQL application would have access to objects and methods using standard SQL syntax and a standard SQL binding style.

8.6 Federal data distribution. A number of Federal agencies support public access to federally maintained data either by maintaining a public database of information or by distributing data on floppy disks, CD-ROMs, or magnetic tape. All Federal departments and Agencies, but especially those with responsibility for providing public data (e.g. Agriculture, Health and Human Services, Census, NASA, NOAA, BLS), will have increasing requests for convenient public access to data. Even individuals will be requesting additional electronic access to their individual data maintained by various Federal agencies (e.g. IRS, Social Security, Medicare). An existing SQL database could provide public access by supporting a Remote Database Access (RDA) or Direct Invocation user interface with appropriate access control restrictions; a non-SQL legacy database could support one of the SQL/ERI Read Only Server profiles for RDA or Direct Invocation in addition to the ERI profiles supported for internal goverment use (see 8.1 above). When goverment data is distributed on disk or CD-ROM, it is often accompanied by software, executable on different workstations, to provide convenient views of the data using a graphical user interface (GUI). At the present time, the government must provide software executable on a number of different workstation platforms with different GUI capabilities and requirements. In the future, the government might reduce its software development efforts by providing an appropriate SQL/ERI front-end, usually with the SQL Call Level Interface option, for each workstation family (e.g. DOS, Macintosh, Unix). Such software should be available commercially in the near term. End users could then use their favorite client-side SQL environment tool to browse the data and present it using report-writer, graphical viewer, or hypermedia presentation techniques.

8.7 Operating system file interface. Sometimes an SQL application desires access to the file characteristics of files stored in an operating system's file store. For example, the POSIX standard (FIPS PUB 151) requires that the following file characteristics be maintained for each file in the persistent file directory: file mode, file serial number, id of device containing file, number of links, id of file owner, id of file group, file size in bytes, time of last access, time of last data modification, and time of last file status change. If it is desirable that this information, as well as file name, file extension, and file usage characteristics, be accessible to SQL applications in the same operating system environment, then an original procurement for a POSIX compliant operating system, or a follow-on new procurement for SQL query access, could point to one of the SQL/ERI Read Only Server profiles supporting an SQL schema description of the desired attributes as a procurement requirement.

8.8 Open system directory interface. Sometimes an SQL application desires access to the directory information related to all of the workstations accessible in a local area network (LAN), or a wide area network (WAN). For example, the X.500 (Directory) standards supported by the International Telecommunications Union (ITU) require that certain explicit directory information be accessible at each site, and part of the IEEE POSIX standard specifies an application program interface (API) for these directory services. In addition to supporting the required X.500 communications protocols and the POSIX API, a number of implementations are also making this information available as an SQL database. If it is desirable that this information be accessible to SQL applications in the same open systems environment, then an original procurement for X.500 compatble communications products, or a follow-on new procurement for SQL query access to directory information, could point to one of the SQL/ERI Read Only Server profiles supporting an SQL schema description of the desired directory information as a procurement requirement.

8.9 Electronic mail repositories. Most electronic mail systems use the host file system to maintain e-mail documents in a user's file space and to maintain a log of e-mail activity in its own file space. Sometimes an electronic mail usability tool, procured separately from the e-mail system itself, will require SQL query access to these files, either relative to a specific individual user or to a group of users. If such SQL access is desirable, then the original procurement for the e-mail system, or a new procurement just for a follow-on SQL interface, might specify an SQL schema of metadata that must be maintained and an appropriate SQL/ERI profile for limited SQL access. Under this scenario, there might exist an underlying base table with column attributes such as: mail-id, owner, title, subject, to/from-address, linked-to-mail-id, timestamp, length, confirmation, content. Each e-mail user might own a table view that identifies all instances from the base table of e-mail sent or received by that user. Users would then be able to grant Select or Delete permissions on their own views to other users, thereby maintaining privacy in the database while supporting flexible multi-user access for the usability tools.

8.10 CASE tool repositories. Many computer-aided software engineering (CASE) tools operate similarly to the e-mail usability tools described above. Each CASE tool may use the underlying file system to maintain persistent data pertinent to its application domain. It is unrealistic to expect every such data repository to handle full function SQL statements. Instead, such repositories can be integrated into an SQL environment if they provide even the simplest SQL/ERI minimal SQL interface. The CASE tool can make simple external SQL views available to more powerful SQL processors, and those processors can, in turn, provide the full power and flexibility of the SQL language to end user applications. If integration of CASE tools into an SQL environment is desirable, then the original CASE tool procurement, or a new follow-on SQL interface procurement, can require implementation of an appropriate SQL/ERI Server profile over an SQL schema specified by that procurement.

8.11 XBase repositories. XBase is an emerging ANSI standard specification for a computer database and graphical presentation language popular on personal computers. The project description for this proposed new language standard specifies the desirability of an SQL interface so that XBase users can have access to standard conforming SQL databases. In this situation, XBase may be regarded as a client-side product in an SQL environment. The XBase language also provides data definition and data management capabilities for persistent tables of data in personal computer environments. With the advent of computer networks, it is often desirable to consider data on individual personal computers or workstations as stand-alone data repositoires in an integrated data processing environment. In this situation, XBase implementations may be regarded as a server-side products in an SQL environment. If it is desirable to integrate data from individual XBase repositories into a distributed SQL processing environment, then the original XBase procurement, or a follow-on SQL interface procurement, could specify an appropriate SQL/ERI Read-Only Server or SQL/ERI Read-Write Server profile for convenient access from other applications in the SQL environment. All XBase tables and columns would map directly to SQL tables and columns, with either XBase data types or SQL data types for columns, as appropriate. If XBase data types are used, then the SQL view would present those columns as SQL Domains and would provide special callable functions for XBase operations on those data types. All applications could then depend upon a single, standard language for access to persistent data, and the SQL Call Level Interface (SQL/CLI) and/or SQL Remote Database Access (SQL/RDA) could be used for interoperability.

8.12 C++ sequence class repositories. The emerging ANSI standard for the C++ programming language specifies search capabilities for Sequence classes in its Standard Template Library. Such sequence classes may sometimes be considered as persistent, data repositories. Often a small, or isolated, database application will use C++ Sequence classes for data management. Since the template library for Sequence classes provides search capabilities analogous to simple SQL predicates, it may be possible to integrate C++ Sequence class repositories into an SQL environment with a minimum of development effort. If such integration is desirable, then either in-house development, or inexpensive commercial software, may provide the appropriate SQL/ERI interface. All applications in the SQL environment would then have homogeneous access to the C++ data repository using standard SQL language statements.

8.13 Object Request Broker repositories. An Object Request Broker (ORB) provides user access to a collection of objects that have public interface definitions. In the X/Open and Object Management Group's architecture for a common object request broker (CORBA), these interface definitions are maintained in a database, called the Interface Repository, that is analogous in intent to an SQL Information Schema. If integration of such interface repositories, or integration of the public interfaces themselves, into an SQL environment is desirable, then the original ORB procurement, or a new follow-on SQL interface procurement, can require implementation of an appropriate SQL/ERI Server profile over an SQL schema specified by that procurement.

8.14 Real-Time database interface. A real-time database is a database optimized for access speed and specialized for handling data structures prevalent in radar systems, aircraft guidance, and satellite transmission. Often real-time databases are specially developed in a systems programming language for performance efficiency. Application-specific data structures are then stored in collection types, usually analogous to the C++ sequence classes mentioned above, with SQL cursor-like operations (e.g., Fetch, Insert) for moving structure instances to and from the database. The Real-Time Object Manager (RTOM) supporting Navy command and control systems is an example of such a system. If it is desirable to integrate real-time databases into an SQL environment, then either the original real-time database procurement, or an explicit follow-on for an SQL interface, could point to an appropriate SQL/ERI Server profile supporting an application-specific schema as a procurement requirement.

8.15 Internet file repositories. The Internet Engineering Task Force (IETF), the engineering group responsible for developing Internet Society applications, has published file access specifications for Wide Area Information System (WAIS) and World Wide Web (WWW). Files stored in these repositories in standard text formats, or in multimedia formats for hypertext, images, audio, motion pictures, or music, are then accessible on the Internet using File Transfer Protocols (FTP) or other client-side file access and presentation tools such as GOPHER and MOSAIC. Since the metadata for these files is very similar to the metadata of a file system (see 8.7 above) and the text content is often subject to bibliographic information retrieval (see 8.4 above), it may be possible to integrate these repositories into an SQL environment with a minimum of development effort, possibly even using tools already available for integrating file systems and bibliographic retrieval systems. If it is desirable to integrate WAIS and Web repositories into an SQL environment, then either ad hoc academic development, or inexpensive commercial software, may provide the appropriate SQL/ERI Server interface. Use of SQL/ERI profiles may provide needed access controls and integrity constraints on the repository side, as well as homogeneous access from SQL applications in remote client-side sites.