« 2008年3月 | トップページ | 2008年5月 »

2008年4月29日 (火)

生命表というもの

河野 稠果 著 『人口学への招待』 (中公新書, 2007)1 p.47 より。

 ... 近年年齢が高くなると死亡率は高くなる傾向にあることが理解されるであろう。人間は老人になれば死ぬのだからそれは当たり前ではないか、と思われるかもしれないが、実は戦前はおろか、かなり最近まで当たり前ではなかったのである。生まれたばかりの乳児は死亡率がゼロで、そこから年を取るにしたがい右肩上がりに高くなっていくのではないかと思われるかもしれないが、戦前は実は全く違っていた。1921〜1925年頃は W の字が変形したような形をしていた。

厚生労働省が 生命表 というものを公表していまして、ここで、男女別の死亡率、死亡数、生存数、平均余命をみることができます。最新は、 第20回(平成17年)生命表 のようですね。

昭和22年(1947年)からの推移がわかりますが、確かに W の字の形になっていたことが推察されます。

Article_20080429_01_2

Article_20080429_02_2

Article_20080429_03_2

Article_20080429_04_2

死亡率 qx の定義は、「年齢 x 歳 に達したものが、 x + 1 歳 に達しないで死亡する確率」2 とあります。年齢階級別に死亡数をその人口で割ったものと考えて良いのでしょう。死亡数 dx は、基数10万人から始めて、年齢階級別に生存数に死亡率をかけて求めてたものです。


1.

人口学への招待―少子・高齢化はどこまで解明されたか (中公新書 1910) Book 人口学への招待―少子・高齢化はどこまで解明されたか (中公新書 1910)

著者:河野 稠果
販売元:中央公論新社
Amazon.co.jpで詳細を確認する

2. 平成18年簡易生命表 参考資料1 生命表諸関数の定義

| | コメント (0) | トラックバック (0)

2008年4月25日 (金)

「約8万ものテストケース」

はてなブックマークで人気エントリーに入っているこの記事。みなさん、それだけ注目しているということでしょうか。

例えば最終確認テストにおいては約8万ものテストケースをこなし,本番に向けては200のサブシステムについてそれぞれ232項目の移行判定基準を確認する。単体テストが終了してから8カ月もSE集団を抱え込んでテストと確認を繰り返す姿は鬼気迫るものがある。だが,それでも「必ず動く」とは言い切れないのがシステムの世界である。

6000人が作ったシステムは必ず動く (ITpro)

テストケース8万は少ないな、と感じたのですけど。”最終確認テスト”ですから、一つのテストケースの粒度はかなり大きいと考えるべきなのでしょうね。全サブシステムを横断して、かつ、最重要なケースに絞り込んだようなものを考えれば良いのですかね。サブシステムの網羅は当然やっている前提でしょう。

例えば:

2n = 80,000

とします。対数をもち出すまでもなく、プログラマであれば:

216 = 65,536

がすぐに出てくるでしょう。8万のケースというのは、2値状態を持つものが約16個程度あれば、全網羅で到達する数なのですよね。

また、6,000人という数字がありますから:

80,000 ÷ 6,000 ≒ 13

一人当たり13ケース程度しかできないとしますと、ひとつひとつのケースは相当大きいのでしょう。

しかし、”人力テスト”というのは、母集団に対してごく少数のケースしかカバーできないのですよね。そろそろ限界に来ている感はあります。

| | コメント (0) | トラックバック (0)

2008年4月24日 (木)

私が死刑制度に反対な理由

ある種の”卑劣さ”を感じるからですね。元来、他者の死を求める者は、自身の命をその代価とせねばならないはずでして。人を呪わば穴2つとでもいいますか。

かのハムラビ法典の第1条には、他者の死刑を求める者が、その立証を行なうことができなかったとき、その者は死刑になる、とあったと思います。目には目を、死刑には死刑を、というわけです。

また、イギリスには、19世紀まで、殺人罪その他重罪に関し、決闘裁判なる制度が存在していました。これは、その名のとおり、原告・被告の双方が、互いの命を賭け決闘を行い、正邪を決する、という制度です。自身の手袋を投じるのが、その宣言の儀式であったとか。これは、原告・被告のいずれかが望めば、行なうことができたようです。

もともと、刑事裁判というのは、現在のように、国家が訴追を行なうのではなく、民事裁判と同じく、私人間の争いとして行なわれていました。この場合、おそらく、刑を執行するのもまた、私人たる原告であったのでしょう。とすれば、死刑を望み、勝訴を得た場合でも、結局、自身の手で被告を屠らねばならないわけです。当然、被告は黙って殺されたりはしないでしょうから、不意を打ってでも返り討ちにする事態が予想されるわけでして、決闘裁判によるのも、一定の合理性はあったのでしょうね。

現代では、刑事裁判では、国家が訴追を行なうようになっています。問題は、国家という実体のない存在が主体となることで、訴追側の誰もリスクを負わなくなったことでありましょう。かっては命賭けで行い、自らの手を汚す必要のあったものが、現代では、被告人を除いて誰の命の危険もなく、また、手を汚すのも限られた人間となっています。かってより、被告人の命は軽く扱われているかのように思えます。

民主主義国では、国家の主権者は国民であるわけですから、死刑を執行する主体もまた国民である、といえるでしょう。とすれば、死刑執行人を国民の中からランダムに選び、その者が刑を執行する、というのも理にかなうと思います。死刑制度に本気で賛成する者であれば、自らの手を汚すことも厭わないはずです。辞退するのは自由で、その場合は刑は執行されないことにします。受刑者と”決闘”する、というのはさすがに無理でしょうから、受刑者が抵抗できない状態で殺すということでよいでしょう。

こうしますと、国民の中に死刑賛成の者がある程度存在し、その者が執行を行なう限り、死刑制度は存続します。辞退多数で刑の執行が行なえなくなれば、そのときには廃止することになります。

どうでしょうかね? もちろん、その際には、私は慎んで辞退させていただきますけどね。

| | コメント (0) | トラックバック (0)

2008年4月20日 (日)

消極的司法と「ねじれ国会」

本題とあまり関係ない感想ですが。

司法も対案示してほしい (レジデント初期研修用資料)

裁判所が、判決で暗に立法を促す、ということはあるはずでして、広い意味で”対案”を示す、ということはあるでしょうね。そして、三権分立という点から、こうした行為を、”司法権の逸脱”として批判する、というのは、よくあるようです。

しかし、三権分立というのは、立法・行政・司法が互いの領分を守って仲良くしましょう、ということではないように思いますけどね。当然、三権が激しく対立する事態をも含意しているはずです。かって、アメリカで、最高裁がニューディール立法をことごとく違憲として、議会と対立したように。

三権分立という言葉は、多義的で、いかようにもとれるところはあるのでしょう。日本では、互いに対立せずに、自らの仕事に専念すべし、という意味が与えられることが多いように思います。

何か似ているな、と思ったのが、いわゆる「ねじれ国会」という言葉。国会というのは、粛々と法律を処理するだけの場所ではなく、議論を交わすべき場所であるはず。また、上下両院に分かれているということは、制度上、上下両院が激しく対立する、という事態は含意しているはずです。「ねじれ国会」なんて事態は、起こって当然の現象だろうと思うわけです。

権力の対立というのは、もともと民主主義のシステムに組み込まれており、それが起きるのは、それこそ、民主主義が正常に機能している証じゃないのですかね。この国には、対立というのがお嫌いな方々が多い、ということなのでしょうか。

| | コメント (0) | トラックバック (0)

「もっと勉強してください」

ときどき見かけるこの発言ですが。少なくとも、”職業としての専門家”の発言ではないでしょうね。

知識ある者は、常に理解される責任をもつものとされてきた。素人は、専門家を理解するために、努力できるし努力すべきであるとしたり、専門家は、ごく少数の専門家仲間と話ができれば十分であるなどとすることは、野卑な傲慢というべきである。

大学や研究所の内部においてさえ、残念ながら今日珍しくなくなっているそのような態度は、彼ら専門家自身を無益な存在としてしまい、彼らの知識を、学識から衒学に変えてしまう。

P.F.ドラッカー著, 上田惇生訳, 『経営者の条件』, ダイヤモンド社, 1995, p. 82-83

素人がいるから、専門家であるわけでして。素人がいなければ、専門家もいないわけです。専門家というのは、自身の専門的知識をもって、素人に貢献するのが、その仕事であり、”飯の種”となっています。自身の専門分野について、必要なことを素人に理解させることのできない専門家というのは、確かに”無益な存在”であることでしょう。

Joel Spolsky 氏の分類に従うならば、この種の人間は、以下の2種類になりそうです。

  • 頭は良いが、成果の出せない人間
  • 頭が悪くて、成果の出せない人間

前者の例は、今まさにソフトウエアを出荷しようという段階で、特定箇所の実装の良否について議論を始めようとするような人間だそうで。”もっと勉強して”から、出荷するわけですな。この調子ですと、いつまでたっても出荷はできないわけですが。

もちろん、必要なことを素人に理解してもらう、というのは、簡単なことではないですけどね。コミュニケーションの重要性が声高に叫ばれているのも、専門分化の著しく進んだ現代にあって、異なる分野の専門家同士が協力することの困難さの表れでしょう。ある分野の専門家は、別の分野では素人であるわけですから、やはり、必要なことを素人に理解してもらわなければならないわけです。

職業として専門家をやっている人間にとっては、このようなことは百も承知のことでしょうけどね。日々、顧客にどうやって必要なことを理解してもらうか、ということに頭を悩ませているはずですから。

職業としては専門家をやっていない人間の場合。一体、自分の知識をもって他者に貢献しようとしているのか、それとも、自分の知識を自慢したいのか、あるいは、他者の知識のなさを笑いたいのか。自覚するのは難しいのかもしれませんね。

| | コメント (0) | トラックバック (0)

2008年4月19日 (土)

データベース正規形とSQL

データベース設計でテーブル正規化を行なう理由のひとつは、リレーショナル演算をスムーズに行なえるようにしたいからですね。つまり、データ処理を、もっぱらSQLを使って行なう、という設計戦略になるかと思います。

しかしながら、リレーショナル・データベースのテーブルをフラットファイルや、あるいは、索引付きファイルとして扱っても、それはそれで、ひとつの設計の考え方といえます。この場合、SQLの力を有効に使うことは難しくなりますので、データ処理は、もっぱら、ホスト言語となっている、なんらかのプログラミング言語を使って行なうことになるでしょう。テーブルは、リレーショナル・モデルではなく、本当に単なる”ファイル”である、というわけです。

正規化したテーブルが、プログラマに嫌がられるのは、リレーショナル・モデルが敬遠されているということであり、ひいては、SQLを使ってデータ処理をするのを嫌がっている、という見方ができます。

プログラマがSQLを嫌う理由は、本質的には、SQLが逐次実行型のプログラミング言語ではないから、かもしれませんね。メジャーなプログラミング言語のパラダイムとは、大分異なっているのは確かです。SQLというのは、”集合型言語”とでもいうべきものでありまして、独特のパラダイムを持っています。集合演算を中心とした言語、というのは、他にあまりないような気がしますね。関数型言語のリスト処理などは、近いとは思います。こちらもあまりプログラマには親しまれてはいませんね。

リレーショナル・モデルを使わないのなら、 RDBMSを使うのは、選択ミスともいえるわけですが。 RDBMS が一番入手しやすいという現実がありますからね。リレーショナル・モデルを使わなくても、トランザクション管理、メタデータ管理、 バックアップ、 レプリケーションなど、 DBMSで使いたい機能というのはあるわけでして。昔のように、TPモニタ(Transaction Processing Monitor)と、索引付きファイルとでOLTPを実現する、なんていうのはないでしょう。

| | コメント (0) | トラックバック (0)

2008年4月17日 (木)

Quality は従属変数

システム開発プロジェクトの3条件といえば、 Quality (品質)、 Cost (コスト)、 Delivery (納期) のいわゆる QCD と呼ばれるものになります。これらは、相互に関係していまして:

 Q = f(C, D)
 C = g(Q, D)
 D = h(Q, C)

といったような形になっているはずです。

しかしながら、現実には、 Cost と Delivery は、独立して決まることが多いわけでして。その結果、これらが独立変数となり、 Quality が従属変数となります。

 q = f(c, d)

また、 一般に、 Cost はより少ない方が、 Delivery はより短いほうが良いでしょう。

 c -> min, d -> min

そうしますと、 これらと Quality との関係は、以下のようになるかと思います:

 c -> min, d -> min ⇒ q -> 0

つまり、何もしなければ Quality はゼロへと向かいます。

Cost と Delivery には、計画段階でも、明確に定量的基準(つまり”数字”)が存在します。対して、 Quality というのは、定量化が難しい、あるいは不可能であるかと思います。事後には、ユーザの満足度等の数字を出すことで、ある程度定量化はできるでしょうが。計画段階では、部分的には定量化できる(処理性能、稼働率など)にしても、総じて定性的にしか定義できない(利便性、経営への貢献度など)と思います。

結果として、 Quality というのは、計画段階においては無視される傾向にあるわけです。

...といったことが、医療分野の Cost、 Access, Quality についても当てはまるのでは? と思ったのですが。私ごときの知識では書けそうにありません。

イキナリ私の答えを言っちゃうと、1)コストをかける、2)アクセス制限、3)医療の質をあきらめるのうち、どれか好きなのを選んでくれ、ということになる。

待ち時間問題 "Cost, access, quality. Pick any two." (NATROMの日記)

3つのうち2つを選ぶとすると、 ほぼ自動的に Cost と Access になりそうな予感。なぜなら、相当程度、定量的に、明確に表せそうだから。

 c -> min, a -> max ⇒ q -> 0

かくして、 Quality はゼロへと向かうのかもしれませんね。

| | コメント (0) | トラックバック (0)

2008年4月15日 (火)

プログラム設計書を書く目的

例えば、誰が書いても同じコードにするために、プログラム設計書(内部設計書)を今、書かせているとしたら、そんな無駄なものはやめたほうがいいと思う。

浜口さんに贈るSI業界を良くする方法 (ひがやすを blog)

プログラム設計書を書く目的というのは、”仕様の確実な伝達”ではないですかね。"誰が書いても同じコードにするため”ではないように思います。結果として、誰が書いても同じコードにはなるでしょうけど。設計書にある擬似コードをそのままコーディングすれば、同じになりますからね。

設計書の擬似コードと異なるプログラム・コードを書いても、別にかまわないはずです。

ただし、

設計書の擬似コード ≡ プログラム・コード

であることを、プログラマ自身が証明しなければなりません。表現の異なる2つのプログラムが、equivalent であることが、常に証明できるものなのかどうか、私は知りませんけど。

結局のところ、プログラムの仕様とは何で、それを伝えるためには、どうすればよいのか、というのが問題なんですよね。抽象的な文言というのは、その背後にあるコンテキストを共有していなければ、”正しく”解釈ができないわけでして。コンテキストを抜きにして、仕様を伝えようとすれば、結局、仕様とコードは表現が限りなく近くなってしまう、というジレンマがあります。プログラム・コードというのは、コンテキストのない表現の見本みたいなものですから。

プログラマに、システム化対象の専門領域について、コンテキストを共有してもらう、というのは、確かにひとつの手段なのですが。私には、プログラマがそれを望んでいるか、確信がもてなかったりします。プログラマは、プログラミングのために、”必要最低限の情報”を求めているようにも思えます。それが擬似コードであるというところが、なんだか、皮肉な感じではあるのですけどね。

| | コメント (0) | トラックバック (0)

認知的不協和論文の確率計算

認知的不協和理論の論文の誤り (Okumura's Blog) より。

元の実験では、まず猿に赤と青のM&Mのどちらかを選ばせ、赤を選んだ場合、次に青と緑から1つ選ばせる。この場合、青と緑では緑のM& Mを選ぶ確率が高くなることから、赤と青では赤の方が好みだっただけなのに「青が好きじゃなかった」と自身に思い込ませることから青の順位を下げてしまうと結論づけられている。

心理学者は確率計算が苦手? (スラッシュドット・ジャパン)

猿の集団には、以下の3群が3分の1ずつ存在するとしまして:

  • 赤が一番好き
  • 青が一番好き
  • 緑が一番好き

最後の集団(緑が一番好き)は、最初の選択(赤か青)では、一番好きな色がありませんので、二番目に好きな色を選びます。このため、一番目に赤を選び、二番目に緑を選ぶ猿の集団というのは:

(赤が一番好き かつ 緑が二番目に好き) + (緑が一番好き かつ 赤が二番目に好き)

となりますね。

対して、一番目に赤を選び、二番目に青を選ぶ猿の集団は:

(赤が一番好き かつ 青が二番目に好き)

のみとなります。よって、 2 : 1 で緑を多く選ぶことになる、ということでしょうかね。

一応、Rubyプログラムを書いて確認しておきます。

# free_choice.rb

RED = 0
BLUE = 1
GREEN = 2

blue_sels = 0
green_sels = 0

(1..100000).each do |i|
  first_sel = rand(3)
  if first_sel == GREEN
    second_sel = rand(2)
    green_sels += 1 if second_sel == RED
  elsif first_sel == RED
    second_sel = rand(2) + 1
    blue_sels += 1 if second_sel == BLUE
    green_sels += 1 if second_sel == GREEN
  end
end

puts "#{green_sels}:#{blue_sels}"

以下が、実行結果です。

>ruby free_choice.rb
33364:16601

緑 : 青 が 33.4% : 16.6% となりました。

| | コメント (0) | トラックバック (0)

2008年4月12日 (土)

コミュニケーション・コストを減らす方法

だからプログラマが仕様を決めちゃえばいいんだよ。そのほうがいいに決まってる。マネージャはユーザーの立場に立って要件を抽出しそれを固めていくことに邁進すればいい。プログラマはその要件を元に「それならこれで出来ます」という仕様を決めて、後は全部自分が実装までやればいい。本来、システム開発は要員が少ないほうがいいと思う。多すぎるとコミュニケーションコストが高すぎて死ねる。

プログラマが仕様を決めればいい (GoTheDistance)

システム開発を行なうのに、こうしたコミュニケーション・コストの高い方法が使われているのはなぜか、ということを考えますと、本質的には、システム開発に必要な情報量が膨大であるから、ということになるかと思います。この膨大な情報量を持つ”仕様”を、コンピュータに入力するため、”高すぎる”コミュニケーション・コストを支払っているのでしょう。

開発体制

システム開発というのは、典型的には、以下のような階層型の体制で行なわれます。

Article_20080411_01

顧客、SE(システムエンジニア)、PG(プログラマ)の3種類しかありませんが。SEのところは、マネージャーなり、コンサルタントなり、適当に読み替えても変わりません。要は、ドキュメントを書く人: SE、コードを書く人: PG という分け方です。

顧客と開発側の階層トップに位置するSEとが、仕様について打ち合わせ、決定した仕様を、下の中間層SEへと、担当別に分配して流します。さらに、中間層SEがその下のPGへと、各自の担当分に分配して流します。仕様は、上から下へと流れるだけではなく、各階層で概要から詳細へとより具体化され、情報量が増やされていきます。また、そうして各階層で作成された成果物は、階層を下から上へと上り、顧客の手に渡ります。

さて、上の図からSEをすべてはずし、顧客とPGだけを残しますと。

Article_20080411_02

顧客は、膨大なコミュニケーション量の前に押し潰されてしまいますね。このような多数と、コミュニケーションをとり、膨大な情報量を処理していくのは、不可能でありましょう。

結局、膨大な情報量のコミュニケーションを処理するために、間に入る人間が増えてしまうわけでして。SEがPGになったところで、本質は変わらないでしょうね。コーディング作業と、他とのコミュニケーションのための作業(結局はドキュメント書きになりそうですが)を両方やるということにはなりますけど。

仕様の情報量を減らさないことには、根本的な解決にはなりそうもありません。

仕様の抽象度

以下のように、顧客とPGとが、1対1で開発する体制を仮定しまして。

Article_20080411_03_3

要件として、弾道計算を行なうプログラムを考えます。仕様としては、以下の4段階とします。番号の大きなものほど、より具体性のある仕様、ということになります。

  1. 弾道モデルを表す微分方程式
  2. 微分方程式の数値解法(アルゴリズム)
  3. 弾道モデルの微分方程式の数値解を得るロジック
  4. 弾道計算のプログラム・コード

3番目の”ロジック”というのは、日本語で書いた擬似コードのようなものを想像していただければ。この例の微分方程式に対し、アルゴリズムを適用した結果です。

さて、顧客の仕事としては、どこまでの仕様を作れば良いでしょうかね。プログラマは、どのレベルの仕様があれば、そこからプログラム・コードまでの仕事をできるでしょうか。

SI現場の現実から考えますと、最低限、3番目まではやらないと、プログラマは仕事ができないでしょうね。それでもおそらくは不足でして、計算の具体例を何点かと、テスト・データも作成して渡してあげないと駄目でしょう。さもなくば、”わかりません”と言われておしまいです。

また、出来上がったプログラムは、顧客自身で、仕様どおりになっているか、チェックする必要があります。プログラマに渡した例を確認するのはもちろん、渡していない例も確認しないといけませんね。不具合が見つかった場合には、どのようなデータの場合に、どこがどのように間違っているのか、どうなるのが正しいのか、具体的に(”ロジック”のレベルまで落として)プログラマに教えなくてはなりません。さもなくば、”再現できません”と言われておしまいです。

どうすればいい?

結局、プログラマがもっと賢くなればよい、などという結論がでそうです。しかし、それは、人類全体の知的レベルをより引き上げるにはどうすればよいか、と問うようなものでしょうね。ある職業に従事するもの全員の知的レベルを引き上げる、というのは、そういうことかと思います。

できるとすれば、仕様を抽象的記述から具体的記述へと、機械によって変換することくらいでしょう。今のプログラミング言語よりも、より抽象的な言語は実現可能か、ということになりそうです。

| | コメント (0) | トラックバック (0)

2008年4月10日 (木)

インターフェイスとしてのリレーショナル・モデル

でも、経験的には、外部インターフェイスが同じであっても内部インターフェイスは、少なくともプログラムの場合は異なる。

データベース(端的にはテーブルのスキーマ)はどうだろうか? 同じだよなぁ。

結果は同じでも過程が異なる (L'eclat des jours)

まさにそのとおり、ですね。

リレーショナル・モデルの範囲内で考えると、"外部インターフェイス”として、唯一使えるのがビューになるわけですが。ビューは基本的に検索にしか使えないわけで、そうしますと:

  • テーブル: 挿入・削除・更新
  • ビュー: 検索

といった形にしかならないのですよね。

結合操作でできたビューが更新可能になる、というのは、現実の製品では聞かないですね。もし可能な製品があったとしても、導出元のテーブルを意識しないわけにはいかないでしょう。特に挿入と削除を行なう場合には。

・・・

テーブルが増えると、SQLクエリのJOIN句が複雑化してしまうという意見もあるが、羽生氏は「サブクエリやOUTER JOINがスラスラ書けない人は、DBの設計をすべきでない」と断言する。DBの設計は、プログラムの都合を一切忘れて行わねばならない、というのが氏の主張するところである。

DBは超グローバル変数、どう設計するか (マイコミジャーナル)

データベースをそうやって設計して、ユーザ/プログラマに「さあ、使ってください」という段階になって、”サブクエリやOUTER JOINがスラスラ書けない人”がユーザ/プログラマである場合は、どうしましょうか。

Who Needs Theory - Just Give Me The Data

Because most of what programmers do has no theoretical basis or system of proof, programmers back away from anything that looks like hard math. Failure to understand and appreciate relational theory has launched countless bad databases (and thousands of witless articles condemning SQL).

Why Programmers Don't Like Relational Databases (Typical Programmer)

アプリケーションで使う全てのクエリを、データベース設計者が書いて、プログラマに渡すとか。

内部設計の工程では,「詳細クラスモデル」 「SQLモデル」 「物理データモデル」を部分的に自動生成し,「共通詳細クラスモデル」を人手で作成する。

システム開発の業務プロセス自動化とは? (ITpro)

あるいは、O/Rマッパー(のようなもの)を使うとかですかね。それは、リレーショナル・モデルの”外”になりますけども。それこそ、オブジェクト指向のような、プログラミング・モデルで、リレーショナル・モデルを隠してしまう、という考えは、昔からありますね。3層C/Sモデルみたいな。

しかし、何か”屋上屋”な感じがして仕方がなかったりします。

| | コメント (0) | トラックバック (0)

2008年4月 4日 (金)

データベース正規化・非正規化

データ・モデリングの普及団体,DOA+コンソーシアムはこのほど,リレーショナル・データベース管理システム(RDBMS)の処理性能に関する実証試験を行い,調査結果を公開した。「データを正規化してデータベースに実装すると,処理性能が低下する」という"誤解"を正すため,実証実験を行ったという。

「DBを正規化すると遅くなる」は誤解,実証実験の結果が公開に (ITpro)

正規化(非正規化)すると早く(遅く)なる、という命題の立て方はどうかと思うのですけどね。

実証実験の結果,データベース上の単一テーブルを対象に検索した場合,いずれのパターンも2〜3ミリ秒で処理を終えた。一方,3つ程度のテーブルにわたりデータを検索した場合,正規化したパターンでは,5000万件のデータを90ミリ秒で検索できた。だが,非正規化したパターンでは,500万件のデータ検索に14秒かかった。

テーブルを非正規化したい理由としては、ユーザー/プログラマが結合操作を嫌う、というのは、よくあるんじゃないですかね。ですので、比較するなら、1テーブルに非正規化・集約したテーブルから検索する場合と、正規化した3テーブルを結合してから検索する場合とを比較するのが、妥当ではないかと思うのですが。この場合、得られるものが全く同じとすれば、非正規化の方が、おそらく処理速度は早くなるでしょうね。

非正規化というのは、正規化がまずあって、行なうものであるわけでして。非正規化によってメリットが得られないのであれば、それを非正規化というのは、どうなんでしょうね。単なる、”失敗作”であろうと思うのですが。

この手の話というのは、よくあるわけでして:

  • オブジェクト指向では、すべてをオブジェクトにするのが正しい。よって、使用する全ての項目について、クラス定義を行なう(しかも、それがリモート・オブジェクトだったり)。
  • 関数呼び出しをすると、呼び出しのコストの分、処理が遅くなる。よって、関数は使わずに、ひとつのルーチンにすべてを詰め込む。

設計というのは、相反する要求の間のトレードオフを考慮しつつ、最適な解を見つけ出そうとする活動なわけでして、一律にこうすべき、ああすべきなどとはいえないと思います。与えられた要件とその優先順位によって、解は異なるでしょう。

データベースの正規化というのは、データベースの拡張性・柔軟性を最大限に引き出すための、設計手法ですよね。それによって、失われるものというのは:

  • 検索の処理性能
  • 単純さ、あるいは、理解のしやすさ

といったものになると思います。

この二つは関係があって、デザインがプログラマにとって、複雑で理解しにくいものになっていたり、データの取得方法として、クエリを何通りにも書けたりすると、プログラマが性能の悪いクエリを書く可能性は、それだけ高まります。SQLクエリというのは、本番データ上で、実行してみなけりゃわからないところがあるのも現実です。コストペース・オプティマイザのように、データの統計情報によって、実行パスが変わるような場合は特に。

単純さ、理解のしやすさという点でも、テーブルの結合操作というのは、結構嫌われるのですよ。データベースの 正規化 vs 非正規化 というのは、オブジェクト指向でいう、小クラス主義 vs 大クラス主義 に通じるものがあるんじゃないですかね。

最後の手法が軽そうで良いなと思ってAPIリファレンスを眺める。

すると、javax.toolsがいかにも面倒そうなのでうんざりする。このうんざり感の原因には小クラス主義(1責務1インターフェイスあるいは、サブジェクト主義と名付けたくなる何か)にあるのだなということがわかる。

つまり、目的主義でAPIを眺めると、その目的にたどりつくまでのステップが多過ぎる。

その一方で、1責務1インターフェイスというのは、ケチのつけようがない考え方だと考えている自分にも気づく。

Javaのメタプログラミング (L'eclat des jours)

データベースにも、ファサドを作る方法というのはあって、ビューやストアド・プロシージャを使えば良いのですが。これはこれで、また新たな問題をもちこむことになるんですよね。

そんな単純な話じゃないよ、ということで。

| | コメント (0) | トラックバック (1)

« 2008年3月 | トップページ | 2008年5月 »