Notionを数ヶ月使うと、多くの人が同じ壁にぶつかる。
- タスクの中に顧客情報をコピペ
- 顧客名変更で過去ページを総修正
- 同じ住所が複数のDBに散在
「第二の脳」が「情報の墓場」になる瞬間だ。
解決策は最新AI機能でも新しいテンプレートでもない。1970年、エドガー・F・コッドが提唱した「関係モデル（Relational Model）」だ。50年以上前の理論が、2026年のNotion運用を救う。
情シス22年の現場で、部署横断の情報管理を何十回と設計してきた。どんなに便利なツールを使っても、設計思想が間違っていれば半年で崩壊する。Notionも例外ではない。崩壊するパターンはいつも同じで、フォルダ思考から抜け出せていないことが原因だ。
この記事でわかること：
- フォルダ思考がデータベースを壊す理由
- コッドの関係モデルの核心「主語を揃えよ」
- 破綻を防ぐ3つの正規化チェック
- 正規化を崩すべき唯一の例外（Snapshot）
1. 結論：フォルダ思考がデータベースを壊す
📌 要点：フォルダ構造は「物理的な場所」で整理する思想。関係モデルは「論理的な意味」で整理する思想。現実の業務は多対多で絡み合うため、フォルダでは限界が来る。
Notionを「高機能フォルダ」として使う限り、破綻は時間の問題だ。
フォルダ構造の本質：
- 階層構造（木構造）
- 1つの情報は1つの場所に属する
- 横断的な参照が弱い
しかし現実の業務はこうなっている。
- 1人の顧客は複数のプロジェクトに関わる
- 1つのタスクは複数の属性を持つ
- データは常に多対多で絡み合う
フォルダは「物理的な場所」で整理する思想。関係モデルは「論理的な意味」で整理する思想。ここが決定的に違う。
官公庁でのシステム運用を担当していたとき、部署ごとにExcelファイルを分けて管理していた担当者がいた。年度が変わるたびに同じデータを何箇所も修正し、修正漏れで書類の不整合が発生する。フォルダ思考の典型的な崩壊パターンだ。
2. コッドの本質：主語を揃えよ
📌 要点：関係モデルの核心は「1つの表に複数の主語を混在させるな」というシンプルな原則。これが崩れた瞬間に更新地獄が始まる。
関係モデルの核心はシンプルだ。
- 表は「主語」が統一された集合である
- 各行は1つの事実（タプル）
- 各列はその事実の属性
つまり、1つの表に複数の主語を混在させるな。
タスクDBに顧客のメールアドレスを入れてしまうと、顧客情報を変更するたびに全タスクを修正する必要が生じる。「タスク」と「顧客」という2つの主語が混在しているからだ。
これが崩れた瞬間、更新地獄が始まる。Notionで起きる破綻の大半はここにある。
3. 破綻を防ぐ3つの正規化チェック
📌 要点：①主語が一致しているか、②紐付けを名前ではなくIDで行っているか、③コピペしていないか。この3点を守るだけで運用の崩壊を防げる。
① 主語は一致しているか？
NG例：
タスクDBに顧客のメールアドレスを保存。
→ 顧客変更時、過去タスク全修正が発生。
正解：
タスクと顧客を分離。メールアドレスは顧客DBに一度だけ記録。タスクからはリレーションで参照する。
② 紐付けを名前に依存していないか？
名前は変わる。識別子（ID）は変わらない。
Notionではリレーションで別DBのレコードを紐付けられる。「田中商事」という名前で紐付けると、社名変更のたびに全レコードを修正する必要が生じる。IDプロパティで紐付ければ、名前を変えても関係は維持される。
③ コピペしていないか？
同じ住所を複数箇所に書いた瞬間、データは腐る。
Notionのロールアップ機能を使えば、参照元DBの値を他のDBで表示できる。「一事実一箇所」の原則を守ることで、修正箇所が1つになり運用コストが劇的に下がる。
4. 例外：正規化を崩すべき場面（Snapshot）
📌 要点：過去の事実は変えてはいけない。請求書の「発送時住所」は正規化を崩してコピーで保存するのが正解。「現在の値の参照」と「過去の事実の固定」を使い分けることが重要。
原則は正規化だ。しかし例外がある。
履歴保存（Snapshot）の考え方：
顧客の「現在の住所」は参照でいい。しかし請求書の「発送時の住所」は固定すべきだ。
なぜなら過去の事実は変わらないからだ。「あの時この住所に送った」という事実は、顧客が引っ越しても変わらない。この場合、あえてコピーして保存する。
ここを理解している人は運用で迷わない。「参照か固定か」を意識的に選択できるからだ。
医療機関での処方記録でも同じ考え方を使った。患者の「現在の体重」は参照でよい。しかし「投薬時の体重」は固定で保存しなければならない。薬の投与量は投薬時の体重をもとに計算されるため、後から体重が変わっても記録は変えてはいけない。
5. 向いている設計・向いていない設計
📌 要点：3人以上のチームや1年以上運用するDBには関係モデルの設計コストが十分回収できる。単発のメモや一時的な整理には凝った設計は不要。
関係モデル設計が向いている：
- 3人以上のチーム運用
- 1年以上継続して使うDB
- 顧客・案件・タスクが絡み合う業務
向いていない：
- 単発イベントのメモ
- 一時的なアイデア整理
- 一人が短期間だけ使うもの
設計コストが回収できないなら、凝らなくていい。ここを判断できるのも設計思想を知っているからこそだ。
FAQ：よくある質問
- QNotionとExcelではどちらが関係モデルに向いていますか？
- A
Notionの方が明確に向いている。
リレーション・ロールアップ・フィルター機能がそのままRelational Modelの概念を実装している。ExcelはVLOOKUPで代替できるが、設計の意図が伝わりにくく運用が属人化しやすい。
- Qリレーションを使うと表示が重くなりますか？
- A
ページ数が1000件を超えるあたりから体感速度の低下を感じる場合がある。
大量データを扱う場合は、表示するビューの絞り込み条件を設定するか、NotionのAPIと外部DBを組み合わせる構成を検討する。
- Q「一事実一箇所」の原則はいつ守らなくていいですか？
- A
本文で触れたSnapshotの場合だ。
「現時点の参照」ではなく「特定時点の記録」が必要なデータは意図的にコピーする。もう一つは読み取り専用の集計・レポート用途で、パフォーマンスのために非正規化することもある。
- Qコッドの関係モデルとNotionの違いは何ですか？
- A
コッドの理論は数学的な集合論に基づく厳密な理論。
NotionはそのエッセンスをUIとして直感的に操作できる形に変換したツールだ。Notionの「DB」「リレーション」「ロールアップ」は、関係モデルの「テーブル」「外部キー」「結合クエリ」にそれぞれ対応している。
- Q個人のタスク管理にも関係モデルは必要ですか？
- A
一人で使うシンプルなタスク管理なら、過剰設計になる可能性が高い。
ただし「プロジェクト・タスク・連絡先」が絡み合い始めた段階で設計を見直す価値がある。複雑さを感じてきたら、関係モデルの出番だ。
まとめ
AI時代こそ、設計思想が差を生む。
- フォルダ思考を卒業し、「論理的な意味」でデータを整理する
- 「1つの表に複数の主語を混在させるな」がコッドの核心
- 主語の統一・IDによる紐付け・コピペ禁止の3チェックで崩壊を防ぐ
- 過去の事実はSnapshotで固定する。「参照」と「固定」を使い分ける
AIはデータベースを自動生成できる。しかし設計思想までは保証しない。情報の「場所」を探すのをやめ、情報の「意味」を設計する。そのとき初めてNotionは本当の意味で機能する。
関連記事：あなたのNotionが散らかる理由。「概念設計」の極意
関連記事：Excelセル結合はなぜダメ？解除して値を埋める最短手順
“`
