テーブル設計がパズルのようで楽しかった

今日とっても悔しい思いをした。

さまざまな切り口でデータを表現する画面。そのさまざまな切り口に対応できるテーブル設計。いわばパズルを解くように設計するテーブル。が、そのパズルを解く事に失敗して悔しがった今日この頃。悲観的な所は一切なくて「こんちくしょー！再挑戦だ！・・・わくわく」という感じ(笑)
とあるチームの話。画面を作った。

業務的観点で画面を作ったらシステム的には非常に作りづらい作りになった。なのでシステム的観点で画面を作ったら業務的に意味が変わってしまいありえない画面になった。なので業務的観点を中心にシステムでありえる形にしたら、すっきり落ち着いた。

そこでテーブル設計をしてひとまず完成させた。画面を見てＯＫ，テーブルを見てＯＫ。ん〜？少し疑問になる部分があった。考えてみると合っているような合っていないようなすごく腑に落ちない気分になった。なので実際にテーブルを作ってみて画面設計時に想定したデータを登録して、画面に必要なデータを形成するSQLを試作してみた。

そしたらなんと！画面で必要としているデータがどうやっても形成できない！！ありえるのかこんな事…と思った。テーブルにデータがあるんだから、どう取ってくるかの違いだけで絶対出せるだろうと思っていたら出せなかった(笑)もちろん小ざかしいSQLを組み立てればできるけどそれはそもそもテーブル設計が間違っているという事。

出した結論はデータの持ち方、データの意味に矛盾があるという事。

• AテーブルとBテーブルは1:Nの関係がある。
• BテーブルとCテーブルは1:Nの関係がある。
• CテーブルとAテーブルは1:Nの関係がある。

こんな感じ。実際は5段階の関連があるデータでひとつずつ見ると矛盾はしていなさそう。だがしかし一連の流れで見てみると矛盾している。さすがに違和感を覚えただけで実際にSQLを作ってみるまで矛盾に気づけなかった。

個別の業務で考えると欲しいデータはシンプル。だけど欲しいデータの出し方にたくさんのパターンがありそれを網羅できるだろうと思って設計したテーブルはやっぱり矛盾が生じていた。グルーピングの項目が違ったり、副問い合わせが必要になるくらいまではありえるとしても、上からデータを見たり、下からみたり、真ん中だけをグルーピングしたりと個別業務で視点がばらばら。それを網羅できるテーブルはデータがいかようにでも結合できるよう分解されていないと駄目だった。これはパズルを解くみたいでかなりおもしろい。データの関連性もはっきり分かったしテーブル作り直しだ。

楽しそうだったので人のやっている事に首を突っ込んだ結果、パズルが解けなかったという話です(自分の仕事もやってますょぅ)