テーブル設計の実務編

実務ではどのようにテーブル設計をしていくかについて説明します。

詳細
1. データベースの選び方
2. 業務系システムでのデータベース設計について

詳細

データベースの選び方

システムによって、使うデータベースとテーブル設計の考え方が異なります。
用途にあったものを選びます

カテゴリ	設計方針	内容
業務系のシステム	第三正規化までする。 RDBを使用する。	・正しくデータを記録する・障害時も正確にデータを戻す・横のつながりが深いデータを扱う
レポート用	正規化を崩す多次元データベース	・参照のスピード重視
ログなど	NonSQL	・記録スピードを重視・参照スピードを重視

業務系システムでのデータベース設計について

この記事では業務系システムについて考えます。

業務系システムとは
　・販売管理
　・発注管理
　・生産管理
　・給与システム
　・勘定システム
　・勘定系システム
など、企業の主にお金や物の取引を記録するために使用するシステムです。

これらのシステムは互いに密接な関係を持ちます。
「販売管理システム」で受けた受注を「生産管理システム」に送って、製造計画を作ります。
「生産管理システム」が発注製品と数量を計算して「発注管理システム」に送り業者に発注するといった形です。

これらを一つにまとめたシステムがERP（基幹系情報システム）です。

テーブル設計

テーブル設計は第三正規形までいったんします。その後実態に応じて微調整します。

DB専門家

データベーススペシャリストの試験ですと関係関数従属とか専門用語がたくさん出てきます。ですが実務では使ったことはないです。
第一正規形と第二正規形の区別も実務で意識する事はないです。

試験は細かすぎて勉強のための勉強になってしまいます。受験しないのでしたら正規形の違いや用語はそれほど細かく覚える必要はないです。

実務で１番意識するのは
　・トランザクションテーブル
　・マスタテーブル
です。

注文情報のサンプルですと
　トランザクションテーブル：注文書ヘッダ、注文書明細
　マスタテーブル　　　　　：業者マスタ、商品マスタ
という分け方となります

第三正規形

注文書のサンプルを見るとわかりますが、帳票の形が、そのまま第二正規形になっています。
・注文書ヘッダ　（注文書の上半分）
・注文書明細　　（注文書の下半分）

業務系のシステムですと、半分以上は「XXXヘッダ」と「XXX明細」の２つのテーブルをメインとして作られています。
請求書でしたら「請求書ヘッダ」と「請求書明細」となります。
業務が変わっても似たテーブル構成が多いので、１つの業務に精通したら他の業務のシステム構成も自然とわかるようになります。

トランザクションテーブルについて

トランザクションテーブルには、取引の記録など日々積み重なって増えるデータを保存します。

・データの追加が多い
・取引中のデータは頻繁に更新されるが、完了するとまったく変更されなくなる
・取引前や完了データは設計によっては削除可能

という特徴があります。
トランザクションが大容量となりそうな場合は事前に設計が必要です。
・完了後のデータは物理的にテーブルを分ける
・パーティション（テーブル内部でデータを分割して持つ）を利用して完了後のデータをわけるというのがあります。

DB専門家

データ量の増加によるパフォーマンスの劣化は、運用後常に問題となります。
対策として多いのは
・高価なサーバに切り替えていく
・バージョンアップや他製品へ変更時に過去データを削除する
というものです。

過去データを削除するというプロジェクトもしましたが、成果のわりにはたいへんすぎました。ERPはデータが業務間で密接に関係しているので、削除も事前に考えられていないと難しいです。

マスタデータ

人、製品、会社の情報を保存します。

・データの更新頻度は少ない
・削除不可

という特徴があります。

DB専門家

マスタデータで問題になるのは、同じ会社を２重に登録してしまったりという事です。重複登録すると集計時に違う会社として計算されたりとかいう問題があります。マスタデータはきれいに保つことが一番求められます。
データ量は人や会社は問題にならないですが、品目が問題になります。製造会社ですと何百万という数の品目が存在したりします。