We've gone over a lot of different things you can do in SQL, from simple things and just pull some fields, to joining multiple tables together. Creating different views and case statements. You have a lot of knowledge and are really well equipped with the few things in your tool box to pretty much do anything you want in terms of extracting, inserting, and updating data. But I think the hard part in learning any programming language is really understanding how it all fits together. So at the next two videos, I want to take you through a few basic principles that will help guide you towards using SQL for your data science. Essentially, how do you bring SQL together for use in data science? After this video, you should be able to discuss the importance of really understanding your data when starting a new problem. As well as discuss the importance of really understanding the business needs before beginning a data analysis. These are just a few things that I use when starting a new problem. I think it's really important to know how to work through a problem from beginning to end. And using SQL for data science, what we're often doing, is extracting the data from some storage system, analyzing it, and then maybe writing back a prediction to the database. This is usually centered around a question or a type of analysis that we're doing. A problem that we want to solve. I think there's a few principles that you can use in making sure that the SQL piece of your work is going through a problem from beginning to end and is successful. All of this starts with the data understanding. This is the most important step. This is why we spent so much time understanding and explaining modeling and Diagrams, and discussing the relationships in your data. Because understanding your data is key to being able to write successful queries. What I mean by understanding your data is really kind of a combination of data understanding and business understanding. It's definitely data understanding, and asking yourself things like, are there lots of NULLs value in this? Is the data made up of string values that were just free form or entered? Or is it concatenated dates and times? But then, there's also this concept of business understanding, meaning how do all these pieces and elements relate to each other. If you're new to this subject area and you've never worked with the data before, it's going to take you a little bit longer to write your queries. Because of this, it's going to take you a little bit longer to figure out, how does everything work together? How does it join or relate to each other? Or, realizing something isn't actually an integer, it's a string, and what does this mean for your analysis? But it'll always be worth taking the time to understand your data as much as you can before you really start to analyze it. It's important to really understand the relationships and the dependencies. That leads us to our second step, which is the business, or subject area understanding. As you start to get familiar with your data, what will happen, is that you'll run into questions about the business problem you're trying to solve, the problem or subject or area that you're looking at. I don't know if steps one or two, data understanding and business understanding, are really separate. Usually, I'm going back and forth between looking at the data and going back to a subject matter expert or somebody who really understands the core business problem, and trying to solve the problem. And I'm asking them more and more questions. Going back to the data then going back and asking more questions. This is essential in being able to really wrap your head around the problem. But also, then, wrapping your head around the data you're using to try and solve for it. One of the things to be careful for is what I call, the unspoken need. You may have a business problem where they say, for example, we want to predict whether or not a customer is likely to buy our product. That seems pretty straight forward and easy, right? But as you dive into the data more, you may start to get questions like, well, what customers? What products? Some of the things that are unspoken are certain logical exclusions. For example, are there certain customers that should be excluded from the this analysis? Are there certain cases where past cells shouldn't be added into this model, or should it be counted? This is why you have to walk in between that data understanding and business understanding. Because you frequently need to look at the data to get questions. And then, you need to go back to the business to understand the problem better. You can think of these steps as two different steps. Because they're definitely two different tasks that you're doing. But you can also think of them as just a back and forth process you're continually doing. This is going to be the most important aspect, though. If you can get this and really understand a problem, the query writing will just come easily. If you really understand your data, and understand the problem, writing the queries is just like filling in the blanks. It's going back to that concept we've talked about frequently in the course, to slowly do. Slowly wrap your head around the problem. Slowly wrap your head around understanding the data. And the query writing will actually come rather simply. Okay, let's pause there for now. We'll go over some other things to consider in this next video. More to come.
