この前Bento2
ライブラリやらコレクションを、フォームにドラッグアンドドロップすれば、関連レコードリストと呼ばれる子エンティティを持つことができます。
別のやり方で言うと、フィールドを作成→フィールドの設定→フィールドタイプの選択で「関連レコードリスト」を選択して、オプションの設定で「データソースの選択」です。
データモデルとしては、やっぱりN:Nということになるんでしょうかね。それも両辺、0件を許容しているN:Nです。
しかしこのリレーションは、親にしたエンティティからしか参照できません。
逆向きの参照をするにはもういっこ、子のエンティティからもフィールドの作成をして親のエンティティをデータソースにした関連レコードリストを作ればいいんでしょうが、同じ内容を子側からも入力しないといけないし、バリデーションを作り込むことはできません。
だから基本的には1:Nの関係を想定しているのでしょう。
たとえば僕が関連レコードリストのフィールドを使っているのは、miniDV
しかし困ったことに、miniDV
もひとつ例をあげます。映画を観た感想を書くライブラリを作ったとします(僕は作ってませんが)。映画は複数の俳優が出演しています。そんなときどうやってBento2
でも、その俳優が出演している映画をリスト化するときは、それだけの入力じゃBento2
Bento2
映画のほうは、ファイルメニューの中から「新規スマートコレクションを作成」を選択して特定の映画のチェックボックスがONの検索条件を入れて保存して作ります。こうすることで、1回の入力で双方から参照可能なデータが作れる訳です。
しかしこれは、映画を観た感想を書くライブラリを作るにはあまりにも手間がかかるし、映画ひとつ増えるたびにチェックボックスを増やしていくことになるので、あまりいいやり方じゃないですね。となると映画と俳優を逆にして、映画のフォーム上に俳優のチェックボックスをつけていくことになるんですかね。それでも、管理する俳優が増えるたびにチェックボックスが増えるという難点は変わりません。
こうなると1オペレーションで双方向の抽出を可能にする、というのをあきらめて、ふつうに俳優のライブラリと映画のライブラリを作って、お互いに関連レコードリストを持ち合って、それぞれのフォームで関連を入力するダブルオペレーションをしたほうがまだ合理的ということになるんですかね。
おなじことをAccess

0 件のコメント:
コメントを投稿