みんなに優しく、解りやすくをモットーに開設しています。 以下のルールを守りみんなで助け合いましょう。
1.ファイルメーカーで解らない事があればここで質問して下さい。 何方でも、ご質問・ご回答お願いします。 （優しく回答しましょう）
You are not logged in.
Pages: 1
FileMaker Pro Advanced14.0.6
mac OS Sierra 10.12.3
こんにちは。いつもお世話になっております。
データベースの正規化についてご教授ください。
日別の売上を管理するのが目的です。販路ごとの売上と、商品別の広告費があります。
日別の集計が目的なのでユニークキーは日付です。
正規化するのに、広告に関する情報と、売上に関する情報は分けて考えるべきか、同一で考えるべきかわからなくなってしまいました。
トランザクションテーブルは一つにするのが良いと思っていたのですが、図のように広告と売上では趣旨が違うため空欄が多くなります。
https://www.evernote.com/l/AEc9NKWP1udO … EOb3IcwORQ
このままの形の方が良いのか、売上明細と広告明細で分け、日付と商品コードでリレーションした方が良いのか。
結局どっちでもいい問題なのか。。。
こういった場合どのように考えたら良いのかご教授いただけると助かります。
よろしくお願い致します。
Offline
前回の質問から思うことですが、
正規化 ということとは違うように思うのです。
それ以前に、売り上げの管理をご自分でどう処理したいのかを決めることが先ではないかと思います。
これを正規化というのか？わたしにはわかりませんが。
売り上げと広告費は原価管理では最終的に同じ土俵に上がってきますが、
中間的な処理としては
売り上げ自体に直接ではなく関節の分野ではないかと思うのです。
一つの販売のために、それ単独での広告費がかかるのなら、一緒に管理すべき問題で
広告が販売全体にかかるものなら、別々に管理するべきではないかと
わたしの過去の経験から、そんな思いを持っています。
正規化
という言葉に縛られる以前に、
仕事の中でのルール、規則性を見つける
これが正規化と言われたらそうなのかもしれませんが、
言葉に縛られないで
仕事をじっくり見ることが肝要ではないのか
そんなことも思います。
また、生意気と言われかねませんが
大学でプログラム理論の授業の中で
正規化という単語にものすごく違和感を感じてしまったので
それ以来こんな思いを持つようになって言いました。
ご容赦ください。
Offline
シャチさん
いつもご返信ありがとうございます。
正規化というか、効率化したいということですね。
仕事のルール自体は決まっており、データはGoogleスプレッドシートで管理しています。
エクセルにしないのは共同作業を優先しているためです。
収集するデータが多く、かつ毎月データも溜まっていくため、先日スプレッドシートの限界セル数に達してしまいました。
よってやむなくFileMakerで管理しようかと思っているところです。
やむなくというのも、作業自体は相対的にかわってくるため、常にルール変更と隣り合わせなので、スプレッドシートの方が管理が楽なのです。
相対的にわかるというのは、新しい方法の出現や、競合他社の出現などにより、自社のルールも変わるということです。
しかしながら、この作業に関しては半年ほどアップデートを繰り返しながら運用し、そろそろ新しく追加される作業もないように思われるため、データベースに移行しても良いかと感じ、ではやってみようと。
よって、長大なスプレッドシートは存在しますし、ルーチンワークも決定しておりますが、それとデータベースが作れるかということはまた別の問題でして汗
ちなみに今回の場合は、一つの販売のために、それ単独で広告費が発生します。
これは商品毎で、広告キャンペーン毎です。そのためトランザクションテーブルは一つで良い。というのが当初の考えです。
結局好きに作ったら良い。
とはいつも思うのですが、作って作って、何処かのタイミングで更新できなくなるような構造の問題があって、新しく作り直すというのを何回もやっているもので、「正規化」という分割方法を知って、これちゃんとやっとけば後で苦労しないんじゃない？と期待しております。それと、前回の質問いたしましたキーワードを管理するものとは別のファイルです。
Last edited by KR (2017-02-28 10:54:45)
Offline
>正規化というか、効率化したいということですね。
難しい言葉でなく、日常の言葉でいいかと思っています。
>ちなみに今回の場合は、一つの販売のために、それ単独で広告費が発生します。
>これは商品毎で、広告キャンペーン毎です。そのためトランザクションテーブルは一つで良い。というのが当初の考えです。
こういうことならば
１商品１レコードを基本として
発生する金額 収入や費用をポータルで管理されてはいかがかと思います。
Last edited by シャチ (2017-02-28 10:58:50)
Offline
シャチさん
ご返信ありがとうございます。
＞１商品１レコードを基本として
なるほど。日付と商品SKUでユニークにするわけですね。
そして、販売先売上や、広告費用などをポータルで管理すると。
なんかいっぺんに色々解決しました。
ありがとうございます。
売上なんですが、日別で特別に値引きが発生するようなケースがありまして、フィールドを追加して対応は可能なのですが、運用面で忘れないようにするためにはどういった方法がございますか？
スプレッドシートの場合は、表形式であらかじめ日付も入力されているので、入力忘れは回避しやすいです。
こういった場合は、値引きテーブルを作成し、あらかじめ日付とSKUと値引金額を入力しておき、売上のレコードが作成された時点で計算させるという方法でしょうか？
Last edited by KR (2017-02-28 13:18:55)
Offline
前にも書いたように
ポータルを使用すると
日付（どちらかと言えばタイムスタンプ）ごとに１ポータル１データで入力をすることになると思います。
これでいけば、フィールドを追加するという考えで無くなると思います。
表計算からの発送とは根本的に違う部分が多いので
頭の切り替えが必要になることも多いと思います。
>スプレッドシートの場合は、表形式であらかじめ日付も入力されているので、入力忘れは回避しやすいです。
この部分は運用上の問題で
ポータルに入力するときに日付も入れることで解決できるのでは？
とにかく、今一度表計算の考えから抜けて見ませんか？
Last edited by シャチ (2017-02-28 14:05:38)
Offline
シャチさん
ご返信ありがとうございます。
＞ポータルに入力するときに日付も入れることで解決できるのでは？
ちょっと情報不足でした。
値引きに関しては、当日決まるわけではなく、最低30日以上前に予算を決定します。リベートというのですが、販売個数に応じて値引き金額が決まります。100円のリベート設定で、1日に10個売れれば、その日は1000円の値引きとなります。これをオペレーターには入力させたくありませんし、30日以上前に決まったデータを目視で参照しながら入力するのもダメです。
よって
値引きテーブル or 価格テーブルで（この辺の名称はどっちでもいいんですが）
リベートを実施する日程が決まったときにその日程を入力しておくテーブルがあれば
売上データを入力するときに参照し、計算が可能なのでこういった方法かなと。
5日〜7日までセールを行うイメージ
https://www.evernote.com/l/AEemPdq5m4VH … 4rbsMV73TI
価格に関しても前月までに予算として販売価格を決定しますので、価格明細テーブルは前月までに翌月分を確定
日々の入力テーブルは日別明細に行い、他の明細はポータルで管理。
スプレッドシート的な思考なことも、転換が必要なこともわかっているつもりなのですが、かといっていきなり転換できるわけでもなく。。。なので鍛えていただけると助かります。
前段階で、予算やらイベントやらリベートやら、色々決めるので、それらを忘れず運用していくにはどうしたら良いかといった感じです。
Last edited by KR (2017-02-28 15:12:07)
Offline
参考画像見ました。
データベース構造になってますね。
EXCELにもデータベース機能があるので、そのまま使えるんですがGoogleは知らないからなぁ・・・
このままをとりあえず作ってみるのも一考かと思います。
今、横に並んでいる表計算でいうタイトルをそのままフィールドとして作ります。
そうすれば、表形式で表示するとほとんど同じになります。
あとは、
検索をすることで、纏めができるようになります。
ここでまでがFMPの入門です。
簡単に、こうなります というレベルのファイルを
http://yahoo.jp/box/ccK5Nf
にアップしました。
ただ、わたしの提案したことはちょっと違っていて
販売品目別にしたデータの作り方で
１品目１レコードで
そのレコードの中に 関連テーブルのポータルを置いて
その中に販売日、販売先、販売金額などなどを入力します。
これが、FMPのリレーションを使ったデータ構造で
この先はとにかく応用がきくことになります。
ただ、一番心配するのは
運用に入って、実際にお使いになる方が
表計算から、移行ができるかという実践的な問題がな起こります。
これは、製作者が説得に当たらねばならないので、
完璧にシステムを理解する必要も出てきます。
とにかく
基本的なFMPの仕組みを理解した上で
実際の仕事の構築をされることをお勧めします。
Offline
ごめんなさい、参考図を読み違えていた
難しい事案だなぁ と、今思います。
同じ品目で取引先ごとに販売価格が違う
これは計算の時になんとかなるけど
https://fm-aid.com/bbs2/viewtopic.php?id=6041
が参考になる話かと思います。
販売明細と価格明細の関連がちょっと理解できていないわたしです。
基本的には
販売明細を作るのですが
その入力をわたしの提案するポータル方式を使う
集計はポータルの中の明細を使って集計という流れになるだろうと。
この先、アドバイスできるかどうか。。。期待はしないでください。
Offline
販売明細と価格明細の関連がちょっと理解できていないわたしです。
業務形態が特殊かもしれません。販売価格は前月までに決めてセールを実施しますので、商品の単価は販売先ごとに日別で管理しています。販売価格を事前決定で日別に管理する業務形態はあまりないと思います。
この部分は、日付、SKU、販売先ID、の3つでトリプルキーにして単価と値引き価格を引っ張ってきて処理しようと思います。
ファイルメーカー無事移行できたら、この部分のデータはエクセル管理法が楽なんですが、エクセルからデータ参照っていうのは出来るんでしょうか？
使ったことはありませんが、エクセルのメニューにはアクセスとの連携機能などがあるようだったので、ファイルメーカーにもあったら楽だなぁと思いました。ググりましたがわからず。。。
運用面のご心配ありがとうございます。
システムは私が作りますし、入力項目自体を減らせば、おそらく問題ないかと。
Last edited by KR (2017-02-28 19:52:38)
Offline
確かに特殊すぎる。
参考画面の３つの表の関係が全くわからない。
どれが元データなのか？
多分に「販売明細」かと思うのですが、
これから「日別明細」は簡単
だけど「価格明細」の元データがどこになるのか？
謎だなぁ。。。。
>この部分は、日付、SKU、販売先ID、の3つでトリプルキーにして単価と値引き価格を引っ張ってきて処理しようと思います。
まぁこれはリレーションさえ理解されれば問題はないわけで。
それにしても
昔、かなり難しい仕事のお手伝いしたことあるけど、
理解するまでかなり時間かかったことがある。
その業界の理解も含めてだったので。
そんなことが頭をよぎりました。
Offline
確かに特殊すぎる。
参考画面の３つの表の関係が全くわからない。
どれが元データなのか？
すみませぬ！
この場合、元データは驚きの日別明細です。
日別で収支を確認し、日付の絞り込みで月次を、SKUの絞り込みで単品別を。日付が主役なのです。
Offline
あの画像からは、無理デスゥ
多分、表計算の持つデータベース機能で絞り込みと想像します。
その考えを、そのままFMPに置き換えるだけだとは思うのですが
機能が全く違うので
まずは、基本機能を知った方が話は早いと思うのですが。。
Offline
たびたびすみませぬ
画像のやつですが、日別明細を主役で日付を主キーにするつもりでしたが、そもそも破綻してたので、シャチさんのアドバイス通り、商品SKUを主キーにして販売明細をポータルで。日別明細は無しで作って見ます。
やっとなんとなくできそうな気がします。
こう、基本構造っていうのが理解できると早いんですが
一番ポイントですよね。
Offline
売上だけを1テーブル、広告を1テーブル、その間は何らかのリレーションを張っておく、
というだけで良いのでは。広告は、1対1で売上に紐づいているのですよね。それは、関連レコードとして表示させれば良いでしょう。日次や月次集計、SKU集計は、そのまま行えば良いでしょうね。
Offline
色々考えてみたけど 原点回帰で
販売明細をメインで入力してと
それをどうまとめていくか、
またリレーションで画面にどう表示するか
そんなことを参考画面のデータをもとにいじって
にしてみました。
ただ、仕事の内容知らないので
多分使い物にしていくべきもではなく
あくまでもFMPはこんなものという面で見てください。
Offline
シャチさん。
丁寧なサンプルファイル、ありがとうございます！
あの後色々やって見まして、画像の通りではうまくはいきませんでした。
しかし、おかげさまでポータルに関してはだいぶ理解を深めることが出来ました。
仰る通り、販売明細をメインにするか、もう一個上の階層を作るかというところで試行錯誤しています。
今の感じですと、販売明細の一つ上に販売管理のテーブルを作成し、販売IDというユニークキーを追加すれば対応できるかな。という感じになりました。
実際にオペレーションするときのことも考えると、色々考えることがあるのですね。
本当は作って見たサンプルをあげて見てもらいたいところですが、まだ未完成部分が多く、かつなかなか時間も取れないため、ちょっとゆっくりめに頑張ってみようと思います。
いつもご回答いただき、本当にありがとうございます。
Offline
Pages: 1
[ Generated in 0.006 seconds, 7 queries executed - Memory usage: 620.18 KiB (Peak: 653.09 KiB) ]