3

同じレコードに対して多くの値を持つ列を連続形式で表示する方法がわかりません

私は3つのテーブルを手に入れました

SalesCall
SalesCallId | etc..

Mill
MillId | name...

SalesCallMills    <------ Junction table 
Id | SalesCallId | MillID

多対多の関係のための基本的な設計。

単純な形式の場合、SQLクエリを使用して、リストを作成し、現在のIDの制御ソースを変更することに慣れています。

これを連続した形式で表示するための一般的な方法は何ですか？

これは、1ミルしかできなかった以前の形でした。

ここに画像の説明を入力してください

製粉所を連結できると思っていたのですが、読みづらく、長くなります。

そこでリストを考えましたが、レコードごとにコントロールソースを変更することはできないと思います。

また、これは読み取り専用であることに注意してください。追加や編集用ではありません。データ入力フォームは作成済みです。そして、レコードごとに1つのミルはオプションではないと思います。これは、ユーザーを本当に混乱させるからです。

データベース設計で複数値の列を表示する適切な方法は何ですか？

4

5 に答える 5

6

これは、相関するサブフォームを持つフォームです。

2つのフォームは、リンクの子フィールドとマスターフィールドを介して同期されます。

Link Master Fields: Forms!Form7![SalesCall Subform].Form.SaleID
Link Child Fields: SalesCallId

そして、サブフォーム＃1の現在のイベントの小さなコード

Private Sub Form_Current()
Me.Parent.[SalesCallMills subform].Form.Requery
End Sub

サブフォーム＃1の行を選択すると、サブフォーム＃2の関連する詳細行が表示されます。

相関サブフォーム

一般的なアウトラインにミル名などの適切な情報を追加することは難しくありません。

于 2012-11-14T20:55:07.790 に答える
1

ジャンクションテーブルはあなたの選択の主力となり、そこから他のテーブルを吊るします。

クエリエディタを使用して視覚的に表示できますが、SQLステートメントは次のようになります。

SELECT *
FROM (SalesCallMills 
        INNER JOIN SalesCall
        ON SalesCallMills.ID=SalesCall.SalesCallID) 
     INNER JOIN Mill
     ON SalesCallMills.ID=Mill.MillID;

（Accessは複数テーブルの結合を囲む角かっこが好きなので、純粋なSQLステートメントには必要ありませんが、角かっこがないとAccessは正しく機能しません）

各SalesCallに対するすべてのミルを1行で表示するには、単純なクエリを残して、独自の（vba）関数を作成する必要があります。

http://allenbrowne.com/func-concat.htmlに例があり、現在のフォームのMillsフィールドを次のように設定できるようにするコードがあります。=ConcatRelated("name", "Mill", "MillID= " & SalesCallMills.ID)

于 2012-11-14T20:27:29.010 に答える
1

<br>フォーマットをリッチテキストに設定し、このようにタグで区切られた同じフィールドにすべてのミルを配置することで、ミルをテキストボックスに一覧表示できます。

Mill1<br> mill2<br>mill3

考慮事項
1.これは、テキストボックスの長さが十分でなければならないことを意味します。
2.クエリ内の単一のフィールドにミルを連結する必要がありますが、これは実行できない場合があります。

于 2012-11-14T21:00:57.960 に答える
1

伝統的な意味での古典的な意味では、2つのテーブル間に多対多の関係があるということは実際にはありませんが、関連するテーブルを次々に組み合わせることで、1日の終わりに同じ結果が得られます。多対多の関係ですが、技術的には、2つのテーブル間で発生することではありません。実際には、常に親テーブルから子テーブルに向かって作業を進めています。ジャンクションテーブルの観点から考えている人は、実際には間違った方法で考えています。

人が多くの好きな色を持つことを許可されている場合、色の多くの選択肢を単に「ジャンクション」テーブルとして利用可能な色にリンクするそのテーブルを呼び出すのは味が悪いです。次のようなテーブルが必要であると単純に述べる方がはるかに優れています。

My List Of Favorite colors table.

上記のテーブルが追加のテーブルにリンクする可能性があるという事実は重要ではありません。実際には、外部キーである複数の列が含まれている可能性があり、実際には単純なジャンクションテーブルではありませんが、その日は同じことを行っています。

とにかく、Accessでは、この方法でモデル化されたデータを表示するために、2つの継続フォームを確実に表示できます。

毎週末、人々からたくさんの寄付を受け取らなければならないと仮定しましょう。これは、この寄付イベントの日時などに関する情報を含むメインテーブルが1つあることを意味します。次のテーブルには、人とその寄付額が表示されます。その後の次の表は、寄付金額を受け取り、資金を別の口座に分割することです。これは古典的な会計配分の問題であり、QuickBooksからいつでも実装する必要のあるほぼすべての会計パッケージです。結局のところ、この古典的な配布の問題は、アクセスを使用するときに非常に少ないコードで解決できます。

これらのタイプのフォームをモデル化する秘訣は、1つのメインフォームに配置された複数のサブフォームを使用することです。

次のフォームはこれを示しています。

ここに画像の説明を入力してください

上部を見ると、このバッチ実行と日時に関する情報を含むメインレコードがあります。さて、左側にはたくさんの人と寄付金があります。そして右側には、一人への寄付が多くの異なるアカウントに分割されていることがあります。ですから、私は多くの人を表示しています。また、寄付が分割される可能性のある多くのアカウントも表示しています。

アクセスでは、連続サブフォームを連続サブフォーム内に配置できないことに注意してください。ただし、上記のスクリーンショットが示すように、2つの連続したフォームを並べて配置して、希望する同じ効果をモデル化することはできます。

驚くべきことに、前述のように、このすべてを管理するためのコードはほとんどありません。

左側の連続フォームの場合、リンクマスターと子の設定がメインフォームレコードに設定されているため、このフォームにデータを入力するためのコードは必要ありません。ただし、右側のフォームが続き、左側の連続フォームに各個人の正しい会計データが表示されるため、アクセスによって自動的にこれが行われることはありません。ただし、左側のフォームのon-currentイベントの簡単なコードにより、アクセスが強制的にウェイクアップし、右側のフォームを再入力して、その特定の人の寄付アカウントを表示する必要があることに注意してください。

左側のon-currentイベントに配置された1行のコードは、これを修正します。

me.Parent.Child2.Requery

私が使用する右側の連続フォームのリンクマスター/子設定：

linkChildFields main_id（親テーブルに関連付けるために使用されるこのサブフォームのフィールドの名前）LinkMasterFields [MasterFormLeftSide]。[form]。[ID]（ "masterFormleft"は、あなたを制御するサブフォームの名前です。左側の連続フォームを保持するために使用されます）。

したがって、ほんの少しのコードが必要になりますが、それほど多くは必要ありません。これで、多くの情報に関連する多くの情報を表示する画面ができました。

于 2012-11-14T22:27:58.697 に答える
0

「ジャンクションテーブルの観点から考える人は、実際には間違った方法で考えている」ということに私は強く反対します。@AlbertD.Kallalの回答で。

m：nリレーションシップをリレーショナルDBに直接実装できないのは事実です。それが、次の唯一の正気のデザインである理由です。

+----------+           +---------+
| Patients |--- m:n ---| Doctors |
+----------+           +---------+

... は：

+----------+           +-----------------+           +---------+
| Patients |--- 1:n ---| PatientsDoctors |--- n:1 ---| Doctors |
+----------+           +-----------------+           +---------+

他のすべては何らかの形で機能する可能性がありますが、貧乏人のリレーショナルDB設計です。また、モデルの設計に妥協を加えることで、プロジェクトの最初の段階で、さらに悪化する可能性が非常に高くなります。

于 2015-03-16T21:33:38.060 に答える