Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
データベース09: 実体関連モデル上の一貫性制約
Search
Y. Yamamoto
June 17, 2024
Technology
0
550
データベース09: 実体関連モデル上の一貫性制約
1. 参加制約
2. 多重度制約
3. キー制約
講義ノートURL
https://dbnote.hontolab.org/content/er-model/02.html
Y. Yamamoto
June 17, 2024
Tweet
Share
More Decks by Y. Yamamoto
See All by Y. Yamamoto
データベース12: 正規化(2/2) - データ従属性に基づく正規化
trycycle
0
560
データベース11: 正規化(1/2) - 望ましくない関係スキーマ
trycycle
0
540
データベース10: 拡張実体関連モデル
trycycle
0
560
データベース08: 実体関連モデルとは?
trycycle
0
540
データベース14: B+木 & ハッシュ索引
trycycle
0
260
データベース15: ビッグデータ時代のデータベース
trycycle
0
170
データベース06: SQL (3/3) 副問い合わせ
trycycle
0
400
データベース05: SQL(2/3) 結合質問
trycycle
0
510
データベース04: SQL (1/3) 単純質問 & 集約演算
trycycle
0
570
Other Decks in Technology
See All in Technology
組織に自動テストを書く文化を根付かせる戦略(2024冬版) / Building Automated Test Culture 2024 Winter Edition
twada
PRO
16
4k
Oracle Cloudの生成AIサービスって実際どこまで使えるの? エンジニア目線で試してみた
minorun365
PRO
4
280
1等無人航空機操縦士一発試験 合格までの道のり ドローンミートアップ@大阪 2024/12/18
excdinc
0
160
Fanstaの1年を大解剖! 一人SREはどこまでできるのか!?
syossan27
2
170
OpenAIの蒸留機能(Model Distillation)を使用して運用中のLLMのコストを削減する取り組み
pharma_x_tech
4
560
5分でわかるDuckDB
chanyou0311
10
3.2k
ずっと昔に Star をつけたはずの思い出せない GitHub リポジトリを見つけたい!
rokuosan
0
150
継続的にアウトカムを生み出し ビジネスにつなげる、 戦略と運営に対するタイミーのQUEST(探求)
zigorou
0
550
Snowflake女子会#3 Snowpipeの良さを5分で語るよ
lana2548
0
230
サービスでLLMを採用したばっかりに振り回され続けたこの一年のあれやこれや
segavvy
2
450
Qiita埋め込み用スライド
naoki_0531
0
5.1k
生成AIをより賢く エンジニアのための RAG入門 - Oracle AI Jam Session #20
kutsushitaneko
4
230
Featured
See All Featured
How to train your dragon (web standard)
notwaldorf
88
5.7k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
The Language of Interfaces
destraynor
154
24k
Optimising Largest Contentful Paint
csswizardry
33
3k
Docker and Python
trallard
42
3.1k
Become a Pro
speakerdeck
PRO
26
5k
Git: the NoSQL Database
bkeepers
PRO
427
64k
How STYLIGHT went responsive
nonsquared
95
5.2k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
26
1.9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
No one is an island. Learnings from fostering a developers community.
thoeni
19
3k
Transcript
実体関連モデル(2/3) ⼭本 祐輔 名古屋市⽴⼤学 データサイエンス学部
[email protected]
第9回 データベース 2024年6月17日 〜
実体関連モデル上の一貫性制約
講義ノート https://bit.ly/3xqTSds
draw.io: 実体関連図を書くツール https://app.diagrams.net/
Q1: 復習 Q. Orange Musicの「ユーザ」は「ユーザID」「氏名」「性別」 「誕生日」「電話番号」をもつ. Orange Musicの 「アーティスト」は「アーティストID」「アーティスト名」をもつ. Orange
Musicの「楽曲」は「楽曲ID」「楽曲名」「ジャンル」 「長さ」をもつ. 「アーティスト」は作成した「楽曲」をOrange Musicに「公開」する.「公開」には「公開日」が 記録される. Orange Musicの「ユーザ」は「プレイリスト」を 「作成」することができる. 「プレイリスト」は「プレイリストID」 「プレイリスト名」「公開日」をもつ. 作成された「プレイリス ト」には「楽曲」を「追加」することができる. 「追加」には楽曲 がプレイリストに「追加された日」が記録される.「ユーザ」は 別の「ユーザ」を「フォロー」する. 「フォロー」は「フォロー日」 が記録される. この状況を実体関連図で表現せよ.
A1: 回答 A.
関係データモデル上の⼀貫性制約 一貫性制約 ドメイン制約 キー制約 参照制約 データ従属性 DB上のデータが 実世界を正しく反映すべく データが満たすべき規則 …
実体関連モデル上の⼀貫性制約 一貫性制約 参加制約 多重度制約 キー制約 実体関連モデル上の 関係データモデルに変換する場合も有効
参加制約 1 Participation Constraint
実体型 商品ID = P0001 商品名 = はーいお茶 価格 = 150
商品ID = P0002 商品名 = PONオレンジ 価格 = 180 商品 商品ID 商品名 価格
関連型 A 商品X ユーザ名「A」のユーザは 商品ID「PXXX01」の商品を 2023年9⽉25⽇に購⼊希望登録 B 商品Y ユーザ名「B」のユーザは 商品ID「PYYY01」の商品を
2023年7⽉15⽇に購⼊希望登録 商品 商品ID 商品名 価格 発売⽇ ユーザ ユーザ名 ⽒名 email 住所 購⼊希望 登録⽇
実体関連図における関連型の解釈 商品 ユーザ 購⼊希望 ユーザ 購⼊希望 商品 P1 P2 P3
P4 P5 U1 U2 U3 U4 U1,P1 U2,P2 U2,P3 U3,P2 U1,P4 U4,P4 U4,P1 実体の組み合わせによって関連が表現される
実体関連図における関連型の解釈 商品 ユーザ 購⼊希望 ユーザ 購⼊希望 商品 P1 P2 P3
P4 P5 U1 U2 U3 U4 U1,P1 U2,P2 U2,P3 U3,P2 U1,P4 U4,P4 U4,P1 「購⼊希望」 関連 とつながっていない「商品」実体がある
関連につながっていない実体があることが許されないケース 必修科⽬ 学⽣ 履修 学⽣ 履修 必修科⽬ M1 M2 M3
M4 M5 S1 S2 S3 S4 S1,M1 S2,M2 S2,M3 S3,M2 S1,M4 S4,M4 S4,M5 1名以上から 履修される必要あり
参加制約(1/2) ある実体型のある関連型へのつながりが 部分的か全体的か定める制約 部分的な参加 全体的な参加
参加制約(2/2) 部分的な参加 全体的な参加 必修科⽬ 学⽣ 履修 商品 ユーザ 購⼊ 希望
関連とつなぐ 線を太線に
Q2: 参加制約 Q. Orange Musicに関する実体関連図において 参加制約が全体的になりえる関連型を考え, Q1で作成した実体関連図に反映させよ. (新たな実体/関連型を追加する必要はない)
A2: 回答 A.
多重度制約 2 Cardinality Constraint
多重度制約 関連型を通じて、ある実体が他の実体と 何個つながりを持てるかを定める制約 商品 ユーザ 購⼊希望 製造 メーカー
多重度制約 関連型を通じて、ある実体が他の実体と 何個つながりを持てるかを定める制約 商品 ユーザ 購⼊希望 製造 メーカー ユーザ 商品
P1 P2 P3 P4 U1 U2 U3 U4 U1,P1 U2,P2 U2,P3 U3,P2 U1,P3 購⼊希望 ユーザは1つ以上の複数商品 を購⼊希望登録ができる. 商品は1名以上の複数ユーザ から購⼊希望登録される.
多重度制約 関連型を通じて、ある実体が他の実体と 何個つながりを持てるかを定める制約 商品 ユーザ 購⼊希望 製造 メーカー 商品 P1
P2 P3 P4 製造 P1,A社 P2,A社 P3,A社 P4,B社 メーカー A社 B社 商品は必ず1社のメーカー によって製造される. メーカーは1つ以上の 複数の商品を製造する.
実体関連図における多重度制約の表現 多対多関連 多対1関連 1対1関連 ユーザ 購⼊希望 商品 商品 製造 メーカー
国 ⾸都 都市 両⽅向に⽮印なし 「1」に向けて⽮印 両⽅向に⽮印 多対1は⽮印の⽅向に注意!
多重度制約を考慮した実体関連図の例 商品 商品ID 商品名 価格 発売⽇ ユーザ ユーザ名 ⽒名 email
住所 購⼊希望 登録⽇ 製造 メーカー 企業名 email TEL ショッピングサイトにおける「ユーザが購⼊希望の商品」 「商品の製造メーカー」の情報の管理
Q3: 多重度制約(1/4) Q. Q2で作成した実体関連図に以下の設定を 追加せよ. 「レーベル」は「レーベル名」「住所」をもつ. 「アーティスト」はいずれか1つの「レーベル」 に「所属」し,「レーベル」には何組かの 「アーティスト」が「所属」する.
A3: 回答 A.
Q4: 多重度制約(2/4) Q. Q3で作成した実体関連図に以下の設定を 追加せよ. 「アーティスト」はいくつかの「楽曲」を「公 開」する.「楽曲」公開時には必ず「アーティス ト」が1名登録される.「ユーザ」はいくつかの 「楽曲」を「プレイリスト」に「追加」する. 「プレイリスト」を作成する「ユーザ」は必ず⼀
⼈である.
A4: 回答 A.
Q5: 多重度制約(3/4) Q. Q4で作成した実体関連図に以下の設定を 追加せよ. 「ユーザ」は気に⼊った「楽曲」に「いいね」を することができる.「ユーザ」は何曲でも 「いいね」できる. 「いいね」は「いいね⽇ (liked_at)」が記録される.
A5: 回答 A.
キー制約 3 Key Constraint
キー制約 ある実体型のある属性が主キーとして指定された場合、 主キーの値によって実体が一意に特定される必要あり 商品 商品ID 商品名 価格 主キー 商品ID =
P0001 商品名 = はーいお茶 価格 = 150 商品ID = P0002 商品名 = PONオレンジ 価格 = 180
クイズ Q. ショッピングサイトを利⽤する際,ユーザ と同居する家族を宛先として購⼊商品を配 送できるようにしたい.そこで,実体関連 図に § 実体型「家族」を追加 § 実体型「ユーザ」と実体型「家族」
の間に関連「同居」を追加 したとしよう. 実体型「家族」の属性を適当に 考え,実体関連モデルを作成せよ.
案1 ⽒名を主キーにすると同姓同名の⼈がいたときが問題 ユーザ ユーザ名 ⽒名 email 住所 同居 家族 ⽒名
続柄
案2 ユーザ ユーザ名 ⽒名 email 住所 同居 家族 ⽒名 続柄
家族ID 家族は「ユーザ」のおまけなのにわざわざIDで管理する? 「ユーザ」が退会すれば 家族情報が使われることもなくなる
案1を⾒直す ユーザ ユーザ名 ⽒名 email 住所 同居 家族 ⽒名 続柄
ユーザ名と⽒名を組み合わせれば「家族」を⼀意に特定できる
弱実体と弱関連 ユーザ ユーザ名 ⽒名 email 住所 同居 家族 ⽒名 続柄
弱関連 (太字ひし形) 弱実体 (太字⻑⽅形) 部分キー (下線点線) - ⾃分⾃⾝の属性だけでは主キーを構成できない実体集合 - 弱実体型は太字⻑⽅形で記す - 関連する実体(所有実体)の主キーとセットにして弱実体 特定のために使う属性を部分キーと呼ぶ 弱実体集合 実体と弱実体をつなげる関連(太字ひし形で記す) 弱関連集合 弱実体は所有実体がないと存在できない弱い存在
回 実施日 トピック 1 04/15 ガイダンス:データベースを使わない世界 2 04/22 データベースの概念 3
04/29(祝) 関係データモデル 4 05/13 SQL (1/3) 5 05/20 SQL (2/3) 6 05/27 SQL (3/3) 7 06/03 SQL演習 – レポート課題1 8 06/10 実体関連モデル (1/3) 9 06/17 実体関連モデル (2/3) 10 06/24 実体関連モデル (3/3) 11 07/01 正規化 (1/2) 12 07/08 正規化 (2/2) 13 07/15(祝) データベース設計演習 – レポート課題2 14 07/22 索引付け 15 07/29 NoSQL 16 08/05 期末試験 今後の予定 37