Hello World程度のデータベース（その２３：外部スキーマ（７）ＳＱＬその６）

情報処理とは何から、データベースの基本的な話(情報処理試験のデータベーススペシャリスト程度の話まで）を書く、土日のシリーズ「Hello World程度のデータベース」です。

いま、ＳＱＬをやっています。
ＳＱＬは検索(select)、挿入(insert）、削除(delete）、更新(update)とあって、今回はSELECTにおける副問い合わせです。

---

■副問い合わせとは

いままで、ＷＨＥＲＥ句には、値を使っていましたが、検索結果を使うことも出来ます。

たとえば、ここで、
前回同様SHAIN_TBLが


そしてSYUSSEKI_TBLがこんなかんじ


になっているとき、（まったく意味ないんですけど）
SYUSSEKI_TBLでSHAINIDが、２番の人の姓と名をSHAIN_TBLから検索して出す場合、

SELECT SHAIN_TBL.SEI, SHAIN_TBL.MEI FROM SHAIN_TBL WHERE (SHAIN_TBL.SHAINID= (SELECT SHAINID FROM SYUSSEKI_TBL WHERE SYUSSEKI_TBL.SHAINID = 2));

となります。

　　あるテーブルの検索結果(カッコ内のSELECT)と、
　　テーブルの値(SHAIN_TBL.SHAINID)を
　　比較したいときに、

上記のように書きます。このとき”カッコ内のSELECT”が、副問い合わせ（サブクエリー）になります

---

■このサブクエリでは１つのレコードしか返せません

では、もうちょっと意味のあるものをやりましょう。
SYUSSEKI_TBLでEVENTIDが１２３番の人のSHAIN_TBLの姓と名をだしてみましょう。
つまり、イベント番号１２３番の出席者ということです。

これは、さっきのSHAINID=2がEVENTID=123に変わっただけだからと考えて

SELECT SHAIN_TBL.SEI, SHAIN_TBL.MEI FROM SHAIN_TBL WHERE SHAIN_TBL.SHAINID=(SELECT SHAINID FROM SYUSSEKI_TBL WHERE SYUSSEKI_TBL.EVENTID = 123)

と書いてしまうと、Ａｃｃｅｓｓでこうやると、

　　　このサブクエリでは１つのレコードしか返せません

というエラーになります。

どこが違うのでしょう。どーしてエラーになるのでしょう。

---

■ＩＮとＮＯＴ　ＩＮ

　はじめのＳＨＡＩＮＩＤ＝２のほうは、結果を満たすレコードが１レコードしかありません。
　それに反して、２番目のＥＶＥＮＴＩＤ＝１２３のほうは、結果を満たすレコードが複数（３レコード）あります。＝で結ばれたとき、複数だとこまります。

　初めの意図のようにイベント番号が１２３のもののレコードを出したい場合は、ＩＮを使います。こんなかんじ

SELECT [SHAIN_TBL].[SEI], [SHAIN_TBL].[MEI] FROM SHAIN_TBL WHERE (((SHAIN_TBL.SHAINID) IN (SELECT SHAINID FROM SYUSSEKI_TBL WHERE SYUSSEKI_TBL.EVENTID = 123)));

この場合、副問い合わせの中に「あるもの」になりますけど、逆に、「ないもの」を出したい場合はＩＮの代わりに、ＮＯＴ　ＩＮ　と書きます。

---

■ＥＸＩＳＴＳ

同じことを、EXISTSを使っても書けます。
こんなかんじ

SELECT [SHAIN_TBL].[SEI], [SHAIN_TBL].[MEI] FROM SHAIN_TBL WHERE EXISTS ( SELECT * FROM SYUSSEKI_TBL WHERE [SHAIN_TBL].[SHAINID]=[SYUSSEKI_TBL].[SHAINID] AND SYUSSEKI_TBL.EVENTID=123);

WHERE句の後にEXISTS句を書いて、そのあとの副問い合わせに連結内容（ＳＨＡＩＮＩＤが一致）と条件（ＥＶＥＮＴＩＤが１２３）と書けばいいのですが。。

　うーん、こっちのほうがわかりにくいですね。

　これにもＮＯＴ　ＥＸＩＳＴＳがあります（存在しないものを選ぶ）

---

■限定述語ＡＬＬとＡＮＹ（ＳＯＭＥ）

　ＡＬＬとＡＮＹ（ＳＯＭＥと同じ）というのがあります。

　ＡＬＬと書くと、副問い合わせの結果すべてに対して、条件を満たすものということになります。

　あんまり意味ないですけど、イベント番号１２３の出席者すべての社員番号より大きい社員番号の人を出すには、

SELECT [SHAIN_TBL].[SEI], [SHAIN_TBL].[MEI] FROM SHAIN_TBL WHERE SHAIN_TBL.SHAINID > ALL(SELECT SYUSSEKI_TBL.SHAINID FROM SYUSSEKI_TBL WHERE SYUSSEKI_TBL.EVENTID=123);

というようにかきます。
　WHERE句のところ、ＡＬＬを使って書くと、
　まず、副問い合わせの結果は１，２，３となるので、それより大きい、４番の香坂さんが表示されます（１件だけ）

　またまたあんまり意味ないですけど、イベント番号１２３の出席者のだれか１人の社員番号より大きい社員番号の人を出すには、

SELECT [SHAIN_TBL].[SEI], [SHAIN_TBL].[MEI] FROM SHAIN_TBL WHERE SHAIN_TBL.SHAINID > ANY(SELECT SYUSSEKI_TBL.SHAINID FROM SYUSSEKI_TBL WHERE SYUSSEKI_TBL.EVENTID=123);

というようにかきます。

　副問い合わせの結果は前回同様１，２，３なんですけど、そのうち、どれか１つより大きければよいとなると、２番の小笠原さんは、１番より大きいのでＯＫ、４番の香坂さんは、どれよりも大きいのでＯＫ，でも、１番の吉村さんは、１，２，３どれよりも大きくない（１番とは同じ、２，３より小さい）のでＮＧ，ということで、２番の小笠原さんと、４番の香坂さんが表示されます。

---

　っていうかんじなんですけど、わかりましたあ？？

受託会社とソフトベンチャーでは、そもそもスタートラインが違う

さいきん、
「中毒性」ある受託開発がソフトウェアベンチャーの躍進を阻む
http://blogs.itmedia.co.jp/repedant/2007/06/post_c660.html
というブログが話題のようだ

　この議論自体は、１０年以上前だったとおもうけど（雑誌名が思い出せないし、資料が手元にないので、いった人ははっきり書かないけど）某会社社長が「受託開発は麻薬である」といったのと、ま、似ていると思う（ちなみに、コレは当時、受託とパッケージの両方をやっていた会社があり、当時の人は、どこの会社を批判したことか明確にわかる話だった）。

　で、上記のブログのお話は、
（以下斜体はブログからの引用）

１．受託開発では「技術」が蓄積しない
２．受託開発では「人材」が蓄積しない
３．受託開発では「資金」が蓄積しない

という点から書かれている。

　ウィリアムのいたずらは、受託開発とソフトウエアベンチャー、両方の会社にいたわけで、その立場から見ると、表面的には、上記のとおりなんだけど、実際には、

「受託会社で成功する会社」
と
「ソフトウエアベンチャーで成功する会社（っていうかやっていく必要条件）」

の間にもっと、根本的な違いがあると思う。

その違いは、会社を実質的に運営する人間に、

「もし仮に、今日が自分の人生最後の日だとしたら、何をしますか？」

と聞いたとき（これば、スティーブ・ジョブズの変形だけど・・）

　・家族と過ごすとか、おいしいものを食べるとか、女の子と。。。
　　って、コンピューター以外のことを答えるのが、受託会社

　・あるコンピューターの技術を書き残すとか、新しいマシンを作れるところまで作るとか
　　コンピューターのことを答えるのがベンチャーで、
　　その分野の仕事をやれば、成功する。
　　→この人は、ジョブズがいうように、そのために必要な優先順位を付けていき、
　　　仕事をこなせば、いつかは、その分野で成功する可能性がある。

---

　たぶん、人生最後の日でも

　　スティーブ・ジョブズは、Coolなガジェットを考えていそうだし、
　　ビルゲイツは、コンピューターでビジネスを考えていそうだし
　　ウィリアムのいたずらは、ブログの連載を書いてるだろうし、
　　平井堅は、歌うたっていそうだ。。

　そんなかんじ。。本人に聞いて違う答えをしても、少なくとも、まわりからみて、そういうイメージを受けることが大切。また、将来的には変わることもあるし、変わってもいい場合もある（変わったところで会社が終わる場合もある）。

　そーいう人は、それに対する情熱もあるし、技術というか、知識というかもたいていある。なので、周りがついてくる。なんとなく、夢のある話のようだから、金持ちがカネを出すし、人も夢についてくる。

　そういう会社が受託をやる場合、自分が技術を持っている分野を、無理しないでやるのが普通で、そのような会社の受託の場合、あまりプラスにはならないけど、そんなにマイナスにもならない。ただ、受託で資金をつくったり、技術を培うのは、無理。
　もともと、技術はもっていて、資金はどっかから来るのが、ふつう。
　面白いことをやってるみたいと、人もきて、チャネルも人づてで、出来てくる。

---

　一方、人生最後の日に「家族と一緒にいる」とか「旅行する」という場合、コンピューターは、お金稼ぎの手段に過ぎない。ということは、仕事を「だぼはぜ」のように何でもとってくる（この業界で、何でも仕事を取ってくるときには、よく「だぼはぜのように」と形容される）。

　そうすると、今流行りの技術をやることになるから、技術の蓄積はない。
　たとえば、今Ｊａｖａのプログラマが売れるから、Ｊａｖａをみんな勉強しているが、このＪａｖａを技術と捕らえてしまうと、何年もつかわからない。ＣＯＢＯＬも、２０年前は廃れることはないと思っていた。今ＣＯＢＯＬの技術は余り役立たないし、ＰＬ／Ｉにいたっては、まったくだし、ＲＰＧっていったら、ロールプレイングゲームだとおもわれる。全部、いま、それらの技術や知識を持っていても、無駄。

　っていうだけならいいんだけど、むかしの開発方法と今の開発方法に連続性がない（これについては、ずーっと先に昔から今までの話をやろうと思ってて、そこで書くけど）ので、むしろ、昔の知識を持っていると、混乱することがある。

　だから、今流行りの技術を追いかけているだけでは、技術は蓄積しないんだけど、受託で人気なのは、今流行りの技術（今Javaで、多分次はWebＡＰＩ）だ。

---

　そして、人材に関しては、上記のブログで書かれているとおり。上流工程の技術が実は確定していない今において、下の受託企業は振り回されて、まず、社員の多くは３年以内でやめる。
　　１年目は、がんばる
　　２年目は、だめだと悟る
　　３年目で、求人誌をみて、他に行く
ので、人材も定着しない。定着する企業は、初めに述べたベンチャーみたいな会社だ。そこは、技術の中心があるので、ぶれない。だから、振り回されることがない（振り回されそうな仕事をはじめから受けない）
　上流工程のとくに機能要件に関しては、認知言語学などと組み合わせると、たしかにうまくいきそうなことは、このブログとかで示してきたわけだけど、そーいう研究を受注企業がすることはまず無理で、やるとしたら、、初めに述べたベンチャーみたいな会社か、ウィリアムのいたずらか、大企業だ。

　それが証拠に、ＢＲＥＷにおける開発は、昔から、受託で、大変な作業になっていたが、それがフレームワーク化できることは、このブログで示したあと、東芝ソリューションがやった、つまり、ＢＲＥＷの受託会社が、そーいうソリューションを出してくることはなかった。

　そもそも、そういう社長は、そーいうことには、興味はないのだ。

---

　なぜ、興味がないかというと、受託会社の社長にとっては、自分の生活が第一。

　で、受託の場合、自分の生活は守れる程度は儲かるので、文句はないが、パッケージをやるほど莫大なお金は儲からない。

　なぜなら、そんなに莫大な金が儲かるなら、受注金額を下げて、受注を多く獲得し、売上げを伸ばす会社が出るからだ。そーいう会社の社長にとって、会社を大きくすることは自分の名誉であり、楽しいことなのだ（むしろ、一番やりたいことかもしれない）その場合、売上げをあげることがうれしい。
　売上げを比較的安全にあげるには、受託先を増やす（集中すると、一時的にあがるが、リスクが大きくなる）。そのためには、単価を下げないと他社に勝てないのだ。そうすると、外注支払いや給与支払いのために、現金が必要になり、融資が必要になってくるので、利益率が下がる。

　一方、ベンチャーでやっているところは、受託をしたいわけではないので、ある一定の利益を出るところを狙う。そーすると、幅広くはできない。だから、大きくはならないけど、確実に利益は出るので、現金はたまってくる。

---

ってかんじで、表面的には、いろいろと違いがあるけど、根本的には、ジョブスの質問に、どう答えるか、これがすべてのような気がします。