 Dear students, designing effective database is a complex undertaking and it has to be done in a stepwise, in a formal manner, in divided into systems, into blocks and into the modules, right? So as to make this process efficient, effective, easy to understand, easy to communicate. Now that process of the architecture and the designing is the focus of this module. So need to develop and design a system which conveys what the end user needs. The business requirements of the end user should be there. When we talk of the schema, the schema is a visual representation of the business requirements of the end user or there are formulas in terms of relationships that are listed that can be understood by the developers by the programmers and that can be communicated. So this is the focus of this module. Let's go into more detail. So fundamentally, this process or this understanding or this concept is divided into three parts, which is the logical schema, which is the external schema, and which is the physical schema. When we say physical schema, it does not means that we are interested in which hard disk is being used. What is the idea of this hard disk? No, no, no, it is not physical schema deals with that the data is stored on the storage device, right? And the mechanism of storing that data, how the indexes have been formed and so on. The logical schema deals with what are the attributes? What are the things of interest? What we need to record? What is the relationship between them? That is in the logical schema as you can see on the screen also. And then is the external schema, different views, what the marketing people will see, what the sales people will see, what the CEO will see, what the line managers will see, different views. So these are what we'll be discussing in more detail. So physical schema, as I said, is not about actually storing the data. But when we say the logical, but we are of course concerned about the integrity of the data, we are concerned about the security of the data. These things are taken into account. And the logical schema we are interested in what things are important, the entities, which I'll discuss in more detail when I go into what is called as the entity relationship diagrams. And the external schema is the view, what is seen by the different people in an organization at different levels. So these are the things which I also discussed in the previous slide. So there are three things over here, which you would like to know, database schema and database instance. Now, data's base schema is a visual pictorial representation of what is important in a business, how it's related, what are the constraints represented visually using the physical schema using the external schema using the logical schema. So that is the schema. Now a database instance is the contents of the database at a certain point in time. That is the database instance. And of course, the contents of the database can be changing over time. People are say, for example, I am making telephone call over my mobile phone. My billing information is changing. Okay. And for example, people are purchasing things, taking money in and out of the bank. So the contents of the database is changing. That is the database instance. See, a database instance is something dynamic, but the schema is not dynamic. And the database management system, we develop a database management system based upon the schema. Okay. And through that schema, we can make changes in the database. That is the database, how these things are tied together. So what are the characteristics of our DVMS database management system, real world entity, it can be a student, it can be a faculty, it is a university, real things. These are the entities and these entities are stored in tables. What are the relation between tables? So I have a table about the courses. I have the table about the students. So students registered in these courses. That is a relationship as the data is isolated from the design from the schema. Okay. Of course, I can change the data, but the applications are running on the data. Okay. The data is isolated in the sense that the user is not allowed to directly access the data. The user accesses the data through the DVMS. I'll talk more about it when we discuss the code rules. And the query language, how I access the data, I make a request through a query language and that request is broken down at lower level. And of course, through that query language, I am accessing the data and I have multiple views. So I have many users of the DVMS, I have the administrator, the administrator sets the profile of the users, sets the right, the rights of the users, helps the designers, ensures the policies, takes the backups, enhances the performance, takes care of the indexes and so on. So these are the tasks of the administrator. The designer is the people who design the database. They take the input from the end users. They ensure the business rules are there. They ensure the constraints are there. They ensure the relationships are there. And the users who actually use the DVMS. And what are the advantages and disadvantages of the scheme? Advantages are obvious. But the disadvantages, it is a complex task. And it is difficult to understand. And it requires effort to maintain. And because of this layered approach, separating things, the performance also is affected. That's all I have to say in this module. Thank you for your time.