kyoko55回答ポイントなし

業務関係の市販のアプリ（以下、アプリＡ）を使用し各営業所でスタンドアローン版で動作中。

元来Oracleや、SQL Serverにも対応可。
今後、Oracle導入済みのサーバにアプリＡを移行して動作予定。
そこで、自社開発予定のシステムなどから、アプリＡが保存することになるDBの
中身を直接読み込む（SELECTのみ）ことの問題点をお聞きします。

質問１．
DB接続のユーザのパスワード等は、Oracleを管理している自社が、アプリＡ（を設定する代理店）に付与するもの
だと想像しています。なので当方が接続のパスワードがわからないことは無いですよね。接続可ですよね。

質問２．
元来の独自のバイナリファイル形式からDBのテーブルに変わるので
有る程度のデータは判読可と予想しますが、逆アセンブリできなくする技術のように、あえて判読困難にしてあるのでしょうか。

質問３．
アプリＡと自社システムの場合のように複数のシステムで使用する場合、DBCAなどを使ってデータベースを新規に作成するのですよね？
それとも同一のデータベース上ですか？

質問４．
ライセンスは、Standard Edition Oneですが、データベースの作成数に制限はありませんよね？

宜しくお願いします。

ログインして回答する

ベストアンサー

papavolvol2011/08/01 10:05:42

アプリAの Oracle DBに、ユーザー企業のアプリや統計・集計処理を行うためにアクセスする場合、2通りの方法があります。
1つは、夜間にバッチジョブで書き出したり、統計・集計処理を行う場合です。
2つめの方法は、オンラインでDBのデータにアクセスする方法です。こちらの方法では、中規模以上のシステムでは、レプリカのDBを作成してユーザー企業のアプリはレプリカDBにアクセスするようにします。
アプリAは実体のDBを使用し、ユーザー企業のアプリはレプリカDBを使用します。
ユーザー企業のアプリの原因でDBやデータに障害を起こさないため、アプリAのレスポンス確保のため、データの一貫性・整合性保証のためです。
特にDBはインデックスの設定とアクセスパスの選択で、レスポンスが極端に悪くなります。ユーザー企業のアプリが、DBのレスポンスを低下させて、アプリAを止めてしまうリスクがあります。
管理者権限のユーザーIDの管理は、通常はユーザー企業の責任範囲です。セキュリティー管理責任まで含めたアウトソーシング契約をしない限り、ユーザー企業がユーザーIDとパスワードの管理責任を持ちます。

スター
- kyoko55 2011/08/04 21:03:19
  
  ありがとございます。レプリカのDB、勉強してみます。

業務関係の市販のアプリ（以下、アプリＡ）を使用し各営業所でスタンドアローン版で動作中。

ベストアンサー

papavolvol2011/08/01 10:05:42

kyoko55 2011/08/04 21:03:19

その他の回答

この質問へのコメント

この質問への反応（ブックマークコメント）

質問の情報

この質問のカテゴリ

この質問に含まれるキーワード

人気の質問

メニュー

PC版