Solved

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

Posted on 2009-05-17
6
788 Views
Last Modified: 2012-06-21
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
Comment
Question by:F-J-K
6 Comments
 
LVL 9

Accepted Solution

by:
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

by:dportas
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

by:TimSledge
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
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 46

Expert Comment

by:tbsgadi
ID: 24406405
0
 
LVL 9

Assisted Solution

by:tculler
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

by:F-J-K
ID: 31582357
Well Answered
0

Featured Post

IT, Stop Being Called Into Every Meeting

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

This article explains all about SQL Server Piecemeal Restore with examples in step by step manner.
In this article we will get to know that how can we recover deleted data if it happens accidently. We really can recover deleted rows if we know the time when data is deleted by using the transaction log.
Video by: Steve
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…

705 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now