Home/ Questions/Q 7845759
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-02T17:21:07+00:00

I am struggling to model a scenario and came across a question that, while

  • 0

I am struggling to model a scenario and came across a question that, while normalizing table should we consider FK also as key to determine whether a field should be in same table or other table?

For example, I have Users and Teams tables (One user may ZERO or more teams considering different sports). 

Owner                                       Teams

 -----                                    -------- 
OwnerID ---PK                              TeamID  ---PK
OwnerName                                  OwnerID    ---FK  
                                          TeamManager
                                          TeamLogo

If we observe this relation, TeamManager and TeamLogo are completely dependent (functionally) on only TeamID not at all dependent UserID (am I correct in understanding this?). Should we have another table for UserID and TeamID to establish relationship?

Any suggestions would be really helpful.

This is not a home work. I am modeling for a website and improve my knowledge on normal forms to get best scalable database design.

Thank you,

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    … should we consider FK also as key to determine whether a field should be in same table or other table?

    Being a child endpoint of a referential integrity is orthogonal to being a key (i.e. FK child may or may not be a key). The name “foreign key” only refers to the parent endpoint, which is required to be a key (in most DBMSes).

    So, in your example, Teams.OwnerID does not have to be a key (and actually isn’t, judging on your description).

    If we observe this relation, TeamManager and TeamLogo are completely dependent (functionally) on only TeamID not at all dependent UserID (am I correct in understanding this?).

    Yes, you are correct.

    The Teams is in 3NF because all attributes functionally depend on key, whole key and nothing but the key (so help me Codd 😉 ).

    Here is why:

    • Nothing depends on a key subset, so this is 2NF (in fact, there is no “key subset” since key is just one attribute).
    • As you already noted, TeamManager and TeamLogo do not functionally depend on OwnerID, so you do not have a transitive dependency, so this is 3NF.

    Should we have another table for UserID and TeamID to establish relationship?

    For modeling a simple 1:N relationship like this: no.

    Modeling M:N would be a different matter.

    So unless there are some additional details you didn’t mention, this model looks nicely normalized to me.

    • 0