リレーショナルデータベース（以下、RDB）では、格納されたデータを全て
リレーション（関係）として表現する。実際はリレーションという表現はあまり使われず、表（テーブル）と呼ぶ。《顧客表》
顧客番号 顧客名 顧客電話番号 担当者 1 清水商事 052-xxx-xxx 佐々木 2 渡辺スポーツ 052-xxx-xxx 加藤 3 山田文具店 052-xxx-xxx 杉村 4 Lady's Shop 朝倉 052-xxx-xxx 杉村 5 荒井建設 058-xxx-xxx 杉村 6 安藤工務店 058-xxx-xxx 間野 表には１つ以上の（縦方向の）
列（カラム）がある。顧客名は１つの列である。当たり前だが、顧客名の列には顧客の名前を格納し、顧客電話番号の列には顧客の電話番号を格納する。顧客名の列に製品名を入れたり、住所を入れたりはしない。（データの内容を保障する）
表には、ゼロ個以上の（横方向の）行（タプルまたはロー）がある。そして、１つの行は各列について値を持っている。例えば「清水商事」という顧客に関するデータが１つの行で、顧客番号の列の値は「１」、顧客名の列の値は「清水商事」、電話番号の列の値は「052-xxx-xxx」、担当者の列の値は「佐々木」である。
RDBでは、データを全てこのような表の形で表現する。元のデータが表の形式であるだけでなく、様々な操作を行った結果についても、表の形で表現されるのが大きな特徴である。
RDBに対する基本的な操作として、「選択」「射影」「結合」という３つの操作がある。
(1) 選択
選択は、
表から一部分の行を（横方向に）取り出す操作である。取り出した結果も表形式になる。《選択を行った表（結果）》
顧客番号 顧客名 顧客電話番号 担当者 3 山田文具店 052-xxx-xxx 杉村 4 Lady's Shop 朝倉 052-xxx-xxx 杉村 5 荒井建設 058-xxx-xxx 杉村 (2) 射影
射影は、
表から一部分の列を（縦方向に）取り出す操作である。取り出した結果も表形式になる。《射影を行った表（結果）》
顧客名 担当者 清水商事 佐々木 渡辺スポーツ 加藤 山田文具店 杉村 Lady's Shop 朝倉 杉村 荒井建設 杉村 安藤工務店 間野 (3) 結合
結合は、
２つ以上の表から関連のあるものをつないで新しい表を作り出す操作である。例えば顧客からの受注データを格納する「注文表」を、次のように想定する。《注文表》
注文番号 顧客番号 注文日 製品名 単価 数量 金額 101 2 3/15 TV451 78,650 5 393,250 102 2 3/15 TV551 97,230 2 291,690 103 3 3/16 クリーンHS33 11,550 3 34,650 104 5 3/17 明灯S40 350 40 14,000 105 1 3/17 チルド335 143,400 1 143,400 顧客についての情報（データ）は顧客表に格納されているので、注文表には顧客を表す「顧客番号」だけを格納することにする。この時、注文表の顧客番号を
外部キー（FOREIGN KEY）と呼び、顧客表の顧客番号を主キー（PRIMARY KEY）と呼ぶ。外部キーには必ず対応する主キーが存在する（注文には必ず顧客の情報が必要ということ）。このような条件のことを参照制約と呼び、これらが必ず守られるようにRDBを構成することもできる。
顧客に関する情報が必要な場合は、注文表の外部キーと顧客表の主キーの値が同じ行同士を並べた新しい表を作成する。この操作を結合と呼ぶ。《顧客表と注文表を結合した表》
顧客番号 顧客名 顧客電話番号 担当者 注文番号 注文日 製品 単価 数量 金額 2 渡辺スポーツ 052-xxx-xxx 加藤 101 3/15 TV451 78,650 5 393,250 2 渡辺スポーツ 052-xxx-xxx 加藤 102 3/15 TV551 97,230 2 291,690 3 山田文具店 052-xxx-xxx 杉村 103 3/16 クリーンHS33 11,550 3 34,650 5 荒井建設 058-xxx-xxx 杉村 104 3/17 明灯S40 350 40 14,000 1 清水商事 052-xxx-xxx 佐々木 105 3/17 チルド335 143,400 1 143,400 結合によって、注文と顧客の情報を同時に得ることができる。RDBでは、個々の表は必要最小限の情報のみを保持するように設計する。
関連する情報は外部キーによって参照し、結合によって情報を取り出す。RDBでは結合が多用されるため、結合の性能が非常に重要になる。
必要最小限になった表を
正規形と呼び、その状態にすることを正規化と呼ぶ。例として、顧客表に顧客担当者の電話番号を追加することを想定する。《担当者電話番号を追加した顧客表》
顧客番号 顧客名 顧客電話番号 担当者 担当者電話番号 1 清水商事 052-xxx-xxx 佐々木 1432-1098 2 渡辺スポーツ 052-xxx-xxx 加藤 1432-1095 3 山田文具店 052-xxx-xxx 杉村 1432-1234 4 Lady's Shop 朝倉 052-xxx-xxx 杉村 1432-1234 5 荒井建設 058-xxx-xxx 杉村 1432-1234 6 安藤工務店 058-xxx-xxx 間野 1432-1056 この表では、杉村氏の電話番号が重複して出現する。仮に杉村氏の電話番号が変更になった場合、３箇所とも正しく更新しなければならない。この表は必要最小限な状態ではないので、正規形とはいえない。正規形にした表は次のとおりである。
《正規形にした顧客表》
顧客番号 顧客名 顧客電話番号 担当番号 1 清水商事 052-xxx-xxx 501 2 渡辺スポーツ 052-xxx-xxx 502 3 山田文具店 052-xxx-xxx 503 4 Lady's Shop 朝倉 052-xxx-xxx 503 5 荒井建設 058-xxx-xxx 503 6 安藤工務店 058-xxx-xxx 504 《担当者表》
担当番号 担当者名 担当者電話番号 501 佐々木 1432-1098 502 加藤 1432-1095 503 杉村 1432-1234 504 間野 1432-1056 表が正規化されていれば、データの更新が容易になり、間違いも少なくなる。ただし、人間にとって理解しやすい表現であるとはいえない。エンドユーザや業務アプリケーションが使いやすいように、必要な結合や選択、射影を行った表を
ビューと呼ばれる形で保存しておくことができる（ビューの表が実際に物理的に存在していることは少なく、通常はビューが使用されるたびに、RDBシステム内部で仮想的な表が作られる）。
また、結合にはかなりの処理時間がかかる。このため実際のRDB設計では、表を正規化したあとで、性能を上げるために特定の表だけわざと正規形でない形にすることができる。
RDBの特徴について簡単に説明する。
- 1.シンプルな構造で理解しやすい
- RDBの構造は表形式で、非常に簡単で理解しやすいものである。これがRDBの最大の特徴である（ただし、RDBMSが実際にディスク上で管理しているデータは、もっと複雑である）。
- 2.SQL
- RDBがここまで普及した理由のもう１つが、標準化されたデータベースアクセス言語である
SQLの存在である。SQLにより、どのRDBMS製品であっても同じようにデータベースにアクセスできるようになった。- 3.理論による裏づけ
- 1970年にE.F.Codd氏がリレーショナルモデルについての論文を発表し、その後、多くの人が関連する論文を発表して理論が完成した。りろんの裏づけがあるため、例えば最適化や並列処理を行った場合でも、結果が正しくなることを確認できる。
- 4.物理構造／論理構造からの独立とスキーマ
- データベースの大きな目標は、アプリケーションがデータの物理構造／論理構造から独立することと、データベースの自己記述能力（データベース自身についての説明をデータベース自身が行うこと）を持つことである。SQLでは、物理構造を意識したデータアクセスを行うことはできないため、それらから独立したアプリケーションとなる。また、RDBMSではデータベースの論理構造は
スキーマと呼ばれる情報としてデータベース自身に格納されている。そしてスキーマへは、SQLを使ってアクセスできる。（ただし、RDBMSごとにスキーマの構造は異なっている）