桐質問掲示板 [One Topic All View / Re[3]: フォームを作りたい / Page: 0]

(現在過去ログ76 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■11500 / inTopicNo.1)

　フォームを作りたい

□投稿者/ ド初心者 -(2018/10/18(Thu) 09:43:00)

桐10 ﾋﾞﾙﾄﾞ#2238を使用しています。
サンプルとしてtest1.TBXを添付しています。


例えば、このサンプルtest1.tbxでデータで001を編集するときには、


	地区01	地区02　地区03	地区04	地区05	地区06	地区18
001	　　1	　　4	　　6　　　4	　2	　37	　32

となり、次のレコード002を編集すると、


	地区02	地区18
002	　　3	　 54


と表示され、さらに次のレコード003へ編集を動かすと、



	地区01	地区03	地区05	地区08	地区09	地区10
003	　2	　※5	　※19	 ※108	　34	　689



のように、要はデータのある地区だけが表示されるようなフォームを
作りたいのですが、どうしたらよいのかわかりません。

ご教示をよろしくお願い申し上げます。

1539823380.zip/62KB

引用返信 [メール受信/OFF] 削除キー/

■11502 / inTopicNo.2)

　Re[1]: フォームを作りたい

▲▼■

□投稿者/ 悲しげ -(2018/10/18(Thu) 22:37:22)

■No11500に返信(ド初心者さんの記事)

まず「…を編集するとき」の「編集」の意味がよく判りませんが、
「フォームで表示させて訂正入力等なんらかの処理をするとき」
のような意味ですよね？

それと「※108」の「※」の意味するところもよく判りません。
全体に数値系のデータ型だと思われるので、このように文字列が
入ってくると扱いがややこしくなるような気がします。
「※」的なところは何か別な工夫をしてみる。例えば「1000108」
とか「0.000108」とか「-108」とか、あるいは何らかのフラグ
を設けて文字色や背景色を変えてみるとか。

さて、このようなデータ構造は、いかにもワープロとかエクセルっ
ぽくて、およそデータベース処理には向かないように思えます。

趣旨が違うのかもしれないが、私なら次のようなデータ構造として
試してみるかもしれません。

商品番号　地区　値(数値)　flag(文字列)
-------------------------
001 地区01 1
001 地区02 4
・・・・・・
001 地区18 32
002 地区01 3
002 地区18 32
003 地区01 2
003 地区03 5 ※
003 地区09 34
003 地区10 689
・・・・・・

で、フォームとしてはグループ項目のある一覧表とし、[商品番号]を
ヘッダのグループ項目とする。
そして例えば「グループ移動」イベントとかで、[地区]か[値]が入力
済みのデータだけを絞り込み表示させるとか。

この辺りは、そもそも何のために必要なのか次第なので。

引用返信 [メール受信/OFF] 削除キー/

■11503 / inTopicNo.3)

　Re[1]: フォームを作りたい

▲▼■

□投稿者/ ねむねむ -(2018/10/19(Fri) 09:20:26)

■No11500に返信(ド初心者さんの記事)
> 桐10 ﾋﾞﾙﾄﾞ#2238を使用しています。
>
> 例えば、このサンプルtest1.tbxでデータで001を編集するときには、
>
地区01 地区02　地区03 地区04 地区05 地区06 地区18
>001 　　1 　　4 　　6　　　4 　2 　37 　32
>
>となり、次のレコード002を編集すると、
>
>
> 地区02 地区18
>002 　　3 　 54
>
> のように、要はデータのある地区だけが表示されるようなフォームを
> 作りたいのですが、どうしたらよいのかわかりません。
>
> ご教示をよろしくお願い申し上げます。

例えば、002を編集するとき、地区03にデータを入力しようとした場合、
表示されていないと編集出来ないのではないでしょうか。それとも表示のみで
編集はしないのでしょうか？

引用返信 [メール受信/OFF] 削除キー/

■11504 / inTopicNo.4)

　Re[2]: フォームを作りたい

▲▼■

□投稿者/ ド初心者 -(2018/10/19(Fri) 11:29:52)

■No11503に返信(ねむねむさんの記事)
> ■No11500に返信(ド初心者さんの記事)
>>桐10 ﾋﾞﾙﾄﾞ#2238を使用しています。
>>
>>例えば、このサンプルtest1.tbxでデータで001を編集するときには、
> >
> 地区01 地区02　地区03 地区04 地区05 地区06 地区18
> >001 　　1 　　4 　　6　　　4 　2 　37 　32
> >
> >となり、次のレコード002を編集すると、
> >
> >
> > 地区02 地区18
> >002 　　3 　 54
> >
>>のように、要はデータのある地区だけが表示されるようなフォームを
>>作りたいのですが、どうしたらよいのかわかりません。
>>
>>ご教示をよろしくお願い申し上げます。
>
> 例えば、002を編集するとき、地区03にデータを入力しようとした場合、
> 表示されていないと編集出来ないのではないでしょうか。それとも表示のみで
> 編集はしないのでしょうか？

質問が曖昧ですいません。
データのない部分は編集できない方針です。
データのある列のみ表示していればよい、という考えです。
この例では10列程度ですが、実際に作りたいテーブルでは200列以上あります。
データある列は、値をできれば文字列で編集できるようにしたいのです。
よろしくお願い申し上げます。

引用返信 [メール受信/OFF] 削除キー/

■11505 / inTopicNo.5)

　Re[2]: フォームを作りたい

▲▼■

□投稿者/ ド初心者 -(2018/10/19(Fri) 11:31:42)

■No11502に返信(悲しげさんの記事)
> ■No11500に返信(ド初心者さんの記事)
>
> まず「…を編集するとき」の「編集」の意味がよく判りませんが、
> 「フォームで表示させて訂正入力等なんらかの処理をするとき」
> のような意味ですよね？
>
> それと「※108」の「※」の意味するところもよく判りません。
> 全体に数値系のデータ型だと思われるので、このように文字列が
> 入ってくると扱いがややこしくなるような気がします。
> 「※」的なところは何か別な工夫をしてみる。例えば「1000108」
> とか「0.000108」とか「-108」とか、あるいは何らかのフラグ
> を設けて文字色や背景色を変えてみるとか。
>
> さて、このようなデータ構造は、いかにもワープロとかエクセルっ
> ぽくて、およそデータベース処理には向かないように思えます。
>
> 趣旨が違うのかもしれないが、私なら次のようなデータ構造として
> 試してみるかもしれません。
>
> 商品番号　地区　値(数値)　flag(文字列)
> -------------------------
> 001 地区01 1
> 001 地区02 4
> ・・・・・・
> 001 地区18 32
> 002 地区01 3
> 002 地区18 32
> 003 地区01 2
> 003 地区03 5 ※
> 003 地区09 34
> 003 地区10 689
> ・・・・・・
>
> で、フォームとしてはグループ項目のある一覧表とし、[商品番号]を
> ヘッダのグループ項目とする。
> そして例えば「グループ移動」イベントとかで、[地区]か[値]が入力
> 済みのデータだけを絞り込み表示させるとか。
>
> この辺りは、そもそも何のために必要なのか次第なので。
>

悲しげ様、ご教示をありがとうございます。
でも、すいません、テーブル構成自体は、私が決められないので、これはどうしようもありません。
要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。
何か良い知恵がありましたら、ご教示をよろしくお願い申し上げます。

引用返信 [メール受信/OFF] 削除キー/

■11506 / inTopicNo.6)

　Re[1]: フォームを作りたい

▲▼■

□投稿者/ ONnoji -(2018/10/19(Fri) 13:02:05)

2018/10/19(Fri) 13:09:17 編集(投稿者)

ポイントをまとめると
>
> ・列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。
> ・データのある列のみ表示していればよい、という考えです。
>
ですね。

ということは、次のような発想なんですね。

　逐一スクロールしてデータをメンテナンスするのが大変
　　↓
　解決策として
　　↓
　データのある列のみ表示していればよい

でも、↑上の「データのある列のみ表示していればよい」って言うのは簡単だけれど、ほぼ不可能なんですよ。

そこで、代案を２つ示します。

＜Ａ案＞

　逐一スクロールしてデータをメンテナンスするのが大変
　　↓
　解決策として
　　↓
　表形式のフォームのコマンドボタン［←前の項目］［次の項目→］を実行すると、データがある項目へジャンプする

↑これならば、実現可能でしょう。

＜Ｂ案＞

　逐一スクロールしてデータをメンテナンスするのが大変
　　↓
　解決策として
　　↓
　表形式のフォームのコマンドボタンを実行すると、データを表示するフォームをモーダルで開く

↑これならば、実現可能でしょうけれど、Ａ案の方がはるかに簡単です。

以上、こんなところですかね。

しかし、Ａ案でも、Ｂ案でも、実装するのは非常に大変ですよ。

よってサンプルの提示はいたしません。悪しからず。

ｐ．ｓ．

ちなみに、2018/08/06(Mon)の

一括処理の定義の仕方　□投稿者/ 桐ド初心 -(2018/08/06(Mon) 16:45:28

の投稿は解決したのでしょうか？

あのスレッドは、尻切れトンボのままなので、解決しない場合でも、なんらかの締めを入れてください。

引用返信 [メール受信/OFF] 削除キー/

■11507 / inTopicNo.7)

　Re[2]: フォームを作りたい

▲▼■

□投稿者/ ド初心者 -(2018/10/19(Fri) 13:32:29)

■No11506に返信(ONnojiさんの記事)
> しかし、Ａ案でも、Ｂ案でも、実装するのは非常に大変ですよ。
>
> よってサンプルの提示はいたしません。悪しからず。
>

そうなんですかぁ。じゃあ、このレスも未解決になります。(^^;;;;;
だって解決していないんです。前のレスも。
桐っていい本とかがないんですよね。

引用返信 [メール受信/OFF] 削除キー/

■11508 / inTopicNo.8)

　Re[3]: フォームを作りたい

▲▼■

□投稿者/ ONnoji -(2018/10/19(Fri) 20:27:41)

2018/10/20(Sat) 11:55:38 編集(投稿者)
2018/10/20(Sat) 11:21:36 編集(投稿者)
2018/10/20(Sat) 08:35:10 編集(投稿者)
2018/10/20(Sat) 07:47:56 編集(投稿者)
2018/10/19(Fri) 21:26:41 編集(投稿者)
2018/10/19(Fri) 21:16:23 編集(投稿者)

>>しかし、Ａ案でも、Ｂ案でも、実装するのは非常に大変ですよ。

まず、「データのある列のみ表示していればよい、という考えです」ですが、

これって、ひょっとして、エクセルのフォームの話ではありませんか？？

もしも、そうならば、エクセルのよくわかる人に尋ねてください。

>>よってサンプルの提示はいたしません。悪しからず。

簡単なサンプルならば直ちに提示できますが、いかんせん非常に込み入ったプログラムになると予想します。

なので、

・当方は多忙で余裕が全くありません
・仮にサンプルを提示しても、そちらの現場に応用できるか不明

↑このふたつの理由から、サンプルを提示出来ません。

> そうなんですかぁ。じゃあ、このレスも未解決になります。(^^;;;;;

このスレッドには、私の他にも参加者がいますから、未解決になるか否かを判断するのは時期尚早です。

> だって解決していないんです。前のレスも。

あれは２ヶ月以上も前の投稿ですから、すでに賞味期限切れですよ。改めてスレッドを立ててください。

あまりにも、貴殿が無反応でしたから、私のレスを削除しようと思ったくらいですよ。

解決しなければ、「諦めました」でも「別ツリーで新規に質問し直します」でもＯＫです。

まずは、尻切れトンボのスレッドに、〆（締め）の返信投稿をして、スレッドの完結をしてください。

それは、この掲示板に質問者した人の最低限守るべきマナーですよ。

> 桐っていい本とかがないんですよね。

私の個人的な意見ですが、インターネットが普及したので、いわゆるコンピュータ本は、出版社が出版を手控える状況で、今後も変わらないと思いますよ。

引用返信 [メール受信/OFF] 削除キー/

■11509 / inTopicNo.9)

　Re[1]: フォームを作りたい

▲▼■

□投稿者/ Sai -(2018/10/20(Sat) 00:23:15)

■No11500に返信(ド初心者さんの記事)

> 要はデータのある地区だけが表示されるようなフォームを
> 作りたいのですが、どうしたらよいのかわかりません。

ではなくて

> 要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。

ということでしたら

メンテ用にカード型フォームを設定するのはいかがですか。
例えば２０行×１０列で２００項目（列）表示できますね。

最近はディスプレイ（解像度）も大きくなっていることですし。

引用返信 [メール受信/OFF] 削除キー/

■11511 / inTopicNo.10)

　Re[3]: フォームを作りたい

▲▼■

□投稿者/ 悲しげ -(2018/10/20(Sat) 00:36:37)

■No11505に返信(ド初心者さんの記事)
>でも、すいません、テーブル構成自体は、私が決められないので、これはどうしようもありません。
>要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。

解決への一番の近道は、テーブル構成自体を「正規な形」に変えることです。
云い換えれば、そのように「決定権のある人」を説得することです。

「正規な形」ってのは、俗っぽく言えば「横のものを縦に」です。(例えばNo11502や後述のような)。

*

ところで「データをメンテナンスする」って何をやるんですか？
例えば、「毎日」または定期的な「或る日」に
「商品001」について、「地区01」の値を変更入力し、「地区02」の値を変更入力し、「地区03」・・・・
次に
「商品002」について、「地区01」の値を変更入力し、「地区02」の値を変更入力し、「地区03」・・・・
（いや「商品002」は「地区03」と「地区06」と「地区091」・・・なのかもしれない）
「商品003」について・・・・・
・・・・・・

とすれば、私なら入力作業用のフォームを用意して
(1)商品番号を指定し
　(商品.tbxから選ぶ)
(2)地区を指定し
　(地区番号.tbxから選ぶ)
(3)必要な数字を入力し
(0)でも最初に入力年月日とか伝票番号を入力するのが先かな？

そしてその結果を「何らかの方法で」マスター的な表に転記する。
この方法は幾らでもあるはずです（表の構成がまともでさえあれば）。
例えば、表の構成がお示しのような「まともじゃない」(^^;)場合でさえも
[商品番号]項目で指定された商品番号値のレコードを検索して、
指定の地区番号項目で、入力された数字(的文字列)に「行訂正」する。

*

仮に商品の種類が50で、地区が200あるのなら
商品を横に、地区を縦にする方がよいかもしれない。
それでも私ならそんなエクセルみたいな表は作りたくない。

*

ありうる（まともな）台帳的tbxの形

伝番　　年月日　商品番号　(商品名)　地区番号　数量　備考
0001　2018/01/20　001　　○○○○　　018　　　　8
0002　2018/01/20　007　　××××　　123　　　　5　　※
・・・・・
0072　2018/01/21　033　　▽▽▽▽　　005　　　109
・・・・・

横（項目）はせいぜい10～20くらいで
縦は無限大的に。(^^)v

このような形ならば、検索も絞り込みも集計も印刷も・・・諸々自由自在。

って、キリがないのでやめます(^^;)

ps.
引用は、全文ではなく、必要最小限に願います。

引用返信 [メール受信/OFF] 削除キー/

■11514 / inTopicNo.11)

　Re[1]: 悲しげさん江

▲▼■

□投稿者/ ONnoji -(2018/10/20(Sat) 13:11:40)

2018/10/20(Sat) 13:20:20 編集(投稿者)
2018/10/20(Sat) 13:16:33 編集(投稿者)

悲しげさん江

寄り道の話なので、遠いところに投稿しました。

ちょっと以下を読んでみて下さい。

> >でも、すいません、テーブル構成自体は、私が決められないので、これはどうしようもありません。
> >要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。
>
> 解決への一番の近道は、テーブル構成自体を「正規な形」に変えることです。
> 云い換えれば、そのように「決定権のある人」を説得することです。
>
> 「正規な形」ってのは、俗っぽく言えば「横のものを縦に」です。(例えばNo11502や後述のような)。

項目数が２００個以上ってどんなデータなんでしょうかね。

ひょっとすると、トランザクションデータではなくて、マスタデータなのかもしれませんね。

そもそも、トランザクションデータならば、変更の必要がないですからね。

変更しちゃったら、過去を書き換えることになっちゃう。

となると、マスタデータということになる。

しかし、未定義値が沢山あるマスタデータのようだから、あまり見かけないタイプなんでしょうね。

｛物品名,配置先１,配置先２,配置先３, ･･･配置先ｎ｝

例えば、物品マスタデータ、つまり配置表です。

※後述のように単なるトランザクションデータからのアウトプットで、本来の意味のマスタデータでは無いと思いますが…

　物品名　　　Ａ町　　　Ｂ町　　　　
　消火器Ａ　１０個　　１０個　･･･
　バケツ　　１０個　　１０個　･･･
　乾パン　　１０個　　１０個　･･･

こんなデータなのかな？　この例は、防災備品の想定だけどアリガチかな。

でも、物品配置の記録、つまりトランザクションデータもあるでしょう。

日付　　　　物品名　　数量　消費期限　　配置先　
yyyy-mm-dd　消火器Ａ　１０　yyyy-mm-dd　Ａ町
yyyy-mm-dd　消火器Ａ　１０　yyyy-mm-dd　Ｂ町
yyyy-mm-dd　バケツ　　１０　yyyy-mm-dd　Ａ町
yyyy-mm-dd　バケツ　　１０　yyyy-mm-dd　Ｂ町
yyyy-mm-dd　乾パン　　１０　yyyy-mm-dd　Ａ町
yyyy-mm-dd　乾パン　　１０　yyyy-mm-dd　Ｂ町
　：　　　　　：　　　　：　　：　　　　　：
　：　　　　　：　　　　：　　：　　　　　：
　：　　　　　：　　　　：　　：　　　　　：
　：　　　　　：　　　　：　　：　　　　　：

こういうトランザクションデータを用意して、マスタデータを併合するというのがマトモナ運用方法なのでしょうね。

※そもそも、単なる配置表が必要ならば、トランザクションデータの消費期限内の物品データを使って、配置表を出力すれば良いだけでしょうね。

しかし、トランザクションデータを使わずに、マスタデータを人力手動でメンテナンスする。

だから、オペレーションする人間が疲弊する。

こんなストーリーなのかもしれませんね。

全部タラレバですけどね。(^^ゞ

引用返信 [メール受信/OFF] 削除キー/

■11517 / inTopicNo.12)

　Re[2]: 悲しげさん江

▲▼■

□投稿者/ ONnoji -(2018/10/21(Sun) 10:05:58)

2018/10/21(Sun) 10:10:05 編集(投稿者)
2018/10/21(Sun) 10:08:47 編集(投稿者)

タラレバの続きです。

分かったような気がします。

>要は列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。

↑これって異常でしょ。もしも、そう思わない人はコンピュータ音痴ですよ。

これって、神エクセルと同じ。つまり、コンピュータ音痴の方法論ですね。キッパリ。

　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇　◇

データベースの場合には、

　取引などの事象
　　↓
　入力原票（いわゆる伝票類のこと）
　　↓
　キーボード等による入力作業
　　↓
　データ登録　←　参照：入力支援（各種マスタファイル）
　　↓　　　　　　※注意：トランザクションデータはマスタデータとリレーションしないこと
　　↓
　作業ファイル（日時更新・月次更新などで用いる）
　　↓
　　↓
　トランザクションファイル

↑上のような流れになるハズです。

そして、「列が200列以上あって、逐一スクロールしてデータをメンテナンスするのが大変な」表は、

　トランザクションファイル
　　↓
　有効データに絞り込み
　　↓
　配置表を出力　※作成方法はいろいろあるが、縦横変換なので、（何度も説明してきたように）結合表は使えない　

↑このように、トランザクションファイルから導出されるファイルなのです。

だから、マスタファイルではありません。

そして、そもそも導出ファイルなのですから、物品の種類が増えても対応できますし、数量の変更にも対応できます。

こうするべきだったのです。※「ブランド売るならブランディア」みたいな。

ところが、ぎっちょんちょん、悲しいかな神エクセルです。

作業が大変ですし、間違えもあるでしょう。

そして、何よりもオペレータがコンピュータの奴隷のようにコキ使われてしまいます。

それでは駄目なんです。

オペレータが楽に操作して、コンピュータを支配しているようなフィーリングを持たせることが大事なんです。

これというのも、すべて「神エクセルしか知らない無知」の産物なんですね。

全部タラレバですよ。(^^ゞ

引用返信 [メール受信/OFF] 削除キー/

■11518 / inTopicNo.13)

　Re[3]: フォームを作りたい

▲▼■

□投稿者/ 尾形 -(2018/10/21(Sun) 11:47:40)

どうも、こんにちは

表形式で項目幅を小さくして、全項目画面に収めて

表示(V) → 拡張編集(V)
じゃダメかな

引用返信 [メール受信/OFF] 削除キー/

■11519 / inTopicNo.14)

　Re[2]: 悲しげさん江

▲▼■

□投稿者/ 悲しげ -(2018/10/21(Sun) 17:15:03)

■No11514に返信(ONnojiさんの記事)

寄り道コメントへの質問です(^^;)

ところでここで言う「トランザクション」の意味というか、
「マスターとトランザクション」の違いについて、ざっくりと
教えていただけますか？

余のボキャブラリに「トランザクション」はなかったので、
ネットでちょっと当たってみたが、よく判らなかった(;_;)。

引用返信 [メール受信/OFF] 削除キー/

■11520 / inTopicNo.15)

　むかしばなし

▲▼■

□投稿者/ 悲しげ -(2018/10/21(Sun) 18:03:43)

■No11505に返信(ド初心者さんの記事)
10年以上前ですが、次のようなエクセルのシートがありまして
列（項目）は、
仕入先、品名、コード、仕入時の包装単価、1日、2日、3日、4日、・・・、30日、31日、金額※
で、毎日、当日仕入の個数を手入力するというもの。
金額は1日～31日の合計×包装単価として、当該品目の当月仕入計を掌握するため。
列は上述のように40個弱ですが、行が1000前後という・・・
品物の並びは1:仕入先、2:概ね品名順(漢字入りの雑なソート)
だから仕入先と独特の並び順を頭で覚えていないと探せない。(;_;)
探すのはもちろん目で(;_;)。
入力する列がずれてしまう（つまり20日の分を19日の列に入れてしまったり）こともしばしば。
その上、ひどいことに新商品があっても殆ど追加はしない(ﾟOﾟ)。
また仕入単価は時々変更になるが、殆ど修正されない（数年前のまま）。(ﾟOﾟ)
疑問もさほど持たずに、そのまま数年間運用されていたらしい。

私が行くようになってから、こんなことやってられっかと、桐で仕入システムを作り上げました。
そしたらエライ人（他店にいる）が激怒して、従来どおりでやれ、と。
説明を理解できる人ではなかったので、私はサラリと無視して暫く自店だけで運用していたのですが、
或る時に別の他店の人がその存在を知り、２年越しで全店で採用に至った。

・・・こんなエピソードを思い出しました。

引用返信 [メール受信/OFF] 削除キー/

■11521 / inTopicNo.16)

　Re[3]: 悲しげさん江

▲▼■

□投稿者/ ONnoji -(2018/10/21(Sun) 18:31:40)

2018/10/21(Sun) 22:00:42 編集(投稿者)
2018/10/21(Sun) 18:41:37 編集(投稿者)
2018/10/21(Sun) 18:33:25 編集(投稿者)
2018/10/21(Sun) 18:32:03 編集(投稿者)

> 寄り道コメントへの質問です(^^;)
>
> ところでここで言う「トランザクション」の意味というか、
> 「マスターとトランザクション」の違いについて、ざっくりと
> 教えていただけますか？
>
> 余のボキャブラリに「トランザクション」はなかったので、
> ネットでちょっと当たってみたが、よく判らなかった(;_;)。

まず、「トランザクション」でちょん切ってしまうと、

・トランザクション・プロセッシング（トランザクション処理）※ＲＤＢＭＳの標準機能

と、

・トランザクションデータ（マスタデータと対極をなします）※データの性質の区別

との、どちらなのか分からなくなりますので、省略しないことをおススメします。

今回取り上げているのは、トランザクションデータとマスタデータの方です。

新規に書くのは大変なので以下に引用させていただきます。

こちら
　↓
【引用】フォームアプリケーションの練習をする ( ソフトウェア ) - ブログ版－桐のイベント道場 - Yahoo!ブログ
https://blogs.yahoo.co.jp/siliconvalley_bay_7565/58233113.html

マスターデータとトランザクションデータを区別することが重要です。

この点が理解できていないと、変てこなデータ処理をしてしまいます。

こういう基本的な事柄は、桐関係の掲示板やＨＰで扱われることが殆どありません。

しかし、実はここがキモなんです。

マスターデータとトランザクションデータは桐固有の知識ではありません。

処理系にどんな言語を使おうと、どんなデータベースを使おうと知っておかなければならない基本知識です。

以下にネットで見つけた記事を引用しよう。

【引用】マスターデータとトランザクションデータって結局なんぞや – gomokulog
http://gomocool.net/gomokulog/?p=906

データベースに触れると、割とすぐに当たり前のように使われている言葉、マスターデータ(マスターテーブル)とトランザクションデータ(トランザクションテーブル) とはなんぞや。

色々解釈ありますが、私的には、

メンテナンスされ、常に最新なデータが反映されているのがマスタデータで、原則削除しないで履歴として残しておくデータがトランザクションデータです。

例えば、ネットで商品を購入し、その時の明細が以下のような感じだとします。

===================

4/20 注文番号 OR0000132

商品A (Item02001) 10000円 2個小計20000円
商品B (Item02002) 5000円 1個小計5000円

合計 25000円

===================

これは購入後マイページで、見れるとします。

その後、商品Aが思ったより売れるので、お店が12000円に値上げしました。

新たにECショップでみると、12000円で売られていて、「安いときに買えてよかった。」って経験ありませんか？

後から、マイページの購入履歴で見たとき、購入履歴の商品の値段が12000円になるわけが無いですよね？

このように、売る時には常に最新のデータを表示するためのデータがマスタデータです。
しっかりメンテナンスされて、もちろん正規化されています。

そして、売れた後に証拠として残されるべき情報がトランザクションデータです。
原則削除は行わず、キャンセルになった場合などはステータス情報などが、”キャンセル済み”などになります。
値段などはシステムのミスなどでなければ、改変することはありません。
このように、履歴、証拠として残しておくデータで、それ故、日ごろの業務(transaction)を行っていると増えていくデータといういみで、トランザクションデータというようです。

よく、日ごろの業務を行うとお客様データは増えていくから、マスタではなくトランザクションデータではないのかという疑問を抱くことがあるのですが、お客様が現住所を変更したら、変更しますよね。過去の住所は原則必要ないですよね？
このようにメンテナンスされていくのでマスタデータといえます。

まぁ、私も今でも、「あれ、これってマスタだっけトランザクションだっけ？」と迷うような曖昧なデータはありますが・・・、そこらへん慣れですかね。

ちなみに以前、データベースの正規化(正規形)とはなんぞやの最後の方で、正規化しないデータもあると書きましたが、まさにそれがトランザクションデータです。

例えば、注文テーブルなどは、第二正規化あたりでよく止めておきます。

上を第二正規化まで進める下記のようになる。

そして、多くはここから正規化を行わない。

なぜなら、第三正規化は、導出項目である小計や合計など、購入時(取引時)の値段を削除するからです。
また、第三正規化では、商品をマスタ化する必要があるが、商品名や商品の値段は変わる可能性があり、変わるたびに過去の購入時の金額や商品名も変わってしまうことになる。

まぁ、難しいこと考えずに消したら困るし変わったら困るなら、それ以上は何もしなければいいだけやね。

引用返信 [メール受信/OFF] 削除キー/

■11522 / inTopicNo.17)

　Re[4]: むかしばなし

▲▼■

□投稿者/ ONnoji -(2018/10/21(Sun) 18:40:04)

2018/10/21(Sun) 18:49:27 編集(投稿者)

>10年以上前ですが、次のようなエクセルのシートがありまして

まさしく、コンピュータ音痴のシートですね。

> 私が行くようになってから、こんなことやってられっかと、桐で仕入システムを作り上げました。
> そしたらエライ人（他店にいる）が激怒して、従来どおりでやれ、と。

エライ人って声がデカイだけで、頭を使わない御仁が非常に多いようですね。

パワハラの温床ですね。

> 説明を理解できる人ではなかったので、私はサラリと無視して暫く自店だけで運用していたのですが、
> 或る時に別の他店の人がその存在を知り、２年越しで全店で採用に至った。

それは慶祝ですね。

483×188 => 250×97

1540127482.jpg/18KB

引用返信 [メール受信/OFF] 削除キー/

■11523 / inTopicNo.18)

　Re[4]: むかしばなし

▲▼■

□投稿者/ まさやん -(2018/10/21(Sun) 18:54:27)

2018/10/21(Sun) 18:57:16 編集(投稿者)

> 或る時に別の他店の人がその存在を知り、２年越しで全店で採用に至った。
>
> ・・・こんなエピソードを思い出しました。

ＳＮＳでいう　『いいね』　です。

引用返信 [メール受信/OFF] 削除キー/

■11524 / inTopicNo.19)

　一応できました

▲▼■

□投稿者/ 悲しげ -(2018/10/22(Mon) 00:17:09)

2018/10/22(Mon) 00:31:23 編集(投稿者)

表が「トランザクション」か「マスター」かは置いといて(^^;)
(無理すじながら？)現構成のまま対応することを考えてみました。

で、編集（入力）のタイミングがふたつ考えられました。
（いつ訂正入力したかの値も入れたいですが、それは今回無視）

【１】下記のような入力値のセットが存在する場合
(1)商品番号、(2)地区番号、(3)入力する値
これを使って表に書き込むとすれば、
上記３項目入力用のフォーム（カード型）を用意する。
左の２つは、手入力でもいいけど、「商品(番号).tbx」と「地区(番号).tbx」から
検索取得するのがベター。
※zip1はataiset.zip（値セット方式、おまけとして地区番号取得.cmxも）
　"値セット.wfx"から実行する。

【２】そうではなく入力済み項目を総当たりで表示して任意に値を訂正入力する。
　　　（未入力項目は上記方式か？）
商品番号と地区番号の（云い換えれば縦と横）どちらが先でもよさそうだが、
先に地区番号項目を固定してから、入力済みの行を絞り込んで商品番号を表示させてみた。
[商品番号]とひとつの[地区番号]項目(可変)の一覧表フォームを用意して、
[地区番号]項目は前後に変更できるようにしてみた。
※zip2はsouatari.zip（総当たり方式）
　"総当たり.wfx"から実行する。

【PS】併合は使えない？
値が数値系ではなく文字列ということから、入力値の更新に加算や減算は使えず、全て複写となるため。(;_;)

*

いずれにせよ、かなりの力技です。
繰り返しになりますが、今後の運用のこともあるので、表の構成をこの際に抜本的に見直すことをお勧めします。

1ataiset.zip/25KB

引用返信 [メール受信/OFF] 削除キー/

■11525 / inTopicNo.20)

　Re[2]: 一応できました（２本目）

▲　■

□投稿者/ 悲しげ -(2018/10/22(Mon) 00:19:18)

■No11524に返信(悲しげさんの記事)
一度に2個のzipは挙げられないようなので、2本目です。

2souatari.zip/11KB

引用返信 [メール受信/OFF] 削除キー/

次の20件＞

トピック内ページ移動 / << 0 | 1 >>

[このトピックに返信]

HOME HELP 新規作成新着記事トピック表示ファイル一覧検索過去ログ

- Child Tree -
- Antispam Version -