コンテンツにスキップ
JP

モデルの構造を先に決める

更新日

複数の人がデータを入力すると、値の書き方が人によって分かれてしまうことがあります。たとえば建物の情報では、用途の欄に「住宅」と記入する人がいる一方で、別の人は「住居」と記入するかもしれません。建築年の欄に「1985年?」のような値が混ざることもあります。

「住宅」と「住居」が同じ用途を指すことは、入れた本人には分かっていても、データの上では別の値です。集計するプログラムは別の値として数えるので、用途ごとの集計が合いません。「1985年?」をどの年として扱うかも入れた本人にしか分からず、データを使う側は、その値を信用してよいかを判断できません。このように不揃いなデータは、値の意味を知っている入れた本人以外の人や、プログラムには使いにくくなります。入力を各人の判断に任せた運用では、不揃いはデータが増えるほど広がります。

複数の人が入力した建物のデータ。建築年と用途の値の書き方が人によって分かれている

このような不揃いを防ぎ、データを入れた人以外の人やプログラムにも使いやすくするために、データを入れる前にどの項目にどんな値を入れるかを定義するのがデータ管理の基本です。Re:Earth CMS でのデータ管理も、データを入れる先を決め、そこに入る値を定義するところから始まります。

データを入れる箱を、モデルと呼びます。Re:Earth CMS では、モデルに入れるデータの一つひとつを、アイテムと呼びます。建物のデータを扱うなら、建物のモデルを 1 つ作り、建物 1 棟につき 1 つのアイテムを入れます。100 棟を扱うなら、100 個のアイテムが 1 つのモデルに集まります。

建物のモデルに、建物 1 棟につき 1 つのアイテムが入っている

スキーマは、データを入れる前に決める定義

Section titled “スキーマは、データを入れる前に決める定義”

Re:Earth CMS では、モデルを作るとき、そのモデルに入るデータの構造をスキーマとして決めます。データを入れる前に作っておく定義が、このスキーマです。

スキーマで決めるのは、そのモデルのデータがどんな項目からできているかです。たとえば、この記事で例にする建物のモデルでは、建物 1 棟のデータを「名前」「建築年」「用途」の 3 つの項目で表すことにします。この一つひとつの項目を、フィールドと呼びます。

1 つのフィールドを定義するには、フィールドに名前を付け、そのフィールドに入れてよい値を決めます。この記事の例の 3 つのフィールドは、次のとおりに定義できます。

  • 「名前」フィールドはテキストフィールドにする。 建物の名前は自由な文字列なので、どんな文字でも入力できるようにします。
  • 「建築年」フィールドは整数型のフィールドにする。 建てられた年だけを入れるフィールドなので、「1985年?」のような文字の混じった値は入れられなくなります。
  • 「用途」フィールドは選択肢フィールドにする。「住宅」と「住居」のような表記揺れが起きないよう、あらかじめ用意した選択肢から選ぶ形にします。

モデルのスキーマで「名前」「建築年」「用途」の 3 つのフィールドを定義し、アイテムの値がそのフィールドに入っている

先に決めたスキーマが、不揃いを防ぐ

Section titled “先に決めたスキーマが、不揃いを防ぐ”

スキーマを先に決めておけば、誰が入力しても、アイテムに入れられる値はスキーマの定義に合うものだけになります。値がそろうかどうかが入力する人の判断ではなくスキーマで決まるので、データを管理する側は、データの品質を属人的にではなく仕組みで保てます。

値がそろっていると、データを入れた人に値の意味を聞かなくても、ほかの人やプログラムがデータをそのまま使えます。たとえば、別の担当者が建物を用途ごとに集計するとき、「用途」フィールドの値はあらかじめ用意した選択肢のどれかなので、同じ用途の建物は同じ値として数えられます。建物の一覧を Web サイトに表示するアプリも、API を通じてスキーマで定義したフィールドのとおりにデータを受け取るので、受け取った値をそのまま表示に使えます。データは、入れた人の手元のものではなく、ほかの人やプログラムにも使いやすいものになります。

Re:Earth CMS は、こうしたデータ管理の考え方をもとに設計されています。