Relational Database Systems

Relational Database Systems

Following a famous paper written by Ted Codd in 1970, database systems changed considerably. Codd suggested that database systems should present the user with a view of data arranged as tables called relations. Behind the scenes, there might be a complicated data formation that allowed quick response to different queries. But, unlike the user of earlier database systems, the user of a relational system would not be troubled with the storage structure. Queries could be expressed in a very high-level language, which greatly improved the efficiency of database programmers.

Relational Database Systems
We shall discuss the relational model of database systems throughout most of these articles, starting with the basic relational concepts in “The Relational Data Model”. SQL ("Structured Query Language"), the most important query language based on the relational model, will be discussed in “The Database Language SQL”. However, a brief introduction to relations will give the reader a hint of the simplicity of the model, and an SQL sample will suggest how the relational model promotes queries written at a very high level, avoiding details of "navigation" through the database.

Example: Relations are tables. Their columns are headed by attributes, which describe the entries in the column. For instance, a relation named Accounts, recording bank accounts, their balance, and type might look like:

Heading the columns are the three attributes: accountNo, balance, and type. Below the attributes are the rows, or tuples. Here we show two tuples of the
relation explicitly, and the dots below them suggest that there would be many more tuples, one for each account at the bank. The first tuple says that account
number 12345 has a balance of one thousand dollars, and it is a savings account. The second tuple says that account 67890 is a checking account with $2846.92.

    Suppose we wanted to know the balance of account 67890. We could ask this query in SQL as follows:

    SELECT balance
    FROM Accounts
    WHERE accountNo = 67890;

For another example, we could ask for the savings accounts with negative balances by:

    SELECT accountNo
    FROM Accounts
    WHERE type = 'savings' AND balance < 0;

We do not expect that these two examples are enough to make the reader an expert SQL programmer, but they should convey the high-level nature of the SQL "select-from-where" statement. In principle, they ask the DBMS to

1. Inspect all the tuples of the relation Accounts mentioned in the FROM clause,

2. Pick out those tuples that satisfy some principles indicated in the WHERE clause, and

3. Produce as an answer certain attributes of those tuples, as indicated in the SELECT clause.

In practice, the system must "optimize" the query and find a well-organized way to answer the query, even though the relations involved in the query may be very large.

By 1990, relational database systems were the norm. Yet the database field continues to develop, and new problems and approaches to the management of data surface regularly. In the balance of this section, we shall consider some of the modern trends in database systems.