データベースを設計する工程は非常に重要な工程の1つです。端的に言ってしまえば、このシステムを動かすのに何個のテーブルが必要なのかを決めることです。テーブルにはドラマの登場人物の相関図のような関連性を示すための図面があり、それをER図(Entity-Relationship-Diagram)と言います。
ER図には、ユーザーがこのシステムを利用してどんなデータをやり取りしているのかの全てが描かれています。管理したいデータがあり、それがどういう設計で保存されているかを見れば、どんな振る舞いをシステム上で行っているか、高い正確性を持って類推することが出来ます。
エンティティ(Entity)とは
テーブル設計を難しくさせている(難しく考えさせている)のが、このエンティティという概念だと考えています。エンティティとはデータベースで管理したい情報を抽象化したものです。顧客管理システムなら顧客情報になるでしょう。在庫管理なら商品と在庫です。入庫と出庫の履歴が取れないと在庫管理は出来ませんので、それらもエンティティ候補になります。
これだけではピンとこないと思いますので、エンティティの抽出の観点を列挙しておきます。
エンティティを3つの視点から抽出しよう
エンティティはこの3つの観点から抽出することをオススメします。
| 名称 | 概要 |
|---|---|
| ヒト | システムで登場する人物像 |
| モノ | システムで取り扱う資産・サービス |
| コト | システムを通じて行われる行動・出来事 |
ホテルの予約システムにおけるエンティティ
| 名称 | 概要 |
|---|---|
| ヒト | 顧客、会員、ホテルの従業員etc.. |
| モノ | プラン、お部屋、お部屋の種別、お部屋の設備etc.. |
| コト | 予約を受付する、問い合わせる、決済する、キャンセルする、部屋を手配するetc.. |
ヒト系のエンティティ
ヒト系のエンティティは、そのシステムの登場人物の総称です。
登場人物と言いましても、田中さん佐藤さんと言った固有名詞ではなく、共通の属性を抽象化して抽出します。ホテルの予約であれば、予約の依頼を行う顧客が当然必要です。会員登録をしているホテル等であれば、会員と非会員を分ける必要があるでしょう。
新しい予約の受付があったら、当然それはホテルの従業員の方が確認してお部屋の手配に入ります。従業員も登場人物に挙げられます。
モノ系のエンティティ
ホテルで何を予約するのか。予約で何を取り扱っているのか。それらがモノに該当します。モノは、システムの登場人物が取り扱っている業務上の約束事や資産などが主に該当します。
予約をするにあたっては、プランが必要になります。部屋だけの場合でも、素泊まりプランという格好になります。プランをいくつも登録できて、編集できるようにしなければなりません。他に必要なものは、お部屋でしょう。部屋というか部屋の種類ですね。
最近ではお部屋の設備についても細かく書いてあります。禁煙/喫煙、Wifiの有無等。どのお部屋を選んでも表示したい設備の情報があるのであれば、エンティティ候補になりえます。
コト系のエンティティ
コトは「登場人物がどんな行動を取るのか」という事象のことです。どういった出来事が発生しているのかを管理しなければ、システムとして使い物になりません。
ホテルの予約において最大の出来事は、予約です。顧客がホテルに予約するというイベントが発生します。その内容をちゃんと保存しておかないと、大変なことになります…
問い合わせも管理したいところですね。お客様がプランを見て、そのプランについて質問がしたい場合等に活用できそうです。忘れてはいけないのがキャンセル処理です。予約のキャンセルは必ず発生します。キャンセルの依頼があったことを別途管理できるようにしておく必要があります。
予約とキャンセルという2つのイベントによって変動する要素が1つあります。お部屋の在庫です。シングル残り2部屋だったと仮定すると、キャンセルが発生すれば3部屋になります。残りの部屋数まで表示されている所が多いので、どれだけのお部屋数が空いているのかを管理する必要があります。
コト系のエンティティから詰めていく
エンティティの3タイプのうち、まず最初に手を付けるのはコトのエンティティです。
どんな出来事がシステムの操作で発生するのかを考えます。予約なのか出荷なのか決済なのかキャンセルなのか請求なのか。そういった出来事を適切に管理できるようにするのが、データベースの意義です。ココを間違えると全部ダメです。先にコトから攻めていきます。
管理する出来事の対象が見えてきたら、登場人物と取り扱う資産やサービスについて整理します。
良いER図は深読みによって作られる
エンティティの抽出にあたっては、そのビジネスでどんな出来事が発生するのかを読み取れるかがポイントになります。業務知識が大切だと言われる最たる理由はここにあると考えています。
データベースの論理設計でもっとも重要なことは、ビジネスの深読みです。
プログラムの実装に業務知識が役立つケースは、正直そんなにないでしょう。実装には実装技術の知見が再重要です。テーブル設計においては、技術よりもビジネスへの知見や想像力のほうが重要度が高くなります。抽象的な概念を整理して抽出してデザインしていくのは、技術力とは違う能力が求められるからです。
Start-SQLのご紹介
いかがでしたでしょうか？
データベースの論理設計はシステムの品質を決める最重要工程の１つです。弊社が提供している「Start-SQL」というSQL学習Webサービスでは、SQLの学習のみならず、ER図の作成やデータモデリングの学習をサポートしています。詳しくは以下を御覧ください。