So folks, welcome back to our course, we're going to start our module two relational model. So where we are right now. So now after module one you learned about and you know about what database management systems are and what are the pros and cons of it. And what entity relationship models are. And you know how to represent these Models. Use entity relationship diagrams, use Crow's Foot Notation. And next step will be, converts this entity relationship models which are conceptual models into a intermediate step, which is a relational model. So you are going to represent this graphic diagrams, use some syntax or schemas. So that's when you are into our course two you're going to learn how to either implement it in massive crow or create tables in Microsoft access to do that. So, relational models will build up an intermediate stage between a conceptual ERD or Model to implementable physical database. The early learning objectives for this module once you finish it, you will be able to understand and explain what are the relational models. And you are going to explain the property of the relational models. And you are going to explain and select appropriate keys for relational models and for each of the relations in the relational models. And also you're going to represent relational models with a set of relational schemas, that is one of the syntax, we're going to learn, quite straightforward. And then the last thing is you are going to convert the entity relationship attribute, the diagram into the relational models so we can move to the next stage. Okay so what are relational models, relational models is specifically for relational database. Because it is a model describing how the tables or how relations are connected. So it organizes data into two dimensional tables and columns and rows. And each relational model includes, relations tuples, attributes, keys and foreign keys. Those things will be specified in the relational models. And the representation of a relational model will be a set of relational schemas, we're going to learn them later on. So let's see some examples of a relation. So here it is a table and it is quite straightforward. And this table has a name as a store, has the columns as store ID, street, city and zip. Has the rows from number 1506 to number 1502 etc. So this will be an example of a relation or it will be implemented as a table in a physical database. And we have several properties for this relation. First of all, we have the name of the relation which is the same name on the table as stores, which is right here. We also have the degree of the relation which corresponding to the number of columns of these relations. We have one, two, three, four, we have four columns, that is why we say this relation has a degree of four. The next one is cardinality. So this cardinality is how many rows, how many instance in this relation in these stores. So we just count, we have one, two, three, four, five, six, seven. So that will be seven as our cardinality. So in terms of the property of this relation, we have the name and store, we have the degree of four, we have cardinality as seven and we have the attributes of this relation as street, city and zip and that's it. Let's take another example, do the same exercise. So we have another table records the employee information. So obviously the name of the relation will be employees right? And the attributes of the employees relation will be employee ID, first name, last name, date of birth, position, department and store ID. So in terms of the degree we have a degree of seven because we have seven columns. And then in terms of the cardinality, which is account, we have one, two, three four, five, six, seven, eight, nine, am I right? Yes, we have nine rows, which means we have cardinality as nine. Okay, that's all the properties of a relation you need to know so far. The terminologies, so basically a relation is a table with columns and rows. And attributes, is the name, the column of a relation or just the name of the columns. And the domain is something called is the set of allowable values for one or more attributes. We're going to go over the domain later on specifically in the example. And the tuple is a row of a relation, which is quite straightforward, that is the tuple row is a tuple. So how many tuples in one relation? It is the cardinality. And degree is the number of the attributes, which is the number of columns. Cardinality is the number of tuples, that is the number of rows. Relational database is a connection of normalized relations with distinct relation names. So we are having some new terms jump up but we're going to revisit them later on. For this normalized, we're going to learn that in next module. And for the distinctive relation names, we're going to learn that in the properties of relations later on. Okay now let's go back to our example and example the domain of a attribute. So in each of the attributes we can see that the value has some characteristics, for example, for the employee ID it is obvious that employee ID are all six letters long. The first one is a special march and then we have five digits that is how the employee ID are composed. So the possible domain for the employee ID, we can specify as six long chart and five digits for the second to the last chart, that will be a domain. So what we have to give so much restrictive definition or domain for the attributes. Think about if you are running a database, you really want to avoid the typo mistakes or missing value or anything you want to avoid as mistakes. So the more restrictive the domain is, more accurate data you will get. Because for example if we do not specify the domain of employee ID, then you may end up with some employee without the special mark. Or another employee ID with the value of cell phone. Because there are many human errors when we enter the data into our database right? So with this specific domain we can restrict what kind of data will be accepted as value the data. Even though we cannot avoid some other mistakes such as instead of 20399, it should be 28399. So we cannot avoid that however, by the domain we still can avoid a large amount of inviting the data out. For example for the first name and last name we will only accept a certain length of charts. We're not going to accept one million charts as the name which is not possible. So we can avoid that for the department we have HR, we have market and marketing and sales and ID here. So you can specify what kind of department of value is valid in your database. So definitely you don't want to have a department not exist at all into your database. For example, someone may enter sales as sale without the s by a typo. Then if you do not set up the domain for the department to all the possible values, then the sale will be a valid value for the department. And will cause future mistakes when you do the curie or when you try to find, for example, get all the names of employee working in sales department, then you will miss someone if that record shows he or she is working in sale department right? So the domain is a way for us to limit the input of a certain attribute and that will definitely help to to filter out invalid the data.
