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 原文请找腾讯752018766优,文^论~文.网http://www.youerw.com/ 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.