 Dear students, today we are in the lecture number 14 of the database management system course. As you must remember that during last two lectures, we were discussing an example scenario and I was trying to explain to you how do we apply the database development process steps on the real life examples. We were studying the examination system of an educational institute. Initially, we applied the preliminary phase of the database development process. In that process, we studied the system, we studied the working of the system and then we also collected the requirements of the users of different user groups that exist in an environment, in our example environment. And then we used two tools which were the DFT and the cross reference matrix. From the basis of the interviews that we conducted with the users, we developed our DFDs and also the cross reference matrix. After that, we entered into the analysis phase and in the analysis phase, using our tools, using our diagram that we developed in the preliminary phase of the database development process, we applied the process of abstraction and through our analysis, we identified different entry types, their attributes and also we identified the relationship between different entry types. Then we completed our diagram in different steps and ultimately, we discussed our complete diagram of the system. Dear students, as we have discussed many times now that the next phase of the database development process is the logical database design. We touched the topic in the previous lecture. In this lecture, we will continue our discussion. As you know that the logical database design is generally in the relational data model. In the previous lecture, I told you that the two major strengths of the relational data model that played the basic role in the popularity of the DBA messages that are based on the relational data model and those strengths are the simplicity and the strong mathematical foundation. We have discussed this point in the previous lecture. Today, we will move on from this point. The relational data model was originally presented by a researcher named E.F. Codd. At that time, he was working in the IBM company, which is the time of 1970s. In the 1970s, he wrote a very famous paper that was published in a journal and in that paper, the Codd published the paper or Codd presented the paper of the relational data model. Initially, the idea did not get the popularity, but later, the IBM itself developed a DBMS based on the data model. Before the relational data model, there were two famous data models that were being implemented at that time. One was the hierarchical data model and other was the network data model. The first DBMS that was built by the IBM and that was based on the relational model. It was the system R. And after that, another very famous system that was a relational DBMS that was Ingress. So these two were the initial relational DBMSs. By the end of 70s, the relational DBMSs, they started getting the popularity. And the major reason, as I told you before, that the simplicity of the data model and secondly, the mathematical strength. Then as you will study further, that the relational data model and obviously, the DBMSs that were based on the relational model, the relational DBMSs, they clearly separated the three layers of the database architecture. That is, they in particular, the important thing is that they separated the conceptual and the physical layer. The advantage was that when you were designing the conceptual database design, when you were designing the middle layer, at that moment, you do not need to concern about the physical implementation of this schema or at this level. Whereas, in the previous two data models, like in the hierarchical and the network data model, you need to know the implementation of the database as well. So these were the reasons that gave a popularity to the relational DBMSs. Now we will study the basics of the relational data model. I have briefly written here RDM that means relational data model. And dear students, as I have told you before, that in order to make the proper use of the relational DBMSs that are maximum prevailing DBMSs in the market today, you have to have a very clear understanding of the concepts of the relational data model. So first we study the relational data model and then we will also use a relational DBMS to see how do we implement these concepts into the DBMSs. This relational model is used mainly for the external and conceptual and to some extent the physical level. You remember the three level schema architecture. Here we are talking about basically the layers of that database architecture. Again as I mentioned before that it separates the conceptual schema and the physical implementation of that schema. The basic structure in the relational data model is the relation. And that again as I have mentioned before that this is the simplicity of the relational data model that there is just one construct, just one structure and that is relation. If you see in the anti-relation data model, we have got anti-types, we have got relationships and then we have got different types of cornellities and different types of relationships whereas here you have got just one thing, the relation. See both things have their merits and demerits. How? When we say that the relational data model is easy to understand, it gives less structure, so on the one hand it is useful, but if you pay attention to it, then it also becomes a limitation because when you are talking about the ER data model, you have got different constructs. The advantage of that is that when you represent different situations, you have to portray them, you have to model them, you have got different tools, different constructs, different structures. So, in different situations, for different things, you use different structures or different constructs. But when you talk about the relational data model, then for every situation, you have got just one structure. So, this means that you will have a loss that the things that you are representing in the relational data model, they will not be that apparent, they will not be that much clear from the schema. So, if you feel that when we talk about the ER data model or a design that we did in the ER data model, it gives you a lot of meaning about the system. For example, when you see that there are two anti-types in the relationship, you see the carnality, you feel that there is a weak entity type, it is strong. Apart from this, when you see super-type sub-type relationship, that is also giving you some meaning. So, if you compare it with the relational data model, for all these situations, all the constructs that you have in the ER data model, when you want to implement them into a database design that you want to implement in the relational DBMS, for all those structures, you have only one structure, relation. So, you have to put an entity type builder, you have to put a ratio builder, you have to put a super-type sub-type relationship in the same way. So, when you use one structure of all the situations, that does not give you so much meaning by just looking at it. Why? Because it is used for various situations, for all the things. So, at a particular time, the relation is used for what purpose? You will have to pay attention to it. Whereas in that, you have to understand that it is sufficient to look at it. I hope you understood the difference between a semantic data model and a record-based or asset data model, which is not a semantic data model. You must have understood the difference. Now, especially, when you are looking at a record-based data model, which is not a semantic data model. Let us move forward. As I said, you have only one thing to model the entity types and relationships here, relation-getable. When you implement relations, it means that when I am talking about implementation, it means that it is on a physical layer. No. You must understand that even at the conceptual level, when we write relations, if we physically see its representation, and again, physically does not mean the practical implementation. No. Means that if we write records here, if we write relations, then we write it in the form of a table. What is a table? A table represents something in two dimensions of one time. And if you remember that in the small classes, when we specifically say tables, like mountains in Urdu, when you write mountains, then you say that you see it like this. In that, the components that are fixed, what will come in the first name, then what will you write, then what will you write, then what will you write. Similarly, when we call table here, it means that it is a two-dimensional arrangement. This is how it is arranged and this is how it is arranged. Similarly, we call a two-dimensional arrangement. So, we call this two-dimensional arrangement a table. This means that we represent the relations in the form of a table. That is, we represent them in a two-dimensional format. And as you can imagine, whenever we arrange a two-dimensional thing, then we partition it like this, then we call it columns. And if you look at it horizontally, then we call it rows. This means that when you think about a relation and if you represent it practically, then it will become a table in which columns are and rows are. For example, when you look at different tables, you will understand more. Column represents attributes and rows represents records. For example, we were talking earlier that if you make sections from the use of the table, then every section that is like this will be vertical and the section that will be representing an attribute. So, this means that if you define a table, the amount of attributes that you have defined will be as many columns as that. Because every column will represent an attribute. And the rows represent a record. If you look horizontally, then there will be a record in one row. One record, second, third. Now look, note one thing. As I just said, that a table will have as many columns as you have defined the attributes in it. What about rows? We cannot say any such thing about the rows. Because rows represent records. You are talking about records that you have a record that increases and decreases in the normal tables. When you define a table for the first time, you have defined it with attributes. If there is no data in it, then you have columns of this table but there is no row. You have added one record and one row. Second, third, fourth. Initially, there was no row. And later, a table can have a million rows. So, as far as the columns are concerned, we can count them. We can say, okay, this table has got this much columns. But as far as rows are concerned, it's a dynamic thing. It keeps on increasing and decreasing. So, when we talk about how many rows are in this table, we say that this is the day. And it is in our mind that the number of rows can be changed at any time or they can be frequently changed. Strictly speaking, the number of columns can be changed. But this is something that happens very rarely. Because, as I told you, changing the number of attributes is obvious that you have to change the definition of that table and that relation. And that is something that I have already said that there is no such frequency. Apart from this, when you use the terms from now on, when we talk about tables, the horizontal thing that we said that the row represents the record, along with it, it is also called tuples. So, from now on, if you use the term row, record or tuple, one of these three means one thing. If you are confused, it means one thing. And similarly, if we say column or attribute, both of them mean one thing. Dear students, as I just told you, if we represent the relation in the form of two dimensions, it is called a table. So, when we represent it in two dimensions, it is okay to call it relation. If we call it table, it is also okay. So, the difference in terminology is that you can put it in your mind so that you are not confused with it. Okay? Now, one thing about this is that the relation of this particular representation is called a table. Along with it, it means that any other representation of the relation is also possible. We will discuss that later. What we are going to discuss at this point is that when you represent your relation in the table, it has got certain properties. And those are six basic properties. At this point, we are going to discuss them. And again, I will declare that which is one of the basics. So, you kindly understand them. And you should always understand this. I would like to tell my students that if you have read the database course, then you should understand this. The basic properties of the relation you should understand. Now, the first property in this is that each cell of a table contains atomic or single value. Now, look at this. This is a little bit of an explanation. The first thing is who is the cell? The cell will say that whenever you talk about the table, there is an intersection of a column and a row. You will call it a particular cell. So, a particular cell will represent a value of an attribute in a particular record. We have some diagrams and tables that I will explain to you. But it is not difficult for you to understand that when you take a column like this, when you look at the column, it is going in all rows. But when you draw a row, then definitely this column and this row will intersect with you. So, where they are crossing, that particular place, that block, that house, where they are crossing, that cell will be called. And obviously, you have understood that a cell, first of all, we have a student name. So, if we look at the student name and if we cross it horizontally on row 3, then what is the student name? So, the student name is that in row 3, in row 3, in row 3, in row 3, student name's value. So, a cell shows a particular attribute, a particular record. Now, this property is the basic property of this relation. It is that a cell will have a single value. What do we mean by single or atomic value? That is treated as a single value. That is treated as a single thing, as a whole. Again, that value, which you will treat as a single thing, as a single value, you will say that this is a single or atomic value. Dear students, usually the students who have read this course for the first time take some time to understand this concept. When we say that it can contain a single value, then there is such a situation in which we can get multiple values of an attribute. For example, we talked about the multi-valued attribute that we mentioned in the ER data model reference. So, in this, the table in which you have a cell, an attribute, its value cannot be multi-valued. And look, first of all, we are talking about hobbies. If we suppose that a student or an employee has multiple hobbies, if we assume that the employee or student is representing a table or a relation, then the hobby attribute will either have a value or decide that if a student has multiple hobbies, then we will store only one of them and it is up to him to decide which hobby he wants to tell. The second situation is that in the form of a text, a particular sequence of characters, you store multiple hobbies. For example, if a student has a hobby, he is a snooker, he has a reading, and he has a gardening. Now, if his attribute is a hobby, if you place a snooker or a snooker, reading or gardening, then you can write, give space, give comma. If you even feel like that, that in your opinion, I have stored the multiple values there. But the thing is that the DBMS, it will consider it as a single value. By looking at it, you have written a letter, by looking at these three letters, by looking at it, you assume that there are three hobbies for this student's basic. But the computer, rather than your relational DBMS, it did not consider it as a multiple value. It said that there is a string, in which the string can be very long, in which you can write the entire story. So, it means that by storing multiple words, by storing a long string, it does not mean that there are multiple values. For example, if you talk about the address, we discussed this earlier, during the data model, that for example, if you store the address as a single thing, it will become a long string, like house number, street number, colony number, city number, postcode, and now it is a complete string. All the addresses of the components are present in it. One condition is that you make the address a composite attribute, which has a further component attribute. So, if you first store it as a single string, when you are composing it, then according to you, what you are seeing, what you are seeing as a user, you understand that there are multiple values here, like city number, street number, but again, computer think-set, rather your relational DBMS think-set as a single value, as a text, which has 3, 4, 5, 6, 10, 15, 20, 25, these words are there, but they are not multiple things. It is still a single value, single thing. This concept, when you discuss it further, you will be clear. Each column has a district name, the name of the attribute it represents. If you are representing on the table, then the column, which is your vertical arrangement, will have a name for each column. And this name will be that is basically the name of the attribute that this particular column is representing. If we have defined student record, student ID, student name, student father name, student address, then if there are 4 columns, then each column will have a heading, on top of it. And that will represent that attribute, the name of that attribute, which this column represents. So, it means that every attribute, every column has a name. But look, again, the same thing I have discussed earlier, that we do not say such things every day. See, because you know the number of attributes in a relation or in a table, but you cannot guess the number of rows in a particular table. There can be anything, there was nothing in the beginning, it can decrease, it can decrease. So, to identify rows, generally, we use keys. In fact, not keys, we use key value. So, rows are identified by the key value individually. But when you talk about columns, in a table, then columns are identified by the name of the column. The values of the attributes come from the same domain. Keep in mind that when you talk about a column, we have discussed earlier that you attach a domain with every attribute. So, when you are representing a column with an attribute, then all the values will come in it. How will the values come in it? When you enter the record, then it is obvious that you will enter the value of every attribute. When you enter the value of every attribute, then the column is increasing, increasing. So, since one column is representing an attribute, then all the values will come in it. They will all come from the same domain. We have already read that the domain means the set of possible values. For example, if we say we have an attribute of age. In age, we have declared it as the number. You can say that the age attribute, the age column, the domain is the number. Now, all the values will come in it. They will all be of the number type. It is not possible that in one column, in the three records of the beginning, you put the value in it, that age is 20 years, 21 years, 19 years, 20 years, and after that, you start with that attribute, that its name is Ahmed Murtaza. Its name is Shumaila. No. When you say that this is a particular column, the record you want to enter in that column, the value that will come in that column will be from that domain which you have associated with the domain. The order of the columns is immaterial. When you write a table, obviously, the table arrangement is column-wise and row-wise. Now, the column is written. After that, we do the first thing that you have put some data in it. First, you have made a table, first you have defined 6 attributes in it. And first, when you started the data entry, you have put 1000 records in it. Now, first, do this table in which you said we have this attribute 1, attribute 2, 3, 4, 5, 6, 6 attributes, 1000 records. If you take this table and change the arrangement of the columns, what was the arrangement? Change their order. Mind it. Just the order. You are not touching the value. No. I am just talking, this property only talks about order arrangement. That is, the first thing you said that column was on the first position, first you have to do it on the 5th position. What was on the 5th position, you can do it on the 3rd position. What was on the 3rd position, you can do it on the 1st position. You can do any changes in the order of the columns. So, when you arranged the table in the new order of the columns, the first table and the second table they both feel be considered the same. By changing this order, you will not call this table different. You will not say that the table was different because it had columns but this table is different because it has columns. No. That is, if you call it formally or theoretically, you will call them the same tables. That is, by changing the order of the columns, there is no difference on the table. It still remains the same. Let us move on. The order of the rows is also immaterial. This is exactly what it means that you also have a thousand rows of the columns. If you have entered the rows on a special condition, if you change the order of the rows in this table later, you can do anything. Mind it. Don't touch the values. If one value has also changed, if one value has also changed, then it is a different thing. No. The emphasis on these properties is on the order of the things. So, here, property number 5 says that if you change the order of the rows of the table, then the table will not be different or any other table will not be called. It will still remain. It will still be considered as the same table. Each row, tuple, record is distinct. No. Two rows can be same. That is, the way you enter the rows in a relation, in a table, two rows cannot be the same. In a table, you can put one record, either one lakh, or ten lakh. It cannot be that two rows are exactly the same. And just to clear this, as a clarification, we make sure that we declare a primary in each table. When we declare a primary, the basic quality of the primary is that it is unique. This means that if you put ten lakhs or more, in each row or tuple, your primary key is very different from that of the table. So, in a table, each row or tuple your primary key is very different from that of the table. So, if you do the duty, all other attributes are exactly the same. But at least, at least your primary key cannot be the same. So, if you do the duty, we have six attributes. For example, if five, two, three, four, ten, thousand, five attributes are exactly the same. Due to any reason or any circumstances, the primary key will be different. Based on this, the rows between them will not be exactly the same. So, this property says that the number of rows and the number of tuples in a table cannot be the same. All of them will not be completely the same. Mind it. I have given you an example. I have also said that even if five attributes, six of them, even if five attributes are the same, but one of them is different. And one of them is different from the character. One is different from the alphabet. Even then, they are different. This property says that the two rows cannot be exactly the same. I hope you have understood these properties. Kindly refer your books and notes so that you can understand them. Because this is important to understand these properties. Let us go ahead. Now, you see an example table in front of you. If you see this table, this table has got one, two, three, four, and five attributes or five columns and one, two, three, four, five rows. The top page you are looking at is not considered as part of the table as such. That is considered as heading or label of the columns or attributes. That is your table. This is the first row that will not be considered from the data point of view. Now, the first thing is that you can see that each column has a name and this name is unique. This means that in one table two attributes cannot have the same name. So, all these attributes are student ID, name, class name, date of birth and sex. These columns are unique and every day one, two, three, four, five and on this if you look at it in every row the value is a single value. For example, if you look at the name it is M. So, although it consists of two words. But DBMS is considered as a single value. Another thing is that all the columns are the same domains. For example, if you look at the date declared domain all the values they are dates. If you look at sex it is declared as M or F because you cannot date or number or not even a string of two characters. If you define a single character domain relation that has been represented in a two-dimensional arrangement. Dear students when we were discussing the data models at that time I told you that generally data models have got three components but at the same time I also told you that you will be able to see these components very clearly only in the model. So the three components that we talked about and will see are the three components i.e. structures that the arrangement of data the storage of data in which format your data model supports just one structure and that is manipulation language your relational data model is manipulation language i.e. SQL has been accepted as a standard that it is a manipulation language and the third is integrity support or support for integrity constraints so the support of integrity constraints is that it is based on the mathematical theory it has strong mathematical foundation and how the database relations are related with the mathematical relations and how the database relations are related with mathematical relations among those who have studied mathematics to the BSc level or may be in FSE or in FFSE may be that you have studied about relations but if you did not study mathematics then you must have studied about sets because there will be a set with a special notation and different members even an empty set the mathematical relations that is based on the sets so let us see how it relates with the sets first we have two Cartesian products Cartesian product you may have an idea if you buy two Cartesian products then there will be a set two Cartesian products another set but the new set will denote A cross B A cross B and the members will be ordered pairs which are important so this ordered pair will be the first member will be the first set and the second member will be the second set so in Cartesian products there is a possible combination i.e. you have to mix each member of the first set with each member and when they are ordered pairs and the braces are the braces of the set so this is two Cartesian products now we are talking about this in the terminology of mathematics we are discussing mathematics here now the two Cartesian products take any subset if you know all the Cartesian products take any subset then that will be a relation so if you see what is a relation then if there are two sets then any subset of Cartesian products will be a relation for example i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. i.e. will be called the relations. This is mathematical relations. The same notion of Cartesian product and relations can be applied to more than two sets. For example, in case of three sets we will have a relation of ordered triplets. For example, in the last example you saw that in the Cartesian product you had an ordered pair. i.e. in each member there were two elements. Similarly, if you take three sets, A, B and C, when you take the Cartesian product first, then in the order triplets you will have three members. In the order triplets A, B and C, the first member will be A, the second member will be B, and the third member will be C. This will be the Cartesian product. Similarly, as we have already taken the definition of mathematical relation, the definition will be applied again in such a way that if you take any of the sets of Cartesian product, then that will be called a relation. Similarly, we can do this with four sets, with five sets, with six sets. As much as you wish, as much as you wish, you can apply the Cartesian product and the definition of relation to all of them. Now, for this mathematical relation, if we try to apply it or relate it to database relations, then how will they relate? We will take a small example of that. Just to give you the idea, just to explain you the idea. First, we have two attributes. We call them name and age. Now, the attribute we have is the set of possible values, or the domain. First, we call it four names. As you have written, Ali, Sana, Ahmad and Sara. These four names are possible as values for the attribute name. Similarly, we have another attribute, age. And its domain, the set of possible values, contains 15 to 25 numbers. That is, the age attribute value can be taken from 15 to 25. Now, if we first take the name and age attributes of Cartesian product. Then it will be a set like this. In this, I have not written all possible ordered pairs because it could have taken too much space. But look, you are getting the idea that whatever your ordered pairs are making, you can see that because the name is cross age, the first value of the ordered pair is the domain of the name. And the second value is the domain of the age. For example, the first ordered pair is Ali 15. After that, the second value of the name set is Sana. With Sana, you have mixed 15. This is another ordered pair. Similarly, the third value of the name set is Ahmad. Ahmad class is 15. Ahmad is 15. Third pair. And then Sara is 15. Fourth pair. Now, with the same value of the age attribute, you have made all the possible combinations of the name. Now you move to the next value of the age. So what will happen in that? Ali, 16. Sana, 16. Ahmad, 16. Sara, 16. This is your 16. And in the same way, the age attribute of all the domains, from 15 to 25, you will make all the combinations with all of them. And it will carry on. The last two values are written on the screen. Ahmad, 25. And Sara, 25. So in this way, what is written in front of you is a Cartesian product, of the name and age attribute. So far, you have seen how our two domains of the attribute were made by the Cartesian product. Now, let's move on to the relation. Dear students, let's suppose that we have a class or many classes. And in those classes, the students we have, their names are possible from the domain of this name and their ages are possible from these names. Now if you visualize it a little, then you can very easily realize it that you can take any class of the world. If we apply these two basic conditions, their names are possible from these names and the age is possible from these names, then the situation of each class, if you want to write it, then it must be the subset of this Cartesian product. Again, if we have a class where we apply these two conditions, name is possible, age is possible. Now, the class's preferred situation, if you look at it, the combination of name and age, it must be in this Cartesian product or it must be a subset of it. If you broad this scenario a little, the example we have given here, we have said that the name is possible only in the domain of these four names. If we understand this, if we assume that we have the domain of the name, there are not just these four names, but all the names that are possible. Let's say, if we talk about Pakistan, then all the names that are possible in Pakistan, Muslims or non-Muslims, if we consider them as domains, obviously this domain will be very large, there may be millions of values. Let's suppose that we have a domain of name, all possible names, then we say age. So, the age of any possible ages, let's say in the class, it is 15 to 25, then this is the domain of age. Now, if you take the Cartesian product, it will be a very large set, there are millions of values in the domain of the name. Now, all the names are given to this age, it is 12 values, it is 15 to 15, there are 11 values. So, the history of these will be a very large set. But, if you think that if you are existing in Pakistan in any class, of this MCS-BCS level, the general class that is existing, if you look at the age of any student, if you look at the combination, then the ordered pair will be existing in the Cartesian product of this name and age. So, if you take your class, if you look at your class, and you make the name and age of all the people in it, and write it in a set. You can easily understand that in your class, the combination of the names and the age, will exist in this Cartesian product as well. Or, it will be its subset. Now, you can apply it in any class. So, in the class, the particular situation of that class, the grand set of the Cartesian product, will be present in the class or it will be its subset. I hope you have related to this, that there is a database relation, a database table, that relates to the mathematical relation. When you have an attribute and its domain, then whatever your table will be related to it, it will be the subset of the Cartesian product. This is how the database relations and mathematical relations relate to each other. As I told you before, what is the benefit of this is that you treat these database relations as mathematical relations. Now, you have to perform any operation on this. So, you can see that the question is whether we should do it or not. For that, instead of experimenting or thinking about something else, you have got the mathematical relations. You can see that the operation on the mathematical relations, we should put it there. And like that. So, it gives a whole infrastructure to the relational model. What are its liberties? What can we do in it? And what are its constraints? What are its limitations? If you put it in it, then it will always be well defined. Clearly defined. In its meaning, in its operations, in some activity, there is no confusion. There is no opinion. Because all things are mathematically proven. Let us move on. This is an example of a class given in the continuation. And the class in front of us is the subset of that Cartesian product. Now, there is some relation to database relations. We will see that with the reference of the relational model. Let A1, A2, A3, do not confuse this. This is a notation. A1 is like a student ID. A2 is student name, A3 is student address. You relate it like this. It will be very easy to understand. And every one has its own domain. Mind it. Every attribute has its own name and its own domain. You have to associate these two things with every attribute. You have some attributes and every attribute has its own domain. This is a relation scheme. The scheme means that the structure defines a relation. A relation scheme relates certain attributes with their domain in the context of a relation. We will say that when we have to define the structure of a relation, we will collect the attributes and associate a domain with every attribute. How will the domain be associated? Depending upon the environment, the situation. What should be stored there? What is defined? For example, it is a student ID. A student ID is not defined as it should always be a number or it should always be a text. It depends on different situations. The structure of a relation can be written as R is our relation and A1 is the column D1. A1 is the name of attribute and column D1 is its domain name. A2 attribute name, D2 domain name and so on. Last attribute an and domain dn. Student ID colon text. Student ID has domain text. Student name text. Student address text, date of birth date. Can you write it like this? Or briefly, we do a relation scheme and sometimes we do not mention the domain and just mention the attributes that is also sometimes sufficient. Now, once we have defined the scheme, how will the relation be made? The relation will be that according to each attribute, for example, here we have student ID attribute name colon instead of domain a particular value. Now you are basically forming the relation itself. That was the relation scheme. The structure. According to that structure, now you will formulate your relation. Zahra said that the scheme will be made once. According to that, add as many records or rows or tuples as you like. See in front of you as student ID colon S001. This is the value of attribute student ID in a particular tuple or particular row. Similarly, ST name. In this tuple, ST name value is Ali. The same way, ST address, date of birth, is a tuple. Now, along with it, another tuple started. You saw that student ID is written as S03, student name, student address, date of birth, so this is your second tuple. Third tuple, fourth tuple, fifth tuple. You add the tuple to define the relation scheme. According to that, you add tuples. Similarly, we can write these tuples as we know the scheme. Instead of attribute name, we write this relation as it has just the value of tuples. Finally, if you represent it in two dimensions, that becomes a table. This is what we talked about, that we can have another scheme of the relation. If we write the top form, that is a relation. If we write the bottom form, that is relation and table. The top one is not table. The bottom one is relation and table. Because that is a representation of a relation in a two-dimensional arrangement. Dear students, we will conclude today's lecture here. Today, the course of our database management system is the most important thing that is our relational data model. We have started it. I hope that you have understood what is a relation and what is a table. What is a mathematical relation? How do we relate the mathematical relation with the database relations? What are the basic properties of the database? What is the meaning of every property? Finally, we were looking at how to represent a table relation scheme and relation. Until then, I wish you all the best. Allah Hafiz.