データーベースの正規化（Normalization）は、アプリケーションやシステムの開発で、
データの整合性を保つ為に、最も重要な設計手法となります。
データーベースの正規化（Normalization）を知り、開発案件の現場で設計・実装する事で、
アプリケーションやシステムの安定稼働、品質向上、お客様との信頼構築に役立てましょう。
データベース設計プロセス
データーベースの正規化（Normalization）を行う前に、データベースの設計プロセスから、
理解して行きましょう。
要件分析
「新規開発案件」 または 「保守開発案件」に於いて、アプリケーションやシステムで、
- どのようなサービスや機能を実現したいのか
- どのようなデータを扱うのか
を、お客様と一緒に明確にする工程（プロセス）になります。
例として、【販売管理システム】を構築する場合、「商品情報」「顧客情報」「注文履歴」など、
どのような情報が必要になるかを洗い出す事になります。
シニアエンジニアや若手エンジニアにアドバイスとなりますが、【要件分析】のプロセスに
参画する事が出来たら、非常にラッキーで信頼関係を構築する機会だと認識して下さい。
お客様との打ち合わせに参加して、直接、お客様の声や要望を聞く事、データの登録・更新の
タイミングやコード体系を確認出来る事は、構築するアプリケーションやシステムの品質に
非常に影響します。
多くの開発現場では、【要件分析】のプロセスに参画が出来るのは、お客様から請け負った
SIベンダーのマネージャーまたはリーダーに限定する現場が多い為、もし、参画が出来たら、
率先して議事録（議事メモ）を記載する担当になる事をお勧めします。
若い頃に経験しましたが、議事録（議事メモ）を担当する事で、構築するアプリケーションや
システムに携わる業務の流れや関連する専門用語、略語を否応なしに記述する事になります。
新人当初やプロジェクトの参画当初は、当然の事ながら専門用語や略語は分からないので、
議事録（議事メモ）を作成する為に、先輩社員や協力会社のエンジニア、関係者に教わりに
行くので、大変苦労したものの、繰り返しているうちに理解を深めたものです。
また、お客様や開発現場の関係者の「言った」「言わない」のエビデンスを抑える事となり、
責任の明確化と可視化で、お客様との信頼を高める事も出来ます。
概念設計
要件分析で得た情報を基に、データの全体図（関係）を大まかに描きます。
管理すべきデータの種類（エンティティ）や、それらの関係性（リレーションシップ）を
図に表して、【関係者の意識を統一する工程（プロセス）】になります。
ここでは特別なツールは必要無く、MS ExcelやPowerPoint、MindMap、使い鳴れた
描画ツール、或いは、手書きで描いた図などをスキャンして共有しても大丈夫です。
先程、例とした【販売管理システム】の場合、「商品」「顧客」「注文」といった
「エンティティ(実態）」を四角で描き、それぞれがどのように「リレーション（関連）」
が有るかを示します。
この段階では、細かい技術的なことは気にせず、データ構造をシンプルに可視化してみましょう。
論理設計
概念設計で描いた全体像を、データベースで扱える形に具現化する工程（プロセス）です。
「エンティティ(実態）」をテーブルに、「アトリビュート（属性）」をカラムに対応させ、
データの重複や不整合を防ぐために、ここで「正規化（Normalization）」と呼ばれる手法を
用いてデータ構造を整理します。
「正規化（Normalization）」の手法により、利用するツールは異なります。
「正規化（Normalization）」は、データの重複や不整合を防ぐだけではなく、レスポンスや
運用後の可用性、拡張性、安定性を決めるとも言え、システムやアプリケーションの根源です。
構アプリケーションやシステムの基となる【コード体系】に準拠しながらビジネスを逆解析せず、
単なる「お絵描き」で論理設計を済ましている「似非（えせ）エンジニア」が非常に多いと
痛感しています。
別の記事で記載しますが、正しい「正規化（Normalization）」の手法を是非、身に付けて下さい。
物理設計
ここでは、論理設計で決めたデータ構造を、実際のデータベース管理システム（DBMS）上で、
効率的に動作をさせる為に、詳細設計を行います。
具体的には、
- データ型の選定
- インデックスの設定
- パーティショニングの検討
など、データベースのパフォーマンスやストレージを考慮した最適化を行います。
頻繁に検索されるカラムには、インデックスを設定することで、検索速度を向上が期待出来ます。
正規化（Normalization）
論理設計のところで記載しましたが、「正規化（Normalization）」は、データの重複や不整合を
防ぐだけではなく、レスポンス運用後の可用性、拡張性、安定性を決めるとも言え、システムや
アプリケーションの根源と言えます。
「正規化（Normalization）」を追求した解説は、
などの有名な文献やサイトにお任せするとして、ここでは、概要を知って頂ければと思います。
第一正規化
目的は、「属性を原子化」になります。
簡単に説明すると、同一行（同一レコード）内で、繰り返し項目を排除する意味です。
繰り返し項目を排除する事で、更新や削除時の矛盾を避け、データの正確性を保つことができます。
第二正規化
目的は、「部分関数従属の排除」になります。
簡単に説明すると、主キーが複数列（複合主キー）の場合に、キーの一部にだけ依存する列を
排除します。（冗長性の排除）
第二正規化によって、更新時の不整合が起こりにくくなります。
第三正規化
目的は、「推移的関数従属の排除」になります。
簡単に説明すると、
- 【主キー】→ 【非キー属性】 → 【他の非キー属性】
という間接的な依存関係が無いように、排除します。
第三正規化によって、データの整合性を保ち、更新・削除異常を防止します。
標準化（Standardization）
「正規化（Normalization）」を実現した後は、データの入力ルールや形式、単位、表記法などを
統一すること（標準化）を心掛けます。
標準化を実施すると、下記の内容が期待出来ます。
- データのばらつきが無くなる（例：日付の形式、文字コード、単位など）
- システム間で、データ連携をスムーズにする事が出来る
- ユーザー及びプログラマーにとって、一貫性のある使い易さを提供します
- 命名規則の一貫性は、コードの可読性と保守性を高めます。
- テーブル名やカラム名には、意味のある名前を付けることが重要です。
- スネークケース（例：long_name）やキャメルケース（例：LongName）など、命名スタイルをプロジェクト全体で統一することで、開発者間のコミュニケーションが円滑になります。
まとめ
今回、「データーベース設計プロセス」「正規化」「標準化」と解説して来ました。
最初に記載しましたが、データーベースの正規化（Normalization）を知り、開発案件の現場で
設計・実装する事で、アプリケーションやシステムの安定稼働、品質向上、お客様との信頼構築が
構築出来ると思いますが、単なる「お絵描き」で論理設計を済ましている場合は、信頼を損なう
恐れが有ります。
「正規化（Normalization）」の手法を間違えて実装している案件や現場を、数多く見て来ました。
リリース後、システムの拡張や運用管理に不要な人件費（コスト）を多く掛けているものの、
一向に改善されず、お客様やITベンダーが迷惑を被（こうむ）るのは本末転倒です。
より良い「正規化（Normalization）」の手法を身に付けて、お客様との信頼構築に
励んで頂ける事を期待します。
- いらすとや より引用
コメント