Structured Data
Structured data is data organized into a predefined, fixed schema — rows and columns, each column with a known name and type — the format of a relational database table or a well-formed spreadsheet, where every record has the same fields in the same shape. The schema is defined before the data arrives, not inferred from it afterward, and that upfront structure is what makes structured data straightforward to query, validate, and aggregate: a SQL query summing a "revenue" column works reliably because every row is guaranteed to have a revenue field of a known numeric type, with no row-by-row surprises about what shape the data takes.
Industry estimates — most frequently cited as roughly 80 to 90 percent of enterprise data being unstructured, a figure that has circulated across IDC, Gartner, and vendor research since the mid-2010s and should be read as a rough, widely-repeated order-of-magnitude estimate rather than a precise measurement — still put structured data as the clear minority of all data generated, even though it remains the format most core business systems (accounting, inventory, CRM, transactional databases) are built around. That's because structured data's advantages — cheap to query, easy to validate, fast to aggregate — matter most for the specific, repeatable, high-volume operations that run a business day to day, which is exactly the use case relational databases were designed for starting with Edgar F. Codd's 1970 paper proposing the relational model, the foundational document behind the SQL databases still in widespread use today.
The rigidity that makes structured data fast and reliable is the same property that makes it a poor fit for data that doesn't naturally come in fixed rows and columns — free-text documents, images, audio, video, and sensor streams don't have a stable, predefined set of fields, which is why those formats are classified as unstructured data rather than forced into a structured schema that doesn't fit them. Forcing naturally irregular data into a rigid schema either discards information (truncating a variable-length free-text field to fit a fixed column width) or produces a schema with mostly-empty optional fields (a table with fifty possible product attributes where any given product only has five), both of which defeat the purpose of structuring the data in the first place.
Structured data's reliability depends entirely on constraints enforced at write time — primary keys preventing duplicate records, foreign keys enforcing valid relationships between tables, NOT NULL constraints preventing required fields from being left empty, and type constraints rejecting malformed values — and these constraints are what distinguish genuinely structured data from data that merely looks tabular. A CSV file with rows and columns looks structured but typically has none of these constraints enforced; nothing stops a date column from containing a typo'd string or a required field from being blank in row 4,000, which is why CSV is more accurately described as semi-structured in practice despite its superficially tabular appearance — the real test of "structured" isn't the visual shape of the data but whether a schema is actually being enforced against it.
Read structured data as data that paid an upfront cost — designing and enforcing a fixed schema before any data was collected — in exchange for speed and reliability later: Codd's 1970 relational model is the theoretical foundation that made this tradeoff practical at scale, the tradeoff pays off precisely for the repeatable, high-volume operations core business systems run, and the same rigidity that makes structured data fast to query is exactly why it can't accommodate the free-text, media, and sensor data that make up the large majority of data organizations actually generate.