自由であるためにドキュメントを作る - 設計者の発言
前回記事で、ドキュメンテーションを重要視しない開発業者を避けるべきだと指摘した。同様の問題は、業務システムを内製した場合にも生じている。むしろ、ドキュメントレスな困ったシステムは、内製で生み出されているケースのほうが多いような印象が私にはある。 ドキュメントレスなシステムが重大なリスクを抱えていることを、ほとんどの経営者は認識していない。なぜなら、ドキュメントレスであってもシステムのあり方は内製担当者の「頭の中」に入っているので、彼に頼めば必要な改修はやってもらえるからだ。結果的に業務システムが、担当者のエンプロイアビリティ（雇用意義）を強化するための政治的ユーティリティと化すことを許してしまう。その歪みは、担当者がいなくなったときに一挙に顕在化する。いなくなった当人としては「後は野となれ山となれ」である。 業務システムがドキュメントレスになりがちな根本的な理由は、まさにここらへんにある。
アンチパターン「成長する主キー」 - 設計者の発言
我ながらしつこいが、またまたテーブルの主キーに関する話題である。「複合主キー」を毛嫌いする開発者がいるとすれば、その根拠はおおむね２つある。「ID等の単独主キーにしておけば、主キーの仕様変更に振り回されない」、および「複合主キーにすると実装が煩雑になる」だ。それぞれについて反論しよう。なおこれらの他に「ナチュラルキーを主キーにすると値が変わったときに困るから、複合主キーはダメ」と説明されることがあるが、こちらは非論理的なので取り上げない（詳しくは「ナチュラルキーを主キーにしてはいけない」を参照）。 ■成長する主キー まず「ID等の単独主キーにしておけば、主キーの仕様変更に振り回されない」についてだが、この主張は一面的には正しい。じっさい私自身、複合主キーの仕様変更に振り回された思い出がある。 新人の頃、ある重要なテーブルを処理するアプリをプログラミングしていた。仕様書にしたがって検索すると
実装スキルと業務知識を統合するために - 設計者の発言
９０年代の後半以降、WEBアプリの実装技術が急速に発展した。そのおかげで、それまで使いにくかったHTMLページを業務システム（基幹業務支援システム）でも使えるようになった。それはそれで意義深いことではあったが、いっぽうで若手の技術者から業務知識の学習機会が奪われてしまった。いったい何が起こったのか。 ソフトウエアの適用分野毎に、技術者に求められる専門性は異なる。「組込ソフト」の分野であれば、ハードウエアの動作や利用に関するさまざまな専門知識が要るだろう。「音楽ソフト」向けには、MIDIやサウンドデータに関する専門知識が求められそうだ。業務システムの開発者であれば、いわゆる「業務知識」が求められる。具体的には、簿記、DB設計、業務プロセス設計といった知識やスキルだ。業種・業態を越えてシステム要件を仕様化するためには欠かせない素養である。 ところが現在のWEBアプリの開発現場において、日常的に
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
「複合キー」と実装用フレームワーク - 設計者の発言
テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルＡが「社員」で、Ｃが「趣味」で、ＡＣが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の５つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [Ａ] {a}, b ＋ 100 aaa
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
