データベースシステム入門 2
前回の記事からの続き
3. データベースシステムの構成
開発者の観点: データベースは、データベースの内部システムの構造モデルである3 レベルの構造モデルを採用しています。下の図を参照してください:
3 レベルの構造モデルは、内部モデル - モデル - 外部モデルを指します。
1. 内部スキーマ: データベースには 1 つの内部スキーマしかありません. 内部スキーマは、システム内でのデータの保存と記述の詳細な処理です. たとえば、データをどのような方法で保存するか? シーケンシャルに保存するか? それともハッシュ村が荒れてるの？それともヒープストレージでしょうか？データは圧縮されていますか? 暗号化されていますか？などはすべて内部モード
2 に属します。 モード: すべてのユーザー向けのパブリック データ ビュー。データの物理的なストレージ、ハードウェア、アプリケーション、開発言語、そして開発ツール。(スキーマの詳しい説明は後述します)
3. 外部スキーマ: データベース利用者が利用するローカルデータの論理構造と特性記述 内部スキーマの範囲が広すぎるため、一部のみが記述されている可能性があります。アプリケーションに必要な外部スキーマは、さまざまなアプリケーションのニーズを反映しています。要件によってビューが簡素化され、データベースのセキュリティを確保するための強力な手段となります。
ユーザーの観点から見ると、データベースのシステム構造は次のようになります。
- シングルユーザーアーキテクチャ
- マスタースレーブ構造
- 分散構造
- クライアントサーバーアーキテクチャ
- ブラウザとアプリケーションのサーバー アーキテクチャ
4. データベースシステムの構成：
5. リレーショナルモデルのデータ構造（2番目のリスト）
リレーショナル モデル: 最も簡単に言えば、2 次元のテーブル
フィールドとして説明できます。 : 同じタイプのデータ セットの
デカルト積です。 : 与えられたフィールドのセット: D1、D2、D3、...、Dn 、これらのフィールドのデカルト積です。積は D1xD2xD3x…xDn={(d1,d2,d3…dn)|di∈Di,i=1,2,3,4…n} であり、デカルト積は次のようにみなできます。関係の領域として。
関係
: D1xD2xD3x…Dn のサブセットは、ドメイン D1、D2、D3…Dn 上の関係と呼ばれ、次のように表されます。 R (D1、D2、…、Dn) R: 関係名 n:関係
タプルの順序または次数
:関係 の各要素 (d1、d2、d3、...、dn) はタプルと呼ばれ、t は通常、属性を表すために使用されます。
テーブル内の列は属性であり、各属性に付けられた名前は属性名コード
: 1. 候補コード、関係内の特定の属性グループの値がタプルを一意に識別できる場合、その属性グループは候補コードと呼ばれます。 2. 完全なコード、(極端な場合) 関係パターン内のすべての属性グループこの関係パターンの候補コードです
6. 関係モデルと関係の関係
(リレーションシップ モデルとリレーションシップは、総称してリレーションシップと呼ばれることがよくありますが、それでも違いがあります)
- 関係モデル: 関係モデルは関係の説明です。関係モデルはタイプであり、関係は値であり、関係モデルは静的で固定されています。
- 関係: 動的であり、時間の経過とともに変化します
7. 関係の 2 つの重要な整合性の側面 - エンティティの整合性と参照整合性
1. エンティティの整合性: 関係の主な属性は空であってはなりません (null 値は次のとおりです: 知らない、存在しない、無意味) 例: 学生関係、学生 (学生番号、年齢、身長)学生番号がメイン属性 (メイン コード) の場合、学生関係フォームに記入するときに空白のままにすることはできません。
2. 参照整合性: 関係の整合性 (つまり、2 つのテーブル間の整合性) は、「外部コード」の概念につながります。例: 学生 (学生番号、年齢、専攻番号)、専攻 (専攻番号) 、専攻名) ここには 2 つの関係があり、1 つは学生関係、もう 1 つは職業関係です。学生関係では「学生番号」が主コードとなり、職業関係では「専攻番号」が主コードになります。プライマリ コードですが、学生関係にあります。関係には専門職番号の属性もありますが、これはメイン コードではありません。実際、学生関係の専門職番号は外部コードです。