ER図 データベース移行心得

 2017.05.12  株式会社システムインテグレータ

er-mig1.png昨今、Cloud化の流れやMySQLなどフリーデータベースの隆盛により、データベースの移行を検討するケースが増えてきています。手動でデータベースを移行することは、とても大変な作業です。ただ闇雲に行うだけでは失敗の可能性だけが高くなってしまいます。ここでは異種データベース間でのデータベース移行をテーマに、「ここだけは抑えておきたい」ポイントをご紹介します。

 

移行先にテーブルを作る

まずは移行先データベースにテーブルを作ります。移行成功の多くはここに懸かっていると言っても過言ではなく、チェックするポイントも一番多くなります。

SQLの方言

テーブルごとにCREATE文を用意していきます。その構文はほとんどのデータベースで大筋は同じですが、細かな点で違いがあります。たとえばオブジェクト名の大文字小文字を区別する場合などに引用符で囲みますが、データベースによって異なります。また、SQL文を連続して発行する場合の「区切り文字」もデータベースに合わせて変更していきましょう。

ほとんどのデータベースは引用符で囲む事によって大文字小文字の区別がなされますが、PostgreSQLは引用符をつける事によって区別しなくなります。(「”Test”」は「TEST」として生成)ほかのデータベースと逆になりますので、特に注意が必要です。

囲み引用符、区切り文字の違い

  Oracle SQL Server PostgreSQL MySQL
囲み引用符 ”Test” [Test] ”Test” `Test`
区切り文字 / go / ;

Oracleのオブジェクト名はほかと比べて短い

移行先がOracleの場合、オブジェクト名の長さにも注意が必要です。制限が30byteと意外に短く、テーブル名などに日本語を設定していると、思いのほかすぐに制限に抵触してしまいます。場合によりテーブル名の見直しが必要になるでしょう。なお、Oracle 12c R2より、128byteに拡張されます。今後はそれほど神経質になる必要はありませんが、現状は心に留めておく必要があります。

 

オブジェクト名の制限

Oracle SQL Server PostgreSQL MySQL
30byte※ 128文字 63文字 64byte

※Oracle12 c R2より128byteに拡張

データ型を考える

データ型もデータベースによって名称が変わります。Oracleで「NUMBER」で定義しているものはSQL Serverでは「Numeric」か「Decimal」に変更する必要があります。

このように名称は違いますが同じ意味を持つデータ型にそれぞれ置き換えて行きます。変換ゆれなどを防ぐためにもマッピングテーブルを作成して整理しておく事をお勧めします。

 

データ型マッピングの一例(Oracle基準)

Oracle SQL Server PostgreSQL MySQL
BLOB IMAGE BYTEA BLOB
CHAR CHAR CHAR CHAR
DATE DATETIME DATE DATETIME
LONG TEXT TEXT TEXT
NCHAR NCHAR CHAR CHAR
NUMBER NUMERIC NUMERIC DECIMAL
NVARCHAR2 NVARCHAR VARCHAR VARCHAR
VARCHAR2 VARCHAR VARCHAR VARCHAR
BFILE VARBINARY BYTEA BLOB
CLOB TEXT TEXT TEXT
FLOAT FLOAT FLOAT FLOAT
RAW BINARY BYTEA BLOB
NCLOB NTEXT TEXT TEXT

同じ名前でも注意が必要

VARCHAR、CHARは、どのデータベースにも存在しておりますが(OracleはVARCHAR2)データベースによってUniCode文字が格納できる、できないの差があります。例に挙がっているデータベースのなかでは、SQL ServerのみUniCodeが格納できません(NVARCHARなどのN系のデータ型を使用する)。また、VARCHAR(20)とした場合、「(20)」の部分はOracleとSQL Serverは 通常は文字のbyte数を表しますが、PostgreSQLとMySQLは文字数をそのまま表します。移行元データベースのデータ格納状況に合わせて、柔軟に設定していきましょう。

データベース設計・移行に関するお役立ち資料

日付型DEFAULT

最後に制約まわりを確認します。大きなところでは、やはり日付型DEFAULT関数でしょうか。Oracleは「SYSDATE」、SQL Serverは「GETDATE()」など、データベースごとに置き換えていきます。

代表的な日付型DEFAULT関数

Oracle SQL Server PostgreSQL MySQL
SYSDATE GETDATE() CURRENT_DATE CURRENT_TIMESTAMP※

※5.6.5以降

移行先がMySQLの場合、Check制約への考慮が必要です。というのも、MySQLにはCheck制約がないのです。移行先でもチェックを行いたい場合、代替させる仕組みを用意する必要があります。下記はその一例です。

  • ENUM型、SET型を使用する
    ENUM、SETはデータ型の一種です。格納可能なデータを列挙して宣言する事ができ、それ以外のデータを排除する事ができます。
  • トリガーを作成する
    更新時に発生するトリガーで、エラーチェックやロールバック処理を生成します。


ここまででテーブル生成の処理が一通り終わりました。

ポイントを下記にまとめましたので確認しましょう。

ここがポイント

  • 区切り文字、囲み引用符をデータベースにあわせて変更しよう
  • PostgreSQLは囲み引用符をつけた場合の意味がほかのデータベースと異なるので注意
  • Oracle(12.1以下)に移行する場合、オブジェクト名の長さを意識して
  • UniCode文字の扱い。おなじVARCHARでホントに大丈夫?
  • データベースによってデータ型の長さのとらえ方が異なる
  • 日付型DEFAULT関数の置き換え、MySQL移行時のCheck制約の扱い

データを移行する

バイナリデータは扱いがむずかしい

ではいよいよデータを移行します。移行方法そのものについては、それほど問題はないと思います。先にあげたようにUniCodeデータに注意するくらいでしょうか。

CSVなどのテキストデータとして出力し、移行元でインポートするなどの方法が取れるデータベースもあります。単純なインポートが難しい場合でも、移行元でINSERT文を生成するプロシージャを作成し、移行先でそのSQLを実行することで比較的容易に移行できます。この場合、合間にCOMMIT命令を挟み込めば、データを確定しながらの移行も可能です。

ただ、バイナリ系のデータだけはテキストで扱えない分、工夫が必要になります。データの取り出し処理、読込処理をそれぞれ移行元データベース、移行先データベースで作成する必要があるでしょう。

また、この時点では移行の妨げになる可能性がある外部キーやトリガーは構築しておかないほうが無難です。

ここがポイント

  • 移行するデータに投入できない内容が含まれていないかを確認
  • バイナリデータは別途考慮する必要がある
  • 外部キーやトリガーの設置は完璧に移行が済んでから

移行データをチェックする

まずは件数確認からはじめよう

移行が済んだら、処理がうまくいったか確認します。一番簡単なチェックは、移行元データと移行先データの件数確認です。何らかのエラーが発生しデータの投入に失敗している場合は件数に差異が出ているはずです。ほかにも文字化けていないかなどの確認も必要に応じて行いましょう。全データを移行元、移行先でそれぞれテキストに出力し、比較ツールを使用して差分がないかを比較するのも有効です。

しかしながら、数万、数十万件のデータからエラーデータを特定していくのは、なかなか骨の折れる作業です。地道にいきましょう。

ここがポイント

  • まずは移行前、移行後の件数チェック
  • 比較ツールの利用も有効
  • エラーデータの特定は根気よくおこなう
[RELATED_POSTS]

ツールを使って自動化

SI Object Browser ER を使えば簡単にデータベース移行できます

データベース移行の流れ、及びそのポイントについてご紹介していきました。いかがでしたか?たぶん「大変な作業だ」と思われたと思います。確かに最初から最後まで手動で行なうのは大変です。

そこで、弊社では異種データベースの方言の違いを変換し、データベース移行、データベース・マイグエ―ションを簡単にできるツール「SI Object Browser ER(以下OBER)」を用意しました。このツールを使えば、RDBMSマイグレーションとデータ移行をあっという間に実施することができます。

【特長1】移行ナビに従って操作するだけでメタデータをコンバージョン

もともとOBERはデータモデリングツールでしたが、Ver.9.0より「データベース移行機能」を実装し、データベース移行を簡単に行えるようにしました。次のような移行手順に沿ったナビゲーションを用意していますので、ナビに従って操作するだけでスムーズにデータベースとデータの移行を行うことができます。

  • 移行元データベースからテーブルをリバース
    リバースエンジニアリング機能を使い、OBERから移行元データベースに接続して、テーブル情報を自動で取込みます。
  • データベースタイプ一括変更
    モデルのタイプを移行先データベースのものへと変更します。この操作で、引用符や区切り文字といったデータベースごとのSQLの方言が変更され、データ型、日付型DEFAULT関数もあらかじめマッピングされた内容に基づいて自動で変換されます。
  • モデル検証
    この機能では、移行元にそぐわない誤ったデータ型や日付DEFAULT関数が設定されていないかなど、モデルの正当性を検証します。オブジェクト名の長さ制限などもここで抽出できます。
  • 移行先データベースにフォワード
    移行先データベースに接続し、フォワードエンジニアリング機能を使用してテーブルを作成します。これでテーブル移行までは完了です。
  • データ移行
    あとはデータ移行画面にて、移行元、移行先双方に接続し、データを移行するだけです。同名テーブルであれば自動でマッピングされます。また、手動でマッピングを変更する事もできます。

データベースにテーブルを作成し、データを移行するまで特に迷う事もなく、あっという間に完了させる事ができます。①~⑤までの詳細や、データ移行機能については、下記特設ページをご用意しておりますので、興味のある方はご参照ください。

https://products.sint.co.jp/ober/support/history

 

OBERでは上記手順をナビゲートする「移行ナビ」画面もご用意しております。画面上の解説にあわせて順番に進めるだけ移行完了までご案内しますので、初めての方でも安心です。

【特長2】中間ファイルを介さず「右から左」へ驚くほど簡単にデータを移行

OBERでは移行時にデータベース間のデータ型の差異を埋めるため、移行元、移行先双方をいったん互換性のあるテーブルとして展開する手法を採用しております。そのテーブル間でダイレクトにデータコピーを行なうので、CSVなどのファイルに出力したり、INSERT文を作成したりしません。ファイルの出力、移送、取込といった手順を大幅に削減できるので、データ移行をより簡単に行うことができます。

バイナリデータも気にならない

この仕組みにより、手動移行の場合に特別に対応しなければならなかったバイナリデータも、ほかのデータと同じように「右から左」へ移行が可能です。また、一時的に外部キー、トリガーを解除する事もできます。(データ移行後に復元)

エラーデータはログで確認

データ移行後、成功件数/全体件数が表示されます。さらに、何らかの原因により移行(移行先テーブルへのINSERT)に失敗したデータは、1レコードごとにログとして吐き出されますので、移行失敗の原因究明に役立ちます。

まとめ

データベース移行におけるポイントや注意点は、データーベース移行ツールOBERを使用することによって解決できます。ツールを使って機械的な変換やチェックを行なう事によって移行ミスを防ぐ事ができますし、移行に関わる作業工数を大幅に削減することができます。

また、もともとOBERは設計効率を高めるデータモデリングツールです。移行後はそのままER図でデータベース設計・保守ができますので、移行作業だけでなく移行後も大幅に工数削減できます。

SI Object Browser ER ガイドブック

RECENT POST「OBERをトコトン極める」の最新記事


この記事が気に入ったらいいねしよう!