複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
「ユース・ファースト」なシステム開発 - 設計者の発言
「販売管理システム」や「生産管理システム」といった基幹システムを開発する場合、基本設計よりプログラミングを先行させるアジャイル系のスタイルは向かない。「動くシステム」は「動くプログラムの集まり」ではある。しかし、「動くプログラム」を作って集めたものが「動くシステム」であるとは限らない。そのシステムは、各部屋の住み心地がいいわりに、完成した翌日に自重で崩壊するマンションのようなシロモノであり得る。一般に、一定以上複雑な工学的構築物向けに、組み立てながら基本設計をまとめるといったカジュアルな手法は通用しない。 ただしこれは「レファレンス・システム」を用いない場合の話。ここでいう「レファレンス・システム」とは、オープンパッケージとして提供される「完成していて実際に動くシステム」のことである。オープンパッケージであるゆえに、データモデルや業務マニュアルといった基本設計情報も添付されている。そういう
「何かと便利」な設計方針？ - 設計者の発言
データベースの「正規化崩し」の理由としてしばしば聞くのが「何かと便利なのでこのようにした」である。 たとえば、次のような関数従属要件があるとする。 これが、たとえば次のように物理設計される。 なぜテーブルＤやＤＦに、本来並ばなくていい項目がごそごそ並ぶのかと問うと、「これらを置くことで、関連テーブルを読まずに値が手に入る。プログラムがシンプルになるし、何かと便利だろうから」と説明される。 この種の設計の妥当性を吟味するためには、「継承属性」と「スナップショット項目」の違いを理解しておく必要がある。継承属性とは、あるテーブルから見て多重度１のテーブル上に載っている項目（テーブルＤから見ればＡ、ＤＦから見ればＡとＤ）のことで、インデックスを張るとか参照キー制約を組み込むといった明確な目的にもとづいて実装される。実装された継承属性については、もともと載っていた項目の値が変更されたら、すかさず値を
少人数開発と「能力プール」 - 設計者の発言
■少人数プロジェクトが儲かる理由 開発案件の最終利益率とプロジェクトメンバー数には一定の相関がある。開発に関わったメンバーの数が少ないほど、一般に利益率は高い。実際に数字で調べてみたわけではないが、筆者の過去の経験からも確信できるし、そのように思い当たる人も多いだろう。 その理由は単純である。メンバーが多いほど、メンバー間の情報伝達のためのコスト（情報コスト）が飛躍的に増えるためだ。指示やいわゆるホウレンソウのための初期コストだけでなく、訂正や伝達ミスにともなうさまざまな後追いコストが、人数の多いプロジェクトほど大きくなる。メンバーが２人のときに情報コストが１だとすれば、（１人のときなら０）、人数に従って次のようにコストは増えてゆく。 ２人 １ ３人 ３ ４人 ６ ５人 １０ ： ： ｎ人 n(n-1)/2 たとえこの事実が理解されていたとしても、これらのコストを考慮して工数積み上
「オーバースペック」でコストが下がる話 - 設計者の発言
「革新的生産スケジューリング入門」や「ＢＯＭ入門」といった、生産管理に関する優れた著作を書かれた佐藤知一さんと神戸でおしゃべりしてきた。さすが「工場そのものの開発」に携わってきた佐藤さんだけあって、面白い話をいろいろと聞かせていただいた。それらの中から、設計者のまっとうなコスト感覚が建設現場での障害をもたらすという話を紹介したい。 佐藤さんが本業で扱う化学プラントにおいて、いちばん目に付く部品は「パイプ」である。素人には想像を絶するが、その種類はじつに４千点にものぼるのだそうだ。口径や長さはもとより、壁面の厚さや付随するバルブの仕様だのなんだのが順列組み合わせ的に関係するためだ。 で、プラントの設計者は、要求性能にぴったり沿うパイプを用いて各モジュールを設計する。たとえば１００の強度を要求する部分には１００の強度を保障するパイプを組み込む。あたりまえの話だ。そんなところに２００の強度を保障
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
関数従属性は多重度に先行して認識される - 設計者の発言
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるＯＲマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次ＴＴＭレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
「科目履修管理」のレファレンスモデルが登場 - 設計者の発言
教育関係者に朗報である。四年制大学向けの履修管理システムの基本設計情報「ＣＯＮＣＥＰＴＷＡＲＥ／科目履修管理」が、この夏に公開される。同時期に出版する本（システム設計の練習用問題集みたいなもの）で扱われている業務要件にもとづく連動企画である。３年前に書いた「上流工程入門」では、基本設計書の一部を図版として示すだけだったが、今回は無償のモデリングツール「ＸＥＡＤ」で閲覧・編集できる設計コンテンツとして誰でもダウンロードできるようになる。大進歩である。 システムの規模としては、テーブル数２０、機能単位数４０程度と小さめだ。「ＣＯＮＣＥＰＴＷＡＲＥ／財務管理」のテーブル数８０、機能単位数２７０と比べると、その小ささがよくわかる。しかも、「財務管理」は簿記の知識がない人にはチンプンカンプンだろうが、「科目履修管理」は業務としてわかりやすい（かといって単純すぎるわけではない）。 その本には「科目履修
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
