So far in this series we have discussed database design, creating tables, and constraints. We've brought up the concept of foreign keys, but we have not explained how to create them. That is the goal of this video and the upcoming videos. We want to study those foreign keys! Let's make them not so foreign. Let's learn the proper way to define a foreign key.
As a reminder, a foreign key is a column that references a column of another table. The column it references must either be a primary key, or have the UNIQUE constraint. This means that every value inside of the column that is labeled as a foreign key, there must be that value in some row of the referenced column. As an example, imagine that we have the users table, and we have a table service_requests. We could have a column in the service_request that references a column in the users table. Usually this would be the primary key that is referenced, but there is nothing stopping you from referencing a unique column. Just for fun, let's go through an example using the username column.
If we have a service_requests table, every single row within the table is going to be what some would consider an instance of a service_request. This means that the table columns are like the blueprint for what a service request looks like and then each row is an individual service request. If we have one of the columns labeled as a foreign key to the username of the users table, what does that mean practically? It means that for a single row, the value for that column must be a value that exists in the users table. We could have a service_request submitted by a user with the username of Yoloswagman. This means that there must be a row inside of the users table that has the value Yoloswagman for the username column.
This brings up the concept of parent and child relationships. Yoloswagman in this situation is the parent, and his service request is the child. When we draw it out, it makes sense why a primary key must be UNIQUE. If we had two Yoloswagmans, the child would not know which column is the parent. The same applies if we were using IDs and we had So remember, always reference a primary key or a column with the UNIQUE constraint.
Now, I have a question for you. Do foreign keys automatically have the UNIQUE constraint, just like primary keys? The answer is no. A parent row can have many child rows. It makes sense because the user could submit multiple service requests.
Can we force the column to be unique? Absolutely. If that was the case, the user could only make one service request.
Another question. Do foreign keys automatically have the NOT NULL constraint, just like primary keys? The answer is no. Essentially what this means is that a child could be created with no parent.
Can we force the column to be NOT NULL? Absolutely. It is ok in some situations to allow the row to be null, but in this situation it makes no sense. It would be wise for us to add that constraint ourselves.
So now that you understand some more differences between primary and foreign keys and parent child relationships, take all of these questions into consideration when you are creating foreign keys.
In the next video, we are going to start a small project that is going to require multiple tables. We'll take a video to design our structure and then we'll get to creating those foreign keys in Oracle SQL Developer. Stick around and if you like these videos please be a serious supporter and subscribe to my channel.
HELP ME! http://www.patreon.com/calebcurry
Subscribe to my newsletter: http://bit.ly/JoinCCNewsletter
More content: http://CalebCurry.com
Amazing Web Hosting - http://bit.ly/ccbluehost (The best web hosting for a cheap price!)