Understanding Business Data

Chapter 1.3 · Understanding Business Data

A spreadsheet contains rows and columns, but understanding data requires more than recognizing cells. The analyst must know what each record represents, how a field was collected, whether it is reliable and how different sources relate. Two datasets can look similar while answering entirely different questions.

In Meridian Retail, a sale, a product, a customer and a website visit are different business entities. Counting them interchangeably may create convincing but incorrect conclusions. This chapter provides the language and habits needed to interpret data before calculating results.

1.3.1 Structured, semi-structured and unstructured data

Structured data follow a predefined arrangement, commonly a table with named columns and consistent types. A list of completed orders with order IDs, dates and values is structured. Semi-structured data, such as many JSON records or system logs, have recognizable labels and hierarchy without requiring every record to share identical fields. Unstructured data includes free-text comments, images, audio recordings and documents whose meaning cannot be understood reliably from fixed columns alone.

These categories describe organization rather than quality. A structured table can contain numerous errors, while an unstructured customer complaint may contain highly useful evidence. Analysts select methods suited to the source: tables for aggregations, parsers for nested logs, and text-processing methods when language itself is the subject.

1.3.2 Data types and why they matter

Numeric fields can represent quantities or measured values, such as revenue and units. Text fields represent descriptions and identifiers; a postal code should generally be kept as text because leading zeros may matter. Date and time fields describe when events occurred. Boolean fields represent yes/no states. Categories are labels such as channel or product group, even when stored internally as numbers.

It is important to distinguish a field's displayed appearance from its semantic meaning. An order ID such as “100023” looks numeric but should not be averaged. A date written as “02/03/2026” may be ambiguous until its format and timezone are agreed. A missing value can mean not recorded, not applicable, unknown or deliberately withheld—each interpretation has different consequences.

1.3.3 CSV, Excel, JSON and databases

CSV is a simple text format that stores one record per line with fields separated by delimiters. It is portable and easy to inspect, but does not preserve formulas, cell formatting or multiple sheets. Excel workbooks support tables, sheets, formulas and visual analysis; they are convenient for exploration but can also contain accidental manual changes. JSON represents data through objects and arrays and is widely used for software and event exchange.

A relational database stores related tables, often connected through keys. An Orders table may contain a customer ID; a Customers table contains one row per customer. A primary key uniquely identifies a record in its table. A foreign key links it to a related table. Using these relationships correctly can avoid duplication in reporting.

1.3.4 Granularity: what does one row mean?

Granularity, often called a dataset's grain, is the level of detail represented by a record. A daily sales summary has one row per day; an order table has one row per order; an order-line table has one row per product within an order. Analysts must state the grain explicitly before making joins or aggregations.

Suppose one order worth ₹2,000 contains two product lines. Joining the order header to both lines and then summing the order-header revenue would produce ₹4,000—double the correct amount. This is a fan-out error. The appropriate approach is to aggregate at the intended grain or use line-level amounts. Similarly, counting lines is not the same as counting distinct orders.

Ask three questions before using an unfamiliar dataset: “What does one row represent?”, “Which column uniquely identifies that row?”, and “What records may be missing or duplicated?”

1.3.5 Data quality and responsible use

Common quality dimensions include completeness (are required values present?), uniqueness (are records duplicated?), validity (do values meet rules?), consistency (do sources agree?) and timeliness (are records available when needed?). Accuracy—the closeness of a record to the true event—is especially important but can be difficult to check without an independent source.

For Meridian's order file, useful tests include checking that order IDs are unique, dates fall within the reporting period, channel values belong to the expected set and revenue is nonnegative for completed sales. Customer-level data should be handled according to authorized access and data minimization rules. A useful analysis does not require every analyst to receive identifiable personal information.

1.3.6 The business data lifecycle

Data move through stages: creation or collection, storage, processing, use, sharing, archiving and eventual deletion according to retention requirements. A quality issue may originate at any stage. For example, a missing checkout event might be caused by a collection bug, not by a customer's behavior.

A data-source inventory records each dataset's owner, system, grain, business purpose, refresh frequency, sensitivity, key fields and known limitations. In a larger organization it also includes approved access paths and retention requirements. Maintaining this inventory prevents teams from relying on outdated, unauthorized or misunderstood copies.

1.3.7 Worked example: profile the retail files

Download Retail_Sales.csv and Retail_Customers.csv from the dataset library. In Excel, inspect the first ten rows, count records, look for blank order IDs and check whether each order ID is unique. Identify order date as a date, channel as a category, customer ID as an identifier and net revenue as a monetary measure. Confirm that the sales file has one row per order before computing order counts.

The next step is to compare possible join keys. A customer may place multiple orders, so customer ID is not unique in the sales file. That is expected, not automatically a duplicate error. A reliable profile explains what should be unique and what should repeat.

1.3.8 Chapter summary

Before analysis comes interpretation. The format of data, the meaning of each field, the grain of each table, source lineage and quality conditions all shape what conclusions are valid. Analysts create trusted results by documenting these features rather than assuming that familiar-looking columns tell the full story.