汝の隣人のブログを愛せよ | LOVELOGau one netのブログサービス 『LOVELOG』は2014年6月30日をもちまして提供を終了致しました。 永らくのご利用、誠にありがとうございました。 引き続きau one netをご愛顧いただきますよう、よろしくお願い申し上げます。 ※お手数ではございますが、新ブログにて閲覧の皆さま向けにブログURL変更等をご周知いただけますよう、お願い申し上げます。
続・主キーにサロゲートキーを使うことの是非 - iビジネス&テクノロジー
前回の続きです。 代理キーは「スタイル」ではなく「テクニック」: 設計者の発言 理論的な話になると難しくてわからないので、とりあえず私も理解を深めるためにER図を描いてみようかなと思いました。 わたなべさんの問題の要件は以下の通りだとします。 倉庫が複数あるとして、倉庫にはさまざまな商品が保管される それぞれの商品は倉庫毎の特定の棚に保管される これだけの要件だと、こんな感じでよいでしょうか。 在庫テーブルについては、見やすいように（倉庫ID、商品ID）を複合主キーとし、idにユニークインデックスをつけています。idを主キーにする場合と意味は変わりません。 あるいは 一つの棚に一つの商品しか置けない という要件が追加されるとすると、 としても良いでしょう*1。niraikanaibirdさんのモデルも、この前提で作られているものと思われます。 さて、上記要件だけだと倉庫棚テーブルというもの
ID or not ID - A.R.N [日記]
おぉ、ガチだ。 [RDBMS]複合主キー？ 18:57 ･･･まだそんなこと言ってる人いるのか。 id等の単一のサロゲートキーを導入して逃げることも可能ではあるが、そのために仕組みが複雑になることが避けられない。 いや、お互いものすごく優秀で有名な方だし大人なのでガチの勝負はしてくれないとは思うのだけれど、ぜひ世の多くのさまよえるSEのためにガチンコ勝負して決着つけてくれんかなぁ。てゆうか、今回の案件でもID派（＝私）と複合主キー派（＝モデラー）でもろに喧嘩してるし、前のプロジェクトでも他の人が同じようなことやってたし、さらに前の案件でも(w そろそろ、IDを使うべきかそうでないかくらいベストプラクティスを決めてほしいなぁと思う今日この頃*1。 たしかにDB直接見て何かするような運用だと、複合主キーの方がわかりやすかったりするのはたしか。でも複雑なシステムで他のテーブルへの関連が沢山あるよ
![ID or not ID - A.R.N [日記]](https://cdn-ak-scissors.b.st-hatena.com/image/square/0b9f5dd5b04b969b65543d66daeabf09d2f67327/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127064254481%2F17680117127064335398%2F1555805246)
極北データモデリング■[RDB]タグ
削除フラグ(というか「論理削除を削除フラグだけで実装すること」)批判は何度も見てきたが PostgreSQLアンチパターン これ見るともはや論理削除自体が闇扱いになってしまったようだ。 闇だろうと何だろうと論理削除(というドリルが提供する穴)は要件の実装に必要なので、このへんの議論はあまりまじめに追ってこなかった。 いつだったか「削除フラグはバグの温床だからやめろ」という主張を読んでおぉなるほどと思い、ではどうやって論理削除を実装するのかなと思って続きを読むと「『ほんとに削除したデータが必要ですか?』とユーザに確認して、物理削除に変えさせてもらう」と書いてあってズコーとなったことがあるが、要件削っていいなら実装上のどんな問題も消えるわけで、何かもう別世界の議論で自分の仕事には関係ないと思っていた。 が、これだけ繰り返し批判されているからには、論理削除を正しく使う方法なり条件なりを明らかに
![極北データモデリング■[RDB]タグ](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)
2007年のはぶにっき
■[RDBMS]複合キーのこと 11:44 http://d.hatena.ne.jp/habuakihiro/20060820#c1156782184にて 『楽々ERDレッスンにそれらしきところは一箇所だけあったが例が悪すぎる。悪例で複合主キーを批判して自分の理論を正当化させる稚拙な説明では初心者以外は納得してくれないよ。もう少しまともな理屈で説明をしたらどう？』 とのことで、まぁ、ERDレッスンにあれだけ書いてるんだし煽られるつもりはないのでスルーしちゃおうかと思ったのですけど、他の方からのTBもあったのでちょっと書いておきます。キーワードはライフサイクルとリレーションシップです。 そもそもリレーションとは何か ERDレッスンではあえてこの辺の話は書いてません。だから参考文献を提示したのだし。だけど、念のために書いておきましょう。 RDBはリレーショナルデータベースの略です。リレーショ
楽々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方式のモデルが出来上がる。モデリング技法によらな
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
満足せる豚。眠たげなポチ。:外部インタフェースのコードと内部実装のためのコードを分離する
１０年来の業務プログラムなので、いろいろ経緯があって今の形なのは仕方がないと思うけど、よくない設計に何も言わないとそのまま次の１０年も過ぎ去りそうなので指摘してしまおう。 今後、コードをデータとして持つときは、次の二点を考慮して扱ってください。 外部インタフェースであるコード（ユーザの都合で変わるコード）と内部の実装で取りまわすためのコード（identifier）は別にすること 他システムは自分のシステムから見たらお客さんであり、コードがお客さんの都合に左右されることを考えたら、他システムで使うコードもやっぱり内部の実装からは切り離した設計にすること たとえば、こんなシステムの話です。GUIからコードとその名称を入力値として受け取り、DBへ一時保存します。そして、あるタイミングでそのコードを他システムへ送信します。送信された先ではそのコードを使って集計・分析をします。 こんなときに、現在の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
