日常用語で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 あり得ない)」と
Sybase IQが速い仕組み - 極北データモデリング
サイベースの情報系専用RDBMS・Sybase IQのデモを見てきた。 ノートPCにインストールしたSybase IQが、1億件ｘ数万件ｘ数万件ｘ数万件の結合と集計を5秒でこなしていた。 同社の汎用DB（Sybase ASE）は同等の処理に80秒かかっていた。 一般的なRDBがレコードをページに格納するのに対して、Sybase IQはカラムをページに格納する。 データをヨコ切りしないで、タテ切りしてディスクに書くわけだ。するとクエリに関係のない不要なカラムまで読み出して捨てる手間が省ける。これが速い理由の一つ。 ホワイトペーパーを引用すると 以下のような条件を想定してみます。 テーブルは1ローあたり800バイト、1000万ローからなる 性別・州・保険の加入状況のカラムがある 「カリフォルニア州で保険に加入していない男性」を検索する 汎用なRDBMSの場合、ロー単位のアクセスですから、800
2chに学ぶCGMとDBMSとの相性(データのローカリティはとても重要) - 最速配信研究会(@yamaz)
もう一ヶ月以上前の記事だけど,ニコニコ動画が1000万コメントを達成したというニュースがあった. 「24日で1千万コメント突破！ 「ニコニコ動画」が好調」 ドワンゴグループの1社で、メールポータルなどの事業を企画運営しているニワンゴは8日、同社がサービスを提供している「ニコニコ動画」（ベータバージョン）に投稿されたコメント数が、 オープンから24日で1,000万件を突破したことを発表した。また、1日のページビュー数が2,000万を突破していることもあわせて発表した。 http://www.rbbtoday.com/news/20070208/38344.html ニコニコ動画のすごいところは動画キャプション部は システム的に掲示板とほとんど同じで,おそらくその場に リアルでいる人の数はせいぜい数十人とかなのに,さも数100人 とかがその場にいるような臨場感を与えているところだと思う. モバ
極北データモデリング - 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
「何かと便利」な設計方針？ - 設計者の発言
データベースの「正規化崩し」の理由としてしばしば聞くのが「何かと便利なのでこのようにした」である。 たとえば、次のような関数従属要件があるとする。 これが、たとえば次のように物理設計される。 なぜテーブルＤやＤＦに、本来並ばなくていい項目がごそごそ並ぶのかと問うと、「これらを置くことで、関連テーブルを読まずに値が手に入る。プログラムがシンプルになるし、何かと便利だろうから」と説明される。 この種の設計の妥当性を吟味するためには、「継承属性」と「スナップショット項目」の違いを理解しておく必要がある。継承属性とは、あるテーブルから見て多重度１のテーブル上に載っている項目（テーブルＤから見ればＡ、ＤＦから見ればＡとＤ）のことで、インデックスを張るとか参照キー制約を組み込むといった明確な目的にもとづいて実装される。実装された継承属性については、もともと載っていた項目の値が変更されたら、すかさず値を
ACIDデータとACIDフリーデータ - 公園音楽のすゝめ
データベースのデータベースたる所以は、データが壊れないことだと言ってもいいでしょう。ACIDで保護されたデータですね。ところが最近考えているのは、ACIDで保護されない、ACIDフリーデータ。例えばあるメソッド内でしか使用されないローカルオブジェクトで、もしメモリに十分な余裕がある場合には、メモリ上で操作されるようなデータが、メモリ制限によってディスクを利用しなければならないようなデータに使いたいわけです。 トランザクションで保護されるということのメモリ・I/Oアクセスのオーバーヘッドはかなりのものです。つまりこれらのオーバーヘッドを取り除くことで、非常に高速で省メモリなアクセスが可能になります。db4oはオブジェクトデータベースですから、ACIDで保護されたオブジェクトとACIDフリーなオブジェクトは互いに参照を持っていても何ら問題ないようにします。例えばこんな風に： objectCon
IDがあっても、event からコードを削除してはいけない - 極北データモデリング
盛り下がってきたけど、今かすかにID論が熱い！ 渡辺氏がIDについて懸念していることに自分もよく引っかかるので、自戒のメモ。 コードはfactだから削除しちゃダメ ウチで持っているECサイトのパッケージでは、受注明細テーブルに、商品マスタから商品名をコピーして保持している。 商品名は時々変わるので、何かの方法で「販売時点の商品名」が取れるようになっていないと、お客さんに送った納品書と、 システムの受注履歴表示画面とで、商品名が違ってしまうから。 「コードは不安定で外部キーにはなり得ない」という立場に立つなら、コードも名前と同じ意味で、resource から event にコピーする必要がある。 商品コードを外部キーにするトラディショナルな設計では、商品コードは 商品マスタの当該レコードを指すポインタ 受注というイベントに属するfact（商品名とかと同じ） の２つの意味を持っている。 ID導
代理キーは「スタイル」ではなく「テクニック」 - 設計者の発言
データモデリングでは、複合キーに代わって単一項目の代理キー（サロゲートキー）を導入することがある。これは「モデリング上のテクニックのひとつ」ではあるが「モデリングのスタイル（基本方針）」とみなすべきではない。その根拠を説明しよう。 まず、倉庫が複数あるとして、倉庫にはさまざまな商品が保管されるとする。それぞれの商品は倉庫毎の特定の棚に保管される（つまり、商品と倉庫の組み合わせで棚が決まる）ことになっているとする（在庫管理では典型的な業務要件だ）。この関係をデータモデルで表すとモデル１のようになる。横浜第１倉庫でA01の棚に保管されることになっている商品１００の現在庫が２５０個であることが示されている。 このモデルをサロゲートキーにこだわって変形するとモデル２のようになる。 ２つのモデルの形式上の違いはどこにあるのだろう。モデル１では、倉庫コード、棚記号、品番が一次識別子として置かれているゆ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
not found
はてなブログ | 無料ブログを作成しよう
not found