Turn a Retail Database Export Into a Useful Public Table

To share retail sales data, publish a reviewed summary—not a copy of the operational database. A useful starting point is one row per month, region, product category and currency, with clearly defined sales and unit measures.

The result is a table readers can filter to a category or region without needing your database software, customer records or internal lookup tables.

What is a retail database?

A retail database stores structured records about retail activity: products, stores, orders, sales lines, returns and inventory. Those records often live in related tables rather than one spreadsheet.

For analysis, it helps to distinguish events and measurements from descriptive information. Microsoft’s star-schema guidance calls these fact tables and dimension tables: facts hold observations such as sales or stock balances; dimensions describe entities such as products, places and dates.

Here is an illustrative structure, not a required schema:

Table	What one row represents	Identifier or relationship
Products	One product	Unique product_id
Stores	One store	Unique store_id
Orders	One order	Unique order_id; links to a store
Sales lines	One line within an order	Unique order_id + line_id; links to a product
Inventory snapshots	One product at one store at one observation time	product_id + store_id + snapshot_at

A database supports the underlying business records. A public spreadsheet export serves a narrower purpose: answering a defined reader question with an approved subset of those records.

1. Define the question and row meaning

Start with a question such as: How did monthly net sales vary by region and product category?

Write down the row meaning before joining or exporting anything. This is the table’s grain, or level of detail. Microsoft recommends keeping fact-table data at a consistent grain.

For this example, each combination of month, region, category and currency must appear only once. Do not mix individual purchases, category subtotals and all-region totals in the same data body: summing the resulting column would double-count sales.

Keep inventory snapshots separate unless you explicitly define how they become a monthly measure. Adding daily stock balances does not produce a meaningful month-end inventory figure.

2. Build a publication-only extract

Select only the fields needed for the question. Join product and store descriptions to sales lines, then aggregate to the chosen grain. If returns are stored separately, include their events too—even for groups with returns but no new sales in the month.

Before aggregation, check the relationships:

• Lookup keys are unique. Two product records with the same join key can turn one sales line into two rows. If descriptions are versioned over time, match each event to the appropriate version rather than joining on product ID alone.
• Unmatched records are counted. Decide whether they belong in an “Unknown” category; do not silently discard them.
• Totals reconcile. Compare sales and units before and after descriptive joins, then compare the export with the approved source report.
• Returns are handled once. If sales amounts already include refunds, do not subtract those refunds again.

Do not sum an order-level total after repeating it across every sales line. Use line-level amounts, or calculate order totals separately.

Here is a synthetic CSV example containing no real retailer or customer data:

month,region,category,units_sold,units_returned,net_sales,currency
2026-09,North,Home,120,5,3450.00,USD
2026-09,North,Apparel,80,8,2160.00,USD
2026-09,South,Home,95,3,2810.00,USD

For this example, units_sold counts units before returns, units_returned counts returned units as positive numbers, and net_sales means sales after discounts and refunds, excluding sales tax. Record sales and returns in their respective event months, assigning returns to the original sale’s region and category. Consequently, units_returned may relate to purchases made in earlier months; it is not a same-month purchase-cohort return rate.

Keep monetary values numeric and currency separate. Do not combine different currencies into a total without a documented conversion method.

3. Review disclosure risk before uploading

Exclude names, email addresses, delivery addresses, payment information, loyalty identifiers and free-text customer notes. Also remove confidential commercial fields unless their release is authorized.

Removing names alone is not enough. The UK ICO’s anonymisation guidance explains that records can identify people through singling out or linkage with other information, and that public release requires stronger risk controls than sharing with known recipients.

Review small groups and unusually detailed combinations. Broaden categories, suppress risky cells or omit data where necessary. Aggregation is a disclosure-control option, not a guarantee of anonymity. If the extract cannot be approved for unrestricted public access, do not upload it to a public publisher.

4. Export, document and publish

Create a clean file with one header row, no merged cells and no embedded subtotals. Re-import it and check row count, dates, numeric columns and totals. Excel’s CSV export documentation notes that only the current worksheet is saved and that some workbook features are unsupported. See also why CSV helps when sharing data.

Prepare an accompanying note stating:

• Source and permission or license for reuse.
• Coverage period, included regions and exclusions.
• Row grain, units, currency and measure definitions.
• Treatment of returns, missing values and suppressed cells; do not represent missing or suppressed amounts as zero.
• Extraction date and update schedule—or that this is a fixed snapshot.

As of October 19, 2026, TablePage supports CSV, TSV, XLSX and XLS uploads and generates a public dataset page with a shareable link and filterable table. Upload only the reviewed publication file, then inspect the resulting page before distributing the link.

Check that a reader can isolate one region and category, interpret the amounts correctly and find the provenance note in the accompanying publication. For a broader scorecard, choose additional measures using the retail store performance metrics guide—and define their denominators before adding them to the export.