Search⌘ K
AI Features
Home
Courses
Data Science Bootcamp

Welcome to Data Science: How This Course Works

Map a retail returns question to extraction, cleaning, EDA, modeling, evaluation, interpretation, and deployment. Run in-browser Python and SQL sanity checks, then record package versions and a fixed seed for reproducibility.

We'll cover the following...

Reducing product returns starts with a question that a retailer can act on: which products drive returns, and which new orders are likely to come back? A list of raw order records cannot answer that question by itself. The retailer needs a path from records to a decision that someone can inspect and trust.

That path begins with the business question, the decision the analysis must support. Data extraction collects the needed records from a source, often with SQL. Cleaning fixes or removes unusable records, while exploratory data analysis (EDA) inspects patterns, gaps, and unusual values before any prediction is built. Python commonly supports both steps through NumPy and pandas.

Next, modeling uses past orders to produce an estimate or prediction for a new order. Evaluation checks that prediction against held-out records rather than the records used to build it. Interpretation identifies what the result means for the return-reduction decision. Finally, packaging and serving makes a checked result available in a form people or software can use, such as a small Streamlit application.

A model that predicts returns accurately but cannot be checked, explained, or rerun is not a trustworthy decision tool. The workflow keeps the question, the records, and the result connected.

How the course builds the workflow

Basic Python is the one prerequisite. We will use variables, functions, lists, dictionaries, and imports without reteaching their syntax. Every Python and SQL example runs directly in this in-browser environment, with no local setup required.

The course develops the workflow in dependency order.

  • SQL for Data Analysis and From SQL to Python introduce extraction and shaping. SQL retrieves records, while NumPy and pandas make numeric arrays and tables available for analysis in Python.

  • Statistics for Data Science gives us ways to describe variation and measure uncertainty. A return rate from 100 orders carries less certainty than the same rate from 100,000 orders.

  • Data Cleaning and Exploratory Analysis, Feature Engineering, and Data Visualization and Storytelling prepare records for use and communicate what the records show. These steps expose missing values, define useful inputs, and make evidence visible.

  • Framing a Responsible ML Problem turns a business question into a prediction task with a clear outcome and a clear cost for mistakes.

  • Linear Regression, Classification Models, and Generalization, Validation, and Regularization build first models and test whether their results hold beyond the data used to fit them.

  • Decision Trees, Classification Evaluation, Bagging and Random Forests, and Gradient Boosting extend those models and give us stronger ways to judge prediction quality.

  • Model Interpretability and Deployment explains a model’s outputs and packages a result for use beyond an analysis session.

  • Unsupervised Learning, Time Series Fundamentals, Forecasting Models, Text Analytics, A/B Testing, and Recommender Systems apply the same workflow to specialized questions such as customer groups, demand forecasts, written feedback, controlled changes, and product suggestions.

The order matters because evaluation cannot honestly assess a model before the task is framed, and a model cannot use records that extraction and cleaning have not made usable. We can now locate extraction, statistics, modeling, evaluation, and specialized techniques within one connected process.

The checks behind a trustworthy result

Because each workflow stage can introduce error, every result needs a small set of checks. Provenance records where the order data came from and how it reached the analysis. Honest evaluation prevents misleading performance claims caused by leakage, where information unavailable at prediction time slips into the inputs, or by reporting only favorable metrics. Explainability identifies what drives a prediction. Reproducibility means another person can rerun the work and obtain the same result from the same inputs and settings.

Software versions belong to reproducibility. A library update can change a default behavior or remove an older interface. If a return model later produces different output, recorded versions help separate a data change from an environment change.

Trust rule: Before analyzing records, print and record the Python version, library versions, and any fixed random seed.

Record the Python environment

The following check imports the libraries used across the workflow and prints their versions together with a fixed random seed. Copy the resulting block into personal notes before starting later analysis.

Python
import sys
import matplotlib
import numpy as np
import pandas as pd
import plotly
import seaborn as sns
import sklearn
import sqlalchemy
import streamlit
import xgboost
SEED = 42
def main() -> None:
    python_version = sys.version.split()[0]
    packages = [
        ("numpy", np.__version__),
        ("pandas", pd.__version__),
        ("sqlalchemy", sqlalchemy.__version__),
        ("sklearn", sklearn.__version__),
        ("xgboost", xgboost.__version__),
        ("matplotlib", matplotlib.__version__),
        ("seaborn", sns.__version__),
        ("plotly", plotly.__version__),
        ("streamlit", streamlit.__version__),
    ]
    label_width = max(len(name) for name, _ in packages + [("python", "")] + [("seed", "")])
    print("Environment versions")
    print("-" * (len("Environment versions")))
    print(f"{'python':<{label_width}} : {python_version}")
    print(f"{'seed':<{label_width}} : {SEED}")
    print()
    print("Packages")
    print("-" * (len("Packages")))
    for name, version in packages:
        print(f"{name:<{label_width}} : {version}")
if __name__ == "__main__":
    main()

  • Lines 3–11: Importing all workflow libraries up front makes missing or incompatible packages fail immediately, so the version report is only produced when the required libraries can be imported.

  • Line 13: SEED = 42 is the fixed random seed value the lesson asks to record for reproducible analysis.

  • Lines 19–29: Versions are collected directly from each package’s __version__ attribute and kept in a single ordered list so the output is a clear, labeled block.

  • Line 31: The label width is computed from the longest name (including python and seed) so the printed name : version rows align cleanly and remain readable if names differ in length.

  • Lines 33–41: The report prints a heading, the Python version, and the seed, followed by a Packages heading and one aligned name : version row for each package.

This code shows whether the in-browser Python environment can import the required libraries and gives a concrete record of the environment that produced later results. The fixed seed is a chosen starting value for randomized operations. Recording it is not enough on its own: later examples repeat their results only when they pass the seed to each randomized step, such as a data split, a sampler, or a model with a random_state parameter.

Confirm the SQL environment

Python handles much of the analysis, but SQL often supports the extraction stage by retrieving the rows an analysis needs. The following SQL code creates an orders table, adds a few order records, and returns a visible result set.

SQL
CREATE TABLE orders (
  order_id INTEGER PRIMARY KEY,
  product TEXT NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  returned BOOLEAN NOT NULL
);
INSERT INTO orders (order_id, product, amount, returned) VALUES
  (1, 'Notebook', 25.00, FALSE),
  (2, 'Headphones', 75.00, TRUE),
  (3, 'Backpack', 120.00, FALSE),
  (4, 'Mouse', 60.00, TRUE);
SELECT
  order_id,
  product,
  amount,
  returned
FROM orders
WHERE amount > 50
ORDER BY order_id;

  • Lines 1–6: These lines define the orders table schema so the later inserts and query have concrete column types: an integer order_id, text product, an exact decimal amount with two decimal places, and boolean returned.

  • Lines 8–12: These lines insert four sample order records in one statement so the extraction query returns a non-empty result set.

  • Lines 14–21: These lines filter to orders with amount > 50 and sort by order_id, producing a small, ordered extraction-style result set.

This query proves that the SQL environment can create, store, and retrieve records. The returned rows are not an analysis of returns yet. They are the evidence that a later extraction step can supply the records Python will clean, inspect, and model.

Work from self-contained examples

Each code example starts from a blank state. When an example needs an orders table or a small pandas table, the example builds that data inside itself. Nothing depends on an unseen file, a previous run, or an unrecorded setup step. That constraint makes examples safe to rerun and makes failures easier to locate.

Before moving on, confirm four facts:

  • The Python output printed a Python version, library versions, and the fixed seed.

  • The Python code completed without an import error.

  • The SQL code returned visible rows from orders.

  • The outputs are recorded where we can find them again.

We can now recognize a practical data science task as a chain from a decision question through evidence to a result that can be checked. This chapter establishes the workflow and the environment only. SQL querying and pandas data work come later, once the same in-browser checks support every example.