RDBでは、表はリレーション(relation)と呼ばれ、表の列は例えば、社員番号、氏名、保険証記号、保険証番号、保険者番号、基本給などの項目になり、これらを属性 (attribute) と呼びます。一方、表の各行は、この例の場合、それぞれの社員のデータ（社員番号：1080、氏名：加藤太郎、保険証記号：123、保険証番号：1234、保険者番号：12345678、基本給：356,000）を指しますが、この行のことはタプル (組) (tuple)もしくはレコード (record) と呼びます。リレーションRが、属性a1, a2, a3, …, an を持つとき、リレーションRの構造をR(a1, a2, a3, …, an)のようにあらわして、これをリレーションスキーマ (relation schema)と呼びます。リレーションスキーマは、RDB中にデータを格納するための枠組み、つまりデータモデルとして使われ、これに従ってリレーションに格納されるタプルは、インスタンスと言われます。なお、全ての属性値が同じ値をもつタプルがリレーションに重複して存在することは許されません。
社員番号のように、タプル中の値が一意になる属性は、それを指定すれば、唯一つのタプルを示すことができるので、タプルの検索のために使うことができます。このような属性は社員番号以外にも、保険者番号など、複数ありうるのですが、特に検索のために選ばれた属性はキーと言われます。
さて、二つのリレーション同士で、和 (union)、差 (difference)、直積 (cartesian product)といった演算を行って、新たなリレーションを作ることができます。この演算は、一般的な集合の演算（図１）に似ています。図1では、集合RとSの和、差、積、そして直積を示しています。
図１ 集合RとSの演算リレーション同士の演算については、例えば図2上段に示すような三つのリレーションR(A, B, C), S(A, B, C), T(D, E)があるとき、図2の下段にあるリレーションは、RとSの和、差、そしてRとTの直積を示します。演算の結果、同じタプルができた場合は、一つにまとめられます。なお、これ以外にも、一つのリレーションについて、指定した属性だけを残して新たなリレーションを作る射影 (projection)や、リレーション内のタプルの中で選択条件を満たすものだけを残して新たなリーションにする選択 (selection)といった演算などもあります[1]
図２ リレーション同士の演算の例さらに、二つのリレーションに対して、結合 (join)という演算を適用することができます。直積ではRとTのタプルの全ての組み合わせが新たなリレーションになりますが、結合では、Rの属性とTの属性に対して条件を与えて、新たなリレーションにします。条件はいろいろ考えられますが、例えば、Rの属性Aの値(R.A)とTの属性Dの値(T.D)が等しい値をとるときだけ、直積で生成されたタプルを採用すると、R.AとT.Dの等値結合が得られます。
以上のような、リレーションを使った演算を通じて、欲しいデータを検索する能力を持っていることがRDBの特徴です。一方で、大量なデータの中から検索処理をするたびにこれらの演算を実行すると、データを要求してから、応えが返って来るまでに長い時間がかかり、ユーザを待たせることになります。そこで、即応性を求める定型的な検索処理をするときは、あえてデータの冗長性を許してでも、検索性能を優先したリレーションを作っておき、それを使用すべきです。RDBの設計者は、融通性と効率性のバランスを考えて、実用的な設計を行うべきでしょう。
さて、地理情報システム (Geographic Information System, GIS) の多くは、汎用的なデータベース管理システム(Data Base Management System, DBMS)と連結させることによって、サーバに置かれたデータベースを複数のクライアントが同時使用することを可能にしています。そして、使われるDBMSは、点・折れ線・多角形といった、GISが必要とする幾何データ型が扱えるように、データベース操作用の言語であるSQL（注１参照）に拡張的な機能を持たせています。その仕様の多くは、SQLのマルチメディア拡張のために制定された、国際標準化機構（International Organization for Standardization, ISO）の標準 [2] と調和する、オープン地理空間コンソーシアム (Open Geospatial Consortium, OGC) が制定した実装仕様 [3] を使用しています（例：RDBMSのPostgreSQLにおけるPostGISなど）。なお、今日ではRDBの問題点を解消し、ビッグデータの管理を容易にすることなどを目的として、NoSQLと呼ばれる非リレーショナル型のデータベースシステムが実用化されています（例：Amazon DynamoDB, MongoDBなど）。
注１ SQLは Structured Query Languageの略称（頭字語）であるという説明がインターネット上などで散見されますが、ISOや日本におけるSQLの規格化に貢献してきた芝野耕司は「SQLは固有名詞である」と述べています[4]。事実、ISO規格や日本産業規格（Japanese Industry Standard, JIS）において、SQLが頭字語であることを示す記述は、実際にこれらを調べてみた限り、見当たりませんでした。
［参考文献］
[1] 北川博之・石川佳治編著、データベースシステム（改定２版）、オーム社、2020、pp.45-49
[2] ISO 13249-3: 2016, Information technology - Database languages – SQL Multimedia and Application Packages - Part 3: Spatial
[3] OGC OpenGIS Implementation Specification for Geographic Information – Simple feature access – Part1: Common architecture, 06-103r4, 2011
[4] 芝野耕司著、SQLの20年と現状および今後の展開（前編）、情報処理45巻5号、情報処理学会、2004
（2021年01月25日 初稿）