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

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

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

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

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

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

宜しくお願いします。

回答の条件
  • 1人3回まで
  • 13歳以上
  • 登録:2011/07/29 10:19:55
  • 終了:2011/08/05 10:20:03

ベストアンサー

id:papavolvol No.1

papavolvol回答回数1073ベストアンサー獲得回数1982011/08/01 10:05:42スマートフォンから投稿

アプリAの Oracle DBに、ユーザー企業のアプリや統計・集計処理を行うためにアクセスする場合、2通りの方法があります。

1つは、夜間にバッチジョブで書き出したり、統計・集計処理を行う場合です。

2つめの方法は、オンラインでDBのデータにアクセスする方法です。こちらの方法では、中規模以上のシステムでは、レプリカのDBを作成してユーザー企業のアプリはレプリカDBにアクセスするようにします。

アプリAは実体のDBを使用し、ユーザー企業のアプリはレプリカDBを使用します。

ユーザー企業のアプリの原因でDBやデータに障害を起こさないため、アプリAのレスポンス確保のため、データの一貫性・整合性保証のためです。

特にDBはインデックスの設定とアクセスパスの選択で、レスポンスが極端に悪くなります。ユーザー企業のアプリが、DBのレスポンスを低下させて、アプリAを止めてしまうリスクがあります。

管理者権限のユーザーIDの管理は、通常はユーザー企業の責任範囲です。セキュリティー管理責任まで含めたアウトソーシング契約をしない限り、ユーザー企業がユーザーIDとパスワードの管理責任を持ちます。

id:kyoko55

ありがとございます。レプリカのDB、勉強してみます。

2011/08/04 21:03:19

コメントはまだありません

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

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません