DataModel via capsctrldays
期待。
|
|||||
|
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回毎回出るのはほぼ無理！なので、事前配布される資料を見て、都度出席するかどうか？を判断する形になるかな。 The Data Administration Newsletter (TDAN.com) 何の気なしにGoogleしてたら見つけた。なかなか面白い。 適度に概念的で、それなりに実際的なレベルの議論で楽しい。こういうのは、日本では読めない。 ヨコのものをタテにするのが商売の連中か、電波を飛ばすのが趣味の連中ぐらいしかメディアにいないから。 いや、いるにはいるのだけど、適切な具体的レベルで言葉を発することができないのだ。 残念なことだ。 ### XML 関連 ### 個人的にもやもやしていているが、自分では表現できないことを代弁してくれる記事に出くわすと、とてもありがたく感じる。 * TDAN – Mullins – DBAs You Should Fear XML * TDAN – Riggs – What XML Means 土曜日、日曜日で読了した。 タイトルにデータベース設計とうたいつつも、基本は販売業務の説明が中心。細かい部分に関しては立ち入っていない。 しかし、販売業務の基本を抑えるには非常に良い本だ。なぜなら、丁寧な文章に加えた形でデータモデルが示されているため、意味を明確理解することができる。 販売業務システムの開発経験がない人には、お勧めできる。 ただ、実際のデータベース設計をするならば、返品処理、戻し処理、キャンセル処理など例外系についてもう少し細かい設計が必要となるし、おそらく仕訳処理も書籍もように簡単にはいかないと思われる。 個人的には、トランザクション系のステータス管理を詳細にまとめた書籍が欲しいと思っているが、ここらへんは明文化しにくいモノなのだろうか？ 会議の帰りに、ふとファウラーの話になり、そして、アナパタの話になった。 同僚曰く、「ファウラーは、基本的に一番まともなことを言っているように思える。だから結構スキ。が、アナパタよくわからん。理解できん。難しすぎる」 とのこと。 確かにアナパタは難しい。自分もかなり難しく感じた。 苦労して何度も読んだ結果、ぼんやりと理解はできた。 が、今思うと、カナリ無駄な時間を費やしたような気がする。 話の中で、アナパタ難しい理由として以下の2つをあげた。 表記法としてオブジェクトモデルを利用しているが、実概念（意味）とモデル要素の関係のとり方が一般的なオブジェクト指向と異なるため、理解が難しい。 オブジェクトモデルはモデル要素の意味が曖昧であるため（特に関連）、読み取った結果、読み手がイメージする意味が、各人でブレ易い。 個人的には、アナパタという本は、とんだ食わせ物だと思っている。 アレは、オブジェクトモデルの乱用である。オブジェクトモデルの適用領域を超えてオブジェクトモデルの表記方法を利用しているため、普通の人間には理解しがたい。 アナパタが表現したいモデル構造を理解するためなら、Data Model Resouce Bookを見る方が良い。おそらく、こちらの方がわかりやすい。 これは何故だろうか？自分でもよくわからない。 リレーショナルモデルのリレーションシップの意味の明確さが理解をたすけるのだろうか？ それとも、オブジェクトモデルにおけるインスタンスであるレコードなる概念が、非常にわかりやすいものであるため、理解がしやすいのだろうか。 ま、いずれにせよ、アナパタを理解したい人には、Data Model Resouce Bookをお勧めしたい。 リレーショナルモデルにおける正規化の延長上に多階のモデルがあるという、新しいものの見方を学べるというおまけもついてくる。 内容的にはすばらしい（といっても全部は読んでいないのだけど・・・）のだけど、腹立たしい点が一点ある。 CD-ROMが添付しており、データモデルのDDLがはいっているとうたっているにもかかわらず・・・・、別途$350払わないと読めない・・・。どーなの？これ？ […] |
|||||
|
Copyright © 2024 WR blog - All Rights Reserved Powered by WordPress & Atahualpa |
|||||