advanced help
per page, with , order by , clip by
Results of 1 - 1 of about 2422 for ピボットテーブル (0.004 sec.)
[[20170820065624]]
#score: 4769
@digest: 4251975d07a12a6e315a251ab78e8e0a
@id: 74215
@mdate: 2017-08-25T01:46:51Z
@size: 6672
@type: text/plain
#keywords: 品類 (56043), 規化 (49953), rdbms (13013), 正規 (9982), ピポ (9100), 、db (8972), 一レ (8062), 接参 (7865), にdb (7757), 類1 (7480), ポッ (6269), 収支 (5742), 原価 (4796), ド数 (4327), トテ (3999), レコ (3812), 利益 (3666), db (3447), ーブ (3082), テー (2998), 構造 (2631), ブル (2313), ル参 (2241), 商品 (2160), タベ (2135), 算式 (1699), 年度 (1527), ベー (1487), 売上 (1428), ット (1408), ド内 (1380), 集計 (1364)
『データベースの正規化等について』(tst)
データベース(DB)について 【質問】 1・正規化したほうがよいのか 2・データベースのシート上に関数を入れてよいのか 3・ピポットテーブル参照は辞めたほうが良いのか。 初見で触る人や、引き継ぎの事なども考えて、なるべく単純な形でわかりやすくしておきたい。 どのような方法がベストかご指導ください。 ---- 【経緯】 毎年、販売者別収支を一括で把握するために収支表を作成していて、全販売員を載せた収支表を作成している。下表 A B C D E F AZ 商品類1 商品類2 ・・・商品類20 氏名 売上 原価 利益 売上 原価 利益 山田 100 30 70 白石 500 150 350 川辺 ・ ・ ・ 約900人 これを年度の経緯を評価するため、全年度が入っているデータベース(DB)を作成することにした。 試しに一度作ってから考えようと、DBらしきものを作成したものの、上記の疑問がわき、より単純な形に作り変えた方が良いのかどうか、アドバイスをいただきたい。 ---- 【試作DBの作成過程】 [フィールドの決定] 年度を識別するフィールド(列)を加え、DBに列数はほぼそのままの形式で値貼り付けをして約3年分のDBを作成した。下表 A B C D E 年度 氏名 商品類1売上 商品類1原価 商品類1利益 商品類2売上・・・ 2017 山田 100 30 70 2017 白石 500 150 350 2017 川辺 ・ ・ [計算式の追加] さらに追加でデータを作成するために、DBに追加でフィールドを作成し、そこに計算式を挿入した。 (例) BA2 =C2/B2 ・・・原価率 [ピポットテーブル参照] さらに、全体集計に対する比率を出したかったのだが、レコードをまたぐ計算式を入力したくなかったので、DSUMやSUMPRODUCTなどは使わず、一度別シートにピポットテーブルで集計表を作成し、そこからの参照の関数を作成した。 ピポットテーブルでの集計を簡単に見られることで、検算の意味合いもあった。 (例) CA2 = ピポットテーブル参照(販管費計÷全人員)/B2 ・・・販管費率 [完成・課題] これで思い通りのデータを得られるようになったし、 DBを直接参照してもわかりやすいので、満足いく形になっている。 一方で、安定した構造になっているとは思えないこと、説明無しでは解読が難しいと思われることなどから、今後の蓄積に耐えられるように、より単純な 構造に改善したい。 ---- 【質問】 1.正規化したほうがいいのか。 例えば、売上、原価、利益は正規化してレコード数を増やして、アイテムとして処理する方が良いのかどうか。(列数がデータで70、数式を入れると100列を超える) そうした場合、現在は、同一レコード内(+ピポットテーブル参照)だけで計算しているが、別レコードを参照する計算式になってしまう。すると、DBを直接参照する際に、フィルターなどをかけると、計算が崩れたりする可能性を 考慮する必要がある。 また、DBを直接参照して、わかりにくくなるような気がする(やってみないとわからない) 今回正規化せずにDB化してみた理由は、 a.DBの直接参照性を優先したこと b.現状年間レコード数が千に満たないので、10年単位で考えた場合は、わざわざ正規化する必要がないのではないか と考えたから。 2.そもそもDBに計算式を追加していいのか DBに計算式を挿入するのがなんとなく憚られたために、今回の計算式も同一レコード内だけの計算式にしたが、DB内で計算式を入れることは一般的かどうか。重くなったりしないか。今後のDBの追加や引き継ぎ等も含めて、注意点は何かあるか。 3.ピポットテーブルの参照は続けていいか ピポットテーブルで集計値を出して、それを計算式にして戻しているが、 ピポットテーブルを経由した循環参照になっていると言えるので、なんとなく不安定な構造になっていると感じる。集計値をピポットテーブルで見られるのは便利だが、このまま続けてよいか。 また構造として複雑だが、何かもっとスッキリした方法の提案はないか。 漠然とした質問で申し訳ありませんが、エクセルを使いはじめて日が浅いため、当たり前の事がいまいち理解できていないことがあります。見当違いな点もあるかと思いますが、どうぞご指導ください。 < 使用 Excel:Excel2010、使用 OS:Windows8 > ---------------- 初質問マーク?が付いてなかったので、-を-に変更。 その際、左に半角スペースを追加。 スレ主の初投稿時間 2017/08/20(日)09:32 BJ 2017/08/20 13:05 ---- 一般にDBとは、RDBMSを指しますが、ご質問のキーワードから判断すると、DB=Excelの1シート、と考えているように見えます。いかがですか?(ピボットテーブルは対象がシートなので、これに言及するということは、RDBMSを知らないのでは?、と思えます) DBと呼ぶのであれば、70列もある大きなテーブルであれば、正規化を考えるのは当たり前です(レコード数と正規化は関係なく、 列数の方が重要です)。 ただし、現在1テーブルだけで用が足りているならば、あえて完全に正規化せず、冗長性を持ったままでも良いかも知れません。 何でもかんでも完全正規化するのではなく、登録のしやすさ、利用のしやすさや速度性能を考え、あえて冗長性を残すというのも、DB設計では当たり前の事です。 その判断は、データ内容によるので、漠然と正規化すべきか、だけ聞かれても、答えようがありませんよ。 正規化すべきかどうかの判断は、例えば社員番号や顧客番号、商品番号と商品情報、商品類と商品番号の関係等、情報を分けて考えたほうが入力処理と集計、出力がすっきりするとか、それぞれのテーブル更新が簡単になるかどうか、という事を考慮して決めてください。 (???) 2017/08/21(月) 09:14 ---- コメントありがとうございます。 まず、DBについて、おっしゃる通りの認識でごさいます。 ただここはエクセルの学校ですし、一般にDBと言ってRDBMSの事だとは思いませんでした。 より広義でのただのデータの蓄積とお考えください。 さて、ご返事を読むにつれて、結局はデータの使いやすさを決めるのは使う本人(=自分)だということがわかり、自分の中でも疑問が整理された気持ちでおります。 私としては「形式を変えてしまった場合の、ピポットテーブルの使い勝手」を知りたかったのだとわかりました。また、それもつまるところ自分でやってみないとわからないだろう、というなんとも赤面する示唆を頂いたような気がしております。試しにいろいろやってみて形を決定していこうと思います。 アドバイスありがとうございました。 (tst) 2017/08/24(木) 19:05 ---- DB設計はデータ次第なのだから、関係する人自身でないと判らない、という認識で正しいです。 ピボットについて意見すると、ピボットはちょっとしたデータ集計、特にDBではクロス集計という少し高度なSQL文を書かないと実現できないようなことを、簡単なドラッグ&ドロップで実現できてしまうので、とても便利です。命令を調べる必要がないので、SQL文やマクロの知識が無い人でも、DB集計できてしまうわけです。 ただ、商品流通の管理となってくると、データ量が膨大であり、しかも列の数が増えてくると、処理時間もかかってきます。ピボットはあくまでも簡易集計と捉えて、ちゃんとしたRDBMSへの移行を考えてみても良いかもです。(データベースに詳しいソフトウェア技術者を雇うか、依頼するのがお薦め) 詳しい人に実際の情報を見せれば、どういうテーブル構成にするのが適切なのか等、的確なアドバイスが得られると思いますよ。 (???) 2017/08/25(金) 10:46 ...
https://www.excel.studio-kazu.jp/wiki/kazuwiki/201708/20170820065624.txt - [detail] - similar
PREV NEXT
Powered by Hyper Estraier 1.4.13, with 97059 documents and 608315 words.

訪問者:カウンタValid HTML 4.01 Transitional