Data analyst solving business problems with SQL, Python, and reliable data. Nine years in food production — the last three and a half in industrial bakery manufacturing — then a B.Sc. in Business Administration and a 360-hour data analytics bootcamp. I read operational data as someone who has produced it.

Based in Mölln, Hamburg Metropolitan Region · open to relocation across Germany · authorised to work in Germany (§18a AufenthG).

I build analytics end to end: pull the raw data, validate it, model it in SQL, and put a dashboard on top that someone can plan production from. Both projects below are complete, reproducible from a clean clone, and have a public dashboard.

Seven years of official German grid data, and a CI gate that fails the build if any headline number drifts.

Repo · Live dashboard · Python SQL DuckDB Data Studio pytest GitHub Actions

• Pipeline over SMARD / Bundesnetzagentur data, 2019–2025: download → hourly fact table → day-ahead forecast table → reporting marts.
• Found the pressure point: residual-load minima fell from +2.5 GW in 2019 to −8.4 GW in 2025, and 2025 logged 202 hours where wind and solar alone out-produced total demand — against zero before 2023.
• Tied pressure to price by sorting every hour into residual-load deciles: median day-ahead price runs €4/MWh in the loosest decile against €110/MWh in the tightest, with the mean rising faster than the median — the expensive tail concentrates at the top.
• Reconciliation as a test, not a claim. CI checks the pipeline against official 2025 figures on every push: net generation 437.90 vs 437.6 TWh, day-ahead price €89.32 exact, 573 negative-price hours exact.
• Handled the time-series faults that quietly corrupt energy data: 15-minute → hourly aggregation by sum with no partial hours, DST-aware 23/25-hour days, and a stitched cross-border series across a 2021 source change.

232,679 real point-of-sale lines turned into production-planning guidance — including the finding that would have been wrong.

Repo · Live dashboard · Python SQL BigQuery DuckDB Data Studio

• Cleaned 234,005 raw rows into 232,679 analysable sales lines across 147 products (€562,717 revenue, Jan 2021 – Sep 2022): parsed European-format prices, rebuilt timestamps from split columns, removed returns and zero-price rows, documented every field.
• Caught a false conclusion before it reached a plan. Wednesday looked like the weakest trading day — until a check on open days per weekday showed the bakery closes most Wednesdays (62 trading days vs ~90 elsewhere). Re-basing on revenue per open day confirmed the real signal: a genuine July–August peak in both years.
• Volume leaders are not revenue leaders. The traditional baguette is roughly a third of units and a quarter of revenue, but sandwiches sell in far smaller numbers and still rank near the top on revenue. Planning from unit counts alone undervalues them.
• Found a data-integrity issue nobody had flagged: a €0.15 line item with zero price variation across 20,386 sales and 21 months, while every genuine product repriced twice. An ancillary fee, not a manufactured product — excluded from the production model.
• Built an MES-style star schema (products, machines, batches, downtime, quality) on a clearly separated synthetic layer that claims no findings, where the generator writes raw events only and yield, scrap cost and OEE derive in SQL — validated by assertions including OEE reconciling from Availability × Performance × Quality.

Cleaning is where the analysis actually happens — both projects above have a finding that only exists because a number looked wrong and I checked it. I'd rather ship two projects where every figure is traceable to SQL in the repo than five that look busy. And I say plainly which parts of a dataset I can draw conclusions from and which I can't.

Currently looking for a Junior Data Analyst role where I can turn complex data into reliable insights and help teams make better business decisions.

Email · LinkedIn English fluent · German B1, working toward B2 · Filipino native