タグ

ブックマーク / watanabek.cocolog-nifty.com (5)

  • 「シンプル・イズ・ベスト」はややこしい - 設計者の発言

    データモデルは「シンプル・イズ・ベスト」ではない。データモデルを下手にシンプルにすると、他のモデル要素(業務モデルや機能モデル)が無駄に複雑化するからだ。システム仕様にはある種の「複雑さの保存則」があって、何かをシンプルにすると別の何かが複雑になる。 その中でもとくに「機能モデル」が複雑になると、コード量が増えてシステムの保守性が顕著に悪化する。ゆえに、データモデルをシンプルにしておく戦略は不適切である。コツとしては、データモデルを精緻に正規化したうえで、その後で必要に応じてシンプルな形に調整する手順を踏むとよい。そうすることで、より多くのシステム要件をデータ構造の形で回収できるからだ。 いちばんまずいのが、じっくり考えることをせずに最初からデータモデルをシンプルにまとめてしまおうとする姿勢だ。その典型例が「森羅万象テーブル(*1)」や「IDリクワイアド(*2)」と呼ばれるアンチパターンで

    「シンプル・イズ・ベスト」はややこしい - 設計者の発言
    mantax
    mantax 2014/06/21
  • 売上計上基準の設計と実装 - 設計者の発言

    商品を販売する過程で、厳密にはどのタイミングで売上計上が起こるのだろう。スーパーでは商品をレジに持っていったときに売上計上される。B2B(business to business,企業間取引)ではもっとややこしく、「計上基準」によって違う。すなわち、出荷基準(売り手が出荷した時点で売上計上)、納品基準(買い手に渡した時点で売上計上)、検収基準(買い手が検収した時点で売上計上)、といったタイミングの違いが生じる。 売り手にとっての売上計上は買い手にとっての「仕入計上」なので、来であればこれらの事象は同時に起こるはずだが、会計基準において仕入計上と売上計上の同時性は大きな問題にならない。業務システムの多くは、顧客側の仕入計上基準に関係なく単一の売上計上基準で処理している。 国際会計基準(IFRS)では売上計上基準の適用厳格化が図られるため、業務システムが単一の売上計上基準では処理しきれなくな

    売上計上基準の設計と実装 - 設計者の発言
  • サロゲートキーは強制されるべきものではない - 設計者の発言

    複合主キーに代えてサロゲートキー(単独主キーの代替キー)を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する(あるいはサロゲートキーを導入しないと開発しにくい)開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら

    サロゲートキーは強制されるべきものではない - 設計者の発言
  • 「有効期間」を含むテーブルとの参照関係 - 設計者の発言

    一次識別子に「有効期間」が含まれることがある。そんなテーブルに対して関連を張ってゆくと正規化違反を生じてしまうケースがある。これを避けるためには「動的参照関係」の知識と、これに対応した開発基盤が必要だ。よほど単純なDBでない限り「動的参照関係」のデータ要件は出現するものなので、実務者としてはしっかり理解しておきたい。 まず、有効期間とキーとの関わりを整理しておこう。「商品値引テーブル」を例にした場合のモデリングパターンをいくつか挙げよう。{...}内はキー(一次識別子)を表している。 (1)開始日・終了日ともに属性 [商品] {商品ID},商品名,... +   12345 全自動漬物石TS100 | └―…[商品値引] {商品値引ID},商品ID,開始日,終了日,値引率,... 000001  12345 07/01 08/31  15 000002  12345 08/01 09/30

    「有効期間」を含むテーブルとの参照関係 - 設計者の発言
    mantax
    mantax 2011/12/08
  • 「アジャイルなスクラッチ開発」ではダメ - 設計者の発言

    他のソフトウエア分野についてはわからないが、売掛・買掛・在庫・原価といった会計要素を統合的に管理するためのしくみ(基幹システム)の開発については、はっきり言えることがある。ウォーターフォール手法(WF)に替わるやり方としてアジャイル手法を導入しても、それが「スクラッチ開発(いちいちゼロからシステムを作るやり方)」である限り、状況はたいして変わらない(もっと悲惨なことにならなければ幸運というものだ)。 基幹システムの開発に関して、アジャイル手法に救いを求めようとする人たちの初歩的な勘違いが「WF元凶論」である。これまでの開発プロジェクトがなかなかうまくいかなかったのは、やり方が悪いからだ――そこまでの観察はおおむね正しい。しかし、そこからWFこそが元凶と断ずるのは短絡である。 それは、今にも崩れそうな石橋を前にして「<石橋を叩いて壊す>ような慎重でおおげさな渡り方はやめて、軽やかにスキップし

    「アジャイルなスクラッチ開発」ではダメ - 設計者の発言
    mantax
    mantax 2011/10/03
  • 1