ABD飲み会参加 - yojikのlog
Railsな人々、Seasarな人々に挟まれて、無所属系で人見知りの僕は大変緊張いたしました。 ちょっと面白かったのは飲み会前の妙に緊張した雰囲気。全員が沈黙して資料読んでる風景がすごかった。店員がちょっとびっくりしてたね。 僕は、宴会初期はid:habuakihiroさんの隣の位置という好ポジションにつけながら、なぜかABDの話をほとんどしてなかったり。(だめじゃん) ちょっと話していたのはUIの話。ちょっと話題になったのは、例えばMSOfficeのようなGUIアプリのデザイナはどんな仕事をしているんだろうという話。なんとなくオフィスアプリの「デザイナ」がHTML相当の画面系のコード(WPFみたいな)に触ることが無いような気がする。今のWeb系プログラマの常識がどこまで常識なのか? あとWindowsPowerShellカッコイイという話。 そのあと他の人とABDやワークフローの話などな
Railsの人がABDに興味がある理由がわからない - recompile.net
RailsにはDB設計技法がないから、Railsの人たちがABDに興味あるってそれ本当？ 実はRailsがやろうとしてないことをRailsに押し込めようとしてるから無理がでてきたってだけじゃないの？ なんてね。おれ、RubyとかRails大好きだからさ、Java系の人がRailsに騙されて一瞬右往左往しちゃったみたいに、Rails系の人が騙されて右往左往すんのは見たくないのよ。（騙されてっていうのは比喩ですからね！ ここで騙す方とされてる側に騙す意図はありませんですよ。それこそ騙すのは話題にでてたああいう雑誌ですよ！） さて、うまく言語化できるかどうかはわからんけど、つらつらと書いてみる。あと、私はBuriとかABDとか詳しく知らないので、嘘書いてるかもしれません。先に謝っておきます。ごめんなさい。 まず、なんでABDの話なのにBuriってのがでてきたのかってことを考えなきゃいけないはず。
ABD飲み会実施しました - moroの日記
羽生さんはじめ、出席してくださった皆様、ありがとうございました。おかげさまで無事に開催できました。 今回は羽生さんがABDについてまとめてくださった資料をいただいたんですが、それを見ながらお話を聞いて、これまでの理解がそれなりに正しかったことを確認できました。ただ、実戦投入はまだ早いかもしれないという由、確かに前にちょっとだけ試した感じでは、(少なくともRailsでは)まだ難しい感はありました。ERDレッスンがちょうど良いというのも実感してます。 で、Rails界隈の人がABDに興味津津なのは何か不思議、という話を高井さんがおっしゃってたんですが、それはたぶんRailsではDB設計の部分がすっぽり抜けてるんですよね。 「DBのデザインを決めたらあとはカッコよくいけるよ」というDavidさんですが、じゃあどうやってデザインすんのよ、と。いい替えると、他の部分が楽になりすぎたので、必然、残りの
ABD飲み会 - http://nxfhqh.com/
@@ -1 +1,94 @@ -qxOrcqGl +2006年12月3日に、Activity Based Datamodel飲み +会を開催します。ABD提唱者の羽生章洋さんをお招きしてデータ +ベースモデリングについて語る集いです。 + +'''（このウィキは遅くとも2011年には管理されなくなっています）''' + +! 概要 +ABD(Activity Based Datamodel)は羽生章洋さんが提唱するデータベー +ス設計技法です。羽生さんのホームグラウンドであるSeasarコ +ミュニティは勿論のこと、そのアジャイル開発との親和性からRuby on +Railsコミュニティにおいても注目を集めています。 + +ABDについては2006年Developers SummitやSeasar +Conference 2006 Springにおける羽生さんの講演が唯一の情報源であ +り
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。 もちろん毎回書くの繁雑な
エンティティの見出し方・属性の割り振り方 - 伝統的設計・T字形ER手法・ABD - 極北データモデリング
非正規形の表が与えられたときに、その表を出力できるDBをどうやって設計するか。 伝統的DB設計法・T字形ER手法・ABDのやり方を並べて書いてみる。 伝統的DB設計法 伝統的なDB設計では、非正規形の表を正規化する過程で、エンティティを切り出していく。 また正規化しながら、関数従属性に従って属性を割り振っていく。 データ項目の意味は考えず、データ項目の重複が最小になるように分解するので、m:nの関係の時以外は交差エンティティは発生せず、「社員マスタに所属部門コードがある」といった結果になる。 T字形ER手法 上記を問題視したのがT字形ER手法。 T字形ER データベース設計技法 P-26 ER手法が大きく勘違いされた点は、データを正規化してから、ER手法を使ってデータ構造を表現する、という点にある。 つまり、ER手法が表現手段に成り下がってしまったのである。ER手法は、思考手段(解析手法)
極北データモデリング - 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
ヽ( ・∀・)ノくまくまー(2006-08-27) - Rails勉強会＠東京第9回
● [Rails] Rails勉強会＠東京第9回 勉強会に初参加。今まで行かなかった最大の理由は ポジションペーパーを書くのが面倒臭い ポジションペーパーの書き方がわからない ポジションペーパーのサンプル情報が少ない (リンク先が死んでいた) という情けないものであったが、Yugui たんと has_one :through について語りたい欲が遂に行動の閾値を超えたのだった。ポジションペーパーは結局、「ぶろぐ。@4bit.net」様を参考にさせてもらいました。結局、A41枚程度に好きなことを書けばいいようなので、結局は4bitの人とは似ても似つかないポジションペーパーに。(面倒なのでHTMLで直書き&文章なし)。私以外にも似たようなメンド教徒がいると思うので、ポジションペーパーのサンプルは、勉強会公式ページに*直接*一杯置いておくのがよいと思いまんた。 ● 前半セッション:「Seleni
Rails勉強会@東京 第9回 - 世界線航跡蔵
形式は前半・後半に時間を区切って オープンスペース 形式。要 ポジション・ペーパー というのも変わらず。 この形式はいいんじゃないかなと思ってる。最初、秋葉原でやっていた頃、参加者全員が集まって座れる場所を確保できなかった故に 角谷さん の発案でオープンスペースになったそうだけれど( 第0回 )、これによって、最多で10人程度に分かれるから参加者のコミュニケーションが促進されてる。Listen Only Memberを発生しにくい仕組みになってるんじゃないかと思う。 反面、少数であるが故に全員が受け身だとひたすら沈黙になってしまうのは確か。一時期、そういう感じでいつまで経ってもセッション案が出なかったりしたけれど。でも、 もろはし さんの提言で事前にセッション案を十分に出しておくというのが復活して、そういう難点は解消されつつある。 ポジション・ペーパーについてはこれはよい作用をしているのは
has_one :through - 世界線航跡蔵
Rails 1.1以降のActiveRecordではhas_and_belongs_to_manyの代わりに has_many :through を使うのがトレンド。これはこれで便利なのだけれど、Activity Based Datamodel式のテーブル構造を使うためにはやっぱりhas_one :throughも欲しい。 本家のMLでは7月24日の"belongs_to :through?"とかいうスレッドでdelegate使えとか言われてる。でも、その場合発行されるSQLが効率悪そうで嫌だ。やっぱり結合して一気に持って来たい。 で、作ってみた。プラグインでも、environments.rbに直接書き込みでも好きなようにインストールしてください。暫定版だし。 ActiveRecord本体の関連の実装に激しく依存してるというたちの悪さ ActiveRecord 1.14.3で動作確認。他は
[DB]【Developer Summit 2006】楽々ERDレッスンLIVE (application/pdf オブジェクト)
楽々ERDレッスンLive ～これが楽々DB設計の勘所！～ 9-E-3 羽生 章洋 羽生 株式会社スターロジック 代表取締役兼CEO 自己紹介 自己紹介 羽生 章洋（はぶ あきひろ）と申します。 羽生 昭和43年生まれの今年37歳です。 昭和 受託電算業務の伝票打ちから始まりました。 受託電算業務の伝票打ちから始まりました。 プログラマ～システムエンジニアを経てコンサルタントをやって プログラマ～システムエンジニアを経てコンサルタントをやって きました。 様々な業種・業務に関わってきました。 様々な業種・業務に関わってきました。 今はスターロジックという会社の経営をやっています。 今はスターロジックという会社の経営をやっています。 国産オープンソースコミュニティであるNPO法人、 国産オープンソースコミュニティである Seasarファウンデーションの理事でもあります。 今日のお話
Activity Based Datamodel - 浅草橋クロニクル
http://event.seasar.org/sc2006spring/viewAttachment.do?_pageName_=Materials%2FD4.ppt 今さらながら、はぶさんのSeasar Conference 2006 Springの資料を見て、 その分かりやすさに鱗が落ちまくりました。 で、WEB+DB PRESS Vol.21のはぶさんの記事を読み返すと、これまた素晴らしい。何がいいかって、その記事を周りの人への説明にそのまま使えることです。佐藤正美さんのT字型ERだと、その難解な表現ゆえに、「これ通りやってみて」ではどうにもなりません。(同じようなことを言ってるんですけどね) で、このコードとは別にIDを付けろとか、交差エンティティを作れなどはRailsのモデリングには最適なのです。Railsの流行とともに良いDBモデリング手法も流行りますように…
EJB3とABD その1 - 今日とは違う明日
EJB3とABD その1 EJB3.0入門, 技術, オブジェクト指向, DB ABD(Activity Based Datamodel)で設計されたテーブルをEJB3で実際に使ってみる。 ABDの復習 まずはABDの復習から。 使用するEntityは、先日のSeasarConferenceのセッション資料から拝借。 Resource系Entity 顧客 商品 Event系Entity 売上 売上明細 通常のデータモデル Event系EntityとResource系Entityを関連させるために、FKを設定する。 楽々ERDレッスン (CodeZine BOOKS)を読んだ段階だと、こんな感じのモデルになるのだらうか。 ABDへ ABDはEntity間の関連に、より焦点をあてているようだ。 通常、FKによって関連が表現されているが、そのせいで1:mだとかm:mのような小難し関連が出てきてし
RailsとABDとCRUDとワークフロー - moroの日記
羽生さんのABD(Activity Based Datamodel)ですが、それを知った感想を自分なりにすごく乱暴にまとめると、DBをイベント系とリソース系にわけた上で、仕事っていうのはリソース間やイベントとリソースの間になんらかの関係を発生させる捉える、という考え方かなぁ、と。 イベントとリソース 売上げが立つ、というイベントはつまりお客さん(リソース)と商品(リソース)との間に購入/入金という関連が発生するというふうに捉えられます、と。 あんまり例えが良くありませんが、ビジネス上のできごと＝イベントに着目し、イベントも関連テーブルのエンティティを素直にcreateすることで表現するという方法論だと読んでいます。 さらにDBを設計するということは、そういったイベント、すなわちビジネス上のアクティビティをどう記録するか、という観点でデータの持ちかたを設計していくということなんじゃないでしょ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://rails.office.drecom.jp/takiuchi/archive/99
http://d.hatena.ne.jp/habuakihiro/20060828
not found
PADDLE ～明日へとパドリング～ - 楽々ERDレッスンLive
夏のはぶにっき - オフショア
はてなブログ | 無料ブログを作成しよう
