佐藤正美氏新刊出版記念セミナー

(佐藤正美氏新刊出版記念)新T字形ER手法「TM」で始めるシステム分析セミナー ?短納期・高品質・低投資時代への対応?

あるみたいです。 TM/T字形ER手法に興味がある方は是非。

CONCEPTWARE/財務管理

渡辺幸三の開発支援サイト「システム設計のこと、もっと知りたい」 – レファレンスモデル

公開されたようです。

T字形ER 早稲田エクステンションセンター

> ▼ 早稲田大学エクステンションセンター 秋講座 >  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ > > 早稲田大学エクステンションセンター(社会人向けの公開講座)の講師を、秋もやることになりました。 > > 秋の講座は、9月30から12月9日まで、毎週金曜日の19:00から20:30までの10回の連続講座です(10月21日、休校)。

費用が非常に安価なので、個人的にT字形ERに興味があるが、会社からお金を出してもらうのはちょっと・・・という方にオススメできます。

毎回の講座後の飲み会も楽しい。

社員マスタという不思議なエンティティ(第2回)

社員マスタという不思議なエンティティ(第2回)

面白いです。

XMLデータベース開発方法論

* @IT:XMLデータベース開発方法論(1) 1/4 * @IT:XMLデータベース開発方法論(1) 2/4 * @IT:XMLデータベース開発方法論(1) 3/4 * @IT:XMLデータベース開発方法論(1) 4/4

面白い。

from @IT:XMLデータベース開発方法論(1) 2/4 :

> RDBは「例外的な処理」との相性が悪いということである。きれいに正規化されたデータを扱っている限り、RDBは実に快適で、わずかな手間で素晴らしい成果をもたらしてくれる。しかし、そこから逸脱する例外的なデータや、例外的な処理が発生すると急に扱いにくくなる。そして、例外的なデータや例外的な処理は、多かれ少なかれ、どこかで要求に入り込んでくる。

(筆者を批判するわけでなく・・・)より正確に言えば、上記の批判(というか制約か・・・)はRDB特有のものではない。厳密な意味にでの「データモデル」を扱った場合に一般の問題といえると思う。

from @IT:XMLデータベース開発方法論(1) 3/4 : AWK、使い捨てデータ処理の切り札 > AWKによるデータ処理は、RDBによるデータ処理の対極に存在するといってよいだろう。RDBによるデータ処理は、専門家によって構築され、大量の定型化された情報を効率よく処理し、日常業務の中で数え切れないほど繰り返し長期にわたって使うことができる。しかし、AWKによるデータ処理は、ユーザー自身が記述し、少量の不定形の情報を効率は悪くとも必要十分な時間で処理し、使い捨てられる。

from @IT:XMLデータベース開発方法論(1) 4/4 : RDBとAWKの中間ポイントに位置するXML

> XMLとは、テキストでデータを記述するというAWK的テキスト処理の世界を継承しつつ、そこに要素や属性という構造を導入することで、自由を制約した言語であると見ることができる。自由の制約は、利用者がより少ない手間で成果を得られるようにするために導入される。しかし、自由の制約は最小限に抑えられ、RDBと同水準の高い秩序は要求していない。

筆者の立場は、XMLを、厳密な意味での「データモデル」として捕らえたものではない。逆の立場をとっている。(モデルとして)全くの構造を持たないテキストデータに対して、制約を加えたものという立場をとる。まさにボヘミアン。

T字形ER 土曜勉強会

久しぶりに顔を出した。 しばらく休んでいたのに快く迎えてくれた皆さんに感謝!

### As-Is As-IsとTo-Beを区別することは必要だけど、あまりAs-Isにこだわりすぎるのはどうかと、ふと思った。

PoEAAとか

ロイホにしけこみ読書。

Essential XML・・・うーむどうなんだろう。ちょっと必要以上にわかりにくく書いてないか?この本。 訳が良くないというのもあるけど・・・(シリアライズを「順序化」って、あーた・・・。せめて「直列化」で頼む。) インフォセットの語りもなんだか抽象的でよーわからんし、SAX、DOMのあたりも構成が練れていない感じ。

PoEAA読書会に向けて、2部のパターン、O-Rマッピングあたりをさらりと読む。

1部の概論はイマイチしっくり来なかったが、2部はまぁまぁな気がする。 各パターンの説明の中で、未説明のパターンに言及するあたりがなんだかなーだけど、 各パターンの概要が頭に入ってきてパターン間の関係を頭の中で整理することができると、 比較的すんなり読めた。 ただ、ファウラーのコメントが散文的で踏み込みが甘いので、若干フラストレーションがたまるなぁ。 もう少し、具体的なコメントがほしいところではある。 現在は様々なフレームワークが出回っているわけだから、それらに触れるような切り口もありなのでは?と思ったりした。

### EOFとPoEAA ###

パターンの本来的な役割は、共通の語彙・概念の形成であると理解している。 というわけで、PoEAAの語彙・概念を利用してEOFを表現する。(乱文すぎるので、たぶん、あとで書き直す)

### ドメインロジックパターン ### ドメインロジック(=ビジネスロジック) の割り当ての方針は、基本的に「ドメインモデルパターン」が推奨される。 もちろん、画面にビジネスロジックを埋め込むような実装・設計も可能ではあるけれども。

物理的にも、「ドメインモデル」を実装したオブジェクト群をパッケージ化・フレームワーク化して、様々なアプリケーション形態(WOFと呼ばれるリッチなWebアプリケーションフレームワークを使用したWebアプリケーション、DirectToWebと呼ばれるルールベースのUI定義ベースのWebアプリケーション、Javaクライアントなどなど)で、それらを共用することが(それなりに)一般的であるようだ。

### データソースのアーキテクチャに関するパターン データソースとオブジェクトの変換は、オブジェクトグラフとリレーショナルモデルの変換という形で実行される。 であるので、「データマッパーパターン」になるのかな? オブジェクトとリレーショナルの対応は、物理的には*.eomodelファイル群、論理的にはEOModelGroup、EOModelなどのメタモデルクラス群で管理される。(「メタデータマッピングパターン」に相当)

### オブジェクトリレーショナル振る舞いパターン ### 基本的に、「ユニット・オブ・ワーク パターン」。 EOEditingContextと呼ばれる、オブジェクトグラフの編集用ブール、SandBox的なオブジェクトが存在しており、これがオブジェクトグラフの編集状態を管理する。編集をコミットしたタイミングで、オブジェクトの編集処理が、SQLクエリに変換される(「データ・マッパー パターン」)。この際、デフォルトでオプティミスティックロック戦略が使用される・・・ことになっている。(苦笑&謎めき)

EOEditingContextの寿命とWeb層のSessionの寿命がシンクしている点がなかなかいい感じではある。 (超私見)

#### 一意マッピング #### 異なる2つの世界、RDBMSとオブジェクトの中で、一意性をどのように、どのレベルで確保するか?という戦略。

EOFは一意性に関しては、2種類の一意性管理をもつ。 「ユニット・オブ・ワーク」単位の一意性と、データベース群レベルの一意性であり、EOGlobalIDなるクラスを用いることで一意性管理を実行する。EOGlobalIDは「データソース×テーブル×プライマリキーの組み合わせ」と考えてよい。文字通り、複数データソース内で、グローバルに一意である。

1つの編集用領域(EOEditingContext)には、同じEOGlobalIDのオブジェクトは1つしか読み込まれない。 ただし、複数ユーザーが編集中である場合など、複数の編集用領域が存在する場合、同じEOGlobaIDのオブジェクトが複数存在する。(当たり前!) ただし、下位のデータ管理レイヤがそれぞれのオブジェクトをトラッキングしており、あるオブジェクトが編集された場合、同じEOGlobalIDを持つ別のオブジェクトに変更を伝播させたり、しなかったりする。

#### レイジーロード #### レイジーロードはfaultingと呼ばれる機構でサポートされる。 関連の先にぶら下がっているオブジェクトは、必要に応じてRDBMSから読み込まれる。 […]

対照表はパワフルだ

Data Model Resouce Book vol.1を読みながら、記載されているデータモデルをVisioでお絵かき。 VisioにはBarker NotationのER図を書く機能がないので、角丸四角と(普通の)コネクタを使用して書いてみた。単に書き写してもしょうがないので、適当に構成要素を分類したり、構成のパターン的な要素を洗い出したりしながら読み進めるわけである。

ただ、当方T字形ER出身なので、やっぱりT字形ER的な分類や、パターンからERを見たほうが親しみやすいもの。というわけで、色分けでその分類を表してみた。

* ピンク:リソース(的な)エンティティ * 水色:対照表(的なエンティティ) * 紫色:再帰(エンティティ)

もちろん、T字形ERでは相当する概念がないようなものもあるわけで・・・

* 黄色:タイプを示すエンティティ

このようにエンティティを分類することにより、リレーショナルモデルが見やすくなる。 この作業を通じて思うのは、「そのエンティティが対照表か否か?」を意識すること、「概念的な意味での関係か否か?」を意識することで、かなりリレーショナルモデルが見やすくなる点である。

対照表はパワフルな概念だし、T字形ERにおける対照表と対照表が関連するリレーションシップの表記方法は簡便でよい。対照表に相当する概念を、いわゆるIntersection Tableで表記してしまうと、リソース⇔リソース間の多重度が理解しずらくなる。

違いを示すために、上の図をT字形ER図で書いてみようなぁ・・・と思ったけど面倒なのでやめ。

#つーか、エディタがないと書く気がしません!!

六の日記はここにはないぞ

六の日記はここにはないぞ

書籍には出てこないような、詳細なレベルで業務システムのデータモデリングについてまとめてようとしてらっしゃっているサイト。すばらし!

* 六の日記はここにはないぞ – 仕訳を度外視で入金処理 * 六の日記はここにはないぞ – 仮受金で前受を管理する話続き * 六の日記はここにはないぞ – 血液ガッ手形 * 六の日記はここにはないぞ – 血液ガッ手形・補遺 * 六の日記はここにはないぞ – 現預金の入金でウーンウーン * 六の日記はここにはないぞ – 今度は前受金でウーンウーン * 六の日記はここにはないぞ – 前受金つづき * 六の日記はここにはないぞ – 請求書上で消し込みをシミュレートする訳・補遺 * 六の日記はここにはないぞ – 仕訳をいつ作るかなあと云う話 * 六の日記はここにはないぞ – 領収書はモデルに含めるか

法政大学エクステンション・カレッジ – データ中心アプローチによる情報システム分析・設計

法政大学エクステンション・カレッジ – データ中心アプローチによる情報システム分析・設計 に行ってきた。

ただ、大幅に遅刻してしまった。残念。やはり18:30開始はしんどい。 しかも、講義が1時間30分で、全12回とは・・・。 結構出席するのはしんどいですよ?コレ。 もう少し時間を遅くして、1回の講義時間を長めにして講義回数を少なく欲しいなぁ・・・。

閑話休題。初回から遅刻してしまったわけだが、講義の資料は(聴講者専用の)Webサイトに公開されており、これに事前に目を通していたため大体の内容は把握できた。

今後は、初回において概要レベルで語られていた内容が、どのように詳細化・具体化されていくのか?をチェックしていきたい。ただ、12回毎回出るのはほぼ無理!なので、事前配布される資料を見て、都度出席するかどうか?を判断する形になるかな。