| 過去の桐井戸端ＢＢＳ （桐ver.８） |
| 3355 | メイン・サブフォームの用途 | 初心者 | 1999/11/16-18:09 |
|
どうもいつも有難うございます。 桐ｖ8なんですが、メインサブフォームが 新機能としてあるのですが理屈や作成方法は分かるつもり なのですが、実際使ってみようかとした場合 どんな場面や用途でつかったらいいのか分かりません。 ちょっとした例を教えてもらえないでしょうか？ よろしくお願いします。 | |||
| 3363 | Re:メイン・サブフォームの用途 | 関口喜人 | 1999/11/17-17:22 |
| 記事番号3355へのコメント はじめまして、初心者さん 自分も初心者なんで(^^;うまく説明できませんが 1対多でリレーションを組んであるテーブル同士なら どんな場合でも便利に使えると思います。 親テーブルをメインフォームで、子テーブルをサブフォームに設定 すれば、OKです。 具体例をあげると、販売管理的なものなら 取引先の会社マスターを親テーブルに、販売した商品一覧を子テーブルに 設定すれば、親テーブルの会社をスクロールすると、それに連動して サブフォームの販売商品一覧も、リンクデータにスクロールします。 自分は、ケーブルテレビの仕事をしていますが、放送番組の管理を 主テーブルに、その番組に使用した素材テープの管理をサブテーブル として設定し、利用しています。 伝票フォームだと、1つのテーブルにすることもできますが、 効率よいデータ管理するには、主キー項目を設定して、グループごとに テーブルを分けたほうが、TBLも小さくなるし、スピードも上がるような気がしま す。 初心者さんの質問の趣旨と違ったら、申しわけありません | |||
| 3367 | Re:メイン・サブフォームの用途 | 佐田 守弘 | 1999/11/17-19:10 |
| 記事番号3355へのコメント 初心者さん このての話を始めると、１冊の本ができてしまいますので、ここでは簡単に述べます。 ●実際のデータの多くは引出し型 一般に表計算ソフトでも、データベースでも、データが縦横に並んだ二次元配列型 のデータを扱います。しかしながら、実際のデータは、２次元配列で表現できない 場合があります。 ちょうど昔の図書館の図書カードの様に、縦横のセルの何れかの中に、その中にも う１つのデータベースが入っている様な形、これを私は引出し型のデータベースと 呼んでいます。 ●引出し型のデータの例 ・戸籍や住民台帳 例えば市役所の住民台帳は、１世帯のデータの中に、その世帯に属する複数の人が います。住所や世帯主名１件に対して、その世帯の複数の人が対応します。 ・音楽CDのタイトル 音楽CDのタイトルも、１枚のCDの情報に対して、そこに収録されている曲のデータ が１対ｎで対応します。 ・料理のレシピー 料理のレシピーも１つの料理に使う材料のデータが複数あります。 ・売上データ 売上データも同様です。１件の売り先に対して、複数の商品を同時に販売しますか ら、１対ｎの関係になります。 ●表の正規化 この様な、データの一部が１対ｎ型になっている場合、ｎの部分を基準にレコード を作ろうとすると、１の部分が重複します。例えば上記の例の最後の売上データで 言えば、１顧客に５品販売したとすると、それぞれの商品データは異なりますが、 顧客のデータは同じものが５レコード並びます。 これはデータとして非効率です。この様な場合、１の部分とｎの部分で別の表を作 ります。そして主キーと外部キーを使って２つの表の関連を取り、１組のデータと して扱います。 ●メイン/サブフォーム この様な１対ｎ対応の１組のデータを１画面に表示して、編集を行う場合、メイン/ サブフォームを使います。つまり１の方の表をメインフォームにし、ｎの表の方を サブフォームで表示するわけです。 これによって、１顧客に対して、複数の売上データを同時に表示できます。 佐田守弘(KS-00119) 追伸：現在執筆中の桐ガイドブックでは、ご質問のテーマズバリの題材を取り上げ ております。近日中に第１章を掲載しますので、参考にして下さい。 | |||
| 3369 | よく分かりましたが、画面伝票の価値は0？ | 初心者 | 1999/11/17-21:49 |
| 記事番号3367へのコメント 関口さん、佐田さん親切な解説ありがとうございます。 よく理解できました。 桐5時代（画面伝票）の意識が強く、現在準備中のシステム は画面伝票型のテーブル構成にしてました。 メインサブの形式で再検討してみようと思います。 販売管理の売上入力を考えた場合、桐8としては どちらがいいんでしょうか？ 画面伝票を使用する価値はあるのでしょうか？ 移植性の為に画面伝票はあるのですか？ 教えてください。お願いします。 ｐｓ.佐田先生 しばしば、ＨＰ見ています。解説書たのしみにしてます。 頑張ってください。 先生のＨＰには助けられてます。おかげてイベント処理 にも結構すんなり入れてます。 | |||
| 3371 | Re:メイン・サブフォームの用途 | MIT | 1999/11/18-02:05 |
| 記事番号3355へのコメント MITと申します。 佐田先生の述べられている通りで「正規化」を考えるとメインサブフォーム になるのは自明の理です。 確か画面伝票は桐Ｖ３から導入されたと記憶していますが，画面伝票では グループ項目を複数設定した時点で重複項目を持つデータが生成される事 になり，リレーショナルデータベースの概念からすると「桐ならでは」と 言う処でしょうか。 ところで画面伝票，メインサブフォームのいずれの場合も，もし複数ユー ザーによるファイル共有システムを構築される場合は，本格的なシステム 開発を始める前にレスポンスに関して検証した方が良いと思います。 Ｗｉｎ桐では表を共有した時に共有の「索引」を生成しません。 桐のような歴史のあるパソコンＲＤＢシステムでは数万件から数十万件に 及ぶデータの蓄積をお持ちのユーザーも多くいらっしゃると思いますが， そういうデータ件数ではレスポンスが問題になる事があるかもしれません。 なお桐以外の共有索引を生成出来るタイプのパソコンＲＤＢシステムでは 共有索引が破損する事が多々あり，共有索引が無いＷｉｎ桐のデメリット を指しているわけではありません。 以上ご参考までMIT | |||