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

ツリー一括表示

Nomal フォームを作りたい /ド初心者 (18/10/18(Thu) 09:43) #11500 1539823380.zip/62KB
Nomal Re[1]: フォームを作りたい /悲しげ (18/10/18(Thu) 22:37) #11502
│└Nomal Re[2]: フォームを作りたい /ド初心者 (18/10/19(Fri) 11:31) #11505
│  ├Nomal Re[3]: フォームを作りたい /悲しげ (18/10/20(Sat) 00:36) #11511
│  └Nomal むかしばなし /悲しげ (18/10/21(Sun) 18:03) #11520
│    ├Nomal Re[4]: むかしばなし /ONnoji (18/10/21(Sun) 18:40) #11522 1540127482.jpg/18KB
│    └Nomal Re[4]: むかしばなし /まさやん (18/10/21(Sun) 18:54) #11523
Nomal Re[1]: フォームを作りたい /ねむねむ (18/10/19(Fri) 09:20) #11503
│└Nomal Re[2]: フォームを作りたい /ド初心者 (18/10/19(Fri) 11:29) #11504
Nomal Re[1]: フォームを作りたい /ONnoji (18/10/19(Fri) 13:02) #11506
│└Nomal Re[2]: フォームを作りたい /ド初心者 (18/10/19(Fri) 13:32) #11507
│  ├Nomal Re[3]: フォームを作りたい /ONnoji (18/10/19(Fri) 20:27) #11508
│  │└Nomal Re[4]: フォームを作りたい /ONnoji (18/10/23(Tue) 11:07) #11527
│  │  └Nomal Re[5]: フォームを作りたい /尾形 (18/10/23(Tue) 17:20) #11528
│  │    └Nomal Re[6]: フォームを作りたい /ONnoji (18/10/23(Tue) 19:33) #11529
│  └Nomal Re[3]: フォームを作りたい /尾形 (18/10/21(Sun) 11:47) #11518
Nomal Re[1]: フォームを作りたい /Sai (18/10/20(Sat) 00:23) #11509
Nomal Re[1]: 悲しげさん江 /ONnoji (18/10/20(Sat) 13:11) #11514
│├Nomal Re[2]: 悲しげさん江 /ONnoji (18/10/21(Sun) 10:05) #11517
│└Nomal Re[2]: 悲しげさん江 /悲しげ (18/10/21(Sun) 17:15) #11519
│  └Nomal Re[3]: 悲しげさん江 /ONnoji (18/10/21(Sun) 18:31) #11521
│    └Nomal Re[4]: 悲しげさん江 /悲しげ (18/10/27(Sat) 23:24) #11534
│      └Nomal Re[5]: 悲しげさん江 /ONnoji (18/10/27(Sat) 23:51) #11535
Nomal 一応できました /悲しげ (18/10/22(Mon) 00:17) #11524 1ataiset.zip/25KB
│└Nomal Re[2]: 一応できました(2本目) /悲しげ (18/10/22(Mon) 00:19) #11525 2souatari.zip/11KB
│  └Nomal Re[3]: 一応できました(3本目) /悲しげ (18/10/27(Sat) 23:01) #11532 3souatariyoko.zip/9KB
Nomal Re[1]: フォームを作りたい /尾形 (18/10/23(Tue) 05:54) #11526
  └Nomal Re[2]: フォームを作りたい /ONnoji (18/10/25(Thu) 12:06) #11530
    └Nomal Re[3]: フォームを作りたい /ド初心者 (18/10/25(Thu) 13:00) #11531 解決済み!


親記事 / ▼[ 11502 ] ▼[ 11503 ] ▼[ 11506 ] ▼[ 11509 ] ▼[ 11514 ] ▼[ 11524 ] ▼[ 11526 ]
■11500 / 親階層)  フォームを作りたい
□投稿者/ ド初心者 -(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
[ □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / ▼[ 11505 ]
■11502 / 1階層)  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
    ・・・・・・

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

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

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11502 ] / ▼[ 11511 ] ▼[ 11520 ]
■11505 / 2階層)  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列以上あって、逐一スクロールしてデータをメンテナンスするのが大変なのです。
    何か良い知恵がありましたら、ご教示をよろしくお願い申し上げます。
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11505 ] / 返信無し
■11511 / 3階層)  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.
    引用は、全文ではなく、必要最小限に願います。

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11505 ] / ▼[ 11522 ] ▼[ 11523 ]
■11520 / 3階層)  むかしばなし
□投稿者/ 悲しげ -(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゚)
    疑問もさほど持たずに、そのまま数年間運用されていたらしい。

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

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

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11520 ] / 返信無し
■11522 / 4階層)  Re[4]: むかしばなし
□投稿者/ ONnoji -(2018/10/21(Sun) 18:40:04)
    2018/10/21(Sun) 18:49:27 編集(投稿者)

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

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

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

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

    パワハラの温床ですね。

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

    それは慶祝ですね。


483×188 => 250×97

1540127482.jpg
/18KB
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11520 ] / 返信無し
■11523 / 4階層)  Re[4]: むかしばなし
□投稿者/ まさやん -(2018/10/21(Sun) 18:54:27)
    2018/10/21(Sun) 18:57:16 編集(投稿者)



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


    SNSでいう 『いいね』  です。

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / ▼[ 11504 ]
■11503 / 1階層)  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にデータを入力しようとした場合、
    表示されていないと編集出来ないのではないでしょうか。それとも表示のみで
    編集はしないのでしょうか?
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11503 ] / 返信無し
■11504 / 2階層)  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列以上あります。
    データある列は、値をできれば文字列で編集できるようにしたいのです。
    よろしくお願い申し上げます。

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / ▼[ 11507 ]
■11506 / 1階層)  Re[1]: フォームを作りたい
□投稿者/ ONnoji -(2018/10/19(Fri) 13:02:05)
    2018/10/19(Fri) 13:09:17 編集(投稿者)

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

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

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

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

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

    <A案>

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

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

    <B案>

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

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

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

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

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

    p.s.

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

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

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

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


[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11506 ] / ▼[ 11508 ] ▼[ 11518 ]
■11507 / 2階層)  Re[2]: フォームを作りたい
□投稿者/ ド初心者 -(2018/10/19(Fri) 13:32:29)
    No11506に返信(ONnojiさんの記事)
    > しかし、A案でも、B案でも、実装するのは非常に大変ですよ。
    >
    > よってサンプルの提示はいたしません。悪しからず。
    >

    そうなんですかぁ。じゃあ、このレスも未解決になります。(^^;;;;;
    だって解決していないんです。前のレスも。
    桐っていい本とかがないんですよね。
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11507 ] / ▼[ 11527 ]
■11508 / 3階層)  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 編集(投稿者)

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

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

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

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

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

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

    なので、

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

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

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

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

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

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

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

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

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

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

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

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



[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11508 ] / ▼[ 11528 ]
■11527 / 4階層)  Re[4]: フォームを作りたい
□投稿者/ ONnoji -(2018/10/23(Tue) 11:07:27)
    2018/10/23(Tue) 11:24:43 編集(投稿者)

    今までにも、項目数が100個とか200個とかという質問がありました。

    大抵の場合、これは駄目だから、正規化しなさいとなるわけです。

    ところが、今回は、「200項目の表を訂正入力する楽な方法」の質問があったわけです。

    当初は、訂正が必要なデータなのでマスタデータかと思ったのですが、

    いろいろ考慮すると、トランザクションデータから縦横変換して導出するデータだと思われます。

    縦横変換して導出したデータならば、必要時に、再び導出すれば最新の状態になるわけです。

    つまり、「200項目の表を訂正入力する楽な方法」そのものが本末転倒の思考なのです。

    しかし、導出の元になるトランザクションデータがまったく考慮されていませんね。

    ひょっとして、リアルな紙の200項目帳簿で、消しゴム(インク消し)と鉛筆(ペン)を使って文字を書き換えているのでしょうか?

    もしもそうならば、本当にトランザクションデータが無いことになりますが、

    それでも、書き換えるためのデータを求めることが出来る原票くらいはあるのではないでしょうか?。

    つまり、なんの根拠も無しに、書き換えたりしないでしょう。

    まさにそれが、トランザクションデータに相当します。

    なお、どうしても項目数が200個の表で管理したいのならば、

    データベースではなく表計算ソフトのワークシートの方が適していると思いますよ。



[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11527 ] / ▼[ 11529 ]
■11528 / 5階層)  Re[5]: フォームを作りたい
□投稿者/ 尾形 -(2018/10/23(Tue) 17:20:24)
    何度もすいません


    わたしの記憶違いかもしれませんが
    ONnojiさんは、結合表もメインサブフォームも使われない派?
    だったように思います


    ちょっと疑問なのですが
    どうやって正規化してあるのですか?


    見当違いでしたらすいません


[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11528 ] / 返信無し
■11529 / 6階層)  Re[6]: フォームを作りたい
□投稿者/ ONnoji -(2018/10/23(Tue) 19:33:35)
    2018/10/23(Tue) 20:01:48 編集(投稿者)
    2018/10/23(Tue) 19:59:29 編集(投稿者)
    2018/10/23(Tue) 19:39:40 編集(投稿者)
    2018/10/23(Tue) 19:36:56 編集(投稿者)
    2018/10/23(Tue) 19:35:11 編集(投稿者)

    > ちょっと疑問なのですが
    > どうやって正規化してあるのですか?

    質問者がどのように正規化してあるのかは、全く不明です。

    しかし、私は、マスタデータではなく、トランザクションデータからデータを導出するのが正しい運用方法だろうと睨んでいます。

    いわゆる、縦横変換ですね。

    現状は、ただの電子的な紙ですね。だから、表計算ソフトで処理した方がよいのではないかと思っています。

     ◇ ◇ ◇ ◇ ◇ ◇

    > どうやって正規化してあるのですか?

    ひょとして?、正規化が不十分だというご意見でしょうかね????

    それでは、以下に誤解が非常に多い正規化の話題を…

    ご承知のようにマスタデータは正規化します。これは当然ですね。

    しかし、トランザクションデータは導出項目を含めて冗長を許して、完全に正規化しませんよ。

    何故ならば、変更すると、改竄になってしまうデータだからです。※入力誤りを除きます。

    この点をご存じない人が非常に多いので、以下に引用を示します。

    詳しいことは、既出の 11521 悲しげさん江 投稿者/ ONnoji -(2018/10/21(Sun) 18:31:40)
    http://tayu.o0o0.jp/bbs/kiri/cbbs.cgi?mode=one&namber=11521&type=11500&space=45&no=0

    の引用を参照してください。

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


    その他にもあります、こちらもお読みください。
     ↓
    【引用】RDBの正規化の方法と、正規化を崩す方法 - ウィリアムのいたずらの開発日記
    http://blog.goo.ne.jp/xmldtp/e/2a35412416a6f9b56f194d69d09f94bb

    【引用】データベースは正規化しない方がよい? : makoto_fujimotoのblog
    http://blog.shinkaku.co.jp/archives/19849328.html


    > 見当違いでしたらすいません

    巷に溢れかえっているwebページに見られるRDB教科書のように「盲目的に何でもかんでも正規化するというわけではありませんよ」というだけのことですよ。

    p.s.

    > ONnojiさんは、結合表もメインサブフォームも使われない派?

    必要があれば、結合表も使いますよ。

    でも、私の場合には、トランザクションデータを処理することが多いので、結合表を使う機会が殆ど無いのです。

    使う必要がないものは、使わないというだけのことですよ。

    つまり、好き嫌いで結合表を使わないのではありません。キッパリ。

    簡単なメインサブフォームも使うことがありますよ。

    ただし、サブフォーム側でイベント処理は一切使わないというレベルのものに限ります。

    基本的にメインサブフォームは使い難いので使いません。これは好き嫌いの話です。(^^ゞ



[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11507 ] / 返信無し
■11518 / 3階層)  Re[3]: フォームを作りたい
□投稿者/ 尾形 -(2018/10/21(Sun) 11:47:40)
    どうも、こんにちは

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

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

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / 返信無し
■11509 / 1階層)  Re[1]: フォームを作りたい
□投稿者/ Sai -(2018/10/20(Sat) 00:23:15)
    No11500に返信(ド初心者さんの記事)

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

    ではなくて

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

    ということでしたら

    メンテ用にカード型フォームを設定するのはいかがですか。
    例えば 20行×10列 で200項目(列)表示できますね。

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

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / ▼[ 11517 ] ▼[ 11519 ]
■11514 / 1階層)  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や後述のような)。

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

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

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

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

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

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

    { 物品名,配置先1,配置先2,配置先3, ・・・ 配置先n }

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

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

     物品名   A町   B町    
     消火器A 10個  10個 ・・・
     バケツ  10個  10個 ・・・
     乾パン  10個  10個 ・・・

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

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

    日付    物品名  数量 消費期限  配置先 
    yyyy-mm-dd 消火器A 10 yyyy-mm-dd A町
    yyyy-mm-dd 消火器A 10 yyyy-mm-dd B町
    yyyy-mm-dd バケツ  10 yyyy-mm-dd A町
    yyyy-mm-dd バケツ  10 yyyy-mm-dd B町
    yyyy-mm-dd 乾パン  10 yyyy-mm-dd A町
    yyyy-mm-dd 乾パン  10 yyyy-mm-dd B町
     :     :    :  :     :
     :     :    :  :     :
     :     :    :  :     :
     :     :    :  :     :

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

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

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

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

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

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




[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11514 ] / 返信無し
■11517 / 2階層)  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列以上あって、逐一スクロールしてデータをメンテナンスするのが大変な」表は、

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

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

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

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

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

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

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

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

    それでは駄目なんです。

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

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

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


[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11514 ] / ▼[ 11521 ]
■11519 / 2階層)  Re[2]: 悲しげさん江
□投稿者/ 悲しげ -(2018/10/21(Sun) 17:15:03)
    No11514に返信(ONnojiさんの記事)

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

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

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

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11519 ] / ▼[ 11534 ]
■11521 / 3階層)  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 編集(投稿者)

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

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

    ・トランザクション・プロセッシング(トランザクション処理)※RDBMSの標準機能

    と、

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

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

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

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

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

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

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

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

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

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

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

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


    【引用】マスターデータとトランザクションデータって結局なんぞや – 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)を行っていると増えていくデータといういみで、トランザクションデータというようです。

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

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

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

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

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

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

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

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


[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11521 ] / ▼[ 11535 ]
■11534 / 4階層)  Re[4]: 悲しげさん江
□投稿者/ 悲しげ -(2018/10/27(Sat) 23:24:57)
    No11521に返信(ONnojiさんの記事)
    この話題をこれ以上ひっぱるのも何ですが・・・・(^^;)(^^;)(^^;)
    あまり難しいことは(特にカタカナ語)は実は判らないままに、私は我流でやってきまして(^^;)、
    まあ、それはそれでひとつの有効なスタイルではないかと思っていたりします。

    (1)マスター表(商品マスターとか仕入先マスターとか)
    (2)伝票入力用作業表
    (3)入力データを転記保存するための保存表(仮に「**台帳」と呼んでいる)

    たいていはこの3つの表で回しています。
    付随する処理は上記(3)のデータから抽出したものを諸々加工しまくる。

    このスタイルをどうして採用するようになったかは、今となっては思い出せませんが(^^;)、
    おそらく「浦秀樹本」の影響が大きいように思います。あとpc-van、nifty-serveも。
    「桐使い」は親切な人が多かったし。


[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11534 ] / 返信無し
■11535 / 5階層)  Re[5]: 悲しげさん江
□投稿者/ ONnoji -(2018/10/27(Sat) 23:51:56)
    > (1)マスター表(商品マスターとか仕入先マスターとか)
    > (2)伝票入力用作業表
    > (3)入力データを転記保存するための保存表(仮に「**台帳」と呼んでいる)
    >
    > たいていはこの3つの表で回しています。
    > 付随する処理は上記(3)のデータから抽出したものを諸々加工しまくる。

    データファイルを、台帳に例えることがありますね。

    私も僅かな業務アプリケーション作成の経験の中で、

    取扱説明書に「○○○台帳」や「×××台帳」といった呼称を用いたことがありました。

    事務作業の機械化のためにパソコンを利用するのですから、昔はリアルな台帳が存在していることが多かったのです。

    なので、「ほにゃらら台帳」という言葉が飛び交っても、プロジェクトの誰にでも理解できました。

    しかし、いったん事務作業の機械化が完成してしまうと、

    つまり、業務アプリケーションが完成してしまうと、

    ハードディスクに保存されているファイルを「ほにゃらら台帳」と呼ぶのに違和感が生じてきます。

    ということで、最近では、「○○○トランザクション」や「×××マスタ」と、データの種類によって呼び方を変えています。

    直近のプロジェクトの場合には、○○○トランザクション.tbl や ×××マスタ.tbl とファイル名そのものにデータの種類を明示しています。

    なお、オペレータには、トランザクションデータとマスタデータの違いを口が酸っぱくなるまで説明してあります。



[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / ▼[ 11525 ]
■11524 / 1階層)  一応できました
□投稿者/ 悲しげ -(2018/10/22(Mon) 00:17:09)
    2018/10/22(Mon) 00:31:23 編集(投稿者)

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

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

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

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

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

    *

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


1ataiset.zip
/25KB
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11524 ] / ▼[ 11532 ]
■11525 / 2階層)  Re[2]: 一応できました(2本目)
□投稿者/ 悲しげ -(2018/10/22(Mon) 00:19:18)
    No11524に返信(悲しげさんの記事)
    一度に2個のzipは挙げられないようなので、2本目です。

2souatari.zip
/11KB
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11525 ] / 返信無し
■11532 / 3階層)  Re[3]: 一応できました(3本目)
□投稿者/ 悲しげ -(2018/10/27(Sat) 23:01:13)
    No11525に返信(悲しげさんの記事)

    締めた後ですが、横(商品番号)を固定した処理を執念深く考えてみました。
    当初の例示が下記のようだったので。

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

    結構悩んだ末のかなりの力技です。
    まるでゲームのような感覚で作ってみました。
    実務だとこんなふうにはしないだろうと思いつつ。(^^;)

3souatariyoko.zip
/9KB
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11500 ] / ▼[ 11530 ]
■11526 / 1階層)  Re[1]: フォームを作りたい
□投稿者/ 尾形 -(2018/10/23(Tue) 05:54:01)
    どうも、こんにちは


    項目名に「地区」と書いちゃったんで

    気の毒な感じになっちゃったですね (^^;



    マスタ項目とかにしとけばよかったのかな

[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11526 ] / ▼[ 11531 ]
■11530 / 2階層)  Re[2]: フォームを作りたい
□投稿者/ ONnoji -(2018/10/25(Thu) 12:06:15)
    2018/10/25(Thu) 12:24:08 編集(投稿者)

    横レスで大変失礼します。m(__)m

    > マスタ項目とかにしとけばよかったのかな

    項目の名称の問題ではないですよね。

    データの質の問題でしょ。

    実際のデータは提示したくないので、その替わりに、

    { 商品名,地区01,地区02,地区03, ・・・ 地区20 }

    ↑このような、仮のサンプルを提示されたのかもしれませんね。

    本当はアンケートのデータで

    { 氏名,質問01,質問02,質問03, ・・・ 質問20 }

    なのかもしれません。

    しかし、今までのやり取りを見る限りアンケートのデータではなさそうですね。

    ちなみに、アンケートデータは参照するデータではなさそうなので、マスタとは呼べませんね。


[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/

▲[ 11530 ] / 返信無し
■11531 / 3階層)  Re[3]: フォームを作りたい
□投稿者/ ド初心者 -(2018/10/25(Thu) 13:00:43)
    悲しげ様ほか、皆様、ありがとうございました。

    正直悲しげ様のサンプルは、高度すぎてまだ理解できていない
    のですが、これ以上の解決もないので、一応レスを締めさせて
    頂ければ、と思います。
    ありがとうございました。

    >
解決済み!
[ 親 11500 / □ Tree ] 返信 [メール受信/OFF] 削除キー/


Mode/  Pass/

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

- Child Tree -
- Antispam Version -