Hey everyone and welcome to the second major topic in our database design and management class. This topic is going to focus on the relational model. So we're going to begin developing a set of critical skills that will allow us to become effective database designers as we work our way through the material for this topic. In this first video for topic number two in our database class, we're going to focus on database entities. Let's get started. Let's begin with a little terminology and we will begin by talking about the concept of entity as it relates to relational databases. Now, whether we realize it or not, we've already spoken a bit about entities during our time together in this class. An entity, as is noted here, is essentially something of importance about which we would like to track information in our database. Now, in the past, I've talked about this same concept as this idea of a table containing information about just a single theme or business concept. Some of the examples that we've seen in the past are things like employees, right, an employee is different from a customer or customer is different from a product. Each of these things is a distinct concept and therefore using this new terminology would be modeled as its own entity within our relational database. So an entity is just something of importance about which we need to track information typically it will be more than one attribute of that entity that we want to keep track of and that should stand on its own as its own concept, its own business theme, its own topic, etc. This is an important point to understand about entities is that they do typically contain several attributes or more familiar languages columns, whose values collectively represent the entity. So what does this mean? It's a challenging language, but what's really being said here is that if, in my world, let's say that I want to store information about employees. So I start to create this employee entity and I'm going to give it some columns. So maybe we have an employee ID and we have a let's just keep it simple. Let's say we have a name we keep track of our employees names and we keep track of their email address and maybe we keep track of their phone number. What this is saying is if we want to record information about employees in our database and we decide that based on our needs are based on our business, the information that we need to record is that we need some sort of unique identifier for every employee and the employee's name, email and phone number collectively that is all of the information that we are storing about employees. As far as our database is concerned, the combination of these values is an employee. That's all we know about them. Right. We've decided that we need to record the employee ID, the name, the email address and the phone number. And to us from the perspective of the database, that is an employee. And so what that means is the combination of these values then represent an employee in the context of our database model. Now do keep in mind here that we are doing modeling. Right. And when we create a model, every model has something about it that makes it a model and that is simply that a model is a simplified representation of something in the real world. So, if we think about all of the possible things that we could record for an employee, we could have many more attributes than this. Right. We could record something like the employees. Oh, I don't know. Let's add some more attributes out here. So let's say that we decided to record the employees height. So, the other thing that we could record about them, we could record their weight and we could record their age. Right. We could record other things like their hair color or their eye color. So lots of other possibilities exist for attributes that we might be interested in keeping track of. For our business purposes, we decide that it's not really necessary. We don't necessarily need these. Sorry about that. So we don't necessarily need these values over here for our business, whatever that may be. Right. We don't need those instead we decide that we just need these ones. So what we're talking about here is a model of an employee and we know that an employee is a real world human being. Some human being who works for us. And if we think about all of the things that we possibly could record about any human being, there are thousands and thousands of them. We could record things like the, I don't know, the day of the week on which you were born, we could record the length of your thumbs. We could record your average number of hours of sleep that you get per night. So there are lots and lots of things that are properties of you as an individual human being that if we wanted to describe you entirely that we would need to measure and record. But we do not do that when we are creating a representation of an entity like a human being inside of a database. Instead, what we do is we identify the set of attributes that are necessary or important to us, for carrying out to whatever our business purpose is, and then we can happily ignore all the other attributes that are nevertheless properties of that human being but are not necessary for us to handle our business. So again, we're creating a simplified representation of the real world thing in our database that is by definition a model. Right, a model is a simplified representation of some now keep in mind that this is these concepts are domain specific. So if I'm running like a technology company. I probably need attributes like this for my employees. And maybe I want to record something else like their age or date of birth, but I almost certainly have not recording their hair color or their eye color if you go to work for a company like I don't know Microsoft, they're probably not recording your hair color in their database. I mean, it's not about you. Nevertheless, we can imagine businesses out there where based on the domain or the industry in which that business operates that these sorts of things would be valuable. Let's say that I don't know I'm running like a talent agency, right, where I have say actors available. In that case, I might want to record the person's hair color or their eye color because that might be important in my business. I may be a particular movie script calls for someone with I don't know like hazel colored eyes. Right, or someone with say red hair. In that case, we would want to have these that information available about all of our potential actors so that we could filter the results accordingly based on our business needs. But again, if we're like a company like Microsoft or Starbucks or whatever, we probably don't care so much about our employees hair color or eye color. Instead, we might want some more basic attributes like their name email address phone, etc. So we are learning to create models simplified representations of things in the real world. Now, key thing here is that in the entity relationship world. We restrict the definition of entities to things that can be represented by a single table. And as we don't want to have a single thing that exists in the real world that requires us to record information and multiple tables about them. Each entity should stand on its own. Single theme, a single topic, single business concept per entity.