概念モデルと論理モデルの違い（前編） - 設計者の発言
管理会計システムの開発ツール「FusionPlace」の開発者であり会計士でもある杉本さんが、９月の「第19回関西IT勉強宴会」でたいへん興味深い発表をされた。それを聞いて、私の中で曖昧だった「概念データモデル」の位置づけがはっきりして、「論理データモデル」との違いが浮き彫りになった。この快適なスッキリ感をおすそわけしたい。 ■従来の「概念データモデル」の危うさ これまで「概念データモデル」という用語は「対象領域における重要なテーブルのみを示したデータモデル」くらいの意味で使われていた。１ページか２ページに収まるように重要なテーブルのみを置き、しばしばキーが省略された形で示される。一部を示すとたとえばこんな調子だ。 以前に書いた記事「危ういデータモデルを見破るコツ」で、概念データモデルと呼ばれる図面の上に「多対多」のテーブル関連が現れることを批判した。一部のテーブルを省略すれば必然的に「多
危ういデータモデルを見破るコツ - 設計者の発言
ひところよりもデータモデル（ＥＲ図）を作成することの重要性が理解されるようになったが、それでも形だけ整えられて納品されてしまうことがある。「納品しろと言われたからしかたなく作った」ようなモデルはヤバい。素人のイラストにもとづいて高層ビルを建てるような無茶を避けるために、危ういモデルを事前に見破るコツを知っておこう。 ただし、データモデルの「意味的な正しさ」は個別の問題なので立ち入らない。ここではその「見かけ」から危ういモデルを見破るための３つのポイントを紹介しよう。「キー設計が甘い」、「多対多を含んでいる」、「他の設計要素を支えない」といった兆候があれば注意したほうがいい。それぞれを説明しよう。 １．キー設計が甘い データモデルはデータ項目間の「関数従属性」と「ドメイン制約」を示すための図面である。それゆえに、キー属性がいい加減に設計されたモデルは役にたたない。キーはテーブルの存在証明のよ
サロゲートキーは強制されるべきものではない - 設計者の発言
複合主キーに代えてサロゲートキー（単独主キーの代替キー）を導入すべきかどうか。それはDB設計上の重要な判断事項である。なにしろレコードのアイデンティティである主キーの設定にかかわる問題だ。さまざまなメリットやデメリットを考慮してそれは判断される。その結果、サロゲートキーを導入することもあるし、しないこともある。 ところが、サロゲートキーを強制する（あるいはサロゲートキーを導入しないと開発しにくい）開発基盤がいくつか存在する。具体的には、全テーブルの識別子が"ID"等のフィールド名を持つ単独主キーであることが求められたりする。私に言わせれば、そういう開発基盤は「大盛を強制する牛丼屋」である。メニューにあるはずの「並」を頼むと、あれこれイヤガラセをされる牛丼屋。 この問題に関連して、「サロゲートキーを使わなかったから、ひどい目にあった」という開発者の声を聞いたことがあるかもしれない。心配はいら
ナチュラルキーを主キーにしてはいけない - 設計者の発言
定期的に複合主キーの話題が盛り上がるのは楽しい。好きな話題なので便乗しよう。 「複合主キーを許すべきかどうか」の議論に関して私が理解できないのが、なぜか「ナチュラルキーを主キー（一次識別子）に含めてはいけない」という話とセットで語られがちな点だ。もちろん、ナチュラルキーを主キーに含めてはいけない。だめ、ゼッタイ。しかしこれは複合主キーの必要性とは無関係な議論であって、複合主キーを回避すべき理由にはならない。 ■ナチュラルキーと人工キー ナチュラルキーについて、公開中の販売管理システムのモデルで説明しよう。まず、商品マスタの主キーは「内部商品№」である。これは、追加されるたびに自動的に発番されてセットされる項目で、ユーザの目には触れない「人工キー」だ。「Row ID」と思ってもらえばいい。 [商品] 内部商品№、品名、{品番}、．．． いっぽうユーザの目に触れる項目は、「二次識別子」とされて
実行可能な仕様書は“設計できるプログラマ”が書く
実行可能な仕様書は“設計できるプログラマ”が書く：“実行可能な仕様書”を作る！（2）（1/3 ページ） 前回、「実行可能な仕様書」を実現するための鍵が「機能パターンの確立」だと述べた。それらのパターンを有効活用するためには、DBを正規化するとともに、ビジネスロジックを機能側からDB側に移行しなければいけない。そして、ビジネスロジックを的確に仕様化するためには設計スキルとともにプログラミングスキルが必要になる。 DBを正規化することのインパクト 前回、業務システムに含まれる機能（データ処理プログラム）をいくつかの「機能パターン」に整理することで「実行可能な仕様書」が実現可能になると説明した。機能パターンごとに仕様情報のデータ様式を定め、これを処理する「仕様翻訳エンジン」と「仕様エディタ」を用意すれば、「実行可能な仕様書」のための基盤が完成する。この基盤を便宜上「アプリケーションドライバ（アプ
渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 - ＸＥＡＤ
動作環境 J2SE の1.4.* 以上が必要です(*1) WindowsXP(SP1)にて動作確認してあります 解像度1024×768ピクセルかそれ以上の画面の利用をお勧めします *1.J2SE1.4.1で起動できないケースがあります。その場合には、1.4.2以降をインストールしてください。WindowsVistaでは、1.6.0以降をインストールしてください（そうでないと文字化けします）。コマンドプロンプトで java -version と入力すれば、現在のバージョンを確認できます。そのコマンドが無効とみなされたなら、Javaがインストールされていないということです。新規にインストールするのであればRuntimeでかまいません。なお、Javaの環境設定に関して当社へ問い合わせることはご遠慮ください。 よくある質問 なぜフリーウエアとして提供しているのですか？ 当社としては、
クラウド時代に求められる 「実行可能な仕様書」とは？
Excel方眼紙の問題 業務システム開発の世界には「Excel方眼紙」と多少軽蔑的に呼ばれるものがある。行間と列間を細かく設定したExcelシートのことで、さまざまなドキュメントの汎用様式とされる（図1）。特にソフトウェアの「仕様書」を書くために多用されている。 表計算ソフトはもともと表形式の数値計算や、これに付随する文字列操作に特化したソフトウェアだ。にもかかわらず、日本においては文書作成や仕様書を書くためのツールの“デファクトスタンダード”と言っても良いほどに「Excel方眼紙」は普及している。罫線へのこだわりと同様に、これはどうも日本だけでの現象らしいことから、一部では、日本の「格子偏愛文化」が生んだものではないかとも推測されているようだ。 Excel方眼紙上で仕様書を作成するのは面倒ではあるが、セル結合やフォント指定を駆使すれば思った通りにまとめられるし、印刷してもそれなりにキレイ
「複合キー」と実装用フレームワーク - 設計者の発言
テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルＡが「社員」で、Ｃが「趣味」で、ＡＣが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の５つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [Ａ] {a}, b ＋ 100 aaa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
設計者の発言−渡辺幸三ブログ