資格を目指す計画的な勉強と習得した知識を活用する事例を紹介する

（某ＳＩ会社のＳＥ論文応募で優秀論文に選ばれた作品です。）

甘　大文

2008年12月6日

日本滞在中の１０年に渡って仕事に関わる資格を目指す計画的な勉強と習得した知識と技術を活用する事例を紹介し、知識を習得するノウハウと知識を活用するノウハウを社内に共有するとともに、会社に資格取得の奨励制度を提案します。資格を目指す計画的な勉強では、ＳＥとして常に仕事に関わる知識や技術を習得する重要性を強調しながら、著者の計画的な勉強を紹介します。取得済みの資格や目標となっていた資格を説明するとともに、若者のＳＥに推奨したい資格を紹介します。習得した知識と技術の活用とは、元々資格を取得するきっかけは仕事ですが、習得した知識と技術はまた仕事の場面で役に立つことです。活用する事例をすべて紹介するのは無理で、知識や技術を習得する重要性を強調するために、以下の代表的な事例を紹介します。

事例１．二分探索を考案する開発（情報処理試験）

事例２．ADOのオフライン機能を導入するSNMPツールの設計開発（MCSD試験）

事例３．SQL Serverのインデックス特徴を利用する性能改善（MCDBA試験）

事例４．ROWIDを利用するデータ移行（Oracle試験）

キーワード：資格、情報処理、MCSD、MCDBA、OCP、SJC-WC、二分探索、ADO、クライアントカーソル、クラスタ化インデックス、ROWID

目次

1.      仕事に関わる資格を目指す知識と技術を習得する

1.1.       資格を目指す知識と技術を習得する重要性

1.1.1.        ＳＥとして新しい知識と技術を習得する重要性

1.1.2.        知識と技術を習得する道筋

1.1.3.        受験のための勉強と受験のない勉強

1.1.4.        資格の取得とその他目標の勉強

1.2.       １０年に渡ってSE仕事に関する計画的な勉強

1.2.1.        SE仕事に関する勉強履歴の概要情報

1.2.2.        資格を目指す受験回数および自己投資の費用

1.2.3.        受験履歴情報と仕事に最も役に立つ受験勉強

1.2.4.        受験履歴のある各種資格の紹介

1.3.       推奨したい資格と資格取得支援制度の提案

1.3.1.        若者のＳＥに推奨したい資格

1.3.2.        資格取得の支援または資格保有の奨励に関する制度の提案

2.      習得した知識の活用事例を紹介する

2.1.       二分探索を考案する開発（情報処理試験）

2.1.1.        二分探索の論理知識

2.1.2.        検索エンジンを設計・開発する背景

2.1.3.        検索エンジンという発想

2.1.4.        検索エンジンの事例データ（薬剤相互作用）

2.1.5.        検索エンジンの設計開発と性能改善の効果

2.2.       ADOオフライン機能を導入するSNMPツールの設計開発（MCSD試験）

2.2.1.        ADOオフライン機能（非接続型データアクセス）の論理知識

2.2.2.        SNMPデータ収集ツールの開発要件とレスポンスの問題点

2.2.3.        レスポンス問題を対応する考案

2.2.4.        ADOオフライン機能の導入効果

2.3.       SQLServerのインデックス特徴を利用する性能改善（MCDBA試験）

2.3.1.        インデックス構成においてSQLServerとOracleの相違点

2.3.2.        クラスタ化インデックス（SQLServer）の設計が問題視された事例

2.3.3.        クラスタ化インデックス（SQLServer）の変更提案および性能効果

2.4.       ROWIDを利用するデータ移行（Oracle試験）

2.4.1.        OracleのROWIDを利用するデータ移行の背景

2.4.2.        Oracleのデータ移行手順とデータIDの振り直し

2.4.3.        データID振り直しSQL文とレスポンスの比較

本文

1.      仕事に関わる資格を目指す知識と技術を習得する

1.1.       資格を目指す知識と技術を習得する重要性

1.1.1.        ＳＥとして新しい知識と技術を習得する重要性

どの業界でもスキルの高い技術者の共通点は広く深い知識と技術をベースとする豊富な経験だと思いますが、表1に示すように他業界の技術職と比べてSI業界の技術職であるSEは新しい知識と技術を習得することがよりいっそう大切だと思われます。

1.1.2.        知識と技術を習得する道筋

知識と技術を習得する道筋は仕事での経験と自主的な勉強に分かれます。表2に示すように、スキルになるのはどの業界でも仕事での経験が不可欠ですが、知識と技術の系統性や将来性を図るため、自主的な勉強はとても大切だと思われます。

1.1.3.        受験のための勉強と受験のない勉強

自主的な勉強は受験のための勉強と受験のない勉強に分かれます。表3に示すように、受験のない勉強と比べて受験のための勉強は効果的だと思われます。

1.1.4.        資格の取得とその他目標の勉強

受験のための勉強には、資格の取得や社外研修コースへの参加などがありますが、表 3に示すように、やはり社会人として資格の取得は有効な勉強方法だと思われます。

1.2.       １０年に渡ってSE仕事に関する計画的な勉強

1.2.1.        SE仕事に関する勉強履歴の概要情報

資格の取得は有効な勉強方法ですが、資格の設定できない勉強もあります。表5に示すのは日本滞在中の１０年の勉強履歴の概要情報です。

1.2.2.        資格を目指す受験回数および自己投資の費用

資格を目指す受験は十分な勉強をしても合格できるとは限りません。表6に示すように、私は合計36回の受験で17回も失敗しました。また、資格を目指す受験は自己投資が必要であるため、表7に示すような相当な費用が掛かりました。

1.2.3.        受験履歴情報と仕事に最も役に立つ受験勉強

表8に示すのは日本滞在中の１０年の間の主な受験履歴情報ですが、何回も失敗しても諦めず再受験することがある一方、資格取得後長い歳月を経たため再受験することもあります。例えばMCPであるソリューション アーキテクチャの合格（03/02/08）は5回目の受験で、資格取得後再受験したのは3年ぶりの基本情報処理技術者（02/10/20）の受験と4年ぶりの日本語能力1級試験の受験（06/12/03）でした。

表9に示すのは仕事に最も役に立つ受験勉強です。表9では、試験に合格できても必ず役に立つとは限らない反面、試験に合格できなくても受験勉強が非常に役に立ったことを説明しています。例えば、情報処理試験のデータベースを今まで4回受験しても合格していませんが、受験勉強が仕事に非常に役に立っていると思います。

1.2.4.        受験履歴のある各種資格の紹介

情報処理試験とベンダー試験の相違点は表10に示し、データベース管理資格であるオラクル・マスタ（OCP）とMCDBAの相違点を表 11に示し、ソリューションデベロッパー資格であるSJC-WCとMCSDの相違点を表12に示します。

1.3.       推奨したい資格と資格取得支援制度の提案

1.3.1.        若者のＳＥに推奨したい資格

若者のＳＥに推奨したい資格は表13に示すように4種類に分かれますが、いずれも著者と関わっている分野なので、分野が違っているＳＥであれば、資格種類もまだたくさんあると思われます。

1.3.2.        資格取得の支援または資格保有の奨励に関する制度の提案

前の会社で、技術職は資格に関する報告が毎年少なくとも4回ありました。これは上半期と下半期の人事評価と、4月と１０月に行われる情報処理試験のタイミングに行われました。上長からの関係指示や連絡は厳しく行われましたが、個々の能力の開発や自己啓発に当たって勉強しなければならない雰囲気を強く感じていました。因みに資格取得支援または資格保有の奨励制度は我が社以外、今まで勤めた会社にはすべてありました。我が社は資格取得支援または資格保有の奨励制度がないようですので、この場で以下のように提案します。

１）．資格の取得費用を補助する

資格の取得は費用が必要ですので、全額または一部を補助することを提案します。具体的な実施方法はよく検討または議論すべきですが、以下は著者の考えです。

A）一時報奨金を支払えば、別途取得費用を補助しなくてもいいです。

B）内容と達成レベルを考慮し、対象となる資格と補助する金額を決定します。

２）．一時報奨金を支払う。

資格の取得は費用が必要ですので、全額または一部を補助することを提案します。具体的な実施方法はよく検討または議論すべきですが、以下は著者の考えです。

A）資格手当を毎月支払えば、一時報奨金を支払わなくてもいいです。

B）内容と達成レベルを考慮し、支払い対象となる資格と支払い金額を決定します。

３）．資格手当を毎月支払う。

資格手当を毎月支払うことを提案します。具体的な実施方法はよく検討または議論すべきですが、以下は著者の考えです。

A）内容と達成レベルを考慮し、対象となる資格と支払い金額を決定します。また、支払う基準の資格レベルが高すぎないように配慮します。資格手当の支給に該当する資格レベルが高くなりますと，資格手当を貰える技術者が少なくなります。資格保有の奨励制度の効果を十分発揮するのは全社において一定割合（例えば30％）以上の技術者が資格手当を貰えるレベルまで調整するべきです。

B）支払う期間を設定します。資格は時間が経つにつれて価値が下がっていきます。再受験で資格が更新されない限り、一定期間が経つと資格手当の支給を停止するまたは支給ランクを降格するべきです。技術者達は常に新しい業務知識と先進技術を習得する必要があるため、業務知識または技術分野の資格を常に更新する必要があります。

2.      習得した知識の活用事例を紹介する

2.1.       二分探索を考案する開発（情報処理試験）

2.1.1.        二分探索の論理知識

二分探索というデータ検索アルゴリズムは大学の授業でも言及されましたが、色々な検索アルゴリズムとの比較やプログラム実例までの訓練は情報処理試験（1999年の第2種情報処理試験）を目指す勉強でした。

二分探索は整列済のデータを二つに分けて、そのどちらに検索対象が含まれているか判断するという手順を再帰的に繰り返していく検索方法です。まず、データの配列を昇順または降順に並べ、その中央の要素が検索対象と等しいかどうかを調べます。等しければそれで検索は完了し、等しくなかった場合は中央と検索対象のどちらが大きいかを比べ、配列の前半分と後半分のどちらに検索対象が含まれているかを判断します。因みに線型探索もデータ検索のアルゴリズムの一つですが、リストや配列に入ったデータに対する検索を行うにあたって、先頭から順に比較を行い、それが見つかれば終了するとう検索方法です。

データ要素数の増加に伴って、二分探索は線形探索に比べ非常に高速に探索が行えるアルゴリズムとなります。表14はデータ要素数によって探索が終了するまで比較回数（平均）を示しています。

2.1.2.        検索エンジンを設計・開発する背景

図1に示すように、某社が販売する医科管理システムパッケージには処方支援というサブシステムが付属されています。処方支援APは相互作用チェックを行うために、医科管理システムと同じ保存先のDBサーバーの薬効情報にアクセスしています。

図1 医科管理システムの処方支援システムのイメージ（更改前）

図2に示すのは更改後の医科管理システムの処方支援システムのイメージですが、本来2.1.5検索エンジンの設計開発 に置くべきで、更改前後のイメージを比較するために図 1と同じ場所に移動しました。取りあえず図 2を無視してもいいです。

図2 医科管理システムの処方支援システムのイメージ（更改後）

図3は処方支援APの主な処理ステップと各ステップにおいてアクセス対象となる薬効情報の主なテーブルを示しています。

図3 薬効情報の主なテーブルと処方支援APの主な処理ステップ

2.1.3.        検索エンジンという発想

処方支援APは最悪の条件で２分以上がかかるため、1999年10月レスポンスを２秒以内に改善するユーザーの要望がありました。２分以上から２秒以内に改善する実現可能な方法を色々考案した結果、図 2に示すような検索エンジンという発想ができました。理由は以下のようであります。

①．検索対象となる薬効情報は月に1回しか更新しないため、更新に関するレスポンスを考慮する必要がありません。日常的な業務は単純な検索しか行わないため、薬効情報を複雑な管理機能を持つRDBMS（オラクル）から分離すれば、RDBMSのオーバーヘッドを削減でき、レスポンスの改善が期待できます。

②．検索対象となる薬効情報はすべてCSVファイルにダウンロードしても2MBに過ぎないため、2000年時点の普通マシンでも全情報をメモリに事前展開できます。メモリへのアクセスはハードディスクへのアクセスと比べて桁違いに速いため、メモリへの事前展開を実現すれば、レスポンスの改善がさらに期待できます。

③．検索対象となる薬効情報はオリジナルデータ情報とインデックス情報を分離し、インデックスの生成およびインデックスへの検索は二分探索を導入すれば、レスポンスの大幅改善を期待できます。

※元々は検索エンジンという言葉を使わず、薬剤相互作用チェックDLLという名前で定義しました。数年後著者はある勉強で検索エンジンという市販製品を理解した上、この薬剤相互作用チェックDLLに最も適切な名前が薬剤相互作用検索エンジンではないかと思いました。

2.1.4.        検索エンジンの事例データ（薬剤相互作用）

薬剤相互作用検索エンジンの開発に導入するのは二分化探索というアルゴリズムなので、二分化探索の論理に基づき検索対象となるデータを整列するプログラム（インデックスファイルの生成）とインデックスに対する検索プログラムが不可欠となります。

薬効情報においては相互作用Tableを含む１２個の類似テーブルがありますが、二分化探索という処理方法はまったく同じですので、後記は相互作用Tableを挙げて説明します。

まず、表15は相互作用Tableの主要項目の事例データですが、検索キーとなる項目（薬効ID1と薬効ID2）を整列しますと、表16に示すデータになります。また、整列の順番を示すために、IndexNoという項目（これは配列の添え字になります）を追加します。

表16に示す整列済（薬効ID1と薬効ID2の昇順）の相互作用Tableのデータに基づき、表 17に示すようにインデックス情報とコメント情報（他のテーブルであれば、インデックス情報と後続のテーブルに対する検索キー情報）を分離します。また、検索キーは複数（事例は薬効ID1と薬効ID2）があっても、桁を揃えて１つの検索キーに統合します。

因みに、表17に示す情報はインデックスファイル生成のプログラムに対してファイルに保存する前の情報で、検索プログラムに対してメモリに展開する情報です。

2.1.5.        検索エンジンの設計開発と性能改善の効果

2.1.4 検索エンジンの事例データの説明とおり、図 4に示すようにデータファイルの生成プログラムと薬剤相互作用チェックDLLを設計して開発します。データファイルは開発言語のVB6で生成し、暗号化した上で圧縮し、保存します。薬剤相互作用チェックDLLの開発言語はVC6で、ファイルのオープンはデータファイルの生成と同一ロジックで解凍した上で復号化します。

図4 検索エンジンのファイル生成機能（AP）と薬剤相互作用チェックDLL

最悪要件での計測結果は0.07秒で、要望レスポンス（２秒以内）の30分の１を実現しました。薬剤相互作用チェックDLL（開発言語はVC）が当初対応できる言語はVB、DelphiとVCでしたが、1年後Java版の移植開発も依頼され、数多くの医療メーカーに販売されました。該当検索エンジンは2年後、某社の特許として認定されました。

2.2.       ADOオフライン機能を導入するSNMPツールの設計開発（MCSD試験）

2.2.1.        ADOオフライン機能（非接続型データアクセス）の論理知識

該当仕事をする前はADOの経験もありましたが、ADOの全面的な知識の習得は2002年MCSDを目指す計画的な勉強でした。MCSDの取得ではかなり幅広い知識を勉強してきたため、多方面の仕事に役に立ちましたが、ここではその一つを例として挙げます。

図5に示すのはごく普通のADOのオンライン（サーバーカーソル）機能とオフライン（クライアントカーソル）機能です。オフライン機能の特徴はデータベースから対象となるデータ（テーブルの全件または一部）をクライアントカーソルとして取得してからDB接続を切断します。その後はクライアントカーソルに対してデータのアクセス（検索および追加と更新）を行いますので、データベースサーバーとの通信が発生しないため、オンライン機能より速くなります。また、クライアントカーソルのデータ変更（追加または更新）がある場合、変更されたデータをオリジナルデータに反映する必要がありますが、クライアントの都合（ある変更回数に達する時やアプリケーションの終了時）でもう１回DB接続を行って変更されたデータをデータベースサーバーに送信します。オフライン機能を利用する注意点は以下です。

1）．メモリ領域や通信量の制限でクライアントカーソルが大きくなってはいけません。

2）．排他制御がないため、クライアントカーソルに変更されたデータは他のユーザーにより変更された場合、オリジナルデータに反映できません。

図5 ADOのオンライン（サーバーカーソル）機能とオフライン（クライアントカーソル）機能

2.2.2.        SNMPデータ収集ツールの開発要件とレスポンスの問題点

SNMPはIP ネットワーク上のネットワーク機器を監視（モニタリング）・制御するための情報の通信方法を定めるプロトコルです。SNMP データ収集は巨大なネットワーク上で、数多くの機器の状態を把握するためには、SNMPを使い機器からの情報を集めることです。

事例であるSNMPデータ収集ツールの設計開発はデータ収集部分とデータベース保存部分に分かれます。テーブル「SNMPデータ収集」レコード情報は表18に示していますが、列「相対数」以外の情報は計算する必要がなく、既存データベースにアクセスする必要がありません。SNMPデータ収集の要件は以下です。

1）．1回のSNMPデータ収集は2時間前後；

2）．同一オブジェクト(IP&OID)においてデータ収集の間隔が5秒（約1440回）；

3）．対象となるオブジェクト(IP&OID)の数は最大5000個；

4）．1回のSNMPデータ収集は約720万件。

SNMPデータ収集の要件と表18に示すテーブル「SNMPデータ収集」レコード情報を分析しますと、事前にレスポンスの問題点を想像できます。これは列「相対数」の情報を求めるのに既存データベースへとの通信が必要となり、最大720万件データの中でIPとOIDで絞ってから最も直近収集時刻の列「絶対数」と「時刻」を求める必要となります。以下は少々詳細的に説明します。

前回の絶対数と前回の時刻(同一IPと同一OID)を取得するのがレコードの増加に伴って徐々に遅くなることで、列「相対数」の情報を求めるのがボトルネックになってしまうというレスポンスの問題を想像しました。

2.2.3.        レスポンス問題を対応する考案

①.ADOのオフライン機能を導入する事前準備

2.2.1 ADOオフライン機能（非接続型データアクセス）で言及したオフライン機能を利用するために、まず表19に示すようにSNMPデータ収集のスナップショットデータを保存するテーブル「スナップショットデータ」を追加しました。

このテーブルは最新収集時刻のSNMPデータのみ保存するため、レコードの最大件数は5000件（テーブル「SNMPデータ収集」の最大件数の1440分の１）に過ぎません。検索の効率を考慮し、スナップショットデータというテーブルの設計に以下の工夫をしました。

・A）テーブル「SNMPデータ収集」のPKであるIPとOIDを連結して単一のPKにします；

・B）最新収集時刻のレコードのみ残すため、収集時刻からPKを外します；

・C）必須である最低限の列（絶対数と相対数）のみ残します。

②.スナップショットデータへのアクセスはADOのオフライン機能を導入する

図 6に示すように、テーブル「SNMP収集データ｣へのアクセスがADOのオンライン機能で、テーブル「スナップショットデータ｣へのアクセスがオフラインで行うように設計し、直近収集時刻の絶対数と収集時刻を取得する対象をテーブル「SNMP収集データ｣ではなく、テーブル「スナップショットデータ｣に設計しました。

テーブル「SNMPデータ収集」へのアクセスはレコードの追加だけなので、普通のオンライン機能（サーバーかソール）を利用するのはレスポンスの問題がありません。テーブル「スナップショットデータ」へのアクセスはレコードの検索、追加と更新がありますが、検索と更新のレスポンスを改善するために、ADOのオフライン機能を利用します。既に「①. ADOのオフライン機能を導入する事前準備」で説明しましたが、テーブル「スナップショットデータ」が軽量化になっています。また、２つ以上のユーザーがデータベースに同時にアクセスすることがありませんので、ADOのオフライン機能を利用するのは問題がありません。利用する詳細仕様は以下です。

テーブル「スナップショットデータ」への初回アクセスは、全件のテーブルデータをクライアントカーソルとして取得してからDBとの接続を切断します。初回以降のテーブル「スナップショットデータ」に対するデータの取得や更新はクライアントカーソルに対して行ないますが、アプリケーションの実行が終了する時、クライアントカーソルの変更情報をデータベースサーバーに送信してオリジナルのスナップショットデータを更新します。

図6 SNMP収集データはオンライン、スナップショットデータはオフラインでアクセス

2.2.4.        ADOオフライン機能の導入効果

性能テスト結果、単位時間で当時性能の最もいい類似ツールの２倍の収集量を実現しました。ユーザーに非常に満足したと言われました。

2.3.       SQLServerのインデックス特徴を利用する性能改善（MCDBA試験）

2.3.1.        インデックス構成においてSQLServerとOracleの相違点

データベースの資格であるMCDBAやオラクル・マスタを取得する前に、SQL ServerとOracleを数多くの案件で経験しましたが、SQL ServerとOracleに関する体系的な知識の習得はMCDBAとオラクル・マスタを目指す計画的な勉強でした。

SQL ServerでもOracleでも資格を目指す勉強で習得した知識はデータベースと関わる仕事にとても役に立ちました。この節ではインデックスの構成においてSQL　ServerとOracleの相違を紹介し、後節および後章に続きその特徴を活用する事例を紹介します。

図7 SQL Serverのクラスタ化と非クラスタインデックス

図8 Oracleの識別子（ROWID）とインデックス

図7に示すのはSQL　Serverのインデックスの構成です。クラスタ化インデックスというインデックスがありますが、オリジナルテールと同じ領域で1テーブルに付き1個しか作成できません。クラスタ化インデックスを指定する検索はオリジナルテーブルに直接なアクセスになりますが、非クラスタ化インデックスを指定する検索は必ずクラスタ化インデックスを経由します。クラスタ化インデックスはオリジナルテールと同じ領域であるため、検索用SQLの実行計画はクラスタ化インデックスが効いてもテーブルスキャンに見えます。また、主キーのインデックスはクラスタ化インデックスのデフォルトです。

図8に示すのはOracleのインデックスの構成です。OracleはSQL　Serverのようなクラスタ化インデックスがありませんが、SQL　Serverにない識別子（ROWID）があります。識別子（ROWID）を指定する検索はオリジナルテーブルに直接なアクセスになりますが、主キーを含むすべてのインデックスを指定する検索は必ず識別子（ROWID）を経由します。

インデックス構成においてSQL ServerとOracleの主な相違点は表20に示されます。

2.3.2.        クラスタ化インデックス（SQLServer）の設計が問題視された事例

クラスタ化インデックスの設計が問題となる事例は某ERP案件のデータベース性能改善の仕事です。表21に示すのはインデックスの設計が問題となるテーブルおよびインデックスの項目詳細ですが、図 9に示すのは問題となるテーブルにおいて全インデックスの検索ルートです。

図9 問題となるテーブルにおいて全インデックスの検索ルート

表21に示すように問題となるテーブルのクラスタ化インデックスは合計10項目があり、単純的な項目のサイズ合計が148バイトに達します。実装されているSQLを調査しますと、非クラスタ化インデックスであるI1～I5がよく使われていますが、クラスタ化インデックスが1回も使われていません。そのため、図 9に示すように問題となるのは非クラスタインデックスであるI1～I5は項目数も少なく、単純的な合計サイズも小さいですが、テーブルへのアクセスは合計10項目を持つクラスタ化インデックスを経由しなければなりません。

2.3.3.        クラスタ化インデックス（SQLServer）の変更提案および性能効果

2.3.2クラスタ化インデックス（SQL Server）の設計が問題視された事例について、合計10項目を持つPKはクラスタ化インデックスになっていることが問題であるため、表22のように項目C0を追加し、図 10に示すようにPKからクラスタ化インデックスを分離すれば、問題を解決できると思われます。

図10 変更後の全インデックスの検索ルート

インデックスが多いテーブルはクラスタ化インデックスを以下の優先順位で選定します。

・A）既存の項目が少なくサイズが小さい一意インデックスをクラスタ化にします。

・B）予想で使用する頻度の高い一意インデックスをクラスタ化にします。

・C）IDENTITY列を追加してクラスタ化インデックスにします。

変更後性能測定結果は該当テーブルへのアクセスはトータル的にアクセス時間が変更前の44%になりました。テーブルおよびインデックスの保存領域の増加は約5%でした。

2.4.       ROWIDを利用するデータ移行（Oracle試験）

2.4.1.        OracleのROWIDを利用するデータ移行の背景

OracleのROWIDおよびインデックスは既に2.3.1インデックス構成においてSQL ServerとOracleの相違点で紹介しましたので、この節ではOracleのインデックスとROWIDの説明を省略します。

今までOracleデータ移行の仕事にインデックスの代わりにROWIDを利用する経験は何回かありましたが、ここではその一つを例として挙げて、インデックスを利用する場合とROWIDを利用する場合のレスポンス性能差を説明します。

表23に示すのは文書管理データを保存するテーブルの項目定義ですが、実データは表24～表26に示すように5つのテーブル（データ3とデータ5は省略）に保存され、さらにPKであるデータIDの値は5つのテーブルでも1から起算され、重複されています。5つのテーブルも一意なインデックスIndex1がありますが、Index1の項目であるタイトル（DOCTITLE）がそのテーブルに限らず、5つのテーブルにまたがって一意になっています。今回紹介する仕事は文書管理データのテーブル定義を変更せず、図 11に示すように5つのテーブルのデータを１つのテーブルに移行し、データIDの値をタイトル（DOCTITLE）の昇順で１から振り直します。

図11 文書データのマージ処理図

2.4.2.        Oracleのデータ移行手順とデータIDの振り直し

2.4.1 OracleのROWIDを利用するデータ移行の背景に続き、図 12に示しますようにデータ移行の手順とデータIDの振り直しを説明します。

図12 データ移行の手順とデータIDの振り直し

図13 データID振り直しの案１と案２の比較

約６０万件のレコードに対してデータIDの振り直しを行う場合、ROWIDもインデックスも使用しなければ、約1800億（文書データの６０万件 X １時テーブルへの平均検索回数３０万回 ）回の検索が必要となるため、相当な時間がかかると想定できます。確かに、データIDの振り直しはROWIDもインデックスも使用しないことを考えていなかったです。図 13に示しますように、案１のキー項目はROWID型で文書データのROWIDの値を保持し、案２のキー項目は文書データのDOCTITLEと同じデータ型で、DOCTITLEの値を保持します。案１の場合、Index１を経由せず直接文書データのROWIDを参照して振りなおされたデータIDで更新を行いますが、案２の場合、Index１を経由してから文書データのROWIDを参照して振りなおされたデータIDで更新を行います。

2.4.3.        データID振り直しSQL文とレスポンスの比較

ROWID（案１）とインデックス（案２）を使用するSQL文は図 14に示します。

図14 データID振り直しの案１と案２のSQL比較

レスポンスの測定結果：案１は15分で、案２は185分でした。

※．上記同じデータでROWIDもインデックスも使用しない案を確認しようとしましたが、10時間でも終わらないので、諦めて強制終了しました。