図までたくさん使っていただいて、ありがとうございました。
よく状況がわかりました。

引用：

属性の型によって、リレーションシップに変換する場合と、エンティティの属性に変換する場合があります。
今回のDate型の属性については、今のところリレーションシップに変換する仕様になっています。（Pro5.1では、属性に変換するように仕様を変える予定です）
employeeDAOの場合、Date型の属性が５つありますので、５つのリレーションシップがempoyeeDAOエンティティとDateエンティティの間に作成されています。図上でリレーションシップをドラッグしていただくと、５つの線が重なっていることをご確認いただけると思います。このため、emp_cdを主キーに変更したときに、複数のFKがDateに追加されます。それらの名前がbirthdayやjoin_dateなどの名前にならないのは、クラスとERのモデルの意味の違いによります。birthdayのようにしてしまうと、DateからみてemployeeDAOがbirthdayといった意味になり、論理的にかわってしまうと考えています。

引用：

”違い”は、リレーションシップが依存か非依存かの違いのことでしょうか？もしそうであれば、例えば、返還前の属性が、compositeかどうかなどによって、依存になる場合と非依存になる場合があります。一度ご確認いただけないでしょうか？

FKの数の違いのことであれば、作成されるリレーションシップの数が違うためです。