楽々ERDレッスンを読む(1) - 第１部 DB設計総論 - 極北データモデリング
羽生 章洋「楽々ERDレッスン (CodeZine BOOKS)」を読了したので３回に分けてまとめ。 まず第１部「DB設計総論」。 浅海氏智晴氏はこの第１部について「上級者向け」と書いてらっしゃるが、そんなことはない。 初めてDB設計をやる人は絶対に読んだ方がいいと思う。で、ここに書いてあることを論破できないなら、書いてある通りにした方がいいと思う。そういう意味で初心者向き。 第1部の要点は データ構造の設計時に、アイデンティファイア（ID）を導入する。 外部キーにするのはコードではなくアイデンティファイア。 これに尽きる。 で、なぜそう考えなくてはならないのか、が60ページにわたって詳細に書いてある。 コードとは 第1部で言う「コード」とは、コンピュータシステムの外で、ビジネス上の意味を持つ符号のこと。 携帯の請求書に印字された顧客番号とか、通販カタログの商品に与えられた商品コードとか、
極北データモデリング - 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
「複合キー」と実装用フレームワーク - 設計者の発言
テーブルの主キーの設定に関して「複合キーと代理キーのどちらが適切か」という議論がある。私の立場は明確で、 分析段階では必要に応じて複合キーを用いながらモデリングし、実装段階で環境の事情に応じて代理キーを導入すればよい。もちろん、モデルのとおりに実装することが許されるならば、それがいちばんよい。 というものだ。根拠を説明しよう。 以下のようなデータ要件があるとする。記号ではイメージしにくいという読者には、テーブルＡが「社員」で、Ｃが「趣味」で、ＡＣが「社員の趣味」と想像してもらえばよい。その場合の属性eは、各社員の各趣味に対する「好みの度合い(-2は大嫌い、2は大好き、とか)」くらいと考えてもらえばよい。要は a,b,c,d,e の５つの管理項目が見出され、項目間に b=F(a)、d=F(c)、e=F(a,c) の関数従属性が認められたという例だ。 [Ａ] {a}, b ＋ 100 aaa
A.R.N [日記] - ID付与は設計技法ではなく実装技法
なのではないかと主張してみるテスト。 ここではぶ先生に否定されてしまうと、私は第三勢力アクシズとして動かなければならんのですが、男のハマーンはいやですか（←いやです） 論拠は二つ。 どのようなモデルでも誘導的にID方式に変更できる はぶ先生がidとはROWIDのことだ、と言っているように単にRDBMS上にオブジェクトモデルと相似の構造（ポインタによるリレーション）を作るだけなんだから、当たり前の話ではある。複合主キー派の方は、全部サロゲートキーにするなんて！ という反応を見せるわけだけど、ID派の言うIDとサロゲートキーは似て非なるものなのだと思う。旧来の主キーの役割はユニークキーが担うだけの話なわけだし。T-ERで論理モデルを作成した後に、IDを主キーにして作って、参照先をIDにするようにモデルを修正するだけでT-ER的に正しくなおかつID方式のモデルが出来上がる。モデリング技法によらな
![A.R.N [日記] - ID付与は設計技法ではなく実装技法](https://cdn-ak-scissors.b.st-hatena.com/image/square/06a15c64ba0ceec233d86d71001ebb29a9dcbf5d/height=288;version=1;width=512/https%3A%2F%2Fcdn.blog.st-hatena.com%2Fimages%2Ftheme%2Fog-image-1500.png)
満足せる豚。眠たげなポチ。:外部インタフェースのコードと内部実装のためのコードを分離する
１０年来の業務プログラムなので、いろいろ経緯があって今の形なのは仕方がないと思うけど、よくない設計に何も言わないとそのまま次の１０年も過ぎ去りそうなので指摘してしまおう。 今後、コードをデータとして持つときは、次の二点を考慮して扱ってください。 外部インタフェースであるコード（ユーザの都合で変わるコード）と内部の実装で取りまわすためのコード（identifier）は別にすること 他システムは自分のシステムから見たらお客さんであり、コードがお客さんの都合に左右されることを考えたら、他システムで使うコードもやっぱり内部の実装からは切り離した設計にすること たとえば、こんなシステムの話です。GUIからコードとその名称を入力値として受け取り、DBへ一時保存します。そして、あるタイミングでそのコードを他システムへ送信します。送信された先ではそのコードを使って集計・分析をします。 こんなときに、現在の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
