Databricks SQL Bakery Sales Analysis

Use Databricks SQL to analyze bakery sales and publish findings on GitHub.

Introduction

30 Second Summary

Bakery receipts capture every sale as a separate line. A manager still needs a clear way to see which products and stores bring in the most revenue.

In this project, you will use Databricks SQL to investigate sales from a small bakery dataset. You will visualize the strongest store result before publishing the reproducible investigation on GitHub.

What You'll Build

Picture running your notebook to see Riverside stand tallest in a revenue bar chart at 73.00.

By the end of this project, you'll have:

  • A reproducible sales notebook where you can recreate the dataset whenever the session restarts. You can inspect all 12 transaction lines without downloading a file.
  • A product performance ranking that shows Sourdough Loaf leading with 56.00 in total revenue. You can compare it with the Downtown line ranking to explain why aggregation changes the answer.
  • A store revenue bar chart that makes Riverside's 73.00 result easy to present. A public GitHub portfolio repository lets anyone inspect the SQL and reproduce your findings.
  • Secret Mission: Add a HAVING filter that keeps only products earning at least 45.00 in total revenue.

Are there any prerequisites?

You need a Databricks Free Edition account plus a GitHub account. You do not need local development tools because the entire workflow runs in your browser.

Before We Start

A clear project purpose gives every analysis decision a business reason. This is your moment to connect bakery product and location performance to the decisions a bakery manager needs to make.

Set Up a Reliable Bakery Dataset

Your bakery investigation needs stable transaction rows before its calculations can answer a manager's questions.

A self-contained dataset protects the project from changes in shared sample schemas. In this step, you create that dataset inside a Databricks Free Edition SQL notebook.

In this step, get ready to:
  • Create a notebook named Bakery Sales Investigation with serverless compute.
  • Create the bakery_sales temporary view from 12 bakery sales lines.
  • Confirm that the temporary view contains all 12 rows.
Create the SQL notebook

A notebook keeps executable SQL beside its results. Serverless compute processes each cell without requiring a local database installation.

  • Go to Databricks Free Edition in your browser.
  • Sign in with your existing account.
  • Select New in the left sidebar.
  • Select Notebook.
  • Replace the generated notebook name with Bakery Sales Investigation.
  • Set the Default language to SQL.
  • Use the notebook's compute control to select the available serverless compute.

You should see Bakery Sales Investigation at the top of the notebook. SQL should be the default language with serverless compute attached.

Notebook Did Not Open?

  • Confirm that your browser session is signed in to Databricks Free Edition.
  • Select the available serverless compute again if the notebook shows no attached compute.
  • Ask for targeted help with creating the Databricks SQL notebook.
  • Share a redacted screenshot in the NextWork community if the workspace still behaves differently.
Create the temporary view

The temporary view gives every query the same five named columns. Its session-scoped lifetime keeps the project self-contained without creating persistent catalog data.

Why Use an Inline Dataset?

Shared sample schemas can change between workspaces. Inline values keep these 12 bakery sales lines under your control.

Anyone can reproduce the same analysis by running this setup statement first.

  • Create the bakery_sales temporary view in the first notebook cell by pasting this SQL:
-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

What Does This SQL Create?

  • The CREATE OR REPLACE TEMP VIEW statement creates a session-scoped view named bakery_sales.
  • The column list names the transaction identifier, product, store, quantity, and unit price fields.
  • The VALUES section supplies 12 fixed rows without requiring a file upload.
  • Run the setup cell by pressing Shift+Enter.

The cell should finish without a SQL error. The bakery_sales temporary view is now available to later cells in this compute session.

The Setup Cell Did Not Finish?

  • Confirm that the notebook language is set to SQL.
  • Check that the final bakery row ends with a closing parenthesis followed by a semicolon.
  • Ask for help with diagnosing the temporary view statement.
Verify all 12 rows

A successful setup message confirms that the statement ran. A count query proves that every bakery sales line reached the temporary view.

Before you run this check, how many rows do you expect the count to return?

  • Add the verification query to the empty SQL cell beneath the setup statement by pasting this code:
-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

What Does This Query Check?

The COUNT(*) AS row_count expression counts every row in the temporary view. The alias gives the result column a readable name.

  • Run the count query by pressing Shift+Enter.

The result table should show row_count with the value 12. That checkpoint confirms your complete bakery dataset is ready for analysis.

The Count Is Missing or Incorrect?

  • Run the dataset setup cell again before rerunning the count query.
  • Confirm that all 12 value tuples are present in the first cell.
  • Ask for targeted help with checking the bakery row count.

✔️ Awesome, I've got everything!

Your two notebook cells create the complete 12-row temporary view and verify its row count.

ⓧ I'd like to double check the full code

-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

Your 12-row bakery dataset is ready. Next, you will inspect its named columns and representative sales rows.

Preview the Sales Rows

Your Databricks Free Edition notebook now contains 12 verified bakery sales rows. The count confirms that the dataset is complete.

A focused SQL SELECT preview reveals the fields inside those rows. Inspecting named columns first prevents calculations against data you have not inspected.

In this step, get ready to:
  • Add a query that previews the five columns used in the investigation.
  • Connect each selected column to its business meaning.
  • Test a five-row limit before restoring the ten-row preview.
Add the preview query

A preview keeps the output focused on the columns that support the investigation. Sorting by sale_id gives the rows a consistent order.

  • Add a new SQL cell beneath the row-count cell.
  • Paste the preview query below into the new cell:
-- Preview sales rows.
SELECT
  sale_id,
  product_name,
  store_location,
  quantity,
  unit_price
FROM bakery_sales
ORDER BY sale_id
LIMIT 10;

What Does This Query Do?

  • The SELECT list chooses the five fields needed for the investigation.
  • The FROM bakery_sales clause reads rows from the temporary view created earlier.
  • The ORDER BY sale_id clause places the transactions in identifier order.
  • The LIMIT 10 clause keeps the result to the first ten ordered rows.
  • Run the preview cell by pressing Shift+Enter.

The Table result should show 10 rows. The headers should be sale_id, product_name, store_location, quantity, and unit_price.

That is your first visible analysis result. The bakery dataset now reads like business records.

Preview Table Missing?

  • Confirm that the new notebook cell uses SQL.
  • Rerun the dataset setup cell if the session-scoped temporary view is unavailable.
  • Compare the selected column names with the query above.

Ask for help with troubleshooting the bakery sales preview.

Read the business columns

Each result row represents one bakery transaction line. Together, the five columns describe what sold at one location.

What Does Each Column Mean?

  • The sale_id column identifies the transaction line.
  • The product_name column names the bakery product.
  • The store_location column shows where the sale happened.
  • The quantity column records the number of units sold.
  • The unit_price column records the price of one unit.
Test the result limit

The LIMIT clause controls the maximum number of rows shown. The ordered result makes the size change easy to observe.

  • Change LIMIT 10 to LIMIT 5 in the preview cell.

Before you rerun it, how many rows do you expect the smaller limit to return.

  • Run the edited preview cell by pressing Shift+Enter.

The Table result now shows five rows. The first row still has a sale_id of 1.

  • Replace LIMIT 5 with LIMIT 10.

Before the final run, how many rows do you expect after restoring the original limit.

  • Run the restored preview cell by pressing Shift+Enter.

The Table result shows 10 rows again. It displays sale_id, product_name, store_location, quantity, and unit_price.

You have now tested the limit without changing the finished analysis. Your ten-row preview is restored.

Still Seeing Five Rows?

  • Confirm that the final query line says LIMIT 10.
  • Rerun the preview cell after restoring the value.
  • Check that you are viewing the latest result beneath the preview cell.

Ask for help with restoring the ten-row preview.

✔️ Awesome, I've got everything!

Your notebook query is restored to LIMIT 10. The result table shows ten rows with all five selected headers.

ⓧ I'd like to double check the full code

-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

-- Preview sales rows.
SELECT
  sale_id,
  product_name,
  store_location,
  quantity,
  unit_price
FROM bakery_sales
ORDER BY sale_id
LIMIT 10;

Your verified rows now have clear business meaning. Next, you will calculate revenue for each Downtown transaction line and rank the results.

Rank Individual Sales

Your Databricks Free Edition notebook already proves that the bakery dataset contains the columns needed for analysis. Those rows show quantity beside unit price.

Now SQL arithmetic can calculate the revenue generated by each transaction line. You will rank the Downtown sales to test whether row-level results can identify the strongest product across all stores.

In this step, get ready to:
  • Calculate revenue for each transaction line with the readable alias line_revenue.
  • Filter the results to sales from Downtown.
  • Rank the transaction lines by descending revenue to evaluate the row-level result.
Calculate Downtown line revenue

Revenue for one transaction line is quantity multiplied by unit price. A column alias gives that calculated expression the readable heading line_revenue.

The WHERE clause narrows the calculation to one store location. This creates a focused view of Downtown sales.

  • Add a SQL cell beneath the preview query.
  • Calculate revenue for the Downtown rows by pasting this query into the new cell:
-- Rank individual Downtown transaction lines.
SELECT
  sale_id,
  product_name,
  quantity,
  unit_price,
  quantity * unit_price AS line_revenue
FROM bakery_sales
WHERE store_location = 'Downtown'

What Does This Query Do?

  • The quantity * unit_price expression calculates revenue for one transaction line.
  • The AS line_revenue alias gives the calculated column a business-friendly name.
  • The WHERE store_location = 'Downtown' condition keeps only Downtown transactions.
  • Run the current cell with Shift+Enter.

Good progress. You will see four Downtown rows with a line_revenue value for each transaction.

Missing the Revenue Column?

  • Confirm that quantity * unit_price AS line_revenue appears in the SELECT list.
  • Rerun the first setup cell if the bakery_sales temporary view disappeared after the compute session ended.
  • Ask for targeted help with diagnosing the missing revenue result.
Rank the Downtown transactions

The ORDER BY clause controls the sequence of the result rows. The DESC direction places the largest calculated revenue first.

  • Update the Downtown query with descending revenue sorting by replacing its contents with the code below:
-- Rank individual Downtown transaction lines.
SELECT
  sale_id,
  product_name,
  quantity,
  unit_price,
  quantity * unit_price AS line_revenue
FROM bakery_sales
WHERE store_location = 'Downtown'
ORDER BY quantity * unit_price DESC;

How Does the Ranking Work?

  • The query calculates line_revenue before presenting the result.
  • The ORDER BY quantity * unit_price DESC clause ranks the calculated values from highest to lowest.
  • The output still preserves each sale as its own transaction line.

Before you run the ranking, which product do you expect to appear first?

  • Run the completed Downtown query with Shift+Enter.

Your ranking works. Croissant appears first with a line_revenue of 24.00.

Ranking in the Wrong Order?

  • Confirm that the final line contains ORDER BY quantity * unit_price DESC.
  • Check that DESC follows the complete revenue expression.
  • Ask for targeted help with fixing the Downtown revenue order.

✔️ Awesome, I've got everything!

Your notebook now contains the complete Downtown transaction-ranking query.

ⓧ I'd like to double check the full code

-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

-- Preview sales rows.
SELECT
  sale_id,
  product_name,
  store_location,
  quantity,
  unit_price
FROM bakery_sales
ORDER BY sale_id
LIMIT 10;

-- Rank individual Downtown transaction lines.
SELECT
  sale_id,
  product_name,
  quantity,
  unit_price,
  quantity * unit_price AS line_revenue
FROM bakery_sales
WHERE store_location = 'Downtown'
ORDER BY quantity * unit_price DESC;
Test the ranking's limit

The first row reveals the largest individual Downtown sale. The business question asks which product earned the most across every store.

  • Inspect the four displayed transaction rows in the result table.
  • Look for one combined revenue total for each product.

The table contains separate transaction rows. A single large sale cannot show a product's combined performance across all stores.

That is the intended shortfall. The query answers a transaction-level question without answering the overall product question.

You have proved exactly where row-level analysis stops. Next, you will combine each product's transactions into one performance summary.

Find the Best-Performing Product

Your Downtown ranking identified Croissant as the highest-revenue transaction line. Separate rows still hide each product's performance across all stores.

The GROUP BY clause combines rows that share a product name.

SUM calculates totals for each product. COUNT measures how many transaction lines contributed.

In this step, get ready to:
  • Group all sales into one row per product.
  • Calculate three performance metrics for each product.
  • Rank the grouped products by total revenue.
Group sales by product

Grouping changes the result from one row per transaction to one row per product. Each aggregate then works across every sales line in that product's group.

  • Add a SQL cell below the Downtown transaction query.
  • Populate the new cell with the grouped product summary by copying this query:
-- Summarize performance by product.
SELECT
  product_name,
  SUM(quantity) AS units_sold,
  SUM(quantity * unit_price) AS revenue,
  COUNT(*) AS transaction_lines
FROM bakery_sales
GROUP BY product_name
ORDER BY SUM(quantity * unit_price) DESC;

How Does the Product Summary Work?

  • The GROUP BY product_name clause combines sales lines that share the same product name.
  • The SUM(quantity) expression calculates the total number of units sold for each product.
  • The SUM(quantity * unit_price) expression calculates each product's total revenue.
  • The COUNT(*) expression counts the transaction lines in each product group.
  • The descending ORDER BY clause places the highest-revenue product first.

Before you run the new query, do you expect the product with the highest single Downtown line to remain first after all stores are combined?

  • Run the current cell by pressing Shift+Enter.

You'll see four product rows ordered by revenue. Sourdough Loaf appears first.

You have closed the transaction-level gap. The notebook now compares complete product totals.

Product Summary Did Not Run?

  • Check that the query groups by product_name.
  • Switch back to the dataset setup cell if the temporary view is unavailable.
  • Rerun the dataset setup cell before retrying the product summary.

Ask for help with diagnosing the grouped product query.

✔️ Awesome, I've got everything!

Great. Your notebook now contains the complete product summary query.

ⓧ I'd like to double check the full code

  • Compare your notebook cells with the complete analysis so far:
-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

-- Preview sales rows.
SELECT
  sale_id,
  product_name,
  store_location,
  quantity,
  unit_price
FROM bakery_sales
ORDER BY sale_id
LIMIT 10;

-- Rank individual Downtown transaction lines.
SELECT
  sale_id,
  product_name,
  quantity,
  unit_price,
  quantity * unit_price AS line_revenue
FROM bakery_sales
WHERE store_location = 'Downtown'
ORDER BY quantity * unit_price DESC;

-- Summarize performance by product.
SELECT
  product_name,
  SUM(quantity) AS units_sold,
  SUM(quantity * unit_price) AS revenue,
  COUNT(*) AS transaction_lines
FROM bakery_sales
GROUP BY product_name
ORDER BY SUM(quantity * unit_price) DESC;
Read the aggregate metrics

The aliases turn aggregate expressions into readable business metrics. The first row contains the strongest product performance across the full dataset.

  • Locate the Sourdough Loaf row in the result table.
  • Read the value under units_sold.
  • Read the value under revenue.
  • Read the value under transaction_lines.

The units_sold cell shows 7. The revenue cell shows 56.00.

The transaction_lines cell shows 3. Three source rows contributed to the winning total.

Compare the product and transaction rankings

The Downtown query ranked individual sales lines. The product summary ranks combined performance across every store.

Before you rerun the product summary, do you expect Croissant's highest single line to outweigh Sourdough Loaf's combined sales?

  • Return to the product summary cell.
  • Run the current cell by pressing Shift+Enter.

You'll see Sourdough Loaf first with 7 units. Its revenue is 56.00.

The same row shows 3 transaction lines. Croissant's 24.00 described only one Downtown transaction.

That's the business question answered. Your analysis now identifies the best-performing product from all sales.

Your product ranking now reflects performance across the entire bakery dataset. Next, you'll turn a location summary into a bar visualization and publish the investigation.

Visualize and Publish the Investigation

Your Databricks Free Edition notebook now identifies the best-performing product. A location chart makes the next finding understandable at a glance.

Publishing the investigation on GitHub gives another person access to the SQL. A documented repository also explains the business findings and reproduction steps.

In this step, get ready to:
  • Summarize revenue by store location.
  • Turn the location summary into a bar visualization.
  • Publish the complete SQL and documented findings in a public GitHub repository.
Build the location chart

The product summary groups transactions by product. The next query applies the same aggregation pattern to store locations.

  • Add a SQL cell beneath the product summary in the notebook.
  • Calculate the revenue for each store location by pasting this query into the new cell:
-- Summarize revenue by store location for the bar visualization.
SELECT
  store_location,
  SUM(quantity * unit_price) AS revenue
FROM bakery_sales
GROUP BY store_location
ORDER BY SUM(quantity * unit_price) DESC;

What Does This Query Do?

  • The GROUP BY clause combines every transaction from the same store location.
  • The SUM expression calculates the total revenue for each location.
  • The descending sort places the highest-revenue location first.

Before you run the query, which store location do you expect to rank first?

  • Run the current cell with Shift+Enter.

The result contains one row per location. You should see Riverside first with revenue of 73.00.

Location Totals Look Wrong?

Confirm that the query groups by store_location. Check that the revenue expression multiplies quantity by unit_price before applying SUM.

Ask for help with diagnosing the location summary.

A table provides exact values. A bar visualization makes the difference between locations faster to compare.

  • Select + above the location result table.
  • Choose Visualization.
  • Set Visualization Type to Bar.
  • Set the category to store_location.
  • Set the value to revenue.
  • Select Save.

Your saved chart should display three bars. Riverside should have the tallest bar at 73.00.

Chart Does Not Show Three Locations?

Rerun the location summary before creating the visualization. Confirm that store_location is the category field.

Ask for help with fixing the Databricks bar visualization.

Publish the SQL analysis

The notebook proves that the analysis works in your workspace. A public repository makes the same SQL inspectable without requiring access to that workspace.

Why Publish Through the Browser?

GitHub can create the repository and files directly in the browser. This keeps the project reproducible without depending on a local Git installation.

  • Return to GitHub in your browser.
  • Select New repository.
  • Enter databricks-bakery-sales-analysis as the repository name.
  • Choose Public as the visibility.
  • Turn Add README on.
  • Select Create repository.

Good progress. Your public repository now has a README that can introduce the investigation.

  • Select Add file above the repository file list.
  • Select Create new file.
  • Enter bakery_sales_analysis.sql in the file name field.
  • Add the reproducible dataset and row-count check by pasting this first section into the file contents text box:
-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

What Does This SQL Section Do?

The temporary view keeps the dataset inside the SQL file. The row-count query gives anyone reproducing the project an immediate setup check.

  • Select Preview above the file contents.

The preview should show the dataset definition followed by the row-count query.

Dataset Section Missing From the Preview?

Return to the file contents text box. Confirm that all 12 value rows appear before the row-count query.

Ask for help with checking the dataset section.

  • Return to the file contents text box.
  • Append the preview query beneath the row-count query by pasting this section:
-- Preview sales rows.
SELECT
  sale_id,
  product_name,
  store_location,
  quantity,
  unit_price
FROM bakery_sales
ORDER BY sale_id
LIMIT 10;

What Does the Preview Section Add?

This query selects the five business columns used in the investigation. The ordered limit keeps the preview consistent across runs.

  • Select Preview.
  • Select Commit changes....
  • Enter a short commit message that describes the dataset and preview queries.
  • Select Commit changes.

The repository should now list bakery_sales_analysis.sql. Opening it should show the dataset followed by the preview query.

SQL File Was Not Created?

Confirm that the file name ends with .sql. Check that you completed both commit buttons.

Ask for help with creating the SQL file on GitHub.

  • Open bakery_sales_analysis.sql from the repository file list.
  • Select the file editor icon in the upper-right corner of the file view.
  • Append the Downtown transaction ranking by pasting this section beneath the preview query:
-- Rank individual Downtown transaction lines.
SELECT
  sale_id,
  product_name,
  quantity,
  unit_price,
  quantity * unit_price AS line_revenue
FROM bakery_sales
WHERE store_location = 'Downtown'
ORDER BY quantity * unit_price DESC;

What Does the Transaction Section Preserve?

This section records the row-level revenue calculation from the notebook. It also preserves the focused Downtown filter that revealed Croissant as the highest single transaction line.

  • Select Preview above the edited content.

The preview should show the Downtown query appended after the sales-row preview.

Downtown Query Replaced Earlier SQL?

Return to the file contents text box. Place the Downtown query after the existing preview query without removing the earlier sections.

Ask for help with restoring the SQL sections.

  • Return to the file contents text box.
  • Append the product summary beneath the Downtown query by pasting this section:
-- Summarize performance by product.
SELECT
  product_name,
  SUM(quantity) AS units_sold,
  SUM(quantity * unit_price) AS revenue,
  COUNT(*) AS transaction_lines
FROM bakery_sales
GROUP BY product_name
ORDER BY SUM(quantity * unit_price) DESC;

What Does the Product Section Preserve?

The grouped query captures the analysis that fixed the row-level limitation. Its three aggregate columns document units sold, revenue, and transaction-line count.

  • Select Preview.
  • Select Commit changes....
  • Enter a short commit message that describes the transaction and product analyses.
  • Select Commit changes.

The committed file should now contain the transaction ranking and product summary beneath the preview query.

Product Summary Missing After the Commit?

Open the latest version of bakery_sales_analysis.sql. Confirm that the product summary appears after the Downtown query.

Ask for help with checking the product summary commit.

  • Open bakery_sales_analysis.sql from the repository.
  • Select the file editor icon in the upper-right corner of the file view.
  • Append the location summary by pasting this final SQL section:
-- Summarize revenue by store location for the bar visualization.
SELECT
  store_location,
  SUM(quantity * unit_price) AS revenue
FROM bakery_sales
GROUP BY store_location
ORDER BY SUM(quantity * unit_price) DESC;

What Does the Final SQL Section Add?

The final query reproduces the result behind the saved bar visualization. Another person can run it to confirm the Riverside revenue finding.

  • Select Preview.
  • Select Commit changes....
  • Enter a short commit message that describes the location summary.
  • Select Commit changes.

Your public SQL file now contains the complete base investigation. The final query matches the result used for the location chart.

Location Summary Missing From GitHub?

Open the committed SQL file. Confirm that the store-location query appears after the product summary.

Ask for help with checking the final SQL commit.

✔️ Awesome, I've got everything!

Your committed SQL file contains the complete bakery investigation. Continue to document the business story in the README.

ⓧ I'd like to double check the full code

-- Create a reproducible, session-scoped dataset.
CREATE OR REPLACE TEMP VIEW bakery_sales
  (sale_id, product_name, store_location, quantity, unit_price) AS
VALUES
  (1,  'Chocolate Chip Cookie', 'Downtown',  4, 3.50),
  (2,  'Croissant',             'Downtown',  6, 4.00),
  (3,  'Blueberry Muffin',      'Downtown',  3, 4.50),
  (4,  'Sourdough Loaf',        'Downtown',  1, 8.00),
  (5,  'Chocolate Chip Cookie', 'Riverside', 3, 3.50),
  (6,  'Croissant',             'Riverside', 2, 4.00),
  (7,  'Blueberry Muffin',      'Riverside', 5, 4.50),
  (8,  'Sourdough Loaf',        'Riverside', 4, 8.00),
  (9,  'Chocolate Chip Cookie', 'Uptown',    5, 3.50),
  (10, 'Croissant',             'Uptown',    4, 4.00),
  (11, 'Blueberry Muffin',      'Uptown',    2, 4.50),
  (12, 'Sourdough Loaf',        'Uptown',    2, 8.00);

-- Verify the setup.
SELECT COUNT(*) AS row_count
FROM bakery_sales;

-- Preview sales rows.
SELECT
  sale_id,
  product_name,
  store_location,
  quantity,
  unit_price
FROM bakery_sales
ORDER BY sale_id
LIMIT 10;

-- Rank individual Downtown transaction lines.
SELECT
  sale_id,
  product_name,
  quantity,
  unit_price,
  quantity * unit_price AS line_revenue
FROM bakery_sales
WHERE store_location = 'Downtown'
ORDER BY quantity * unit_price DESC;

-- Summarize performance by product.
SELECT
  product_name,
  SUM(quantity) AS units_sold,
  SUM(quantity * unit_price) AS revenue,
  COUNT(*) AS transaction_lines
FROM bakery_sales
GROUP BY product_name
ORDER BY SUM(quantity * unit_price) DESC;

-- Summarize revenue by store location for the bar visualization.
SELECT
  store_location,
  SUM(quantity * unit_price) AS revenue
FROM bakery_sales
GROUP BY store_location
ORDER BY SUM(quantity * unit_price) DESC;
Document the investigation

SQL shows how you reached the results. A technical README explains why the analysis matters and how someone else can reproduce it.

  • Return to the repository file list.
  • Open README.md.
  • Select the file editor icon in the upper-right corner of the file view.
  • Replace the existing README contents with this objective and findings section:
# Databricks Bakery Sales Investigation

## Objective

Use Databricks SQL to turn bakery transaction lines into product and store performance insights.

## Business questions

- Which individual Downtown sale generated the most revenue?
- Which product generated the most revenue across all stores?
- Which store location generated the most revenue?

## Key findings

- The highest-revenue Downtown transaction line was a Croissant sale worth 24.00.
- Sourdough Loaf was the top product with 56.00 in total revenue.
- Riverside was the top store location with 73.00 in total revenue.

What Does This README Section Explain?

The objective introduces the business purpose. The questions and findings connect each SQL result to a decision a bakery manager could understand.

  • Select Preview above the edited content.

The preview should display a project title followed by the objective, three business questions, and three findings.

README Preview Shows the Old Text?

Return to the editor. Select all existing text before pasting the replacement section again.

Ask for help with replacing the README contents.

  • Return to the file contents text box.
  • Append the skills and reproduction section beneath the final key finding:
## SQL skills demonstrated

- Selecting and limiting columns and rows
- Creating calculated columns with aliases
- Filtering rows with `WHERE`
- Sorting results with `ORDER BY`
- Aggregating with `SUM` and `COUNT`
- Grouping business categories with `GROUP BY`
- Turning a grouped query into a Databricks bar visualization

## Reproduce the analysis

1. Create a SQL notebook in Databricks Free Edition.
2. Run the dataset setup statement in `bakery_sales_analysis.sql`.
3. Run each analysis query in its own notebook cell.
4. Build a Bar visualization from the store-location summary.

## Result

The project demonstrates the difference between ranking individual transaction lines and aggregating all rows to answer a business question.

What Does the Final README Section Add?

The skills list makes the SQL techniques explicit. The reproduction steps give another person a short path from the repository to the same results.

  • Select Preview.
  • Review the rendered headings and lists.
  • Select Commit changes....
  • Enter a short commit message that describes the completed project documentation.
  • Select Commit changes.

The repository homepage should now render the completed README beneath the file list. Visitors can understand the investigation before opening the SQL file.

README Formatting Looks Broken?

Confirm that each heading starts on its own line. Check that every list item begins with a hyphen or a number.

Ask for help with fixing the README formatting.

✔️ Awesome, I've got everything!

Your README documents the objective, findings, SQL skills, and reproduction steps. The public portfolio repository is complete.

ⓧ I'd like to double check the full code

# Databricks Bakery Sales Investigation

## Objective

Use Databricks SQL to turn bakery transaction lines into product and store performance insights.

## Business questions

- Which individual Downtown sale generated the most revenue?
- Which product generated the most revenue across all stores?
- Which store location generated the most revenue?

## Key findings

- The highest-revenue Downtown transaction line was a Croissant sale worth 24.00.
- Sourdough Loaf was the top product with 56.00 in total revenue.
- Riverside was the top store location with 73.00 in total revenue.

## SQL skills demonstrated

- Selecting and limiting columns and rows
- Creating calculated columns with aliases
- Filtering rows with `WHERE`
- Sorting results with `ORDER BY`
- Aggregating with `SUM` and `COUNT`
- Grouping business categories with `GROUP BY`
- Turning a grouped query into a Databricks bar visualization

## Reproduce the analysis

1. Create a SQL notebook in Databricks Free Edition.
2. Run the dataset setup statement in `bakery_sales_analysis.sql`.
3. Run each analysis query in its own notebook cell.
4. Build a Bar visualization from the store-location summary.

## Result

The project demonstrates the difference between ranking individual transaction lines and aggregating all rows to answer a business question.

Before the final check, which repository files and chart result do you expect to find?

  • Return to the main page of databricks-bakery-sales-analysis.
  • Check which two files appear in the repository file list.
  • Review the rendered README beneath the file list.
  • Switch back to the Bakery Sales Investigation notebook.
  • Check which store has the tallest bar in the saved visualization.

The public repository should display bakery_sales_analysis.sql and README.md. The Databricks bar visualization should show Riverside as the top location at 73.00.

That completes the investigation. Your notebook now communicates the location result visually while your public repository preserves the full analysis.

Secret mission

Filter the Product Summary

Filter the grouped product summary to products with at least 45.00 in total revenue. Publish the challenge query and explain why grouped results need a HAVING condition.

Clean Up Your Resources

Clean Up Your Resources

Your Databricks Free Edition notebook costs $0 to keep while your account remains available. Your public GitHub repository also costs $0 to keep.

Resources you used:

  • The Bakery Sales Investigation notebook.
  • The saved store-location Bar visualization inside the notebook.
  • The session-scoped bakery_sales temporary view with 12 rows.
  • The public databricks-bakery-sales-analysis repository.

Keep everything running

No action is needed. Choose this if you want to keep the investigation available for demonstrations or further analysis.

  • Keep the Bakery Sales Investigation notebook in your Databricks workspace.
  • Keep the public databricks-bakery-sales-analysis repository available on GitHub.
  • Rerun the dataset setup cell whenever a later session needs the bakery_sales view.

The notebook stays ready as your Databricks project evidence. The repository remains public for review.

Pause - I'll come back to this later

Step away by closing the browser tabs. Your saved notebook files remain available when you return.

  • Close the Databricks browser tab.
  • Close the GitHub browser tab.

Your notebook retains its saved Bar visualization. Your GitHub files remain in the public repository.

The bakery_sales view disappears when the current session ends. Rerunning the first notebook cell recreates its 12 rows.

Delete - I don't want to use this again

Deleting these resources is permanent. Keep either copy if you want a recoverable version of your work.

  • Return to the Bakery Sales Investigation notebook from earlier.
  • Locate Bakery Sales Investigation in the Databricks workspace navigation.
  • Open the notebook context menu.
  • Use the notebook deletion action to remove Bakery Sales Investigation.
  • Confirm that Bakery Sales Investigation no longer appears in the workspace navigation.

The saved Bar visualization is removed with the notebook. The bakery_sales view drops automatically when the current session ends.

  • Return to the public databricks-bakery-sales-analysis repository from earlier.
  • Use the repository settings page to reach its deletion controls.
  • Use the repository deletion control to remove databricks-bakery-sales-analysis.
  • Confirm that the public repository page no longer displays the project.

That clears the project completely. No project resource remains available after the current session ends.

Nice Work!

Nice Work!

You did it! Your Databricks SQL notebook now turns 12 bakery sales rows into product and location insights. Your public GitHub repository makes the investigation reproducible for other people.

You've learned how to:

  • Build a reproducible dataset containing 12 bakery sales lines. Inspect its business columns with a controlled LIMIT.
  • Expose the gap in transaction-level ranking with a calculated line_revenue. Resolve it with GROUP BY, SUM, and COUNT to identify Sourdough Loaf at 56.00.
  • Turn the store summary into a bar visualization that shows Riverside at 73.00. Publish the reproducible SQL and findings in a public GitHub repository.
  • Secret Mission: Filter grouped product results with HAVING so only products earning at least 45.00 remain. Explain how WHERE filters transaction rows before grouping while HAVING filters aggregated groups.

Ready to quiz yourself? Let's see what you remember.