記事ディレクトリ
1. 関係演算
1. 基本的な関係演算
一般的に使用されるリレーショナル操作:
クエリ (Query) 操作と挿入 (Insert)、削除 (削除)、および変更 (更新) 操作。
リレーショナル クエリは非常に表現力が豊かで、リレーショナル操作の最も重要な部分です。
クエリ操作は
、選択、投影、結合、除算、結合、例外、交差、デカルト積などに分類できます。
このうち、選択、射影、和集合、差分、デカルト積の5 つの基本演算です。
他の操作は、基本操作を使用して定義および派生できます。ちょうど乗算が加算の観点から定義および導出できるのと同じです。
リレーショナル演算の特徴は集合演算モード、つまり演算の対象と結果が両方とも集合であることです。この操作方法は、一度に設定する方法とも呼ばれます。これに対応して、非リレーショナルデータモデルのデータ操作方式は、レコード・アット・ア・タイム方式である。
2. リレーショナルデータ言語の分類
関係代数言語
関係に対する演算を使用してクエリを表現する
表現: ISBL
関係微積分言語
述語を使用してクエリ要件を表現します。
- タプル関係計算言語：述語変数の基本オブジェクトはタプル変数
代表：APLHA、QUEL - ドメイン関係計算言語: 述語変数の基本オブジェクトはドメイン変数の
代表: QBE
関係代数と関係微積分の二重の特徴を持つ言語
代表：SQL (Structured Query Language)
関係の誠実さ
リレーショナル モデルの整合性には、エンティティの整合性、参照整合性、およびユーザー定義の整合性の 3 つのタイプがあります。
このうち、エンティティの整合性と参照整合性は、リレーショナル モデルで満たさなければならない整合性制約であり、関係の 2 つの不変条件と呼ばれます。
用語の説明：
- 候補コード: 属性グループ (単一の属性をグループにすることもできます)。この属性グループの値はタプルを一意に識別できますが、そのサブセットは識別できません。
- 主属性: 候補キーの属性。
- 非コード属性: どの候補コードにも含まれない属性。
- 主コード: 候補コードが複数ある場合、そのうちの 1 つを主コードとして選択します (つまり、主コードは候補コードの 1 つです)。
- 外部キー: 属性または属性のセット。これはこのリレーションシップのキーではありませんが、別のリレーションシップの主キーです。この関係は参照関係であり、もう一方の関係は参照関係です。
1. エンティティの完全性
エンティティ整合性ルール
属性 A が基本リレーション R の主属性である場合、 A はnull 値を取ることはできません
。主キーが複数の属性で構成されている場合、これらすべての主属性が null 値を取ることはできません。
Null値：
「わからない」、「存在しない」、「意味がない」...0ではない
説明:
- エンティティの整合性に関するルールは、基礎となる関係に関するものです。基本テーブルは通常、表示世界のエンティティ セットに対応します。
- 現実世界のエンティティは区別可能です。つまり、ある種の固有のアイデンティティを持っています。
- 同様に、主キーはリレーショナル モデルの一意の識別子として使用されます。
- プライマリ コードの属性、つまりプライマリ属性は null 値を取ることができません
2. 参照整合性
参照整合性ルール
属性または属性グループ F が基本リレーション S の主キー Ks に対応する基本リレーション R の外部キーである場合 (基本リレーション R と S は必ずしも異なるリレーションであるとは限りません)、R の各タプルに対してF の値は次のとおりである必要があります。
(1) NULL 値。F の各属性値は NULL 値です。
(2) Sのタプル内の主キー値（主キー値）。
つまり、参照される関係の属性値は、参照される関係内で見つかるか、 null 値を取る必要があります。そうでない場合は、データベースのセマンティクスに準拠しません。
テーブルへのデータの更新、削除、挿入など実際の操作では、関連する他のテーブルのデータを参照することで、テーブルに対するデータ操作が正しいかどうかを確認し、正しくない場合は操作を拒否します。正しくない。
参照関係→参照関係（対象関係）
当然のことながら、ターゲット リレーション S の主キー Ks と参照リレーション R の外部キー F は同じ (または同じグループ) フィールド上に定義されなければなりません。
参照関係
同じ関係
参照整合性ルールでは、R と S は同じ関係になる可能性があります。
学生（学生番号、名前、性別、年齢、専攻番号、クラスリーダー）の関係では、「学生番号」属性が主キーとなり、「学生番号」属性は学生のクラスリーダーの学生番号を表します。クラスなので、この関係「学生番号」属性に適用されます。参照整合性の規則に従って、「分隊長」の属性は次の 2 種類の値を取ることができます。
(1) Null 値。生徒のクラスがまだモニターを選出していないことを示します。
(2) NULL 以外の値。この関係のタプルの学生 ID 値、つまりモニターに選出された学生の学生 ID 値でなければなりません。
学生エンティティと専門エンティティなどの2 つの関係は
、次の関係スキーマで表すことができます。学生番号が学生の主キーであり、専門職番号が専攻の主キーです。学生 (学生番号、名前、性別
) 、専攻番号、年齢)
専攻 (専門職
) 2 つのリレーションシップの間に属性参照があります (同じ属性「専門職番号」が含まれます)。学生リレーションシップは、専門職リレーションシップの主キー「専門職番号」を参照し、専攻番号はStudent リレーションシップの外部キー。また、参照整合性の規則によれば、学生関係 (職業関係ではない) の各タプルの「職業番号」属性は、次の 2 つの値のみを取ることができます。 (1) Null 値。専攻がその学生に割り当てられていないことを示します
。学生。
(2) null 以外の値 現時点では、その値は、学生を存在しない専攻に割り当てることができないことを示す、職業関係内のタプルの「職業番号」値である必要があります。つまり、学生関係における属性の値は、職業関係における属性の値を参照する必要があります。
3 つ以上の関係 3 つ以上の関係は参照関係を持つこともでき、学生、コース、コース (学生とコース) 間のつながりは、学生 (学生番号、氏名、性別、専攻番号、学生) の
3 つの関係で表現できます。
年齢）
専攻（専門職番号、専攻名）
コース選択（学生番号、コース番号、学年）
ここで、「学生番号」と「コース番号」属性はコース選択関係の外部キーですが、「学生番号」と「コース番号」のみが外部キーとなります。 「科目番号」「番号」を組み合わせて科目選択関係を決定できるため、ここでは複合主キー関係があり、（学生番号、科目番号）が科目選択関係の主キーとなります。参照整合性に従って 2 種類の値を取ることができますが、エンティティ整合性のため、複合主キーの各属性は null 値を取ることができません。したがって、コース選択リレーションシップの「学生番号」および「コース番号」属性は、参照先リレーションシップ（学生リレーションシップおよび専門リレーションシップ）の既存の主キー値のみを取ることができます。つまり、コース選択関係における「学生番号」の値は、実在する学生の学生番号でなければならず、学生関係にその学生の記録が存在する；コース選択関係における「コース番号」の値は、また、存在するコースのコース番号である必要があります。つまり、コース関係にそのコースのレコードが存在します。
3. ユーザー定義の整合性 (ユーザー定義の整合性)
ユーザー定義の整合性とは、特定のリレーショナル データベースに対する制約を指します。これは、特定のアプリケーションに関係するデータが満たさなければならないセマンティック要件を反映しています。
属性に対して一意の値を取る必要があり、非プライマリ属性に対して null 値を取ることができないユーザー定義の整合性は、
エンティティ整合性、ドメイン整合性、参照整合性などの整合性タイプをカバーできます。
たとえば、特定の属性は一意の値を取る必要があり、非プライマリ属性は null 値を取ることができず、特定の属性の値の範囲は 0 ～ 100 であるなどです。