すみません。

Essbaseという多次元サーバを開発することになったんですけど
Webブラウザからデータを分析したいといわれ困っています。
しかも、お金を掛けないで行いたいととどめを刺されました。

なにかよい方法はありませんでしょうか?
宜しくお願い致します.

このQ&Aに関連する最新のQ&A

A 回答 (2件)

参考URLの「Essbase OLAPサーバー」の


説明によると

「情報をユーザーが活用するための方法として、Essbaseは多くの選択肢を提供します。ユーザーが使い慣れているスプレッドシートのような一般的なデスクトップツール、レポートライター、クエリツール、およびWebブラウザなどです。統合された強力な開発環境であるMicrosoft Visual Basicを初め、業界標準である、HTML、C、C++、そしてJavaなどを用いて、カスタムアプリケーションを構築することも可能です。さらに、Essbaseとシームレスの統合を可能とする、Essbase-Ready(TM)パートナーから提供されるツールやアプリケーションも利用することができます。」

とありますのでJavaでも可能ではあるとは思います。


http://www.sirius.co.jp/products/essbase/seminar …
での「Wired for OLAP」のセミナー内容に
「JavaクライアントによるWEBソリューション」
と言う物がありますから。

参考URL:http://www.sirius.co.jp/products/essbase/cata_eb …
    • good
    • 0
この回答へのお礼

ありがとうございました。
これからもがんばります。

お礼日時:2001/06/13 10:08

Essbase Web Gateway



を使えば可能ですがこれではお金が掛かりすぎるのでしょうか。

参考URL:http://www.sirius.co.jp/products/essbase/cata_eb …
    • good
    • 0
この回答へのお礼

早速の御回答ありがとうございます。

確かに「Essbase Web Gateway 」でも可能なのですが
情報によると販売中止、サポートが打ち切られてしまうということ
らしいので、ちょっとそれだと厳しいですね。(^^;)

JAVAかなんかでできないでしょうかねぇ・・・。

お礼日時:2001/06/09 10:46

このQ&Aに関連する人気のQ&A

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!

このQ&Aを見た人が検索しているワード

このQ&Aと関連する良く見られている質問

Qすみません・・・

初歩的なことかもしれませんが、
アドバイスお願い致します。

既存のテーブルにフィールドを2つ追加したいのですが、
どのようにすればよろしいのでしょうか?

既存テーブル:sample_tbl
既存フィールド:name, old, address
追加フィールド:job[varchar2 80], email[varchar2[20]
です。
宜しくお願い致します。

Aベストアンサー

ALTER TABLE sample_tbl ADD (
jobVARCHAR2(80),
emailVARCHAR2(20)
);

ORACLEの場合
他でも 多分 同じだと思いますが・・・。
既存のフィールドは 関係ないです。

Q商品DBの開発

現在、商品マスタDBの開発を検討しています。商材の追加が月100件程度あり、更新も結構頻繁に発生します。使用者が、10人程度のためアクセスのDBをファイルサーバー経由で共有する形をとりたいと考えていました。
しかし、マスタ登録前の商談中の商品に関しても簡単に登録し、情報共有できるツールにしたいという追加の要件がでてきました。その場合、このツール上で商談中の商材を仮登録し、商談終了後にマスタ登録の承認を含めた一連の業務フローに対応する必要があります。アクセスではこのフローへの対応が出来ないのではないかと考えています。Notesのような感じのソフトで、安価で開発できるものはないでしょうか。予算は、50万から70万程度を見込んでいます。ユーザーは10人程度を想定しています。ご存知の方ございましたら、ご連絡をお願い致します。

Aベストアンサー

#1さんがおっしゃる通りで何の問題もないかと考えます。
仮登録か本登録かの区別のつく状態をテーブルに持たせておく。

MadeInTokyoさんの疑問はアクセスの機能で十分解決できます。

ユーザーによって参照のみにすることや、見えなくすることやボタンを消したり、フォームを消したり、操作不能にしたりなどなど、まず不可能と思われることはAccessに無いと思って結構です。

それから、DBを仮登録と本登録で分けることはしません。
ひとつで結構です。

また、この程度のユーザーであればAccessDBの信頼性も問題ないと思います。
DBがときどき破損することがありますが、「修復機能」をかければ問題ありません。必要であれば自動修復もかけられます。
DB使用中にテーブルをいじったり、プログラムの作り方が極端に悪くない限り、修復不可能に陥ることはまず無いです。

ひと時も絶対にDBが落ちる瞬間があってはならない!という次元のプロバイダーのような管理をお考えでしたら、他の方々が言われている方法を使用し、Accessは避けられた方が無難です。
ただし、費用を桁違いに出し外注するか、ご自身が専任され昼夜問わずプロ同等の管理を行っていくこととなります。

その他、疑問点がありましたら具体的にご質問ください。

#1さんがおっしゃる通りで何の問題もないかと考えます。
仮登録か本登録かの区別のつく状態をテーブルに持たせておく。

MadeInTokyoさんの疑問はアクセスの機能で十分解決できます。

ユーザーによって参照のみにすることや、見えなくすることやボタンを消したり、フォームを消したり、操作不能にしたりなどなど、まず不可能と思われることはAccessに無いと思って結構です。

それから、DBを仮登録と本登録で分けることはしません。
ひとつで結構です。

また、この程度のユーザーであればAccessDBの信...続きを読む

Qアクセス開発で質問

 こんにちは、かなりの難関が迫ってきました。
 現在WinXPでアクセス97の簡易アプリを開発しています。それの仕様を簡単にすると次の通りです。テーブルのフィールドには「団体名」「団体区分」の二つがあり、それをフォーム上に表示する。また、フォーム上のコンボボックスで「団体区分」を選択すると、その区分に属する「団体名」が全て表示される仕組みです。それで、ここまではできました。しかし、追加で指示された仕様ができません。それは、「団体区分」に何件の「団体名」が属しているか数えて表示するとの事です。どうすればよいですか?お願いします。

 簡単なのは、アクセスで抽出をしたとき画面下に表れる、データ件数を参照して更新すれば良いのでしょうが、その方法がわかりません。データの件数をカウントする方法があれば教えてください。また、別の方法で簡単なものがあれば提示してください。

PS
 わかりやすく説明してくださいね。

Aベストアンサー

こんにちは。maruru01です。

DCount関数を使ってはどうですか。

コンボボックスのクリックイベントなり、件数表示用のコマンドボタンを用意してそのクリックイベントなりに、表示用コントロール(テキストボックスなりラベルなり)に表示するように、

= DCount("団体名", "(テーブル名)", "団体名 = '" & Me!コンボボックス名.Value & "'")

という風に書けばいいでしょう。
では。

QDB開発

製品管理DBをAccess勉強のために作成しようと思っています。開発経験が無い為、どのような工程で作業を進めていけばいいのでしょうか?
どなたかお詳しい方いらっしゃいましたら、教えて下さい。

Aベストアンサー

DBを使用したいわゆる「ショッピングカート」のCGIを
作成したことのある者です。

#1の方の内容とともに、私がやっていた手法と視点を
挙げてみたいと思います。


・製品に関する情報の項目をひとまず書き並べる。

名称、型番、色や大きさ(縦、横、奥行き)、重さなどの
管理したい情報を細かく気味に書き出します。
そして、開発途中でも気が付いたらすぐに追加していきます。
なのでルーズリーフなどのメモ用紙を活用すると良いでしょう。
また、「あると便利かも」と思いついた管理情報も
記録していくと良いでしょう。
(食品だと「季節ごとに変動する有効期限項目」などがこれにあたります。)


・要求される情報の正確さを明確にする。

販売した時期によって金額が変わったりした場合の対応などについてです。
販売記録を残す場合、「どの金額の時」に「いくつ売れたのか」といった
履歴をのこす時、その履歴情報参照の時にどれだけその情報の量が
要求されるかです。
「その時の販売情報が100%再現できる」場合と
「単純に数量が分かれば良い」場合では
販売記録に対して、上記の商品情報の中で残しておくべき情報量が
変わってくるのが分かると思います。


・操作しやすく、必要な情報は分かりやすく、
 そして適切なメッセージが表示される画面設計。

情報量は多くても、入力するのに必要な項目がどこで、
どんな入力をすればよいのか分かりやすいインターフェースが必要です。
そして入力にエラーがあった時に、そのエラー内容が確実に操作者に伝わり
間違った処理が続行されないようにガードする必要があります。
この部分が不十分だと「数百億規模の損失が発生する場面もある」
というのは記憶に新しいと思います。


・「勉強である」ことを活用する。

勉強であるということは、つまり「仕事ではない」。
手順を守って行う必要が無いということです。
なので、「気が付いた事は手をつけてしまう」のです。
その時に「何に手をつけているのか」、
「何に手をつけなければいけないのに気が付いたのか」を
忘れることなく書き出していくことが大切です。
そうすれば作業をすすめていくうちに
「どんな情報が実は必要となっていくのか」
「どんな点を気にしていれば良いのか」
「どんな例外パターンが発生しそうなのか」
といった必要事項が積み重ねられていくと思います。


ある程度進行していくと、気にしていく項目と
実際の作業進行速度とのギャップで
頭がパンクしそうになるかもしれませんが、
注意すべき点を気にするように「心がけ」ていれば
その経験はしっかりと次に活かされることと思います。
そしてそれがまた次の開発の時のヒントとサンプルに
なってくれることでしょう。

DBを使用したいわゆる「ショッピングカート」のCGIを
作成したことのある者です。

#1の方の内容とともに、私がやっていた手法と視点を
挙げてみたいと思います。


・製品に関する情報の項目をひとまず書き並べる。

名称、型番、色や大きさ(縦、横、奥行き)、重さなどの
管理したい情報を細かく気味に書き出します。
そして、開発途中でも気が付いたらすぐに追加していきます。
なのでルーズリーフなどのメモ用紙を活用すると良いでしょう。
また、「あると便利かも」と思いついた管理情...続きを読む

QAccessを開発するに当たり

開発する人は。
VBAを熟知している人。
修正をする人は、VBAは全く知らない人。

このような状況の場合。
皆様ならどちらを選択しますか?

尚、システムとしては。
・テーブルの更新は、複数あります。
・途中で電源等を切られたくないとか、常識では考えられないような
ことをされないように、制限をする予定です。

このシステムを開発する場合。
1.VBA・SQLをフル活用し、仕様書等で極力VBA・SQLの
知識が乏しくても修正とか、何をしているのか、分かるようにする。

2.VBAの使用は、必要最低限度に押さえ、更新・選択・削除等は、
クエリーで行う。
但し、この場合の開発についても、仕様書を作成し、知識が乏しくても何をしているのか、分かるようにする。

また、
ファイルの大きさに関しても、知りたいです。
1で作成した場合と。2で作成した場合。
データは、空の状態で差があるのか?
もちろん、フォーム数。テーブルの数。インデックスを
貼るのかどうか?
これらによっても、誤差があると思います。
おおよその目安で構いません。
ゴク一般的な意見としてお聞きしたいと思います。

大変に申し訳ありませんが宜しくお願いします。

開発する人は。
VBAを熟知している人。
修正をする人は、VBAは全く知らない人。

このような状況の場合。
皆様ならどちらを選択しますか?

尚、システムとしては。
・テーブルの更新は、複数あります。
・途中で電源等を切られたくないとか、常識では考えられないような
ことをされないように、制限をする予定です。

このシステムを開発する場合。
1.VBA・SQLをフル活用し、仕様書等で極力VBA・SQLの
知識が乏しくても修正とか、何をしているのか、分かるようにする。

2....続きを読む

Aベストアンサー

いちおう、ITでメシ食ってる一人です。

使う人が一人の場合は、Accessでもかまわないと思いますが、複数人で同じDBを共用する場合は、SQLServer Expressを強く推奨します。

フロント画面:アクセス
バックエンド:SQLServer
という構成です。

理由は、Accessの信頼性にあります。
もともとスタンドアロンで利用することを想定されたデータベースソフトであり、複数人で使用する環境でのトラブルは幾度も耳にしているからです。
一方、同じMS製品でも、SQLServerの方が少しは信頼性があります。
一番廉価なExpressでも、基本設計は上位のSQLServerと同じであり、ある程度負荷がかかるような環境にも耐えられるからです。

さて、ご質問の件については、メンテをする人がVBAのスキルがない場合、極力フォームやクエリーだけで運用可能なシステムにするべきでしょう。
VBAを駆使したシステムでは操作性は向上しますが、予期せぬトラブルが発生した場合、対応が難しいからです。

どうしてもPG開発を取り入れたい場合は、仕様書を充実させて、開発した担当者以外のSEやプログラマでも、容易に対応可能な準備を整えるべきかと思います。

いちおう、ITでメシ食ってる一人です。

使う人が一人の場合は、Accessでもかまわないと思いますが、複数人で同じDBを共用する場合は、SQLServer Expressを強く推奨します。

フロント画面:アクセス
バックエンド:SQLServer
という構成です。

理由は、Accessの信頼性にあります。
もともとスタンドアロンで利用することを想定されたデータベースソフトであり、複数人で使用する環境でのトラブルは幾度も耳にしているからです。
一方、同じMS製品でも、SQLServerの方が少しは信頼性があります。
一...続きを読む


人気Q&Aランキング

おすすめ情報