データスキーマ

遊園地の会員登録の用紙に、欄が何もない白紙を渡されたらどうなるでしょう?ある人は名前をハングルで書き、ある人は電話番号の代わりにメールアドレスだけを書き、ある人は住所を三行にわたって書くでしょう。こうしてごちゃごちゃに集まった情報は、あとでコンピューターが検索したり整理したりするのが不可能に近くなります。

そこで私たちは、あらかじめ四角い欄をつくってルールを決めます。「名前欄は10文字以内」「生年月日欄は数字8桁」「電話番号欄は必須入力」といった具合です。データベースでも同じです。たくさんの情報を整然と保管するには、データが入ってくる規格とルールをあらかじめ決めておく必要があり、この約束事の集まりがスキーマです。

スキーマがしっかり組まれていれば、おかしなデータが入ってくるのを入り口で防げます。年齢欄にうっかり「ソウル市」という文字が入ろうとしても、データベースがすぐに入力を拒否して、システムエラーを防いでくれます。

もう少し正確に言うと、専門家は家を建てるとき鳥瞰図と平面図を別々に描くように、スキーマも三つの視点に分けて扱います。これを「3層スキーマ構造」と呼びます。ユーザーが見る画面と、データ全体の構造、そして実際のハードディスクへの保存方式を切り離して管理するための方法です。

一番外側には、ユーザーが見る外部スキーマがあります。同じショッピングサイトでも、購入者が見る注文履歴の画面と出品者が見る精算の画面では必要な情報が違うように、ユーザーの立場ごとに合わせて見せる個別の設計図です。

真ん中にはデータ全体の骨組みである概念スキーマがあり、一番下にはディスクへ物理的に記録する方式を扱う内部スキーマがあります。このように層を分けておくと、ハードディスクの交換のような内部の変更があっても、ユーザーが見るプログラムの画面まで作り直す必要がなくなります。

従来のリレーショナルデータベースでは、スキーマはとても厳格です。家を建てるときにコンクリートの壁をしっかり固めるのと同じで、最初に決めたルールから外れたデータは決して受け付けません。銀行や病院のようにほんの少しの誤差も許されない場所では、この厳格なスキーマがデータの信頼性を守る頼もしい盾になります。

一方、最近のインターネットサービスのようにデータの形がたびたび変わる環境では、スキーマが柔軟なNoSQL方式を使うこともあります。規格化された引き出し付きの棚の代わりに、物を自由に入れられる大きな箱を使うようなものです。今日は文章だけを入れて、明日は写真や位置情報を付け足しても、システムは止めません。

結局、どんなスキーマを選ぶかはデータの目的しだいです。ルールと正確さが最優先の金融取引では堅いスキーマを主に使い、新しい形の投稿が次々に押し寄せるサービスでは柔軟な方式も併用します。ただ、大規模なSNSも中核となるデータはリレーショナルデータベースに入れていることが多く、一つのサービスの中で二つの方式を混ぜて使うのはよくあることです。