kintoneにおけるデータの取り扱いは、RDBとは異なる部分があります。
このTipsでは、kintoneにおけるデータ設計の基本について説明します。

RDBとは、リレーショナルデータベース（Relational Database）の略称です。
リレーショナルデータベースとは、データを行と列の形式で保存するデータベースの一種です。
もしリレーショナルデータベースをイメージしにくい場合は、エクセルの表を思い浮かべてみてください。

リレーショナルデータベースでは、複数のテーブル（表）を結合できます。
たとえば、あるテーブルには社員情報が、別のテーブルには部署の情報がそれぞれ保存されているとします。
これらのテーブルは共通の「部署ID」を使って結合できます。
テーブルを結合すると、社員の名前とその所属部署名を一緒に取得できます。
次の画像では社員情報と部署情報のテーブルを表示し、部署IDで結合する様子を示しています。

kintoneの1つのアプリが、RDBの1つのテーブルに相当する？

kintoneでは、リレーショナルデータベースのように、別のアプリのデータを参照できます。
kintoneの1つのアプリがリレーショナルデータベースの1つのテーブルに相当するように思えますが、別物として考えることが重要です。
性能面においてもRDBとは異なる面があり、特にデータを関連付けるときには注意が必要です。

kintoneでデータを結合するには

kintoneでデータを結合するには、次の方法があります。

• ルックアップフィールドを使用する。
  • 別のアプリから必要なデータをコピーして取得できる。
  • RDBのJOINとは異なり、参照元が変更されても参照先のデータは自動更新されない。
• 関連レコードを使用する。
  • 「条件に一致したレコード」を一覧表示できる。
  • 参照元の変更が反映されるが、アプリ内検索では検索できない。

ルックアップは別のアプリからデータをコピーして取得できる機能です。
次の図では、左の注文管理アプリでルックアップフィールドを作り、右の商品管理アプリのデータを取得しています。
その結果、注文管理アプリ内で商品管理アプリのデータを扱うことができます。

便利なルックアップですが、主な注意点が3つあります。

コピーしたフィールドは変更できない

1つ目は、コピーしたフィールドが編集不可となり変更できなくなるという点です。
コピーしたフィールドには自動で値が設定され、編集できません。

次の図では、顧客管理アプリのデータを案件管理アプリへコピーしています。
コピー後に案件管理アプリの部署名、担当者名が編集不可となります。

ルックアップ元が変更されても参照先のデータは自動更新されない

2つ目は、ルックアップ元が変更されても参照先のデータは自動更新されないという点です。
リレーショナルデータベースやEXCELのVLOOKUP関数とは異なり、参照先のデータは自動で更新されません。

次の図では、顧客管理アプリで部署名を「ソリューション営業グループ」から「開発部」に変更していますが、案件情報アプリの部署名は自動で更新されません。
変更を反映するには、案件情報アプリで再度ルックアップの取得ボタンを押す必要があります。

ルックアップの候補が複数ある場合

3つ目は、ルックアップの候補が複数ある場合の扱いです。
GUI、つまり、ブラウザー上での操作は、次の図のように複数ある候補から選択できます。

しかし、CSVファイルからのデータ読み込みや、REST APIを使用したデータの更新には注意が必要です。
この場合にルックアップの候補が複数あると、どの値を設定すべきか特定できず、更新に失敗します。
そのため、ルックアップの候補が複数ある場合は、値を特定できるように、ルックアップ元のフィールドを重複禁止にしておく必要があります。

関連レコードを使うと、レコード詳細画面で条件に合致したレコードを一覧表示できます。
ルックアップと同じく、別アプリのデータを参照できます。

次の図は案件管理アプリと案件に紐づく活動履歴アプリです。
案件管理アプリ上で、案件に紐づく活動履歴を一覧表示しています。

関連レコードにも、主に4つの注意点があります。

テーブル内フィールドは関連レコード一覧の表示項目に利用できない

1つ目は、テーブル内フィールドを関連レコード一覧の表示項目に利用できないという点です。
関連レコードを表示するときに設定できるフィールドには制限があります。
関連レコードはテーブルのように表示されるため、さらにその中にテーブルフィールドを設定できません。

関連レコードは参照元の変更が自動的に反映される

2つ目は、関連レコードでは参照元の変更が自動的に反映されるという点です。
ルックアップの場合は、参照元の変更が反映されませんでした。
しかし、関連レコードは参照元の変更が常に反映されます。

REST API で関連レコードの値を操作することはできない

3つ目は、REST APIで関連レコードの値の取得／登録／更新ができないという点です。
REST APIで関連レコードの値を操作できません。
詳しくは、 関連レコード一覧 を参照してください。

集計、レコード一覧画面への表示、CSV出力の項目に利用できない

4つ目は、集計、レコード一覧画面への表示、CSV出力の項目に利用できないということです。
これは、kintoneにおけるデータ設計に大きく影響を与えます。

関連レコードは条件に合致するデータを表示しているだけで、レコード内にデータを保存していないため、集計やCSV出力ができません。
ルックアップの場合はレコード内にデータを保存しているため、集計、レコード一覧面面への表示、CSV出力が可能です。

実現したい場合は、ルックアップやカスタマイズなど、別の方法を検討する必要があります。

別アプリのデータを参照するための方法として、関連レコードとルックアップについて説明しました。
これらの使い分けについて、次の表にまとめます。

項目	ルックアップ	関連レコード
集計（グラフ化）したい	◯	✕
一覧画面で表示したい	◯	✕
CSV出力したい	◯	✕
参照元の変更を常に反映したい	✕	◯
参照元フィールドが重複する	△	◯

「集計（グラフ化）したい」「一覧画面で表示したい」「CSV出力したい」場合はルックアップを使います。
「参照元の変更を常に反映したい」場合は、関連レコードを使います。
「参照元フィールドが重複する」場合は、要件に応じて適切に使い分けが必要です。
ブラウザーでの操作のみの場合は、どちらをつかってもよいかもしれませんが、APIまたはCSVでの更新をしたい場合は、重複禁止を設定する必要があります。

この特徴を理解して、どのような要件を満たしたいのかを考慮してルックアップと関連レコードを使い分けることが重要です。

しかし、「集計（グラフ化）したい」かつ「参照元の変更を常に反映したい」という場合は、ルックアップと関連レコードのどちらも実現できません。
このような場合はカスタマイズやプラグインを検討する必要があります。

ルックアップを使うときや、REST APIで特定のレコードを操作するときなど、レコードを一意に識別する必要のある場面があります。

例として、在庫管理アプリを作るとき、商品名だけではレコードを一意に特定できない場合があります。
そのような場合に、商品のカテゴリ名と商品番号を組み合わせて、商品を特定するための商品IDを作るとすると、次のようになります。

このレコードを一意に定めるためのキーが、ユニークキーです。
kintoneでデータを扱う上では、ユニークキーをどのように作るかが重要です。

代表的なユニークキーのつけ方には、人工キーと自然キーがあります。

人工キーとは、システムが機械的に値を設定したものです。例としてkintoneのレコード番号があります。
自然キーはユーザーがルールを決めて設定します。
さきほどの商品カテゴリと商品番号を組み合わせたユニークキーは、自然キーの例になります。

	意味	例
人工キー	システムが機械的に値を設定 システムが付与する	- kintoneのレコード番号
自然キー	ユーザーが与えるキー 特定のフィールドを組み合わせるなど、ユーザーがルールを決めて作成	- 商品カテゴリと商品番号 - 氏名とメールアドレス

人工キーの例として、kintoneのレコード番号を挙げましたが、レコード番号をユニークキーにすべきではありません。
連番になっていないレコード番号を含むデータを移行したときに、データの整合性を保てなくなるためです。

レコード番号の連番は、レコード作成された順番に振られます。
たとえば次の図のように、レコードを3つ作成し、そのうちのレコード番号3のレコードを削除します。
その後に新しいレコードを作成すると、新しいレコードはレコード番号4になります。
テスト環境ではこの状態で、顧客管理アプリと案件管理アプリと問題なく紐づいているとします。

本番環境にCSVデータをインポートして、顧客管理アプリと案件管理アプリを移行します。
次の図のように、CSVでデータ移行をしたとき、顧客管理アプリのレコード番号は自動で設定され、「1, 2, 3」の連番になります。
しかし、案件管理アプリのルックアップフィールドは顧客管理アプリのレコード番号「4」のレコードを参照しているため、データの整合性が保てなくなります。

このように、データ移行したときにデータの整合性が保てなくなるため、レコード番号をユニークキーにすることは非推奨です。
そのため、アプリにユニークキーを設定して自動採番したい場合は、プラグインを使用したりカスタマイズを行ったりする必要があります。

その他、kintoneのデータ設計上で重要な機能について説明します。

次の図のように、kintoneでは1つのレコード内にテーブルを作ることができます。
リレーショナルデータベースとは異なる点です。

レコードの内容を別のアプリに転機する際には、アプリアクションを使うと便利です。

たとえば次の図のように、顧客リストのアプリから顧客情報を見つけ、注文管理アプリに転記できます。
この例では「注文管理に登録」ボタンをクリックすると、注文管理アプリに顧客情報が転記されます。

最後に、kintoneにおけるデータ設計の基本についてまとめます。

• kintoneとRDBは別物として考える。
• 特にデータを関連付けるときに注意が必要となる。
• kintoneでのデータの関連付けはルックアップまたは関連レコードを使う。
• ルックアップと関連レコードの特性を理解して使い分ける。
• データを関連付けるときには適切なユニークキーが必要となる。