I would like to ask a question about Database Management.
So for example, I have a Relationship called 'Attends' with a few Relationship Attributes.
So when I turn this relationship into an Expanded Entity Relation Diagram, can an Attribute of this Relation turn into a Primary Key when this turns into an Entity?
Thank you in advance.
Between two entities is a 1 to many relationship but this relationship has an attribute of its own.
When converting these entities to a relational schema what will happen to this attribute? Does it get joined into the entity on the many side of the relationship like a foreign key does? I don't think it should be another separate relation because that is like saying it's an associative entity which it's not.
Any help is greatly appreciated.
In ER as described by Chen, each entity relation and each relationship relation would map to a separate table (except weak entities/identifying relationships). However, one-to-one and one-to-many relationships commonly get denormalized to reduce the number of tables. In this case, attributes of the relationship become attributes of the determining entity.
Associative entities occur when a relationship is the subject of a relationship. Recording a relationship in a separate table doesn't make it an associative entity. Nor do attributes make a relationship into an entity. Attributes on relationships are quite normal in the ER model.
I have a question about the ER diagram below.
Question: If there are 2 relationships born and live from actor to place entity.
Do they both have the same foreign key which is place_no? So does that mean I just put the foreign key in Actors relational model and that's it or do I have to make a table for Born?
Because an actor is born in a place and lives in a place... so how would it be possible to differentiate between 1 place_no FK?
You have to specify the arity of the relationships. You can map the conceptual 1:n relationships directly in relational model using just foreign keys. For n:m relationships you should use junction tables.
Since it seems that the relationships here are both n:1 since a person can be born in just one place and (based on your comments) we can also assume that a person can only live in one place at the time we can map these relationships as foreign keys.
As an example in SQL (assuming we have two relations actor and place, the code is in CREATE code of actor):
[...]
born int REFERENCES place(place_no),
lives int REFERENCES place(place_no),
[...]
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,
... 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.
I I do not see a reason to have a third table for UserId and TeamId. Now if you have more infromation for TeamManager I would create a manager table. Is it one user per team? Can a user be a Manager?
When having a one-to-one relationship in a database the other table has a foreign key ID (in this example). And in a one-to-many relationship the table contains many foreign keys.
But does the database know whether this is a one-to-one or one-to-many relationship? Are the relationships that I make in an ER-Diagram only to indicate where there should be foreign keys when making the actual tables?
What is the difference between one-to-one and one-to-many relationship in a database?
In a sense, all the relationships we talk about are not known to the database, they are constructs we have invented to better understand how to design the tables.
The big difference in terms of table structure between one-to-one and one-to-many is that in one-to-one it is possible (but not necessary) to have a bidirectional relationship, meaning table A can have a foreign key into table B, and table B can have a foreign key into the associated record in table A. This is not possible with a one-to-many relationship.
One-to-one relationships associate one record in one table with a single record in the other table. One-to-many relationships associate one record in one table with many records in the other table.
To enable one-to-one relationship you need to add unique constraint to foreign key. It is not possible to have two foreign keys for each table as it will be impossible to create records.
Im having trouble understanding what the actual question is.
Your analysis is for the most part correct, in that if you have a 2 tables, and table2 has a foreign key to table one, it could be either a one-to-one or a many-to-one.
Your sentence "And in a one-to-many relationship the table contains many foreign keys."
The table of the 'many' side still contains one column that is a foreign key, its just that more than one row can have the same foreign key value (many rows point to one parent).
Also note that you can put the foreign key on the parent table, to the child, instead of the other way around. In this way, you can prevent one-to-many if you want to do that. Also note that in this way, more than one parent can share a child, which might or might not be what you want.
The database-level equivalent of a 1:1 vs. 1:m is having a unique index on the foreign key column. Note that this will only work for 1:1, NOT 1:0..1, as null is considered when evaluating uniqueness. There are workarounds for this restriction, but that's it at the basic level.
Similarly by example, a product has only one product code, so it's one-to-one relationship (product <-> ABC123), but a customer can purchase more than one product, so it's one-to-many relationship (person <->>>product).
well, you are right, this relation is important for you, but not for db itself. When you have two tables, one with your basic information, and another one with your detailed information.. for both tables you are you, so it is one-to-one relation, you can not map your data to somebody else.
Now add third table "cities" and one of your information points to city you live in - this is example of one-to-many (one city can be used, and should be used for many people).
one-to-many / one-to-one just show how your tables interact. And all the time, you want to "save" rows/columns in table not duplicating them you will use one-to-many relation with another table. Or many-to-many :)
Let's assume you have a table with two attributes A and B. If A is a candidate key and B is not then the relationship between A and B is 1 to many. If both A and B are candidate keys then the relationship is 1 to 1.
Given table A and B if
A and B have a strict 1 to 1 relationship
For every B instance, there will always be an A instance
The best approach is to make the primary key of B also a foreign key referencing A. This is also called "Table per Type Inheritance" and the "is a" relationship. There are other ways to enforce a unique foreign key, but using the primary key makes the relationship clear in the schema and in ER diagrams.
Of course there are always other scenarios, and if your design doesn't meet both of the criteria above, you'll have to use another approach.