データベーススペシャリスト 試験情報＆徹底解説

質問1、関数従属性について教えて下さい。
社員名や年齢は、社員IDに関数従属しますか？
それとも会社IDと社員IDに関数従属しますか？
それともケースバイケースですか？
それとも●●に関数従属しますか？
質問2、次のテーブルを正規化するとどうなります？
社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},会社名,社員名,年齢
0001,0001,会社A,太郎,20
0001,0002,会社A,花子,30
0002,0001,会社B,浩二,40
質問3、もし質問1と質問2の回答に矛盾があればどのように説明すれば良いでしょうか？

質問1
→ケースバイケースです。社内システムなど１つの会社のみで充足する場合は、社員IDごとの管理で社員情報は一意に決まるので、複合主キーは不要です。
複数の会社で構成されるシステムの場合は、会社ごと社員IDごとで管理する必要があります。そのため複合主キーは必要です。

質問2
→正規化すると以下のようになります。
会社テーブル(主キー:会社ID)
{会社ID},会社名
0001,会社A
0002,会社B

社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名,年齢
0001,0001,太郎,20
0001,0002,花子,30
0002,0001,浩二,40

質問3
→具体例があれば良いですが、正規化ですので矛盾はありません。

あたまさん、回答ありがとうございます。

>回答1、ケースバイケース。
>複数の会社で構成されるシステムの場合は、会社ごと社員IDごとで管理する必要があります。
>そのため複合主キーは必要です。

  正直、腑に落ちません。社員ICカードが決まると社員名と名前が決まる、社員名と年齢は社員ICカードに関数従属すると理解すればいいのでしょうか。名前と年齢を決めるのに、会社という概念が必要になるなんて、摩訶不思議な話だと思うのですが。

>回答2:会社情報は外部参照するけど、個人情報は外部参照しない、会社ごと社員IDごとで管理。
   
  次のように、正規化するのが正解だと思うのですが、どうでしょう。転社ごとに会社名や社員名や年齢をゼロから打ち込む、なんて事をしていたら整合性が崩れる懸念があるから、どちらも外部参照にする。
※正規化後、社員名の外部参照は、個人番号のような代理キーを導入して切り替えます。
会社テーブル(主キー:会社ID)
{会社ID},会社名
0001,会社A
0002,会社B

社員テーブル(複合主キー:会社ID,社員ID)
{会社ID,社員ID},社員名
0001,0001,太郎
0001,0002,花子
0002,0001,浩二

個人テーブル(主キー:社員名)
{社員名},年齢
太郎,20
花子,30
浩二,40

あたまさんがケースバイケースと書いたのは
前提とするテーブル構造をlogres_Fanさんが書かれていないためです。

質問内容から読み取れるのは
①１つの会社だけで完結している社員管理
②親会社/子会社/グループ会社などで共用している社員管理（各会社毎に採番）
このどちらも想像できるため、あたまさんがNo2のように回答しました。

なので、あたまさんの回答通り
・上記①の場合は、社員IDに関数従属
・上記②の場合は会社IDと社員IDに関数従属
といった、ケースバイケースとなります。

logres_Fanさんが懸念している上記②の場合に
転社などによってまたゼロから～という部分はその通りで
各会社全体でそれぞれの社員に一意の個人番号を設ける手法はアリですし
そうではなく懸念部分をDB外のシステムで解決する事もあります。
（社員名でのキーは同姓同名が発生する可能性があるため
  正規化前になんらか対応しておく必要があります。）

ただこの試験で求められている正規化は
問題文の項目を無駄なく分けるというには・・・という内容ですので
どこにも記載されていないような個人番号などが突然出てきても
不正解か減点かになってしまう恐れがあります。

実務として提案する分には、良いのではないかと思います。

ｍｋｋさん、回答ありがとうございます。

> ただこの試験で求められている正規化は…
> どこにも記載されていないような個人番号などが突然出てきても不正解か減点かになってしまう恐れがあります。

  受験生の方へ。ｍｋｋさんのご指摘の通り、試験問題の何処にも記載されていない用語を用いて解答すると、不正解又は減点になる恐れがあります。配慮不足でした、すみません。

> あたまさんがケースバイケースと書いたのは
> 前提とするテーブル構造をlogres_Fanさんが書かれていないためです。
> ②親会社/子会社/グループ会社などで共用している社員管理（各会社毎に採番）
> ・上記②の場合は会社IDと社員IDに関数従属

  ご指摘を受けて再検討します。

> 各会社全体でそれぞれの社員に一意の個人番号を設ける手法はアリですし
> そうではなく懸念部分をDB外のシステムで解決する事もあります。

  一意の個人番号を設ける手法に賛同頂きありがとうございます。DB外のシステムで解決する手法には驚きました。貴重なご経験を教えて頂き、ありがとうございます。

logres_Fanさん、理解に繋がり良かったです。
ｍｋｋさん、追記いただきありがとうございました。

(個人番号と聞いて、R3のJANコードを思い出しました、、。一意に決まるか決まらないかの論争がどこかでありましたね)

  質問1を再検討しました。成立すべき関数従属性についてご意見募集します。
親会社、子会社、グループ会社を扱わない場合が①、扱う場合が②と③です。
①１つの会社で社員IDを採番する場合(主キー:社員ID)
{社員ID},社員名,年齢
0001,太郎,20
0002,花子,30
0003,浩二,40

成立すべき関数従属性
{社員ID}→社員名
{社員ID}→年齢
成立すべきでない関数従属性
{社員名}→社員ID、{社員名}→年齢
{年齢}→社員ID、{年齢}→社員名
{社員ID,社員名}→年齢
{社員ID,年齢}→社員名、{社員名,年齢}→社員ID

②複数の会社かつ会社毎に社員IDを採番する場合(複合主キー:会社ID,社員ID)
{会社ID,社員ID},会社名,社員名,年齢
0001,0001,会社A,太郎,20
0001,0002,会社A,花子,30
0002,0001,会社B,浩二,40

・成立すべき関数従属性
{会社ID}→会社名
{会社ID,社員ID}→社員名
{社員名}→年齢
・成立すべきでない関数従属性
{会社ID,社員ID}→会社名
{会社ID,社員ID}→年齢
…etc

③複合の会社かつ全社共用で社員IDを採番する場合(複合主キー:会社ID,社員ID)
{会社ID,社員ID},会社名,社員名,年齢
0001,0001,会社A,太郎,20
0001,0002,会社A,花子,30
0002,0003,会社B,浩二,40

・成立すべき関数従属性
{会社ID,社員ID}→属性項目なし(定義域制約)
{会社ID}→会社名
{社員ID}→社員名
{社員ID}→年齢
・成立すべきでない関数従属性
{会社ID,社員ID}→社員名
{社員名}→年齢
…etc

この投稿は投稿者により削除されました。(2022.08.15 22:34)