Tag: women-in-tech

Categories
Analysis Analytics Business Decisions

The King’s Pantry — Where Business & Westeros Converge

🌾 Full Circle

It’s funny how things come full circle. Back in undergrad, Database Design and Modeling was one of my favorite classes — I loved the logic, the structure, and the creativity behind building relationships between tables. I didn’t realize then that I’d be revisiting those same concepts years later, this time through the lens of a working analyst.

Now, projects like The King’s Pantry let me bring that passion back to life, combining the fundamentals I first learned in the classroom with everything I’ve experienced in real-world ERP systems. It’s proof that even as our careers evolve, the subjects we once loved have a way of finding us again — just in more meaningful, applied ways.

Meet The King’s Pantry

A few weeks ago, I started building something new — a dataset inspired by the Game of Thrones universe, but modeled after real ERP systems I’ve worked with in retail and distribution.

Meet The King’s Pantry, a grocery market fit for the realm.

It’s more than a themed dataset, it’s a teaching tool designed to help analysts learn how to connect sales, products, vendors, and customers the way real business systems do.

the schema: where business logic meets design

Every dataset needs a solid foundation, and The King’s Pantry was designed with a structure that mirrors a real ERP system: simple enough for analysts to explore, yet realistic enough to teach key data relationships.

At its core, the schema includes five main tables that represent how business flows through the kingdom:

  • Customer — Holds details about every buyer in the realm, from noble households to local merchants. Includes hierarchy fields that let you practice self-joins and account roll-ups.
  • Vendor — Represents the suppliers (or noble houses) who provide goods to The King’s Pantry. Each vendor links to multiple products and includes a preferred vendor flag for analysis.
  • Product — The heart of the operation. This table lists every item sold in the market (from fresh produce to imported sweets along with category taxonomy, pricing, and cost details).
  • Sales Orders — Records transactions placed by customers. Each order includes details like customer ID, order date, payment method, and status, a perfect table for learning joins and date-based analysis.
  • Sales Order Details — Breaks each order down into individual line items. This is where quantities, pricing, and margins live, allowing for analysis at the most granular level.

Together, these tables create a relational map that connects vendors → products → sales → customers, forming the foundation for everything from category dashboards to SQL query practice.

Coming This saturday: Power BI Tutorial

The first tutorial will walk through category and sales insights using The King’s Pantry dataset, designed in the same storytelling style as my Daily Grind Coffee dashboard.

We’ll build visualizations that mirror real-world category management dashboards while keeping the aesthetic of a Westerosi market.

Coming next Monday: SQL Tutorial

Next, I’ll release a SQL tutorial with hands-on exercises based on queries I actually used in my analyst roles (from calculating margins to joining vendor data through products and sales orders).

This will show how technical SQL joins and calculation translate into the insights that Power BI visualizes, connecting backend logic to business storytelling.

Why I Built This Project

I wanted to bridge the gap between creativity and real-world analytics, showing that learning SQL, database design, and data modeling doesn’t have to be dry.

By re-imagining ERP systems through a fantasy lens, I’m creating a way for analysts to practice with data that feels approachable, fun, and still grounded in real business logic.

Sneak Peek: The Next Launch

This first release focuses on the external stakeholders of the realm — customers, vendors, and marketplace sales.

In the next phase of The King’s Pantry, we’ll turn the focus inward — toward the internal stakeholders who keep the kingdom running.

That means expanding the dataset to include purchase orders, purchase order details, buylines, buyline branches, and more, reflecting how businesses manage inventory, procurement, and supply chain performance behind the scenes.

It’ll be a deeper dive into the full ERP cycle (from purchase to sale) and I can’t wait to build it piece by piece.

A Little Poetic, Isn’t It?

When I started my blog and LinkedIn, it was mainly to build a professional portfolio and presence. But somewhere along the way, it evolved into something I genuinely love — a space to create projects, resources, and tutorials to help others do the same.

I took the advice to “build a project to stand out to recruiters”… and ended up building a project to help others build their own.

Project inception? Maybe.

The Realm Awaits

Stay tuned — the first Power BI tutorial drops this Friday, followed by the SQL tutorial on Monday.


Because even in Westeros… data reigns supreme.

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Business

ETL vs ELT: Why Knowing the Difference Still Matters

The Acronym That’s Everywhere

When I first learned about ETL (Extract, Transform, Load) during my undergrad (2017–2019), it felt like the golden rule of data movement.

Fast forward to my master’s program (2023–present), and suddenly… it’s ELT. Same letters, different order, but a completely new approach to data processing.

So, what changed?

FROM ETL TO ELT

ETL ruled the traditional data warehouse world — where storage was expensive and processing power was limited.
Transformation had to happen before data was loaded into the warehouse.

But as cloud storage (like Snowflake, BigQuery, and Azure Synapse) became faster and cheaper, the paradigm flipped.
Now, data gets loaded first, then transformed inside the warehouse itself. Hence: ELT.

Why This Still Matters — Even as ETL “Fades Out

It’s tempting to think ETL is outdated, but it’s not gone, just evolving.

Many companies today still rely on legacy systems or are in the middle of migrating to cloud environments. Others are merging with businesses already using ELT.

As an analyst, you might encounter:

  • Nightly ETL batch jobs in SSIS
  • Hybrid pipelines with external transformations
  • Full ELT stacks using dbt + Snowflake

Understanding both gives you a real-world edge. You’ll walk into a job ready to troubleshoot data flows, explain performance issues, or even guide migrations, not just run queries.

In one of my data analyst roles, I experienced this firsthand. LinkedIn is full of seasoned analysts offering advice about “what it’s really like” out there, but most of those conversations center around big tech companies, where systems are already deep into the ELT phase.

The reality?

Not everyone works in — or even wants to work in — big tech.
Many analysts thrive in industries that keep the world running:
🏥 Hospitals
🏦 Financial institutions
🎓 Higher education
🏪 Everyday businesses and distributors

And here’s the truth no one talks about:

Many of these organizations still rely on ETL, where nightly batch jobs quietly run behind the scenes to keep operations moving.

Some are just beginning to make the shift toward cloud-based storage, balancing modernization with legacy systems that have been around for decades.

✨ That’s why knowing both ETL and ELT isn’t just a technical advantage — it’s a career advantage. It allows you to step confidently into any environment — whether it’s a cutting-edge cloud setup or a legacy warehouse that still hums at midnight.

And personally, this where I thrive and feel I make the most impact. This is why I started this blog, as a resource for junior analysts stepping into the real world — because this kind of guidance is what I wish I had years ago.

Why Foundational Knowledge Sets You Apart

When you look at job descriptions, what do you see?
Azure. Snowflake. ERP. DBT.

These aren’t just buzzwords — they’re clues. They reveal the data ecosystem that drives a company’s analytics workflow.

Most analysts focus on the tools (SQL, Python, Power BI), but it’s the foundation that makes you stand out. Knowing how and where data is stored, structured, and transformed separates someone who writes queries from someone who designs solutions.

FINAL THOUGHTS

Whether it’s ETL or ELT, what matters most is understanding how data moves — and why that matters.

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Business Decisions Growth Innovation Lifestyle Reflection Reflections Thoughts Tips

Wardrobe Optimization 101: The Closet That Felt Like a Database

There’s something oddly humbling about standing in front of a packed closet and realizing you still have “nothing to wear.”

As I stared at the rows of shirts, dresses, and jeans (some I hadn’t worn in years) I couldn’t help but draw data parallels to my closet… which was its own dataset. Messy, redundant, and full of null values.

So, I decided to treat it like a data problem.

If I can clean, model, and transform millions of rows of data — surely I could handle a hundred hangers.

STEP 1: EXTRACT – PULL OUT THE PIECES THAT MATTER

In data, extraction means pulling from a messy source and capturing what’s worth analyzing.

In closets, it means facing the pile and being brutally honest with yourself… and your consumption problems 🥲

I pulled everything out: clothes, shoes, purses, even those “just in case” items that hadn’t seen daylight in years.

This was my data extraction phase, full transparency.

As I started sorting, I noticed a pattern.

The pieces that truly stayed with me weren’t the trend-driven ones I’d bought on impulse — they were the classics. The high-quality basics I’d invested in over the years: the crisp white button-up shirt, the houndstooth work pants , the heavy grey cardigan. Many of my favorite pieces from Everlane and Zara.

It reminded me of the difference between fast data and clean data.

Fast fashion can be tempting, just like downloading flashy datasets for quick results but in the long run, it’s always the timeless pieces that hold their value.

ELT QUERY

SELECT * FROM closet WHERE joy = TRUE AND quality = ‘timeless’;

Step 2: Load — Stage Your Data (and Your Rack)

Once I’d extracted my favorite pieces, I loaded them onto a single clothing rack — my staging table. I went on Amazon the day before and bought one for $30 and telling myself: everything you choose has to fit on here. Instead of putting everything back in my closet, I needed to force myself to part ways with pieces I haven’t touched in so long and free up space that I could use for other storage like my yarn collection – ha.

Just like loading data into a staging environment, this step helped me visualize patterns and relationships.

I began noticing color palettes (my “columns”), favorite fits (my “key values”), and duplicates (“Do I really need three beige bottoms?”).

The rack became my mini data warehouse.

Step 3: Transform — Preparing for the Next Phase

In data, transformation is where separate tables come together through joins to create new meaning.

In fashion, the same principle applies. My base outfit, a classic striped button-up and wide-leg denim is like my primary table.

From there, I layered on new pieces: a denim vest, a paisley patterned jacket, a gingham coat. Styling instead of just “wearing”. Each addition felt like a join, combining two clean, distinct datasets to create a new, more insightful result.

🧮 A left join: keeping the core outfit, adding a jacket that changes the tone.

✳️ An inner join: when the base and layer perfectly align, polished yet effortless.

🧤 A cross join: when pattern meets pattern, bold, unexpected, but still connected.

Every transformation kept the base intact — proof that when your foundation is strong, creativity has infinite combinations.

Step 4: Optimize — Maintain and Measure

A capsule wardrobe isn’t just a one-time cleanup. It’s database maintenance.

I’ve learned it’s important to:

• Revisit each season (scheduled refresh).

• Add only what complements what I already own (controlled data inputs).

• Retire pieces that no longer align with my lifestyle (data depreciation).

And just like a well-designed data model, it’s made my life more efficient.

Capsule Wardrobe: The Loaded Dataset

(Every ETL project needs a final dataset — this one just happens to hang on a clothing rack.)

After the extract phase, here’s what officially made it into my Fall/Winter 2025 Capsule Wardrobe — the timeless pieces I’ve collected, loved, and worn through the years. Each one feels intentional, classic, and true to my style.

The Final Pieces

Tops & Layers

  • 6 button-ups
  • 6 tops
  • 2 polos
  • 3 sweaters
  • 1 cardigan
  • 2 jackets

The “primary keys” — the foundation of every future outfit join.

Bottoms

  • 4 skirts
  • 4 pants
  • 4 pairs of denim

Most are neutral, but the occasional statement color (hello, red skirt) keeps things interesting.

Dresses

  • 3 classic dresses
  • 2 tunic shirt dresses

Functionality > Flash: These are versatile, comfortable, and can easily move from casual to polished.

Footwear

  • 2 pairs of boots
  • 3 pairs of clogs (yes… I love clogs)
  • 1 pair of flats
  • 1 pair of sneakers

Balanced Load: Equal parts practicality and personality — because good footwear is basically good indexing.

Color Story: Classic Meets Creative

As I stepped back and looked at my final capsule, the color story felt like a reflection of me — grounded yet expressive. The foundation is built on soft neutrals: beige, cream, tan, and black — the kind of timeless tones that quietly do the heavy lifting, much like clean, reliable data. But then there are the pops of red and green, my visual outliers that make the dataset interesting. They’re bold, unapologetic, and full of life.

The mix of patterns — from paisley to gingham to classic stripes and leopard — adds just the right level of texture and personality. Together, it’s the perfect balance between classic and fun, a wardrobe that feels both analytical and artistic.

wrapping up

What surprised me most wasn’t how many clothes I had but how freeing it felt to simplify.

Decluttering my closet mirrored the process of decluttering my life, my workspace, and even my creative energy.

When we clear out what’s no longer serving us, whether it’s old data, cluttered dashboards, or unworn clothes, we make room for clarity.

For intention.

For transformation.

Because sometimes, the best insights don’t come from adding more, they come from refining what’s already there.

And yet, there’s one category I refuse to normalize or declutter, my handbags and purses.

They’re my beautiful exceptions to the rule and my little “data anomalies.” Each one carries a story, a moment, or a milestone.

If the rest of my closet is a clean, optimized dataset, my handbag collection is the carefully preserved archive, the one I’ll never delete.

But let’s be real… I’m probably gonna fail hard at this capsule thing because it’s too hard when you love pretty things 😭

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Business Mindfulness Notes Personality Psychology

SQL Joins… But Make Them Tarot

SQL joins are usually explained with Venn diagrams, charts, or code snippets. And then I had this pretty cool idea.

Because guess what… analysts have fun too and data doesn’t have to be boring *wink-wink*. So —

What if we gave sql joins mystical archetypes instead?

I designed a tarot-inspired deck where each join type becomes a card — complete with symbols, archetypes, and short fortunes.

I included all join types (Inner, Left, Right, Outer, Cross, Self, Natural, Semi, and Anti) to make the set feel more complete, even if most people only cover the most common ones.

DISCLAIMER 🔮

Not every database system supports all join types the same way. Think of them like tarot archetypes: some are the classic cards you’ll always pull, some are special but still standard, and a few are rare but powerful when you know them.

The Core 4 (the joins everyone learns first):

  • INNER JOIN
  • LEFT JOIN (LEFT OUTER)
  • RIGHT JOIN (RIGHT OUTER)
  • FULL OUTER JOIN
    These are the backbone of SQL joins — standard across SQL Server, MySQL, PostgreSQL, Oracle, and almost every tutorial or bootcamp.

Standard but less commonly used:

  • CROSS JOIN – Supported everywhere, but less commonly taught because it returns every possible pairing (which can blow up row counts fast).
  • SELF JOIN – Also standard, but often taught later. It’s just a table joining to itself, like looking in a mirror.

Natural Join (The Magician):

  • Supported in Oracle, PostgreSQL, and MySQL, but not SQL Server (SSMS).
  • It auto-matches columns with the same name — which feels magical ✨ but can be dangerous in production since it might pull in new columns you didn’t expect. That’s why it’s rarely used or covered in tutorials.

The “Rare Cards” (not always explicit keywords):

  • SEMI JOIN and ANTI JOIN
    • In PostgreSQL and Oracle, they exist as recognized operations.
    • In SQL Server and MySQL, they’re simulated with subqueries (EXISTS / NOT EXISTS or IN / NOT IN).

Why I included them all:
Most people only ever see the “core 4” (and maybe cross join). But including Self, Natural, Semi, and Anti shows the full spread of how SQL handles matches and non-matches. That’s why my Tarot deck has 9 archetypes instead of 4 or 5.

Are you ready?

The SQL Tarot Deck

  • Does the Matchmaker speak to you — are you drawn to perfect harmony?
  • Do you feel like the Caretaker — giving even when nothing comes back?
  • Are you the Ally today — steadfast, joining where you can?
  • Does the World call to you — a place where everyone belongs?
  • Are you in a Trickster mood — craving endless possibilities and a little chaos?
  • Do you feel like the Reflection — turning inward to uncover hidden patterns?
  • Is the Magician with you — where connections happen like magic?
  • Does the Hermit resonate — choosing solitude and independence?
  • Are you guided by the Seer — glimpsing just enough to know what’s there?

inner join – the matchmaker

Only rows that match on both sides are kept. Harmony, balance, and true pairs.

Left Join – The Caretaker

All rows from the left remain, even if the right gives nothing back. Loyalty and nurture.

right join – the ally

All rows from the right remain, with the left joining where it can. Steadfast support.

full outer join – the world

All rows from both tables are included. Matches and loners alike find a place in the whole.

cross join – the trickster

Every row pairs with every other. Endless possibilities, but beware of chaos.

SELF JOIN – THE MIRROR

A table reflects on itself, revealing hidden patterns within.

natural join – the magician

Automatically connects matching columns — a shortcut that feels like magic.

ANTI JOIN – THE HERMIT

Only rows without matches are shown. Solitude and independence define this path.

SEMI JOIN – THE SEER

Rows are revealed if they exist in another set, but details remain veiled.

pretty cool right?

WHAT’S NEXT

It doesn’t end here, my fellow analysts.

COMING NEXT

  • A full overview of all the joins and their syntax using Tarot inspired tables.
  • Which SQL Join Are You? — an interactive quiz to reveal your archetype.

AND AFTER THAT…

  • Tarot Reader in Python (with ASCII art cards)

So tell me… which SQL Tarot card speaks to you?

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Reflection Strategy

Why Croissants Are King: A Market Basket Analysis

Last week I wrapped up a small but insightful Market Basket Analysis project.

Working off of the bigger Coffee Sales Dashboard project I completed (see here), I decided to explore a bit more and do some data science *tings*.

My goal was to explore how products are frequently purchased together and uncover patterns that could inform cross-selling strategies or promotions.

At first, I kept running into issues with the Apriori algorithm. No matter how I tuned it, the model kept failing to generate meaningful rules. I was just like:

If you haven’t gone through the bang-your-head-on-the-desk rite of passage working in analytics or coding, then you need to share your superpower with world.

As the saying goes:

“80% of the job is debugging and cleaning data. The other 20% is explaining why it took 80% of the time.”

After digging deeper, I realized the problem: in the dataset, each transaction only had one item! It’s always the simplest thing that is often the problem, amirite?

Without multiple items per basket, there were no associations to discover and this proved to be a great learning moment. I went back, rebuilt the dataset so that baskets could contain multiple items, and reran the analysis.

Instead of scrapping the project, I realized it’s perfectly fine (and actually really useful) to simulate data. If you’ve never created a dataset before, fear not. I have a tutorial in mind for that!

By redesigning the dataset so baskets could include multiple items, I was able to validate the workflow, uncover meaningful associations (hello coffee + croissant), and learn just as much from the setup as from the results.

TAKEAWAY: It’s okay if the data isn’t “real.” Simulation is a powerful way to practice, experiment, and build intuition—especially when you’re learning or building portfolio projects.

If you’re interested in the technical nitty-gritty, check out my GitHub [HERE] where I have all the code and documentation for this mini-project.

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Business Decisions Reflection

Behind the Beans: The Process of Visualizing Coffee Sales

are you team starbucks or team dutch bros?

Either way, coffee isn’t just this magical concoction that many of us love and *ahem* can’t live without — it’s also a dataset waiting to be explored. For my latest project, I built a Coffee Shop Dashboard to dig into customer habits, product sales, and time-based trends.

At first, I planned to keep it simple: load a flat file I found on Kaggle and throw some visuals on a page using Power BI. But the deeper I got, the more I realized this was the perfect chance to practice building a proper data model. What started as a “quick dashboard” turned into a full star schema project. And honestly? That decision made all the difference.

So grab yourself a cuppa joe and as we sip *pinkies out*, I’ll quickly walk you through this project.

my process (with a twist)

1. Data Prep

I used a fictional dataset that came from Kaggle (link here) featuring a coffee shop called Daily Grind Coffee. When I first skimmed the columns, it had everything that I was looking for — a realistic transactional dataset similar to the ones I’ve worked with in the real world. But once I started building from the flat file, new ideas started firing in my head, and I realized I could show even more with the data than I originally planned.

2. From Flat File to Schema

Originally, I was going to connect the flat file directly into Power BI. Instead, I built out a star schema — one fact table (orders) connected to dimension tables (customers, products, dates). Knowing how to build a proper data model is essential for data analysts. A clean schema doesn’t just make dashboards easier to maintain — it makes analysis:

  • Scalable: Add new data without breaking your model.
  • Flexible: DAX measures are simpler and more powerful.
  • Efficient: Queries run faster and avoid messy workarounds.

Having this background is a huge advantage, and it makes me grateful for everything I learned in my database courses in my undergrad. Not every business analyst has formal training in data modeling — many focus on tools and reports without understanding the structure underneath. But knowing the foundation of databases changes the way you think about business questions. You stop just visualizing numbers and start structuring the data so every future question is easier (and faster) to answer.

3. Measures & Metrics

I created DAX measures like average order value, customer retention rate, retained customers, etc.

For example, see the graph below.

This shows the trend of customer retention rate this year. The highest retention rate was in March at 29.91%, which dipped in April and May. Which leads us to asking questions like:

  • Did customer retention rate drop due to the warmer climate?
  • What items were these customers buying (iced vs hot drinks)?
  • What strategies can we take to keep customers buying in April and May? Promotions? Campaigns?

4. design

I kept the dashboard clean and minimal, with aligned visuals, consistent fonts, and filters for exploration.

insights that jumped out

  • Croissants and muffins were the surprise stars.
  • Customers split into two groups: daily cappuccino loyalists vs weekly tea drinkers.
  • Weekends had a completely different sales rhythm than weekdays.

This reminded me that dashboards aren’t just for reporting KPIs — they spark questions you wouldn’t have thought to ask otherwise.

what i learned

  • A good schema pays off. That extra effort upfront gave me flexibility and saved time.
  • Measures > calculated columns. Cleaner, leaner, and easier to maintain.
  • Design is analysis. Layout, spacing, and color choices shape how insights are understood.

💡 CONFESSION TIME:
I’ll admit it — I’m way more comfortable with calculated columns than measures. They feel familiar and straightforward, while DAX has been a tougher learning curve for me. Honestly, I’m still figuring it out.

But that’s part of why I write these reflections. My audience isn’t a room full of experts — to be honest, I’m writing for other analysts like me, all in different parts of their journey in data analytics. And sometimes the most helpful thing isn’t pretending you know everything, but being transparent about where you’re growing.

I’ve learned that while calculated columns get the job done, measures are worth the effort — they make dashboards cleaner, leaner, and much easier to maintain in the long run.

next steps

I’d love to add:

  • Customer Segmentation (Daily vs Weekly Buyers).
  • Forecasting so the dashboard can move from reporting the past to predicting the future.

Curious about the full project or want the technical nitty-gritty? You can check out the dataset, Power BI file, and documentation on my GitHub repo.

wrapping up: dashboard screenshots

☕ This dashboard gave me a great starting point, but it also got me wondering: what products do customers actually buy together? That’s where market basket analysis comes in. Stay tuned for my next post where I dig into those patterns.

And don’t worry, I won’t end this post without showing you what the dashboards look like!

Voila – a Coffee Sales Dashboard from a Virgo Mind.

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Business Tips

5 SQL Queries Every Analyst Should Know

SQL is one of the most important tools in any analyst’s toolkit. Whether you’re pulling transactional sales data, cleaning messy records, or preparing insights for dashboards, SQL is often the very first step.

If you’re just getting started, here are the five SQL queries that will cover 80% of your daily work as an analyst.

Manual effort?

Nah, let’s automate these data management tasks!

SELECT

The Foundation

This is your bread and butter: pulling data from a table.

Think of SELECT as your “give me the data” query. It’s the most basic — and the most powerful — command in SQL.

CODE SNIPPET:

SELECT customer_id, first_name, last_name, email
FROM customers;

WHERE

Filtering Results

Analysts rarely want all the data. WHERE lets you focus on what matters.

CODE SNIPPET:

SELECT *
FROM orders
WHERE order_date >= ‘2025-01-01’
AND status = ‘Shipped’;

For example, the query above pulls only shipped orders after January 1, 2025. Trust me, this is especially important when you’re working with millions of records that go back years. You do not want to be poring over a list that seems infinite and neither does the recipient who may have requested the ad-hoc report from you.

WHERE can be used to filter by categories or conditions as well.

GROUP BY

Summarizing Data

Aggregation is where insights begin. GROUP BY helps you summarize large datasets.

CODE SNIPPET:

SELECT product_id, COUNT(*) AS total_orders
FROM orders
GROUP BY product_id;

Now you can see which products have the most orders. Perfect for identifying bestsellers or analyzing trends.

JOIN

Combining Tables

Most real-world data lives in multiple tables. JOIN lets you stitch it together.

CODE SNIPPET:

SELECT c.customer_id, c.first_name, o.order_id, o.order_date
FROM customers AS c
JOIN orders AS o
ON c.customer_id = o.customer_id;

This connects customer details with their order history. Almost every analytics project requires joins at some point.

JOIN is often the most confusing query that beginners come across since there are different types. It can get confusing but don’t let that intimidate you, I’ll cover the different types of joins in a separate post 🙂

CASE

Adding Logic to Queries

Sometimes you need to create quick categories without exporting to Excel or Python. That’s where CASE comes in.

CODE SNIPPET:

SELECT order_id, total_amount,
CASE WHEN total_amount > 500 THEN ‘High Value’
ELSE ‘Standard’
END AS order_type
FROM orders;

This example creates a new column that classifies orders as “High Value” or “Standard.”

WRAPPING UP

These five SQL queries are the building blocks of data analysis. Master them, and you’ll unlock the ability to:

  • Extract exactly the data you need
  • Summarize and explore patterns
  • Connect multiple sources together
  • Add quick insights directly in SQL

Once you’re comfortable with these basics, you’ll be ready for more advanced techniques like CTEs, window functions, and query optimization.

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.

Categories
Analysis Analytics Growth Notes Thoughtful Thoughts

Why Mercury Musings?

Mercury rules Virgo, and as a Virgo, I’ve always been detail-oriented, analytical, and curious about how things connect. If you asked me ten years ago that my career would revolve around data and analytics, I wouldn’t have believed you. I was a pre-nursing major in college and that first year, I realized the medical field wasn’t for me. By sophomore year, I was lost trying to figure out a new major to switch to and I spent weeks trying to decide until I came across Information Management.

I know, soooooooooo interesting and cool right?!

Tbh, I don’t remember exactly how I discovered it but I remember part of my decision stemmed from taking a business class that all freshman students were required to take. It was an introductory course to using tools like Excel and PowerPoint. Out of all the classes I took my freshman year, that was the one I enjoyed the most.

It wasn’t until my senior year of my undergrad that I finally realized I was on the right path and doing something I enjoyed. Funnily enough, it wasn’t until a couple of years ago that I made the connection between my sun sign (Virgo) and the field I ended up in — ha ha ha. If you’re even a *little* into astrology, then you’d know that Virgo is ruled by Mercury.

Which leads me into the next part: my blog name.

the name: mercury musings

I’ve never been one for boring usernames or titles — I’ve lost count of all the moments in my academic career where I’d sit down to write an essay or report and I’d spend an absurd amount of time just trying to think of a title. If you’re a millennial who grew up watching SpongeBob, this is me just thinking of a title:

Any who, back to why I chose the name. I wanted something unique and creative that would play on both my personality and professional style:

Mercury = planet of communication, detail, and intellect

+

musings = casual reflections, notes, and insights.

Together, Mercury Musings reflects both my professional mindset and my personal curiosity: thoughtful, precise, and always seeking connections.

And if you’re a Sailor Moon fan, you can already guess which character speaks to me the most:

what you’ll find here.

Mercury Musings is a place where I’ll share:

Tips + Tutorials — breaking down concepts and techniques in data science and analytics.

Project Reflections — walking through real-world analyses, from dashboards to clustering models.

Insights — thoughts on decision-making, detail-oriented work, and the learning process.

My goal is to write in a way that’s approachable, useful, and a little personal — mixing the precision of analytics with the curiosity that Mercury inspires. And I probably won’t be able to help myself from throwing in a meme or two or many…

Fair Warning: You’ll probably even see me post about random non-data related things that I think are cool or stuff that I’m obsessed with like a new book, my favorite brand of yarn, my go-to purse, or my new favorite game •⩊•

looking ahead.

For now, this space is a blog — a place for me to write, reflect, and share. Over time, it will grow into a larger portfolio, with project showcases, teaching resources, and eventually research.

In other words, Mercury Musings is not just about where I am today, but where I’m headed. So —

welcome.

If you’re interested in analytics, detail-driven decision-making, or simply enjoy thoughtful yapping from a Virgo mind, I invite you to follow along.

Welcome to Mercury Musings.

Until next time,

Ardonna •ᴗ•

author’s note

Ardonna Cardines Avatar

Hi, I’m Ardonna Cardines — a data analyst and creator of Mercury Musings, where business meets imagination through data. I love blending analytics, design, and storytelling to make learning data modeling and visualization approachable — one creative dataset at a time.

If you’ve enjoyed this post, I’d love for you to follow along.
You can subscribe to my blog for new tips + tutorials, creative datasets, and behind-the-scenes projects — or connect with me on LinkedIn where I share updates and learning resources for analysts and data storytellers.