複合主キー「否定派」と「許容派」の論争 - 設計者の発言
定期的に取り上げたくなるDB設計に関する話題である。WEBアプリが一般化して以来、議論されてきた事柄がある。テーブルの主キーを「単独主キー」のみとするか、複数項目を組み合わせた「複合主キー」を必要に応じて使うべきかという問題だ(*1)。複合主キーに対する「否定派」と「許容派」に分かれた議論は劇烈で、宗教論争のようにも見える。 主キーというものは、テーブルの存在意義といってもいいほどに重大な要素である。にもかかわらず、なぜそんな基本的なレベルの議論が始まってしまったのか。２つほどの理由が考えられる。 まず、単独主キーとしてIDを機械的に置くやり方（ID方式）が「オブジェクト指向」と相性がよかったからだ。オブジェクトは固有の識別子（オブジェクトID）を持つので、これに相当するIDをテーブルの主キーとすることで、オブジェクトとDBの設計問題を統合できると考えた技術者が少なからずいた。そのアイデア
モデリングのスタイル：意味論と統辞論 - 設計者の発言
ＤＯＡ（データ中心アプローチ。ＤＢシステム設計においてＤＢ構造の検討を優先させる手法）の考え方では、それぞれのテーブル（エンティティタイプ）について、「リソース」か「イベント」かを区別するやり方が主流である。 主流派の向こうを張ろうってわけでもないのだが、筆者はデータモデリング手法の前提としてそれらを区別しない。なぜかというと、それらの区別が各テーブルの「絶対的な特性」ではなく、「相対的な傾向」でしかないと考えるからだ。ある文脈ではイベントとみなされるテーブルが、別の文脈ではリソース的なものに見えるなんてことが実際にはある。 たとえば、イベントの代表であるような「受注」や「売上」も、一定期間向けキックバックの計算過程においては、「顧客」同様にリソース的なものとして見える。また、リソースの代表であるような「品目」も、品目分類や商品企画を云々するモジュールにおいてはイベント的なものに見える。
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
関数従属性は多重度に先行して認識される - 設計者の発言
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるＯＲマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次ＴＴＭレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
在庫引当から在庫推移へ（前編） - 設計者の発言
在庫管理分野でのデータ項目として「有効在庫（利用可能在庫）」と呼ばれるものがある。現在庫数量から「直近の出荷予定数量」を差し引いて得られる値を、事実上利用可能な在庫数量とみなして管理する。現在庫には直近の出荷予定が「引当」されていると考えるわけだ。式で表せば次のようになる。 有効在庫数量＝現在庫数量－Σ(直近の出庫予定数量) 現在庫が１００個だとして、直近での出荷予定が合計７０個だとすれば、有効在庫は３０個である。この時点で５０個の注文があったとする。有効在庫が３０個であることを知っていれば、すぐに出荷できる分３０個と、将来の入荷後に出荷できる分２０個とを分けて受注するといった事前の交渉が可能だ。いっぽう有効在庫を認識していないとすれば、すぐに出荷できる受注として５０個分をひとまとまりとして受け付けてしまうだろう。結果的に、出荷時点で欠品に気づいてあわてるハメになる。 在庫数量が規定レベル
Ａｊａｘで業務マニュアルサーバ - 設計者の発言
◆システムの設計情報は業務マニュアルのデータベース 何回かに渡って説明したように、業務システムの設計情報には「業務マニュアル」が含まれている。そして、それらの情報が的確に構造化されているならば、システムの設計情報はそのまま「業務マニュアルのデータベース」となり得る。 ＸＥＡＤのコンテンツファイルも「業務マニュアルのデータベース」である。それを専用のＡｊａｘモジュールとともにＷＥＢサーバにアップロードすれば、たちどころに次のような「業務マニュアルサーバ」が出来上がる。ＸＥＡＤをインストールしてある読者は「サンプル社販売管理システム(sample.xead)」のＸＥＡＤ上での業務定義の見え方と比べてみてほしい。 「サンプル社販売管理システム」の業務マニュアル（ＩＥ６専用Chrome専用） Ａｊａｘアプリとしてはひどく単純だし華やかさにも欠ける。しかし、いくつも定義される業務単位毎のマニュアルが
業務マニュアルの作り方 - 設計者の発言
業務マニュアルをまとめるのは想像以上にやっかいな仕事である。とくに、コンピュータを用いて進める業務の場合、パネルや帳票（これらを合わせて入出力フォームと呼んでおく）の使い方を盛り込む必要があるのでややこしい。仕事の手順の軸、入出力フォームに関する説明の軸、および各手順における入出力フォームの使い方の軸とが複雑に交錯する。コンピュータ上の業務システムの仕様を巻き込んで周到に構造化しない限り、使いやすく保守しやすい業務マニュアルは生まれない。 ◆業務フローと業務マニュアル そもそも業務マニュアルとは何か。それはいわゆる「業務フロー」とはどう違うのか。まず、筆者が提唱する三要素分析法での、業務フローと業務マニュアルの位置づけを確認しておく。データフローダイアグラム（ＤＦＤ）で描かれた業務フローには、いくつかの「業務プロセス（個々の仕事の単位のこと）」が載っているが、それぞれの業務プロセスのあり方
家計における「資本勘定」とは（前編） - 設計者の発言
簿記システムでは、さまざまな取引が「仕訳」として入力され、帳簿組織に集計されるようになっている。仕訳毎の「貸方・借方」の金額が一致していることから、簿記は「貸方・借方」の二元論と思われがちであるが、この理解はまったく不正確である。 簿記は「貸方・借方」の次元と「ＢＳ（貸借対照表）・ＰＬ（損益計算書）」の次元とが交差する４象限を基礎とする、「四元論」とも言うべき体系である。それらの象限には以下のような呼び名がある。 借方 貸方 ＢＳ 資産 資本・負債 ＰＬ 費用 収益 というわけで簿記は、「収益」、「費用」、「資産」、「資本・負債」の４つの勘定グループ間の振替を記録したり、振替にもとづく残高（合計額）の変化を捉えるための体系である。 具体的に見てみよう。たとえば、現金１００万円を元手に会社を起業したなら、その時点で次のような取引が認識される。 ＜仕訳１＞ 現金１００万円／資本金１００万
プログラマではなくテスターとして現場デビューする - 設計者の発言
筆者はプログラミングは好きだったが、テストについてはずっと苦手意識があった。プログラムがそれなりに完成してしまうとそれで満足してしまって、さっそく次のプログラムにとりかかりたくなる。結局、システムテストの段階でハデにバグが見つかってどれだけ周りに迷惑をかけたかわからない（今思い出しても冷や汗が出る）。「自分に代わってテストだけをやってくれる要員」がいてくれたらと本気で願っていた。 だから、１年前にある小さなソフト開発企業で、「新人をまずテスターとしてみっちり仕込むようにしている」と聴いたときは感心した。その発想は考えれば考えるほど合理的かつ発展的だ。筆者なりに肉付けした形で紹介したい。 ◆新人は現場のお荷物である 多くのソフト開発企業での新人教育が何から始まるかというと、大学の一般教養課程のような「コンピュータ概論」だったりする。その後に「ソフトウエア分析・設計」とか「プログラミング」の学
要件を要件として深追いしてはいけない - 設計者の発言
ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。 ◆スクラッチ案件での要件の位置づけ 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。 そのような案件向けであっても、要件の扱い方は２つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手（からめて）を用いるやり方。便宜上、前者を「Ａ方式」、後者を「Ｂ方式」と呼んで検討しよう。 ◆要件をじっくりモデル化するＡ方式 上流工程手法の多く
分析設計手法のスタイルとオフショアの脅威 - 設計者の発言
顧客との打合せの場でどんどんモデリングするやり方を「その場方式」と筆者は呼んでいる。いっぽう、ユーザからヒアリングしたことをメモして持ち帰って机上でモデリングして、次回の打合せでその結果を示して検討するやり方を「持ち帰り方式」と呼んでいる。「持ち帰り方式」で対応できる案件も一定の比率で存在するので、そればかりを受注できる職場にいるのなら「その場方式」を身につける必要はない。しかし、「持ち帰り方式」の実践者はオフショアの脅威にさらされていることを知っておいたほうがいい。 ◆スクラッチ案件とリプレース案件 「持ち帰り方式」が有効なのは、メインフレームのオープン化プロジェクトを典型とする「リプレース案件」だ。顧客の生の声よりも、既存のコンピュータ内部のあり方をじっくり調査することで新システムを構想できる。もともと使っていたシステムが使いやすいものだったのであれば、新システムは「建材の刷新された住
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
