質問: 業務関係の市販のアプリ(以下、アプリA)を使用し各営業所でスタンドアローン版で動作中。 元来Oracleや、SQL Serverにも対応可。 今後、Oracle導入済みのサーバにアプリAを移行して動作予定。 そこで、自社開発予定のシステムなどから、アプリAが保存することになるDBの 中身を直接読み込む(SELECTのみ)ことの問題点をお聞きします。 質問1. DB接続のユーザのパスワード等は、Oracleを管理している自社が、アプリA(を設定する代理店)に付与するもの だと想像しています。なので当方が接続のパスワードがわからないことは無いですよね。接続可ですよね。 質問2. 元来の独自のバイナリファイル形式からDBのテーブルに変わるので 有る程度のデータは判読可と予想しますが、逆アセンブリできなくする技術のように、あえて判読困難にしてあるのでしょうか。 質問3. アプリAと自社システムの場合のように複数のシステムで使用する場合、DBCAなどを使ってデータベースを新規に作成するのですよね? それとも同一のデータベース上ですか? 質問4. ライセンスは、Standard Edition Oneですが、データベースの作成数に制限はありませんよね? 宜しくお願いします。
回答: アプリAの Oracle DBに、ユーザー企業のアプリや統計・集計処理を行うためにアクセスする場合、2通りの方法があります。 1つは、夜間にバッチジョブで書き出したり、統計・集計処理を行う場合です。 2つめの方法は、オンラインでDBのデータにアクセスする方法です。こちらの方法では、中規模以上のシステムでは、レプリカのDBを作成してユーザー企業のアプリはレプリカDBにアクセスするようにします。 アプリAは実体のDBを使用し、ユーザー企業のアプリはレプリカDBを使用します。 ユーザー企業のアプリの原因でDBやデータに障害を起こさないため、アプリAのレスポンス確保のため、データの一貫性・整合性保証のためです。 特にDBはインデックスの設定とアクセスパスの選択で、レスポンスが極端に悪くなります。ユーザー企業のアプリが、DBのレスポンスを低下させて、アプリAを止めてしまうリスクがあります。 管理者権限のユーザーIDの管理は、通常はユーザー企業の責任範囲です。セキュリティー管理責任まで含めたアウトソーシング契約をしない限り、ユーザー企業がユーザーIDとパスワードの管理責任を持ちます。