## Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people, just like you, are talking about what matters.

• Help others & share knowledge
• Earn cash & points
Solved

# Confused About One-to-Many Relationships - SQL Relational Database Managment System

Posted on 2009-05-17
791 Views
1. Is it true that the table that carries the foreign key is considered the many side of the relationship? (Assume the table is called A)

2. I find that the table that has the foreign key always references back to the other table. In this case, table A references back to table B, so table B will have many tables points at it. Thus, table B is considered the "many" side of the relationship because it has many tables points at it. While 'A' table is considered the "one" side of the relationship because it can only points to one record in table B. Therefore, the statement in question 1 is false.

I'm quite confused about the whole concept little bit...
0
Question by:F-J-K

LVL 9

Accepted Solution

cdaly33 earned 250 total points
ID: 24406319
Using the example of a Customer table and an Order table, taking a single Customer who may or may not have many orders.  So a CustomerID would be the primary key (the 1 side of the equation) of the Customer table.  In the Order table there would be a column called CustomerID which would be the foreign key back to the Customer table.  There can be many Order records for a Customer so that would be the many side of the equation.
0

LVL 22

Assisted Solution

dportas earned 125 total points
ID: 24406374
"One to Many", "One to One", "Many to Many" are Entity Relationship Modelling terms (ER modelling). They refer to the Cardinality of the relationship in question. In a relational database, cardinality means the number of rows that participate in the relationship. For example, the relationship Manager ->Employee could be a One to Many relationship (One row in the Manager table associated with Many rows in the Employee table). The foreign key would go on the Employee table and would reference the Manager table.
0

LVL 4

Expert Comment

ID: 24406382
1.  No, the table that carries the foreign key would be the "one" side of the relationship.
2.  No, table B is the "one" side of the relationship.

Think of "one" and "many" not in terms of how many tables are pointing to a table, but like this...

"One" Customer can have "Many" Orders.
Or, one company can have many customers.
One order can have many items.  Etc...
0

LVL 46

Expert Comment

ID: 24406405
0

LVL 9

Assisted Solution

tculler earned 125 total points
ID: 24407827
I think this concept eludes a lot of people new to RDBMS's (Relation Database Management Systems). A relationship, which is usually a one-to-many, must consist of a Primary Key on the ONE side table pointing to the Foreign Key of the MANY side table. For example, depending on how you organize your database, ONE customer will have MANY orders/transactions/etc. However, you probably wouldn't say that one transaction has many customers. Sure, the customer could have other customers with him or her, but the transaction should only register to one customer.

Remember, one-to-many refers to two tables: no more, no less. When you have a one-to-many relationship, you're not saying one table poitns to many tables. You're saying that ONE record on the ONE sided table points to MANY records on the MANY side table, just like the customer example I gave.

Just think about it logically, and you'll get it :)

Hope I helped,
Nate
0

LVL 1

Author Closing Comment

ID: 31582357
0

## Featured Post

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

### Suggested Solutions

Never store passwords in plain text or just their hash: it seems a no-brainier, but there are still plenty of people doing that. I present the why and how on this subject, offering my own real life solution that you can implement right away, bringin…
When table data gets too large to manage or queries take too long to execute the solution is often to buy bigger hardware or assign more CPUs and memory resources to the machine to solve the problem. However, the best, cheapest and most effective so…
Using examples as well as descriptions, step through each of the common simple join types, explaining differences in syntax, differences in expected outputs and showing how the queries run along with the actual outputs based upon a simple set of dem…
Polish reports in Access so they look terrific. Take yourself to another level. Equations, Back Color, Alternate Back Color. Write easy VBA Code. Tighten space to use less pages. Launch report from a menu, considering criteria only when it is filled…