Applications require access to multiple data repositories, many of which are managed by non-SQL processors. It is not unusual for applications to require data from the operating system, from graphics repositories, from CD-ROM's, from CAD/CAM databases, or from libraries of cataloged data. From a user's perspective, it is unrealistic to expect every data repository to be able to handle even the lowest "Entry SQL" queries. For example, who would expect an electronic mail system to handle SQL joins and subqueries over its message headers? Yet, every e-mail system is a data repository with information that applications sometimes require. What is needed is an interface specification that enables a non-SQL data repository to make certain external views available to SQL processors and for those SQL processors to, in turn, allow the full power and flexibility of the SQL query language over those views to the end user. It makes sense to specify a "client" and a "server" interface to external repositories so that non-SQL systems can act as servers to SQL requests for data. It makes sense to develop the conformance requirements needed for non-SQL systems to provide SQL views of their data and for SQL systems to provide full function SQL operations over that data to SQL users.

This interface is defined to be the SQL External Repository Interface (SQL/ERI). It consists of a "Server" part and a "Client" part. Non-SQL systems may claim conformance as SQL/ERI Servers and full-function SQL systems may claim conformance as SQL/ERI Clients. This first FIPS PUB for SQL Environments only addresses conformance criteria for SQL/ERI Servers; subsequent versions may address conformance criteria for SQL/ERI Clients. A wide range of non-SQL products and services might be able to claim conformance as SQL/ERI Servers. They could provide high level abstract data types with application-specific methods and operations. They would be required to evaluate "simple" SQL queries over individual tables defined in the schema. The exact meaning of "simple" is specified in the SQL/ERI profile specifications at different levels of service. The SQL processor can then think of the external repository as an SQL-environment that can be connected to, but that can only respond to whatever SQL statements are specified for that level of service.

If an SQL system claims conformance as an SQL/ERI Client, then it agrees to provide SQL functionality, at whatever level of the SQL standard it conforms to, over any table provided by an SQL/ERI Server. This may require that the SQL system automatically create a temporary table whenever the external view is referenced in a query, and then populate that table using the limited capabilities provided by the "server" interface so that it can guarantee the ability to perform nested queries, or searched updates and deletes, or recursive queries, or whatever is requested by its application.

With the SQL/ERI "client" and "server" definitions, non-SQL systems would be able to provide services to SQL-based applications even though they might not be able to provide the expected query flexibility, access control, concurrency control, or updatability required of a full-function SQL data manager. Full-function SQL processors could provide these expected data management facilities and, in addition, provide user access to data repositories not otherwise accessible via the SQL language. Section 2 describes how SQL/ERI profiles might be used to provide uniform and integrated application access to both SQL and non-SQL data at local and remote sites.

The SQL/ERI profile specifications provide several different conformance levels for non-SQL systems. A conforming SQL/ERI server is required to be "self-describing" as if it were a separate SQL-environment. It is required to supply an SQL Information Schema describing all available tables and the equivalent SQL data types for its columns. If the ERI Server provides new abstract data types not defined in the SQL standard, then it is also required to provide an SQL ADT interface definition as specified in the emerging SQL3 standard [12].

What is needed to make the above scenario feasible is an SQL/ERI Server profile, so that these non-SQL data repositories can provide a simple, external interface, accessible from full-function SQL systems. Sophisticated applications can then be built without the need to "understand" the non-standard data access methods unique to each repository. Instead, full-function SQL systems could be used as intermediaries. The SQL "client" could connect itself to the non-SQL "server" using the standard SQL/ERI interface; the application could then use the full power and flexibility of the SQL data manipulation language, as well as the system provided special access methods, to select and mange the data as if it were maintained in an SQL database. Section 7 of this FIPS PUB provides the necessary SQL/ERI Server profiles to get this integration scenario started.