LoginSignup
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@taleau(t @leau)

学習メモ【Access】

Last updated at Posted at 2022-03-01

この本をざっくりメモ

オブジェクトざっくり

テーブル

命名例

  • T_テーブル名
  • MT_マスタテーブル名

クエリ

命名例

  • Q_クエリ名

レポート

命名例

  • R_レポート名

テーブル

  • フィールド追加時に「集計フィールド」から計算式を作るダイアログが開く。パワクと似たような画面
  • 命名
    • T_テーブル名
      • 随時更新・追加されるもの
    • MT_テーブル名
      • マスターテーブル。商品情報など更新があまりないもの

リレーションシップ

3つのポイント

  1. 参照整合性：対応していないデータの入力を防ぐ仕組み
    1. 参照される側にある値しか入力できない
    2. チェックを入れると連鎖更新がアクティブになる
      1. フィールドの連鎖更新
      2. レコードの連鎖更新
      3. レコードの連鎖削除
        1. 参照されている側データを削除すると参照している側のレコードも削除される
  2. リレーションシップの種類
    1. 1対1
    2. 1対多
      1. 結合フィールドは主キーが定石
    3. 多対多
      1. テーブルA-Bが1対多、テーブルC-Bが1対多なら間接的にA-Cが多対多になる
  3. 結合の種類
    1. 内部結合
      1. 両方のテーブルの結合フィールドがないと取り出せない
    2. 左外部結合
      1. よくわからん
    3. 右外部結合
      1. よくわからん
  • テーブルデザインビュー
    • フィールドのデータ型
      • ルックアップウイザード

からリレーションシップを組むと参照している側のレコード入力セルにプルダウンメニューが追加される。

クエリ

クエリデザイン

  • 抽出条件に>=[プロンプト文字列]と書くとInputBoxからの検索条件入力可能になる。
  • 演算フィールドは[新しいフィールド名]:[既存のフィールド名]*1.08とか

クエリ種類

  • 選択
    • ざっくり言うとフィルタ機能
    • 抽出条件と表示フィールド、演算フィールドを列挙するだけ
  • 更新
    • 元には戻せない。
    • 事前に抽出結果を確認するのはリボン＞クエリデザイン＞表示
  • 削除
    • 元には戻せない。
    • 事前に抽出結果を確認するのはリボン＞クエリデザイン＞表示
    • 削除したものはIDごと全レコードが#Deleted#となり、そのID連番は欠番になる。

他にも

  • テーブルの作成
  • 追加
  • クロス集計
    なんてのもあるみたい

テーブルを結合した選択クエリ上での演算クエリの式

式のカテゴリから直接押してもできるが、
image.png

[テーブル名].[フィールド名]と入力しようとするとインテリセンスが使えるのと完成後に参照テーブル名まで見ることができて好き。
image.png
image.png
image.png
インテリセンスは途中まで入力してからでもいいし、最初からCtrl+Spaceでも出せる。

image.png

レポート

ざっくり2種類ある

  • テーブルそのままレポート
  • 選択クエリの結果をレポート

ロゴ

jpgとか仕込める。
OLEサイズはストレッチにしておく。
image.png

伝票ウイザード

こんな帳票テンプレートもある。すごい。
image.png

はがきウイザード

image.png

正規化

これ地味に知らなかったので

第1正規化： 繰り返される列がない

第1の中にも2段階あるっぽい

  1. 商品名だ価格だ数量だと同じ種類の列が複数ないこと
    image.png

  2. 顧客情報などはマスターテーブルに切り出して重複をなくす
    ※結合用にマスタ側のIDを呼び出す側のテーブルに残す
    image.png

第2正規化： 主キーの値が決まると他の列の値が必ず決まる

第1の多段バージョン
image.png

まとめるとこうなる
とにかく列も行も重複のないテーブルに因数分解していく作業という印象
image.png

第3正規化： 主キー以外の列の値によって、他の列の値が決まることがない

また多段バージョン？

この例だと顧客情報も切り出せるよね、という話
image.png

正規化すればいいというものでもないらしい

  • 正規化すると途中で値引きで単価が変わるなどに対して臨機応変さがなくなるというデメリットがある
  • 単価×個数で小計は計算すれば良いので列は不要、とすると毎回計算しなきゃなので面倒→計算列は増やしておこうか

など、単に冗長さを取り除くだけでなく、追加や変などに対応できる柔軟さやパフォーマンスなどを鑑みて、システムに求められるよう県から両社のバランスが取れるよう、着地点を見出すことが重要とのこと。

データベースの共有

複数ユーザーが同じレコードを同時に編集できないようにロックする

チェックが「編集済みレコード」ならそのレコードのみ
「すべてのレコード」だとテーブル全体をロック
image.png

0
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?