A "dimension" table is supposed to have one row per entity. In practice a customer profile gets a new row every time it's updated, and the table that reaches you has three rows for the customer you are about to join against.
Write enrich_orders(orders, customers). orders has order_id, customer_id, amount. customers has customer_id, name, updated_at, and may contain more than one row per customer_id — each one a snapshot of that customer's profile at a point in time.
Return orders with a name column added, taken from that customer's most recently updated profile row. A customer with no row at all in customers gets name = NaN; the order is still present.
The output must have exactly one row per input order. A join that lets a customer's duplicate profile rows multiply an order into two or three copies of itself is the bug this problem is about.
Sorted by order_id ascending.
Build the architecture on a canvas: place the components, configure them, connect them into a data flow, and write a short reason for each one. The AI reviewer grades your design against a rubric written specifically for this problem.
Minimum 5 components · needs a wide desktop screen