Classifying Structured, Semi-Structured, and Unstructured Data

Structure describes form, not importance

The terms from the previous lesson answer questions such as, “Is this a business report, a source fact, or metadata about an asset?” The terms in this lesson answer a different question:

How predictably is this information organized for people and systems to process?

For example:

• A customer’s CustomerID, name, and account status stored in fixed database columns are structured data.
• The same customer represented as a JSON document with optional fields and nested addresses is usually semi-structured data.
• A customer’s free-text complaint email or a recorded support call is unstructured data.

None of these categories says whether the asset is more valuable, accurate, sensitive, or well governed. A spreadsheet can contain confidential payroll information; a video can be an essential safety record. Structure is about format and organization, not business importance.

It is also useful to separate structure from other classifications:

• Data can be quantitative or qualitative, and either may be structured, semi-structured, or unstructured.
• Metadata is often structured—for example, catalog fields for owner, source, classification, and refresh date—but it can also describe an unstructured file.
• One business object can exist in several forms. An order might begin as a structured transaction in an application database, be sent as a semi-structured JSON API message, and later appear in an unstructured PDF invoice.

The short DP-900-oriented explanation below establishes the three categories using an e-commerce example. It is useful preparation for later Azure data-storage and database decisions.

The three classifications

A schema is an agreed blueprint for data: the expected fields, their meanings, and often their allowed data types or values. For example, a customer table might require every record to have:

The more consistently an asset follows a known schema, the more structured it is.

Structured data

Structured data follows a fixed, predictable model. Each record has the same fields, normally organized in rows and columns. A relational database table is the classic example: each row represents one occurrence of something, such as one order or one employee, and each column represents a defined attribute.

Typical examples include:

• customer, product, employee, and order tables;
• inventory balances;
• financial ledger entries;
• a carefully maintained spreadsheet with one row per transaction and consistent columns;
• coded survey responses, such as a field that allows only Yes or No.

Structured data is especially suitable for filtering, aggregating, comparing, and reporting. If an operations manager asks, “How many orders were late in March, grouped by warehouse?” a well-structured order dataset can answer that question efficiently.

Semi-structured data

Semi-structured data has recognizable internal organization, but does not require every record to fit one rigid table schema. It often uses labels, tags, key-value pairs, delimiters, or nested sections to show what a value means.

JSON and XML are common examples. Consider these simplified order events:

{
  "eventType": "OrderPlaced",
  "orderId": "A-1042",
  "customerId": "C-10482",
  "items": [
    { "sku": "LAMP-18", "quantity": 2 }
  ]
}

{
  "eventType": "OrderDelayed",
  "orderId": "A-1042",
  "delayReason": "Weather disruption",
  "revisedDeliveryDate": "2026-03-18"
}

Both records have meaningful labels, such as eventType and orderId. But the second event has fields that do not appear in the first. The first event has a nested list of items. This flexibility makes JSON useful for APIs, web applications, event messages, and integration between systems.

Semi-structured does not mean “messy.” It means that the organization is present, but is more flexible than a fixed relational table.

Unstructured data

Unstructured data does not have a predefined data model that reliably separates its meaningful content into consistent fields. It is often designed primarily for human interpretation rather than direct querying as a table.

Common examples include:

• free-text emails and chat messages;
• Word documents, PDFs, policies, contracts, and meeting notes;
• photographs, scans, diagrams, and satellite images;
• audio recordings and videos;
• social-media posts;
• open-ended survey comments.

A PDF contract may look highly organized to a person: it can have headings, paragraphs, page numbers, and signature blocks. But the legal clauses are generally not stored as reusable fields such as ContractTermMonths or TerminationNoticeDays. A system must first extract or interpret the text before it can reliably analyze those concepts at scale.

The comparison below is worth reading because it emphasizes the key architectural point: a format’s classification affects how directly it can be queried and processed.

A reliable classification method

When you encounter an information asset, do not classify it solely from its filename or software product. Instead, inspect how its meaningful content is represented.

Use this sequence:

1. Look for a fixed schema.
   Do all records have the same expected fields, in the same arrangement? Are values expected to follow stated types or rules? If yes, classify it as structured.

2. Look for machine-readable labels or flexible organization.
   Does the asset use JSON keys, XML tags, delimiters, headers, or nested sections? Can different records contain different fields? If yes, it is usually semi-structured.

3. Look for free-form content.
   Is most of the meaning contained in prose, pixels, sound, or video rather than predictable fields? If yes, classify it as unstructured.

4. Classify the relevant unit, not just the container.
   An email, a workbook, or a PDF can contain components with different structures. State which component you mean.

This can be summarized as a practical decision rule:

Important edge cases

Real enterprise assets are often mixed, so a good classification includes a short rationale rather than only a label.

CSV files: A CSV has rows, columns, and delimiters, so it is far more organized than a PDF or video. Yet a CSV file may not enforce data types, required fields, unique identifiers, or relationships between tables. In this course, treat an exchanged CSV file as semi-structured unless it is loaded into and governed as a fixed-schema table. Once the same rows are loaded into a database table with defined columns and validation rules, the resulting table is structured.

Emails: An email is a composite asset:

• sender, recipient, timestamp, and subject are usually structured metadata;
• the email body is usually unstructured free text;
• an attached JSON file may be semi-structured;
• an attached spreadsheet table may be structured.

Documents with headings: Headings and sections give a document some visible organization, but a policy document remains primarily unstructured if its meaningful content is free-form language. It should not be treated as a relational table simply because it has a table of contents.

Scanned forms: A scan of a completed application form is an unstructured image or PDF, even if a human can see boxes for name, address, and date of birth. Optical character recognition or document extraction can create structured fields from it, but that is a transformation. The original scan remains unstructured.

JSON with identical fields: A JSON dataset may happen to have the same keys in every object. It is still commonly described as semi-structured because its structure is embedded in flexible documents rather than enforced in a relational table. In architecture work, note both the conventional label and the actual consistency of the records.

An enterprise example: retail order fulfillment

Consider a retailer trying to improve late deliveries. The following inventory contains assets from the same business area but in very different forms.

The purpose of the asset does not decide its category. A customer complaint email and a delivery-status table both relate to order fulfillment. The difference is the consistency of their internal organization.

This distinction matters because an architect might design different handling approaches:

• A structured order table can support direct reporting on delivery performance.
• Semi-structured API messages may need parsing and validation before they are loaded into a common data model.
• Unstructured complaint emails may require classification, search indexing, text extraction, or human review before their themes can be analyzed.

Later modules will explore the Azure services and integration patterns used for these tasks. For now, focus on the classification logic before selecting technology.

Structure and governance work together

It would be a mistake to assume that only structured data needs governance. Every category needs clear ownership, security handling, retention, quality expectations, and useful metadata.

The governance emphasis changes somewhat by structure:

For example, a contract PDF might need a sensitivity label, legal retention rule, business owner, and searchable title even though the document is unstructured. Those catalog details are metadata—connecting directly to the previous lesson.

A helpful working habit is to record an asset classification with its rationale in one sentence:

“The source is semi-structured because each API event uses JSON keys and nested objects, but optional fields vary by event type.”

That explanation is more useful than simply writing “JSON = semi-structured.” It demonstrates that you can inspect the asset rather than memorize examples, which is an important skill for entry-level architecture and governance work.

Key takeaways

• Structured data follows a fixed schema, commonly through rows and columns in a relational database or consistently governed table.
• Semi-structured data contains machine-readable organization—such as JSON keys, XML tags, headers, or delimiters—without requiring one rigid schema for every record.
• Unstructured data holds its meaning mainly in free text, documents, images, audio, video, or other content without predictable fields.
• The same business object can appear in several structures as it moves between applications, files, APIs, reports, and documents.
• Classify the relevant component of an asset: email headers and email bodies, for example, are not structured in the same way.
• Structure does not indicate value, sensitivity, quality, or governance need. All three categories require metadata and responsible management.

Next, you will follow an information asset through its lifecycle: creation, use, retention, archival, and disposal. That lifecycle view will add a time dimension to the classification skills developed here.