 As I said in the prior module, that in this module, I will briefly explain the 12 chord rules using simple examples. And of course, the details are given in the notes you can read there. And for the simple example, I will only use a very simple table with three rows and about three or four columns, so that you can understand the concept. Once you understand the concept, then you can understand the details also. So the information rule, the information rule states that if I change the order of the rows, the result doesn't changes. I change the order of the columns, the result does not changes. If the salary comes first, and then is the email address, and then is the name, it doesn't matter. The data which is stored in the cells, that data should not be separated by commas, by space, by hyphens. The data which is stored in the cell, that is it. If I store something like this 10, 5, or 6, that is not allowed. Or if I store 10, 5, 6, that is also not allowed. That is the information rule. Okay. Then is the guaranteed access rule. Now I know the table name. The table name is employee. So if I would like to know the details of a certain employee, this is the primary key. This is unique. This is the primary key. So I give the primary key, and I give the column names, and I give the table name. I get the answer. It should be guaranteed access. That is the example. That is how this rule is supposed to be implemented. Systematic treatment of null. In the previous example, or the table, or the rule, over here I showed empty space. This is, null is fine. This is okay. But empty space, NA not applicable, missing value, value not available is not allowed. There has to be consistency. Now this null can be there. If say for example, maybe in certain case, the email address is not there. You can leave it. That is the null. And in this case, the salary was not mentioned null. Now null plus zero is not zero is null. Now in this case, say for example, if everybody gets a 5% raise, right, then the employee with the null salary, the result will be null, but other employees will get the raise. That is the systematic treatment of null active and online catalog. There's certain table in the database. You can run the query on that table. I believe it's all underscore tab and you get all the metadata about the data database itself. That is a data dictionary. You learn the same query language. Comprehensive data sub language rule. Okay. Comprehensive data sub language rule. I am using a language and that is a query language that is a structured language. I can get what I want using the query language view updating rule. Now what I do is that I create a view instead of writing a query every time that this condition should be met. This should be met. This should be met. It becomes complicated. So I create a view and the view you see over here is the view of those employees with salary is shown as null. Whatever the reason it is irrelevant. This is just the representation. So I have a table which is actually a view to the end user. It's like a table, but it's a view. So this is the employee underscore null cell. Right. Now why is it difficult to implement theoretically if I change make the change in the view. It should be reflected in the underlying table or database. But usually it's not the case. Usually when I make the change in the underlying table, the view changes. Okay. High level insert update and delete. Now insert update, delete, intersection, union, minus all that should be available to be implemented at a high level. Okay. We are not concerned at the low level. And along with this, this should not be limited to row by row basis. For example, in a large organization, we say, for example, with 10,000 employees, right? And if there is a management decision that everybody in this salary range will get a 5% increase and there are 2000 employees in that category, then only one query will be executed will update the salary of those 2000 employees. Physical data independence. It is irrelevant. What is the file name in which the data is stored? It is irrelevant. How the data is stored. It is irrelevant, whether it's on a magnetic hard disk or on a solid state hard disk. That is the physical independence that I believe I also mentioned in the previous module also. Logical data independence. It is irrelevant how my data stored over here. The data is is already bifurcated into two tables. One is those employees with the salary is not null. And those employees with the salary which is null. So I have these two tables over here. This is the logical. This is table one. This is table two. What the view I am getting what the user is seeing is table one and table two collectively. Okay, seeing table T. That is logical data independence. Of course, that partition of the tables can be vertical also, and so on. Integrity independence. Okay, integrity independence is that, for example, I would like to add an employee in department number 50, and that department 50 does not exist. So that should generate an error. That is the integrity independence, and they should not be any shortcut or any other way to insert that employee in a department that does not exist. That would be a violation. That is the core spirit of the relational model. Distribution independence. This is the basis of distributed databases. My data could be anywhere. It could be on any server. It could be physically located anywhere. Okay, and it should not be the issue or the problem of the database designer of the user where data is located to that user. The data is located in a set of tables. And those set of tables may may be giving an impression that they are on the hard disk of the end user. And finally, the non subversion rule. It means that if I run a query to perform an insert or an update that query will only perform and insert an update in the table and only on those at columns for which the query was executed. It means that if I am updating the records of certain students, their grades, it will not change the grades of those students which were not included in the query. It means that if I am updating the accounts of my customer who made a deposit, it should never ever affect the accounts of other customers who were not listed in the query. I believe you understand this. More details are in the notes. Thank you very much.