Hello, and welcome to our lecture on data modeling. We're going to have a couple lectures on data modeling. And this first one is sort of the one to many, which is the easiest to understand, and then we'll have another lecture on many to many. Just to give you sort of, we're still sort of building a Django application one piece at a time and we haven't built a whole Django application. But basically, we're really focused on model.py and a little bit more on admin to inform. So model.py is where we define the structure of our database. And we see this database through data models, data model objects. And we can register our data models in admin.py. There's not too much in this admin.py. And so we're going to be talking to things like the shell or you can even run scripts in here. So the whole thing in this lecture, we're not talking much about the routing or the views or forms or templates. So really focus down in this area of our Django application. And it's okay, we'll get to the rest of them. And we're just kind of talking about the data modeling now. So I came to databases late in life. I saw them a little bit in grad school, which is a very long time ago, and I didn't like relational database as much, and I went to a job and I had to learn relational databases for the job. And I actually was a pretty advanced programmer at that point in time. And so they taught me how to do data model design and I picked it up really fast and I totally fell in love with databases. And so the model design is a interesting problem to solve. That the basic idea really comes down to efficiency of storing and retrieving data. And it just come down to, like if you build an online application like Facebook, and if you're not clever about how to store your data and somehow every time you logged into Facebook you had to read all the Facebook's data to find you login. It would really literally can't take you 2 to 3,000 hours to log into Facebook if it had to read all of its data. Now, obviously millions of people log in per second in Facebook. And so obviously they're a little faster than that. So somewhere between days and days and days to read the data, and can read the data million times a second, in there is where databases win. And so at times it seems like when we rely on data model like, this is so difficult, why are we working so hard? And the answer is you just can't scale. I mean, you can read through your data for simple data mining things, but databases are really important, and especially when you're building interactive online application speed's important. So it turns out that most and things in database you can learn the basics pretty quick. And the rest of it is sort of an art form that you you learn as you go. And so the the goal is to figure out the data that you want to store in your application, and then draw a picture spreading that data across multiple tables and then creating links between those tables. So you kind of start with a sample data set. Now, this is where we're going to end up, and this is the model for the data for this local library application that we're building. And this is the thing we're going to keep coming back to over and over. So this is the destination, but we're not going to hit this destination, we're going to start more with the data. Now, different applications when you work at different organizations, you're going to find that the data model is very important. So, this is the data model of my autograder, which is based on a framework I built called Sugi. And so, if you were to learn this thing that early on I say, and here's our data model, and here's how we store stuff, and here's this that and the other thing. And this data model took a lot of time to get right. And it's a real important part of the application. And another project I work on it's called Sakai. It's a learning management system that's open source. And this is a tiny fraction of the data model. But if you want to work in this application, and you want to improve something or at a feature you got to figure out this data model, because where the data goes it shows up kind of flatten the user interface, but eventually it's stored in very specific locations and linked. And that's why you see all these little boxes but then lines. The lines are also the links between the various tables. So there's a whole bunch of theory about database normalization, and it's important, it really is. And if you take some time go ahead and read about it. First normal form the second normal form, third normal form, third normal form, version A and stuff. I'm not really into the math. I don't really want to explain you to the math to you. The key thing about database normalization ultimately, that it can be sort of distilled down to don't replicate string data. And what I mean by string date is like names and URLs and things like that. So in a system ultimately, if my email address is stored in text in that system, it literally should be stored once. There should be no email address, email address, email address. What you need is to have the email address one place, and then kind of give that email address a number and all the places you want to indicate about that email address you use the number. And so these integer numbers are the key. So we create Keys, which are the lookup handles, and then we point to those keys. And we use integers to make links between the tables because integers are fast, they're the thing that computers understand better. Computers understand and move integers around, they use less data, they calculate, they compare really fast. And so integers are very important. So next we're going to take a look at some example of data, and then we're going to design a data model for that data. [MUSIC]
