SQL:1999, formerly known as SQL3 Andrew Eisenberg Jim Melton Sybase, Concord, MA 01742 Sandy, UT 84093 [email protected] [email protected] number of Working Groups to actually do the Background technical work—WG3 (Database Languages) is responsible for the SQL standard, while WG4 is For several years now, you’ve been hearing and progressing the SQL/MM (SQL MultiMedia, a suite reading about an emerging standard that everybody of standards that specify type libraries using SQL’s has been calling SQL3. Intended as a major object-oriented facilities). enhancement of the current second generation SQL In the United States, IT standards are standard, commonly called SQL-92 because of the handled by the American National Standards year it was published, SQL3 was originally planned Institute’s Accredited Standards Development to be issued in about 1996…but things didn’t go as Committee NCITS (National Committee for planned. Information Technology Standardization, formerly As you may be aware, SQL3 has been known more simply as “X3”). NCITS Technical characterized as “object-oriented SQL” and is the Committee H2 (formerly “X3H2”) is responsible for foundation for several object-relational database several data management-related standards, including management systems (including Oracle’s ORACLE8, SQL and SQL/MM. Informix’ Universal Server, IBM’s DB2 Universal When the first generation of SQL was Database, and Cloudscape’s Cloudscape, among developed (SQL-86 and its minor enhancement SQL- others). This is widely viewed as a “good thing”, but 89), much—perhaps most—of the development work it has had a downside, too: it took nearly 7 years to was done in the USA by X3H2 and other nations develop, instead of the planned 3 or 4. participated largely in the mode of reviewing and As we shall show, SQL:1999 is much more critiquing the work ANSI proposed. By the time than merely SQL-92 plus object technology. It SQL-89 was published, the international community involves additional features that we consider to fall was becoming very active in writing proposals for the into SQL’s relational heritage, as well as a total specification that became SQL-92; that has not restructuring of the standards documents themselves changed while SQL:1999 was being developed, nor with an eye towards more effective standards do we believe it’s likely to change in the future— progression in the future. SQL is truly an international collaborative effort. A work of explanation is in order about the Standards Development informal names we’re using for various editions of Process the SQL standard. The first versions of the standard are widely known as SQL-86 (or SQL-87, since the The two de jure organizations actively involved in ISO version wasn’t published until early 1987), SQL- SQL standardization, and therefore in the 89, and SQL-92, while the version just now being development of SQL:1999, are ANSI and ISO. finalized should become known as SQL:1999. Why More specifically, the international the difference…why not “SQL-99”? Well, simply community works through ISO/IEC JTC1 (Joint because we have to start thinking about what the next Technical Committee 1), a committee formed by the generation will be called, and “SQL-02” seemed International Organization for Standardization in more likely to be confused with “SQL2” (which was conjunction with the International Electrotechnical the project name under which SQL-92 was Commission. JTC1’s responsibility is to develop and developed)…not to mention the fact that “02” isn’t maintain standards related to Information really greater than “99”. In other words, we don’t Technology. Within JTC1, Subcommittee SC32, want even the name of the SQL standard to suffer titled Data Management and Interchange, was from the year 2000 problem! recently formed to take over standardization of several standards related to database and metadata that had been developed by other organizations (such Contents of SQL:1999 as the now-disbanded SC21). SC32, in turn, formed a With that background under our belts, it’s time to take a survey of the actual contents of SQL:1999. While we recognize that most readers of this column will not know the precise contents of even SQL-92, WHERE COL1 > COL2 AND space limitations prohibit our presenting the complete COL3 = COL4 OR feature set of SQL:1999. Consequently, we’re going UNIQUE(COL6) IS NOT FALSE to restrict our overview to just those features that are new to this most recent generation of the SQL SQL:1999 also has two new composite standard. types: ARRAY and ROW. The ARRAY type allows The features of SQL:1999 can be crudely one to store collections of values directly in a column partitioned into its “relational features” and its of a database table. For example: “object-oriented features”. We’ll cover them in that sequence for convenience. WEEKDAYS VARCHAR(10) ARRAY[7] would allow one to store the names of all seven Relational Features weekdays directly in a single row in the database. Although we call this category of features Does this mean that SQL:1999 allows databases that “relational”, you’ll quickly recognize that it’s more do not satisfy first normal form? Indeed, it does, in appropriately categorized as “features that relate to the sense that it allows “repeating groups”, which SQL’s traditional role and data model”…a somewhat first normal form prohibits. (However, some have less pithy phrase. The features here are not strictly argued that SQL:1999’s ARRAY type merely allows limited to the relational model, but are also unrelated storage of information that can be decomposed, much to object orientation. as the SUBSTRING function can decompose These features are often divided into about character strings—and therefore doesn’t truly violate five groups: new data types, new predicates, the spirit of first normal form.) enhanced semantics, additional security, and active The ROW type in SQL:1999 is an extension database. We’ll look at each in turn. of the (anonymous) row type that SQL has always had and depended on having. It gives database New Data Types designers the additional power of storing structured values in single columns of the database: SQL:1999 has four new data types (although one of them has some identifiable variants). The first CREATE TABLE employee ( of these types is the LARGE OBJECT, or LOB, type. EMP_ID INTEGER, This is the type with variants: CHARACTER NAME ROW ( LARGE OBJECT (CLOB) and BINARY LARGE GIVEN VARCHAR(30), OBJECT (BLOB). CLOBs behave a lot like character FAMILY VARCHAR(30) ), strings, but have restrictions that disallow their use in ADDRESS ROW ( PRIMARY KEYs or UNIQUE predicates, in STREET VARCHAR(50), FOREIGN KEYs, and in comparisons other than CITY VARCHAR(30), purely equality or inequality tests. BLOBs have STATE CHAR(2) ) similar restrictions. (By implication, LOBs cannot be SALARY REAL ) used in GROUP BY or ORDER BY clauses, either.) Applications would typically not transfer entire LOB SELECT E.NAME.FAMILY values to and from the database (after initial storage, FROM employee E that is), but would manipulate LOB values through a special client-side type called a LOB locator. In While you might argue that this also violates first SQL:1999, a locator is a unique binary value that acts normal form, most observers recognize it as just as a sort of surrogate for a value held within the another “decomposable” data type. database; locators can be used in operations (such as SQL:1999 adds yet another data type-related SUBSTRING) without the overhead of transferring facility, called “distinct types”. Recognizing that it’s an entire LOB value across the client-server generally unlikely that an application would want, interface. say to directly compare an employee’s shoe size with Another new data type is the BOOLEAN his or her IQ, the language allows programmers to type, which allows SQL to directly record truth declare SHOE_SIZE and IQ to each be “based on” values true, false, and unknown. Complex INTEGER, but prohibit direct mixing of those two combinations of predicates can also be expressed in types in expressions. Thus, an expression like: ways that are somewhat more user-friendly than the usual sort of restructuring might make them: WHERE MY_SHOE_SIZE > MY_IQ of UNIX’s characters were already in use for other (where the variable name implies its data type) would purposes in SQL. be recognized as a syntax error. Each of those two The other new predicate, DISTINCT, is very types may be “represented” as an INTEGER, but the similar in operation to SQL’s ordinary UNIQUE SQL system doesn’t allow them to be mixed in predicate; the important difference is that two null expressions—nor for either to be, say, multiplied by values are considered not equal to one another and an INTEGER: would thus satisfy the UNIQUE predicate, but not all applications want that to be the case. The DISTINCT SET MY_IQ = MY_IQ * 2 predicate considers two null values to be not distinct from one another (even though they are neither equal Instead, programs have to explicitly express their to nor not equal to one another) and thus those two deliberate intent when doing such mixing: null values would cause a DISTINCT predicate not to be satisfied. WHERE MY_SHOE_SIZE > CAST (MY_IQ AS SHOE_SIZE) SET MY_IQ = SQL:1999’s New Semantics MY_IQ * CAST(2 AS IQ) It’s difficult to know exactly where to draw the line when talking about new semantics in SQL:1999, but In addition to these types, SQL:1999 has we’ll give a short list of what we believe to be the also introduced user-defined types, but they fall into most important new behavioral aspects of the the object-oriented feature list.