1.2 A Brief History of SQL
In the early 1970s, an IBM
research fellow named Dr. E. F. Codd endeavored to apply the rigors of
mathematics to the then-untamed world of data storage and retrieval.
Codd's work led to the definition of the
relational data model and a language called
DSL/Alpha for manipulating data in a relational database. IBM liked
what they saw, so they commissioned a project called System/R to
build a prototype based on Codd's work. Among other
things, the System/R team developed a simplified version of DSL
called SQUARE, which was later renamed SEQUEL, and finally renamed
SQL.
The work done on System/R eventually led to the release of various
IBM products based on the relational model. Other companies, such as
Oracle, rallied around the relational flag as well. By the mid
1980's, SQL had gathered sufficient momentum
in the
marketplace to warrant oversight by the American National Standards
Institute (ANSI). ANSI released its
first SQL standard in 1986, followed by updates in 1989, 1992, and
1999.
Thirty years after the System/R team began prototyping a relational
database, SQL is still going strong. While there have been numerous
attempts to dethrone relational databases in the marketplace,
well-designed relational databases coupled with well-written SQL
statements continue to succeed in handling large, complex data sets
where other methods fail.
1.2.1 Oracle's SQL Implementation
Given that Oracle was an early adopter of the relational model and
SQL, one might think that they would have put a great deal of effort
into conforming with the various ANSI standards. For many years,
however, the folks at Oracle seemed content that their implementation
of SQL was functionally equivalent to the ANSI standards without
being overly concerned with true compliance. Beginning with the
release of Oracle8i, however, Oracle has stepped
up its efforts to conform to ANSI standards and has tackled such
features as the CASE statement and the left/right/full outer join
syntax.
Ironically, the business community seems to be moving in the opposite
direction. A few years ago, people were much more concerned with
portability and would limit their developers to ANSI-compliant SQL so
that they could implement their systems on various database engines.
Today, companies tend to pick a database engine to use across the
enterprise and allow their developers to use the full range of
available options without concern for ANSI-compliance. One reason for
this change in attitude is the advent of n-tier architectures, where
all database access can be contained within a single tier instead of
being scattered throughout an application. Another possible reason
might be the emergence of clear leaders in the DBMS market over the
last five years, such that managers perceive less risk in which
database engine they choose.
1.2.2 Theoretical Versus Practical Terminology
If you were to
peruse the
various writings on the relational model, you would come across
terminology that you will not find used in this book (such as
relations and tuples).
Instead, we use practical terms such as tables and rows, and we refer
to the various parts of an SQL statement by name rather than by
function (i.e., "SELECT clause"
instead of projection). With all due respect to
Dr. Codd, you will never hear the word tuple
used in a business setting, and, since this book is targeted toward
people who use Oracle products to solve business problems, you
won't find it here either.
|
