データスキーマ
新築マンションを建てる前に部屋の広さや配置を決める設計図であり、会員登録用紙の四角い記入枠のようなものです。
定義 データベースに情報を格納する前にあらかじめ決めておくデータの公式な設計図です。会員登録用紙に「氏名」「生年月日」「電話番号」といった記入欄が決まっているように、コンピューターがデータをどのような構造とルールで保存すべきかの枠組みを定める約束事です。
会員登録のフォーマットが必要な理由
テーマパークの会員登録用紙に枠線が一切なく、真っ白な紙だけを渡されたらどうなるでしょうか？ ある人は漢字で名前を書き、ある人は電話番号の代わりにメールアドレスだけを書き、ある人は住所を3行にわたって書くかもしれません。このようにバラバラに集まった情報は、後からコンピューターが検索したり整理したりすることがほぼ不可能です。
そのため、私たちはあらかじめ四角い記入枠を作り、ルールを定めます。「氏名欄は全角10文字以内」「生年月日欄は数字8桁」「電話番号は必須入力」といった具合です。データベースでもまったく同じです。膨大な情報を整然と保管するには、データが入る規格とルールを事前に決めておく必要があり、この約束事の集まりこそがスキーマです。
スキーマがしっかり定義されていれば、おかしなデータが入り込むのを入口で防ぐことができます。年齢欄に誤って「東京都」と入力しようとしても、データベースが即座に入力を拒否してシステムの不具合を防いでくれます。
もう少し正確に言うと：設計図の3つの視点
専門家は、家を建てるときに外観パースと間取り図を分けて描くように、スキーマも3つの視点（階層）に分けて扱います。これを「3層スキーマ構造」と呼びます。ユーザーが見る画面、データ全体の構造、そして実際のハードディスクへの保存方法を切り離して管理するための仕組みです。
一番外側にはユーザーが見る外部スキーマがあります。同じネット通販でも、購入者が見る注文履歴画面と出品者が見る売上管理画面では必要な情報が異なるように、ユーザーの立場ごとに最適化して見せる個別の設計図です。
中央にはデータ全体の骨組みである概念スキーマがあり、一番下にはディスクに物理的に書き込まれる方法を扱う内部スキーマがあります。このように階層を分けておくことで、ハードディスクの交換といった内部の変更があっても、ユーザーが見るプログラム画面まで作り直す必要がなくなります。
厳格な設計図と柔軟なボックス
伝統的なリレーショナルデータベース（RDB）では、スキーマが非常に厳格です。家を建てるときにコンクリートの壁をしっかり固めるようなもので、最初に決めたルールから外れたデータは決して受け入れません。銀行や病院のようにたった一つの間違いも許されない場所では、この厳格なスキーマがデータの信頼性を守る強固な盾になります。
一方で、最近のWebサービスのようにデータの形式が頻繁に変わる環境では、スキーマが柔軟なNoSQLという方式を使うこともあります。仕切りのあるタンスの代わりに、物を自由に入れられる大きな衣装ケースを使うようなものです。今日はテキストだけを入れて、明日は写真や位置情報を追加してもシステムは拒否しません。
結局のところ、どちらのスキーマを選ぶかはデータの目的次第です。ルールと正確さが最優先される金融取引には堅固なスキーマが適しており、新しい形式の投稿が次々と生まれるSNSなどには柔軟な方式が向いています。
🤔 よくある誤解
スキーマは一度決めたら絶対に修正できない。
サービスの成長に合わせてスキーマを変更（マイグレーション）することができます。ただし、すでに保存されている大量のデータが破損しないよう、慎重な手順を踏んで変更を行います。
🧺 日常で出会う場面
データスキーマとは、データベースのルールと構造をあらかじめ定義した設計図であり、データがバラバラに乱れないように保つ骨組みです。