Explanation of ER model to functional dependencies solution - relational-database

Question

I am trying to understand solution on one exercise that translates ER model to functional dependencies.
As you can see above, we only have relation names and nothing else besides that, and by solution, they somehow come up to conclusion that
mother, daughter → father
father, daughter → mother
mother, son → father
father, son → mother
And that moreover we can infer additional f dependencies to represent real world more accurately:
mother, son → father
father, son → mother
What I don't understand here is how can we base our translation to functional dependencies by just looking at the relation names, since I always when I did translation from ER model to relational model, I did it by looking at attribute names. Is it possible that there is something wrong in this exercise, or that the task giver was just trying to make us translation to functional dependencies more closer to me as a student first time looking at it (i.e. by making in more educational)?

Answer 1

TL;DR
As you can see above, we only have relation names and nothing else besides that
Well, there are some lines, each with a name & a digit or letter.
There isn't anything strange about the assignment. Go to your textbook & find out exactly what every technical term & graphic element means. (In particular you might be confused by the meaning of "relationship" or your cardinality labels.) How the solution arises follows.
The R in ERM (for the Entity-Relationship Model) stands for "relationship" as in an n-ary association. Similarly the R in RM (for the Relational Model) uses "relation" per its connected meanings in mathematics as an n-ary relationship/association & as a set of tuples of values that participate in or satisfy such a relation, that are so related/associated. But these ER & RM "relationships" are not participations or FKs (foreign keys), which get called "relationships" or "relations" by methods & presentations that claim to be ER or relational but are not.
A Chen ER diagram has a box per entity type, a diamond per relationship type & a line per participation. A name on a line gives the attribute in the relationship for that participation. A 1 or N label on a line gives cardinality information for that participation.
Each ER entity & relationship type gets a representing relation. Hence a relation per box & diamond & a FK per line. A FD (functional dependency) applies to a relation. So we can say that a FD applies to a relationship.
Presumably the diagram's relationships/relations are like:
-- man [son] is the son of man [father] & woman [mother]
isSon(son, father, mother)
-- woman [daughter] is the daughter of man [father] & woman [mother]
isDaughter(daughter, father, mother)
There are many styles of information modelling methods & diagrams & cardinality labels. Your diagram seems to be one of the Chen styles of true ER. A cardinality label on a participation by an entity type in a relationship type says how many entities of that type can participate with or share a given instance/subtuple of the other participant types over all situations that can arise. A 1 means exactly one & an N means one or more. An n-ary relationship cardinality is a sequence of n such participation cardinalities, "X:Y:..." or "X to Y to ...".
Notice that such a sequence assumes a certain order of entities/attributes. Notice that for a binary relationship N:1 for one order means 1:N for the reverse order. (hasMother(child, mother) is N:1 when/iff isMother(mother, child) is 1:N.) Notice that every entity/attribute in X:Y:... asserts about "a given" or "one given" subtuple of others. That "one" is not from a cardinality label. It's from the phrase that the label is plugged into. In particular it's not from a 1 in a binary N:1 or 1:N.
From your lines we get:
isSon
N sons participate with a given father-mother pair
1 father participates with a given son-mother pair
1 mother participates with a given son-father pair
isDaughter
N daughters participate with a given father-mother pair
1 father participates with a given daughter-mother pair
1 mother participates with a given daughter-father pair
(Binary X:Y is often sloppily expressed as "X entities have Y of the other & Y entities have X of the other". It is intended to mean "a given 1st appears with Y of the other & a given 2nd appears with X of the other". That phrasing doesn't generalize to n-ary relationships or X:Y:.... (A given nth entity appears with how many of what?) That sloppy expression also intends to mean, using the nth letter with the nth entity, "X of the 1st appear with a given subtuple of the others & Y of the 2nd appear with a given subtuple of the others". Which is the Chen n-ary interpretation for n=2. You might think that we could use X:Y:... to mean "a given 1st appears with X subtuples of others & a given 2nd appears with Y subtuples of others & ...". However, that turns out not to be as useful & it contradicts the normal meaning of binary X:Y by taking it to mean what Y:X normally means.)
This particular form of cardinality constraint happens to tell us something rather directly about some FDs (functional dependencies) that hold & don't hold in the representing relations. Observe lines with 1s & Ns paralleling some FDs that hold & don't hold:
isSon
{father, mother} → {son} does not hold
{son, mother} → {father}
{son, father} → {mother}
isDaughter
{father, mother} → {daughter} does not hold
{daughter, mother} → {father}
{daughter, father} → {mother}
What we can determine about FDs per "the real world" depends on what we consider that to encompass & what exactly each relationship's/relation's meaning is--its tuple membership condition/criterion--its (characteristic) predicate. Constraints--including FKs & FDs--are determined by the predicates & the situations/states that can arise. In turn that depends on the meanings of words used in the specification including those expressing the predicates & business rules.
If the predicates above involve biological sons & daughters then we can reasonably expect the given cardinalities & also expect that {son} → {father, mother} & {daughter} → {father, mother}. (Note that those FDs imply the above FDs that determine {father} & {mother} & their cardinality labels.)
However for other predicates & business rules (per what expressions express them & what the words in them mean) & notions of "the real world" we might have different FDs. It all depends on what exactly is intended by "father", "mother", "son" & "daughter", or for that matter "man" & "woman", and what associated rules you assume re what situations/states can arise for your application--marriage, divorce, adoption, disinheritance, parenting, death, etc & just what people you are drawing from & when, etc. One really needs to be really clear.
But you don't clearly give the predicates or the business rules. (Or a legend for interpreting your diagram.) So it's hard to say what other non-implied FDs might hold or not hold.
So there isn't anything strange about the assignment.
PS When you are stuck go to your textbook & find out exactly what everything means & ask a question about where you are first stuck understanding or following a specific definition, axiom/assumption, theorem/fact or algorithm/method/process/heuristic. This question is not from being stuck creatively; here you are supposed to mechanically apply a method in your textbook.
PS Relational Schema to ER Diagram /cardinalities difference