HOME»応用情報技術者試験掲示板»関係データベースのカーディナリ特定 理論の確認
投稿する
まあ、そりゃあ1対1になるようなこともあります。たとえば受注明細単位と売上明細単位が一緒になるという仕様の場合、1対1だから矢印じゃないとかそういうのです。でも、基本は1対多（矢印の起点が1、矢印の尖った方が多。たとえば、受注伝票に営業担当のIDが書いてあって、営業担当のマスタから引いてきたようなことを考えるとそうなる）です。例外になる場合、本文に1対1になるような記述がある（これはDBスペシャリストでも同様）ので、ああ、これは1対1だなと判断出来たら矢印消して棒線にするでもいいんじゃあないでしょうか。
※なお、多対多になったら連関エンティティを作って1対多を作るので考える必要はありません。
まあ、常識的に考えると、世の中の薬局で全く同じ処方箋IDで薬を出したら（≒同日に同じ薬剤を出すってことになる）手抜きにもほどがあるだろ、となるわけで・・・
まあこれはER図にしか書いていないから そういうもん なんですが、常識的には1対1にならないと困ります。
やはりそうですよね。キーがうんぬんで簡単に決まるものではないですよね。
解説に、カーディナリティが断定できるような書き方がされていたので、気になって質問しました。
自分は普段は問題文を読み、そしてテーブルの関係性をイメージしながら解いていたのですが、いちテストという観点で、時間が足りないことが多かったので、横着できるところはしてしまおうと思い、確認させていただきました。
従来通り、常識的に考え、そしてきちんと問題文を読みながら解いていきます。
丁寧な解説ありがとうございました！
関係データベースのカーディナリ特定 理論の確認 [4017]
3投稿目さん(No.1)
2テーブル間のカーディナリの特定の方法について確認したいことがあります。
一般的にAテーブルの主キーがカーディナリで結ばれたBテーブルの外部キーとなっている場合、AテーブルとBテーブルの関係性は「1対多」になると認識していました。
実際、R2秋のデータベース設問1aの解説文にて、
https://www.ap-siken.com/kakomon/02_aki/pm06.html
と表記されていました。
しかし、H31春データベース内の処方箋テーブルと外来受診テーブルの関係性は1対多とはなっていません。
https://www.ap-siken.com/kakomon/31_haru/pm06.html
こちらの理論はあくまで一般的なもので、例外も存在するのでしょうか。
もしそうであれば、基本的にE-R図から機械的にカーディナリを特定することは避けた方が良いということでしょうか。
皆様から回答をいただけることが日々本当に励みになっております。
よろしくお願いします。
一般的にAテーブルの主キーがカーディナリで結ばれたBテーブルの外部キーとなっている場合、AテーブルとBテーブルの関係性は「1対多」になると認識していました。
実際、R2秋のデータベース設問1aの解説文にて、
https://www.ap-siken.com/kakomon/02_aki/pm06.html
>関係データベースの理論上、主キー属性と外部キー属性の関連があるとき、主キー側エンティティが"1"、外部キー側エンティティが"多"になるので、E-R図を見て機械的に判断してしまってもOKです。
と表記されていました。
しかし、H31春データベース内の処方箋テーブルと外来受診テーブルの関係性は1対多とはなっていません。
https://www.ap-siken.com/kakomon/31_haru/pm06.html
>関係データベースの理論上、主キー属性と外部キー属性の関連があるとき、主キー側エンティティが"1"、外部キー側エンティティが"多"になるので、E-R図を見て機械的に判断してしまってもOKです。
こちらの理論はあくまで一般的なもので、例外も存在するのでしょうか。
もしそうであれば、基本的にE-R図から機械的にカーディナリを特定することは避けた方が良いということでしょうか。
皆様から回答をいただけることが日々本当に励みになっております。
よろしくお願いします。
2023.03.07 15:37
3投稿目さん(No.2)
申し訳ありません。カーディナリではなく、カーディナリティでした。
2023.03.07 15:48
GinSanaさん(No.3)
★AP プラチナマイスター
この投稿は投稿者により削除されました。(2023.03.07 19:38)
2023.03.07 19:38
GinSanaさん(No.4)
★AP プラチナマイスター
>関係データベースの理論上、主キー属性と外部キー属性の関連があるとき、主キー側エンティティが"1"、外部キー側エンティティが"多"になるので、E-R図を見て機械的に判断してしまってもOKです。
>こちらの理論はあくまで一般的なもので、例外も存在するのでしょうか。
>もしそうであれば、基本的にE-R図から機械的にカーディナリを特定することは避けた方が良いということでしょうか。
まあ、そりゃあ1対1になるようなこともあります。たとえば受注明細単位と売上明細単位が一緒になるという仕様の場合、1対1だから矢印じゃないとかそういうのです。でも、基本は1対多（矢印の起点が1、矢印の尖った方が多。たとえば、受注伝票に営業担当のIDが書いてあって、営業担当のマスタから引いてきたようなことを考えるとそうなる）です。例外になる場合、本文に1対1になるような記述がある（これはDBスペシャリストでも同様）ので、ああ、これは1対1だなと判断出来たら矢印消して棒線にするでもいいんじゃあないでしょうか。
※なお、多対多になったら連関エンティティを作って1対多を作るので考える必要はありません。
2023.03.07 19:38
GinSanaさん(No.5)
★AP プラチナマイスター
>しかし、H31春データベース内の処方箋テーブルと外来受診テーブルの関係性は1対多とはなっていません。
まあ、常識的に考えると、世の中の薬局で全く同じ処方箋IDで薬を出したら（≒同日に同じ薬剤を出すってことになる）手抜きにもほどがあるだろ、となるわけで・・・
まあこれはER図にしか書いていないから そういうもん なんですが、常識的には1対1にならないと困ります。
2023.03.07 19:43
pixさん(No.6)
★AP シルバーマイスター
横から失礼いたします。
説明を補足させていただきます。
テーブル（エンティティとも）には大まかに2種類あります。
マスタ - トランザクション（リソース - イベントとも）
マスタ：処理を実行する前に必要な行（情報）を格納したテーブル
トランザクション：処理中に行が追加されてゆくテーブル
基本的に以下のようなパターンになります。
・カーディナリティが1対多になるケース（外部キーがマスタ）
マスタ <- マスタ
マスタ <- トランザクション
以上のようなケースはマスタの情報を参照しているため1対他になります
・カーディナリィが1対0以上になるケース（外部キーが親トランザクション）
親トランザクション <- 子トランザクション
売上 - 売上明細のようにトランザクションテーブルの中で親子関係があるときは
トランザクションの性質により、カーディナリティは1対0以上(0,1,多)になります。
テーブルがマスタかトランザクションかはE-R図の中には明記されておりません。
GinSanaさんもおっしゃっているように、アプリケーションレベルでのロジックに
依存するため、経験的に判断するしかないです。
説明を補足させていただきます。
テーブル（エンティティとも）には大まかに2種類あります。
マスタ - トランザクション（リソース - イベントとも）
マスタ：処理を実行する前に必要な行（情報）を格納したテーブル
トランザクション：処理中に行が追加されてゆくテーブル
基本的に以下のようなパターンになります。
・カーディナリティが1対多になるケース（外部キーがマスタ）
マスタ <- マスタ
マスタ <- トランザクション
以上のようなケースはマスタの情報を参照しているため1対他になります
・カーディナリィが1対0以上になるケース（外部キーが親トランザクション）
親トランザクション <- 子トランザクション
売上 - 売上明細のようにトランザクションテーブルの中で親子関係があるときは
トランザクションの性質により、カーディナリティは1対0以上(0,1,多)になります。
テーブルがマスタかトランザクションかはE-R図の中には明記されておりません。
GinSanaさんもおっしゃっているように、アプリケーションレベルでのロジックに
依存するため、経験的に判断するしかないです。
2023.03.07 19:48
3投稿目さん(No.7)
>GinSanaさん
>pixさん
やはりそうですよね。キーがうんぬんで簡単に決まるものではないですよね。
解説に、カーディナリティが断定できるような書き方がされていたので、気になって質問しました。
自分は普段は問題文を読み、そしてテーブルの関係性をイメージしながら解いていたのですが、いちテストという観点で、時間が足りないことが多かったので、横着できるところはしてしまおうと思い、確認させていただきました。
従来通り、常識的に考え、そしてきちんと問題文を読みながら解いていきます。
丁寧な解説ありがとうございました！
2023.03.07 20:04