Project 1 — The Messy Inheritance

Format. Three weeks, solo. Submit P1_LastFirst.pbix plus a one-page data log (a page in any format listing every defect you found and what you did about it). Worth 10% of the course. Graded on the model, not visuals — Module 3 is where pages get pretty; this project proves the machine underneath.

Scenario

Juniper Junction, a five-store garden-center chain, has never had an analyst. You inherit their entire data estate as it actually exists: three quarterly sales exports someone saved from the register system, a product lookup re-exported by a manager ("might have glitched, not sure"), a member list maintained by hand since 2022, and finance's budget grid. Nobody can tell you what is wrong with these files. That is the project.

The estate

File	What it claims to be
`sales_Q1_2026.csv` · `Q2` · `Q3`	Register tickets, one row per line item
`product_lookup.csv`	The SKU catalog with categories, costs, prices
`members.csv`	The loyalty-member list
`budget_2026.csv`	Store × month revenue budget, January–September
`stores.csv`	The five stores (this one is actually clean)

Deliverables

One combined sales fact named Sales 2026 covering all three quarters — with a single, correctly-typed Quantity column. (Look at Q3's headers before you append. Look carefully.)
Clean dimensions: products (the lookup has a re-export problem — profile the key before you merge or relate anything), members (hand-maintained files have hand-maintained diseases; find them all), stores as-is.
The budget unpivoted to a tall Store × Month × Budget table and joined to the model — which means your model needs a date spine. Build one.
A star: sales and budget as facts, products / members / stores / dates as dimensions, every relationship many-to-one and single-direction, no fact-to-fact lines.
Four measures (exact names): Total Revenue (quantity × unit price — check: $2,057,284.88 for Jan–Sep), Ticket Count (distinct: 10,193), Budget, and Budget Attainment % (DIVIDE, measure references).
The data log: every defect, its evidence (the count that exposed it), and the fix. The known defects have exact counts — your log should have exact counts too.

Scoring (100 points)

Component	Points
Sales fact: 10,193 rows, one Quantity column, correct types, all quarters present	20
Products: duplicate keys found and removed (row count proves it); members deduped and trimmed; dates parsed	20
Budget: unpivoted to 45 rows, typed, joined through the date spine	15
Star: correct relationships, no many-to-many accepted anywhere	15
Measures: names and verified values	15
Data log: complete, evidenced, professional	15

One number to fear If your sales fact has more than 10,193 rows after the product merge — or your revenue exceeds $2,057,284.88 — you accepted the multiplying merge. You know the ten-second check that would have caught it. The rubric knows it too.

On the data log The log is where this project stops being an exercise. "Removed duplicates" is a claim; "product_lookup.csv contained 48 rows but 45 distinct SKUs — three re-exported duplicates removed before relating, verified 45=45" is evidence. Write the log you would want to inherit.