Railsの人がABDに興味がある理由がわからない - recompile.net
RailsにはDB設計技法がないから、Railsの人たちがABDに興味あるってそれ本当？ 実はRailsがやろうとしてないことをRailsに押し込めようとしてるから無理がでてきたってだけじゃないの？ なんてね。おれ、RubyとかRails大好きだからさ、Java系の人がRailsに騙されて一瞬右往左往しちゃったみたいに、Rails系の人が騙されて右往左往すんのは見たくないのよ。（騙されてっていうのは比喩ですからね！ ここで騙す方とされてる側に騙す意図はありませんですよ。それこそ騙すのは話題にでてたああいう雑誌ですよ！） さて、うまく言語化できるかどうかはわからんけど、つらつらと書いてみる。あと、私はBuriとかABDとか詳しく知らないので、嘘書いてるかもしれません。先に謝っておきます。ごめんなさい。 まず、なんでABDの話なのにBuriってのがでてきたのかってことを考えなきゃいけないはず。
ABD飲み会 - recompile.net
行ってきました。いえい！ 幹事の方、ありがとうございました。そうそう、初めてyuguiさんをidentifyしたんだけど、びっくりだ！ 二度も紹介されてた！！ 俺、駄目すぎ！！！ もうちょっと、なんかあってもよかったとおもうんですよー！ 「ファクトってのはなあ、イミュータブルなんだよおお！」「ステートを持たないオジェクトなんてオブジェクトじゃねー！！」みたいな乱闘とか。「プッ今時フロントコントローラパタンかよｗｗｗｗｗ」「ステートレスにこだわるなんて、OOPがわかんねーだけじゃないのｗｗｗｗｗｗｗ」みたいな乱闘とか。 うん、俺はどっちも使いますけどね。 あ、今気付いた。モーニング娘は安倍と飯田の敗者復活物語で、飯田がリーダーになるっていう勝利によって第二部完であとはハロプロに興味もてねーんですよって話を一方的にまくしたてた相手が舞波の中の人か！！ もっとまともな話すりゃあよかった。もったい
マスタメンテナンスで未来のデータを入力したいんですけど - 極北データモデリング
マスタメンテの扱いは毎回困るところ。 どうもマスタデータには「最新」系のものと「無時間」系のものがあるらしい。 いつのトランザクションデータと結合しても問題ないのが「無時間」のマスタで、問題を起こすことがあるのが「最新」のマスタ。 元号マスタなんてのは無時間。 商品マスタとか部門マスタなんかが「最新」のマスタ。属性が今時点の値になっているので、古ーいトランザシクョンデータと結合すると「商品名が(過去の事実と)違う」「部門の所属セグメントが違う」みたいなことになる。 そういう属性はトランザクションデータ側にコピーしておけばとりあえず問題ないんだけど*1、ほんとに困るのは未来のデータを前もって入力したいとき。 例えば4/1から新入社員が1000人入ってくる会社で、3月中に新人の情報をちまちま入力していると、3月中の社員数が狂ってしまう。正しくは4/1の明け方に1000人分入力しなくてはならない
ABDとRailsと。現状の理解。 - moroの日記
ちょっと最近まじめにABDとRailsをいじっていて、いくつか気づいたことのメモ。今まで気づいてなかったのかよ、と突っ込まれそうなこともたくさんありますが。 ActivityとEventとResourceは鼎立するわけでなく、Activity:(Event:Resource)と言う分類。Activityは他に比べて特異なもの。 関連テーブル/交差エンティティの役割を果たすわけで当然ですが、Activityは一つの業務の塊の中で複数レコードできますよね。 一つの業務を見るときの入口はActivityじゃなくEventかも。 Railsでいえば、DBヘの書き込みは、イベントをsave!したうえで、has_manyの:throughな交差エンティティ(Activity)を必要な個数分save!する、というのをAR::Base.transaction{}の中でやればOK。 もちろん毎回書くの繁雑な
2006-10-06
真野正 実践的データモデリング入門 (DB magazine selection) によると、CRUD分析とは別にIRUN分析というものがあるそうだ。 CRUD分析では、各アクティビティがCRUDするエンティティの中の、どの属性が読み書きされるのかまではわからない。 そこでエンティティの属性レベルまで降りて、各アクティビティがどの属性を Import/Refer/Update/Nullify するのかを明らかにするのが、IRUN分析。 分析の結果、同じエンティティの中で生成／消滅するタイミングが違う属性のグループを見つけたら、エンティティを分割する。 例えば、注文エンティティの中の｛ 配送先氏名, 住所, 郵便番号, 電話番号 ｝が注文発生時点では未確定で、後続の「配送・支払指定」アクティビティで値が入力されるとしたら、注文エンティティと配送先エンティティに分割する。 こうすると、それぞれ
日: 2006年9月26日 - 工夫と趣向と分別と。
mixiのCAMEL ON THE ROADコミュニティより、Camelの映像。すごいな。 ほかにも「Camel Latimer」で検索するといろいろ出てくるよ！
極北データモデリング - ABD (Activity Based Modeling) の体系を想像する(1)
羽生章洋氏のABD (Activity Based Modeling) とはいったい何か、唯一のまとまった資料 http://event.seasar.org/sc2006spring/viewAttachment.do?_pageName_=Materials%2FD4.ppt からその全体像を復元するシリーズ。 もちろんご本人に伺えばいいんだけど、まずは自習から。 初回はざっと読んで分かった気になったことをメモする。全部俺理解だから正確な情報は原典を見てね。 今回は「ABDすると何が良くなるのか」という最重要な話題は避ける。それはABDで設計したデータベースに触ってから書く。 ABDで設計したら、データ構造はどうなる ABDでは、外部キーを、resourceだけでなくeventからも追放する。 つまり 売上ヘッダには顧客IDがない。 売上明細には商品IDがない。それどころか売上ヘッダI
関数従属性は多重度に先行して認識される - 設計者の発言
「ライド・オン・Rails」を読んで、著者のひとりの馬場さんにメールしたのが縁で「RubyOnRails勉強会@関西」で話をしてきた。業務システムに関わるためには簿記の知識が必須だとか、デーモデリングの基礎知識なんかを漫談風に解説してタダ酒をご馳走になった。 大胆にもRailsの問題もいくつか指摘した。そのひとつが、Railsで利用されるＯＲマッパActiveRecordでは「複合キー」に関数従属する項目の存在を認めていない点だ。そのような業務要件を含むデータベースをRailsでは扱いにくい。 たとえば、「契約単価」は「顧客コード」と「商品コード」との組み合わせに、「月次ＴＴＭレート」は「通貨コード」と「年月」との組み合わせに関数従属する。こういう関係は業務システムではふつうに存在する。Railsは本格的な業務システムを扱うためのフレームワークではないのだからいいじゃないかと考える向きもあ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.pen-chan.jp/~tdiary/pen-chan/20070522.html
今年も僅かだはぶにっき-バランスということ
ルーツ本 - 今年も僅かだはぶにっき
http://d.hatena.ne.jp/habuakihiro/20061102
http://d.hatena.ne.jp/habuakihiro/20061012
http://rails.office.drecom.jp/takiuchi/archive/98
http://rails.office.drecom.jp/takiuchi/archive/94
ABD（はぶにっき 2006/9/30)
http://d.hatena.ne.jp/habuakihiro/20060828
http://d.hatena.ne.jp/habuakihiro/20060824
http://d.hatena.ne.jp/habuakihiro/20060822
はてなブログ | 無料ブログを作成しよう