はてなブックマーク

マスター系テーブルの主キーにいちいち「適用開始日」や「履歴番号」が含まれているDB設計を見たことはないだろうか。品目マスターを例にすると主キーが｛品目№｝ではなく、｛品目№＋適用開始日｝とか｛品目№＋履歴番号｝のようになっていたりする。このように設計した場合、他テーブルとの間に成立しているはずの豊かな関係が見えなくなる（図１）。結果的に、システム仕様の可読性や保守性が著しく低下する。 図１．適用開始日を主キーに含むとテーブル関連が見えない ここでは「適用開始日」が主キーに含まれるケースを前提にして話を進めよう。この奇妙な設計方針を採用しているユーザ企業に話を聞く機会があったのだが、それなりの理由が２つあることがわかった。そのシステムがマルチテナント方式で顧客に提供しているサービスにおいて、各顧客が定義したマスターの更新履歴を保持することが求められているため。もうひとつは、それらのマスター値

アジャイル手法とマイクロサービス(MSA)には妙な親和性があって、ほおっておくと簡単に結びつく。ユーザ企業にとっての顧客が直接利用するSoE系のソフトウエアであれば話は別だが、ユーザ企業のバックエンド業務を支える基幹システムの開発でこれらを導入すれば、事業のDX（デジタル変容）はさらに遠のく。順を追って説明しよう。 IPAの資料「エンタープライズシステムへのマイクロサービスアーキテクチャー適用の実践」では、アジャイルとMSAを組み合わせた開発事例が報告されている。公開時期は2017年なので、まだバズワード的期待がMSAにあったのかもしれないが、それにしても評価はMSAに対して甘すぎるように思える。 甘いといえば、この手の記事でいつも思わされるのが課題選定の甘さである。この報告でもエンタープライズシステム（業務システム）への適用事例と謳っているが、取り上げられている課題が「機器管理システム」

前回記事で、一般的な業務システムの開発において、DDD（ドメイン駆動設計）が提唱する「ユビキタス言語」の実践は難しいと説明した。そもそもDDDを含むオブジェクト指向プログラミング(OOP)は、一般的な業務システムの開発には向いていない。とはいえ、企業がOOPで内製することが合理的なものは存在する。企業に売上をもたらす製品（プロダクト）系のソフトウエアだ。典型的な例が「自社サービス」の運用を支える「サービス支援システム」である。これと業務システムとの関係を見よう。 自社サービスと業務システムの関係 自社サービス、つまり、WEB上で提供される有償サービスで稼いでいる企業があるとして、そのシステム構成はどのような形になるだろう。まずは、企業システム全体の一般形について確認しておこう（図１上 参考記事）。 図１．企業システムの一般形とサービス支援システムの位置づけ この中のａがいわゆる業務システム

システム開発会社で技術者向けにDB設計について教えることがある。関数従属性に関する演習をやってもらうとわかるのだが、中堅技術者でもほとんど手が動かないことがある。さまざまな案件で設計経験を重ねているはずなのに、そういった基礎的な学びに苦労してしまうのはなぜなのだろう。 何度か経験するうちにわかったのだが、彼らにとってシステム設計に関する知見は、限られた数の具体的なシステム仕様と強く結びついている。先輩達がまとめたそれらの仕様を見よう見まねでコピペすれば、駆け出しでもそれなりの結果を出せる。いつしか脊髄反射のような反応パターンを身につけ、良くも悪くも「門前の小僧習わぬ経を読む」ようになる。 そういったやり方を続ける限り、関数従属性のようなややこしい概念を理解する必要はない。ただし、経験した範囲をはずれると勘が働かないし応用が利かない。年齢を重ねるほどに、新しい案件に対して「その分野、やったこ

RDBやデータモデリングに関する説明の中で「リレーションシップ」と言うべきところで「リレーション」と表現する誤用が目立つ。どうでもいいような違いに思われるかもしれないが、これらは明確に区別されるべきだ。そうでないと、RDBの用語の意味がわからなくなるからだ。 IBMのフェローであったE.F.コッド(1923-2003)による1970年のの歴史的論文 "A Relational Model of Data for Large Shared Data Banks" （大規模共有データバンク向けデータのリレーショナル・モデル。杉本さんによる対訳）によって、世界で初めてRDBの理論的枠組みが示された。この論文で使われている用語"relation"が、RDB（relational database)の呼称の由来である。 relationとは何か。その論文でコッド博士は、１個のテーブルに格納された行(

データモデルに「概念モデル」、「論理モデル」、「物理モデル」の３種類があることは広く理解されている。しかし、これらを律儀に作成・保守しているプロジェクトがどれだけあるだろう。ただでさえデータモデリングはないがしろにされがちなので、３種類のデータモデルを作成しているプロジェクトなど例外的といえそうだ。それもそのはずで、全種類をコンプリートすることに意義がないとはいえないが、コストパフォーマンスが悪すぎる。どういうことか。 3種類のデータモデルを作成・維持するためには多大なコストがかかるが、コストの投入量と効果の関係は図1のようになる。経済学でいう収穫逓減の法則がここでも働いている。データモデリングすることで設計品質もプロジェクトの成功率も向上するが、手間が増えるにしたがって効果は頭打ちになる。「全種類コンプリート」を達成するようなレベル(a)より少ないコストで極大値に近い効果を得たい(b)。