Access学習メモ 2-5. Accessは働き者

選択クエリのデザイングリッドに、アニメの「配信リスト」と「キャラクター名簿」をなんとなく置いて「クエリを実行」しただけで...

Accessは「配信リスト：全111レコード」と「名簿：全20レコード」を掛け合わせた2,220行のレコードを表示させてくれる。

「リレーションシップ（結合線）」を組んだわけでもなく、そのような命令式を書いたわけでもないのに、なぜなのか不思議。

リレーションの話題になると、よく目にする「一対多（いち-たい-た）」

テーブル同士において、1件のレコードに複数のレコードが結びつく様子を表現するらしいけど、日本語として不自然だしどちらが「多」なのか毎回こんがらがってしまう。

でも、こういう場面に出会うとなんとなく腑に落ちる。

配信リスト側が「一(一意)」、そこに群れるキャラ達が「多」で合ってる？

人間の目では「これは配信リスト」「これは名簿」って各々のテーブルを独立した存在と理解する。

でもAccessは違う。テーブル同士の関係性（ルール）に基づくデータ整理が目的のクエリデザイン画面に、命令をもたない双方が並ぶと、「とりあえず全ての組み合わせ（全パターン）を表示しとけば間違いないだろう！」と判断するのだろう。

たまたま双方のテーブルに「Season」という共通フィールド。

・「配信リスト」上のSeasonは、そのお話がどのSeasonに紐づくかを表示したもの

・「名簿」上のSeasonは、そのキャラクターがどのSeasonから参加し始めたかを表示したもの

それぞれ役割が異なる。

ためしに「Season」同士をリレーションさせたが「名簿」マスタのSeason定義のあいまいさにより、実態が反映できなかった。

アニメは現在、Season1からSeason4で編成されている。

Season1から参加したキャラは、その後のSeason2にも3にも4にも登場する可能性がある。

Season2から参加したキャラは、その後のSeason3と4にも。Season3から登場したキャラは4にも。

人間だとそのあたりの事情が詳しい説明抜きに解釈し合えるため、テーブル上の表示としては、初参加Seasonの数字のみでも通じる。

でも、Accessとしてはそれぞれのキャラは「明記されたSeasonのみ参加」と文字通り解釈するため、意図したレコードが用意されない。

配信リスト×登場可能キャラ数のレコードを用意したい場合

【簡易版】

全キャラ共通項の条件として「初登場したSeasonの数字以降(以上)のSeasonに出演する可能性」があり「不等号結合（Non-Equal Join）」の関係が成立

不等号結合の作り方（クエリデザイン画面）

1.クエリデザイン画面に「M_配信リスト」「M_名簿」追加

2.デザイングリッドに「M_配信リスト」の「話数」「タイトル」「放送日」「Season」を追加

3.デザイングリッドに「M_名簿」から「キャラクター名」「初登場日」「声優さん」「Season」を追加

4.「M_名簿」の「Season」抽出条件の欄に入力

<= M_配信リスト].[Season]

【問題点】

管理がSeason単位であるため、各話に登場しないキャラのレコードも表示され実用((੭ु;・∀・)੭ु⁾⁾)に不向き

例：「111話（嵐の空中レース） / CH003（ちびギドラ）」が登場

それにしても1,921レコードって...使うの自分しかいないけど

【実用版】

1.「M_配信リスト」主キーと「M_名簿」主キーを仲介するトランザクションテーブル「T_出演」を作成（大変）

2.フォームの構成を「メイン/サブ」に分類、「配信リスト」主キー「話数」でリレーション