DB設計について②

Posted at 2024-12-03

論理設計と物理設計

前回に引き続き、DBの基本知識を学習している
今回は論理設計と内部設計のポイントについてまとめる

論理設計→物理設計の順に設計する
論理設計「物理層の制約にとらわれない」ため論理設計が先立つ

エンティティの抽出
エンティティは日本語訳で「実体」
データベースだと、実体ではなく概念でもデータになるものであればエンティティ
どのようなエンティティが必要になるのか抽出するのが第１ステップ
エンティティの定義
各エンティティがどのようなデータ（「属性」）を保持するかを決める
リレーショナルデータベースだと、どのような「属性」＝「列」をもつか定義する
特に重要なのは「キー(key)」と言う列を定義すること
正規化
システムでの利用がスムーズに行えるよう整理する作業
更新が整合的に行えることが重要な目的
EーR図の作成
大量のエンティティ同士の関係を把握するため

データベースに保管されるデータは業務の期間データなので失うことは許されない
可能な限り高い耐障害性を持つようにシステムを構築する必要がある
ここで登場する技術がRAID(Redundant Array of Independent Disks)である

RAIDとは
複数のディスクを束ねて仮想的に1つのストレージとする技術
メリット
冗長化→複数のディスクに同じデータを書き込むことで一本が壊れても保全できる
性能向上→データを分散して保持するのディスクI/Oが分散される
RAIDの種類
RAID0：複数のディスクにデータを分散。しかし、1つ壊れたら復元は不可
RAID1：2本のディスクに全く同じデータを保持、信頼性UPだが性能は変化なし
RAID5：最低3本で構成し、データとともに「パリティ」を格納
RAID10：RAID1とRAID0の組み合わせ、信頼性/性能UPだがコストも高い

RAIDグループを適用して、どのディスクに配置するかを考える

データファイル
データベースに格納するデータを保持するためのファイル
業務アプリがSQLを通じて参照および更新を行う
インデックスファイル
テーブルに作成されたインデックスが格納されるファイル
DBMSではテーブルととインデックスは普通異なるファイルとして管理される
システムファイル
DBMSの内部管理用に使われるデータを格納する
基本的に業務アプリケーションやユーザーがアクセスすることはない
一時ファイル
DBMS内部での一時的なデータを格納するために使う
例えば、サブクエリを展開したデータやGROUP BYやDISTINCTを利用したソートデータ
処理が終了すれば削除されてなくなるので継続的にサイズ増加はしない
ログファイル
別名はトランザクションファイルと呼ぶ
データファイルに反映が終われば不要になる

	用途	ユーザーからのアクセス	データ量の継続的増加	性能の考慮レベル
データファイル	テーブルデータの格納	有(テーブル経由)	有	高
インデックスファイル	インデックスの格納	有（インデックス経由）	有	高
システムファイル	管理用データの格納	原則無し（DBAのみ有）	有	低
一時ファイル	一時データの格納	無	無	高
ログファイル	更新ログの格納	無	無	中