すごく・・・紙文化ですKenichiro Ota @oota_ken CoreBanking Renovation Framework...., これが真のMDDのなのか！いきなりビジネスエンティティのライフサイクル分析から始まる！僕がやりたかったのはこれか！さらばExcel方眼紙！ 2010-03-27 20:48:56
『ドメインモデルに対する日米の温度差』
マーチン・ファウラー氏によれば、アプリケーションの中核部であるビジネスロジックを構築する方法には、Transaction ScriptパターンとDomain Modelパターンの2通りがあるという。Domain Modelパターンは、データと振る舞いを1つのオブジェクトにまとめ、オブジェクト指向のテクニックを駆使するやり方だ。一方のTransaction Scriptパターンでは、データと振る舞いは別々のオブジェクトに分け、振る舞いをスクリプト的に淡々とプログラミングしていく。 日本ではTransaction Scriptが優勢 この2通りのうち、日本ではTransaction Scriptパターンの方が優勢だ。日本のオピニオンリーダーも軒並みTransaction Scriptを薦めている。 たとえば、Seasarの開発者であるひがやすを氏は、古くからデータと振る舞いを分離するアプローチ
【Rails関西】Rails屋からデータモデリングに対する回答 - プログラマの思索
1/20に開かれた第6回RubyOnRails関西へ行ってきた。 場所は神戸電子専門学校。目の前にオランダ館、風見鶏館などの異人館があり、華やかな場所でした。 このたびの発表の中で最も興味を引いた講演が「やさしいRailsの育て方」(by 西和則さん)。 講演内容は、Railsでもテーブル設計をきちんと考えましょう、ということなのだが、それは昨年8月の渡辺さんの指摘に対する回答になっているように思う。 【1】RDBのテーブル設計におけるアンチパターン Railsをやっていると、例えば、下記のアンチパターンに囚われてしまう。 １・無限ＦＫ地獄や列破綻 テーブルに他テーブルの外部キーをどんどん持たせると列が増えていく。 西さんの例では、社員テーブルに派閥1、派閥2のカラムを増やしていた。 ２・フラグステータスとバタフライ効果 「北京で蝶が羽ばたくとニューヨークで嵐が起きる」がその意味だが、「小
DB Magazineの良記事 - 極北データモデリング
何ヶ月か前から、Struts + DI + O/Rマッパーのサンプルアプリケーションを集めている。 ソースがあるだけではダメで、なんでそういう設計になっているのか、作者の説明付きのものを探している。 で、DB Magazine 7月号の「DIコンテナをベースにしたアプリケーション実装モデルの作法」が、ぴったりの記事だった。 サンプルアプリは、特定顧客の売上情報(ヘッダ＆明細)を一覧する、というもの。 読みたかったポイントは２点。 このサンプルアプリは、データアクセス層が返すentityクラス(データベーステーブルと1対1に対応するJavaクラス)と、サービス層が返すdtoクラスを別々に作成しているが、それはなぜ、と説明しているか。また、entityクラス <-> dtoクラスのデータの詰め替えは、誰がどのように行うのか。 現代的なO/Rマッパーは、(業務アプリでは必然的に発生する)集計行を
Tags: Database schemas
An online tech community is the most exciting place for a software developer to spend their time. It not only offers the chance to work and interact remotely, but also helps in honing one’s own skills and becoming a well-rounded programmer. Whether you are a budding software developer or simply passionate about technology, here are the best online software development communities you can join. The
利害関係者の目的を可視化するプロセス
第1回（「視点を分けて業務システムを可視化」）は、この連載の入門編として、視点を分けて業務システムを可視化することの全体像について説明しました。また、モデルの具体的なイメージを持っていただくために、モデルを活用したRFP（モデルベースRFP）のサンプルを紹介しました。適宜、参照してください。
フラグを属性にするか、リレーションシップにするか - 極北データモデリング
オブジェクトモデリングで何だかよく分からないことに、あるデータ項目を属性にするか関連にするかの基準があいまい、というのがある。 怪しい世界だなあと思って見ていたが、考えてみるとデータモデリングの世界もおんなじです。 あるデータ項目を「属性にするのか、新しいエンティティを生成してそこに入れるか」が、流派によって違う。 どの流派も正規形であることは変わらないのだが... 例えばRDBでは、区分コード＝いわゆるフラグを、別のテーブルとのリレーションシップで表すことができる。 で、あんまりやったことないけど、これからは区分コードを極力排除して、区分をリレーションシップで表現することにしようと思ったのです。 例 商品マスタの中に、現役商品と廃盤商品の両方が入っているとする。 商品マスタ = { 商品ID(PK), JANコード, 商品名, 廃盤区分(Yes/No) ... } また、商品を集めてカタ
Using DBDesigner to generate Rails files | Bill Katz
An occasionally updated repository of thoughts, past work, and links. Topics include programming, web ventures, and writing. dbmodel is a tool to generate Rails files (models, scaffolds) from a free graphic database design tool, DBDesigner 4. You can create tables in DBDesigner, specify table relations, synchronize the model with a MySQL database, and then use dbmodel to automatically generate cod
エンティティの見出し方・属性の割り振り方 - 伝統的設計・T字形ER手法・ABD - 極北データモデリング
非正規形の表が与えられたときに、その表を出力できるDBをどうやって設計するか。 伝統的DB設計法・T字形ER手法・ABDのやり方を並べて書いてみる。 伝統的DB設計法 伝統的なDB設計では、非正規形の表を正規化する過程で、エンティティを切り出していく。 また正規化しながら、関数従属性に従って属性を割り振っていく。 データ項目の意味は考えず、データ項目の重複が最小になるように分解するので、m:nの関係の時以外は交差エンティティは発生せず、「社員マスタに所属部門コードがある」といった結果になる。 T字形ER手法 上記を問題視したのがT字形ER手法。 T字形ER データベース設計技法 P-26 ER手法が大きく勘違いされた点は、データを正規化してから、ER手法を使ってデータ構造を表現する、という点にある。 つまり、ER手法が表現手段に成り下がってしまったのである。ER手法は、思考手段(解析手法)
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
capsctrldays - フリーのERDモデリングツール：Toad(TM) Data Modeler , メモリとモニタが欲しい！
1 [DB] フリーのERDモデリングツール：Toad(TM) Data Modeler via The Joel on Software Discussion Group - Free Database Modeling Tool? 無料のERDツールってDBDesigner4くらいしか使えるものがなかったんだけど、これはいいなあ。論理モデルと物理モデルを描けるのがいいなあ。論理モデルは日本語で、物理モデルは英語表記で、ってなことができる。それに、いろんなRDBMSをサポートしてる。これぞ求めているものだなあ（烏足記法なのがイヤだけど）。 画面はダサいけど、レポート出力したやつはなかなかカッコヨイ。 有償版になると、リバースエンジニアリングができて、DFDが描けるようになるそうな（要らないよね）。 追記 いつからかフリー版は無くなってる？ 以前のバージョンをダウンロードできるサイトがあ
関数従属性は多重度に先行して認識される - 設計者の発言
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるＯＲマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次ＴＴＭレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
【感想】RubyOnRails 勉強会@関西とデータモデリング - プログラマの思索
デスマーチ・プロジェクトに束の間の休日ができたので、RubyOnRails 勉強会@関西に初参加してきた。 Ruby勉強会＠関西と同じく、女子学生や女性エンジニアも多くて、華やかな雰囲気で、講演も甘辛だった。 僕はRubyOnRails初心者なので、聞きやすかった。 聴講の目的は、もちろん渡辺さんの「アジャイルにデータモデリング」。 「何故、RubyにDOAの第一人者の渡辺さんがいるの？」みたいな。 【1】RubyOnRailsに、複合キー(複数の識別子)を持つテーブルはない！？ 渡辺さんのお話は、業務システムとデータモデリングの関係から始まり、テーブルの項目の関数従属性の説明と演習まで、というとても初心者向けの講義。 懇親会で業務に携わっていると言うエンジニアの女性が、 「私はRailsのインストール方法も知らない初心者だが、渡辺さんが話した関数従属性や正規化の話はとても基本的な話です」
オブジェクト指向プログラムのためのパターン言語の使用
以下の文章は、Kent Beck、Ward Cunninghamによる「Using Pattern Languages for Object-Oriented Programs」の日本語訳である。 Ward Cunningham氏の許可を得て、ここに掲載する。 Kent Beck, Apple Computer, Inc. Ward Cunningham, Tektronix, Inc. Technical Report No. CR-87-43 September 17, 1987 Submitted to the OOPSLA-87 workshop on the Specification and Design for Object-Oriented Programming. 概要 オブジェクト指向プログラミングへのパターン言語の適合について概説する。ウィンドウ・ベースの
AspectによるDesign by Contract - 檜山正幸のキマイラ飼育記 (はてなBlog)
以前（4月3日）、「AspectJによる契約駆動開発 (準備＋蘊蓄編) 」、「AspectJによる契約駆動開発 (実験編）」というエントリーを書いたのですが、それに対して“通りすがり”さん（なんでもいいからハンドル付けて欲しいな）に、有益な情報を提供していただきました。ありがとうございます。 まず、消滅してしまったと思ったiContractが、iContract2として最近復活したようです。 iContract2 (http://www.icontract2.org/) "iContract2 is a revival of Reliable System’s iContract project"とのこと。 さらに（by 通りすがりさん）： iContract2 のソースをちらっと見てみたけど、自前でソースをパースしている様子？ いまどきなら、AOPを使うよなぁと散策したところ、ちらほら発
Descriptor/PropertyMap による抽象化 - Cry's Blog
っていうか， PropertyMap についてもうちょっとちゃんと説明しておこうっと． 例えばグラフ構造を考えたとき，グラフの頂点と辺を表現するにあたって，実際に頂点クラスと辺クラスがあって……という抽象化は多分オブジェクト指向なデータ構造の抽象化では（発想としては）一番自然かもしれないけれど，一般には様々なトレードオフなどからこのタイプの抽象化が許容できない場合も多い．例えば，最も代表的なグラフ構造の抽象化の1つである隣接リスト表現を考えても，頂点はプログラム上での明示的なオブジェクトとして表現されていない． もう一つ重要な点は，グラフを扱う側（ユーザ側）ではグラフ構造がどういう抽象化をされているかなんてぶっちゃけどーでも良くて，（実際に頂点や辺がプログラム上で明示的な頂点オブジェクトあるいは辺オブジェクトとして表現されているかどうかに関係なく）あるグラフ内の「ある頂点を一意に表すナニカ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GUI と POSA - Akasata's Page（あかさたのページ）
株式会社オージス総研
http://d.hatena.ne.jp/habuakihiro/20060827
http://d.hatena.ne.jp/habuakihiro/20060203