関係代数は集合論に基づいており、データベースの論理の基礎です。
データベースとSQLの構造を研究していたとき、リレーショナル代数の予備知識は、さらなる知識が私の頭に正しく当てはまるのを本当に助けてくれました。この記事で同様の効果を生み出そうと思います。
したがって、この分野でトレーニングを開始する場合、または興味を持ち始めた場合は、猫の下でお願いします。
リレーショナルデータベース
最初に、すべてのアクションを実行するリレーショナルデータベースの概念を紹介します。
リレーショナルデータベースは、データベースに格納する必要があるすべての情報を含む一連の関係です。 この定義では、関係という用語に興味がありますが、今のところは厳密な定義なしで関係をそのままにしておきましょう。
製品テーブルを想像してください。
製品表
| ID | NAME | 会社 | 価格 |
| 123 | クッキー | LLC「ダークサイド」 | 190 |
| 156 | お茶 | LLC「ダークサイド」 | 60 |
| 235 | パイナップル | OJSC「フルーツ」 | 100 |
| 623 | トマト | LLC「野菜」 | 130 |
テーブルは4行で構成され、テーブルの行はリレーショナル理論のタプルです。 多数の順序付けられたタプルは、リレーションと呼ばれます。
関係を定義する前に、別の用語-ドメインを紹介します。 テーブルに関連するドメインは列です。
明確にするために、関係の厳密な定義を導入します。
N個のセットD1、D2、...を指定します。 Dn（ドメイン）、これらのセットに対する関係Rは、<d1、d1、... dn>という形式の順序付けられたNタプルのセットです。ここで、d1はD1に属します。 セットD1、D2、.. Dnは、関係Rのドメインと呼ばれます。
タプルの各要素は、ドメインの1つに対応する属性の1つの値を表します。
関係のキー
要件に関しては、すべてのタプルが異なる必要があります。 タプルを明確に識別するために、主キーが存在します。 主キーは、特定のタプルを一意に識別する属性または最小数の属性のセットであり、追加の属性は含まれません。
主キーのすべての属性は、特定のタプルを識別するために必要かつ十分でなければならないことが理解され、キーの属性のいずれかを除外すると、識別に不十分になります。
たとえば、このようなテーブルでは、キーは1列目と2列目の属性の組み合わせになります。
DRIVERSテーブル
| 会社 | ドライバー |
| LLC「ダークサイド」 | ウラジミール |
| LLC「ダークサイド」 | マイケル |
| OJSC「フルーツ」 | ルスラン |
| LLC「野菜」 | ウラジミール |
組織には複数のドライバーが存在する可能性があり、ドライバーを一意に識別するには、「組織名」列と「ドライバー名」列の値を使用する必要があります。 このようなキーはコンポジットと呼ばれます。
リレーショナルデータベースでは、テーブルは相互接続されており、メインおよび従属として相互に関連しています。 主テーブルと従属テーブル間の接続は、主テーブルの主キー（主キー）と従属テーブルの外部キー（外部キー）を介して実行されます。
外部キーは、メインテーブルのプライマリキーである属性または属性のセットです。
この準備理論は、リレーショナル代数の基本操作に慣れるのに十分です。
リレーショナル代数演算
関係代数の主な8つの操作は、
E。Coddによって提案されました。
操作の前半は、セットの同じ操作に似ています。 一部の操作は、他の操作で表現できます。 ほとんどの操作を例とともに検討してください。
理解するために、リレーションに対する代数の演算の結果は別のリレーションであり、他の演算でも使用できることを覚えておくことが重要です。
もう1つテーブルを作成してみましょう。これは例で役立ちます。
テーブル売り手
| ID | 販売者 |
| 123 | OOO Dart |
| 156 | OJSC「バケット」 |
| 235 | CJSC「野菜ベース」 |
| 623 | JSC「会社」 |
このテーブルでは、IDはPRODUCTSテーブルのプライマリキーに関連付けられた外部キーであることに同意しましょう。
最初に、最も単純な操作、つまり関係の名前を検討します。 その結果は同じ態度になります。つまり、PRODUCTS操作を実行すると、PRODUCTS関係のコピーが取得されます。
投影
プロジェクションは、指定されたドメインからのみ関係から属性が選択される操作です。つまり、必要な列のみがテーブルから選択されます。複数の同一のタプルを取得した場合、結果の関係にはそのようなタプルのインスタンスが1つだけ残ります。
例として、IDとPRICEを選択して、PRODUCTSテーブルに予測を作成しましょう。
操作構文：
π （ID、価格）製品
この操作の結果、次の比率が得られます。
| ID | 価格 |
| 123 | 190 |
| 156 | 60 |
| 235 | 100 |
| 623 | 130 |
サンプリング
選択は、指定された条件を満たすテーブル内の多くの行を選択する操作です。 条件には、任意の論理式を使用できます。
たとえば、価格が90を超えるテーブルから選択を行います。
操作構文：
σ （価格> 90）製品
| ID | NAME | 会社 | 価格 |
| 123 | クッキー | LLC「ダークサイド」 | 190 |
| 235 | パイナップル | OJSC「フルーツ」 | 100 |
| 623 | トマト | LLC「野菜」 | 130 |
選択条件では、任意の論理式を使用できます。 価格が90を超え、アイテムIDが300未満の別の選択を行います。
σ （価格> 90 ^ ID <300）製品
| ID | NAME | 会社 | 価格 |
| 123 | クッキー | LLC「ダークサイド」 | 190 |
| 235 | パイナップル | OJSC「フルーツ」 | 100 |
互換性のある投影および選択演算子。 結果として任意の演算子がリレーションを返し、そのリレーションを引数として使用するため、これを行うことができます。
製品の表から、110より安い製品を販売するすべての企業を選択します。
π 会社 σ （価格<100）製品
乗算
乗算またはデカルト積は、2つの関係で実行される操作であり、その結果、2つの初期関係からすべてのドメインとの関係を取得します。 これらのドメインのタプルは、初期関係からのタプルのすべての可能な組み合わせになります。 例がより明確になります。
PRODUCTSおよびSELLERSテーブルのデカルト積を取得します。
操作構文：
製品×販売者
これら2つのテーブルのドメインIDが同じであることに気付くかもしれません。 このような状況では、同じ名前のドメインは、以下に示すように、対応する関係の名前の形式でプレフィックスを受け取ります。
簡潔にするために、完全なリレーションではなく、条件IDが235未満のサンプルを乗算します
（同じタプルが色で強調表示されます）
| PRODUCTS.ID | NAME | 会社 | 価格 | SELLERS.ID | 販売者 |
| 123 | クッキー | LLC「ダークサイド」 | 190 | 123 | OOO Dart |
| 156 | お茶 | LLC「ダークサイド」 | 60 | 156 | OJSC「バケット」 |
| 123 | クッキー | LLC「ダークサイド」 | 190 | 156 | OJSC「バケット」 |
| 156 | お茶 | LLC「ダークサイド」 | 60 | 123 | OOO Dart |
この操作の使用例については、価格が90未満のセラーを選択する必要があることを想像してください。製品がない場合、最初に最初のテーブルから製品IDを取得し、次に2番目のテーブルからこれらのIDを使用して目的のSELLER名を取得し、製品を使用してこのクエリを取得します：
π （ 売り手 ） σ （RODUCTS.ID = SELLERS.ID ^価格<90）製品×
販売者この操作の結果、次の比率が得られます。
ミックスとナチュラルミックス
結合操作は投影操作の反対であり、2つの既存の関係から新しい関係を作成します。 新しいリレーションは、最初のリレーションと2番目のリレーションのタプルを連結することによって取得されますが、指定された属性の値が一致するリレーションは連結されます。 特に、PRODUCTSとSELLERSの関係を組み合わせる場合、これらの属性はドメインIDの属性になります。
また、明確にするために、2つの操作の結果として接続を想像できます。 まず、ソーステーブルの積を取得し、結果の関係から、同じドメインの属性が等しいという条件で選択を行います。 この場合、条件はPRODUCTS.IDとSELLERS.IDが等しいことです。
PRODUCTSとSELLERSのリレーションシップを組み合わせて、リレーションシップを取得してみましょう。
| PRODUCTS.ID | NAME | 会社 | 価格 | SELLERS.ID | 販売者 |
| 123 | クッキー | LLC「ダークサイド」 | 190 | 123 | OOO Dart |
| 156 | お茶 | LLC「ダークサイド」 | 60 | 156 | OJSC「バケット」 |
| 235 | パイナップル | OJSC「フルーツ」 | 100 | 235 | CJSC「野菜ベース」 |
| 623 | トマト | LLC「野菜」 | 130 | 623 | JSC「会社」 |
自然な接続も同様の関係を受け取りますが、データベーススキーマが正しく構成されている場合（この場合、PRODUCTS IDテーブルのプライマリキーはSELLERS IDテーブルの外部キーに関連付けられています）、結果の関係には1つのIDドメインが残ります。
操作構文：
製品⋈販売者;
次のような態度を取ります。
| PRODUCTS.ID | NAME | 会社 | 価格 | 販売者 |
| 123 | クッキー | LLC「ダークサイド」 | 190 | OOO Dart |
| 156 | お茶 | LLC「ダークサイド」 | 60 | OJSC「バケット」 |
| 235 | パイナップル | OJSC「フルーツ」 | 100 | CJSC「野菜ベース」 |
| 623 | トマト | LLC「野菜」 | 130 | JSC「会社」 |
交差点と減算。
交差演算の結果は、完全に両方のリレーションの一部であるタプルで構成されるリレーションです。
減算の結果は、最初の関係のタプルであり、2番目の関係のタプルではないタプルで構成される関係になります。
これらの操作はセットの同じ操作に似ているため、詳細にペイントする必要はないと思います。
情報源
- データベースの使用と設計の基本-V. M. Ilyushechkin
- 講義コースデータベースの概要-スタンフォード大学ジェニファーウィドム
理性的なコメントに感謝します