ch3.

fm Page 31 Thursday, January 25, 2001 6:47 AM

C H A P T E R

T H R E E

SQL Basics

In this chapter we take our first foray into SQL and begin peeling back its many layers. Well examine the Who, What, and Where functional areas present in each SQL query, introduce the SQL clauses used to construct queries, and illustrate these ideas with an example.

ch3.fm Page 32 Thursday, January 25, 2001 6:47 AM

32 | THREE SQL Basics

Who, What, and Where

Every SQL query consists of just three basic parts. I call these the 3Ws. First and foremost, there is the Whowho is the query about? Then there is the Whatwhat information do you want to see about the Who? And finally, there is the Wherewhere will you locate the information? As you construct a query, you first identify the Who and translate it into SQL. You next identify the data columns needed in the report (i.e., the What) and write the SQL that provides access to these data columns (i.e., the Where). You finish the query by writing the SQL to list the What data columns. Its a Who-What-Where-What process. You might wonder why its necessary to make two passes at the What section. Its a matter of testing and debugging. Well take this up in greater detail in later chapters. Lets take a simple example and illustrate the 3Ws. Suppose that someone asks you the following question: What are the names and permanent addresses of people in our registration database whose last name is Weaver? Lets think about the query first. Well translate it into SQL shortly, after an introduction into the basic SQL language elements. First, theres the Who. Just who is the report about? Clearly, its people and not their courses or their grades or something else entirely. But there are also modifiers. We dont want all people, just those whose last name is Weaver. Thats our populationpeople in the registration database whose last name is Weaver. Now lets deal with the What. What information do we want to see about the registered students? Clearly, we want names and permanent addresses, but exactly what this means is open to some interpretation. Is city, state, and nation sufficient for the address? Or should we include zip codes and street addresses too? Well need to clarify this with the person making the request. Also, nothing was said about an identification number, but the report probably should include this data column as well. Again, well need to clarify this. For now, lets assume that identification number, name, street, city, state, zip code, and nation are sufficient. Finally, what about the Where? Where will we get this information? Well, names appear in the NAME table. Their addresses appear in the ADDRESS table. We could use these two tables to produce the report, but it

ch3.fm Page 33 Thursday, January 25, 2001 6:47 AM

THREE SQL Basics | 33

would mean wed need to join the tables properly. Thats not a big deal, but there might be an easier way if we could find a data view or static table that contained the necessary information. In fact, Figure 2-8 on page 23 did list a data view for names and permanent addresses (V1_NAME_ADDRESS). Figure 3-1 shows the data dictionary. Scan the data column comments. It looks like this view will work fine. Wed want to confirm that assessment by discussing it with MIS staff or others familiar with the view.
15-JUN-2000 14:13 VIEW: V1_NAME_ADDRESS Page: 1 Report: v1_name_address.dic Owner: OR3 SQL: tabldict.sql View of Current Name and Current Active Permanent Address name type width scale nulls comments ----------------------- -------- ----- ----- --------- ------------------------V1_NAME_ID VARCHAR2 7 NOT NULL Identification number. name_id from NAME table. V1_NAME_SEQNO NUMBER 2 0 NOT NULL Sequence number for name. Most recent name has highest sequence number. name_seqno from NAME table. V1_NAME_LAST VARCHAR2 30 NOT NULL Last name. name_last from NAME table. V1_NAME_FIRST VARCHAR2 20 NULL First name. name_first from NAME table. V1_NAME_MIDDLE VARCHAR2 20 NULL Middle name. name_middle from NAME table. V1_ADDRESS_CODE VARCHAR2 2 NULL Type of address. Uses codes from ADDRESS_CODES table. address_code from ADDRESS table. V1_ADDRESS_SEQNO NUMBER 2 0 NULL Sequence number for addresses of a specified type for the person. address_seqno from ADDRESS table. V1_ADDRESS_ACTIVE_IND VARCHAR2 1 NULL Indicator Y if address is active. address_active_ind from ADDRESS table. V1_ADDRESS_STREET VARCHAR2 30 NULL Street address. address_street from ADDRESS table. V1_ADDRESS_CITY VARCHAR2 20 NULL City of address. address_city from ADDRESS table. V1_ADDRESS_STATE_CODE VARCHAR2 2 NULL State code of address. Uses codes from STATE_CODES table. address_state_code from ADDRESS table. V1_ADDRESS_ZIP VARCHAR2 10 NULL Zip code of address. address_zip from ADDRESS table. V1_ADDRESS_NATION_CODE VARCHAR2 3 NULL Nation code of address. Uses codes from NATION_CODES table. address_nation_code from ADDRESS table.

FIGURE 3-1 Data dictionary of the v1_name_address view.

ch3.fm Page 34 Thursday, January 25, 2001 6:47 AM

34 | THREE SQL Basics

This is pretty typical of the way queries begin. Someone asks a question. You mentally translate that question into the Who, What, and Where precursors to SQL. You then clarify any issues that arise from this translation. And finally you begin to write the actual SQL. Before constructing the SQL for our name and address report, lets examine the basic clauses that comprise each query.

SQL Clauses
One of the things that has always struck me as extraordinary about SQL is its sparseness and apparent simplicity. There is only one command with seven basic clauses that can appear in a SQL query. And only six of the seven clauses commonly get used. From just these six or seven language elements we can construct an unlimited number of queries of tremendous variety and complexity. In this sense, SQL is truly an elegant language. The SQL command used to construct all ad hoc queries is the SELECT command. There are, of course, other commands in SQL. For example, the INSERT command inserts data into a table; the UPDATE command updates existing data in a table; the DELETE command deletes rows of data from a table. As a query writer, you need not worry about any of these other commands. You wont have access rights to use them. The only command that matters is the SELECT command. The SELECT command begins with the word SELECT (Could it be any other way?). The six most commonly used clauses are SELECT: In the SELECT clause, you list the data items that will appear in the report. These items may be simple data columns (e.g., an identification number or an address city) or expressions created for the report (e.g., a name constructed by stringing together first and last names). If the report summarizes data by groups, the SELECT clause also specifies which summaries to include (e.g., averages or counts). All ad hoc queries must have SELECT and FROM clauses. All other clauses are optional. FROM: In the FROM clause, you list the tables or views needed to define the report population and display the items that appear in the SELECT clause. Typically, the FROM clause contains from one to a dozen tables.

ch3.fm Page 35 Thursday, January 25, 2001 6:47 AM

THREE SQL Basics | 35

As the number of tables increases, the complexity of the query increases, and the response time and system performance generally decrease. So keep the list of tables in the FROM clause to a minimum. In a later chapter, well also discuss a special table in every FROM clause called the driving table. The choice of driving table can also affect query response times. WHERE: In the WHERE clause, you accomplish two things. First, you define the report population. And second, you specify how the tables that appear in the FROM clause are joined. Typically, the WHERE clause of a query is the most complex in appearance. It can sometimes be long and, if not structured properly, can become convoluted. Getting it right is critical. But fortunately, getting it right is not a big deal if you follow a few simple ideas. Much more on this later. While the WHERE clause is optional, almost all queries contain this clause. The only exception would be a query run against a single table where the population consisted of the entire table. GROUP BY: In the GROUP BY clause, you specify which groups will be used to summarize the data using averages, counts, sums, and other summaries. As well see, the GROUP BY and the SELECT clauses frequently must be coordinated to produce the desired effect. Many queries do not contain a GROUP BY clause. HAVING: In the HAVING clause, you limit the report to specific subgroups of the population. You can think of the HAVING clause like a WHERE clause for groups. It restricts the final output to those groups meeting the specified criteria (e.g., courses where the average grade exceeds a B). Many queries do not contain a HAVING clause. HAVING cannot appear without a GROUP BY, but the reverse is not true. ORDER BY: In the ORDER BY clause, you sort the rows to appear in the report (e.g., alphabetically by last name). Typically, this clause is easy to construct. It appears frequently in reports but is optional. These clauses provide a structure, a kind of skeleton, to every SQL query. This skeleton holds the query together, and it distinguishes functionally distinct parts of the query (see Figure 3-2).

ch3.fm Page 36 Thursday, January 25, 2001 6:47 AM

36 | THREE SQL Basics

SELECT FROM WHERE GROUP BY HAVING ORDER BY

... ... ... ... ... ...;

FIGURE 3-2 Structure provided by clauses in the SELECT command.

1

The six clauses in the SELECT command must appear in this order, although only the SELECT and FROM clauses are required. In this book, all SQL words appear in uppercase to distinguish them from other parts of a query. However, it is unnecessary to use uppercase; lowercase or mixed case will work just as well. Words like the six clauses that are part of the SQL syntax are also known as reserved words. You cannot use a reserved word in a query except as an item of SQL, so, for example, you cannot have a data column called from because that is a reserved word. Note that the query ends with a semicolon.

Example
Lets construct the SQL needed to provide the name and address report for people whose last name is Weaver. Well do this in the Who, What, and Where steps discussed earlier. Step 1. Our population is people whose last name is Weaver. Figure 3-3 shows the FROM and WHERE clauses needed to translate this English definition into SQL. This is a particularly simple example, so the SQL is also simple. In more complex queries, the SQL definition of the population also will be more complicated. In either case, its absolutely essential that we define the population correctly or the report will be meaningless. Step 2. Identify the data columns or expressions needed in the report. Earlier we said the report should include the identification number, name, street, city, state, zip code, and nation. These are all available

ch3.fm Page 37 Thursday, January 25, 2001 6:47 AM

THREE SQL Basics | 37

FROM WHERE

v1_name_address v1_name_last = Weaver

FIGURE 3-3 SQL that defines the Who in the Weaver report.
1

Define the Who in each query with the FROM and WHERE clauses. Here the population is people in the V1_NAME_ADDRESS view whose last name is Weaver.

in the V1_NAME_ADDRESS view. By referring to the data dictionary for the view (Figure 3-1), you can locate the appropriate data column names. The fact that everything exists in one view makes things easy. And since we already included the view in the FROM clause when we defined the Who population, there is no need to join additional tables and thus no need for more WHERE criteria. So we can skip the Where step in the Who-What-Where-What chain. Step 3. Figure 3-4 shows the SELECT clause that includes each of the What data columns in the report. Its just a simple list of the columns. The order in which you place the columns in the list is the order in which they will appear in the report. For example, because v1_name_id is listed first, that will be the first column in the report. Step 4. Add an ORDER BY to sort the report in the desired fashion. In this case, lets get an alphabetical listing of the people by their name. Figure 3-5 shows the ORDER BY needed to sort people by first name. Step 5. Finish the query by formatting the report. There are many SQL*Plus formatting commands. These will be discussed in more detail in Chapter 10. For now, lets just consider the COLUMN command that can be used to adjust the default headings and width of the report columns. Figure 3-6 shows the final query and the report. Note the effect of the COLUMN formatting on the report. For more information on the COLUMN command, see Appendix E on page 325. Also note the use of aliases in Figure 3-6. An alias is just a nickname that you assign to a data column or expression in the SELECT clause. Aliases let you refer easily to an item using a meaningful name.

ch3.fm Page 38 Thursday, January 25, 2001 6:47 AM

38 | THREE SQL Basics

SELECT

FROM WHERE

v1_name_id, v1_name_last, v1_name_first, v1_address_street, v1_address_city, v1_address_state_code, v1_address_zip, v1_address_nation_code v1_name_address v1_name_last = Weaver

FIGURE 3-4 SQL that defines the What in the Weaver report.
1

In the What section of an SQL query, you simply list the data columns or expressions that should appear in the report. The order that you list the data columns is the same order in which theyll appear in the report. In this case, the identification number will appear in report column 1, the last name will appear in the report column 2, and so on. In this example, all the items in the SELECT clause are data columns in the V1_NAME_ADDRESS view. As well see in later chapters, there are many other types of items that may also appear in the SELECT clause.

SELECT

FROM WHERE ORDER BY

v1_name_id, v1_name_last, v1_name_first, v1_address_street, v1_address_city, v1_address_state_code, v1_address_zip, v1_address_nation_code v1_name_address v1_name_last = Weaver v1_name_first;

FIGURE 3-5 Adding an ORDER BY to sort the Weaver report.

1

The ORDER BY in this SQL will sort the report by first name. With an ORDER BY, you also can use something called positional notation. Because v1_name_first appears third in the SELECT clause, using an ORDER BY 3 will produce the same effect as using ORDER BY v1_name_first. Note that all SQL queries end with a semicolon or slash (/).

ch3.fm Page 39 Thursday, January 25, 2001 6:47 AM

THREE SQL Basics | 39

CLEAR COLUMNS 1 COLUMN last FORMAT a8 COLUMN first FORMAT a8 COLUMN v1_address_street HEADING street FORMAT a16 COLUMN city FORMAT a14 COLUMN st FORMAT a2 COLUMN zip FORMAT a5 COLUMN natn FORMAT a4 SELECT v1_name_id id, v1_name_last last, 3 v1_name_first AS first, v1_address_street, v1_address_city city, v1_address_state_code st, v1_address_zip zip, v1_address_nation_code natn FROM v1_name_address WHERE v1_name_last = Weaver ORDER BY v1_name_first;

4
id ------@527282 @377715 @363399 @089628 @123456 LAST -------Weaver Weaver Weaver Weaver Weaver FIRST -------Bobbie Doug Iraj Joseph Ronald street ---------------53 Amburn Rd 84 Park Ave 232 S River St 494 Sunbury Rd 972 Seminary Rd city -------------Berkeley San Francisco Chicago Youngstown Boston st -CA CA IL OH MA zip natn ---------- ---94704 94134 60604 44509 02116

FIGURE 3-6 Using the COLUMN command to format the Weaver report.
1

The CLEAR command can be used to clear any existing definitions created with the COLUMN command. See Appendix E, page 324 for more options. This illustrates two uses of the COLUMN command. One uses a data column alias called first that was created in the SELECT clause to identify first name (v1_name_first). The second uses the full data column name (v1_address_street) and then assigns the heading street. Both revise the default width using the FORMAT option. For example, the report will use a width of 8 for first names (the a8 means alphanumeric data of width 8). Formats for numbers get specified differently and will be discussed later. This illustrates three ways to assign aliases to data column names. Think of an alias as a nickname for a data column. An alias provides an easy way to change the default headings in a report. Note the effect of the different ways of assigning aliases.

ch3.fm Page 40 Thursday, January 25, 2001 6:47 AM

40 | THREE SQL Basics

Creating SQL Programs

Figure 3-6 showed the final SQL program for our Weaver report. But how was that program created? And if changes are required, how would you edit the program? You can create and edit an SQL program using the SQL*Plus command called EDIT (see Appendix E, page 336). The syntax for EDIT is the word EDIT or the abbreviation ED followed by the name of the file you want to create or edit. This name can use operating system-specific pathnames (e.g., c:\my_sql\fig3-5.sql). The default file extension is sql and is optional. When you execute an EDIT command, the default editor will open, and youll be able to create, edit, and save the SQL program file. Figure 3-7 illustrates the use of the EDIT command to create and save an SQL file. In this case the default editor was Microsoft Notepad available on Windows operating systems.

FIGURE 3-7 Saving the SQL program file fig3-5.sql.

ch3.fm Page 41 Thursday, January 25, 2001 6:47 AM

THREE SQL Basics | 41

Structured Queries
Note the structure to the SQL that appeared in our Weaver example (Figure 3-6). The various SELECT clauses each begin at the far left, and each data column appears on a single line. This was done deliberately. Structuring queries makes them easier to develop, easier to test, easier to debug, and easier to revise or maintain at a later date. You can cause yourself considerable trouble if you dont provide physical structure in each query you write. Unfortunately, structure in SQL queries is largely optional, despite SQL being the Structured Query Language. As well see shortly, its possible to write some truly abominable SQL that works fine. Please dont; youll save yourself immense frustration if you take the few extra minutes to add structure to your queries. Here are some suggestions: Start each of the clauses in the left-hand margin. Use indents liberally. Place items one on a line. And in the WHERE clause, physically separate the table joins. Figure 3-8 provides structure for a query thats a little more complex than our Weaver example. For now, dont worry about the SQL; just notice the physical structure in the query.
SELECT name_id, name_last, name_first, reg_catalog_code 1 demog, name, reg reg_term = 199909 reg_status_code = RG name_id = reg_id name_last LIKE A% demog_id = reg_id 2 demog_sex = F name_last, name_first;

FROM

WHERE AND AND AND AND AND ORDER BY

FIGURE 3-8 An example of a structured SQL query.

1

Indent each data column in the SELECT clause, and place one column on a line. Do the same for the tables in the FROM clause. Keep all criteria for each table in one location in the WHERE clause. In this case, the join between DEMOG and REG and the criteria that demog_sex = F are physically located together. This makes a query easier to test, debug, and maintain.

ch3.fm Page 42 Thursday, January 25, 2001 6:47 AM

42 | THREE SQL Basics

Some modification to Figure 3-8 may work better for you. For example, the word AND is one of the reserved words known as logical operators. They affect how two or more conditions in the WHERE clause are met (see Appendix C page 265). Some people prefer to place logical operators at the end of a line of SQL rather than at the beginning. It doesnt really matter. Either version gets parsed and executed by Oracle in exactly the same way. What is important, however, is that you incorporate physical structure into your queries in some fashion. The alternative to structured queries is not pretty. Figure 3-9 shows the same SQL query as in Figure 3-8. However, it uses no structure except for the mandatory ordering of the six clauses. This SQL produces exactly the same report as the structured query. But it is very difficult to decipher. This hinders testing and increases the chances that your query will contain errors that go undetected. Please get into the habit of adding physical structure to all the queries that you write.
select name_id,name_last,name_first,reg_catalog_code from demog, name,reg where demog_id = reg_id and name_last like A% and demog_sex = F and reg_term = 199909 and reg_status_code = RG and name_id = reg_id order by name_last ,name_first;

FIGURE 3-9 An example of an unstructured SQL query.

Structure and Function

Weve looked at SQL queries from two perspectives nowas composed of Who, What, and Where functional sections and, more traditionally, as composed of the six basic clauses in the SELECT command. Lets put these two perspectives together and find out how the two are related. Figure 3-10 shows the six clauses of the SELECT command and their associated 3Ws function. Who gets defined in the FROM and WHERE clauses and, less frequently, in the HAVING clause. What gets defined in the SELECT clause and, if there are group summaries like averages, in the GROUP BY clause. The ORDER BY affects the appearance of the report, not its content. Where gets defined in the FROM and WHERE clauses.

ch3.fm Page 43 Thursday, January 25, 2001 6:47 AM

THREE SQL Basics | 43

SELECT what FROM where who WHERE who where GROUP BY what HAVING who ORDER BY ...;

1 2 3 3 2 1 3

FIGURE 3-10 SELECT command clauses and their function.

1

The SELECT and GROUP BY clauses define the What of a query by identifying the data columns, expressions, and group summaries that will appear in the report. The Where in a query gets defined in those portions of the FROM and WHERE clauses needed solely to access the What data items not already accessible via the Who definition. Those portions of the FROM and WHERE clauses which specify the report population define the Who in a query. When group summaries appear in the report, you can further define the Who with the HAVING clause to limit the groups.

I Exercises
1. The FROM and the WHERE clauses of the SELECT command each perform two of the 3Ws functions. What are those functions? 2. When you start writing an SQL query, where do you start? 3. What structure does SQL compel a query writer to use? 4. Why is additional structure necessary in an SQL query?

ch3.fm Page 44 Thursday, January 25, 2001 6:47 AM