Googleカレンダーのためのデータベース設計チュートリアル

はじめに

このデータベース設計チュートリアルでは、複雑な実案件のデータベーステーブルをどのように設計するかを示す。Google Calendar のクローンを設計していく。このシリーズは『Database Design using Minimal Modeling』という書籍のアプローチを説明するもの。まずカレンダーデータを説明する完全な論理モデルを構築し、その論理モデルに基づいてテーブル設計を進める。

対象読者

この本の目的は、曖昧なアイデアからデータベーステーブルの完全な定義へと進む助けになること。本文の最初の 3/4 ではデータベースについての一般的な理解だけを前提とし、論理モデルを説明する。最後の 1/4 では、論理モデルから物理的なテーブル構造へ移行する方法を説明する。

目次

• はじめに
• この本のアプローチ
• 問題の説明
• Part 1: 基本的な終日イベント
• Part 2: 時刻ベースのイベント
• Part 3: 繰り返される終日イベント
• Part 4: カレンダーページのレンダリング
• Part 5: 時刻ベースのイベントのカレンダーページレンダリング
• Part 6: これまでの完全な論理モデル
• Part 7: SQL テーブルの作成
• 結論
• 次のステップ

この本のアプローチ

人はしばしばテーブル設計から始めるが、ここでは別のアプローチを取る。まず論理モデルを作成し、データ属性とエンティティ間の関係を定義する。論理モデルが固まったら、物理テーブルを設計する。

問題の説明

Google Calendar の主要機能を実装していく。ユーザー関連データは最小限に実装する。イベントはタイトル、説明、場所などの属性を持つ。最も複雑な部分は時刻と日付である。

Part 1: 基本的な終日イベント

アンカー

まずアンカーを見つける必要がある。アンカーとはエンティティのことで、たとえばユーザー(User) やイベント(Event) がある。アンカーは ID とカウントを扱う。

ユーザー属性

ユーザーについては最小限のデータをモデル化する。たとえばメールアドレス。

終日イベントの属性

イベント名、開始日、終了日を保存する必要がある。

リンク

特定のユーザーが特定のイベントを作成したという情報をどこに保存するかを決める必要がある。これは属性ではなくリンクとして扱う。

Part 2: 時刻ベースのイベント

タイムゾーン

タイムゾーンは複数の国や地域で使われる。タイムゾーンの定義は時折変更される。タイムゾーンに関する最小限のモデルを実装する。

タイムゾーン属性

タイムゾーンの人間が読める名前を保存する。

時刻ベースのイベント属性

イベント名、開始時刻、終了時刻を保存する。ローカル時刻を使う。

リンク

タイムゾーンと時刻ベースのイベントの間のリンクを定義する。

日付イベントと時刻イベントの類似点

2 つのイベントタイプの類似点を検討する。論理モデリングによって意思決定を先送りできる。

Part 3: 繰り返される終日イベント

属性 #1、周期

イベントがどのくらいの頻度で繰り返されるかに関する属性を定義する。

属性 #2、絡み合った属性

繰り返しイベントの周期を定義する。

属性 #3

月次イベントの場合、同じ日付で繰り返すのか、同じ曜日で繰り返すのかを定義する。

曜日: マイクロアンカー

曜日をどこに保存するかを決める。新しいアンカーを導入する。

リンク

曜日とイベントの間のリンクを定義する。

完了確認

モデリングが完了したかを確認するため、元の要件を再確認する。

繰り返しの制限: さらに絡み合った属性

イベントがいつまで繰り返されるかに関する属性を定義する。

Part 4: カレンダーページのレンダリング

ここまではカレンダーの記録部分について議論してきた。ここからは、ユーザーのカレンダー週表示を見せる必要がある。

---

GN⁺の要約

このチュートリアルは、複雑なデータベース設計を段階的に説明することで、初心者にも理解しやすくしている。Google Calendar の主要機能をモデル化することで、実プロジェクトに適用できる有用な例を提供している。論理モデリングによってデータベース設計の誤りを防ぎ、物理テーブル設計へ自然につながる流れを説明している。類似した機能を持つプロジェクトとしては Microsoft Outlook Calendar などがある。