I know this video is a bit dated, but it helped me immensely! The part that I was not understanding was the look up. I know look ups, because I use them in every database I design. I just couldn't figure it out on my own, but this video triggered me to understand how to get the PK 'relate' between the two tables. Now I am golden!!! Thanks again immensely!
Very nicely explained, Thank you very much. I have a question, please. I do not understand why you would have a one to one relationship in the first place, What is stopping you from adding the billing info to the customer table? In your example, there will be only one contact for each customer. Please explain why you break the tablet in half.
There are other videos on this topic, but I will try to explain based on what I think I understand. There a few reasons for using two separate tables in a one-to-one relationship. 1. If you have a main table that includes an attribute that categorizes things, such as music, but music albums that can be categorized by genre. Let's go with classical, rock, rap, country, world, and jazz. For the most part, the main table might have your PK, album name, artist, year produced, and medium type (CD, LP, tape, MP3, Google Music, etc.). However, what if you wanted to maintain additional data for music of the 'classical' type, because the additional data only applies to classical music. In this case, the additional data might include name of the orchestra or symphony that performed the piece, whether or not it was performed live or in a studio, the composer of the piece/work, the number of members in the particular orchestra that performed the piece, recording location, the year the piece was composed. As you can see, the other genres won't have all of those particular attributes, so including them in the main table might not be the best way to keep this data. Therefore, you'd create a secondary table that pertained only to the classical type of music and establish a one-to-one relationship. 2. If you had sensitive information that you wanted to restrict from certain users in certain circumstances, such social security numbers in an employee table or credit card data in a billing table, you could put that data in a separate table with a one-to-one relationship. 3. If you have a table that had an ton of attributes and you wanted to group your attributes based on certain criteria. For example, let's say you had a car table and you wanted to document data about every single part in the car. As you might imagine, your attributes might be a mile long, no pun intended. You could group your car attributes into tables, such as the engine, the electronics, the transmission, the interior, etc. 4. Another reason you might want to create a one-to-one relationship is linking certain attributes to a source outside of the database itself. For example, if you were linking data to a website, SharePoint, or another database, you might not want your main table (static attributes) to be in the same table as the table that has dynamic data or data that is accessed by certain users. Hopefully, this explanation helps others who have questions about why/how a one-to-one relationship could be leveraged in a relational database.
Your personality made this video engaging
Thank you :)
I know this video is a bit dated, but it helped me immensely! The part that I was not understanding was the look up. I know look ups, because I use them in every database I design. I just couldn't figure it out on my own, but this video triggered me to understand how to get the PK 'relate' between the two tables. Now I am golden!!! Thanks again immensely!
Very nicely explained, Thank you very much. I have a question, please. I do not understand why you would have a one to one relationship in the first place, What is stopping you from adding the billing info to the customer table? In your example, there will be only one contact for each customer. Please explain why you break the tablet in half.
There are other videos on this topic, but I will try to explain based on what I think I understand. There a few reasons for using two separate tables in a one-to-one relationship.
1. If you have a main table that includes an attribute that categorizes things, such as music, but music albums that can be categorized by genre. Let's go with classical, rock, rap, country, world, and jazz. For the most part, the main table might have your PK, album name, artist, year produced, and medium type (CD, LP, tape, MP3, Google Music, etc.). However, what if you wanted to maintain additional data for music of the 'classical' type, because the additional data only applies to classical music. In this case, the additional data might include name of the orchestra or symphony that performed the piece, whether or not it was performed live or in a studio, the composer of the piece/work, the number of members in the particular orchestra that performed the piece, recording location, the year the piece was composed. As you can see, the other genres won't have all of those particular attributes, so including them in the main table might not be the best way to keep this data. Therefore, you'd create a secondary table that pertained only to the classical type of music and establish a one-to-one relationship.
2. If you had sensitive information that you wanted to restrict from certain users in certain circumstances, such social security numbers in an employee table or credit card data in a billing table, you could put that data in a separate table with a one-to-one relationship.
3. If you have a table that had an ton of attributes and you wanted to group your attributes based on certain criteria. For example, let's say you had a car table and you wanted to document data about every single part in the car. As you might imagine, your attributes might be a mile long, no pun intended. You could group your car attributes into tables, such as the engine, the electronics, the transmission, the interior, etc.
4. Another reason you might want to create a one-to-one relationship is linking certain attributes to a source outside of the database itself. For example, if you were linking data to a website, SharePoint, or another database, you might not want your main table (static attributes) to be in the same table as the table that has dynamic data or data that is accessed by certain users.
Hopefully, this explanation helps others who have questions about why/how a one-to-one relationship could be leveraged in a relational database.