システムアーキテクチャ設計専門スキル・データベース設計

シリーズ記事の目次

システム アーキテクチャ設計の専門スキル · ソフトウェア エンジニアリング (1) [システム アーキテクト]
高度なシステム アーキテクチャ設計スキル · ソフトウェア アーキテクチャの概念、アーキテクチャ スタイル、ABSD、アーキテクチャ再利用、DSSA (1) [システム アーキテクト]
高度なシステム アーキテクチャ設計スキル · システム品質属性およびアーキテクチャ評価 (2) [システムアーキテクト]
システムアーキテクチャ設計の高度なスキル・ソフトウェア信頼性分析および設計 (3) [システムアーキテクト]

1. データベースの概念

1.1 データモデル

データ モデルは、階層モデル、ネットワーク モデル、オブジェクト指向モデル、リレーショナル モデルに分類されます。

データ モデルの 3 つの要素は、データ構造、データ操作、データ制約です。

データ制約には以下が含まれます:
(1) エンティティの整合性:
(2) 参照整合性:
(3) ユーザー定義の整合性:

1.2 データベースビュー

ビューは実際にはデータベースに存在しませんが、仮想テーブルです。

2. データベースモデル

データベースは一般に 3 レベル モデルを採用しており、システム開発者は、ビュー層、論理層、物理層の 3 つのレベルでの抽象化を通じて、ユーザー シールド システムの複雑さを軽減し、ユーザーとシステム間の対話を簡素化する必要があります。
データベース管理システムの観点から見ると、データベースは外部スキーマ、概念スキーマ、内部スキーマにも分類されます。

データベース システムは、概念スキーマ/内部スキーマ イメージ、および外部スキーマ/概念スキーマ イメージの 3 レベルのスキーマの間に 2 レベルのイメージを提供します。これら 2 つのレベルのイメージングにより、データベース内のデータの論理的独立性と物理的独立性が確実に高くなります。

データベースの 3 レベルのスキーマ

外部モード	概念モデル	内部モード
サブモードまたはユーザー モードとも呼ばれ、ユーザーが表示または使用するデータ部分の論理構造を記述するために使用されます。ユーザーは、データ操作ステートメントまたはアプリケーションを使用して、外部モードに従ってデータベース内のデータを操作します。	これは、データベース内のすべてのデータの論理構造と特性の説明であり、すべてのユーザーにとって共通のデータ ビューです。	これは、データの物理構造と保存方法、データベース内でデータがどのように表現されるかを説明し、すべての内部レコード タイプ、インデックス、ファイル編成方法を定義します。

データベースの 2 レベルのイメージング

論理的独立性	身体的自立
外部スキーマと概念スキーマ間のマッピングに対応します。これは、アプリケーション プログラムがデータベースの論理構造から独立していることを意味し、データの論理構造が変化しても、アプリケーション プログラムは変更されません。	概念スキーマと内部スキーマ間のマッピングに対応します。これは、アプリケーションとディスク上のデータが互いに独立していることを意味します。データの物理ストレージが変更されても、アプリケーションは変更されません

3. リレーショナルデータベース

3.1 リレーショナルモデル

データ モデルの 3 つの要素は、データ構造、データ操作、データ制約です。

関係モデル表現
形式１：
学生（学籍番号、氏名、年齢、クラス番号）

書式2：
学生（U、F）
U = {学籍番号、氏名、年齢、クラス番号}
F = {学籍番号→氏名、学籍番号→年齢、学籍番号→クラス番号}

基本概念:
順序または次数: 関係パターン内の属性の数。
候補キー (候補キー): 関係内の属性または属性グループの値であり、タプルを一意に識別します。
主キー (主キー): リレーションシップに複数の候補キーがある場合、そのうちの 1 つを主キーとして選択します。
プライマリ属性と非プライマリ属性: 候補コードを構成する属性はプライマリ属性であり、その他は非プライマリ属性です。
外部キー (外部キー): 他のリレーションシップのコードが外部キーです。
完全なコード: 関係パターンのすべての属性グループが、この関係の候補コードです。

整合性の制約:

• エンティティ整合性制約: 基本関係の主要な属性が null 値を取ることができないことを規定します。
• 参照整合性制約: リレーションシップ、主キー、または他のリレーションシップの null 値の間の参照。
• ユーザー定義の整合性制約: アプリケーション環境によって決定されます。
• 引き金：

3.1 リレーショナル演算

Union (∪) :Sに属するタプルから構成される集合です。

交差 (∩) :リレーション R と S の交差は、R に属し、同時に S にも属するタプルのセットです。

差異 (—) :リレーション R と S の差異は、R に属するがS

デカルト積 (X) :それぞれ n 列と m 列の 2 つの関係 R と S のデカルト積は、(n + m) 列のタプルのセットです。最初の n 列はリレーション R のタプルであり、最後の m 列はリレーション S のタプルであり、RXS として示されます。R と S が同じ属性名を持つ場合、リレーション名を修飾子として属性の前に追加できます。違いを示す属性名。R に K1 タプルがあり、S に K2 タプルがある場合、R と S のデカルト積は K1 X K2 タプルになります。

選択(σ) :リレーション R 内の条件を満たす行を取得します。

射影 (π) :リレーション R 内の修飾された列を取得します。

接続 (Φ) :
等価接続: 関係 R と S を選択し、その 2 つのデカルト積で属性値が等しいタプルを選択します。
自然結合: 属性列を同じ属性グループとして比較する必要があり、結果から重複する属性を削除する特別な等価結合。

3.1 リレーショナルデータ設計の基本理論

リレーショナル データベース設計の目標は、システム内の情報ストレージの冗長性を減らしながら情報への簡単なアクセスを可能にする、適切でパフォーマンスの高いリレーショナル スキーマのセットを生成することです。

3.1.1 機能の依存関係

R (U, F) を属性 U の関係パターンとします。X と Y は U の部分集合で、r は R の任意の関係です。任意の 2 つのタプル u, v の場合、r に u[ Y がある限り、 ] = v[Y] の場合、X 関数は Y に依存する、または Y 関数は X に依存すると言われ、X → Y と表されます。これは関数依存と呼ばれます。
例：学籍番号→学科番号、学科番号→学科名

3.1.2 キー/候補キー

• プライマリ属性と非プライマリ属性: 候補コードを構成する属性はプライマリ属性であり、その他は非プライマリ属性です。

候補となるキーインスタンスを見つける

• 関係パターンの機能依存関係を「有向グラフ」の形式で表現します。
• 次数 0 の属性を見つけ、この属性セットを開始点として使用して、有向グラフの走査を試みます。グラフ内のすべてのノードが正常に走査できた場合、この属性セットはリレーショナル パターンの候補キーになります。
• 入次数 0 の属性セットがグラフ内のすべてのノードを横断できない場合は、いくつかの中間ノード (入次数と出力次数の両方を持つノード) を入次数の属性セットに組み込む必要があります。セットがすべてのノードを横断できるようになり、セットが候補キーになるまで 0 から始まります。
  

3.1.3 関数依存性の公理（アームストロングの公理）

既知の関数の依存関係から、他の関数の依存関係を推定するには、一連の推論ルールが必要です。これらのルールは、「アームストロングの公理」と呼ばれることがよくあります。

関係 R (U, F)、U が関係モデル R の属性セット、F が U の関数依存関係のセットであると仮定すると、次の 3 つの推論規則が存在します。 (1) 再帰法則: if Y ⊆
X ⊆ U、すると X → Y はF
(2)増補法則: Z ⊆ U かつ X → Y が F に含意される場合、XZ → YZ はF
(3)推移法則: X → Y、Y → Z が F に含意され、X → Z がF

上記の推論規則によれば、次の 3 つの規則が推定できます。
(1)結合規則: X → Y、X → Z の場合、X → YZ は F によって暗示されます。
(2)擬似推移則： X → Y、WY → Z の場合、 F
(3)分解規則:Y , Z ⊆ Y の場合、X → Z は F によって暗黙的に解釈されます。

証明は次のとおりです。

3.1.4 正規化理論

リレーショナルデータベースの設計手法の一つとして、適切なパラダイムモデルを満たすことが挙げられますが、通常、モデルの標準化度は、分解したモデルがいくつのパラダイムに到達するかによって評価できます。通常の形式には、1NF、2NF、3NF、BCNF、4NF、5NF が含まれます。

仕様レベルの向上はどのような影響をもたらしますか?

(1)第一正規形 (1NF) :リレーショナル スキーマ R において、すべてのフィールドに原子値のみが含まれる場合、つまり各属性が分割不可能なデータ項目である場合に限り、リレーショナル スキーマ R は第一正規形に属します。

例: 以下は 1NF を満たしておらず、上級専門職の称号の数はさらに教授と准教授に分けることができます。

(2)第 2 正規形 (2NF) :リレーショナル スキーマ R ∈ 1NF で、各非主属性が主キーに完全に依存する (部分的な依存がない) 場合、リレーショナル スキーマ R は第 2 正規形に属します。

例: 以下は 2NF を満たしておらず、コース番号には単位を含めることができます。

(3)第 3 正規形 (3NF) :関係パターン R ∈ 2NF であり、主キーに対する非主属性の推移関数依存性がない場合。この場合、関係パターン R は第 3 正規形に属します。

例: 以下の場合は 3NF を満たさず、部署名と部職は部番に依存します。

(4) BC 標準形式 (BCNF) : R が関係パターン、 Fがその依存関係セットであり、F の各依存関係の行列式に R の特定の候補コードが含まれなければならない場合に限り、R が BCNF に属するとします。

例えば：

3.1.5 パターン分解（機能の依存関係を維持するかどうか、ロスレスにするかどうか）

4. データベース設計

データベース設計の基本的な手順は、ユーザーニーズ分析、概念構造設計、論理構造設計、物理構造設計、データベース導入段階（アプリケーション設計）、運用・保守に分かれます。

4.1 構造設計の概念

4.2.1 ERモデル

ER モデルは ER 図 と呼ばれ、概念的な世界を記述し、概念モデルを確立するための実用的なツールです。ER 図の 3 つの要素:
(1) エンティティ: 四角形で表され、ボックス内にエンティティの名前がマークされます。
(2) 属性: 楕円グラフィックで表され、線でエンティティと接続されます。
(3) エンティティ間の関係: ひし形のボックスで表され、ボックス内に連絡先の名前がマークされ、ひし形のボックスと関連するエンティティが線で結ばれ、線で連絡先の種類が示されます。

4.2.2 ER 図における 2 つの異なるエンティティ間の関係:

4.2.3 概念構造設計のプロセス:

• 統合方法:
  複数のローカル ER 図を
  一度に統合し、段階的に統合する方法と、2 つのローカル ER 図を累積的に統合する方法。

• 統合によって引き起こされる競合とその解決策:
  属性の競合: 属性ドメインの競合および属性値の競合を含む
  ネーミングの競合: 同名の異議および同義
  構造の競合を含む: 異なるアプリケーションで異なる抽象化を持つ統合オブジェクトや、異なるアプリケーションで同じエンティティを含む異なる部分 ER 図に含まれる属性の数と属性の順序は、まったく同じではありません。

4.2 論理構造設計

• ER 図のリレーショナル モデルへの変換
  エンティティのリレーショナル モデルへの変換
  連絡先のリレーショナル モデルへの
• リレーショナルスキーマの正規化
• 整合性制約の決定 (データの正確性の保証)
• ユーザービューの決定（データのセキュリティと独立性を向上させるため）
  データフロー図に基づいて処理プロセスのビューを決定
  ユーザービューに基づいて、さまざまなユーザーが使用するビューを決定
• アプリケーション設計

☆ エンティティ タイプはリレーションシップ モデルに変換する必要があります
☆ リレーションシップ モデルへの連絡先:

• (1) 1 対 1 の関係を
  独立した関係モデルに変換するには、両端の主キーと関係自体のプロパティをマージする 2 つの方法があります。(主キー: どちらかの端の主キー)
  マージ (どちらかの端): もう一方の主キーにマージし、独自の属性を関連付けます。(主キー: 変更しない)

• (2) 1 対多のリレーションシップを変換するには、両端の主キーとリレーションシップ自体のプロパティをマージする2 つの
  独立したリレーションシップ モードがあります。(主キー: 複数端末の主キー)
  マージ (複数端末) : 相手の主キーと関連属性をマージします。(主キー: 変更しない)

• (3)多対多の関係を
  独立した関係モデルに変換する唯一の方法は、両端の主キーと関係自体のプロパティをマージすることです。(主キー: 両端の主キーの組み合わせキー)

4.3 同時実行性の制御

4.3.1 トランザクションの ACID 特性

4.4 データベースのセキュリティ

4.5 データベースのバックアップとリカバリ

4.6 データベースのパフォーマンスの最適化

1. アプリケーションとデータベース間の対話

1.NoSQLデータベース

SQL なし (SQL だけではない): インターネット Web 2.0 Web サイトの台頭により、従来のリレーショナル データベースは Web 2.0 Web サイト、特に超大規模で同時実行性の高い SNS タイプの Web 2.0 の純粋に動的な Web サイトに対応できなくなり、危険にさらされています。克服するのが難しい問題は数多くありますが、非リレーショナル データベースはその特性により急速に発展してきました。

	リレーショナル データベース スキーマ	NoSQLモデル
同時実行のサポート	同時実行性のサポート、低効率	高い同時実行パフォーマンス
ストレージとクエリ	リレーショナルテーブルストレージ、SQLクエリ	大規模なデータストレージと高いクエリ効率
拡張モード	上に拡大する	規格外
インデックスモード	Bツリー、ハッシュなど	キー値インデックス
応用分野	一般分野向け	特定の応用分野

分類	典型的なアプリケーションシナリオ	データ・モデル	アドバンテージ	欠点がある	例例
キーと値	コンテンツ キャッシュは主に、大量のデータの高いアクセス負荷を処理するために使用され、一部のログ システムなどでも使用されます。	Key は Value のキーと値のペアを指します。通常はハッシュ テーブルを使用して実装されます。	高速な検索速度	データは構造化されていないため、通常は文字列またはバイナリ データとしてのみ扱われます。	Redis、東京キャビネット/タイラント、ヴォルデモート、Oracle BDB
カラムストアデータベース	分散ファイルシステム	データを列クラスターに保存して、同じ列にデータをまとめて保存します	高速な検索速度、強力な拡張性、容易な分散拡張	機能は比較的限定されています	HBase、カサンドラ、リアク
文書データベース	Web アプリケーション (Key-Value と同様に、Value は構造化されていますが、データベースが Value の内容を理解できる点が異なります)	Key-Value に対応する Key-Value ペア、Value は構造化データです	データ構造の要件は厳しくなく、テーブル構造は可変であるため、リレーショナルデータベースのようにテーブル構造を事前に定義する必要はありません。	クエリのパフォーマンスは高くなく、統一されたクエリ構文が不足しています。	カウチDB、モンゴDB
グラフデータベース（グラフ）	ソーシャルネットワーク、レコメンデーションシステムなど 関係グラフの構築に重点を置く	グラフ構造	グラフ構造関連のアルゴリズムを利用します。たとえば、最短パス アドレッシング、N 次関係検索などです。	必要な情報を取得するにはグラフ全体を計算する必要があることが多く、この構造は分散クラスター ソリューションには適していません。	Neo4J、インフォグリッド、無限グラフ

1. 分散データベース

1. データベース最適化技術

1. 分散キャッシュ技術 Redis