データベースとしてのkintone(キントーン)

kintoneには様々な機能があり、単純にWebデータベースと呼ぶのは少し正しくない側面があるのですが、とはいえkintoneを導入される多くの方がデータベースとしての機能に期待されていると思います。

このコラムでは、データベースとしてのkintoneの機能について解説をしていきます。

このコラムは、弊社のYouTubeチャンネルで公開している次の動画の解説記事となります。

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

身近にあるデータ蓄積手段

データを蓄積する方法には色々なものがあります。kintoneに興味がある方にとって身近なものは次の3種類じゃないかと思います。

Slide2.png

エクセル

エクセルはおそらくどこの会社でもお使いかと思いますが、忘れてはいけないのはエクセルは「表計算ソフト」であるということです。表計算ソフトですので、データベースっぽく利用すると色々不都合が出てきます。kintoneをお使い・導入を検討されている方は、すでにこの不都合に直面されているのではないでしょうか?

RDBMS

RDBMSは、Relational DataBase Management Systemの略ですが、データ同士の関係性を表現できるようにすることによって、非常に柔軟なデータ表現ができるようになっています。

Slide11.png

この図のように、社員名簿と所属部署を「社員No」というキー(外部キーといいます)でひもつけることで2つのテーブルの関係(Relation)を表現できるようにしています。

身近なところでは、Microsoft Accessが有名ですね。もっと規模が大きいデータベースになると、OracleやSQL Serverなどがあります。また、 RDBMSはオープンソース製品も多く、MySQL, PostgreSQLなどがよく使われています。

RDBMSのデータに対しては、SQLという言語を使ってアクセスしますが、このSQLが強力なため、かなり自由にデータを好きな形で取ってくることが可能になっています。

また、パフォーマンスやデータの一貫性という観点で見たときも、RDBMSはたくさん利用されおり、多くの人が切磋琢磨して開発してきた歴史が積み重なっているため、すばらしいものとなっています。

ただ、その反面ちゃんと学習して利用しないとパフォーマンスが出なかったり、一貫性が保てなかったりするという側面もあります。そいういう意味では、玄人向けなのかもしれません。

kintone

さて、我らがkintoneですが、kintoneは先の2つのどれにも属さない特徴を持っています。このコラムの後半では、この2つのどれにも属さないという特徴について、具体例をみながら考えていきたいと思います。

お題

ご紹介した3つのデータベースを比較するために、共通のお題を設けたいと思います。

文具の販売履歴を管理するデータベースを構築するとしましょう。実際の販売履歴としては次のような履歴があったとします。これを共通のお題として見ていくことにしましょう。

Slide3.png

エクセルでの表現 その1

エクセルでやりがちなデータの表現方法として「帳票の見た目をそのままエクセル化する」というものがあります。これを極めると行と列の幅を極端に狭くして、セル結合でレイアウトを作っていくという「エクセル方眼紙」という職人芸を手に入れることができますが、データ管理という観点で見たときにはエクセル方眼紙はよろしくないので、このコラムの読者さんは絶対に避けましょう。

Slide5.png

エクセル方眼紙ではないですが、伝票っぽいイメージでエクセル化するとこのようなイメージになります。上の部分に注文の基本的な情報が記入されて、その下に注文の明細が記入されます。注文の明細の数は注文の内容によって変わりますので、この行数は可変であるということになります。

お題に上げた他の2つの注文履歴を表現するとこうなります。

Slide6.png

さて、この方法は何が問題でしょうか?瞬間に思いつくものだけでも次のようなものがあります。

Slide7.png

シートが増えすぎるならファイル分ければいいじゃん!というケースは多くて、1つのフォルダに分けられたエクセルファイルがたくさん入っているという方もいらっしゃるんじゃないでしょうか???でも、どのデータがどのファイルに入っているかがわかりにくいので、これもあまりいい手ではなさそうです。

データを蓄積する理由は、「みんなで共有するため」「検索できるようにするため」「集計できるようにするため」が主な理由だと思いますが、この方法は、これらすべての実現を困難にします。

これは、もはやデータベースと呼べないものと思います。

エクセルでの表現 その2

「なるほど、じゃぁ表計算ソフトだから、表にすればいいよね!」ということで、こういう表現も可能です。

Slide8.png

少し表っぽくなりました。

前のやつよりはましに見えますが、どこからどこまでが1注文かわかりにくい上に、このエクセルファイルを共有して編集してしまうと、間違って行を削除したりして大変なことになります。

注文が増えてくると、どんどん表が長くなりますのでどんどん見づらくなってきます。(じゃぁ、ファイル分ければいいんじゃない?というのは上の戻ってしまうのでナシです)

Slide9.png

RDBMSでの表現 その1

RDBMSで表現してみるとどうなるでしょうか?注文の基本情報と注文明細を分ければ良さそうですね。

Slide12.png

でも、これだと20点くらいなんです。

RDBMSでの表現 その2

RDBMSでは、正規化ということを行います。詳細は省きますが、単純なイメージとしてはデータの重複をなくすようにテーブルを分割していくようなイメージです。正規化してみるとこんな感じになります。

Slide13.png

RDBMSはこの正規化の理解が1つのハードルで、過度に正規化するとパフォーマンスが出ない等の問題が出ることがあるため「正規化崩し」と呼ばれる方法であえて正規化せずに置くなどコツを掴まないと思ったような動きをしてくれないことがあります。

kintoneでの表現

さて、いよいよ今回のお題をkintoneで表現してみましょう。次のような感じになります。

Slide17.png

kintone では1つのレコードの中にテーブルを持つことができるので、注文の基本情報と注文明細は同居させることができます。これは言い換えると「1:多のリレーションは1レコードの中で表現できる」と言えます。RDBMSでは、1:多以外の関係も表現できるのですが、実際のところ世の中には、この「1:多」という関係にあるデータが多いので、これが使えるだけで表現できる幅が大きく変わります。

また、この図を見ていただくと、顧客、商品というように重複するデータは別アプリに分けてあり、そこはkintoneのルックアップという機能でひもつけてあります。

Slide20.png

このkintoneのルックアップという機能は、RDBMSで言うところのリレーションとは異なります。RDBMSのリレーションでは、外部キーをたどって関連先のテーブルを参照することで、常に最新のデータを取得することになります。kintoneのルックアップでは、データが作成されひもつけが登録された瞬間に関連先のデータがコピーされます。そのため、関連先のデータが書き換えられてもコピーされたデータは変更されません。

この動きが不便に感じるケースもあるのですが、この動作でないと困るケースも多々あります。例えば、今回の販売履歴のアプリで言うと、注文明細に商品を追加したタイミングで商品アプリを見に行って単価をコピーしてくるようになっています。これがもし、常に最新を参照するようになっていると、したじきが200円から250円に値上げになって商品アプリの価格を修正してしまうと、過去のしたじきの注文の単価を変わってしまって都合悪いですよね?

推測ですが、kintoneの開発時にどちらの動作にするかをサイボウズさんでは悩まれたと思いますが、コピーする方式の方がシステムに与える負荷が低くなるということと、常に更新が必要であればそれはカスタマイズで再度コピーすればいい(弊社のgusuku Customineを使うと簡単にできます)ので、こういう動きにされたんだと思います。

次に、見た目の感じに注意してみてください。

Slide19.png

そう、最初に見たエクセルで伝票っぽい感じで作ったものに似ています。伝票っぽい見た目は人にとってはわかりやすいと思います。kintone ではデータベース設計をすると同時に画面を作ることになりますので、正しくデータを作っていくと見た目にもわかりやすくなるという効果があります。

このように、kintoneでのデータ表現は、エクセルでやるような見た目とRDBMSのような正しいデータ構造を同居させることができます。

Slide21.png

まとめ

今回のお話をまとめつついくつかのポイントをお伝えすると次のようになります。

Slide22.png

kintoneには、エクセルの表を取り込んでアプリを作成する機能がありますが、これを使うのはおすすめしません。kintoneらしさを正しく理解した上で、正しいデータ構造を考えてみることをおすすめします。

また、kintone はRDBMSではありませんが、正規化の理解が必要です。複数のkintoneアプリに重複するデータをもたせてしまうと、二重入力などが発生し作業効率は低下します。

エンジニアの方に向けては、下2つがとても大切です。kintone の複数のアプリを複数のテーブルだと考えてしまうと、トランザクションがないことやjoinできないことが不満に思えてきます。

しかし、各々の kintone アプリがマイクロサービスだと考えることでkintoneアプリの作り方に新たな光が見えてくると思いますので、これを意識してみてください。

今回のお話のようなデータ設計が不安だという方は、弊社の gusuku Boostone をご利用いただいて、弊社のエンジニアのアドバイスを受けながらいいデータベースを構築していってください。