 In this module, we'll talk about data independence. What is data independence? Why we need to have data independence? What are the benefits of data independence? And so on. So what is data independence? Now, if you recall in the prior modules, we talked about different schemas. We talked about models and you can see that when we spoke about and discussed about the schemas, it is a kind of a layered approach. So data independence means that I can make changes in one layer of the schema without affecting what is in the other schema. That is data independence. So I have the logical schema. I can make changes in the tables, in the relationships. And by virtue of the data independence I don't have to worry about what is going to be happening in the physical schema. And the benefit of the data independence is that the data is separated from what is going to be happening on the data. Because if there is no data independence then everything is collected together. It becomes very complex. And once changes are made at the lowest level those changes get reflected at the highest level. It becomes very complex and complicated. So let's go into more details. So I have this logical schema. I have this physical schema and over here you can see I have over here this is the independence. Physical data independence and logical data independence. Logical data independence I am concerned about the entities which I will be discussing shortly and the things which are of importance and significance the relationship between them the constraints and the domain and so on and physical independence is that that data is stored what is the data about the data about the indexes about all those associated things. Data independence with reference to the physical schema it means that if I replace my hard disk magnetic hard disk with a solid state disk it's not my concern. That is the physical schema that is the physical independence I hope you understand. Now this is just a listing of what goes into physical data independence and what goes into logical data independence. You can see that I can I am free about the indexes. There are many different types of indexes giving different types of performance requiring different application domains so that is physical independence you can modify the indexes database location it is irrelevant whether the data is stored on your machine on the server across the continent over a cloud database location that is the physical data independence and there are many many things over there then of course you can have merging of two records you can break an indexing record in logical data independence why do we need to break the records or records why we need to combine them these are the performance issues but to the programmer or to the user everything is in the table which was defined as per the corresponding model and schema independence means that it is irrelevant whether it is a view I am writing the skewers for the view and maybe the tables which are used to generate the view they may be relocated it is all transparent that is the independence so you can see over here is a comparison of logical data independence you can see that it is difficult to retrieving data but in this case for physical data it is easy to retrieve so it depends upon which independence we are stressing concerned with the conceptual schema concerned with the internal schema this is not concerned what is happening over there the point this slide is trying to make is that by virtue of this independence the developers, the designers, the analysts the architects they can work on different layers, tiers without affecting the other layers and tiers that is the advantage so how do we model these things we have this erd entity relationship diagram and we have the UML unified modeling language entity relationship is a diagram but in UML there are many drawings there are about 5 or 4 drawings diagrams drawing is a better word helps visualize the software system but unlike traditional programming like java or c or c sharp or python no programming commands over here this is for software systems this is for database system they are not for the same just to give the difference over here and this the erd gives the relationship this is a representation so you see that what we need to design a database is erd entity relationship diagram right which is most suited for this purpose now let's look at the final slide which compares UML with erd so UML is general purpose this is for a database this has many diagrams actually there are 4 diagrams this is itself a diagram this is for software system this is for database system so we can see that they are not the same they have their own domains we cannot say which is better or which is the best it depends upon the application domain but for us erd is the way to go that's all I have to say in this module thank you very much