Category: Decisions

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 Decisions Strategy Thoughtful Thoughts

House of Data: Data Professionals as Targarayens and their Dragons

“In the Realm of Data, we tame dragons — not dashboards.”

So… I swear I started this blog to share my data projects and build my portfolio. Somewhere along the way, I accidentally created an entire Targaryen-inspired data meme series instead. 😅

Because honestly? Data professionals are a little like Targaryens.


We’re passionate, fiery, and sometimes one bad join away from chaos. Our tools are our dragons — powerful, unpredictable, and capable of absolute brilliance or disaster, depending on how we use them.

So in true Mercury Musings fashion, meet the House of Data…

⚔️ House of Data: The Targaryens of Analytics

🩸 Rhaenyra Targaryen — The Data Analyst
Turns chaos into clarity, one query at a time.

🐍 Daemon Targaryen — The Data Engineer
Builds the pipelines that keep the realm alive.

☀️ Aegon II Targaryen — The KPI Executive
Rules by vanity metrics and victory charts.

🧠 Aemond Targaryen — The AI Strategist
Sees every move before it happens — and still plays to win.

🔮 Helena Targaryen — The Predictive Analyst
Sees patterns others can’t — the data whisperer of the realm.

👑 Viserys Targaryen — The Data Architect
Builds empires of tables and schemas that outlive kings.

💜 Rhaenys Targaryen — The Data Governance Lead
The queen who never was — but still led.

⚔️ Baela Targaryen — The Data Operations Manager
Keeps the data realm running — one project at a time.

If you were in the House of Data, which one would you be — the analyst, the engineer, the strategist, or the dragon?

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 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 Decisions Thoughts Tips

SQL Joins Demystified: Inner, Left, Right, and Outer

If you’ve ever worked with relational databases, you know that most data doesn’t live in a single table. That’s where JOINs come in. They let you connect data across multiple tables to create a complete story.

During my undergrad, I remember learning the different joins in one of my classes and I was just like:

But in this post, I’m going to break down the four most common JOIN types in a fun and easy way. If you’re an analyst and job skills mention SQL, these are essential to your success! But before I do, I want to cover Table Aliases.

table aliases

When you’re working with joins, table names can get long and repetitive. That’s where aliases come in.

WHAT’S AN ALIAS?

An alias is just a nickname for a table that makes your query shorter and easier to read.

For example, instead of writing:

SELECT customers.customer_id, customers.first_name, orders.order_id
FROM customers
JOIN orders
ON customers.customer_id = orders.customer_id;

Aliases become a game-changer and you can instead write:

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

Here, I’ve given customers the alias c and orders the alias o.

  • c stands for Customers
  • o stands for Orders

This way, the query is cleaner and it’s easier to see which table each column comes from.

✨TIPS

  • CONSISTENCY IS KEY: Always use the same alias convention so others can follow your queries.
  • KEEP IT INTUITIVE: Use short, obvious letters like c for customers, o for orders, p for products.
  • IMPROVES READABILITY: Especially helpful when you join 3+ tables.

Now, let’s get into the meat of this post!

1. inner join

the matchmaker.

USE CASE: Return only the rows that exist in BOTH tables.

CODE SNIPPET:

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

RESULTS: Only the customers who have placed orders. Anyone without an order gets excluded.

2. left join

EVERYTHING FROM THE LEFT

USE CASE: Keep all rows from the left table, and match data from the right if it exists.

CODE SNIPPET:

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

RESULTS: A list of every customer — even those who haven’t placed an order yet. Missing values from the right table will show as NULL.

3. right join

EVERYTHING FROM THE RIGHT

USE CASE: The mirror of LEFT JOIN. Keep all rows from the right table, and match data from the left if possible.

CODE SNIPPET:

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

RESULTS: You’ll see every order in the system — even if the customer record is missing (maybe due to data entry issues).

4. full outer join

THE UNION OF BOTH

USE CASE: Return all rows from both tables, with matches.

CODE SNIPPET:

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

RESULTS: This shows every customer and every order, whether or not they match. It’s the widest view — useful for finding gaps in data where possible.

Visual Summary

  • INNER JOIN: Only matches
  • LEFT JOIN: Everything from the left + matches
  • RIGHT JOIN: Everything from the right + matches
  • FULL OUTER JOIN: Everything from both sides

wrapping up

I hope you enjoyed this little lesson on SQL Joins!

Remember, JOINS are the glue of SQL. Mastering them will allow you to:
✅ Combine multiple datasets into one view
✅ Identify gaps and mismatches
✅ Build richer insights for business questions

Next time you’re writing a query, think: Do I need just the matches, or everything from one side (or both)?

That answer will guide which JOIN you use.

💡 CONFESSION TIME: I didn’t fully understand JOINs until I had to write complex queries in the real world. In my next post, I’ll share how JOINs finally “clicked” for me — and why it’s normal if they still feel confusing at first.

👉 In a future post, I’ll share how JOINs came together for me — and why it’s completely normal if you don’t feel 100% confident with them yet.

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.