Hello friends and welcome back to Study Tonight's YouTube channel. In this video we will talk about DBMS keys. Students are always confused about this concept as there are many different kinds of DBMS keys and almost all are related to each other with a slight difference which makes it very difficult at times to get clear understanding. In this video we will learn what are database keys, why we need these and the different types of the DBMS keys. A database key or a DBMS key is an attribute or a set of attributes which help you uniquely identify any record or the row of data in a table. Let's take an example. The table above we have sid, sname, sbranch and s email as attributes, saving details about students. If I ask you to tell me email address of the student with name Adam, can you tell me? No because there are two students with name Adam or if I ask you tell me name of student who is in csbranch. Again there will be many students in that branch. But if you look closely, sid column has unique value for all the rows of data and the s email column also has unique email addresses and these two columns can be used to identify records in the above table. So we can say that sid and s email are keys for this relation. This brings us to the question why we need keys. The first reason is pretty much obvious. Without a DBMS key, you cannot access the rows of data stored in the table uniquely because without a key, most of the time you will either receive multiple rows of data or incorrect rows of data. Another big reason which is kind of an extension of the first reason is we can force identity of data and ensure integrity of data is maintained using DBMS keys. By making an attribute a key and making it mandatory, we can enforce that anything inserted in the table is identifiable and insuring data integrity to. And last but not the least, we can establish a relationship between tables using keys. It's time for the main event types of DBMS keys. There are eight different types of DBMS keys of which super key is like the default key and composite and compound keys are like cousin sisters will see when we learn about them. So we will be starting with super key. Then we will move on to candidate key. Then primary and alternate keys. Then the foreign key which is different from all others and serves a purpose which none of the other keys do. And then we will cover the remaining keys which are composite compound and surrogate. Super key is nothing but a key. It is a super set of keys in which all possible keys are included. Like in our example, SID registration ID, email, then combination of them, SID registration ID, registration ID and email, email and SID and then all three together, SID registration ID, email, all our super keys. There can be more as well. In simpler words, an attribute or a set of attributes that can be used to identify records in a table is a super key. Then comes candidate key. It is the minimal set of super key which can be used to uniquely identify a rows of data in a table. We saw that we have so many options for super keys but most of them are formed by unnecessary pairing of keys. Like email ID, SID registration ID together as a key or email SID as a key, when email SID and registration ID can individually uniquely identify a row of data. And in this case, the three attributes, SID, email and registration ID or REG and RSOID are the minimal set of super key and the candidate keys. In book's language, if any proper subset of a super key is a super key, then that cannot be a candidate key. Now let's try to understand this. registration ID, email and SID together form a super key, while email and SID is a proper subset of it and is also a super key. Hence, this is not a candidate key. Similarly, email SID is a super key and its proper subset, email and SID both can act as a super key individually. Hence, this is not a candidate key. This way, we can come to a conclusive proof that SID, email and registration ID are the candidate keys for the relationship that we have. Now, moving on to primary and alternate keys. A primary key is a candidate key which is used to uniquely identify every row of data in a table. Now, you must be thinking that we have three candidate keys and all of them can do so. Well, in that case, you can make anyone a primary key. This is generally done by database administrator to set a candidate key as a primary key. If we have to create a simple user interface to search for student information for our college using the table in the database that we have as an example, what will make more sense? SID, which is an auto-incremented value by the database itself, or registration ID which every student knows and is more meaningful for college administration too. Hence, in this example, we can make R-EG underscore ID or registration ID as primary key. All the remaining candidate keys which are not selected as a primary key are called alternate keys. Now, coming to foreign keys. Foreign key is nothing but an attribute in a table which is used to create a relationship of that table with some other table. In case a table has a relationship, using foreign keys helps us to maintain data integrity for the relationship. But this, we will have to involve another table in our example. Let's say we have one more table branch with information about the branches in the colleges. It has a unique column with branch code, branch name, HOD and some more branch related information. In the student's table, the branch code can be made a foreign key to set up differential integrity or relationship between the table student and branch. This way, while making a new student entry, a wrong branch name cannot be provided as a D.V. will return error. Similarly, if someone deletes a branch entry or a dates a branch code in branch table, they will have to change the same in students table 2. Generally, this is not allowed by the database and the database returns error when someone tries to modify the column value which is used as a foreign key in some other table. In this way, we can force integrity of data in a relationship using foreign keys. Moving on to the remaining keys, a composite key has multiple attributes. Hence, all the super keys with more than one attribute are also composite key. In our case, email sid together, sid registration id together, registration id email together, all are composite keys. If a composite key has one attribute which is foreign key, then it is called a compound key. Moving on to the surrogate key. Sometimes a relation or a table has no attribute which can uniquely identify the rows in the table. In this situation, when there is no natural primary key, we create an attribute to act as a primary key, that is a surrogate key. These keys do not add any meaning to the data, but serves the sole purpose of identifying the data. With this, we have covered all the DBMS keys starting from super key, candidate key, then primary key, alternate key, foreign key, composite and compound key and surrogate key. I hope after watching this video, you have a better understanding of what DBMS keys are, why they are required and the various different types of DBMS keys. If you like this video, give it a thumbs up, share it with your friends and do not forget to subscribe to the state nerds youtube channel.