春の入門祭りの第12弾です。

自己紹介

こんにちは、TIGメディアユニットチームの川島です。

私は新卒でフューチャーに入社後、基幹系システム刷新PJのDBAからキャリアをスタートしました。その後、小売業の店舗システム刷新PJなど複数のPJで企画フェーズから導入フェーズまで幅広く経験し、現在は、人材サービス企業のクライアントの全社データ活用PJでコンサルティング業務を主として担当しています。

RDBMSについては論理から物理まで一通り経験していて、データに関わるところは強みがあると思っています。

記事の背景

DB設計のデータモデリング入門として、コンビニのレシートを使ったDB設計をやっていきます。

DB設計はよく物理と論理の両面があると言われますが、今回は論理設計について扱います。

論理設計の基本はモデリングの技法にあります。モデリングは、設計する人以外必要ないのでは？ と思われがちですが、ソフトウェア開発する上でも、または上流フェーズでシステムやサービスの提案をしていく上でも重要なスキルになります。なぜなら、モデリングはその名の通り現実を抽象化して、扱いやすい形式に起こして、他者に伝達する手法だからです。これはITエンジニアやITコンサルタント（ITプロフェッショナル）のコミュニケーションスキルの基本ともいえる部分でもあります。ただし、モデリングというととっつきづらく難しい要素もあるので、特別な道具立てもなく、身近なモノからできる例としてレシートを題材にDB設計することをやっていきたいと思います。具体的に、実務で使える内容ではないですが、ITプロフェッショナルとしての力を鍛える「素振り」と思って、取り組んでいただければ幸いです。

よりよいテーブルの設計については、今回の入門記事シリーズでも取り扱っています。ぜひそちらも合わせて勉強してみてください。
春の入門祭り 🌸 #05　データベース　テーブル設計入門

記事の対象読者

対象は、新人エンジニア・ITコンサルタントを想定しています。

題材

今回の題材は、某コンビニエンスストアのレシートを使います。

毎日のように、みなさんが見ているものだと思いますが、このような身近なものにもIT技術が使われており、当然データを格納するDBがあります。DB設計のトレーニングとして身近な帳票（レシートや請求書など、データの印刷されたもの）から、それらを支えるインフラ技術や、プログラムソースコード、DBの設計などを想像することは良い手段です。

レシート

イベント（出来事）を見つける

まずは、このレシートが表す主要な「出来事」を見出しましょう。難しく考えず、この紙が表現している行為は何かを考えてみましょう。

大きく領収書と書かれていますね。

そうすると、「領収」とか「購入」とかが思い浮かびますが、システムの所有者はコンビニエンスストア側であるので、主語はお店の側とします。すると販売とか売上になりますが、今回は売上にしましょう。

イベント系データは、トランザクションと言われることもあります。企業のビジネスはこのようなトランザクションの連なりと積み重ねで成り立っています。人間の体でいうと、血液のようなものです。

リソース（資源）を見つける

次に、売上をあげるにあたって、「誰に」「何を」という部分がないと売上という行為は完結しません。

6W2Hでもれなくダブりなくデータの種類を書き出してみましょう（5W1HにWhom、How Muchを加えた6W2Hを使うとよりもれなくダブりなく物事をとらえることができるのでおすすめです）

• Who（誰が）・・販売店、責任者
• When・・販売日時
• What（何を）・・商品
• Whom（誰に）・・会員（顧客）
• Where（どこで）・・レジ
• Why（なぜ）・・とくになし
• How（どのように）・・決済手段
• How Much（いくらで）・・商品価格、消費税、還元ポイント

全部扱うのは大変なので、 今回は一部の商品と顧客と価格、消費税について扱います。他のリソースについてもみなさんもぜひ考えてみてください。

価格と消費税（率）は商品の一部といえるので、リソースとしてはいったん商品と顧客を書き出します。

リソース系データは、マスタと言われることもあります。トランザクションが血液なら、マスタは企業のビジネスの骨格をなす部分です。
骨格のつくりがおかしいと人間がうまく背が伸びなくなるように、企業のビジネスの成長のボトルネックにもなりかねない部分なのでこの設計は非常に重要です。

項目を入れる

データの箱を用意したら、次は項目を入れていきましょう。

顧客には、コンビニエンスストアからセール情報などを郵送することを想定して、氏名と住所を入れます。
商品には、商品名と価格、税率を入れます。売上には、販売数を入れます。商品と顧客も入れるべきですが、のちのち入れていきます。

税金についてはよくみると、10％対象と8％対象のものがあります。軽減税率制度ですね。

食料品は8％、それ以外は10％対象になっています。商品マスタ上で、分類があると考えます。消費税は数年後には変わっていくものなので、商品マスタにもっていると変更するのが大変です。なので、税対象カテゴリという新しいテーブルを追加して管理することにしましょう。

※実用的には、有効期間を設定してある日を過ぎたときから税率が変わるようにすることがあります。ちょうどよい参考文献があるので、末尾に記載します。

リレーションシップを設定する

次にテーブル同士の関係性を設定していきます（リレーション）。

関係性を設定するまえに、各テーブルのデータを一意に表すPK（主キー）を設定します。
PKとして空欄にしていた部分に、IDを設定します。

この主キーに特定の項目を設定し意味をもたせると、その意味が変わったときに他のテーブルとのリレーションが変わってしまいます。そのため、機械的に○○IDもしくは○○コードなどと設定するのが妥当です。具体的には、商品マスタにおいて、商品名はそのデータを一意に表すと自然に考えられます（ナチュラルキー）が、あえて代理のキー（サロゲートキー）を設定して、意味に依存しない形にします。

そして、各テーブルを関連付ける、FK（外部キー）を設定することでリレーションシップはいったん完成です。

点検する

作成したモデルが現実をきちんと表現しているか点検をしましょう。出来上がったテーブルとリレーション（ERD)を見て、最初のレシートに立ち戻ってみましょう。

すると、このERDでは1つの売上で1種類の商品、1人の顧客しか扱えないことがわかります。1売上1顧客は良いとして、1売上で複数の商品があるのは自然なので、修正して売上テーブルを分割することを考えます。
売上明細というテーブルを作成します。

（注）FKが一部間違っていたので修正しました 6/16

今回は省きますが、加えて以下もやってみると理解が深まるでしょう。

• DDL（CREATE TABLE）を書いてテーブルをRDB（PostgreSQL,MySQL,Oracleなど）上に作成してみる
• テーブルに実データを入れてみる（事前にExcelなどで表を書いてみるのをおすすめします）
• SQLを書いて実行してみる

さいごに

データモデルのポイントは以下のとおりです。

• イベントを見つける
• リソースを見つける（6W2Hでもれなくダブりなく）
• 項目を入れる
• リレーションシップを設定する
• 点検する（モデルが現実を表現しているか）

今回はITプロフェッショナルとしての「素振りの仕方」をご紹介しました。
日頃、目にするデータから設計をする練習をして、本番の仕事のため（試合）に備えましょう。

参考文献

楽々ERDレッスン (CodeZine BOOKS) (株)スターロジック 羽生 章洋 著
レシート（帳票）からERDをつくるというアイデアはここからもらっています。DB設計の基本が書かれている良書です。

SQLで消費税の計算
マスタへの有効期間の設定・SQLの書き方など、実用的な内容が詳細に書かれています。もう一歩踏み込みたい人は読んでみてください。

業務システムのための上流工程入門 渡辺幸三 著
DB設計はお客さんとあるべきシステムのイメージの合意をとりながら進めていくものです。データ指向設計の手法が、ロールプレイング形式で具体的に書かれています。上流工程に興味のある人は読んでみてください。