すべてのカテゴリ

選択クエリのデザイングリッドに、アニメの「配信リスト」と「キャラクター名簿」をなんとなく置いて「クエリを実行」しただけで...Accessは「配信リスト：全111レコード」と「名簿：全20レコード」を掛け合わせた2,220行のレコードを表示させてくれる。「リレーションシップ（結合線）」を組んだわけでもなく、そのような命令式を書いたわけでもないのに、なぜなのか不思議。リレーションの話題になると、よく目にする「一対多（いち-たい-た）」テーブル同士において、1件のレコードに複数のレコードが結びつく様子を表現するらしいけど、日本語として不自然だしどちらが「多」なのか毎回こんがらがってしまう。でも、こういう場面に出会うとなんとなく腑に落ちる。配信リスト側が「一(一意)」、そこに群れるキャラ達が「多」で合ってる？人間の目では「これは配信リスト」「これは名簿」って各々のテーブルを独立した存在と理解する。でもAccessは違う。テーブル同士の関係性（ルール）に基づくデータ整理が目的のクエリデザイン画面に、命令をもたない双方が並ぶと、「とりあえず全ての組み合わせ（全パターン）を表示しとけば間違いないだろう！」と判断するのだろう。たまたま双方のテーブルに「Season」という共通フィールド。・「配信リスト」上のSeasonは、そのお話がどのSeasonに紐づくかを表示したもの・「名簿」上のSeasonは、そのキャラクターがどのSeasonから参加し始めたかを表示したものそれぞれ役割が異なる。ためしに「Season」同士をリレーションさせたが「名簿」マスタのSeason定義のあいまいさにより、実態

＊°˖✧ゴジ図書館の貸出入力簿✧˖°＊なるべくラクに簡単に、最低限の機能だけ備えた設計を目指していて、なのにいつもめちゃ時間も気力も消耗してるけど、なんとか形にできた。メインもサブもコンボボックスもすべて揃えた。貸出日の14日後が返却期限:DateAdd("d",14,[貸出日])　〃　の1ヶ月後が返却期限:DateAdd("m",1,[貸出日])図書館を利用できるか利用可否: IIf([利用期限]<[貸出日],"利用不可","利用可能")貸出後の返却がなされているか返却状況：IIf(IsNull([返却日]),"未返却","返却済")本は貸出可能か貸出可否: IIf(IsNull([返却日]), "要確認", "貸出可能")

MicrosoftAccessを用いたデータベース作りの学習記録です Access標準機能にてExcelデータをAccessテーブルへインポートできる。ただ、例題のようなカッコつけたフィールド名はエラーが起きやすくその場合はExcelから直接、データをコピペすることも可能と教わった。※貼付には若干コツが必要データインポートにてすべてのテーブルにデータを格納させたあと、リレーションシップおよび参照整合性を設定。※先にリレーションさせてしまうと、テーブルの内容に修正が必要となった際にあわわってなるので、テーブルを完璧に仕上げるまではやらなくていい。テーブル寸法(フィールドサイズ)の相違など、リレーションさせたいもの同士に何かしら矛盾があると、ここで発覚する。クエリ設計に入る前には済ませておくとたぶんスムーズ。（実務ではフィールド連鎖更新までさせておいた方が手間が少ない。）

テーブルとは？：データ（レコード）の保管庫 ココナラのようなプラットフォーム上において、ユーザーが公開プロフィールに書き込んだ情報は会員情報としてマスタテーブルに登録される。多くの場合、会員番号以外はユーザー自身で自由に変更できる。 一方で、会員同士の商取引がメインの場合、日々更新される取引実績を格納するためのデータ保管場所も必要になる。そんなときに用いられるのが、トランザクションテーブル。Excelのようにすべてのデータを横並びに一覧表示させる方法もあるが、登録したすべての会員が商取引に参加するとは限らないため、会員名簿としてのマスタテーブルと活動記録のためのトランザクションテーブルという風に、目的ごとにテーブルを分けて効率よく管理を行うのが一般的。 それぞれのテーブルの共通項として、たとえば会員番号を配備することで、別々のテーブルで変更が行われても、お互いのテーブルに更新内容を紐づけ（リレーション）することが可能。プロフィール情報の変更や新たな商取引の追加にも混乱することなく、必要なときに関連項目を正しく結びつけ確認できる。 これこそAccessの持つリレーショナルの構造であり、得意分野らしい。 逆に言えば、1枚のシートで完結できるデータ整理にはExcelが向いている。 主キー&外部キー：結合された各々のテーブル上で果たす役割の違い 各テーブルの橋渡し役の「会員番号」は、会員名簿としてのマスタテーブル上では他の番号との重複が認められず、唯一無二かつ一度きりの登場。レコード情報を引率する主役であり「主キー」と呼ばれる。 一方、日々の商取引を記録するためのトランザクショ

メイン/サブフォームを繋ぎとめてくれていた「利用者ID」親子リンク学習メモ3-8でサブフォームが機能しなくなった理由は、Accessの解釈と私の意図が相反していたことが原因だった。学習メモ3-8.で実装済の構成利用者登録（親）⇔ 利用者IDでリンク ⇔SF_新規登録（子） Accessの解釈（検索対象者　＝　登録対象者）メインフォームのコンボボックス上で利用者を表示↓その利用者に属するデータをサブフォームへ登録私が目指していたもの（検索対象者　≠　登録対象者）「新規利用者がすでに登録されていないか」を確認するためにメインフォームのコンボボックス上で利用者を表示 ↓登録がないと判明した場合はサブフォーム上で新規利用者として登録・・・だから、メインのコンボボックスで利用者を選択しつつサブのテキストボックスに(メイン不在の)新規利用者を登録した瞬間に親子リンクの思想とぶつかってしまい、Accessがフリーズした。そもそもメイン/サブとして各フォームをリレーションさせる目的は、メインに関係する詳細情報をサブに反映させることにある。リンクさせるフィールドには「1対多」の関係性が成立していることが前提。設計の意図：「新規利用者がすでに登録されていないか」を確認するためにメインのコンボボックス上で利用者を表示し、登録がなければサブフォーム上で新規利用者として登録その設計思想をAccessに伝えるためには、①リンク親フィールド・リンク子フィールドを消す②①の代わりにサブフォームへ飛ぶためのボタン「新規登録」をメインに新設Private Sub 新規登録_Click()DoCmd.OpenFor