SQL_1.ipynb

{
 "cells": [
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "# SQL Notebook 1: What are the Characteristics of Jobs by Census Block?\n",
    "\n",
    "In these workbooks, we will start with a motivating question, then walk through the process we need to go through in order to answer the motivating question. Along the way, we will walk through various SQL commands and develop skills as we work towards answering the question.\n",
    "\n",
    "As you work, there will be headers that are in **<span style=\"color:green\">GREEN</span>**. These indicate locations where there is an accompanying video. This video may walk through the steps or expand on the topics discussed in that section. Though it isn't absolutely necessary to watch the video while working through this notebook, we highly recommend watching them at least once on your first time through.\n",
    "\n",
    "**<span style = \"color:green\">If you have not yet watched the \"Introduction to Jupyter Notebooks\" video, watch it before you proceed!</span>**\n",
    "\n",
    "You will also run into some headers that are in **<span style=\"color:red\">RED</span>**. These headers indicate a checkpoint to practice writing the code yourself. You should stop at these checkpoints and try doing the exercises and answering the questions posed in these sections.\n",
    "\n",
    "_Note: Normally, a database is stored seperately from the SQL that you use to query the database. However, for the purposes of these lessons, we have created a light-weight database and added some special tools that will allow you to run queries directly in the notebook. While the SQL commands you will use here are the same, keep in mind that interfacing with most production database systems is more complex and generally requires additional software tools or libraries._"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Longitudinal Employer-Household Dynamics (LEHD) Data\n",
    "\n",
    "In these workbooks, we will be using LEHD data. These are public-use data sets containing information about employers and employees. Information about the LEHD Data can be found at [https://lehd.ces.census.gov/](https://lehd.ces.census.gov/). \n",
    "\n",
    "We will be using the LEHD Origin-Destination Employment Statistics (LODES) datasets in our applications in this workbook. Each state has three main types of files: Origin-Destination data, in which job totals are associated with a home and work Census block pair, Residence Area Characteristic data, in which job totals are by home Census block, and Workplace Area Characteristic data, in which job totals are by workplace Census block. In addition to these three, there is a \"geographic crosswalk\" file with descriptions of the Census Blocks as they appear the in the LODES datasets.\n",
    "\n",
    "You can find more information about the LODES datasets [here](https://lehd.ces.census.gov/data/lodes/LODES7/LODESTechDoc7.3.pdf)."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style=\"color:green\">Motivating Question</span>\n",
    "\n",
    "The LODES data has a wealth of information about jobs at the census block level. We want to explore this, so that we can characterize the data that is available to us. That is, for any given state, we want to answer, for example, some of the following questions:\n",
    "\n",
    "- **How many census blocks contain workplaces?**\n",
    "- **What were the most jobs in a census block?**\n",
    "- **How many census blocks had over 50 jobs? Over 100?**\n",
    "- **Among census blocks containing worplaces, what is the average number of jobs per census block?**\n",
    "\n",
    "These, as well as other questions about the data we might answer, can help us better understand the distribution of jobs by location. In this notebook, try to keep these types of questions in mind as we explore the data."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Starting Out: Introduction to SQL and Relational Databases\n",
    "\n",
    "SQL is a language designed for a very specific purpose: to interact with relational databases. \n",
    "\n",
    "- **Database**: A database is a structured collection of data. There are various different ways of structuring the database, and there may or may not be information about the relationship between entities in the database.\n",
    "- **Query**: A query is a request for data from the database. \n",
    "- **Database Management System (DBMS)**: A DBMS is a system of storing and managing databases, including querying the database.\n",
    "- **Relational Database Management System (RDBMS)**: In an RDBMS, data records are stored in *tables*, each of which has a predefined set of *columns*, the pieces of information captured for each record in a table, and *rows* in the table, where each row has a place to store a value for every column in the table.\n",
    "\n",
    "Tables, including their columns, column types and relationships with other tables, are defined in a database **schema**. Many times, tables will contain a **primary key**, one or more columns that uniquely define a row. You can think of the primary key as a kind of ID, in which each row is given a unique ID. Tables can also contain  **foreign keys**, which are column(s) that comprise the primary key in another table and, thus, provides a way of matching between multiple tables."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style=\"color:green\">Writing a Basic Query (VIDEO)</span>\n",
    "\n",
    "In order to analyze the data in a database, we need to query it, or request specific information about the data. Before we do that, run the following cell to establish a connection to the database:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "%defaultDatasource jdbc:sqlite:lodes.db"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Now, let's start with some basics. We'll start by retrieving all columns from the California Workplace Area Characteristic (`ca_wac_2015`) table. Try running the following query:"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT * FROM ca_wac_2015 LIMIT 10;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "You should see 10 rows of the `ca_wac_2015` dataset. Let's go over the basics of this SQL command.\n",
    "\n",
    "- **SELECT:** We start out with the `SELECT` statement. The `SELECT` statement specifies which variables (columns) you want. \n",
    "    - Here, we used `SELECT *`. The \"`*`\" just says that we want all the variables. \n",
    "    - If we wanted a few columns, we would use the column names separated by commas instead of \"`*`\" (for example, `w_geocode, createdate`).\n",
    "\n",
    "\n",
    "- **FROM:** Now, let's look at the next part of the query, `FROM ca_wac_2015`. This part of the query specifies the table, `ca_wac_2015`, from which we want to retrieve the data. Most of your queries will begin in this fashion, describing which columns you want and from which table.\n",
    "\n",
    "\n",
    "- **LIMIT:** We typically include a `LIMIT` statement at the end of our query so that we don't get overloaded with rows being output. Here, `LIMIT 10` means that we just want the first ten rows. Many times, the `LIMIT` that you want will be higher than 10 -- you might generally prefer to use 1000 or so. Having a `LIMIT` for all queries is highly recommended even if you know only a few rows will be shown, since it acts as a safety precaution against (for example) displaying millions of rows of data.\n",
    "\n",
    "In this case, we've put everything in one line, but that's not necessary. We could have split the code up into multiple lines, like so:\n",
    "\n",
    "    SELECT * \n",
    "    FROM ca_wac_2015\n",
    "    LIMIT 10;\n",
    "\n",
    "This gives the same output as our original query. Generally, once queries start getting longer, breaking up the code into multiple lines can be very helpful in organizing your code and making it easier to read.\n",
    "\n",
    "Along those lines, note that we used a semi-colon at the end of the query to mark the end of the query. That isn't absolutely necessary here, but it does help mark the end of a query and is required in other applications of SQL, so it's good practice to use it. \n",
    "\n",
    "> ### Side note about capitalization\n",
    "If you notice, we've been using all caps for SQL commands and all lowercase for data table and schema names. This is simply a convention, as SQL is not case sensitive. For example, we could have run `select * from ca_wac_2015 limit 10;` and it would have given us the exact same output as the first query. \n",
    "\n",
    "> This does mean you need to be careful when using column names. If your column name has capital letters in it, you need use double quotes (e.g. `\"C000\"`) to preserve the capitalization. For this reason, you might find that using all lowercase letters in column names is preferable, which is what we've done here.\n",
    "\n",
    "Now, consider the following query. What do you think it will do?\n",
    "\n",
    "    SELECT w_geocode, createdate \n",
    "    FROM ca_wac_2015\n",
    "    LIMIT 100;\n",
    "\n",
    "We've changed the original query by using `w_geocode, createdate` instead of `*`, so we'll only get the values from two columns, `w_geocode` and `createdate`. In addition, we've changed the value after `LIMIT` to be 100 instead of 10, so we'll get the first 100 rows instead of the first 10 rows."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT w_geocode, createdate \n",
    "FROM ca_wac_2015\n",
    "LIMIT 100;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style = \"color:red\">Checkpoint 1: Running Basic Queries</span>\n",
    "\n",
    "Consider the following queries. What do you think they will do? Try figuring out what the output will look like, then run the code to see if you're correct.\n",
    "\n",
    "- `SELECT * FROM ca_wac_2015 LIMIT 25;`\n",
    "- `SELECT c000,ca01,ca02,ca03 FROM ca_wac_2015 LIMIT 1000;`\n",
    "- `SELECT * FROM ca_od_2015 LIMIT 100;`\n",
    "- `SELECT * FROM ca_rac_2015 LIMIT 40;`\n",
    "\n",
    "Think about the following scenarios. What is the query you would use to answer these questions? Try them out.\n",
    "\n",
    "- You want to see the first 100 rows of the origin and destination geocodes for each census block in California.\n",
    "- You want to see the top 1000 rows of census blocks containing workplaces and the number of jobs for workers of each race."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "\n",
    "\n",
    "\n",
    "\n"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style=\"color:green\">Checking Number of Rows and Duplicates (VIDEO)</span>\n",
    "\n",
    "Let's say we want to find out how many rows there are. You can do this by using a `COUNT`."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT COUNT(*) \n",
    "FROM ca_wac_2015;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Here, we used `COUNT(*)`, which does a count of all rows, regardless of `NULL` values. We can instead do a count of all non-`NULL` values of a certain variable by including that variable instead of `*`."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT COUNT(w_geocode) \n",
    "FROM ca_wac_2015;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "But wait; what if there are duplicates in the data? We can check for them by using `DISTINCT`."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT DISTINCT(w_geocode) \n",
    "FROM ca_wac_2015\n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This shows us all of the rows with distinct `w_geocode` values; that is, all of the distinct census block ids. Let's count how many there are. To count them, all we have to do is put `COUNT()` around the `DISTINCT` part. "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT COUNT(DISTINCT(w_geocode)) \n",
    "FROM ca_wac_2015;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "> ### Building Up a Query\n",
    "> Notice that we wanted to count the number of distinct rows, but we first started from querying the rows with distinct `w_geocode` first before adding in the `COUNT`. Though this is a simple example, this process of building up a query as we go is important, especially when we get to more complicated tasks. When writing a query, try to think about the basic parts first, and feel free to run intermediate steps (making sure to include `LIMIT`) as you go. "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "##  <span style=\"color:green\">Using Conditional Statements</span>\n",
    "\n",
    "Suppose we want to look at a subset of the data. We can use conditional statements to do this."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT *\n",
    "FROM ca_wac_2015 \n",
    "WHERE c000 < 100\n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Using a query like the one above can be useful for finding if there are any data entry errors or missing values. Since it's not possible to have an age less 0, if there are any rows with negative age, this is likely an error or the method used to code missing values (e.g. `-1`). \n",
    "\n",
    "We can also use more complicated conditional statements."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT count(*) \n",
    "FROM ca_wac_2015\n",
    "WHERE (c000 > 50) AND (c000 < 100);"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This subsets to rows in which `c000` is greater than 50 and `c000` is less than 100. That is, this subsets to census blocks with between 50 and 100 total jobs. Using `OR` works in the same way."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT count(*) \n",
    "FROM ca_wac_2015\n",
    "WHERE (c000 <= 50) OR (c000 >= 100);"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This subsets to rows in which `c000` is less than or equal to 50 or `c000` is greater than or equal to 100. This query should, in other words, capture the rest of the rows."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "> ### Common Comparison Operators\n",
    "> Though there are some more complicated comparison operators (if you're curious, feel free to look up what `LIKE` and `IN` do), these should cover most of what you want to do. \n",
    "> - **`=`**: equal to\n",
    "- **`!=`** or \"**`<>`**\": not equal to\n",
    "- **`<`**: less than\n",
    "- **`<=`**: less-than-or-equal-to\n",
    "- **`>`**: greater than\n",
    "- **`>=`**: greater-than-or-equal-to\n",
    "- **`IS NULL`** and **`IS NOT NULL`**: The signifier of a row in a column not having a value is a special keyword: `NULL`.  To check for `NULL`, you use `IS NULL` or `IS NOT NULL`, rather than \"=\" or \"!=\". For example, to count the number of rows with `NULL` values for `c000` we might use the following:\n",
    "\n",
    ">        SELECT count(*) \n",
    ">        FROM ca_wac_2015\n",
    ">        WHERE c000 IS NULL;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## Creating Variables\n",
    "\n",
    "Suppose we want to create a new column in the table that acts as a \"flag\" for which rows fit a certain condition, so that you can use them later. We can do this using the `ALTER TABLE` statement."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "ALTER TABLE ca_wac_2015 ADD over100 BOOL;"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "UPDATE ca_wac_2015 SET over100 = 0;"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "UPDATE ca_wac_2015 SET over100 = 1 WHERE c000 > 100;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Let's break this down line by line. First, we use `ALTER TABLE`, then specify the table we want to alter. In this case, we want to alter the `ca_wac_2015` table. Then, we `ADD` a new column, `over100`. We designate this as a `BOOL` for boolean (that is, a TRUE/FALSE value) column. \n",
    "\n",
    "After we create this new column, we need to fill it with the appropriate values. First, we're going to set everything in the column to be 0 (or False). To do this, we use `UPDATE`, specify the appropriate table, then use `SET over100 = 0`. Then, we replace the value with 1 (or True) if the value in `c000` for that row is above 100. We again use `UPDATE` in a similar manner, except we add a `WHERE` clause, so that it only set the value to TRUE if a certain condition is met -- in this case, that `c000 > 100`."
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style = \"color:red\">Checkpoint 2: Counting Rows, Using Conditional Statements and Creating Variables</span>\n",
    "\n",
    "We've included the 2015 OD, RAC, WAC, and geography crosswalk data for both California and Illinois for you in tables. The California tables are named the following:\n",
    "- `ca_wac_2015`: CA Workplace Area Characteristics\n",
    "- `ca_rac_2015`: CA Residence Area Characteristics\n",
    "- `ca_od_2015`: CA Origin-Destination\n",
    "- `ca_xwalk`: CA Geography Crosswalk\n",
    "\n",
    "The Illinois data follow the same format as the California, except with `il` replacing `ca` (e.g. `il_wac_2015` for the Illinois 2015 WAC). Try using the methods described in this section to further explore the tables. If you are using PostgreSQL on your own computer, feel free to bring in data from a different state (using the document about bringing in data into PostgreSQL), or use the California or Illinois data provided for you. Answer the questions below, making sure to write out the queries used to answer the questions.\n",
    "\n",
    "- How many census blocks contain more than 200 jobs?\n",
    "- How many census blocks contain residences of fewer than 25 workers?\n",
    "- How many census blocks contain workplaces with more than 10 workers with a Bachelor's degree or higher?\n",
    "- How many counties are there?\n",
    "- How many total census blocks are there?\n",
    "- How many Metropolitan/Micropolitan areas are there?"
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "\n",
    "\n",
    "\n",
    "\n"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style=\"color:green\">Using Aggregation Functions (VIDEO)</span>\n",
    "\n",
    "We've created a variable that indicates whether the census block had over 100 jobs or not. What if we wanted to know how many blocks had over 100 jobs and how many didn't? We can now use the `GROUP BY` statement. "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT over100, COUNT(over100) \n",
    "FROM ca_wac_2015 \n",
    "GROUP BY over100 \n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Here, the `GROUP BY` statement groups it into the categories of the variable. Since we've chosen to display the count, we can see the counts. We can also change the order in which the results are displayed so that it's in increasing order. "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT over100, COUNT(over100) \n",
    "FROM ca_wac_2015\n",
    "GROUP BY over100 \n",
    "ORDER BY COUNT(over100)\n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "The `ORDER BY` statement orders the rows that it displays according to whatever you put after it. In this case, we chose the count of `over100`. \n",
    "\n",
    "### Using GROUP BY with Multiple Variables\n",
    "\n",
    "For the next few queries, let's try using a different table. The `ca_xwalk` table in the same `lodes` database contains information about each of the census blocks in California. We can use this to, for example, look at aggregation by CBSA (metropolitan/micropolitan area) name and by county name."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT cbsaname, ctyname, COUNT(*)\n",
    "FROM ca_xwalk\n",
    "GROUP BY cbsaname, ctyname\n",
    "ORDER BY COUNT(*) DESC\n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This first groups by CBSA (`cbsaname`) name, then it groups by county (`ctyname`), in that order. In this case, county is nested completely in the metropolitan/micropolitan area. In other cases in which we don't have complete nesting, we would be able to see all possible combinations that exist in the data.\n",
    "\n",
    "Further, notice that we used `DESC` after `ORDER BY`. This orders in descending order instead of ascending order, so that we can see the areas with the most census blocks at the top.\n",
    "\n",
    "### Conditional Statements After Aggregation\n",
    "\n",
    "Suppose we wanted to display only certain counts. We can use `HAVING` to do this."
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT ctyname, cbsaname, COUNT(cbsaname)\n",
    "FROM ca_xwalk\n",
    "GROUP BY ctyname, cbsaname\n",
    "HAVING count(cbsaname) > 20000\n",
    "ORDER BY COUNT(*) DESC\n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "This will only display the counts for which the count of `cbsaname` is greater than 20000. Note that this is different from using `WHERE`, since the conditional statement comes after the `GROUP BY` statement. Basically, `HAVING` gives us a way of using the same types of conditional statements after we do our aggregation.\n",
    "\n",
    "### Using Different Aggregation Functions\n",
    "\n",
    "What if we wanted to find the sum within each group, or the minimum or maximum value? We can use the appropriate aggregation function. To show this, let's go back to our `ca_wac_2015` table. "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "SELECT over100, COUNT(over100), AVG(c000) AS avg_jobs, MIN(c000), MAX(c000)\n",
    "FROM ca_wac_2015 \n",
    "GROUP BY over100 \n",
    "ORDER BY over100\n",
    "LIMIT 1000;"
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "Here, we're finding the counts, average, minimum, and maximum value of the total jobs in each census block within each group. Now, we're not doing anything very insightful here, since the groups already split the blocks by how many jobs there are. However, as we'll see later on, these aggregation functions can be very useful. For example, suppose we had the county data that's in `ca_xwalk` in this table. We could find the average number of jobs per census block for each county in this way.\n",
    "\n",
    "> ### Side Note: Aliasing\n",
    "> You may have noticed that we included a part using \"`AS`,\" followed by a new name, in the first line. When you ran the code, you might have noticed that the column labels were changed to these new names. This is called aliasing, and is done for readability and ease of access. Later on, aliasing will also help us more easily reference tables within the same query.  "
   ]
  },
  {
   "cell_type": "markdown",
   "metadata": {},
   "source": [
    "## <span style = \"color:red\">Checkpoint 3: Checking Your Dataset</span>\n",
    "\n",
    "Using the above methods, explore the tables we've provided or your own state's data to answer the questions below. As before, make sure to include the queries with your answers.\n",
    "\n",
    "- Which county has the most census blocks? \n",
    "- Which Metropolitan/Micropolitan area has the most census blocks?\n",
    "- Which Origin census block - Destination census block combination has the most workers? How many workers are in this combination?\n",
    "- How would you find all counties containing at least 1000 census blocks?\n",
    "- For California, how many census blocks are there with a latitude above +36? \n",
    "- For California, which county has the most census blocks above the +36 latitude line? Which county has the most below? "
   ]
  },
  {
   "cell_type": "code",
   "execution_count": null,
   "metadata": {},
   "outputs": [],
   "source": [
    "\n",
    "\n",
    "\n"
   ]
  }
 ],
 "metadata": {
  "anaconda-cloud": {},
  "kernelspec": {
   "display_name": "SQL",
   "language": "SQL",
   "name": "sql"
  },
  "language_info": {
   "codemirror_mode": "sql",
   "file_extension": ".sql",
   "mimetype": "",
   "name": "SQL",
   "nbconverter_exporter": "",
   "version": ""
  },
  "toc": {
   "base_numbering": 1,
   "nav_menu": {},
   "number_sections": false,
   "sideBar": false,
   "skip_h1_title": false,
   "title_cell": "Table of Contents",
   "title_sidebar": "Contents",
   "toc_cell": false,
   "toc_position": {},
   "toc_section_display": false,
   "toc_window_display": false
  }
 },
 "nbformat": 4,
 "nbformat_minor": 4
}