A.3・データベース

評価対象HLの焦点。最初の評価2027の目標；公式PDFの返却は403；以前に取得された要約書は最終評価2026である。残りのガイド、評価、実務的要項は記録された保持状態のままとする。

前提条件：指定された数量と単位を読み取り、算術を使用し、以下のモデル条件に従う。各授業は独立した転移前に独自の方法を発展させる。

これらは元々または明示的に架空の教学例であり、実際の測定値や完了した評価対象学習者調査ではない。

この観察を説明するのは何か？

• 注文ごとにユーザー住所を複製すると、住所が変更された際に矛盾するレコードが発生する可能性がある。
• まず予測を立てる。比較したい量や特徴を明記し、2つの説明を区別できる証拠は何かを決定せよ。

モデルを構築する

• リレーショナルテーブルは行と属性で構成される。主鍵は行を特定し、外貨鍵は別のテーブル内の参照鍵にリンクする。正規化は意味ある関係を維持しつつ、避けられる重複と更新アノマリーを減少させることができる。
• プライマリキー：テーブルの行を一意に識別する属性セット；フォレインキー：他のテーブル内のキーを参照する属性セット。

モデルを検証できる証拠を選ぶ

• ジョインは指定された条件に従って行を結合する。結果の行数は関係のカルディナリティとフィルタに依存する。外貨制約は関係ルールを強制するが、個人情報自体を自動的に暗号化するわけではない。
• 実際の個人情報を含さない小さな合成ユーザー-注文データセットを設計する。鍵を宣言し、重複および未参照の挿入をテストした後、クエリ結果を手計算による予想表と比較する。

既知の値から始める

• 既知の値と単位を明記する。このケースに適応する仮定を持つ関係式を選び、代入前に変形する。
• 既知：4人の顧客はそれぞれ 2, 0, 3, 1 の注文を持っている。顧客から注文への内側結合（inner join）は、2+0+3+1 = 6 行を返す。左結合（left join）はまた、注文のない顧客を1つのnullマッチed行として保持するため、ここでは 7 となる。

例：

3人の顧客が1、3、2件の注文を持っている。顧客-注文の内側ジョインは何行を返すか。同じ手順を使用する：既知量 → モデル → 関係式 → 代入 → 単位と解釈。

結論とその限界を確認する

• 主鍵は必ずしも人名である必要はない。ジョインは単なるテーブルの連結ではない。生文字列からSQLを構築するのではなく、信頼できない入力に対してパラメータ化クエリを使用すべきである。
• 元の観察に戻り、結果が何を裏付けているか、どのような条件を前提としているかを説明し、対立する説明を検証する方法を一つ示す。

警告：

外貨鍵は各行を自動的に暗号化する。この主張は誤りである：主鍵は必ずしも人名である必要はない。ジョインは単なるテーブルの連結ではない。信頼できない入力に対してパラメータ化クエリを使用すべきであり、生文字列からSQLを構築してはならない。

重要：

リレーショナルデータベース：鍵と関係：ジョインは指定された条件に従って行を結合する。結果の行数は関係のカルディナリティとフィルタに依存する。外貨制約は関係ルールを強制するが、個人情報自体を自動的に暗号化するわけではない。

実行可能なトレースと境界

import sqlite3
db = sqlite3.connect(":memory:")
db.executescript("""CREATE TABLE c(id INTEGER PRIMARY KEY);
CREATE TABLE o(id INTEGER PRIMARY KEY, cid INTEGER);
INSERT INTO c VALUES(1),(2),(3);
INSERT INTO o VALUES(10,1),(11,1),(12,3);""")
for kind in ["INNER", "LEFT"]:
    sql = f"SELECT COUNT(*),COUNT(o.id) FROM c {kind} JOIN o ON c.id=o.cid"
    print(kind, db.execute(sql).fetchone())
db.close()

期待される出力：

INNER (3, 3)
LEFT (4, 3)

左外結合（LEFT JOIN）は、nullの注文フィールドを含む顧客2を保持します。COUNT(*)はその行を含みますが、COUNT(o.id)は除外します。主キーはレコードを識別し、顧客数は注文数とは異なります。補間される結合キーワードはユーザー入力ではなく、固定された内部リストから来ます。