人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

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

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

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

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

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

宜しくお願いします。

●質問者: kyoko55
●カテゴリ:コンピュータ
✍キーワード:dB ONE Oracle SELECT SQL Server
○ 状態 :終了
└ 回答数 : 1/1件

▽最新の回答へ

1 ● papavolvol
ベストアンサー

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

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

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

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

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

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

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

◎質問者からの返答

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

関連質問


●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ