WEBVTT 00:00.120 --> 00:05.620 OK so we've established that in real life data can be crazy complex outside the classroom. 00:05.640 --> 00:08.180 Things aren't as nice as we'd like them to be. 00:08.220 --> 00:14.190 So we've established that fact but now where do we start to kind of wrap her head around how we represent 00:14.190 --> 00:16.710 complex data using my queue up. 00:16.860 --> 00:21.220 And the answer is we're going to start talking about the relationship basics. 00:21.540 --> 00:26.700 So I know it sounds like you know marriage counseling 101 or something but this is not that it's not 00:26.700 --> 00:31.390 that this is about the different ways that data can be related. 00:31.620 --> 00:37.500 So if we have two tables or two entities things like mortars and customers and students and teachers 00:38.430 --> 00:42.420 movies and reviews and users how how are they related. 00:42.420 --> 00:46.590 And there's a couple of different ways there's that kind of these big broad categories we can break 00:46.590 --> 00:52.350 relationships down into and the terms that I'm going to use that you'll occasionally come across are 00:52.380 --> 00:52.850 three. 00:52.860 --> 00:57.570 There's a first one which is a one to one relationship and it's going to go through all of them first 00:57.600 --> 00:59.370 before we talk about what they mean. 00:59.440 --> 01:00.600 And you talk about examples. 01:00.720 --> 01:08.840 So one to one relationship a one to many relationship and then a many to many relationship. 01:08.850 --> 01:14.970 So the reality is that one to one relationships aren't actually that common but perhaps another example 01:15.120 --> 01:22.720 or one that I've recently used is had a Customers table that had the basic information for a customer. 01:22.740 --> 01:28.800 So things like the username and password although again you don't actually store the password directly 01:29.090 --> 01:32.290 but your name and password and email and the registration date. 01:32.490 --> 01:37.010 And then there was a separate table where we stored all these details about our customer. 01:37.020 --> 01:42.840 So rather than storing 10 or 20 extra columns on the basic customer table we decided to split it up 01:43.290 --> 01:46.980 based off of what was most commonly needed in the app we were building. 01:46.980 --> 01:52.410 And most commonly All we needed was a user name and the password and the email but there was a whole 01:52.410 --> 01:54.240 bunch of other information that we were storing. 01:54.240 --> 01:56.550 So we created a customer details table. 01:56.850 --> 01:58.520 And that's a one to one relationship. 01:58.590 --> 02:06.840 One customer has their own row one row in the customer details table and one customer details row is 02:06.840 --> 02:09.050 associated with one customer. 02:09.360 --> 02:17.490 So cold still has a cold steel customer details but there is no other user or customer that could be 02:17.490 --> 02:23.010 associated with it because it's a one to one relationship anyway so I guess that is not the most common 02:23.470 --> 02:28.770 what is the most common is actually a one to many relationship and that's what we'll spend the most 02:28.770 --> 02:32.110 time on in this course because like I said it's really common. 02:32.370 --> 02:36.480 So here's an example the relationship between books and reviews. 02:36.660 --> 02:40.540 One book can have thousands of reviews right. 02:40.620 --> 02:46.610 Let's say into thin air by Jon Krakauer could have probably tens of thousands of reviews by this point. 02:46.620 --> 02:47.460 Been out for a while. 02:47.490 --> 02:54.540 It's pretty popular but those reviews belong to that book exclusively to one book. 02:54.710 --> 03:05.200 So the relationship is books have many reviews but reviews belong to one book so it's a one to many. 03:05.300 --> 03:07.880 So that's a really common classic example. 03:08.000 --> 03:11.940 Reviews are ratings and books are some entity. 03:12.440 --> 03:12.970 OK. 03:13.250 --> 03:20.510 So then the next thing that we'll discuss here is a many to many relationship and many to many is still 03:20.510 --> 03:23.710 relatively common in the way that it works. 03:23.750 --> 03:30.650 So what it sounds like we have two entities in this case books and authors and you kind of speak through 03:30.650 --> 03:30.760 it. 03:30.770 --> 03:33.430 You could say OK books can have many authors. 03:33.650 --> 03:34.440 That's true. 03:34.670 --> 03:39.990 We could have two authors writing a book together and those authors can have many books. 03:39.980 --> 03:43.720 There's no rule that says authors get know can only write one book. 03:44.040 --> 03:51.050 You know J.K. Rowling rambling However you say that as ten plus books so it's a two way many to many 03:51.110 --> 03:51.800 relationship. 03:51.890 --> 03:57.660 So hopefully you can see the difference to their reviews in books reviews belong to one book. 03:57.680 --> 04:02.090 They're associated only with one book whatever the book title is for that review. 04:02.090 --> 04:06.700 It can also be the same review associated for another book. 04:06.860 --> 04:09.170 So that part of the relationship is one. 04:09.230 --> 04:09.710 Right. 04:09.740 --> 04:15.350 And then we have the books to reviews which is a many relationship books have many reviews. 04:15.350 --> 04:20.900 This is different because books can have multiple authors and authors can be long to multiple books 04:21.350 --> 04:23.520 or authors can have multiple books. 04:23.630 --> 04:27.270 And the way that we represent this is actually a little more complex. 04:27.320 --> 04:28.980 So we're going to come back to it. 04:29.010 --> 04:33.740 We're going to start off in this section by talking about the most common relationship and how we represent 04:33.740 --> 04:35.910 that which is the one to many relationship. 04:35.930 --> 04:36.920 So that's coming up next.