システムアーキテクチャ: データベース

データベース設計

ここに画像の説明を挿入します

ステップ 出力 説明する
1. データ要件と処理要件に基づいて需要分析を実施する データフロー図、データディクショナリ、要件仕様書など データの流れやデータの詳しい意味などを分析し、具体的なニーズを分析する
2. 現実世界を抽象化し、概念的な構造を設計する ERモデル エンティティおよびエンティティ間の関係を説明するために使用されます。
3. 変換ルール、標準化理論、DBMSの特性を追加して論理構造を設計する 関係モデル データベーステーブル構造の設計
4. ハードウェア機能、OS 機能などを物理設計に追加する - 設計データの物理的な保存方法

関係代数

ここに画像の説明を挿入します

  • デカルト積: 同型写像は必要ありません。結果の列は 2 つの和 (3+3=6)、結果の行は 2 つの積 (3*3=9) です。
  • プロジェクション: 特定の列を垂直方向にフィルターし、テーブルの構造を変更します。
  • 選択: テーブル構造を変更せずに、特定の行を水平方向にフィルターします。

ここに画像の説明を挿入します

  • 自然な接続: 同型性は必要ありません。結果の列は、重複を排除するために 2 つの合計です。結果の行は、同じ名前を持つすべての属性列が同時に同じ値を持つ必要があります。式 1この図は、デカルト積 -> 選択 -> 射影を使用した場合と等価な式です。同じ操作を実装した場合、自然接続のパフォーマンスはデカルト積よりわずかに優れています。

規範理論

候補キーの検索

ここに画像の説明を挿入します
関係パターン R には、属性セット U と関数依存関係セット F という 2 つのタプルが含まれており、R(U, F) として示されます。属性セットはノードとして表され、依存関係は矢印として表されます。R は次のように変換できます。有向グラフ。
ここに画像の説明を挿入しますまず、2 種類のノードを見つけます。

  • 左側にのみ表示され、右側には表示されません。候補キーに含める必要があります。
  • 右側にのみ表示され、左側には表示されません。候補キーに含めることはできません。
    図ではCは右側にしか現れていないので候補キーには含めないでください。AのみであればBCまで辿って完了、BだけであればACまで辿って完了できます。したがって、候補キーは A と B になります (AB ではないことに注意してください)。

特殊な機能の依存関係


  1. ここに画像の説明を挿入します一部の関数が候補キーに依存しており、属性セットが複数ある場合(図の候補キーはAB)、一部の候補キーのみに依存する属性セット(CのみがAに依存する)が存在します
  2. 推移関数の依存関係ここに画像の説明を挿入します

アームストロングの公理

ここに画像の説明を挿入します

パラダイム

ここに画像の説明を挿入します

無損失分解

ここに画像の説明を挿入しますテーブル法による判定:
画像の説明を追加してください
ここに画像の説明を挿入しますまず同じ名前の属性列(生徒関係の生徒番号と学年関係の生徒番号)を見つけ、(生徒番号 -> を信頼することで名前を学年関係に復元できます) name) となり、テーブルは次のようになります: 同じ名前の次のものを探し続けます
画像の説明を追加してください属性列 (学生リレーションシップの名前と学年リレーションシップの名前) には、利用可能な依存関係はありません。 1 つ (学年関係のコース番号とコース関係のコース番号) 依存関係 (コース番号 -> コース名) を通じてコース名を変更できます。学年関係に復元すると、テーブルが変更されます
画像の説明を追加してください。すべて√の行があれば復元は成功です。

おすすめ

転載: blog.csdn.net/weixin_43249758/article/details/132434033