エンタープライズ：知っておきたいデータベース移行術「SQL Server→Oracle編」 (6/15)

エンタープライズ：特集

2003/07/25 18:19:00 更新

［Java Developer特別企画］2003年9月号
知っておきたいデータベース移行術「SQL Server→Oracle編」 (6/15)

JAVA Developer 2003年9月号より転載

・日付データ型
　SQL Serverのdatetime型は、Oracle9iのdate型にそのまま移行できます。どちらも、日付と時間を一緒に格納するデータ型ですが、表現できる日付の範囲が異なります。

　SQL Serverのdatetime型は西暦1753年1月1日から9999年12月31日までなのに対し、Oracle9iのdate型は西暦前4712年1月1日から西暦4712年12月31日までを取り扱います。この範囲のずれは、通常の業務システムで利用するうえではとくに問題にはなりませんが、用途によっては型の変換が必要なケースもあるでしょう。

　たとえば、歴史上の人物やできごと、建築物のデータを取り扱う際、SQL Serverのdatetime型ではそのまま対応することができませんが、Oracle9iのdate型ならそのまま使用できます。もちろん、データの特性によってはまったく逆のケースもありうるでしょう。

　注意しなければならないのは、「timestamp」です。SQL Serverのtimestampは、timestamp列やtimestamp型と呼ばれるもので（rowversionとも呼ばれる）、行の挿入または更新時に自動的に値が更新されるものです。まさに行を操作したことを記録するタイムスタンプなのです。これに対しOracle9iのtimestamp型は、秒の小数点以下最大9桁まで取り扱うことができるデータ型になります。両者の機能はまったく異なるものです。

　さて日付のデータ型に関しては、そのデータ移行よりも、むしろ取り扱い方に変更が必要です。

　たとえば、SQL Serverで現在の日付を得る関数GETDATE関数はOracle9iではSYSDATE関数にする必要があります。また変換関数も異なり、SQL ServerではCONVERT関数を使用しますが、Oracle9iでは日付型にする場合はTO_DATE関数、文字列にする場合はTO_CHAR関数を使用します。

　SQL ServerのCONVERT関数は、関数名を統一することができますが、データ型を正確に覚えておく必要があります。変換関数の違いに関しては、関数移行のパートで解説します。

　2000年を過ぎてから問題の発生がきわめて低くなった2桁の西暦年の解釈にも違いがあります。

　2000年を過ぎた現在のアプリケーションのほとんどは西暦年を4桁で入力／表示し、計算上の取り扱いも行われていますが、2桁でデータを入力させ、データベースに格納するケースがまれにあります。SQL ServerもOracle9iもデータベース中では必ず4桁の西暦を使いますので、2桁データは自動的に4桁に変換されるのですが、このしくみに違いがあり、古いアプリケーションからの使用には注意が必要です。

　SQL Severでは2桁の年号が入力されたら、どの範囲の4桁の年号に置き換えるかを設定します。たとえば1950～2049と設定しておいたなら、「69」と入力された2桁は「1969年」に、「04」の場合は「2004年」になるわけです。

　Oracle9iの場合も日付書式を初期パラメータファイルなどに設定することで、解釈を変えることができます。解釈には現在の日付の年号を自動的に使用する場合の設定と、さらに指定された2桁と今年の下2桁との関係を判断し、現在の世紀か、前世紀か、後世紀を自動解釈する方法があります。

［JAVA Developer特別企画］
知っておきたいデータベース移行術
「SQL Server→Oracle編」

（１）データベース移行に伴う影響範囲～JDBCドライバ

（６）データ型の移行～ラージデータ型／そのほかの特殊な型

（７）表定義に関する情報の移行

（８）関数の移行～数値関数

（９）関数の移行～文字関数