https://www.ap-siken.com/kakomon/29_haru/pm06.html
部署マスタとユーザのエンティティ間の関連及が二種類あるのが分かりません
ユーザエンティティに関しては自分自身に戻る関連もあり分かりません。

どういいう意味なのでしょうか

>ユーザエンティティに関しては自分自身に戻る関連もあり分かりません。

これは自己参照っていって、上司のユーザIDを自分のテーブルから引いてきているからこういうことになっているんですね。組織体系とかの木構造のエンティティとかだとよくあります。

部署マスタに向けて外部キーがはってあるから矢印を引かなきゃで、部長は部署で重複しないから1対1になったんでしょうね、たぶん。書いてないので推測ですけど。

自己参照なのですね。あと何故、1：多なのでしょうか？

そのように考えれば良いですね！  でも二重にエンティティ間の関連があるは気持ち悪いです………

>あと何故、1：多なのでしょうか？
自己参照の件であれば、それはある上司に複数部下がいたら参照対象が1対多になりますよね。上司は1人しか部下を持てない  という変なルールがあったら、1対1です。

ありがとうございます。
でもまだ少しわかりません。自己参照で上司の名前を見に行っているのなら、見に行った先に部下の情報はありませんが……？

あと、別のことですみません。ユーザと承認者情報にもエンティティ間の関連が1:多であります。でもユーザの属性のどれも承認者情報の属性に一致するものが無く、これも気持ち悪くよく分かりません……。  でもこれはそのユーザが申請した場合に承認者が数人いるということを意味すると思えば良いのでしょうか……？

>自己参照で上司の名前を見に行っているのなら、見に行った先に部下の情報はありませんが……？

例えば、
で引けばその上司の直属の部下が全員わかりますよね。

>ユーザと承認者情報にもエンティティ間の関連が1:多であります。でもユーザの属性のどれも承認者情報の属性に一致するものが無く

承認者ユーザIDですね。

ありがとうございます。
でも、問題の流れから部下の情報までは得る必要がない（誰かが申請した時点でそのユーザーから承認者を見つければ良いだけのはずで、上司からその部下を探しその部下が申請したかを見る必要は無いはずです。）ことと、上司のIDだけ知りたいのならそもそも自己参照する必要がないということもあり、（やはり書いてないので想像に頼らざるおえないところがあると思いまずが）ふに落ちません………

あと、承認者ユーザIDだとすると、1:多はたぶん１：（１以上）という意味なので、承認者になりえないユーザーによっては０になってしまうのでよく分かりません……

この投稿は投稿者により削除されました。(2021.08.13 15:19)

>でも、問題の流れから部下の情報までは得る必要がない（誰かが申請した時点でそのユーザーから承認者を見つければ良いだけのはずで、上司からその部下を探しその部下が申請したかを見る必要は無いはずです。）ことと、上司のIDだけ知りたいのならそもそも自己参照する必要がないということもあり、（やはり書いてないので想像に頼らざるおえないところがあると思いまずが）ふに落ちません………

この問題で部下が必要になるかとかそんなことはどうでもよくて、質問の原点に立ち返れば元々記載のあった自己参照の矢印はどういう意味かって話です。
マスタとして上司のIDを持たせると出題者が意図を持った以上、リレーションシップ上は自己参照の関係を有する、それ以上でもそれ以下でもないんです。
部下うんぬんの話が出てきたのは、あなたの追加の質問で部下の情報はどうとるの？と聞かれたから一般的な解法を答えただけで、出題者の世界観で部下の扱いをどうするかまではどうでもいいと考えているからでてきていないだけです。

>あと、承認者ユーザIDだとすると、1:多はたぶん１：（１以上）という意味なので、承認者になりえないユーザーによっては０になってしまうのでよく分かりません……
矢印とかのカーディナリティってそういうので決まるんじゃないですよ。あるユーザが複数の承認者情報の承認者になってたら、カーディナリティは2以上になるじゃないですか。
1人のユーザは1つの承認者情報の承認者にしかなれない、とかであれば1対1と認識できる、というのは昨日も書きましたが、みんながみんな承認者に入らないから0になる（これは白丸のゼロを含む、という）とか、そういうので決まるわけではありません。今回はゼロを含むか含まないかは問われていないのであえて書きませんでしたが、そういう観点もあるにはあります。

矢印の意味とかの立ち返りは
１対多はどういうモデルか · GitHub
gist.github.com/momotar/7c3b694413ae5ba90996
とかを参考にしてください。
あくまで2つのエンティティがあって、Aから見てBに対し1対1か1対多か、Bから見てAに対し1対1か1対多か
で決まります。
www.db-siken.com/kakomon/24_haru/am2_4.html
データベーススペシャリスト平成24年春期 午前Ⅱ 問4
にいい復習内容があります。
こういう意味で多重度、矢印になるか直線になるかが決まります。

すでにたくさん突き合わせてしまいすみません。そしてありがとうございます。
ちなみに、ぼくは基本情報はデータベースも選択し受かっただけの未経験のド素人で純粋に分からないとこを考えてるだけです。まだ大丈夫だと思いますがもし何かかに触っていたとしたら、まったく悪気がないので申し訳ありません。平成24年春期 午前Ⅱ 問4は是非時間があるときやってみます！

部下の参照とかは関係に無いと分かりました。ありがとうございます。あと分からないのは、自己参照の時になぜ
select * from ユーザ where ユーザID = :上司ユーザID  
としなかったかです。それともこうすると自己参照とはならないのでしょうか？

つまり、そのユーザがある承認者になってから考えればよく、すると１：（１以上）という認識でも成り立っている。ということと、そもそも1:多は１：（０以上）と考える場合もあるにはあるということでしょうか？

>部下の参照とかは関係に無いと分かりました。ありがとうございます。あと分からないのは、自己参照の時になぜ
>select * from ユーザ where ユーザID = :上司ユーザID  
>としなかったかです。それともこうすると自己参照とはならないのでしょうか？

自己参照は、外部キーを張るときのはなしですからね。
だと、クエリとして求めるときの話で、キー制約としての観点としての解答にはならないですね。
上司ユーザIDは同じマスタにいるユーザのだれかだろ、ってなれば、登録時にその上司となるユーザが存在するかを確認した上で部下のデータを登録（更新）するわけです。

クエリとして求める、をもう少し深堀するなら、上司、そのまた上司を社長までピラミッド的にどうつながるかを求めるなら、再帰という構文を使います（WITH RECURSE）。今回は特に関係ないので気になったら調べてください。
応用でも出題はされたことはあります。この前解説しましたが。
https://www.ap-siken.com/bbs/2715.html

>つまり、そのユーザがある承認者になってから考えればよく、すると１：（１以上）という認識でも成り立っている。
その認識でよいです。
>ということと、そもそも1:多は１：（０以上）と考える場合もあるにはあるということでしょうか？
あります。むしろ１：（０以上）のケースのほうが多いでしょうね。

この投稿は投稿者により削除されました。(2021.08.13 17:09)

ちなみにキー制約は
で設定したことになります。
テーブル設計（構築）の段階の話なので、リレーションシップの参照うんぬんというのはCRUDのクエリを発行するタイミングの話ではありません。

ここまで付き合って下さりありがとうございました！感謝です。
大分わかってきました！  さらに詳細とか専門用語とかかっこよいです！  
また、教えていただいた深いところはそのうち考えてみたいかとおもいます。

本当にありがとうございました！