事実と真実はどう違うか。また裁判官のキャリブレーションについて - 極北データモデリング
俺が通ってるジムのステアマスターにはテレビが付いていて、いつもテレビ見ながらをステアマスター漕いでるんだけど、この前北斗の拳の再放送見ようと思ってテレビ点けたら放送大学の講義をやっていて、これがえらく面白かった。 それは科学哲学の講義で、テーマは「事実と真実はどう違うか」というものだった。 話の要点は以下の3つだ。 1. 真実は観測できない 先生はこんなフリップを出して話を始めた。 「何かを観測して得たデータを事実と呼ぶならば、事実には必ず誤差が含まれています。事実の集積から、何らかの手続きで誤差を消去して抽出したものを真実といいます」 ガタガタのヒストグラムという事実を集めて、そこから滑らかな曲線を描く真実を取り出すわけだ。 先生の定義によれば、真実は事実のように直接観測できるものではない。 現実世界で見ることも、手で触れることもできないのだ。この点、事実よりも思い込みや妄想に近い存在だ
SQLアンチパターン「IDリクワイアド」の再検討 - 極北データモデリング
SQLアンチパターン 作者: Bill Karwin,和田卓人,和田省二,児島修出版社/メーカー: オライリージャパン発売日: 2013/01/26メディア: 大型本購入: 9人 クリック: 698回この商品を含むブログ (46件) を見る話題のSQLアンチパターンの目次に「アンチパターン：すべてのテーブルにID列を用いる」とあるのを見て、大胆にもサロゲートキーを否定しているのかと思って読んでみたが、どうも主張がはっきりしない。論点が尽くされていないような... 「SQLアンチパターン」の主張 第3章には以下のようなことが書いてある。 「IDリクワイアド」アンチパターン IDリクワイアドは「すべてのテーブルに"id"という列名の無意味な連番の列を追加し、PRIMARY KEY制約を付与する」というパターンのこと。 何がいけないのか 自然キーにUNIQUE制約を付けないなら、自然キーの重複を
うちの会社は休み放題にすべきだ - 極北データモデリング
勤怠管理なんてやめてしまえばいいのだ。休みたかったら休む。会社に行きたい日だけ行く。そういう会社を目指すべきだ。 行っても行かなくてもいいなら、たまには行きたくなる日もあるだろう。行くのが義務だから毎日行きたくないのだ。 40年前の実証研究で否定された、時代遅れの成果主義なんて止めてしまえばいいのだ。 「がんばった分だけ見返りがある」なんて仕組みには何の魅力もない。「やってもやらなくても見返りがある」なら魅力あるけど。 そんな会社なら職場を守るために狂ったように働いてもいい。 「そんなふざけた制度では誰も働かない」なんて言ってはいけない。会社はソ連じゃないのだ。参加者を選べるのだから、そういう会社をこの世に成り立たせることに使命感を持つ人間だけで回せばいい。俺なら狂ったように働くね。 気が向いたときだけ働いて、めんどくさくなったら休む。それでも誰も文句を言わない。そんな会社なら全身全霊をか
やわらかいものがうまいのはなぜか - 極北データモデリング
テレビの食い物番組で、レポーターの女の子が「やわらかーい！」「とろとろー！」「ぷるぷるー!」とか言ったあとに「おいしーい！」ていう場面がよくある。 彼女たちはどうして、食い物がやわらかいと喜ぶのか。 飲食店のコンサルタント・大久保一彦氏によると、それは「咀嚼回数が少なくて済むから」なのだそうだ。 客に「うまい」と感じさせるには２つのやり方がある、と大久保氏は言う。 繁盛の天才 2時間の教え―127人の店長を成功させた P-217 ひとつは、胃をできるだけ早く、パンパンにしてあげることです。 ... 胃の中をスピーディーにいっぱいにするには、柔らかいものを提供し、表面をさくさくに仕上げて、 咀嚼回数を少なくしてあげるのが手っ取り早い方法です。 だから、外食産業は「柔らかさ」を追求してきたわけです。 もう一つは、塩分・糖分・アミノ酸を血中に一気に流し込んであげることです。 つまり、我々の中に
IDがあっても、event からコードを削除してはいけない - 極北データモデリング
盛り下がってきたけど、今かすかにID論が熱い！ 渡辺氏がIDについて懸念していることに自分もよく引っかかるので、自戒のメモ。 コードはfactだから削除しちゃダメ ウチで持っているECサイトのパッケージでは、受注明細テーブルに、商品マスタから商品名をコピーして保持している。 商品名は時々変わるので、何かの方法で「販売時点の商品名」が取れるようになっていないと、お客さんに送った納品書と、 システムの受注履歴表示画面とで、商品名が違ってしまうから。 「コードは不安定で外部キーにはなり得ない」という立場に立つなら、コードも名前と同じ意味で、resource から event にコピーする必要がある。 商品コードを外部キーにするトラディショナルな設計では、商品コードは 商品マスタの当該レコードを指すポインタ 受注というイベントに属するfact（商品名とかと同じ） の２つの意味を持っている。 ID導
極北データモデリング - 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
DB Magazineの良記事 - 極北データモデリング
何ヶ月か前から、Struts + DI + O/Rマッパーのサンプルアプリケーションを集めている。 ソースがあるだけではダメで、なんでそういう設計になっているのか、作者の説明付きのものを探している。 で、DB Magazine 7月号の「DIコンテナをベースにしたアプリケーション実装モデルの作法」が、ぴったりの記事だった。 サンプルアプリは、特定顧客の売上情報(ヘッダ＆明細)を一覧する、というもの。 読みたかったポイントは２点。 このサンプルアプリは、データアクセス層が返すentityクラス(データベーステーブルと1対1に対応するJavaクラス)と、サービス層が返すdtoクラスを別々に作成しているが、それはなぜ、と説明しているか。また、entityクラス <-> dtoクラスのデータの詰め替えは、誰がどのように行うのか。 現代的なO/Rマッパーは、(業務アプリでは必然的に発生する)集計行を
「C.J.Dateの データベース実践講義」からいつか役に立ちそうな話をメモ(2) - 極北データモデリング
一応読了。 へぇと思ったところと、その他思いついたことをメモする。 ORDER BYはリレーショナル演算子ではない 理由は、タプルに並び順のあるもの＝リレーションではないものを返すから。 とはいえ、DateはORDER BYを否定しているわけではない。 便利な道具をリレーショナルモデルの上に積み増すことは、まったく問題ないと考えている。 しかし、積み増した道具が土台のリレーショナルモデルを破壊するなら、その導入には絶対反対の立場を取る。 例えば、ORDER BYはあっても構わないが、ビューの定義にORDER BYを含めることには反対する*1。 outer join否定論も同様。outer joinは便利だが、SQLの世界にnullを呼び込んでしまうのでDateは否定している。 第6正規形とnull 第6正規形の定義は以下の通り。 関係変数Rは、自明でない結合従属性を1つも満たさない場合に限
2006-04-24
ここでは３値論理のアウトラインを書いて、前回の課題のうち「maybe, unknown, undefined とはどういう意味の値か」だけ解決する。 ３値論理 SQLでは、nullは３値論理で扱われる。３値の真理値表は以下の通り。 NOT not true false null null false true AND true null false true true null false null null null false false false false false OR true null false true true true true null true null null false true null false nullがらみの論理演算結果、例えば nullの否定はnull. true AND null は null. true OR null はtrue. など
「インピーダンスミスマッチ」の本質は何か(3) - 極北データモデリング
本来の（OOP登場以前から言われていた）インピーダンスミスマッチの意味は、ものすごくおおざっぱに言うと、SQLはバッチ処理だが言語はレコード指向でしか処理ができないことだった。 そんなミスマッチは埋めようがないじゃないの。 仮にOOPとRDBの間に埋められない溝があるのだとすれば、我々にできることはどっちかに寄せて使うことしかない。 オブジェクト指向言語をオブジェクト指向言語的に使い、RDBを非RDB的に使う オブジェクト指向言語を非オブジェクト指向言語的に使い、RDBをRDB的に使う のどっちかを選択するしかない。 本来、２つのうちどっちかを選ぶという議論は不毛なので、極力避けなくてはならない。 プロなら、社会人なら、大人なら、両立させる方法を生み出さねばならない（Entity Bean や index-only は、その解の一種だ）。 が、それは置いといて。仮に二元論的な考え方で行くと
2006-01-04
2001年にJavaを始めたときにむなしさを感じたのは、ResultSetの形で取得したデータをJavaBeanのプロパティに詰め替えるコードを書いていたとき。 以来、 永続化層から取り出したオブジェクトをそのままViewに渡すと期待通りにレンダリングできて、 Viewから取り出したオブジェクトをそのまま永続化層に渡すとDBに書き込んでくれる そういうフレームワークを誰か作らないかなーと寝っころがりながら待っていたのだが、出てこない。 ていうかJavaオブジェクトの永続化手法は2001年時点よりも混乱しているように見える。ポジティブな言い方をすれば百花繚乱である。なぜだろう？ JavaとRDBとのギャップの本質とは何なのだろう。 で、インピーダンスミスマッチ。 ざっと調べると、インピーダンスミスマッチという言葉には、狭義と広義の使われ方があるようだ。 狭義のインピーダンスミスマッチは、 デ
PostgreSQLで Index-Only - 極北データモデリング
T字形サンプルアプリ作成の前段の作業として、PostgreSQLでIndex-onlyを実験中。 DOA+のレポート「非正規化すると本当に速いのか」は、DBMSにPostgreSQLを使ってIndex-Onlyを実行した貴重な実例。 http://www.doaplus.com/html/bun03_20051101.html ということは、PostgreSQLでIndex-onlyすることは可能ということだ。 Index-onlyとは、アクセスしたいデータをテーブルファイルではなくインデックスファイルのみから取得することで、高速レスポンスを可能にする技法。 参照したいカラムを全て含むマルチカラム・インデックスを作ればいいだけに思えるが、実際に高パフォーマンスを出すには、DBMSに以下の３点を強制しなくてはならない。 作成したインデックスを使わせる。 データファイルにアクセスさせない。 （
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
