主キーが決まらないとき
マーチン・ファウラーの著書、アナリシスパターンの最初の方に、こんな記述があります。
概念モデリングではドメインエキスパートの参加が「不可欠」である。筆者は、効果的なモデルを組み立てられるのは問題領域を本当に理解している人、つまりその問題領域を「生業(なりわい)」としている人だけであると考えている。
(中略)
情報技術の経験はモデリングの技能にとって毒にも薬にもならないことがわかった。筆者の知っている最高のモデラーはロンドンのある外科医である。
海外だと違うのか、ユーザが違うと違うのか*1、ユーザがちゃんと要件出せて、分析設計できてるところがもしあるなら、凄いしうらやましいなー、と思います。
で、僕はお仕事で、DB 設計と、そのDBとやりとりするWeb-API を書いているのですが、表題にも書いてるように、「主キーが決まらない」ということが起こりました。
いや、正確には、「○○単位で見たい(or 更新したい)」っていうのが出てはいるのですが、従来の画面と明らかにミスマッチしているし、僕の直感とも「ちょっとちがうなー」って思ったりして、案の定、次の日に、「やっぱりここは△△で」とか言われたりして、まあ主キーに相当する項目が決まらないわけです。
で、その上諸事情あって、締切りは変えられなくて*2、それなので、無理やりでもキーを決めないと DB も API も作れない。
なので、色々悩んで、こんな仕組みを考えた。
僕の業界用語で説明すると伝わらないので、みんな分かりそうな小売業っぽいモデルで説明すると、例えば、ある製品の「発送単位」「受注」「受注明細」「部品」みたいな単位があるとします。(で、この順に細かくなっていくとします)
で、僕の今の状況は、「A画面では受注単位」、「B画面では部品単位」、「C画面では受注明細単位」みたいなことを言われていて、それが日々変わるような、そんな状況です。
そんな状況なので、DB 側では最小単位(この例だと「部品」)で、主キーを設定し、参照のAPI ではそれぞれのキーをどれを使っても参照可能にし、更新の API には「更新単位」というパラメータをつけて、それに応じて同一の受注などを更新できるしくみをつけてみました。
まだリリースはしていないので、この先どうなるか分からないけど、今のところうまく行っているみたい。
これが「常識」なのか「バッドノウハウ」なのか「世紀の大発明」なのか「トンチンカンな設計ミス」なのか良く分からないけど、今まで勉強してきた中では見ることができなかったパターンだったので、書いてみた次第。
みんなこういうときはどうしてるのかなー？
