kintoneでのデータベース設計の基礎

公開日：2024-05-23

このコラムでは、kintoneを前提としたときにデータベースとしてどのように設計するのが良いのか、解説していきます。
このコラムは弊社のYouTubeチャンネルで公開している次の動画の解説記事となります。

まず動画を見ていただいてから、このコラムを理解の定着のために読んでいただくのがおススメです。

データベースを知る必要がある？

kintoneはドラッグアンドドロップで項目を並べるだけなので、データベースのことは知らなくても良いのではないか？と考える方もいるかもしれません。しかし、何らかのデータを蓄積するツールは、全てデータベースとして設計する必要があります。

このコラムや動画を通して、以下のことをゴールとしています。

  • kintoneアプリ検討に役立つ、データベース設計の基本的な考え方を理解する
  • 本格的なデータベース設計はしないにしても、設計時に役立つ設計手法を理解する

kintoneの利用を前提に、データベースを専門にしていない方に向けて解説します。そのため、厳密なデータベース設計理論とは異なる説明を含んでいますので、ご了承ください。

最初にやること

データベースを考える前に、最初に必ず以下のことを行います。

  • 対象となる業務を整理する。慣れるまでは業務フロー図を描く
  • その業務をどう改善したいのか、具体的なゴールを定める
  • その改善のために、kintoneをどう使うかイメージする

「ゴール＝満たしたい目標」を設定しないと、データベースの設計はできません。kintoneで「何をどう改善したいのか」を明確に考えることを習慣化することが大切です。

kintoneアプリの捉え方

kintone のアプリをデータベースの言葉に置き換えるとテーブルになると言えます。この場合の「テーブル」とは、kintoneのフィールドのテーブルではなくデータベースの用語としてのテーブルを指します。データベースにおける「テーブル」とは具体的に以下のものが該当します。

  • 意味のあるデータの塊
  • 複数あるもの（英語にすると複数形にできる）
    • 例えば、「顧客」はカスタマーであり、複数形にするとカスタマーズになるので当てはまります。当てはまらない例として、kintoneがあります。kintoneは1つしか存在しないので、テーブルにしても1行のみになってしまい、意味がありません。
  • キーとなる情報（1つのデータを確定できる情報）がある
  • その管理単位で業務を語ることができる
    • 業務上意味がないものや業務と合っていない場合、データとして表現できていてもシステムとして使いにくくなります。
  • 現場の人が認識できる単位である
    • データ構造が美しくても、現場の人が意味を理解できる単位でなければ有用なシステムになりません。
  • 伝票や書類と1対1で考えない
    • 安易に既存の伝票、書類と1対1でテーブルにせず、上記の項目をしっかりと検討する必要があります。これは特にやってしまいがちな考え方なので注意が必要です。

データベース設計の基本方針

データベースでいう「テーブル」の捉え方を理解した上で、基本方針をまとめます。

  • データには必ずキー項目を置く（キー項目を置けないデータはテーブルではないかも）
    • データ1行を特定できる単一の項目を必ず置きましょう。
  • 同じ意味のデータは1ヶ所だけに記録されるようにする
    • データベースの用語では、「正規化」と言います。同じデータを複数のテーブルに記録しないようにします。
  • 繰り返し登場するデータは別のテーブルとする
    • 複数のレコードに渡って同じものが何回も出てくる場合は、別のテーブル（kintone においては別の「アプリ」）になり得ます。
  • 1対1で関連付くデータは一緒にする
    • kintone におけるルックアップや関連レコードで常に1件しか出てこないものは注意が必要です。常に1対1の関係にある場合、テーブル（kintone ではアプリ）を分ける意味がない可能性があります。必ずしも同じテーブル（アプリ）にまとめる必要はありませんが、検討の対象としましょう。

実際の設計例

ここからは実際にどのように設計していくのか、例をもとに解説していきます。
まずはゴールを設定しましょう。今回は例として「営業の業務を効率化し、各案件の状況や納品・請求予定がわかるようにする」というゴールを設定しました。

業務フローを考える

ゴールが設定できたら、業務フロー図を作成しましょう。
営業の業務効率化をゴールとしていますが、関わる人は営業のみでなくお客様も含めてたくさんいます。今回関わる人たちとして、以下の人たちが挙げられます。

  • お客様
  • 営業担当
  • 承認する上長
  • 生産部門
  • 経理

こちらのフローでは、お客様の問い合わせからスタートして業務が流れていくものとして、一般的な受注生産の流れを想定しています。

  • お客様から問い合わせ
  • 営業が回答
  • 営業が見積を作成
  • 上長が見積を承認
  • 生産部門が生産
  • 納品
  • 請求
  • 経理部門が入金確認

今回のゴールは「営業の業務効率化」がメインとなるので、上記の中から営業に関わるものに着目します。
具体的には以下が挙げられます。

  • 回答
  • 見積り
  • 受注
  • 納品
  • 請求

また、営業担当の業務と他の業務の間に矢印が存在しています。これらの矢印には業務のアクションとしての名称（「見積依頼」「生産依頼」など）をつけています。

業務フロー図を整理する

この中から、テーブルになりうる候補を整理するため、名詞を拾って並べていきます。実際にホワイトボードに付箋を貼ってやってみるのもおすすめです。
上の業務フロー図自体が「案件管理」を表しているので、業務フロー図内にはなかったものですが「案件」という名詞を追加しています。

情報の主従関係を考える

次に、出てきた名詞の主従関係を考えていきましょう。
例えば、「回答」という名詞は、「問合せ」があるから発生するので、以下の図のような主従関係になります。
次に「案件」は下に見積、受注、納品などがつきます。また、商品は独立したものなので、そのように表現しています。

ER図を作成する

ここまでできたら、いよいよデータベースを考えていきます！
下の図は、「ER図（Entity Relationship Diagram）」と呼ばれる図になります。
テーブルの名前になる「問合せ」「案件」「商品」の下に、属性項目を並べていきます。項目の中で、鍵マークがついているものがキーになります。
「案件」は項目が多くなりすぎるため、今回は取り上げない「請求」などは省いています。新しく「ステータス」という項目を追加していますが、案件は状態がどんどん遷移していくものである、と最初からわかっているからです。そのため、状態遷移を管理するための項目として「ステータス」を追加しました。

また、「商品コード」に矢印をつけています。
これは、商品という別のデータがあります。案件で販売するのは商品なので、案件ではこの商品のテーブルを参照することになります。そのため、商品コードには「外部キー」として矢印をつけています。

案件も「商品名」「単価」などを持っています。例えば見積もり後に単価が変わる（= 商品テーブル側での「単価」が変更になる）といったことはあり得ます。しかし、案件には見積もり時点での金額を残しておく必要があります。そのため、見積作成時点での単価を商品テーブルから案件テーブルにコピーしておき、案件と商品のそれぞれに単価を持たせています。

さらに、案件は商品コード・商品名・単価・数量を持っていますが、これは1セットとは限りません。複数の商品を見積もりする可能性があります。案件ごとに商品点数が何個になるかはわからないため、見積もる商品の明細はテーブルを分けておく必要があります。

正規化を考える

「案件」から、複数になる可能性のある「明細」を分けた図が以下になります。
1つの案件で複数の商品の見積もりをする場合、この明細が複数になります。明細ではキーは2つあり、案件番号と明細番号をセットにしてキーとなります。片方のみだとキーとはなりません。

このようにデータを整理していくことを、データベースでは「正規化」と言います。重複しないように整理し、また複数あるものは別のテーブルにしていきましょう。
案件を正規化したことで明細が別のテーブルとして出てきたということになります。

正規化を繰り返す

次に問合せと案件の中に、氏名・会社名・メアドが重複しているので正規化していきます。
氏名・会社名・メアドは、別のテーブルにする必要があります。

氏名・会社名・メアドは顧客の情報を示しているので、「顧客」という新たなテーブルを追加しました。
顧客のテーブルには「会社コード」というキーを持たせます。問合せ、案件の両方から顧客を参照する形にしましょう。
これが正規化された形になります。

kintoneに合わせた形を考える

kintoneでも、正規化された形を意識することが大切です。しかし、kintoneには（kintoneの）テーブルという機能があるため、必ずしも上図の形になるとは限りません。
ここまで考えたデータ構造を kintoneアプリにするならどうするか、考えていきましょう。

問合せの会社名・氏名・メアドは、フォームブリッジ（トヨクモ株式会社）などの外部のフォームから入ってくることが多いと考えられます。外部のフォームから登録する際に他のテーブル（kintone アプリ）を参照するのは難しいので、ルックアップは使えません。
上述のように問合せ登録時に他のアプリを参照することはできませんが、問合せが入ってきた後はアプリアクションの機能を使って、顧客アプリにレコードを作成することができます。
データベース的なつながりはないのですが、データをコピーすることで作成できるため、点線矢印を入れています。

問合せと回答を繰り返す中で、「見積もりをください」となったら案件の発生です。
案件アプリに会社コードを持たせることで、顧客の情報をルックアップで取得できます。実際のkintoneアプリ上では、案件に会社名・氏名・メアドも項目として持っておく必要がありますが、上の図では省略しています。

そして明細です。kintoneには（kintoneの）テーブルという機能があるので、別のアプリに分けなくてもデータを持つことができます。
注意点として、kintoneのテーブルはたくさんのデータを持つと重くなってしまいます。仕様上は5000行まで持てるのですが、行数が増えると案件1つを開くにもかなりの時間がかかってしまうことになります。1見積もりあたりの商品が最大でも10個（明細が10件）くらいであれば収まる、という場合にテーブルを使用することをおすすめします。

最後に商品です。明細は商品コードを持たせ、商品からルックアップで参照するようにしています。

kintone で設計するときのポイント

まずは正規化された形を考えて、常に頭に置いておくことが大切です。kintoneで作るならどうするかを考えながら、正規化されたものを崩していきましょう。
この手順で行うことで、kintoneに適した形で設計することが可能です。

慣れてくるといきなりkintoneに合わせた形を設計できるようになるかもしれませんが、まずは正規化された状態を頭に置いておくことが重要なポイントです。
こうしたイメージがないままにkintoneでアプリを作ってしまうと、後から変更しにくくて困ってしまうなどの可能性があります。イメージをしっかり固めてからアプリを作成しましょう。

疑問

kintoneはリレーショナルデータベースではないのに、リレーショナルデータベースの考え方で設計するのが正しいのか？

こういった疑問を持たれる方もいらっしゃるかもしれません。

このリレーショナルデータベースの設計方法を利用して設計するのが常に正しいと考えているわけではなく、一つの方法としてご紹介しています。
この方法をご紹介するのは、リレーショナルデータベースの設計手法は歴史が長く、たくさん使われている設計手法であるためです。
歴史が長くたくさん使われているため、データを整理するための考え方として洗練されています。kintone はリレーショナルデータベースではないとはいえ、こうした洗練された考え方を取り入れた方が簡単に、便利に使えると考えています。
さらに、リレーショナルデータベースの設計に関する本やWebなどのコンテンツはすでにたくさん存在しているので、情報収集や学習がしやすくなっています。
一方、kintoneのデータベース設計を、リレーショナルデータベースの考え方なしにゼロから紹介しているものはあまり存在しないのではないでしょうか。

こういった理由から、リレーショナル・データベースの考え方を参考に正規化したデータ構造を考えて、そこからkintoneに向いている形に崩していく設計方法をおすすめしています。

まとめ

1つ目は、kintoneはデータベースなので正しく設計することが大切です。
正しい設計ができていないと、後でそのデータを使って別の業務アプリを作るといった時に、上手くできないということが起こり得ます。

2つ目は、リレーショナルデータベースの設計知識はkintoneの設計にも活きるということです。
ポイントでご紹介した通り、リレーショナルデータベースはとても洗練された設計手法があります。その洗練された設計手法を応用することで、kintoneの設計を綺麗に行うことができます。

最後は、慣れるまでは一足飛びにアプリを作成せずに、丁寧に手順を踏んで設計するということです。
アールスリーのようなkintoneのプロや、kintoneに限らずデータベースをたくさん扱ってきたITのプロは、経験をもとに頭の中でさっと設計できます。そのため、アプリ作成も早くできます。
しかし、kintoneに慣れていない方や、リレーショナルデータベースの使用経験が浅いという方は、これらの設計を丁寧にやることが大切です。繰り返していくことで、だんだん早くなっていきます。また、慣れたらここは飛ばしてもOKだな、とわかるようになっていきます。

そうなるまで、まずは丁寧に手順を踏んで設計しましょう。