(57)【要約】【課題】データベースのレプリケート前後に係る特定文字の取り扱いが異なることに起因するデータ不整合を抑制する。【解決手段】本発明に係るレプリケーションプログラムは、レプリケート元データベースにおけるゼロバイト長文字列およびｎｕｌｌ値を、レプリケート先データベースにおけるこれら文字列の取り扱いに応じて変換する。【選択図】図１
2017027349.tif 000002
【特許請求の範囲】
【請求項１】
第１データベースが保持しているレコードを、前記第１データベースとは異なるデータベース管理システムを用いて実装された第２データベースが保持するレコードとして複製する処理を、コンピュータに実行させるレプリケーションプログラムであって、前記コンピュータに、
前記第１データベースを更新する第１命令の実行履歴を記述した履歴データを取得するステップ、
前記第２データベース上におけるゼロバイト長文字列の書式および前記第２データベース上におけるｎｕｌｌ値の書式を定義する変換テーブルを読み取るステップ、
前記第１命令と同じレコード操作を実施する処理を前記第２データベースに対して実行する第２命令を生成するステップ、
前記第２命令のうちゼロバイト長文字列を用いる部分を前記変換テーブルの定義にしたがって前記第２データベース上における書式に変換するとともに、前記第２命令のうちｎｕｌｌ値を用いる部分を前記変換テーブルの定義にしたがって前記第２データベース上における書式に変換する、変換ステップ、
前記変換ステップによって変換した前記第２命令を実行することにより前記第２データベースを更新するステップ、
を実行させることを特徴とするレプリケーションプログラム。
【請求項２】
前記第１データベースおよび前記第２データベースは、リレーショナル形式のデータベースであり、
前記変換テーブルは、前記第１データベースが有するテーブルのカラムごとに前記ゼロバイト長文字列の書式および前記ｎｕｌｌ値の書式を定義しており、
前記変換ステップにおいては、前記コンピュータに、
前記変換テーブルの定義にしたがって、前記第２命令のうち前記第１データベースが有するテーブルのカラムに対応する部分毎に、前記変換を実施させる
ことを特徴とする請求項１記載のレプリケーションプログラム。
【請求項３】
前記レプリケーションプログラムはさらに、前記コンピュータに、
前記第２命令の文字コードを、前記第１データベースが使用する文字コードから前記第２データベースが使用する文字コードへ変換するステップを実行させる
ことを特徴とする請求項１記載のレプリケーションプログラム。
【請求項４】
前記変換テーブルは、前記第１データベース上におけるゼロバイト長文字列を前記第２データベース上における１バイト長以上の代替文字列に変換するよう指定する変換ルールを定義しており、
前記レプリケーションプログラムは、前記変換ステップにおいて前記コンピュータに、前記変換ルールの定義にしたがって、前記第２命令のうちゼロバイト長文字列を用いる部分を前記代替文字列に変換させる
ことを特徴とする請求項１記載のレプリケーションプログラム。
【請求項５】
前記変換テーブルは、前記第１データベース上における前記代替文字列を前記第２データベース上におけるゼロバイト長文字列に変換するよう指定する変換ルールを定義しており、
前記レプリケーションプログラムは、前記変換ステップにおいて前記コンピュータに、前記変換ルールの定義にしたがって、前記第２命令のうち前記代替文字列を用いる部分をゼロバイト長文字列に変換させる
ことを特徴とする請求項４記載のレプリケーションプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースのレプリケーションに関する。
【背景技術】
【０００２】
データベースのレプリケーションは、あるデータベースと全く同じ内容の複製データベースを作成する処理であり、いわゆるバックアップとは区別される。レプリケーションを利用することにより、例えばマスタデータベースの内容をスレーブデータベースに反映することができる。この手法はデータベースを冗長構成にするとき用いられる。
【０００３】
レプリケーションを実施する毎にデータベースの全内容を複製すると、処理負荷や通信負荷の観点から多大なリソースが必要となる。そこで現実的な手法として、マスタデータベースに対する更新部分のみを抽出してこれをスレーブデータベースに反映することが考えられる。
【０００４】
下記特許文献１は、データベースシステムのレプリケーションに関する技術を記載している。同文献においては、トランザクションレプリケーションのためのデータ変更を追跡するアルゴリズムとして、ログベースのものとトリガベースのものが例示されている（同文献の０００７〜０００８参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３０１３２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
データベースレプリケーションは、異なる機種のホストコンピュータ間で実施される場合がある。ホストコンピュータの機種によっては、データベース内で使用する特定文字の取り扱い方が異なる場合がある。さらには同機種のホストコンピュータであっても、データベース管理システム（ＤＢＭＳ）によって特定文字の取り扱い方が異なる場合もあり得る。レプリケート先データベースにおいて特定文字が正しく取り扱われなかった場合、レコードの内容が正しく認識されず、したがってレプリケート前後に係る整合性がとれなくなる可能性がある。
【０００７】
上記特許文献１記載の技術においては、トランザクションの整合性をレプリケート後においても維持することに着目しており、異機種間（または異なるＤＢＭＳ間）でデータベースをレプリケートすることに起因する問題については考慮されていない。しかし実際の運用場面においては、例えばオープンプラットフォーム（Ｗｉｎｄｏｗｓ（登録商標）など）上のＤＢＭＳから汎用機上のＤＢＭＳへレプリケーションを実施する場合があり、したがってレプリケート前後それぞれのプラットフォームにおける特定文字の取り扱いが異なる可能性がある。かかる場合においてもデータベースの整合性を維持することのできる技術が求められる。
【０００８】
本発明は、上記のような課題に鑑みてなされたものであり、データベースのレプリケート前後に係る特定文字の取り扱いが異なることに起因するデータ不整合を抑制することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係るレプリケーションプログラムは、レプリケート元データベースにおけるゼロバイト長文字列およびｎｕｌｌ値を、レプリケート先データベースにおけるこれら文字列の取り扱いに応じて変換する。
【発明の効果】
【００１０】
本発明に係るレプリケーションプログラムによれば、データベース管理システム毎のゼロバイト長文字列およびｎｕｌｌ値の取り扱いの違いを吸収してレプリケーションを正しく実行することができる。
【図面の簡単な説明】
【００１１】
【図１】実施形態１に係るレプリケーションプログラム１２０を実行するレプリケーションコンピュータ１００およびその周辺構成を示す図である。
【図２】変換テーブル１４０の構成とデータ例を示す図である。
【図３】履歴テーブル２３０の構成とデータ例を示す図である。
【図４】レプリケーションプログラム１２０の動作を説明する図である。
【図５】実施形態２における変換テーブル１４０の構成とデータ例を示す図である。
【図６】実施形態３における変換テーブル１４０の構成とデータ例を示す図である。
【発明を実施するための形態】
【００１２】
＜実施の形態１＞
図１は、本発明の実施形態１に係るレプリケーションプログラム１２０を実行するレプリケーションコンピュータ１００およびその周辺構成を示す図である。レプリケーションコンピュータ１００は、第１ＤＢ（ＤａｔａＢａｓｅ）２２０を第２ＤＢ３２０へレプリケートするコンピュータであり、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）１１０、レプリケーションプログラム１２０、記憶装置１３０を備える。
【００１３】
ＣＰＵ１１０は、レプリケーションプログラム１２０を実行する。レプリケーションプログラム１２０は、データベースをレプリケートする処理を実装したプログラムである。以下では記載の便宜上、レプリケーションプログラム１２０を動作主体として説明する場合があるが、実際にこれを実行するのはＣＰＵ１１０であることを付言しておく。
【００１４】
記憶装置１３０は、変換テーブル１４０を格納している。変換テーブル１４０は、レプリケーションプログラム１２０がレプリケーションを実施する際に、レプリケート元データベース上における特定文字をレプリケート先データベース上における書式に変換するルールを定義している。変換テーブル１４０の具体例については後述する。
【００１５】
第１ＤＢコンピュータ２１０は、第１ＤＢ２２０を実装した第１データベース管理システム（図示せず）を実行するコンピュータである。第１ＤＢコンピュータ２１０は、第１ＤＢ２２０に対する更新操作を履歴テーブル２３０に格納する。履歴テーブル２３０の具体例については後述する。第１ＤＢコンピュータ２１０はさらに、更新操作を履歴テーブル２３０へ格納する際に、採番データ２４０を用いる。採番データ２４０については後述する。
【００１６】
第２ＤＢコンピュータ３１０は、第１データベース管理システムとは異なる第２データベース管理システムを実行するコンピュータである。第２データベース管理システムは、第２ＤＢ３２０を実装している。
【００１７】
＜実施の形態１：データベース管理システムについて＞
データベース管理システムについて以下に補足する。データベースは単なるデータファイルの集合体ではなく、例えば（ａ）トランザクションを受け付けて実行する、（ｂ）トランザクションのログを記録する、（ｃ）所定のイベントが発生するとあらかじめ定めておいた処理を実行する（トリガ機能）、などの機能を有する。これら機能を実装したプログラムのことを一般にデータベース管理システムと呼ぶ。これら機能をどのように実装するかは個々のデータベース管理システムに依拠する。したがってデータベース管理システム毎に機能仕様が異なる場合がある。
【００１８】
データベースが保持するレコードは、それぞれデータ型を有している。例えば文字列レコードを保持するレコードまたはカラムは固定長文字列型／可変長文字列型などの文字列型を有し、数値レコードを保持するレコードまたはカラムは整数型／浮動小数点型などの数値型を有する。
【００１９】
データベース管理システムによっては、データ型の取り扱い方が異なる場合がある。例えば可変長文字列型のカラムにゼロバイト長文字列“”を格納した場合、あるデータベース管理システムにおいてはこれをその定義通りゼロバイト長文字列“”として格納するのに対し、別のデータベース管理システムにおいてはこれをｎｕｌｌ値（データなしを示す特殊なビット値）として格納することが、実際に発生している。
【００２０】
一般にゼロバイト長文字列とｎｕｌｌ値は、アプリケーション上における取り扱いが全く異なる。例えばゼロバイト長文字列は文字列として取り扱われるのに対し、ｎｕｌｌ値は無効なデータ値として取り扱われる場合がある。そうすると、例えば第１ＤＢ２２０が格納しているレコードおよびそのレコードを読み書きするアプリケーションを第２ＤＢコンピュータ３１０へ移行（第１ＤＢ２２０については第２ＤＢ３２０へレプリケート）した場合、アプリケーションが正しく動作しない可能性がある。例えば当該アプリケーションが第１ＤＢ２２０上のゼロバイト長文字列を文字列変数として処理していた場合、当該アプリケーションは第２ＤＢ３２０上の同じレコードを文字列として処理することができない可能性がある。具体的には、ゼロバイト長文字列に対して文字列を追加する処理が、無効なデータ値に対する処理として正常に動作しない可能性がある。
【００２１】
そこで本発明においては、異なるデータベース管理システム間のレプリケーションにともなう上記のような不具合を解消するため、取り扱い方がデータベース管理システム間で異なるデータについてかかる不具合が生じないような処理を施すこととした。
【００２２】
＜実施の形態１：テーブル構成＞
図２は、変換テーブル１４０の構成とデータ例を示す図である。変換テーブル１４０はレプリケート前後におけるデータ変換ルールを定義するデータテーブルである。変換テーブル１４０は、テーブル名フィールド１４１、カラム名フィールド１４２、ゼロバイト長文字列変換ルールフィールド１４３、ｎｕｌｌ値変換ルールフィールド１４４を有する。
【００２３】
テーブル名フィールド１４１とカラム名フィールド１４２は、レプリケート元データベースのテーブル名とカラム名を一意に識別する文字列である。レプリケート元データベースが複数のデータベースを構築している場合は、さらにデータベース名を指定することもできる。ゼロバイト長文字列変換ルールフィールド１４３は、レプリケート元データベース上においてゼロバイト長文字列のカラム値が格納されている場合、その値をレプリケート先データベースにおいてどのような値として格納するかを指定する書式を示す。ｎｕｌｌ値変換ルールフィールド１４４は、レプリケート元データベース上においてｎｕｌｌ値のカラム値が格納されている場合、その値をレプリケート先データベースにおいてどのような値として格納するかを指定する書式を示す。
【００２４】
図２に示す１行目のデータ例においては、レプリケート元データベースの“ｔａｂｌｅ１”テーブルの“ｃｏｌｕｍｎ１”カラムがゼロバイト長文字列を格納している場合、レプリケート先においてはこれをスペース文字に置き換えるべき旨を定義している。同様に同カラムがｎｕｌｌ値を格納している場合、レプリケート先においてもこれをｎｕｌｌ値として格納すべき旨を定義している。変換ルールが定義されていないカラムについては格別変換を実施せずそのままレプリケートすればよい。
【００２５】
図３は、履歴テーブル２３０の構成とデータ例を示す図である。履歴テーブル２３０は、第１ＤＢ２２０に対する更新操作を記録するデータテーブルである。履歴テーブル２３０は、順序フィールド２３１、状態フィールド２３２、命令文フィールド２３３を有する。
【００２６】
順序フィールド２３１は、第１ＤＢ２２０に対して更新処理が実施された通番を保持する。状態フィールド２３２は、当該レコードを第２ＤＢ３２０に対して反映済みか否かを示す。命令文フィールド２３３は、レプリケート元データベースに対して実施された更新操作の命令文を示す。ここでいう更新操作は、例えばＳＱＬにおけるＵＰＤＡＴＥ命令に限られず、ＩＮＳＥＲＴ命令やＤＥＬＥＴＥ命令を含む、データベースに対する全ての書き込み操作を含むものである。
【００２７】
履歴テーブル２３０はさらに、記録した更新操作における各カラムに対する指定値を保持するためのフィールドを有する。例えばＩＮＳＥＲＴ命令であれば各カラムに対して格納した値を保持するためのフィールドを有し、ＤＥＬＥＴＥ命令であれば削除するレコードを特定するための条件文におけるカラム値を保持するためのフィールドを有する。各テーブルが有するフィールドはテーブル毎に異なるので、レプリケート元データベースが有するテーブル毎に履歴テーブル２３０を設ける。例えば第１ＤＢ２２０のあるテーブルが２つのカラムを有する場合、図３に示すようにその２つのカラムに対する操作を記録するフィールドを設けることができる。
【００２８】
データベースに対する更新操作は、複数のテーブルにまたがって実施される場合がしばしばある。またあるテーブルに対する更新操作は別のテーブルのレコードを参照しながら実施される場合がある。テーブル間の整合性を維持しつつこれら複数のテーブルにまたがって更新操作を実施するためには、更新操作を実施する順序が重要になる。そこで本実施形態１においては、レプリケート元データベース（ここでは第１ＤＢ２２０）に対して更新操作を実施した順序を、順序フィールド２３１に記録することとした。
【００２９】
レプリケート元データベースに対する更新操作が発生したことを検出する手段としては例えば更新操作を契機として起動されるトリガをレプリケート元データベースにおいて実装しておけばよい。多くのデータベース管理システムはトリガ機構を備えているので、これを実装するのは容易である。
【００３０】
採番データ２４０は、順序フィールド２３１の現在値を保持する。各トリガの開始部分において採番データ２４０を参照して現在値を取得し、更新操作を履歴テーブル２３０に対して記録した後に採番データ２４０の現在値を１つインクリメントすることにより、各更新操作の実施順序を記録することができる。また複数のテーブルにまたがった更新操作であっても、各更新操作を記録する際に参照する現在値を採番データ２４０に集約することにより、テーブルをまたがる更新処理を実施すべき順序を保存してレプリケート後においても整合性を維持することができる。
【００３１】
図４は、レプリケーションプログラム１２０の動作を説明する図である。以下図４の各ステップについて説明する。
【００３２】
（図４：ステップ（１）：未転送の履歴レコードを抽出）
レプリケーションプログラム１２０は、履歴テーブル２３０が格納しているレコードのうち、状態フィールド２３２が“未転送”であるものを抽出する。複数の履歴テーブル２３０が存在する場合（すなわちレプリケート元テーブルが複数存在する場合）は、全ての履歴テーブル２３０からレコードを抽出する。抽出したレコードを順序フィールド２３１にしたがって本ステップ内でソートしてもよいし、後のステップにおいてソートしてもよい。ここでは本ステップにおいてソートするものとする。
【００３３】
（図４：ステップ（２）：変換ルールを適用）
レプリケーションプログラム１２０は、ステップ（１）において抽出したレコードに対して変換テーブル１４０が定義している変換ルールを適用することにより、ゼロバイト長文字列とｎｕｌｌ値をそれぞれレプリケート先データベース（ここでは第２ＤＢ３２０）上における書式に変換する。例えば図３の３行目のレコードはカラム１をゼロバイト長文字列“”に更新する旨を指定しているので、これを第２ＤＢ３２０へ反映する際には、図２の１行目の変換ルールにしたがって、当該レコードの“”を“  ”（スペース文字）に変換する。
【００３４】
（図４：ステップ（３）：第２ＤＢを更新：その１）
レプリケーションプログラム１２０は、ステップ（２）においてゼロバイト長文字列とｎｕｌｌ値を変換した後の各レコードを用いて、第２ＤＢ３２０を更新する命令を生成する。第２ＤＢ３２０に対して実施すべき更新命令の種別は、命令文フィールド２３３に記載されている。当該更新命令において指定すべき各カラム値は、各履歴テーブル２３０それぞれのカラム値部分（変換を実施した場合はその変換後の値）に記載されている。したがってレプリケーションプログラム１２０は、これらフィールドを参照することにより、第２ＤＢ３２０に対して実施すべき更新命令を生成することができる。
【００３５】
（図４：ステップ（３）：第２ＤＢを更新：その２）
レプリケーションプログラム１２０は、生成した更新命令を順序フィールド２３１が指定する順番で実行することにより、第２ＤＢ３２０に対して履歴テーブル２３０の内容を反映する。レプリケーションプログラム１２０は、反映したレコードについては、状態フィールド２３２を“転送済”に変更する。
【００３６】
（図４：ステップ（２）〜（３）：補足）
これらステップを実施する順序は入れ替えてもよい。すなわち、第２ＤＢ３２０に対する更新命令を生成した後に変換ルールを適用してもよい。
【００３７】
＜実施の形態１：まとめ＞
本実施形態１に係るレプリケーションプログラム１２０は、第１ＤＢ２２０におけるゼロバイト長文字列とｎｕｌｌ値を第２ＤＢ３２０における書式にそれぞれ変換した上で、第１ＤＢ２２０のレコードを第２ＤＢ３２０へレプリケートする。これにより、レプリケート後においてもデータ不整合を生じることなくアプリケーションを稼働させることができる。
【００３８】
本実施形態１に係るレプリケーションプログラム１２０は、第２ＤＢ３２０におけるゼロバイト長文字列の書式とｎｕｌｌ値の書式を、カラム毎に変換する。これにより、変換を実施すべきカラムについてのみ変換を実施し、レプリケーションの処理効率を高めることができる。またテーブルのカラム構造に依拠することなく上記変換を実施することができる。
【００３９】
＜実施の形態２＞
図５は、本発明の実施形態２における変換テーブル１４０の構成とデータ例を示す図である。本実施形態２において、変換テーブル１４０は実施形態１で説明した構成に加えて新たに抽出フォーマットフィールド１４５を有する。その他構成は実施形態１と同様である。
【００４０】
抽出フォーマットフィールド１４５は、レプリケート元データベースのレコードを抽出する際に当該レコードをどのようなデータ型として取り扱うかを指定する。例えば“ＴＥＸＴ”は元レコードを文字列型として取り扱うことを示し、“ＦＬＯＡＴ３．２”は整数部３桁かつ小数部２ケタの浮動小数点型として取り扱うことを示す。
【００４１】
レプリケーションプログラム１２０は、レプリケート元レコードを抽出する際に、抽出フォーマットフィールド１４５が指定するデータ型に合致しない部分については適宜切り捨てなどの措置を施す。例えば“ＦＬＯＡＴ３．２”が指定されている抽出元カラムの小数部が３桁以上ある場合、３桁目以降は切り捨てまたは四捨五入する。あるいは“ＦＬＯＡＴ３．２”が指定されている抽出元カラムが数値でない場合、抽出後のカラム値は例えば“０．０”とする。
【００４２】
＜実施の形態３＞
実施形態１においては、第１ＤＢ２２０から第２ＤＢ３２０へレプリケートを実施することを前提としたが、第２ＤＢ３２０から第１ＤＢ２２０へレプリケートを実施する際にも本発明を用いることができる。本発明の実施形態３ではその１例について説明する。
【００４３】
第２ＤＢ３２０から第１ＤＢ２２０へレプリケートを実施する際にも、処理対象とするデータベースが入れ替わったのみであるから、実施形態１と同様の処理手順を用いることができる。ただし第２ＤＢ３２０がゼロバイト長文字列をｎｕｌｌ値として取り扱うことに鑑み、レプリケーションプログラム１２０またはマニュアル作業によってゼロバイト長文字列の代わりにスペースを代入する措置があらかじめ取られ、レプリケート元たる第２ＤＢ３２０がかかるレコードを格納している場合がある。そこで本実施形態３においては、レプリケート元レコードがスペース文字列であった場合にこれをレプリケート先においてどのように取り扱うかをあらかじめ定義することとした。
【００４４】
図６は、本実施形態３における変換テーブル１４０の構成とデータ例を示す図である。本実施形態３において、変換テーブル１４０は実施形態１で説明した構成に加えて新たにスペース変換ルールフィールド１４６を有する。その他構成は実施形態１と同様である。
【００４５】
スペース変換ルールフィールド１４６は、レプリケート元データベース上においてスペース文字列のカラム値が格納されている場合、その値をレプリケート先データベースにおいてどのような値として格納するかを指定する書式を示す。上記想定によればスペース文字列はレプリケート先データベースにおいてゼロバイト長文字列として格納すべきであるから、図６の１行目のレコードはその旨を指定している。ただしカラムの性質によってはスペースを格納することが初めから意図されている場合もあるので、そのようなカラムについては本フィールドを指定せずレプリケート元レコードをそのままレプリケートするようにしてもよい。図６の２行目のレコードはその旨を示す。
【００４６】
＜本発明の変形例について＞
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換える事が可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について他の構成の追加・削除・置換をすることができる。
【００４７】
以上の実施形態において、レプリケーションプログラム１２０は、レプリケート前後の各ＤＢがそれぞれ異なる文字コードを用いる場合は、レプリケート元レコードをレプリケート先データベースが使用する文字コードへ変換してもよい。
【００４８】
以上の実施形態において、ゼロバイト長文字列をスペース文字列に変換する例を示したが、ゼロバイト長文字列がｎｕｌｌ値として取り扱われる不具合を回避するためには何らかの文字列が格納されていればよいので、スペース以外の適当な文字列を用いてもよい。ただし処理の便宜に鑑みて、何らかの１バイト長以上の文字または文字列であることが望ましい。
【００４９】
以上の実施形態においては、説明の容易のためＲＤＢＭＳ（リレーショナルデータベース管理システム）におけるＳＱＬ命令文を例示したが、実施すべき命令はデータベース管理システムの仕様に応じたものを適宜用いればよく、必ずしもＳＱＬ命令文に限られるものではない。
【００５０】
以上の実施形態においては、履歴テーブル２３０にレコードを格納する手段としてデータベーストリガを用いているが、その他適当な手段によりレプリケート元データベースに対する更新操作を記録してもよい。
【００５１】
以上の実施形態においては、第１ＤＢコンピュータ２１０上のデータベースを第２ＤＢコンピュータ３１０上のデータベースへレプリケートしているが、同一コンピュータ上の異なるデータベース管理システム間でレプリケーションを実施する際に本発明を用いることもできる。
【符号の説明】
【００５２】
１００：レプリケーションコンピュータ、１１０：ＣＰＵ、１２０：レプリケーションプログラム、１３０：記憶装置、１４０：変換テーブル、２１０：第１ＤＢコンピュータ、２２０：第１ＤＢ、２３０：履歴テーブル、２４０：採番データ、３１０：第２ＤＢコンピュータ、３２０：第２ＤＢ。
【図１】
2017027349.tif 000003
【図２】
2017027349.tif 000004
【図３】
2017027349.tif 000005
【図４】
2017027349.tif 000006
【図５】
2017027349.tif 000007
【図６】
2017027349.tif 000008