『データベースの正規化等について』（tst） データベース（DB）について 【質問】 １・正規化したほうがよいのか ２・データベースのシート上に関数を入れてよいのか ３・ピポットテーブル参照は辞めたほうが良いのか。 初見で触る人や、引き継ぎの事なども考えて、なるべく単純な形でわかりやすくしておきたい。 どのような方法がベストかご指導ください。 −−−− 【経緯】 毎年、販売者別収支を一括で把握するために収支表を作成していて、全販売員を載せた収支表を作成している。下表 　　　A 　　　　B　　　　　　C　　　D　　　　E　　　F　　　　　　AZ 　　　商品類１　　　　　　　　　　　商品類２　　　　　・・・商品類２０ 氏名　売上　　　原価　　　利益　　　売上　　　原価　　利益　 山田　100　　　30　　　　　70 白石　500　　　150　　　　350 川辺 　・ 　・ 　・ 約900人 これを年度の経緯を評価するため、全年度が入っているデータベース（DB）を作成することにした。 試しに一度作ってから考えようと、DBらしきものを作成したものの、上記の疑問がわき、より単純な形に作り変えた方が良いのかどうか、アドバイスをいただきたい。 −−−− 【試作DBの作成過程】 ［フィールドの決定］ 年度を識別するフィールド（列）を加え、DBに列数はほぼそのままの形式で値貼り付けをして約３年分のDBを作成した。下表 A　　　　　　　B　　　　　　 C　　　　　　 D　　　　　　　E 年度　氏名　　商品類１売上　 商品類１原価　商品類１利益　商品類２売上・・・ 2017　山田　　100　　　　　　30 　　　　　70 2017　白石　　500　　　　　　150　　　　350 2017　川辺 ・ ・ ［計算式の追加］ さらに追加でデータを作成するために、DBに追加でフィールドを作成し、そこに計算式を挿入した。 （例） BA２　　＝C2／B２　・・・原価率 ［ピポットテーブル参照］ さらに、全体集計に対する比率を出したかったのだが、レコードをまたぐ計算式を入力したくなかったので、DSUMやSUMPRODUCTなどは使わず、一度別シートにピポットテーブルで集計表を作成し、そこからの参照の関数を作成した。 ピポットテーブルでの集計を簡単に見られることで、検算の意味合いもあった。 （例） CA２　　＝　ピポットテーブル参照（販管費計÷全人員）／B2　　・・・販管費率 ［完成・課題］ これで思い通りのデータを得られるようになったし、 DBを直接参照してもわかりやすいので、満足いく形になっている。 一方で、安定した構造になっているとは思えないこと、説明無しでは解読が難しいと思われることなどから、今後の蓄積に耐えられるように、より単純な 構造に改善したい。 −−−− 【質問】 １．正規化したほうがいいのか。 　　例えば、売上、原価、利益は正規化してレコード数を増やして、アイテムとして処理する方が良いのかどうか。(列数がデータで70、数式を入れると100列を超える) そうした場合、現在は、同一レコード内（＋ピポットテーブル参照）だけで計算しているが、別レコードを参照する計算式になってしまう。すると、DBを直接参照する際に、フィルターなどをかけると、計算が崩れたりする可能性を 考慮する必要がある。 また、DBを直接参照して、わかりにくくなるような気がする（やってみないとわからない） 今回正規化せずにDB化してみた理由は、 a.DBの直接参照性を優先したこと b.現状年間レコード数が千に満たないので、１０年単位で考えた場合は、わざわざ正規化する必要がないのではないか と考えたから。 ２．そもそもDBに計算式を追加していいのか 　DBに計算式を挿入するのがなんとなく憚られたために、今回の計算式も同一レコード内だけの計算式にしたが、DB内で計算式を入れることは一般的かどうか。重くなったりしないか。今後のDBの追加や引き継ぎ等も含めて、注意点は何かあるか。 ３．ピポットテーブルの参照は続けていいか 　ピポットテーブルで集計値を出して、それを計算式にして戻しているが、 　ピポットテーブルを経由した循環参照になっていると言えるので、なんとなく不安定な構造になっていると感じる。集計値をピポットテーブルで見られるのは便利だが、このまま続けてよいか。 また構造として複雑だが、何かもっとスッキリした方法の提案はないか。 漠然とした質問で申し訳ありませんが、エクセルを使いはじめて日が浅いため、当たり前の事がいまいち理解できていないことがあります。見当違いな点もあるかと思いますが、どうぞご指導ください。 ＜ 使用 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