1.データベース素人のこと

SE歴8年目なのにシステム構築経験なし。システムに詳しくないお客さま相手にかみ砕いた資料を作成して、かみ砕いた説明をして要件を聞き出してくることしかしたことがない。保守業務として小さい改修はやったことがある。

チーム作業経験なし。だいたい単独行動。1年目の研修終了後、いきなり炎上プロジェクトに突っ込まれ、いきなり一人チーム所属になり、いきなりお客さまの元へ一人で行って要件聞き出して来いと言われ、いろんなプロジェクトを転々としつつも同じような業務を任され現在に至る。

だいたい全部独学。他部署では下流のテスト打鍵作業から入り、先輩が手取り足取り教えてくれるらしいが、自力で頑張るハードな部署に配属されたため、お客さまとの話し方や要件ヒアリングの仕方など自力で調べて習得した。

データベース構築経験なし。データベース（以下、DB）は調査や維持管理で、SQL使ってデータ抽出したり変更したりするくらい。

なのに、データ移行を任されました。
詳しそうな先輩に聞いてみましたが、制約の中で良さそうな方法を考えるしかないとのこと。
なんとかしますよ、お仕事ですからね…。

ひとまず「わたしがかんがえるさいてきなでーたいこう」を考えて、データ移行とかわかりそうな人とかにレビューしてもらうことにしました。

2.環境

現行：オンプレにあるOracle Database 12c
↓
新規：AzureにあるPostgreSQL ※
※バージョン未定。検討中なのでMySQLになる可能性もなくはない。

【すごくぞんざいな用語解説】
オンプレ
自社で物理的なサーバをたてて、保管して、そこにシステムを構築すること。
Oracle Database
おらくる でーたべーす。アメリカのオラクル社が開発・販売しているRDBMSのこと。12cはバージョン。
Oracle
おらくる。データベース界のシャネル。
RDBMS
あーるでーびーえむえす。Relational Database Management System。関係データベース管理システム。データベースを管理するためのシステム。
Azure
あじゅーる。Microsoft Azure。マイクロソフトが提供しているクラウドサービスの集合体。いろんなツールを提供してくれる。
PostgreSQL
ぽすとぐれすきゅーえる。オープンソースのORDBMS。ポスグレ。
ORDBMS
おーあーるでーびーえむえす。オブジェクト関係データベース管理システム。RDBMSにオブジェクト指向の考え方を取り入れたシステム。よくわからないけどOracleとちょっと毛色の違ったデータベースを管理するシステム。

3.データ

現行のデータ量はかなり少なめらしい。最大500万レコード程度。
一時テーブルを除いて110テーブルあり、移行対象は42テーブル。
移行先は27テーブルの予定。
ホスト構築のノリで構築されたDBのようで、正規化が過剰すぎて同じようなテーブルがいくつも存在する。そのため、ほとんど単純移行できない。複数テーブルを統合したりするので、めっちゃ加工して移行する必要がある。

データ量
1億レコードくらいあると、移行方法の制約にデータ量が入るらしい。
正規化
一定のルールで、データを使いやすいようにデータをテーブルごとに分けたり加工したりすること。概念をふんわり知りたい場合は「分かりそう」で「分からない」でも「分かった」気になれるIT用語辞典、具体的な方法まで知りたい場合はQiitaがおすすめです。

4.検討

上司に「わからないのはわかったから、わかる範囲で書いてよ」と言われて、わかる範囲で書いた。

①現行DBからデータを取り出す。
②加工が必要な場合は、加工する。
③新DBにデータを投入する。
④新システムでデータを確認する。

上司に「大きな流れは合ってるね。具体的にどういう方法でやるの？」と、ここでは割愛するが例示までしてくれた。SE歴8年目とは思えないわたしの回答になんて優しい指摘。穏やかな上司好き。とはいえわからない。調べるも単純移行ばかりだし、判断基準なんかだれも載せていない！先輩に聞いたら制約の中で良さそうな方法を考えるしかないとのこと。そうですか…好き勝手考えますわ！

4.検討 - 1.データ抽出方法

検討すべき項目としては、以下の通り。

①抽出方法
②出力形式
③確認方法

①抽出方法

平時利用している方法を利用する方が、実績があり確実だと考える。現行システムでは、OracleDBには2通りの接続を使用している。

A. ツール「A5:SQL Mk-2」（以下、Mk-2）
B. PL/SQL

但し、A.のMk-2を利用すると、日付型についてデータが落ちていたり、文字化けが起こったりしたことがあったため、B.のPL/SQLで実施する。

②出力形式

①で検討したPL/SQLでは、標準出力とファイル出力ができることは知っている。
というわけで、互換性の高いCSVファイルにしよう。txtファイルでもいいけど。
抽出時に加工するかどうかは、次の③で確認する。

③確認方法

抽出時に加工すると、2.の加工についてもいっぺんに完了することができる。但し、確認が大変な気がする。
そこで、カラム単位での確認は不要、レコード数だけの確認で済ませるため、加工せずに全件抽出する。

まとめ

①抽出方法：PL/SQLを用いて、
②出力形式：CSVファイルで全件加工なしで出力し、
③確認方法：テーブルごとのレコード数確認を行う。

4.検討 - 2.データ加工方法

検討すべき項目としては、以下の通り。

①加工方法
②出力形式
③確認方法

①加工方法

CSVファイルで出力するため、変換プログラムをかける。他にも方法があるのかもしれないが、私は知らん。
言語も後で決める。BATでもjavaでも変換されりゃなんでもいいだろ。

②出力形式

確認のしやすさ的には、CSVファイルな気がする。しかしPostgreSQLにデータ投入することを考えるべく、Google先生にお尋ねする。

[PostgreSQL インポート][検索]
PostgreSQLでcsvファイルのインポート - Qiita

なるほど、CSVファイルにしよう。

③確認方法

変換をかけてしまうため、目視でしか確認できないのでは？と思う。確認ツールを作っても、結局その妥当性を確認しなきゃいけないし…。
変換プログラムの確認、ピックアップ（＝数件選択して）で目視確認しよう。

まとめ

①加工方法：変換プログラムで加工して
②出力形式：CSVファイルで出力し、
③確認方法：ピックアップで目視確認する。

4.検討 - 3.データ投入方法

検討すべき項目としては、以下の通り。

①投入方法
②確認方法

①投入方法

「4.検討 - 2.データ加工方法」で見つけた記事通り、/copyコマンドでインポートしようと思う。以下、PostgreSQLでcsvファイルのインポート - Qiitaより抜粋メモ。

# DB「customerdb」作成
createdb customerdb

# 作成したDBに入る
psql customerdb

# テーブル「customer」を作成する
CREATE TABLE customer
(id char(15) NOT NULL,
 name varchar NOT NULL,
 PRIMARY KEY (id));
CREATE TABLE

# csvファイルをテーブルにインポート
\copy customer from 'Documents/file.csv' with csv

# インポート確認
SELECT * FROM customer;

②確認方法

投入前のCSVファイルとインポート結果を比較する。
違うDBMDだし、文字コードも変更するかもなので、全件確認したい。全件確認を目視でやるのは無理。

よって、インポートした結果をCSV出力して、CSVファイル同士で比較する。

まとめ

①投入方法：/copyコマンドでデータ投入し、
②確認方法：新環境から出力したCSVファイルで比較確認する。

4.検討 - 4.データ確認方法

検討すべき項目としては、以下の通り。

①データの妥当性確認
②画面表示確認
③性能要件の確認

①データの妥当性確認

「4.検討 - 3.データ投入方法」の「②確認方法」で確認済みのため、ここでは検討しない。

②画面表示確認

「①データの妥当性確認」で格納されているデータの妥当性は確認しているけど、最終的にユーザーが見るのは画面表示なので確認する。画面裏のロジックと掛け合わせると文字化けとかなにか起こる可能性があるし、念には念を入れるということで。

可能であれば全画面目視確認する。だめならピックアップで。
ついでに画面表示速度も確認する。

③性能要件の確認

画面表示速度、バッチ処理速度、SQLでの抽出時間が思いついた。
正直今回は画面もバッチも新規構築してるから、データだけの問題ではないんだけど、システム全体の最終確認としてやった方がいいかなーと思う。

画面表示速度は、「②画面表示確認」でやるのでここでは割愛。
バッチ処理速度は、全バッチ流して測る。
SQLの抽出時間は、いいかな。ユーザー関係ないし。

性能要件
非機能要件のひとつ。画面表示速度とか。
非機能要件
システムの機能要件以外の要件を指す。画面表示速度や、セキュリティに関する要件。詳しくはIT用語辞典で。
機能要件
機能や動作、画面表示や帳票などの要件のこと。どんなシステムかの問いとして返ってくる項目らへん。

まとめ

①データの妥当性確認：前項で検討済み。割愛。
②画面表示確認：全画面、速度確認も含めてやる。
③性能要件の確認：②と合わせて、バッチの処理速度確認する。

4.検討 - 検討結果

1.データ抽出方法
PL/SQLを用いて、CSVファイルで全件加工なしで出力し、テーブルごとのレコード数確認を行う。

2.データ加工方法
変換プログラムで加工してCSVファイルで出力し、ピックアップで目視確認する。

3.データ投入方法
/copyコマンドでデータ投入し、新環境から出力したCSVファイルで比較確認する。

4.データ確認方法
画面表示確認は全画面に対して実施し、表示速度が非機能要件に則していること、表示内容に文字化けがなくデータ通り表示されることを確認する。
バッチ処理確認は全バッチに対して実施し、処理速度が非機能要件に則していることを確認する。