日常用語でnullを理解する(2) - 極北データモデリング
SQLにおけるnullは「値があることは分かっているが、それが何なのかはわからない」という意味だ。 「値がない」という意味ではない、ということに注意しなくてはならない。 nullは「値がない」ではない nullを「値がない」という意味だと考えてしまうと、 'a'と'b'とnullを連結した結果が、nullになる 1 + nullがnullになる といったSQLの挙動の意味が理解できなくなる。 nullが「値がない」という意味なら select 'a' || 'b' || null の結果には少なくとも'ab'が含まれているはずあって、「値なし」になってしまうのはおかしい。 また select 1 + null の結果が「値なし」になってしまうのも何だかよくわからない。 つまりSQLは、nullを「値がない」という意味のものとしては扱わない。 が、「値がない(まだない or あり得ない)」と
クラスタリングファクタによってSQLのパフォーマンスが変わる話 - 極北データモデリング
昨日の実験では、両側にインデックスがある場合、マージ結合とネスト化ループ結合の速さがハッシュ結合と同等かそれ以上になってしまった。 少量のマスタと大量のトランザクションの結合は、ハッシュ結合が圧勝してしかるべきなので何だこりゃと思ったのだが、これはテストデータが都合よく整列しているせいだとわかったので、結合カラムの値を更新して測定し直してみた。 データを作り直す 昨日の時点では、トランザクションデータの作り方に問題があって、結合カラム(tid)が同じ値のレコードが一箇所に固まっていた。 こんな感じ: bench=# select * from history limit 10; tid | bid | aid | delta | mtime | filler -----+-----+--------+-------+----------------------------+--------
元請から下請に変わって、仕事で理不尽な目に遭うことがなくなった話 - 極北データモデリング
人材募集広告の取材の人が会社に来て、私も転職者代表でインタビューを受けた。 前職と比べて何がよいか聞かれたので、こっちではお客さんに賞賛されたり社内で労われたりすることがあって、そんなこと期待したこともなかったので驚いた話をした。 これは何でなのかというと、以前よりお客さんが儲かるシステムを扱っているからだ。 あたりまえだと思われそうな話だが書いてしまう。 年間1億のコスト削減になるシステムなら、10画面ぐらいのWebアプリに数千万円の予算が付いて、納期もまっとうなものにできる。 逆に、できてもお客さんが大して儲からないシステムを企画すると、予算は付かないし納期も無理なものになる。 先方の担当者の構えも違ってくる。稼動しても社内で評価されないシステムなら、担当者に指名されてもやる気が出ないだろう。 また予算がないと、担当者が我々にタダで追加仕事をさせたくなるので、どうしても不幸なネゴシエー
お経を読んでしまったら自己啓発はおしまい - 極北データモデリング
仕事がひまになったのでこれを丁寧に読んだ。 ブッダのことば―スッタニパータ (ワイド版 岩波文庫) 作者: 中村元出版社/メーカー: 岩波書店発売日: 1991/01/24メディア: 単行本購入: 4人 クリック: 21回この商品を含むブログ (4件) を見るブッダの真理のことば・感興のことば (ワイド版 岩波文庫) 作者: 中村元出版社/メーカー: 岩波書店発売日: 1991/06/26メディア: 単行本購入: 4人 クリック: 13回この商品を含むブログ (3件) を見る 解説によれば、これらは仏典のなかで最も古いもので「ブッダのことばに最も近い詩句を集成した聖典」であるとのこと。 これ読んでしまうと、人生論とか自己啓発書みたいなのはもう読む気がしない。 2500年前に答えは出ているのだ。 私は大昔のインド人と同じことで苦労している。現代特有の苦なんてものはない。 「ブッダのことば」P
マスタメンテナンスで未来のデータを入力したいんですけど - 極北データモデリング
マスタメンテの扱いは毎回困るところ。 どうもマスタデータには「最新」系のものと「無時間」系のものがあるらしい。 いつのトランザクションデータと結合しても問題ないのが「無時間」のマスタで、問題を起こすことがあるのが「最新」のマスタ。 元号マスタなんてのは無時間。 商品マスタとか部門マスタなんかが「最新」のマスタ。属性が今時点の値になっているので、古ーいトランザシクョンデータと結合すると「商品名が(過去の事実と)違う」「部門の所属セグメントが違う」みたいなことになる。 そういう属性はトランザクションデータ側にコピーしておけばとりあえず問題ないんだけど*1、ほんとに困るのは未来のデータを前もって入力したいとき。 例えば4/1から新入社員が1000人入ってくる会社で、3月中に新人の情報をちまちま入力していると、3月中の社員数が狂ってしまう。正しくは4/1の明け方に1000人分入力しなくてはならない
ウィトゲンシュタインの物差し・「いやらしい体」・他人の商売の悪口 - 極北データモデリング
今年No.1の名著「まぐれ」を読む。 まぐれ―投資家はなぜ、運を実力と勘違いするのか 作者: ナシーム・ニコラス・タレブ,望月衛出版社/メーカー: ダイヤモンド社発売日: 2008/02/01メディア: 単行本購入: 28人 クリック: 585回この商品を含むブログ (174件) を見る この中に「ウィトゲンシュタインの物差し」といういい話が出てくる。 書評は本そのものよりも書評を書いた人のことをいろいろと描き出す。私はこの仕組みをウィトゲンシュタインの物差しと 呼んでいる。物差しでテーブルの長さを測っているとき、とても信頼できる物差しでなければ、同時にテーブルで物差しを 測っていることになる。物差しが当てにならなければ当てにならないほど、得られる情報は物差しに関するものが多くなり、 一方テーブルに関するものは少なくなる。 これ、気付かないでやってしまうと恥ずかしいことになるから注意が必要
いかに生きるべきか - 極北データモデリング
昭和十三年に初版が出た、当時80代の禅僧の講話集を読む。 禅談 作者: 沢木興道出版社/メーカー: 大法輪閣発売日: 1997/12/01メディア: 単行本購入: 3人 クリック: 12回この商品を含むブログ (1件) を見る いかに生きるべきかという問題にいまさら独創的な解が残されているはずもなく。戦前に答えはほとんど出揃っていることが分かる。 P-110 たいがいの問題はじっと三十年辛抱しておれば解決してしまう。 もう八十にもなれば「あんなことがあったなー」ということになってしまう。 P-280 採用試験を受けて、通るか知らん、通らぬか知らん、と心配して神経衰弱になってやって来た奴がある。 「お前が通らんなら、お前よりよい奴が通るのだから、よいじゃないか」と言ってやったら「へー」と、狐につままれた ような顔をしておった。おれさえ通ればよい、あいつが通ったら口惜しいというような奴は通らん
オンスケジュール＝崖っぷち - 極北データモデリング
転職して分かった、進捗管理という面白くない作業を楽しくやる方法について。 タイトなスケジュールを組んで、そこからの遅れをチェックするから、楽しくないし、遅れが隠蔽される。 ダルダルにゆるいスケジュールを組んで、1週間以上前倒しにできているかどうかをチェックすれば、みんな遅れていることを隠さないので早めに手が打てる。 タイトなスケジュール＆遅れチェックだと「2日遅れです」と言わなくてはならないところを、だるいスケジュール＆1週間前倒しチェックなら「3日前倒しです」と言えるので気分がいい。 情報量はどっちの言い方でも同じだから、気分のいい言葉を使えばよい。 だいたいオンスケジュールというのは崖っぷちに居るということで、カゼ引いたり障害発生したりしたら即遅れてしまうのだから、「オンスケです」という報告がよいニュースのわけがない。「前倒し」という名前を付けたバッファの減少傾向を見張って、オンスケジ
「フォトリーディングしても、読めたような気がしない...」 - 極北データモデリング
講師の先生に聞きたいことがあったので、週末にフォトリーディングの再受講に行ってきた。 聞きたかったことは インストラクターの人たちは、STEP3(=いわゆるフォトリーディング。ページをパラパラめくるあれ)をやっただけで、我々が普通読みしたのと同じ「読んだ！」「わかった！」という感覚を得ているのか。 STEP3が効果的にできているか、それともただページをめくっているだけで全く頭に入っていないのか、それを自分で知る方法はあるか。 の２点。 今回は20人弱の少人数のクラスなので一人ずつ丁寧にフォローしてもらえた。なので50人ぐらい居た前回より受講者の化け方が激しい。 初受講の人たちはみんなものすごい勢いで読書観を転換して、2日目の昼には全員10倍以上・最高の人だと62倍の速さで読み飛ばせるようになってしまった*1。 で、講師の先生に上の質問をしてみたら、やはりSTEP3しただけで普通読みしたのと
並行プロジェクトは問題ではない。環境だ - 極北データモデリング
うちの会社をやめて独立した人に、久しぶりに会って話をした。 彼が言うには、ウチの会社の問題は、全員が複数のプロジェクトを並行して進めなくてはならないような、受注の仕方をすることにあるのだそうだ。並行プロジェクトは効率が悪いことを営業サイドが理解していないのではないか、とか言っていた。そんなアホな。 受託開発はお客の都合で納品時期が決まるので、来た仕事を普通に受注していたら、複数のプロジェクトを並行して進めなくてはならない時期が必ず発生する。それがいやなら、ウチの一方的な都合で決めた納品時期をお客に飲ませる技術を、営業サイドに開発してもらわなくてはならない。 並行プロジェクトが開発効率を下げる、なんてことは誰でも知っている。が、ウチの一方的な都合で納品時期を決められないのも、おんなじぐらい分かりきったことだ。 「並行プロジェクトは開発効率が悪いからやめよう」なんてのは「開発サイドは難しいこと
DWHではouter join上等 - 極北データモデリング
今メンテしているDWHでは、トランザクションデータに対してマスタを結合するときに、やたらとleft outer joinが使われている。 outer joinしているということは、結合できるマスタデータがないことを想定しているわけで、そもそもそんなことがあり得ないようにシステムを作らないとまずいんじゃないの、というのが第一印象。 が、DWHのデータは夜中に複数の外部システムから流し込まれたものなので、DWH自身はそれらの整合性を保証することができない。 なので、マスタデータに欠落があったときに、ひっそりとトランザクションの件数が減ってしまうinner joinよりも、データに不整合があっても合計値が維持されるouter joinの方がベターなのだ。 メンテしてみてわかったのだが、DWHというのは集計値の検証が一番大変だ。 結合の失敗でトランザクションがひっそりと欠落したりすると、どの段階で
Sybase IQが速い仕組み - 極北データモデリング
サイベースの情報系専用RDBMS・Sybase IQのデモを見てきた。 ノートPCにインストールしたSybase IQが、1億件ｘ数万件ｘ数万件ｘ数万件の結合と集計を5秒でこなしていた。 同社の汎用DB（Sybase ASE）は同等の処理に80秒かかっていた。 一般的なRDBがレコードをページに格納するのに対して、Sybase IQはカラムをページに格納する。 データをヨコ切りしないで、タテ切りしてディスクに書くわけだ。するとクエリに関係のない不要なカラムまで読み出して捨てる手間が省ける。これが速い理由の一つ。 ホワイトペーパーを引用すると 以下のような条件を想定してみます。 テーブルは1ローあたり800バイト、1000万ローからなる 性別・州・保険の加入状況のカラムがある 「カリフォルニア州で保険に加入していない男性」を検索する 汎用なRDBMSの場合、ロー単位のアクセスですから、800
おれおれサブセット実装 - 極北データモデリング
サブセットを実装するとできなくなってしまうことに unique制約 外部キー制約 がある。 例えば、社員マスタを正社員とパート社員というサブセットに分割したとして、 正社員(R) = { 社員ID, 社員コード, 名前, ... } パート社員(R) = { 社員ID, 社員コード, 名前, ... } 社員コードは全社員を通じてユニークである必要があったら、それをチェックするのが面倒になる。 サブセットの社員コードにそれぞれ unique 制約をつけても、「社員全体で一意」かどうかのチェックにならないから。 また、社員の扶養家族マスタというのがあったとして、 社員の扶養家族(MO) = { 社員ID, 続柄コード, 扶養家族名 } このテーブルの社員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
IDがあっても、event からコードを削除してはいけない - 極北データモデリング
盛り下がってきたけど、今かすかにID論が熱い！ 渡辺氏がIDについて懸念していることに自分もよく引っかかるので、自戒のメモ。 コードはfactだから削除しちゃダメ ウチで持っているECサイトのパッケージでは、受注明細テーブルに、商品マスタから商品名をコピーして保持している。 商品名は時々変わるので、何かの方法で「販売時点の商品名」が取れるようになっていないと、お客さんに送った納品書と、 システムの受注履歴表示画面とで、商品名が違ってしまうから。 「コードは不安定で外部キーにはなり得ない」という立場に立つなら、コードも名前と同じ意味で、resource から event にコピーする必要がある。 商品コードを外部キーにするトラディショナルな設計では、商品コードは 商品マスタの当該レコードを指すポインタ 受注というイベントに属するfact（商品名とかと同じ） の２つの意味を持っている。 ID導
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
