Omiroro Ovikute

Problem

Meridian Retail (simulated retailer) had a known revenue discrepancy that the finance team needed to investigate. Nura Ibrahim, the stakeholder, asked me to connect Power BI Desktop to the Meridian PostgreSQL database and load all 8 required tables in Import mode before any visual work could begin.

What I did

Using minimal M code, I connected each table to the Neon PostgreSQL server by referencing the correct schema and item name within the source. Power BI auto-detected 9 relationships from the schema, and I confirmed each one reflected the correct grain: orders to customers, order items to orders and products, inventory to products and stores, and sessions to both orders and customers. The sessions-to-customers relationship was left inactive to prevent ambiguous filter paths, since sessions already connects to customers through orders.

Outcome

Nura had a fully connected data model ready for Power Query transformation and visual development, with no missing tables and no broken relationships.

let
 Source = PostgreSQL.Database("ep-frosty-glade-ab4k8hyw-pooler.eu-west-2.aws.neon.tech", "meridian_retail"),
 retail_categories = Source{[Schema="retail",Item="categories"]}[Data]
in
 retail_categories

This M code pattern, repeated for each of the 8 tables, connects to the correct server and database and pulls one schema-qualified table into Import mode.

Next step

A useful next check would be to verify row counts for each table against the source database, to confirm that Import mode captured the full dataset and not a truncated preview.

Problem

Meridian Retail (simulated retailer) stored all order item prices in kobo, which made the raw columns unusable for revenue and margin reporting. Nura Ibrahim asked me to convert unit_price_cents, discount_cents, and line_total_cents to naira in Power Query and rename them to match the naming convention the team would use going forward.

What I did

For each of the three columns, I applied Table.TransformColumns to divide the cent value by 100, then chained a Table.RenameColumns step to give each column its naira-denominated name. Separating the division and renaming into two sequential steps kept the M code readable and made each transformation explicit. The resulting column names, Unit Price (NGN), Discount (NGN), and Line Total (NGN), confirmed the transformations were live in the loaded model.

Outcome

Downstream calculations and visuals could reference naira-denominated columns directly, removing the risk of anyone accidentally summing raw cent values in a report.

Next step

It would be worth checking whether the converted Line Total (NGN) values reconcile with Unit Price (NGN) minus Discount (NGN) for a sample of rows, to surface any rows where the source calculation was inconsistent.

Problem

Nura Ibrahim at Meridian Retail (simulated retailer) needed a visual she could show the Finance team to explain an October 2023 revenue gap. The specific question was how total revenue split across order statuses for that month, with all statuses visible and values readable without interaction.

What I did

The date filter used an advanced filter on created_at set to on or after 1 October 2023 and before 1 November 2023, which produces a precise calendar-month boundary rather than relying on a relative date that could shift. All 7 known order statuses appeared on the Y-axis. Sorting the chart by bar length descending made the status hierarchy immediately clear, and turning data labels on meant Nura could read exact values without hovering, which matters when presenting to a finance audience.

Outcome

The Finance team received a single, clearly labelled chart showing exactly where October revenue was sitting across all statuses, with no ambiguity about the date range applied.

Next step

A useful follow-on would be to compare the cancelled and returned share across multiple months, to determine whether October's pattern was typical or an outlier worth investigating further.

Problem

Before a customer dashboard could be built for Chidi Okafor at Meridian Retail (simulated retailer), the customers table needed cleaning. Known duplicate records were present, and three calculated columns were required: a full name field, an acquisition year, and a customer tier based on order count.

What I did

Duplicate removal used Table.Distinct keyed on customer_id, which eliminates rows sharing the same identifier regardless of flag column values. The Full Name column concatenated first_name and last_name with a space separator, and a rename step corrected the capitalisation to match the required output. Acquisition Year was derived by first converting created_at to a date type, then applying Date.Year to ensure the function received the correct input type. The Customer Tier conditional column used thresholds of 1 or fewer orders for New, 2 through 9 for Regular, and 10 or more for Loyal, matching the brief exactly.

Outcome

Chidi's dashboard build could start from a deduplicated, enriched customer dimension, removing the inflation risk that duplicate records would have introduced into any customer-count or segment metric.

Table.Distinct(retail_customers, {"customer_id"})

This step removes rows where customer_id repeats, keeping one record per unique customer and preventing duplicate rows from inflating downstream counts.

Next step

It would be worth comparing the row count removed by Table.Distinct against the count of records where is_duplicate equals true, to confirm the two approaches produce the same result on this dataset.

Problem

Meridian Retail (simulated retailer) stored order totals in kobo and included a datetime field with a time component that the analysis did not need. Nura Ibrahim asked me to divide total_cents by 100, rename it to a naira-labelled column, and convert created_at to a date type in Power Query.

What I did

The M code applied Table.TransformColumns to divide total_cents by 100, then Table.RenameColumns to apply the new column name, and finally Table.TransformColumnTypes to change created_at from datetime to date. Sequencing the steps in this order meant each step referenced the output of the previous one by name, keeping the query chain intact. The updated_at column was also removed in the same query, trimming a field that added no analytical value and keeping the model lean.

Outcome

Nura had a clean orders table ready for date-based filtering and revenue aggregation, with no cent-to-naira conversion needed at the report layer.

Next step

Checking whether the renamed column name aligns exactly with the convention used in order_items would ensure joins and measures referencing both tables do not silently pick up the wrong field.