歩数計のスキーマ設計を考えてみよう：組み込みDBプログラミングの道しるべ（5）（1/2 ページ）

データベースを使ううえで、重要な作業の1つであるスキーマ設計。具体的な例を基に、実際にスキーマ設計を行ってみよう。

[加藤大受，＠IT MONOist]

　前回は、スキーマ設計の概要と正規化理論について説明しました。データベースを利用するうえで、スキーマ設計は最も重要な作業の1つです。今回は、具体的な例を挙げて、実際にスキーマ設計を行っていきます。

まずは必要なデータを整理しよう

　ここでは、次のようなGPS機能付き歩数計があることを仮定して、スキーマ設計を考えていきましょう。

歩数計の説明

　GPS機能を装備しており、歩数計の利用者が毎日歩いた距離と時間やその日通過した施設の一覧を閲覧したり、歩数計に装備されている簡易な地図上にプロットすることができる。また、歩いた距離と時間から消費カロリーを計算したり、今後目標とする施設を検索して登録したり、それらの施設の情報を閲覧したりすることができる。施設は電話番号、住所、施設名称でも検索することができる。

　まずは、この歩数計で利用されるデータを分類し、エンティティを整理していきましょう。実際にアプリケーション開発では、このデータ分類の前に、アプリケーションの要件定義が行われ、この要件定義から利用されるデータが特定されますが、ここでは要件定義やこのデータを利用するアプリケーションの設計は省いて説明していきます。

• ユーザーの歩いた距離　
  開始地点、終了地点、開始時間、終了時間、歩いた距離、歩数、消費カロリー
• 施設情報（POIデータ）　
  施設名称、住所、電話番号、GPS情報、施設属性、施設情報
• 都道府県情報　
  都道府県名称
• ユーザーの訪問情報　
  日時、訪問場所

　エンティティの洗い出しが終了したら、続いて各エンティティとの関係を考えます。例えば、ユーザーの訪問情報の訪問場所と施設情報の連携や施設情報と都道府県情報の連携などです。前回説明したように、エンティティの関係は次の4種類です。

1. 1対1関連型
2. 1対多関連型
3. 多対1関連型
4. 多対多関連型

　各エンティティの関係がどれに当たるかを検討することで、すべてのエンティティの関係が見えてくるでしょう。

　洗い出したエンティティを基にER図を作成したり、エンティティの関係をまとめたりすることで、エンティティの関係と各データの関係を表すことはできます。しかし、それらのデータの動きは分かりません。

　データの動きは、「CRUD（クラッド）マトリックス」と呼ばれる表を利用します。CRUDマトリクスは、処理ごとに、データに対してどんな操作を行うかを示したものです。データ操作には、「作成（Create）」、「参照（Retrieve）」、「更新（Update）」、「削除（Delete）」の4つがあります。

　CRUDとは、これら4種類のデータ処理の頭文字を取ったもので、CRUDマトリックスを使ってエンティティの処理内容を表すというわけです。今回のケースでは、ユーザーの訪問情報を作成時に施設情報を参照すること、施設情報の検索時に都道府県情報と施設分類を参照しますので、図1のようになります。

	訪問先	施設分類
施設	R（参照）	R（参照）
訪問先	C（作成）	―
施設分類	―	R（参照）
都道府県	―	R（参照）
図1　CRUDマトリックス