What SQL Does
Although Oracle had the initial impact on the market, other companies, including IBM, followed. In the process of developing the SQL/DS RDBMS product, IBM created a language code-named SEQUEL, which was an acronym for Structured English QUEry Language. This moniker was appropriate because SEQUEL statements looked like English-language sentences, but were more structured than most casual speech.
When it came time to actually release its RDBMS product, along with its associated language, IBM’s legal department flagged a possible copyright issue with the name SEQUEL. In response, management elected to drop the vowels and call the language SQL (pronounced ess-cue-ell). The reference to Structured English was lost in the process. As a result, many people thought that SQL was an acronym for Structured Query Language. This is not the case. In computer programming, a structured language has some very well defined
characteristics. SQL does not share those characteristics and is thus not a structured language, query or otherwise.
SQL does far more than just execute queries. Yes, of course you can use it to retrieve the data you want from a database, using a query. However, you can also use SQL to create and destroy databases, as well as modify their structure. In addition, you can add, modify, and delete database data with SQL. Even with all that capability, SQL is still considered only a data sublanguage. It does not have all the features of general-purpose programming languages such as C, C++, C#, or Java. SQL is specifically designed for dealing with relational databases, and thus does not include a number of features that are needed for creating useful application programs. As a result, to create a complete application that accesses a database, you must write the code in one of the general-purpose languages, and embed SQL statements within the program whenever it communicates with the database.
In SQL, the equivalent of a relation is a table. However, tables are not exactly like relations in that a table can have duplicate rows. For that reason, tables in a relational database are not modeled on the sets of set theory, but rather on multi, which are similar to sets except they allow duplicate objects. Although a relation is not exactly the same thing as a table, the terms are often used interchangeably. Because relations were defined by theoreticians, they have a very precise definition. The word table, on the other hand, is in
general use and is often much more loosely defined. When I use the word table in this book, I use it in the more restricted sense, as being an alternate term for relation. The attributes of a relation are strictly equivalent to the columns and rows of a table.
So, what’s a relation? Formally, a relation is a two-dimensional table that has the following characteristics:
✦ Every cell in the table must contain a single value, if it contains any value at all. Repeating groups and arrays are not allowed as values.
✦ All the entries in any column must be of the same kind. For example, if a column contains an employee name in one row, it must contain employee names in all rows that contain values.
✦ Each column has a unique name.
✦ The order of the columns doesn’t matter.
✦ The order of the rows doesn’t matter.
✦ No two rows may be identical.
If and only if a table meets all these criteria, it is a relation. You might have tables that fail to meet one or more of these criteria. For example, a table might have two identical rows. It is still a table in the loose sense, but it is not a relation.
The ANSI/ISO SQL Standard
In the early 1980s, IBM started using SQL in its first relational database product, which was incorporated into the System/38 minicomputer. Smaller companies in the DBMS industry, in an effort to be compatible with IBM’s offering, modeled their when the American National Standards Institute (ANSI) issued the SQL-86 standard. The SQL standard has been continually updated since then, with
subsequent revisions named SQL-89, SQL-92, SQL:1999, and SQL:2003. SQL:2003 was updated in 2005 with a section called SQL/XML, which significantly enhances SQL’s ability to deal with data in XML format.
What SQL Does Not Do
In the 1930s, Alan Turing defined a very simple machine that could perform any computation that could be performed by any computer imaginable, regardless of how big and complex. This simple machine has come to be known as a Universal Turing Machine. Any computer that can be shown to be equivalent to a Universal Turing Machine is said to be Turing-complete. All modern computers are Turing-complete. Similarly, a computer language that is capable of expressing any possible computation is said to be Turing complete. Practically all popular languages, such as C, C#, C++, BASIC, Fortran, COBOL, Pascal, Java, and many others are Turing-complete. SQL, however, is not. It lacks flow of control structures that are needed for some classes of computations. Because SQL is not Turing-complete, you cannot write an SQL program to perform a complex series of steps, as you can with a language such as C or Java. On the other hand, languages such as C and Java do not have the data manipulation facilities that SQL has, so you cannot write a program with them that will efficiently operate on database data. There are several ways to solve this dilemma:
✦ Combine the two types of language by embedding SQL statements
within a program written in a host language such as C.
✦ Have the C program make calls to SQL modules to perform data manipulation
functions.
✦ Create a new language that includes SQL, but also incorporates those structures that would make the language Turing-complete. All three of these solutions are offered by one or another of the DBMS vendors.