数回に渡って番号（コード）をシステムでどう扱うのかを考えてきました。
このようなことでも、常に選択肢はいくつもありますし、ひとつひとつをどういう視点で選択決定していくかもシステムエンジニアに求められる能力だと思っています。
これまでのシステム開発では、取引先ひとつをとっても主キーとなる取引先コードや、取引先分類のキーとなる分類コードをどう設定するかというのが非常に大事な要件でありました。
システムを設計する場合、そのシステムを稼働しようと見ている期間は5～6年くらいであり、5、6年は企業の組織やビジネスモデルがそこまで大きくは変わらないであろうということがありました。
もちろん、システムはハード・ソフト含めて非常に大きな投資になるのでリースとして扱われることも多く、そこから5年という期間がいつの間にか決められていたのかもしれません。
しかし、ハードを5年間使い続けるのは、時代の流れや要求と比べると限界に近くなっています。
アプリケーションも、5年同じ考え方のものを使っていけるのでしょうか？
実際には、かなり無理をして使っていらっしゃるところが多いのではないでしょうか。
特に組織替え、新しいビジネスへの参入が問題になるではないでしょうか。
得意先であろうと商品であろうと、新しい分類方法、集計方法が次々に生まれてくるのが企業の業務実態ではないでしょうか。
そうした新しい集計は、どのように実現されているのでしょうか。
それは、ローカルのExcelであり外部システムとしてのBIツールを使っているのに違いありません。
それはそれで一過性のものとして、また、ひとつの企業システムの成長プロセスとしては役に立つものだと信じます。
しかし、そのうち全社でできるだけリアルタイムに近い状態でデータを参照し、さまざまな形でデータを集計できるシステムがほしいと思いますよね。
ここで、これまでのデータモデリングとはちょっと考え方を変えたものが必要になってくるのではないでしょうか。
あくまでも、ひとつのアイデア、提案としてお聞きください。
1）全エンティティの主キーには、得意先コード、伝票番号といった現実に存在するコードを使わない。つまり連番にしてしまう。
2）得意先コードをソート順や意味があるコードとして使う場合は、別に得意先コード＋連番といったコードを紐付けるためだけのエンティティを持つ。
3）分類コードや集計コードも2）と同様なエンティティを作成する。
分類コード＋連番
集計コード＋連番
この3）を自由に登録できるようにします。
ただし、この考え方で設計する場合、ジャーナルの中に（集計レスポンスを高めるため、もしくはその時点の集計コードを保存するため）持っている分類コード、集計コードをどう考えるのかといったことが別の問題として出てきます。
特に、半期、期といった締期間とコードとの関係性は重要なポイントです。
また、得意先マスタ、商品マスタ、社員マスタといったマスタテーブルを修正・変更する運用条件を洗い出す必要があります。
もっと突っ込んでメリット・デメリットを考えることが必要でしょうが、マスタの主キー、集計コードについて固定観念を打ち破って考えてみることもたまには必要だと思っています。
Vol.00161