Anuoluwa Olasunkanmi

Problem

Nura Ibrahim, a stakeholder at Meridian Retail (simulated retailer), needed a visual analysis of a revenue discrepancy. Before any report could be built, the full transactional database had to be loaded into Power BI, covering orders, customers, products, categories, stores, inventory, and sessions across 8 tables.

What I did

Using Import mode, I connected Power BI Desktop to the Meridian PostgreSQL server and navigated each table through the retail schema using M code. Power BI auto-detected 9 relationships, which I reviewed against the expected star-schema structure: order_items linking to orders, orders linking to customers and stores, and products linking to categories. The sessions table presented an ambiguity, it linked to both customers and orders, so I set the sessions-to-orders relationship as inactive to avoid conflicting filter paths. The file was saved in PBIP format as instructed.

Outcome

Nura had a fully connected data model ready for revenue visuals, with no broken relationships and no ambiguous filter paths that could distort aggregations.

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

This M code connects to the Meridian PostgreSQL database and navigates to the retail schema to load the orders table, the same pattern was applied to all 8 tables.

Next step

A useful next step would be to check whether the inactive sessions-to-orders relationship needs to be activated for session-level revenue analysis, and whether a USERELATIONSHIP measure is required to query that path.

Problem

Nura Ibrahim at Meridian Retail needed the orders table cleaned before any revenue visuals could be built. The total_cents column stored values in kobo rather than naira, and the created_at timestamp included a time component that was not useful for date-level analysis.

What I did

Using Table.TransformColumns, I divided total_cents by 100 to convert from kobo to naira. To avoid encoding problems with the naira symbol during the division step, I first renamed the column to a safe placeholder before applying the final display name Total (NGN), a two-rename approach the grader confirmed produced an identical output to the single-step canonical method. The created_at column was cast to type date using Table.TransformColumnTypes, stripping the time component. The Applied Steps run in order: Navigation 1, Renamed Columns, Divided Column, Changed Type, Renamed Columns1.

Outcome

Nura's team could build date-level revenue visuals directly from the cleaned orders table, with no downstream unit conversion needed.

#"Divided Column" = Table.TransformColumns(
 #"Navigation 1",
 {{"total_cents", each _ / 100, type number}}
),
#"Renamed Columns" = Table.RenameColumns(
 #"Divided Column",
 {{"total_cents", "Total (NGN )"}}),
#"Changed Type" = Table.TransformColumnTypes(
 #"Renamed Columns",
 {{"created_at", type date}})

This sequence divides total_cents by 100 to convert kobo to naira, renames the result to the display name, and then casts the date column, matching the logical order required to avoid referencing stale column names.

Next step

It would be worth checking whether the two-rename workaround for the NGN character causes any issues if the report is published to a Power BI Service tenant with different locale settings.

Problem

Nura Ibrahim at Meridian Retail flagged that the order_items table stored unit prices, discounts, and line totals in kobo, matching the same issue found in the orders table. All three columns needed to be converted to naira and renamed before being used in any revenue or margin calculations.

What I did

All three columns, unit_price_cents, discount_cents, and line_total_cents, were transformed in a single Table.TransformColumns call, dividing each by 100. The rename step followed using Table.RenameColumns, producing the display names Unit Price (NGN), Discount (NGN), and Line Total (NGN). Dividing before renaming ensured no step referenced a column name that no longer existed. The same conversion pattern applied to the orders table was used consistently here, which the grader noted as a positive sign of uniform data-cleaning habits across tables.

Outcome

The cleaned order_items table gave Nura's team a reliable base for revenue and margin calculations, with all monetary fields expressed in naira and named consistently.

Next step

A natural follow-on would be to verify that Line Total (NGN) equals Unit Price (NGN) multiplied by quantity minus Discount (NGN) at the row level, to confirm no rounding differences were introduced by separate kobo-to-naira conversions.

Problem

Before any reports from Meridian Retail (simulated retailer) were shared externally, the team needed a consistent brand identity applied in Power BI. The stakeholder specified six exact hex codes covering the primary, secondary, accent, and sentiment palette, and asked that the theme be saved under the name Meridian Retail.

What I did

A custom JSON theme file was authored with the name field set to Meridian Retail and the dataColors array ordered to open with the primary orange (#E8521A) and deep navy (#1A2E4A), followed by amber, teal, green, and red in the sequence the brief specified. The sentiment colours, #4A6741 for good, #F0A500 for neutral, and #CC2200 for bad, were included to ensure any conditional formatting visuals would pick up the correct palette automatically. The theme was then applied to the report, confirmed by the grader via the custom theme field in the PBIP metadata.

Outcome

Meridian's reports now carry a consistent brand identity, and any chart series added in future will draw from the correct colour order without manual formatting.

Next step

The next useful step would be to test how the sentiment palette behaves on a KPI card or conditional formatting rule, to confirm the good/neutral/bad colours render as intended rather than falling back to the dataColors sequence.

Problem

Chidi Okafor needed a clean customer dimension to power a customer dashboard at Meridian Retail. The raw customers table contained known duplicate records that would inflate counts, and it lacked a display name, an acquisition year, and a tier label, all of which the dashboard required.

What I did

The first step was a Table.SelectRows filter on is_duplicate = false, placed at the top of the Applied Steps so that all subsequent columns were built only over the deduplicated row set. Table.AddColumn then concatenated first_name and last_name with a space separator to produce Full Name. A second Table.AddColumn call used Date.Year on created_at and typed the result as Int64 to produce the Acquisition Year. The tier column used conditional column logic: total_orders less than or equal to 1 maps to New, less than or equal to 9 maps to Regular, and anything above maps to Loyal, matching the task definition precisely.

Outcome

Chidi had a deduplicated, enriched customer table with segmentation logic built in, ready for aggregation in any dashboard visual without risk of double-counting.

Next step

It would be worth checking the tier distribution across the 2,131 deduplicated customers to see whether the New/Regular/Loyal split is skewed in a way that would affect how useful the tier column is as a slicer in Chidi's dashboard.