A synthetic retail sales dataset for the fictional Contoso company, arranged as a star schema: one denormalised fact table (sales), its normalised equivalents (orders + orderrows), and five dimension/reference tables (product, customer, store, calendar, fx). Contoso sells consumer electronics and appliances through 73 physical stores across eight countries plus a single online channel, in five currencies.
This dataset is synthetic, generated rather than observed. Customer\nnames, addresses, birthdays, occupations, employers, vehicles, and\ncoordinates are filler describing no real person, and nothing here is\nderived from real trading activity — so distributions, seasonality, product\nco-occurrence, and margins are all artefacts of how it was generated, and\nshould not be read as realistic retail behaviour.
\nSee README.md for where the data came from, which snapshot this\nis, how to rebuild the Parquet files, and which apparently meaningful\npatterns are artefacts of how it was manufactured.
\nAll money columns are denominated in USD, regardless of the order's\ncurrency_code, and are therefore directly summable across orders. To\nexpress an amount in the currency the order was actually placed in,\nmultiply by sales.exchange_rate.
This is worth stating explicitly because the schema invites the opposite\nreading — orders carry a currency_code, so it is natural to assume the\namounts are already local. They are not. The evidence:
sales.unit_price equals product.price scaled by a factor that is a\npure function of (product category, order date) — verified across all\n3,816 category-day combinations — with no dependence on currency_code\nwhatsoever. That factor is a category price index (see the glossary), not\na conversion.sales.exchange_rate is supplied separately, and exactly matches the\nfx rate from USD to the order's currency_code (1.0 for USD orders).\nIt would be redundant if the amounts were already converted.So net_revenue sums directly; net_revenue * exchange_rate gives local\ncurrency. units: USD is declared on the money columns accordingly.
Each row is one line item on one customer order — the same grain as orderrows. This is the fully denormalised fact table: it repeats every column of orders and orderrows, adds the day's exchange_rate, and pre-computes seven revenue, cost, and margin measures. Covers orders placed 2021-05-18 to 2024-04-20.
This table is redundant with orders + orderrows. Joining\norders to orderrows on order_key reproduces sales exactly: all\noverlapping columns are value-identical, verified row by row. Use\nsales for analysis and ignore the other two, or use the normalised\npair and ignore sales — but don't join sales to either, or you will\ndouble-count.
All seven derived measures are exact. Each was verified to hold to\nfloating-point precision on every row, so they are safe to trust and\nredundant to recompute:
\ngross_revenue = unit_price * quantitynet_revenue = net_price * quantityunit_discount = unit_price - net_pricediscounts = unit_discount * quantitycogs = unit_cost * quantitygross_margin = net_revenue - cogsunit_margin = gross_margin / quantityNote the asymmetry: gross_margin is computed from net revenue, so\nit is already net of discounts despite the name.
All money columns are in USD regardless of currency_code, so they sum\ndirectly; multiply by exchange_rate for the order's billing currency.\nSee the dataset-level details.
Identifies the order this line belongs to. Sparse and non-sequential — values jump in steps of ~100 with occasional +1 siblings (233400, 233401), so gaps carry no meaning and the key must not be treated as a row counter.
Position of this line within its order, starting at 0. Not always contiguous: 44 of 3,242 orders skip a value, so never infer an order's line count from max(line_number).
Denormalised from orders; constant within an order.
Denormalised from orders; constant within an order. Always on or after order_date. In-store orders are always same-day; online orders always take 1–8 days.
Denormalised from orders; constant within an order.
Denormalised from orders; constant within an order. 999999 is the online channel, not a physical store, and accounts for 54% of orders — filter it out to analyse bricks-and-mortar performance.
The product sold on this line. Only 1,916 of the 2,517 products in product ever appear here.
Units of product_key sold on this line, always a whole number.
List price per unit at the time of the order, before discount. Equals product.price times that product category's price index for order_date — so it is the historical price, while product.price is the mid-2022-onward level. See \"category price index\" in the glossary.
Price actually charged per unit, after discount. Exactly unit_price times (1 - d/100) for an integer d from 0 to 14; equal to unit_price on 39% of lines.
Cost to Contoso per unit. Equals product.cost times the same category price index applied to unit_price, so the cost/price ratio is a property of the product alone and gross margin percentage is unaffected by when the order was placed.
Currency the order was placed in, denormalised from orders. USD on 51% of lines. Note this does not describe the money columns in this table, which are all USD — it is the billing currency, and exchange_rate converts into it.
The fx rate from USD to currency_code on order_date, joined in from the fx table (verified to match exactly). Always 1.0 for USD orders. Multiply any money column in this table by it to get the order's billing currency. It is not the category price index relating unit_price to product.price.
Revenue before discount — unit_price * quantity.
Revenue actually booked — net_price * quantity. This, not gross_revenue, is the top line you usually want. In USD, so it sums directly across orders in different currencies.
Per-unit discount — unit_price - net_price. Zero on 39% of lines. Always an exact whole percentage of unit_price, 0–14%, so unit_discount / unit_price recovers the discount rate cleanly. The rate itself is not stored as a column.
Total discount on the line — unit_discount * quantity.
Cost of goods sold on this line — unit_cost * quantity. Product cost only; carries no allocation of freight, overhead, or labour.
net_revenue - cogs. Computed from net rather than gross revenue, so discounts are already deducted. Always positive — no line in this snapshot sells below cost.
Margin per unit — gross_margin / quantity. Averaging this across lines weights every line equally regardless of quantity; sum gross_margin and divide by summed quantity instead.
Each row is one customer order header — the who, where, and when. One row per order_key, 3,242 orders placed between 2021-05-18 and 2024-04-20. Line-level detail lives in orderrows.
Redundant with sales, which contains every column of this table denormalised to line grain. Nearly one order per customer: 3,242 orders across 3,165 customers, and no customer placed more than 3.
Sparse and non-sequential — steps of ~100 with occasional +1 siblings. Gaps are meaningless.
Customer who placed the order.
", "type": "number(id)", "constraints": [ "foreign_key", "required" ], "references": { "table": "customer", "column": "customer_key" }, "examples": [ 1401, 533076, 1233391, 1692034, 2099336 ] }, { "name": "store_key", "description": "Store the order was placed at, or 999999 for the online channel (54% of orders). Only 58 of the 74 rows in store are ever used. No order falls outside its store's open/close window.
Date the order was placed. Starts 2021-05-18, four and a half months after calendar begins, and stops 2024-04-20, eight months before it ends — so calendar deliberately over-covers the sales period.
Date of delivery. Always on or after order_date. Perfectly determined by channel: in-store orders are same-day without exception, online orders take 1–8 days (median 3) and never 0. The R docs disagree with themselves about whether this is the expected or the actual delivery date; the data cannot distinguish the two, since every order has one and none is null.
Currency the order was placed in. Not implied by the store's country — online orders are billed in a mix of currencies.
", "type": "enum", "constraints": [ "required" ], "values": [ "AUD", "CAD", "EUR", "GBP", "USD" ] } ] }, { "name": "orderrows", "description": "Each row is one line item on one order: which product, how many, and at what price and cost. 7,794 lines across 3,242 orders. The normalised counterpart to sales, without the denormalised header columns, exchange rate, or derived measures.
Redundant with sales: joining this table to orders on order_key reproduces sales exactly. Money columns are in USD, not the order's billing currency — the rate needed to convert them lives in sales.exchange_rate, which this table does not carry.
Order this line belongs to. Every order_key in orders appears here at least once.
Position within the order, from 0. Has gaps in 44 orders, so it is not a reliable line counter.
", "type": "number(ordinal)", "constraints": [ "primary_key", "unique", "required" ], "range": { "min": 0, "max": 6 } }, { "name": "product_key", "description": "Product sold on this line.
", "type": "number(id)", "constraints": [ "foreign_key", "required" ], "references": { "table": "product", "column": "product_key" }, "examples": [ 1, 551, 1183, 1724, 2517 ] }, { "name": "quantity", "description": "Units sold, always a whole number.
", "type": "number(quantity)", "units": "units", "constraints": [ "required" ], "range": { "min": 1, "max": 10 } }, { "name": "unit_price", "description": "List price per unit before discount — product.price times that product category's price index for the order's date. See \"category price index\" in the glossary.
Price charged per unit after discount — per-unit, not a line total. The line total is net_price * quantity, which sales.net_revenue supplies. The discount is always an exact whole percentage, 0–14%.
Cost per unit — product.cost times the same category price index applied to unit_price.
Each row is one sellable product (SKU), 2,517 in total, spanning consumer electronics and home appliances under 11 house brands. The full catalogue, not just what sold: 601 products never appear in sales, so joining from sales will not reach them.
price and cost are USD catalogue values at the mid-2022-onward price level, not at the time of any given sale — the prices actually transacted are in sales/orderrows and differ before 2022-07-03 by that category's price index. color is dirty (see that column), and weight is missing for 284 products.
Dense surrogate key running 1–2,517 with no gaps, unlike the other key columns in this dataset.
", "type": "number(id)", "constraints": [ "primary_key", "unique", "required" ], "referenced_by": [ { "table": "sales", "column": "product_key" }, { "table": "orderrows", "column": "product_key" } ], "examples": [ 1, 630, 1259, 1888, 2517 ] }, { "name": "product_code", "description": "Zero-padded 7-digit business code that encodes the hierarchy: first 2 digits are category_key, next 2 the subcategory sequence, last 3 a within-subcategory counter. So 0101001 is category 1, subcategory 101, item 1. Keep it as a string — leading zeros are significant.
Marketing name, conventionally <brand> <description> <model> <color>. Both brand and colour are repeated here from their own columns, so parsing this string is never necessary.
Legal manufacturer name. Strictly one-to-one with brand — it is the same 11 entities with legal suffixes attached, so the two columns are interchangeable for grouping.
Trading name. All 11 brands are Contoso's own — these are the standard Microsoft sample-data fictional companies, not third-party suppliers.
", "type": "enum", "constraints": [ "required" ], "values": [ "A. Datum", "Adventure Works", "Contoso", "Fabrikam", "Litware", "Northwind Traders", "Proseware", "Southridge Video", "Tailspin Toys", "The Phone Company", "Wide World Importers" ] }, { "name": "color", "description": "Product colour, and it is dirty: blue and Blue are separate values differing only in case, and Grey/Silver/Silver Grey overlap in meaning. Normalise case before grouping or you will split blue across two buckets.
Unit that weight is expressed in — it varies by row, so weight is not comparable across products without conversion. Imperial dominates: 1,867 pounds, 418 ounces, only 10 grams. Null for the 222 products with no weight data at all.
Product weight in the unit given by weight_unit, which differs from row to row — so this column must never be summed or compared directly. Null for 284 products; note the mismatch with weight_unit, which is null for only 222, leaving 62 products with a declared unit but no value.
Catalogue unit cost in USD. A reference value only, and one pinned to the price level from 2022-07-03 onward — the cost recorded against a sale is sales.unit_cost, which rescales this by the category price index in force on the order date.
Catalogue list price in USD. Always above cost, giving catalogue margins of roughly 45–55%. A reference value pinned to the 2022-07-03-onward price level, as with cost.
Top level of the two-level product hierarchy, stored numerically: 1 Audio, 2 TV and Video, 3 Computers, 4 Cameras and camcorders, 5 Cell phones, 6 Music, Movies and Audio Books, 7 Games and Toys, 8 Home Appliances. The dataset ships no category dimension table; category_name carries the same labels as strings.
Second level of the hierarchy, 32 subcategories. Encodes its parent: sub_category_key %/% 100 == category_key on every row, verified. Numbering is not contiguous within a category (Audio has 101, 104, 106), so gaps are expected. Category 6 (Music, Movies and Audio Books) is a stub with the single subcategory 602, Movie DVD.
Label for category_key; strictly one-to-one with it.
Label for sub_category_key; strictly one-to-one with it.
Each row is one customer, 3,165 in total, across eight countries on three continents. Only customers who ordered are present — every customer_key here appears in sales, so this is not a full customer master and cannot be used to study non-purchasers or compute conversion rates.
Deduplicated during conversion: the source R data frame had 7,794 rows,\none per sales line, with byte-identical duplicates per customer. See\nREADME.md.
\nEvery attribute is synthetic filler — names, addresses, occupations,\nemployers, vehicles, coordinates. In a real system most of these columns\nwould be restricted personal data; they are left unrestricted here only\nbecause no real person is described. Two columns are of unknown meaning\n(start_date, end_date) and one is internally inconsistent (age);\nall three are documented below.
There is no geographic dimension table, so geo_area_key cannot be\nresolved to anything beyond the address columns already present here.
Very sparse — 3,165 customers spread over the range 1,401 to 2,099,336, so the key says nothing about how many customers exist.
", "type": "number(id)", "constraints": [ "primary_key", "unique", "required" ], "referenced_by": [ { "table": "sales", "column": "customer_key" }, { "table": "orders", "column": "customer_key" } ], "examples": [ 1401, 533076, 1233391, 1692034, 2099336 ] }, { "name": "geo_area_key", "description": "Identifier for the customer's geographic area, one per state_full value. A dangling reference: no geo-area table ships with the dataset and the key implies no hierarchy, so it resolves to nothing the address columns here don't already give you. It is a leaf-level region, one per state_full. Usable only to group customers, or to match against store.geo_area_key — 51 of the 311 customer areas also contain a store.
Meaning undetermined, and almost certainly filler. The name suggests the start of the customer relationship, but the values run 1980–2010, ending more than a decade before the first order in sales, which is inconsistent with that reading — and no other column corroborates any alternative. Its shape suggests a synthetic identity attribute, such as a document validity date, rather than a modelled business date. Do not compute tenure or customer lifetime from it.
Meaning undetermined, like start_date. Values run 2021-07-17 to 2045-12-28, overwhelmingly in the future, so it is not a churn date; nor is it a far-future sentinel, since the values are nearly all distinct. Do not use it to identify lapsed customers.
Customer's continent. Heavily skewed to North America (4,833 of the source rows) and it treats Australia as a continent.
", "type": "enum", "constraints": [ "required" ], "values": [ "Australia", "Europe", "North America" ] }, { "name": "gender", "description": "Lowercase, and strictly binary. The absence of other categories is a limitation of how the data was synthesised, not a finding about any population.
", "type": "enum", "constraints": [ "required" ], "values": [ "female", "male" ] }, { "name": "title", "description": "Honorific, with the trailing period included. Correlated with gender for the three gendered titles; Dr. appears for both.
First name. 1,411 distinct values, so heavily reused across customers.
", "type": "string", "constraints": [ "required" ], "examples": [ "Aaron", "Douglas", "Jovianne", "Oren", "Zuzana" ] }, { "name": "middle_initial", "description": "Single letter, A–Z plus one accented É — so it is not safe to assume plain ASCII.
Last name, 2,183 distinct values.
", "type": "string", "constraints": [ "required" ], "examples": [ "Aaron", "Dresdner", "Kralj", "Quintana", "Zuidgeest" ] }, { "name": "street_address", "description": "Street line only, no city or postcode. Localised to the customer's country, so formats vary (4741 Philadelphia Avenue, Zwartbroekstraat 180).
City name. Some German values are doubled (Aalen Aalen), so exact matching against external city lists will miss rows.
State, province, or region in whatever short form the country uses — US and Canadian abbreviations (UT, AB), Dutch codes (ZH), but spelled-out names elsewhere (Rutland, Perth and Kinross). Not a uniform code system, and note it means something different from store.state, which is always spelled out.
Spelled-out region name, and the level geo_area_key corresponds to. 311 distinct values against 286 for state, because some short forms collide across countries — prefer this column when grouping geographically.
Postal code in national format — US 5-digit with significant leading zeros (00040), UK alphanumeric (ZE2 4LT), Dutch with a space (3232 SE). Must stay a string.
ISO 3166-1 alpha-2 country code. Eight countries, one fewer than store.country_code, which adds a -- placeholder for the online channel.
Label for country; strictly one-to-one with it.
Date of birth, 1935–2002, implying an adults-only customer base by construction. Prefer deriving age from this over using age.
Age in whole years, frozen at roughly the start of the data (about 2021-01-01) rather than computed as of the order date — so it goes stale and should not be used for point-in-time analysis. It is also not exactly reproducible from birthday: it matches the age implied at 2021-01-01 on only 90% of rows and is off by one on the rest. Recompute from birthday if precision matters.
Free-text job title, 1,849 distinct values over 3,165 customers — effectively high-cardinality noise with no controlled vocabulary or industry coding. Not usable for segmentation without heavy grouping.
", "type": "string", "constraints": [ "required" ], "examples": [ "A & P mechanic", "Deck officer", "Junior high school teacher", "Probation officer", "Zoologist" ] }, { "name": "company", "description": "Customer's employer. Null exactly once, which looks like an accident of generation rather than a meaningful \"unemployed\" marker.
", "type": "string", "examples": [ "10\\", "000 Auto Parts", "Endicott Shoes", "Licorice Pizza", "Reliable Investments", "Zephyr Investments" ] }, { "name": "vehicle", "description": "Model year, make, and model of a vehicle attributed to the customer as a single string (2003 TVR Tuscan). Nearly unique — 2,775 distinct values across 3,165 customers — and unrelated to anything Contoso sells.
Latitude of the customer's address, positive north. Distinct for every customer, so it pinpoints the individual address rather than a city or region centroid.
", "type": "number(quantity)", "units": "degrees", "constraints": [ "required" ], "range": { "min": -43.22282, "max": 68.35464 } }, { "name": "longitude", "description": "Longitude of the customer's address, positive east. The range spans nearly the whole globe because the eight countries straddle the antimeridian side of the Pacific; do not average it.
", "type": "number(quantity)", "units": "degrees", "constraints": [ "required" ], "range": { "min": -165.1375, "max": 153.5661 } } ] }, { "name": "store", "description": "Each row is one Contoso sales location: 73 physical stores across nine countries plus a single synthetic row for the online channel. Includes stores that have since closed, and 16 of the 74 rows never appear in sales at all.
Two things to watch. First, store_key 999999 is not a real store — see that column. Second, store_code is not unique: seven codes are shared by two or three store_key values in the same state, apparently successive premises at one site (typically an earlier Restructured or Closed row alongside a still-open successor). Group by store_key for individual locations and by store_code for sites.
Mostly multiples of 10, with +5/+2/+4 siblings where a site has more than one store. 999999 is the online channel sentinel.
Short business code for the physical site, 1–67. Not unique — seven codes cover two or three stores each, so it is not a usable join key. -1 on the online row.
Geographic area of the store, on the same numbering as customer.geo_area_key, though no geo-area table ships with the dataset. Not unique — sites with more than one store share an area. -1 on the online row.
ISO 3166-1 alpha-2 code, plus the non-standard -- placeholder on the online row. Filter out -- before joining to any real country reference.
Label for country_code, with the pseudo-country Online for the online channel. Excluding that, the same eight countries as customer.country_full.
Region the store sits in, always spelled out in full (South Australia, Delaware) — unlike customer.state, which is often an abbreviation. Literally Online on the online row. Not unique: 67 values over 74 rows, matching the shared store_codes.
Date the store opened, all well before the first order in sales. The online row carries a nominal 2010-01-01.
Date the store closed, null for the 58 stores still open (including the online channel). Every closure predates 2019-11-03, and no order in sales falls outside its store's open/close window — so closed stores contribute only historical sales.
Always the literal Contoso Store <state>, or Online store for the online row. Carries no information beyond state, despite the name suggesting a free-text description or a store format.
Selling floor area. Null only for the online row, which has no floor. Clustered on round numbers (2000, 3500), so it is a banded estimate rather than a measurement.
", "type": "number(quantity)", "units": "m2", "range": { "min": 245, "max": 3500 } }, { "name": "status", "description": "Exceptional status flag, and null means the store is open and operating normally — which covers 59 of 74 rows, including the online channel. Only 8 Closed and 7 Restructured rows carry a value. Beware: status and close_date disagree — some rows with a close_date are marked Restructured rather than Closed — so treat close_date IS NOT NULL as the reliable test for whether a store has shut.
Each row is one calendar day, covering 2021-01-01 to 2024-12-31 with no gaps (1,461 days, including the 2024 leap day). A conventional date dimension: every column is a derived attribute of date, provided so that time-based grouping needs no date arithmetic.
Deliberately wider than the sales period, which runs 2021-05-18 to 2024-04-20 — so 240 days at the start and 255 at the end have no orders. Use an inner join to sales if you want only trading days.\nThe working_day flag is pure weekday logic — Saturday and Sunday are 0, every Monday to Friday is 1 — so no public holidays are modelled, not even 2021-01-01.\nSeveral of the numeric columns don't hold what their names suggest; each says what it actually contains.
The calendar day. Contiguous and complete over the four-year span.
", "type": "date", "constraints": [ "primary_key", "unique", "required" ], "referenced_by": [ { "table": "sales", "column": "order_date" }, { "table": "sales", "column": "delivery_date" }, { "table": "orders", "column": "order_date" }, { "table": "orders", "column": "delivery_date" } ], "range": { "min": "2021-01-01", "max": "2024-12-31" } }, { "name": "date_key", "description": "The same day as an integer in YYYYMMDD form — the conventional date surrogate key. Nothing else in this dataset references it; the fact tables join on real dates instead.
Calendar year.
", "type": "number(ordinal)", "range": { "min": 2021, "max": 2024 } }, { "name": "year_quarter", "description": "Quarter label formatted Q<n>-<year>, e.g. Q1-2021. Note it sorts alphabetically by quarter before year, so order by year_quarter_number instead.
A continuous quarter counter equal to year * 4 + quarter, so Q1 2021 is 8,085 and consecutive quarters differ by exactly 1. Use it to sort or to compute quarter differences. Not a 1–4 quarter number — that is quarter.
Quarter within the year, ignoring which year.
", "type": "enum", "constraints": [ "required" ], "values": [ "Q1", "Q2", "Q3", "Q4" ] }, { "name": "year_month", "description": "Month label formatted <Month name> <year>, e.g. January 2021. Sorts alphabetically, not chronologically.
Abbreviated form of year_month, e.g. Jan 2021. Also sorts alphabetically.
A continuous month counter equal to year * 12 + month_number, so January 2021 is 24,253 and consecutive months differ by 1. Not YYYYMM, despite the name — 202101 does not appear anywhere in this column.
Full English month name, without the year.
", "type": "enum", "constraints": [ "required" ], "values": [ "January", "February", "March", "April", "May", "June", "July", "August", "September", "October", "November", "December" ] }, { "name": "month_short", "description": "Three-letter English month abbreviation.
", "type": "enum", "constraints": [ "required" ], "values": [ "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" ] }, { "name": "month_number", "description": "Month of the year, 1 = January.
", "type": "number(ordinal)", "range": { "min": 1, "max": 12 } }, { "name": "day_of_week", "description": "Full English weekday name.
", "type": "enum", "constraints": [ "required" ], "values": [ "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday", "Sunday" ] }, { "name": "day_of_week_short", "description": "Three-letter English weekday abbreviation.
", "type": "enum", "constraints": [ "required" ], "values": [ "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun" ] }, { "name": "day_of_week_number", "description": "Day of the week with the week starting on Sunday: 1 = Sunday, 2 = Monday, … 7 = Saturday — not the ISO convention of 1 = Monday. Verify against 2021-01-03, a Sunday, which is 1.
", "type": "number(ordinal)", "range": { "min": 1, "max": 7 } }, { "name": "working_day", "description": "Weekday flag, stored numerically: 1 is a working day (Monday to Friday), 0 a non-working day (Saturday or Sunday). Determined purely by day_of_week — public holidays are not modelled, so 2021-01-01 and 2024-12-25 both count as working days.
Cumulative count of working days elapsed since 2021-01-01 — not a 0/1 flag, which is working_day. It increments on each working day and repeats the previous value across weekends, reaching 1,003 by 2024-12-31. Differencing it between two dates gives the number of working days between them.
Each row is a daily exchange rate for one ordered currency pair: the complete 5x5 matrix of AUD, CAD, EUR, GBP, and USD for all 1,461 days from 2021-01-01 to 2024-12-31 (25 pairs x 1,461 days = 36,525 rows, with no gaps).
", "details": "Internally consistent: self-pairs are exactly 1.0, and reciprocal pairs multiply to 1.0 to within rounding. Because the matrix is complete, no chaining through USD is ever needed — look the pair up directly.\nsales.exchange_rate is drawn from this table, specifically the USD → order-currency rate on order_date, verified to match exactly. To reproduce that join, match sales.order_date = date and sales.currency_code = to_currency and filter to from_currency = 'USD' — without the filter the join fans out five-to-one across base currencies. (This relationship is not declared in relationships because the join grammar can't express the constant filter; see tidyverse/data-dict#252.)
Day the rate applies to. Rates are quoted on every calendar day including weekends and holidays, unlike real FX markets.
", "type": "date", "constraints": [ "primary_key", "unique", "required" ], "range": { "min": "2021-01-01", "max": "2024-12-31" } }, { "name": "from_currency", "description": "Currency being converted from — the base of the quote.
", "type": "enum", "constraints": [ "primary_key", "unique", "required" ], "values": [ "AUD", "CAD", "EUR", "GBP", "USD" ] }, { "name": "to_currency", "description": "Currency being converted to. All 25 ordered pairs are present each day, including the five self-pairs.
", "type": "enum", "constraints": [ "primary_key", "unique", "required" ], "values": [ "AUD", "CAD", "EUR", "GBP", "USD" ] }, { "name": "exchange", "description": "Units of to_currency per one unit of from_currency — multiply a from_currency amount by this to get to_currency. Exactly 1.0 whenever the two currencies match.
The normalised header-to-line join. Performing it and adding the derived measures reproduces sales exactly.
Each sales line was bought by one customer. Every customer in customer has at least one sales line, so an inner join loses no customers.
Each sales line is one product. 601 of the 2,517 products never sold, so join from product if you need the full catalogue including non-sellers.
Each sales line was placed at one store, where store_key 999999 is the online channel rather than a physical location. 16 of the 74 store rows have no sales.
Standard date-dimension join for grouping sales by period. calendar covers 495 days with no orders, so join from calendar if you need a dense time series with explicit zeros.
The second date role. calendar can only play one role per join, so alias it (a \"role-playing dimension\") if you need to group by order date and delivery date at once.
A fictional consumer-electronics and appliance retailer used in Microsoft's sample datasets. Also the name of the house brand (product.brand = 'Contoso'), so \"Contoso\" can mean either the whole company or one of its 11 brands depending on context.
The multiplier relating transacted prices to catalogue prices, sales.unit_price = product.price x index(category, order_date). It applies identically to cost, so it shifts a category's price level over time without changing margin percentage.\nIt is a pure function of product category and order date — verified across every category-day combination in the data — and takes the form of a single step per category on 2022-07-03, from a category-specific level to 1.00, where it stays: Computers 1.50, Cell phones 1.40, Music/Movies 1.30, Cameras 1.10, TV and Video 0.95, and Audio, Games and Toys, and Home Appliances all 0.90. So product.price is the price level from July 2022 onward, and electronics prices fell into that date while the cheaper categories rose.\nTwo things it is not: a currency conversion (it has no dependence on currency_code) and a discount (that is separate, and shows up as the gap between unit_price and net_price). The index is not stored as a column — it is only recoverable by dividing transacted price by catalogue price.
Revenue at list price, before discount: unit_price x quantity.
Revenue actually booked, after discount: net_price x quantity. The normal choice for \"sales\" or \"turnover\".
Cost of goods sold — the product cost of what was sold, unit_cost x quantity. In this dataset it is purely product cost, with no freight, overhead, or labour allocated in.
net_revenue - cogs. Despite \"gross\", it is calculated from net revenue, so discounts are already deducted.
The reduction from list to transacted price, unit_price - net_price per unit. Always an exact whole percentage of unit_price between 0 and 14%: 0% on 39% of lines, with the rest concentrated around 11–12%. The percentage itself is not stored — recover it as unit_discount / unit_price. Distinct from the category price index, which moves the list price rather than discounting it.
A geographic region roughly equivalent to a state, province, or county, identified by geo_area_key and named by customer.state_full. No dimension table for it ships with the dataset, so the key resolves to nothing on its own.
Contoso's non-physical sales channel, encoded as the sentinel store_key = 999999 with a synthetic row in store (country_name = 'Online', store_code = -1, geo_area_key = -1, null square_meters). It carries 54% of orders, so leaving it in or filtering it out changes almost every store-level result.
A store.status value marking a store that was rebuilt or replaced rather than simply shut. Restructured stores generally share a store_code with a successor store at the same site, which is why store_code is not unique.
A dimension table joined more than once to the same fact table under different meanings — here calendar, joined on both order_date and delivery_date. Each role needs its own aliased copy in a query.
The level of detail one row represents. sales and orderrows are at order-line grain (order_key + line_number); orders is at order grain. Mixing grains in a join is the most common way to double-count in this dataset.