 So students, this is the continuation of the previous lecture. In that lecture, we were looking at storing the data about a football match season. And there was a log table also there. Now the manager of that record keeping soon realizes that there are certain issues with that record keeping mechanism. And in this lecture, we are going to talk about those issues and how those issues can be resolved. So this is the module coverage for this module, removing data redundancy. Redundancy is that the data which is getting repeated and that data doesn't changes. So breaking the data into multiple tables, so we have a table of more or less static data and we have a table of changing data. I will go through the details and I will also show you a picture also. Then when we have this static data table and we have that dynamic data table, we need to link them together. That is what the relational model is all about. And then of course, briefly talk about in this module and in subsequent modules, a lot of discussion and examples of the MySQL SQL. MySQL is the database and SQL is structured query language. So let's go ahead with this module inefficient table structure. Why? Because I give you a number of examples. For example, when a player is playing and he performs good or bad, the nickname of that player can change. So when the nickname changes, then this table in which the log of the matches was maintained, that change has to be reflected everywhere. That's a big issue. It's a performance issue also. Then of course, when a player enters his data in that table, there are a number of things which are constant. Constant means that they don't change. For example, the phone number of the player, the address of the player and other related things which are fixed, right? Of course, the date at which the match was played is changes. But the problem over here is there is a lot of redundancy, there's a lot of repetition. And not only the repetition is there, but when the change has to be made, that repetition decreases the performance. It affects the performance. It unnecessarily increases the size of the table in which that constant data is being repeated again, again, and again. So what we do, some update in the multiple records, so this problem was handled by Dr. Codd. So he came up with the different rules of normalization, which we've already covered in the prior modules. What the Dr. Codd's rules covered was that we ensure that there is no loss of data. We ensure that the relationships are there among the different data elements. And we can query all the data to get the answers which we are looking for. So what is the solution over here? This is the solution over here is that move, we separate the static data and we have that dynamic data also. We have that dynamic data also and we have this static data and we have this dynamic data and we link them together. So collectively we are going to use this, this relationship among the tables, which is the basis of the relational model to get our answers from this database. So let me get into more detail, into more concrete. So we have this table of our players. This is the static data I was mentioning and this is the match log. This is the dynamic data I was mentioning. Now all the keys over here, they are unique. So this is the primary key over here. Is it not null? This is not null. I'll talk more about it. And over here the keys are repeating. For example, this key is repeating over here. This is repeating over here. And of course, this is repeating over here. This is, so this is not, this is the foreign key. This is not the primary key, right? Now this is a one-to-many relationship we have. This player of ID 6 and he is playing the matches on this date and on this date also. We have over here is that one-to-many relationship. So we are able to link multiple tables, which is the static data and the dynamic data, and you see there is less repetition. There is much less repetition over here. This is the beauty of this approach. Of course, this is normalized. So now we have to query this. How do we query this? We use SQL, the structured query language, and which is the standard for the relational model. It means that if you have a relational model, then it's going to support SQL, right? And using this SQL, you can create, you can update, you can delete, okay? And of course, there are different dialects of the SQL across different databases. So more or less it is going to be the same. Some differences might be there. Basic concepts are similar. So of course, we'll be discussing more of this interesting stuff in the next modules. So that's all I have for this module.