Thus far, our queries have only accessed one table at a time.
Queries can access multiple tables at once, or access the same
table in such a way that multiple rows of the table are being
processed at the same time. Queries that access multiple tables
(or multiple instances of the same table) at one time are called
<firstterm>join</firstterm> queries. They combine rows from one table
with rows from a second table, with an expression specifying which rows
are to be paired. For example, to return all the weather records together
with the location of the associated city, the database needs to compare
the <structfield>city</structfield>
column of each row of the <structname>weather</structname> table with the
<structfield>name</structfield> column of all rows in the <structname>cities</structname>
table, and select the pairs of rows where these values match.<footnote>
ここまでの問い合わせは、一度に1つのテーブルにのみアクセスするものでした。
問い合わせは、一度に複数のテーブルにアクセスすることも、テーブル内の複数行の処理を同時に行うようなやり方で、1つのテーブルにアクセスすることも可能です。
一度に複数のテーブル(または同一テーブルの複数インスタンス)にアクセスする問い合わせは、結合問い合わせと呼ばれます。
それらは1つのテーブルからの行を2つ目のテーブルからの行と、どの行同士を組み合わせるかを指定する式により、結び付けます。
例えば、すべての気象データを関連する都市の位置情報と一緒にすべて返すためには、データベースはweather
テーブルの各行のcity
列を、cities
テーブルの全ての行のname
列と比較することが必要です。
[4]
This would be accomplished by the following query:
これは、以下の問い合わせによって行うことができます。
SELECT * FROM weather JOIN cities ON city = name;
city | temp_lo | temp_hi | prcp | date | name | location ---------------+---------+---------+------+------------+---------------+----------- San Francisco | 46 | 50 | 0.25 | 1994-11-27 | San Francisco | (-194,53) San Francisco | 43 | 57 | 0 | 1994-11-29 | San Francisco | (-194,53) (2 rows)
Observe two things about the result set: この結果について2つのことに注目してください。
There is no result row for the city of Hayward. This is
because there is no matching entry in the
<structname>cities</structname> table for Hayward, so the join
ignores the unmatched rows in the <structname>weather</structname> table. We will see
shortly how this can be fixed.
Hayward市についての結果行がありません。
これはcities
テーブルにはHaywardに一致する項目がないからで、結合の際にweather
テーブル内の一致されなかった行は無視されるのです。
これをどうしたら解決できるかは、しばらく後で説明します。
There are two columns containing the city name. This is
correct because the lists of columns from the
<structname>weather</structname> and
<structname>cities</structname> tables are concatenated. In
practice this is undesirable, though, so you will probably want
to list the output columns explicitly rather than using
<literal>*</literal>:
都市名を持つ2つの列があります。
weather
テーブルとcities
テーブルからの列のリストが連結されるため、これは正しい動作です。
しかし実際には、これは望ましい結果ではないため、*
を使わずに、明示的に出力列のリストを指定することになるでしょう。
SELECT city, temp_lo, temp_hi, prcp, date, location FROM weather JOIN cities ON city = name;
Since the columns all had different names, the parser automatically found which table they belong to. If there were duplicate column names in the two tables you'd need to <firstterm>qualify</firstterm> the column names to show which one you meant, as in: 列がすべて異なる名前だったので、パーサは自動的にどのテーブルの列かを見つけることができました。 2つのテーブルで列名が重複している場合は、以下のようにどちらの列を表示させたいかを示すために列名を修飾しなければなりません。
SELECT weather.city, weather.temp_lo, weather.temp_hi, weather.prcp, weather.date, cities.location FROM weather JOIN cities ON weather.city = cities.name;
It is widely considered good style to qualify all column names in a join query, so that the query won't fail if a duplicate column name is later added to one of the tables. 結合問い合わせではすべての列名を修飾するのが良いやり方であると一般に考えられています。 そうすれば、テーブルのいずれかに後で重複する名前を持つ列が追加されても、問い合わせが失敗しません。
Join queries of the kind seen thus far can also be written in this form: ここまでに示したような結合問い合わせは、以下のような形で表すことができます。
SELECT * FROM weather, cities WHERE city = name;
This syntax pre-dates the <literal>JOIN</literal>/<literal>ON</literal>
syntax, which was introduced in SQL-92. The tables are simply listed in
the <literal>FROM</literal> clause, and the comparison expression is added
to the <literal>WHERE</literal> clause. The results from this older
implicit syntax and the newer explicit
<literal>JOIN</literal>/<literal>ON</literal> syntax are identical. But
for a reader of the query, the explicit syntax makes its meaning easier to
understand: The join condition is introduced by its own key word whereas
previously the condition was mixed into the <literal>WHERE</literal>
clause together with other conditions.
この構文はJOIN
/ON
より以前のもので、SQL-92で導入されました。
テーブルはFROM
句に単に列挙され、比較式はWHERE
に追加されます。
この古い暗黙の構文と新しい明示的なJOIN
/ON
構文の結果は同一です。
ですが、問い合わせを読む方にしてみれば、明示的な構文の方がその意味をより理解しやすいです。
結合条件はそれ独自のキーワードにより導入されるのに対して、以前は条件は他の条件と一緒にWHERE
句の中に混ざっていました。
Now we will figure out how we can get the Hayward records back in.
What we want the query to do is to scan the
<structname>weather</structname> table and for each row to find the
matching <structname>cities</structname> row(s). If no matching row is
found we want some <quote>empty values</quote> to be substituted
for the <structname>cities</structname> table's columns. This kind
of query is called an <firstterm>outer join</firstterm>. (The
joins we have seen so far are <firstterm>inner joins</firstterm>.)
The command looks like this:
ここで、どのようにすればHaywardのレコードを得ることができるようになるのかを明らかにします。
実行したい問い合わせは、weather
をスキャンし、各行に対して、cities
行に一致する行を探すというものです。
一致する行がなかった場合、cities
テーブルの列の部分を何らかの「空の値」に置き換えたいのです。
この種の問い合わせは外部結合と呼ばれます。
(これまで示してきた結合は内部結合です。)
以下のようなコマンドになります。
SELECT * FROM weather LEFT OUTER JOIN cities ON weather.city = cities.name;
city | temp_lo | temp_hi | prcp | date | name | location ---------------+---------+---------+------+------------+---------------+----------- Hayward | 37 | 54 | | 1994-11-29 | | San Francisco | 46 | 50 | 0.25 | 1994-11-27 | San Francisco | (-194,53) San Francisco | 43 | 57 | 0 | 1994-11-29 | San Francisco | (-194,53) (3 rows)
This query is called a <firstterm>left outer join</firstterm> because the table mentioned on the left of the join operator will have each of its rows in the output at least once, whereas the table on the right will only have those rows output that match some row of the left table. When outputting a left-table row for which there is no right-table match, empty (null) values are substituted for the right-table columns. この問い合わせは左外部結合と呼ばれます。 結合演算子の左側に指定したテーブルの各行が最低でも一度出力され、一方で、右側のテーブルでは左側のテーブルの行に一致するもののみが出力されるからです。 右側のテーブルに一致するものがない、左側のテーブルの行を出力する時、右側のテーブルの列は空の値(NULL)で置換されます。
<title>Exercise:</title> 練習: There are also right outer joins and full outer joins. Try to find out what those do. 右外部結合や完全外部結合も存在します。 これらが何を行うかを考えてください。
We can also join a table against itself. This is called a
<firstterm>self join</firstterm>. As an example, suppose we wish
to find all the weather records that are in the temperature range
of other weather records. So we need to compare the
<structfield>temp_lo</structfield> and <structfield>temp_hi</structfield> columns of
each <structname>weather</structname> row to the
<structfield>temp_lo</structfield> and
<structfield>temp_hi</structfield> columns of all other
<structname>weather</structname> rows. We can do this with the
following query:
テーブルを自分自身に対して結合させることができます。
これは自己結合と呼ばれます。
例として、他の気象データの気温範囲内にある気象データを全て取り出すことを考えます。
weather
各行のtemp_lo
とtemp_hi
を、他のweather
行のtemp_lo
とtemp_hi
列とを比較しなければなりません。
以下の問い合わせを使用して行うことができます。
SELECT w1.city, w1.temp_lo AS low, w1.temp_hi AS high, w2.city, w2.temp_lo AS low, w2.temp_hi AS high FROM weather w1 JOIN weather w2 ON w1.temp_lo < w2.temp_lo AND w1.temp_hi > w2.temp_hi;
city | low | high | city | low | high ---------------+-----+------+---------------+-----+------ San Francisco | 43 | 57 | San Francisco | 46 | 50 Hayward | 37 | 54 | San Francisco | 46 | 50 (2 rows)
Here we have relabeled the weather table as <literal>w1</literal> and
<literal>w2</literal> to be able to distinguish the left and right side
of the join. You can also use these kinds of aliases in other
queries to save some typing, e.g.:
ここで、結合の左側と右側を区別できるように、weatherテーブルにw1
とw2
というラベルを付けています。
また、入力量を省くために、他の問い合わせでもこの種の別名を使用できます。
以下に例を示します。
SELECT * FROM weather w JOIN cities c ON w.city = c.name;
You will encounter this style of abbreviating quite frequently. こういった形の省略はかなりよく行われます。
[4] This is only a conceptual model. The join is usually performed in a more efficient manner than actually comparing each possible pair of rows, but this is invisible to the user. これは概念的なモデルでしかありません。 実際の結合は通常、1つひとつの行の組み合わせを比べるよりも、もっと効率的な方法で行われます。 しかし、これはユーザからはわかりません。