達人に学ぶDB設計徹底指南書の学び

ここまでなんとなく先輩の設計をもとに真似してDB設計をしていたが、改めて学び直し、普段触れてこなかった部分を含めて認識をアップデートした箇所をまとめた。

参考：

データベースの役割

「データ」を整合的に保持して、いつでも簡単に利用可能な状態にしておくためのシステムが、私たちが本書でその設計技法を学ぶ「データベース」です（上記参考書籍 p.3)

日常的に扱っている情報を集約するにあたって欠かせないのが、データ。
それらを適切に標準化し、運用できるように整理して構造に落とし込むこと（機能要件）と、安定的に素早く供給するためのパフォーマンス設計（非機能要件）が価値提供に強く紐づいている。

三層スキーマモデル

データ設計をする時に考えるべきスキーマは大きく三つに分けられる。

• 外部スキーマ：ユーザーから見えるビューの世界

• 概念スキーマ：テーブルの世界
  論理設計と言われる部分。

• 内部スキーマ：ファイルの世界
  設計では物理設計と言われる部分。
  普段ビジネスロジックとクエリ、エンティティ部分だけ実装していた自分は意識してこなかった部分を扱っている。

物理設計詳細

サイジング：ストレージサイズ、CPUやメモリの性能の設定を行う。

性能問題の大半はここのI/Oネックによって引き起こされる。(p.35)

ストレージの冗長構成

RAIDという技術で定義されている。
データを失っても復旧できる仕組み。
ほとんどのレベルで、データを分散して保持しているため、システムの性能のボトルネックとなるI/Oも分散されることでパフォーマンス向上にもつながっている。
深掘りしてもそこまで今は必要なさそうだったので細かいのは割愛する。

データベースファイルの物理的な配置

・ログファイル：データ復旧と性能向上目的で、データファイルへのアクセスを一度ここを介して処理している。
・データファイル：データを保持する。
・インデックスファイル：使用するかどうかはこの内部で決められているため、開発者が意識することはない。
・システムファイル（設定ファイル）
・一時ファイル：サブクエリやgroup byなど一時処理のために使用。処理終了後に削除される。

インデックス

レコードを効率的に特定するための概念。劇的な処理の性能向上寄与している。
漠然とDDLを実行する時に書いていたが、その裏側の構造はよくわかっていなかった。
データをフルスキャンするとO(n)だが、インデックスを用いるとO(logn)となる。

どういうデータに設定すべきか？

1. 検索条件や結合条件に頻繁に使われているカラム
   Where句やjoin句に使われるカラムにインデックスを貼ると、その条件にマッチするレコードを高速に検索できる。
   注意：検索は裸のデータで行われないとインデックスが適用されないので注意。
   反例：where col_1 * 1.1 > 100 やname like ‘%soukimu%’ など
   修正例：where col_1 > 100/1.1, name like 'soukimu%'（前方一致ならOK）
2. 更新頻度の低いカラム
   更新される列値が更新されるとインデックスの値も更新する必要がある。そのため、更新時の性能が劣化してしまう。
   よって、更新が頻繁なカラムにインデックスを貼るのは逆効果。
3. カーディナリティの高い（値の種類が多い）カラム
   1. 値のバリエーションが多いほど、インデックスが絞り込みに効く。
   2. 例：ユーザーIDやメールアドレスは○。性別や都道府県は絞り込み効果が低いので△。
4. テーブル全体で分散しているカラム
   1. 特定の値に偏らず、全体的に均等にデータが分布していると、インデックスがより効果的に働く。

特にインデックスは万能ではなく、
読み取りと書き込み性能がトレードオフの関係になっているのは特に気づきとして重要だと思った。

データクレンジング

業務で利用されているデータをデータベースに落とし込める状態にする作業を指す。
まだシステムに落とされてない業務をシステム化する際にデータ設計の前に行う。

必要なこと

• 一意キーの特定
  データを集計する際に、同じユーザーなのに異なるデータとして扱われていると実態と乖離してしまう。

• 名寄せ
  異なる場所で同じデータを異なる名称で管理している場合に統一する必要がある。
  表記揺れの発生する名称、電話番号、住所などをシステムで扱う時にルールを作る。
  システム化に際して、定義を明確にすること、その抜け漏れを無くさないと困ってしまう。

具体的な経験に照らし合わせたデータ設計の意義

本を読みながら実務と照らし合わせてみて、要求としては全てに対応できる完璧なシステムを要求されるのだが、標準化としてのシステムであるため、目的に応じた必要なデータ、標準化から外すデータを分ける必要があると感じている。

例えば、今取り組んでいる、納品チームの行なっているサービス利用状況レポーティング業務の自動化。
元々はレポートによって、体裁が異なっていたり、使用される用語にブレがあった。引き継ぎのたびに説明が必要だが、標準化されていないため、対応する人が増えていく現状に際して、今まで行ってきた人が業務引き継ぐために負荷が集中してしまう。
それをレポートを統一し、出力するまでを一貫して自動で行われるようにした。これによって、誰でも同じ結果を出せる業務の再現性と安定性を生み出し、一貫した業務引き継ぎを行うことができる。

それと同時に、手作業の業務ではレポーティングする際に、別のデータ分析を目的としても使える体裁となっていたが、目的が異なるため、システム化に際しては対象から外した。

ここで改めてデータ設計をする意義をまとめると
単なるスキーマ定義ではなく、
価値ある情報を、いつでも、誰でも、同じように、確実に引き出せる状態を作ることだと捉えられた。