Googleの弱点を克服した検索エンジンを実装
【NET&COM2007】「Googleの弱点を克服した検索エンジンを実装」---Web 2.0時代に向けたLinux活用技術
記事一覧へ
source from http://itpro.nikkeibp.co.jp/article/NEWS/20070209/261537/
ウェブリオ 取締役最高技術責任者 佐々木亨氏
ウェブリオ 取締役最高技術責任者 佐々木亨氏
[画像のクリックで拡大表示]
Weblioのトップページ
Weblioのトップページ
[画像のクリックで拡大表示]
Preferred Infrastructure リサーチャー・エンジニア 岡野原大輔氏
Preferred Infrastructure リサーチャー・エンジニア 岡野原大輔氏
[画像のクリックで拡大表示]
接尾辞配列方式。Sedueはこれを改良した圧縮接尾辞配列方式を採用している
接尾辞配列方式。Sedueはこれを改良した圧縮接尾辞配列方式を採用している
[画像のクリックで拡大表示]
Preferred Infrastructure 代表取締役社長 西川徹氏
Preferred Infrastructure 代表取締役社長 西川徹氏
[画像のクリックで拡大表示]
Seudoの分散システム
Seudoの分散システム
[画像のクリックで拡大表示]
ミュートス 執行役員情報システム開発長 宗近龍一郎氏
ミュートス 執行役員情報システム開発長 宗近龍一郎氏
[画像のクリックで拡大表示]
日本スケーリックス 取締役 大塚和彦氏
日本スケーリックス 取締役 大塚和彦氏
[画像のクリックで拡大表示]
「Googleの弱点を克服したアルゴリズムによる検索エンジンを世界で初めて実装した」（Preferred Infrastructure 岡野原大輔氏）---リナックス ビジネス イニシアチブ（LBI）は2月8日，Net&Com2007で「Web 2.0時代に向けたLinux活用技術」と題したセミナーを開催，Linuxを活用した新サービスなどに関する発表が行われた。
ウェブリオ 取締役最高技術責任者 佐々木亨氏は「Weblio辞書検索の秘密−中古Linux機で月間600万PV−」と題した講演を行った。
Weblioは，様々な辞書や百科事典，200以上の辞書を一度に検索できるサイトである。月間600万PVのアクセスがあるが，それに対し軽快な動作を安価に提供するために様々な工夫を凝らしているという。
まずWeblioのサイトはLinuxを始めとするオープンソース・ソフトウエアを全面的に採用している。負荷分散もLinux Virtual Serverなどオープンソース・ソフトウエアで行っている。他のサイトのサービスを利用する，いわるゆマッシュアップ的なサービスであるため，他のサイトにアクセスしてデータを取得するため遅延が生じる場合があるが，その対策としてプロキシ・サーバーでデータをキャッシュしている。
また，サーバー機は中古マシンを使用している。「これにより同程度のスペックのマシンが約半額で調達できた」（佐々木氏）という。
Sedue：圧縮接尾辞配列を実装した初の商用検索エンジン
Preferred Infrastructureの西川徹氏と岡野原大輔氏は「Sedueによる検索サイト構築 〜情報ビッグバン時代に向けて〜」と題して講演した。
Preferred Infrastructureは，IPAの未踏ソフトウェア創造事業の開発者や世界的なプログラミング・コンテスト出場者らが設立技術ベンチャ。同社が開発した検索エンジンSedueについて紹介した。
前文検索エンジンのアルゴリズムにいくつかの方式がある。「Googleが採用しているのは『転置ファイル』と呼ぶ方式で，各単語ごとに，どの文書に出現したかを記録するもの。Googleは単語に分けてサーバーを配置している。シンプルで速く分散処理しやすいが，単語の境界が不明瞭な日本語では検索漏れが生じる恐れがあるほか，フレーズ検索も苦手」（岡野原氏）。
Sedueが採用したのは，圧縮接尾辞配列と呼ぶアルゴリズムだ。接尾辞配列とは，文字列を後方から1文字ごとに切り出した「接尾辞」を，辞書順序に記録する方式。漏れがないこと，どんな検索でも高速であるという長所があるが，索引のサイズが大きくなる，索引の構築に時間がかかることが難点だった。この問題を解決するために，圧縮接尾辞配列方式では，索引を圧縮することでサイズを小さくする。また「構築に時間がかかるという難点は，最近，高速なアルゴリズムが提案されたことで解決された。Sedueはこの圧縮接尾辞配列方式を実装した，初めての商用検索エンジン」（岡野原氏）。
また「Seudoはシステムを分散化・冗長化し，データ容量や信頼性を向上できるよう設計されている」（西川氏）という。
ミュートス 執行役員情報システム開発長宗近龍一郎氏は，ソーシャルブックマークサービスの動向と同社が開発中の「BookDAQ」などについて講演した。BookDAQは，ソーシャルブックマークにコミュニティ機能を加えたもので，マーケティング・ツールとしての利用が見込めるという。
日本スケーリックス 取締役 大塚和彦氏は，Linux上で稼動するOutlookライクなAjax Webグループウエア「Scalix」を紹介した。Webブラウザ上で，ドラッグ＆ドロップはもとよりCtlキーを押しながら複数のメールを選択したり，右クリックでコンテキストメニューを表示させたりなど，クライアント・アプリケーションと同様な使い勝手を実現しているという。無償版もあり，近くオープンソース版も公開される予定である（関連記事）。
手机无线搜索市场商机渐显
手机无线搜索市场商机渐显
2007年12月14日06:42 [我来说两句] [字号：大 中 小]
来源：深圳新闻网-深圳特区报
巨大的用户市场和逐渐完善的3G技术吸引越来越多企业进入
手机无线搜索市场商机渐显
依靠PC开展互联网搜索业务，成就了百度、谷歌等知名企业。随着3G的即将推出，把类似互联网的搜索业务放到手机上的无线搜索成了企业掘金的新领域。
昨天，记者从“新经济时代企业创新营销高峰论坛”上了解到，无线搜索领域成企业掘取的新金矿。
无线搜索成待挖金矿
电脑的普及成就了一大批以互联网搜索业务为核心的企业，11月百度总市值达到约140亿美元，相当于新浪、搜狐、网易、TOM在线四大门户网市值的总和，有线搜索引縕巨大的市场蛋糕让人垂涎。随着手机的普及以及3G的推出，无线搜索的商机越来越凸显。
与传统互联网搜索相比，无线搜索的自由度更大，可随时随地搜索自己需要的信息。无线搜索服务商还可以通过与定位服务的结合，为客户提供更有针对性的产品。例如，当用户需要了解就餐资讯时，无线搜索技术可以根据他们所处的位置来反馈就近的餐馆而不是简单地罗列信息和海选。
根据信息产业部统计显示，到8月底，全国手机用户数超过5.15亿户，约为互联网用户的3至4倍。巨大的用户市场、良好的用户体验以及逐渐完善的3G或4G技术，手机无线搜索市场被越来越看好，越来越多的企业进入无线搜索领域。
早在2004年，Google、雅虎就已推出短信搜索服务和WAP网站搜索服务。在中国移动未来的战略中，无线搜索与即时通讯、博客、音乐并列四大主要业务。新进入市场的竞争者如宜搜、Cgogo、易查、上海明复、悠悠村等已经在专业手机搜索领域捷足先登，也将成为传统搜索巨头有力的竞争者。
中国和世界站在同一起跑线
相对于传统搜索引縕的成熟，无线搜索正处于启蒙阶段，世界范围内尚无成熟的赢利模式借鉴，也就是说在无线互联网方面，中国和其他国家站在同一起跑线上，这意味着，在无线搜索领域，中国企业将拥有更多的机会。
在高峰会上，业界人士指出，由于国内外用户使用的搜索习惯以及浏览习惯不同，国内企业相对拥有优势。同时，无线搜索技术对人性化及实效性的关注和要求对服务提供商的现有技术是一个不小的挑战，因此国内现有的互联网搜索巨头对于新兴企业无十分明显的先发优势。此外，搜索对本土化的要求在互联网里就已经制约了Google和雅虎这些外来者在中国复制霸业的梦想，外来者在无线搜索业内也有类似的瓶颈。所以新兴企业完全有可能借助突破性技术以及对本土和各内部细分地域的熟悉及渠道资源的掌控，来与巨头们一较长短。
深圳企业欲抢占行业制高点
记者了解到，深圳宜搜科技已成为业内最大的无线搜索门户之一。
宜搜的用户可以通过WAP、短信和互联网三种途径搜索查询本地或异地生活信息、铃声、图片等。以短信搜索为例，如果手机用户用短信搜索，发送“湘菜”到宜搜的短信端口，就会收到该手机号所在地区的湘菜馆联系名称、电话、地址等。目前宜搜的日访问量超过2000万人次。宜搜科技其成熟的技术和业务模式，已经为它赢得了三轮风险投资的垂青，总额超过3500万美元。
谈到市场前景，宜搜核心代理商上海天下欣网负责人凌宗武信心十足，“手机上网始终是今后的主流趋势，尤其是3G牌照下发后可能会有一个大的爆发。手机网络一旦迅速发展，将像PC网络一样不可避免地对搜索提出需求。”
中国モバイル検索
著者: ザイロン チャイナプレス プリンター用 記事を転送
▼2007年12月11日 17:00 付の記事
■ザイロン チャイナプレス 発の記事
このエントリーを含むはてなブックマーク この記事をクリップ！ Buzzurlにブックマーク Yahoo!ブックマークに登録 newsing it!
12月11日、艾瑞マーケットコンサルティング（iReseach：インターネット専門のマーケットリサーチ会社）が発表した「2007年中国無線検索エンジン研究報告」によると、易査（Yicha.cn）は携帯検索エンジン市場シェアの57.1％を占め、Google と百度はそれぞれ31.5％と25％で第2、3位となった模様。
Cgogo、UU 村、そして明複三社はそれぞれ、10.6％、9.0％と2.8％のシェアを占めるという。
現時点で、Google と百度のモバイル検索市場における優位性が見られない原因は、モバイル検索市場への「出遅れ」と見られている。百度は2006年3月に、Google は2007年1月にモバイル検索を開設している。
一方で、易査（Yicha.cn）は2004年7日に開設、2007年11月時点で2,000万ユーザーを抱えるという。
デザインパターン (ソフトウェア)
デザインパターン (ソフトウェア)
出典: フリー百科事典『ウィキペディア（Wikipedia）』
移動: ナビゲーション, 検索
ソフトウェア開発におけるデザインパターン(または設計パターン、英: design pattern)とは、過去のソフトウェア設計者が発見し編み出した設計ノウハウを蓄積し、名前をつけ、再利用しやすいように特定の規約に従ってカタログ化したものである。
デザインパターンの古典的な例としては、Smalltalkシステムで導入された Model View Controller (MVC) が挙げられる。
書籍『オブジェクト指向における再利用のためのデザインパターン』において、GoF (Gang of Four; 4人のギャングたち) と呼ばれる4人の共著者は、デザインパターンという用語を初めてソフトウェア開発に導入した。 GoFは、エーリヒ・ガンマ、リチャード・ヘルム、ラルフ・ジョンソン、ジョン・ブリシディースの4人である。
彼らは以下のように述べている
[Design patterns] solve specific design problems and make object-oriented designs more flexiblem elegant, and ultimately reusable. They help designers reuse successful designs by basing new designs on prior experience. A designer who is familiar with such patterns can apply them immediately to design problems without having to rediscover them.
コンピュータのプログラミングで、素人と達人の間ではびっくりするほどの生産性の差があるのだが、その差はかなりの部分が経験の違いからきている。達人は、さまざまな難局を、何度も何度も耐え忍んで乗り切ってきている。そのような達人たちが同じ問題に取り組んだ場合、典型的にはみな同じパターンの解決策にたどり着くのだが、これがデザインパターンである。(GoF)
それぞれのパターンは、プログラマの間で何度も繰り返し考え出されてきた。なので、それは最善の解決策ではないかもしれないが、その種の問題に対するトレードオフも考慮した、典型的な解決策ではある。更に、コストのかかるかもしれない問題解決を実際に行う前の先行調査として大変役に立つ。パターンには名前がついていることが重要である。なぜなら、名前がついていることで問題や解決策を記述したり、会話の中で取り上げたりすることができるようになるからである。
目次
[非表示]
* 1 GoFによる23のパターン
o 1.1 生成に関するパターン
o 1.2 構造に関するパターン
o 1.3 振る舞いに関するパターン
* 2 参考文献
* 3 関連項目
[編集] GoFによる23のパターン
GoFは彼らの著作『オブジェクト指向における再利用のためのデザインパターン』の中で23種のパターンを取り上げた。
[編集] 生成に関するパターン
Abstract Factory パターン
関連する一連のインスタンスを状況に応じて適切に生成する方法を提供する。
Builder パターン
複合化されたインスタンスの生成過程を隠蔽する。
Factory Method パターン
実際に生成されるインスタンスに依存しない、インスタンスの生成方法を提供する。
Prototype パターン
同様のインスタンスを生成するために、原型のインスタンスを複製する。
Singleton パターン
あるクラスについて、インスタンスが単一であることを保証する。
[編集] 構造に関するパターン
Adapter パターン
元々関連性のない2つのクラスを接続するクラスを作る。
Bridge パターン
クラスなどの実装と、呼び出し側の間の橋渡しをするクラスを用意し、実装を隠蔽する。
Composite パターン
再帰的な構造を表現する。
Decorator パターン
あるインスタンスに対し、動的に付加機能を追加する。Filterとも呼ばれる。
Facade パターン
複数のサブシステムの窓口となる共通のインターフェースを提供する。
Flyweight パターン
多数のインスタンスを共有し、インスタンスの構築のための負荷を減らす。
Proxy パターン
共通のインターフェースを持つインスタンスを内包し、利用者からのアクセスを代理する。Wrapperとも呼ばれる。
[編集] 振る舞いに関するパターン
Chain of Responsibility パターン
イベントの送受信を行う複数のオブジェクトを鎖状につなぎ、それらの間をイベントが渡されてゆくようにする。
Command パターン
複数の異なる操作について、それぞれに対応するオブジェクトを用意し、オブジェクトを切り替えることで操作の切り替えを実現する。
Interpreter パターン
構文解析のために、文法規則を反映するクラス構造を作る。
Iterator パターン
複数の要素を内包するオブジェクトの全ての要素に順にアクセスする方法を提供する。反復子。
Mediator パターン
オブジェクト間の相互作用を仲介するオブジェクトを定義し、オブジェクト間の結合度を低くする。
Memento パターン
データ構造に対する一連の操作のそれぞれを記録しておき、以前の状態の復帰あるいは操作の再現を行えるようにする。
Observer パターン
インスタンスの変化を他のインスタンスから監視できるようにする。Listenerとも呼ばれる。
State パターン
オブジェクトの状態を変化させることで、処理内容を変えられるようにする。
Strategy パターン
データ構造に対して適用する一連のアルゴリズムをカプセル化し、アルゴリズムの切り替えを容易にする。
Template Method パターン
あるアルゴリズムの途中経過で必要な処理を抽象メソッドに委ね、その実装を変えることで処理を変えられるようにする。
Visitor パターン
データ構造を保持するクラスと、それに対して処理を行うクラスを分離する。
[編集] 参考文献
* 『オブジェクト指向における再利用のためのデザインパターン』、エリック・ガンマ (著) 、ラルフ・ジョンソン (著) 、リチャード・ヘルム (著) 、ジョン・ブリシディース (著) 、グラディ・ブーチ (まえがき) 、本位田真一 (監訳) 、吉田和樹 (監訳) 、ソフトバンクパブリッシング、1999年 (初版は1995年)、ISBN 978-4797311129
[編集] 関連項目
Wikimedia Commons
ウィキメディア・コモンズには、ソフトウェアのデザインパターンに関連するカテゴリがあります。
* アンチパターン
* アナリシスパターン (マーティン・ファウラー)
* 開放/閉鎖原則
JDBC とODBCの違い
1.1 JDBCTMとは
JDBCTM は、SQL 文を実行するための JavaTM API です (参考までに、JDBC は登録名であって略語ではありません。しかし、JDBC は「Java Database Connectivity」の略だと思われることがよくあります)。これは、Java プログラミング言語で書かれたクラスとインタフェースのセットから構成されます。JDBC は、ツール/データベース開発者のための標準 API を提供し、Pure Java API を使用したデータベースアプリケーションの作成を可能にします。
JDBC を使用すると、SQL 文を実質的には任意のリレーショナルデータベースに送ることが容易になります。すなわち、JDBC API を使用すると、Sybase データベースにアクセスするためにプログラムを 1 つ作成し、Oracle データベースにアクセスするために別のプログラムを作成し、Informix データベースにアクセスするためにまた別のプログラムを作成するという必要がありません。JDBC API を使用してプログラムを 1 つ作成すれば、そのプログラムが SQL 文を適切なデータベースに送信することができます。その上、Java アプリケーション言語で書かれたアプリケーションを使用すると、異なるプラットフォームで実行する場合にも、異なるアプリケーションを作成する必要がありません。Java と JDBC を組み合わせることにより、プログラマはプログラムを 1 つ作成して、それをどこででも実行することができるようになります。
Java は強固で安全、使いやすく理解しやすい上に、ネットワーク上で自動的にダウンロードできる、データベースアプリケーションのための非常に優れた基盤言語です。必要なのは、Java アプリケーションが異なる多様なデータベースとやり取りするための方法です。JDBC は、これを行うための機構です。
JDBC は、Java の機能を拡張します。たとえば、Java や JDBC API では、リモートデータベースから取得した情報を使用するアプレットが入った Web ページを発行することができます。また、企業は JDBC を使用して、社員全員をイントラネット経由で 1 つ以上の内部データベースに接続することができます (Windows,、Macintosh、および UNIX マシンが混在している場合でも同様)。Java 言語を使用するプログラマが増加するにつれて、Java からデータベースに容易にアクセスする必要が増え続けています。
Java と JDBC を組み合わせると、情報の配布が容易かつ経済的になるので、MIS マネージャは Java と JDBC の組み合わせを好みます。企業は自社ですでにインストール済みのデータベースを引き続き使用しながら、異なるデータベース管理システムに格納されている場合でも、その情報に容易にアクセスすることができます。新規アプリケーションの開発時間も短縮されます。インストレーションとバージョン制御は大幅に簡素化されます。プログラマはアプリケーションを作成し、またはそれを 1 度更新してサーバに置くだけで、誰もが最新バージョンにアクセスできるようになります。また、情報サービスを販売する企業にとって、Java および JDBC は、外部のカスタマに最新情報を配布する、よりよい方法を提供します。
1.1.1 JDBC で何ができるか
簡単にいえば、JDBC によって以下の 3 つのことができるようになります。
# データベースとの接続の確立
# SQL 文の送信
# SQL 文実行結果の処理
以下のコードの一部分は、これらの 3 つのステップの簡単な例を示します。
Connection con = DriverManager.getConnection (
"jdbc:odbc:wombat", "login", "password");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery("SELECT a, b, c FROM Table1");
while (rs.next()) {
int x = rs.getInt("a");
String s = rs.getString("b");
float f = rs.getFloat("c");
}
1.1.2 JDBC は下位 API であり、上位 API の基礎である
JDBC は、「下位」インタフェース、すなわち SQL コマンドを直接起動する (または「呼び出す」) ために使用されるインタフェースです。これはこの能力において非常によく機能し、ほかのデータベース接続 API より使いやすいだけでなく、上位インタフェースおよびツールを作成するための基礎となるようにも設計されています。上位インタフェースとは、よりわかりやすくより便利な API を使用した「ユーザフレンドリ」なインタフェースのことで、その背後で JDBC のような下位インタフェースに翻訳されます。このガイドを書いている時点では、以下の 2 種類の上位 API が JDBC の上に開発中です。
1. Java 用埋め込み SQL。少なくとも 1 つのベンダーがこれを作成しようとしています。DBMS は、データベースに使用するために特に設計された言語である SQL を実装します。JDBC では、SQL 文が Java メソッドへの文字列として渡されることが必要です。埋め込み SQL プロセッサにより、プログラマはこの代わりに SQL 文を Java に直接混在させることができます。たとえば、Java 変数は SQL 文の中で使用して、SQL 値の受け渡しを行うことができます。すると、埋め込み SQL プリプロセッサは、この Java/SQL ミックスを JDBC 呼び出しを持つ Java に翻訳します。
2. リレーショナルデータベーステーブルの Java クラスへの直接マッピング。Java ソフトウェアなどがこれを実装する計画を発表しています。この「オブジェクト/リレーショナル」マッピングでは、テーブルの各行がそのクラスのインスタンスとなり、各カラムの値がそのインスタンスの属性に対応します。したがってプログラマは、Java オブジェクトを直接操作することができます。データをフェッチしたりストアしたりするのに必要な SQL 呼び出しは、「カバーの下」に自動的に生成されます。より精巧なマッピング、たとえば複数のテーブルの行が 1 つの Java クラスに組み合わされるというようなマッピングも提供されています。
JDBC への関心が高まるにつれて、プログラムの作成を容易にする JDBC ベースのツールに取り組む開発者も増えてきました。プログラマはまた、エンドユーザがデータベースに容易にアクセスできるアプリケーションも作成しています。たとえば、あるアプリケーションは、そこから選択できるデータベースタスクのメニューを表示するというようにです。タスクを選択すると、アプリケーションはプロンプトと選択したタスクを実行するために必要な情報を入力するブランクを表示します。要求された情報を入力すると、アプリケーションは自動的に必要な SQL コマンドを起動します。ユーザは、SQL 構文をほとんどまたはまったく知らなくても、このようなアプリケーションの助けによってデータベースタスクを実行することができます。
1.1.3 JDBC 対 ODBC およびほかの API
現時点では、Microsoft の ODBC (Open DataBase Connectivity) API が、リレーショナルデータベースにアクセスするためにもっとも広く使用されているプログラミングインタフェースでしょう。これは、ほとんどすべてのプラットフォームのほとんどすべてのデータベースに接続する能力を備えています。それでは、ODBC を Java から使用しないのはなぜでしょうか。
それは、ODBC を Java から使用することは可能ですが、このあとで説明するJDBC-ODBC ブリッジの形で JDBC の力を借りて行うのが最良の方法であるためです。そこで次に出てくる質問は、「なぜ JDBC が必要なのか?」です。この質問に対しては、以下のようにいくつかの答えがあります。
1. ODBC は C インタフェースを使用しているので、Java から直接使用するには適切ではありません。Java からネイティブ C コードへの呼び出しは、セキュリティ、実装、堅牢さ、およびアプリケーションの自動移植性の上で多くの欠点があります。
2. ODBC C API を Java API にリテラルに翻訳することは好ましくありません。たとえば、Java がポインタを持たない場合に ODBC がそれらを頻繁に使用すると、エラーを生じやすいことで悪名高い汎用ポインタ void * が取り込まれます。JDBC は、Java プログラマにとって自然なオブジェクト指向インタフェースに翻訳された ODBC と考えることができます。
3. ODBC は学習が困難です。これには簡単な機能と難解な機能が混在し、また簡単なクエリーにも複雑なオプションがあります。一方、JDBC は、簡単なことは簡単なままでありながら、必要な場合には高度な機能が使用できるように設計されています。
4. Java API は JDBC と同様、「Pure Java」ソリューションを可能にするために必要です。ODBC を使用すると、ODBC ドライバマネージャとドライバを、すべてのクライアントマシンに手動でインストールする必要があります。しかし、JDBC ドライバが完全に Java で書かれていると、JDBC コードは、ネットワークコンピュータからメインフレームに至るすべての Java プラットフォームへの自動インストールや移植が可能であり、安全です。
要約すると、JDBC API は基本的な SQL の概要と概念への自然な Java インタフェースです。これは、ゼロから作成されているのではなく ODBC の上に作成されているので、ODBC に慣れているプログラマは、JDBC を非常に学習しやすいと感じることでしょう。JDBC は ODBC の基本設計の特徴を残しており、実際、インタフェースはどれも X/Open SQL CLI (Call Level Interface) を基礎としています。大きな相違点は、JDBC が Java のスタイルと長所の上に構築され、それを強化している点と、使いやすい点です。
最近、Microsoft は、RDO、ADO、および OLE DB という、ODBC を超える新規の API を発表しました。これらの設計は、JDBC と多くの点において同じ方向、すなわち、ODBC 上に実装可能なクラスを基礎としたオブジェクト指向データベースインタフェースへと移行しています。しかし、特に ODBC 市場が成熟していることを考えると、これらのインタフェースのどれにも ODBC に代わる基礎となるような魅力的な機能は見られません。これらはほとんど ODBC の上に薄い化粧板を貼ったようなものです。しかし、これは JDBC が最初のリリースから発展する余地がないという意味ではありません。ほとんどの新機能は、前の項で述べたオブジェクト/リレーショナルマッピングおよび埋め込み SQL のような上位 API に属すると考えられます。
1.1.4 2 層モデルと 3 層モデル
JDBC API は、データベースアクセスの 2 層モデルと 3 層モデルの両方をサポートします。
2 層モデルでは、Java アプレットまたはアプリケーションはデータベースと直接やり取りします。これには、アクセスしている特定のデータベース管理システムとやり取りできる JDBC ドライバが必要です。ユーザの SQL 文はデータベースに配信され、それらの文の結果がユーザに送り返されます。データベースは、ユーザがネットワーク経由で接続されているほかのマシンに置くことも可能です。これは、クライアント/サーバ構成と呼ばれ、ユーザのマシンがクライアント、データベースを持つマシンがサーバと呼ばれます。ネットワークは、たとえば社内で社員同士をつなぐイントラネットでも、インターネットでもかまいません。
3 層モデルでは、コマンドがサービスの「中間層」に送信され、中間層が SQL 文を データベースに送信します。データベースは SQL 文を処理して結果を中間層に送り返し、中間層がそれをユーザに送ります。3 層モデルでは中間層が企業データに対して行えるアクセスおよび更新の種類について制御を維持することができるので、MIS の責任者はこのモデルを非常に魅力的だと考えています。そのほかの利点として、中間層があると、中間層によって適切な下位呼び出しに翻訳された使いやすい上位 API を利用することができます。最後に、多くの場合、3 層アーキテクチャの方がパフォーマンス上の利点があります。
現在までのところ、中間層は通常 C または C++ のような高速なパフォーマンスを提供する言語で作成されてきました。しかし、Java バイトコードを効率的なマシン固有コードに翻訳する最適化コンパイラが導入されて、Java で中間層を実装することが現実的になっています。これは大きな進歩で、Java の堅牢さ、マルチスレッド処理、およびセキュリティ機能を利用できるようになります。JDBC は、Java の中間層からのデータベースアクセスを可能にするのに重要です。
1.1.5 SQL の適合性
Structured Query Language (SQL) は、リレーショナルデータベースにアクセスするための標準言語です。困難な面は、1 つにはほとんどの DBMS (データベース管理システム) は、基本機能に標準形式の SQL を使用するにもかかわらず、高度機能のために最近定義された標準 SQL 構文やセマンティクスに適合していないことです。たとえば、すべてのデータベースがストアドプロシージャやアウタジョインをサポートしているわけではなく、またサポートしているもの同士に互いに一貫性がありません。SQL の本当に標準的な部分が、より多くの機能を持つように拡張することが望まれます。しかし、当分の間は、JDBC API が SQL をそのままサポートする必要があります。
JDBC API がこの問題に対処する 1 つの方法は、すべてのクエリー文字列を基盤の DBMS ドライバに渡せるようにすることです。すなわち、アプリケーションは、望む限りの SQL 機能を自由に使用することができますが、DBMS からエラーを受け取る危険があります。実際、アプリケーションのクエリーは SQL である必要すらなく、特定の DBMS のために設計された SQL の特別な形式 (たとえば、ドキュメントまたは画像クエリー) でもかまいません。
JDBC が SQL の適合性の問題に対処する 2 番目の方法は、「4.1.5 Statement オブジェクト内の SQL エスケープ構文」で説明する ODBC スタイルのエスケープ節を使用することです。
エスケープ構文は、標準の JDBC 構文に、より一般的に利用される SQL の拡張機能をいくつか提供します。たとえば、日付リテラルやストアドプロシージャ呼び出しのためのエスケープがあります。
複雑なアプリケーションでは、JDBC が 3 番目の方法で SQL の適合性に対処します。JDBC は、アプリケーションが各 DBMS の必要条件や機能に適合するように、DatabaseMetaData インタフェースを使用して、DBMS についての記述情報を提供します。
JDBC API は、上位データベースアクセスツールおよび API を開発するための基本 API として使用されるので、ここでもその上に構築されるものについての適合性の問題に対処する必要があります。ユーザが頼ることができる標準レベルの機能性を設定するために、JDBC COMPLIANTTM という指定が作成されました。この指定を使用するためには、ドライバが最低 ANSI SQL-2 エントリレベルをサポートする必要があります (ANSI SQL-2 は、1992 年に米国規格協会が採用した標準を指す)。ドライバ開発者は、JDBC API に付属のテストスイートを使用して、自分が開発したドライバがこの標準に適合することを確認できます。
JDBC COMPLIANTTM 指定は、ベンダーの JDBC 実装が Java ソフトウェアの提供する適合性テストに合格したことを示します。この適合性テストは、JDBC API に定義されたすべてのクラスとメソッドが存在することを確認し、および SQL エントリレベル機能が使用可能であることをできる限り確認します。このテストは完璧なものではなく、Java ソフトウェアは現在、ベンダーの実装を認定することはしていませんが、この適合性定義により、JDBC の実装にある程度の信頼が与えられます。JDBC API がデータベースベンダー、接続ベンダー、インターネットサービスベンダー、およびアプリケーション作成者にますます広く受け入れられるにつれて、JDBC は早くも Java データベースアクセスの標準となりつつあります。
1.2 JDBC 製品
このドキュメントが作成された時点では、いくつかの JDBC ベースの製品がすでに出荷済みまたは開発中です。この項の情報はすぐに時代遅れになるので、最新の情報については、JDBC の Web ページを参照してください。これは以下の URL から探すことができます。
http://java.sun.com/products/jdbc
1.2.1 Java ソフトウェアの構造
Java ソフトウェアは、Java Developer's Kit (JDK) の一部として、以下の 3 つの JDBC 製品構成要素を提供します。
* JDBC ドライバマネージャ
* JDBC ドライバテストスイート
JDBC ドライバマネージャは、JDBC アーキテクチャのバックボーンです。これは実際は非常に小さくて簡単です。その主な機能は、Java アプリケーションを正しい JDBC ドライバに接続し、またそれを取り除くことです。
JDBC ドライバテストスイートにより、JDBC ドライバがあるプログラムを実行することがある程度信頼できます。JDBC ドライバテストスイートに合格したドライバだけが、JDBC COMPLIANTTM として指定されます。
JDBC-ODBC ブリッジにより、ODBC ドライバを JDBC ドライバとして使用できます。これは、JDBC をすぐに使用できるようにするための方法として実装されます。将来的には、あまり一般的でない DBMS に JDBC ドライバが実装されていない場合、それらの DBMS のいくつかにアクセスする方法も提供する予定です。
1.2.2 JDBC ドライバのタイプ
現時点で認識している JDBC ドライバは、以下の 4 つのカテゴリのどれかにあたります。
1. JDBC-ODBC ブリッジと ODBC ドライバの組み合わせ: Java ソフトウェア ブリッジ製品は、ODBC ドライバ経由の JDBC アクセスを可能にします。ODBC バイナリコード、および多くの場合のデータベースクライアントコードは、このドライバを使用するクライアントマシンに置く必要があります。結果として、この種のドライバは、クライアントのインストールが大きな問題にはならない企業ネットワークや、Java で 3 層アーキテクチャに作成されたアプリケーションサーバコードに最適です。
2. 一部が Java ドライバであるネイティブ-API: この種のドライバは、JDBC 呼び出しを Oracle、Sybase、Informix、DB2、またはそのほかの DBMS のためのクライアント API での呼び出しに変化させます。このスタイルのドライバはブリッジドライバと同様、一部のバイナリコードを各クライアントマシンにロードする必要があります。
3. JDBC-ネット Pure Java ドライバ: このドライバは、JDBC 呼び出しを DBMS 独立のネットプロトコルに変換し、それがサーバによって DBMS に変換されます。このネットサーバミドルウェアは、その Pure Java クライアントを多くの異なるデータベースに接続することができます。使用されるこの特定のプロトコルはベンダーに依存します。一般的に、これはもっとも柔軟な JDBC の代替です。このソリューションのベンダーはすべて、イントラネットでの使用にあった製品を提供しようとしているようです。これらの製品がインターネットアクセスをもサポートするためには、Web が課するセキュリティやファイヤウォールを通じたアクセスなどの必要条件も処理する必要があります。ベンダーによっては、JDBC ドライバを自社の既存のデータベースミドルウェア製品に追加しようとしているところもあります。
4. ネイティブプロトコル Pure Java ドライバ: この種のドライバは、JDBC 呼び出しを DBMS が使用するネットワークプロトコルに直接変換します。これにより、クライアントマシンから DBMS サーバへの直接呼び出しが可能になるので、イントラネットアクセスのための実質的なソリューションといえます。これらの多くは固有のプロトコルなので、データベースベンダー自身がプライマリソースであり、複数のデータベースベンダーがこれらを開発中です。
結局、3 と 4 のカテゴリが JDBC からデータベースにアクセスする好ましい方法だと考えられます。カテゴリ 1 と 2 のドライバは、直接 Pure Java ドライバがまだ使用可能でない間の過渡的なソリューションです。カテゴリ 1 と 2 には (以下のテーブルには示していない) コネクタを必要とする種類のものが可能ですが、一般的には望ましいソリューションのレベルには到達していません。カテゴリ 3 と 4 が自動インストールを始めとし、Java のすべての利点を提供します (たとえば、JDBC ドライバを、それを使用するアプレットとともにダウンロードすること)。
以下の表に、4 つのカテゴリとそのプロパティを示します。
ドライバのカテゴリ すべて JAVA かどうか ネットプロトコル
1 - JDBC-OCBC ブリッジ いいえ 直接
2 - 基本的にネイティブ API いいえ 直接
3 - JDBC ネット はい コネクタが必要
4 - 基本的にネイティブプロトコル はい 直接
1.2.3 JDBC ドライバの入手
これを書いている時点では、Java ソフトウェアのブリッジとともに使用できるカテゴリ 1 のドライバが数多くあります。DBMS 用のネイティブ API の上に構築されているカテゴリ 2 のドライバは約 12 あります。カテゴリ 3 のドライバは少数です。現在、カテゴリ 4 のドライバは最低 2 つありますが、1997 年末には、主要な DBMS のすべてについてカテゴリ 4 のドライバが登場する予定です。
ドライバについての情報を取得するには、http://java.sun.com/products/jdbc の JDBC の Web ページを参照してください。カテゴリ 3 のドライバが用意できる最初のベンダーは、SCO、Open Horizon、Visigenic、および WebLogic です。Java ソフトウェアおよび主要なデータベース接続ベンダーである Intersolv は、協力して JDBC-ODBC ブリッジと JDBC ドライバテストスイートの開発にあたっています。
1.2.4 そのほかの製品
さまざまな JDBC アプリケーションの開発が進行中です。最新情報については、Java ソフトウェアのページを参照してください。
リテラル
リテラル
出典: フリー百科事典『ウィキペディア（Wikipedia）』
移動: ナビゲーション, 検索
リテラル（literal）とは、コンピュータプログラミングにおいて、ソースコード内に値を直接表記したものをいう。数値、文字列、関数などさまざまなデータ型のものが存在し、それぞれの表記方法も言語によって異なる。
リテラルを記述できることは、第一級オブジェクトを構成するための要件として見なされる場合もある。
テキストエディタには、リテラルとその他のコードを区別しやすいように、シンタックスハイライトを実装したものもある。
[編集] 例
下のコードで、7や"hello"がリテラルである。
int x = 7;
string s = "hello";
VAR在风险评估中的应用
VAR在风险评估中的应用
摘要 风险价值方法(Value-at-Risk)是近几年发展起来的用以测量和控制金融风险的量化模型。本文使用VaR模型测量了投资银行证券业务中的市场风险，应用上海证券交易所的实际数据，具体计算出VaR的时间序列，并论证了应用该时间序列来评估风险的大小的方法。最后分析了VaR方法的应用范围及在我国的应用前景。
投资银行是一种新型金融顾问产业，这些银行持有大量的诸如股票、债券、外汇、商业票据以及金融衍生工具等对市场风险非常敏感的资产，如何控制和管理这一系列市场风险就是摆在各家银行面前的一个重要的课题。一些主要的国际大银行早已开始研究、建立自己的内部风险测量、资本配置模型，以弥补巴塞尔协议之不足。风险评估的方法有定性评估和定量评估两种；定性评估是在风险识别的基础上进一步深化，定量评估是用数量指标来衡量风险。本文主要介绍一种风险评估方法――风险价值法VaR在投资银行市场风险评估领域的应用。
一、风险价值法的内涵及具体应用
风险价值的含义VaR，即Value-at-Risk(风险价值)，作为一种金融风险评估和计量模型，已经被全球各主要银行、非银行金融机构、公司和金融监管机构广泛采用。1996年巴塞尔委员会规定其成员银行和金融机构必须采用VaR技术针对交易书中的所有项目建立内部市场风险模型。
可以从经济学和数学两个不同学科领域定义风险价值VaR。从经济学角度的定义是在一定的持有期(holding horizon)和一定的置信度区间(confidence level)内，一个投资组合最大的潜在损失是多少，资产在正常的市场条件中的风险值。VaR要计算的实际上是正常情况下投资组合的预期价值与在一定置信水平下的最低价值之差。比如某投资组合的VaR为(＄100，95%)，表明这一投资组合有95%的可能性损失，金额不超过100，000；换句话说就是只有5%的可能性损失超过100，000。其中置信度的选择显得尤为重要，它反映了一家银行的风险战略和经营特点，例如大通银行采用97.5%的置信度，而花旗银行的置信度为95.4%，美洲银行与摩根则采用95%的置信度。
若从数学角度来定义VaR，可令W0为持有期初的价值，W为持有期末的价值，E(W)为期望价值，W为给定置信水平下的最低价值，则有
VaR ＝E(W)-W ()
因此，计算VaR等价于推算E(W)和W。例如，在证券市场上可用VaR时间序列来预测风险。VaR时间序列是将每日测算出的VaR值连结起来得到的一条曲线。每一个股(或投资组合)不同时间的VaR值的大小是不同的，VaR值由小变大，表明该股票(或投资组合)风险由小变大；反之表明该股票(或投资组合)风险逐渐由大变小。
投资银行的主要业务之一是证券业务，这使其不可避免地持有大量不同种类的股票。而相对于其他金融市场来说，股票市场更给人一种不稳定的印象。这就决定了投资银行在取得高收益的同时，必然会面临高风险(主要指市场风险)。本文在对模型适当简化的基础上，利用VaR法对股票投资中的市场风险进行定量的分析。
二、VaR计算方法
在实际的市场风险管理中，VaR主要有四种计算方法：方差―协方差法、历史数据模拟法、结构化蒙特卡罗法和压力测试。
1.方差-协方差法(Variance-Covariance)
该方法的核心是基于对资产报酬的方差-协方差矩阵进行估计，属于参数方法，其中最具有代表性的是J.P. Morgan釻s Risk Metrics方法，有两个重要假设：
假设1：线性假定，即给定持有期内资产价值的变化与其风险因素报酬成线性关系：
△ω＝Σδk△Sk／Sk
假设2：正态分布假设，即风险因素报酬Rs＝△Sk／Sk均服从正态分布，记为：R〜N(μ，Σ)，
假定投资组合的未来收益服从正态分布，其中Σ为N×Ｎ协方差矩阵。
在实际应用中经常假设μ＝0，这种方法目前已广泛应用，但其缺点是低估了金融风险VaR值。因为许多实证研究对零均值正态分布假设提出了挑战，研究结果表明：
(1)实际的收益率数据分布并不关于零点对称，而是经常向一侧偏斜，即偏斜度S≠0。
(2)实际的收益率分布尾部概率要比正态分布大，即“厚尾”现象(high Kurtosis)。
这就要求用另外的分布(如t分布)去逼近，或用HS或Monte Carlo模拟方法。
2.历史数据模拟法(Historical Simulation)
历史数据模拟法是根据历史数据摸拟未来的一种方法，它的假设是“历史将会重现”。由于它采用的是历史上真实发生的数据，而不是抽象数学分布作为分析基础，因此该方法较直观，计算结果的说服力也较强，更容易被银行所接受，所以大通银行、瑞士信贷银行等大银行更倾向于采用这种方法。但运用该方法，也就意味着收益分布在整个样本时限内是固定不变的，同时它也不能提供比所观察样本中最小收益还要坏的预期损失。
3.蒙太卡罗模拟法(Monte Carlo Simulation)
蒙太卡罗模拟法被认为是计算VaR的最佳方法。对于其他方法无法处理的风险和问题，如非线性价格风险、波动性风险、事件风险、模型风险、方差随时间变化、厚尾分布、极端场景甚至信用风险，它都能够有效地处理。但是，这一方法的最大缺点是计算量太大，因而造成系统成本太高。它的另一个缺点是，依赖于基础风险因素的随机模型以及证券的定价模型。如果这两类模型有缺陷的话，计算结果就会不准确。以上几种风险价值计算方法的共同缺点就是不能反映市场突发事件情况下的损失程度，如墨西哥比索危机、亚洲金融危机等。因此有必要采用一种方法作为VaR的补充，这就是压力测试法。
4.压力测试法
所谓压力测试，有时称为场景分析，考虑的是关键金融变量的大规模变化对投资组合价值的影响。它先主观地选定一些场景，例如，收益率曲线在1个月内向上移动100个基本点，或者货币在1天之内急剧贬值30%，然后利用新场景对投资组合中的所有资产重新进行定价，这样就可以得出该场景下投资组合的收益率。
三、举例
下面我们以历史数据模拟法为例来介绍VaR的具体计算方法。本例将以宝钢股份(600019)(2004年3月1日〜2004年4月30日)的数据，计算下一个交易日的VaR值。计算样本为2004年3月至4月的数据，在这个阶段我国出台了一系列关于证券市场的政策，特别是针对国内固定资产投资过热的政策，势必会对股市产生影响，所以我们选取具有一定代表性的宝钢股份。其具体计算过程如下(见表1)：
为了计算方便，假设投资银行2004年3月1日在7.30价位买入宝钢股份1股。
2004年从3月1日至4月30日，共用44个交易日，以此计算下一个交易日(5月10日)的VaR值。
1.计算每股的平均盈亏额
计算可得该44个交易日盈亏总额为-4.63元，每日平均盈亏为-4.63／44＝-0.11元，即E(W)＝-0.11元。
2.确定W的值
设置信水平C＝95%，则收益低于W的天数：44×（1-95%)＝2.20，取2天，查表1可得在5%概率下的W为-1.12元。
3.计算VaR
将EW和W的值代入式()，得VaR ＝-0.11-(-1.12)＝1.01元。
按以上方法逐日推算下一交易日得VaR值(如表2)。
从表中的数据可以看出宝钢股份(600019)的风险变化，从5月10日(第一交易日)至6月1日VaR值由大变小。
通过该实例可以得出以下结论：风险应与收益成正比，风险越大，收益越大，否则，应重新考虑投资决策的正确性。
四、风险价值法在我国投资银行和其他金融领域的应用前景
因为VaR主要用来衡量金融资产的市场风险，所以凡是握有存在市场风险的金融资产的机构都可以使用VaR进行风险管理。这些机构可以是投资银行、储蓄机构、投资基金等，也可以是在利率、汇率等方面面临市场风险的非金融机构。此外，金融监管部门出于维护金融市场稳定的需要，也可以利用VaR方法作为金融监管的工具。
1.VaR可用于风险控制
1993年，三十国集团发表的研究报告将VaR方法视为控制金融衍生工具的市场风险的最佳方法，并竭力向其成员银行推荐使用VaR方法。对投资银行来讲，利用VaR进行风险控制，可以使证券公司的每个交易部门或操盘手都能明确他们在进行有多大风险的金融交易，并可以为每个交易部门或操盘手设置VaR 限额，以防止过度投机行为的出现。如果执行严格的VaR管理，一些金融交易的重大亏损也许就可以完全避免。
2.VaR方法可用于业绩评估
在金融投资中，高收益总是伴随着高风险，交易员可能不惜冒巨大的风险去追逐巨额利润。公司出于稳健经营的需要，必须对交易员可能的过度投机行为进行限制。对一个交易员的业绩评价时不再仅仅根据其赢利的大小，而是根据收益与VaR的比率，银行家信托公司的业绩评价指标称为“经风险调整的资本” (Risk Adjusted Return On Capital，简称RAROC，RAROC＝收益率 VaR值)。这样有助于抑制交易员过度投机的内在冲动，使其在最小风险条件下为公司谋取最大的收益。
3.VaR方法可用于金融监管
这方面最典型的例子当数国际清算银行巴塞尔委员会关于资本充足率的规定。1995年4月，巴塞尔委员会公布的《有关在资本充足率协议中纳入市场风险因素的补充文件》中规定，从1997年年底开始，其成员银行在设置应付风险的资本金额时除考虑信用风险外，还要考虑市场风险。美国证券和交易委员会 (SEC)1995年12月规定，上市公司必须及时披露关于其金融衍生工具交易风险的量化信息，VaR方法是可以采用的三种方法之一。
我国对VaR的研究刚刚起步，近期，有关机构已成功研制开发出了一套适合中国资本市场的VaR风险管理模型――MuVaR系统。该系统以VaR技术为核心，为用户提供了从数据库管理、IT系统风险监控、风险分析到风险控制和评估机制的全面解决方案，它为探索VaR风险管理模型在中国新兴资本市场的引入和应用迈出了极有价值的一步。相信随着我国资本市场的进一步成熟开放和VaR技术的深入研究，VaR技术会在我国金融风险管理中发挥越来越大的作用。
参考文献
1 Morgan Guaranty Trust： Risk Metrics Technical Document；New York，Morgan Thrust Company Global Research， 1995.
2 William Fallon： Calculation Value-at-Risk Mimeo Columbia University，199.6
3 Basle Committee on Banking Supervision： Supplement to the Capital Accord to Incorporate Marker Risk，1996.
4 菲利普·乔瑞(美).《VaR：风险价值-金融风险管理新标准》.中信出版社，2000.
5 威廉·Ｆ·夏普等.《投资学》.中国人民大学出版社，1998.
6 吕江林.《投资银行风险预警机制初探》.《金融经济》，2000.
7 戴国强 徐龙炳 陆容.《VaR方法对我国风险管理的借鉴及应用》.金融研究，2000.
8黄海.《投资银行的风险管理和VaR技术的应用》.《财经研究》，1998，9.
9 王春峰 万海晖 张维.《金融市场风险测量模型―VaR 》.《系统工程学报》，2000，15
