Data consists of recorded facts, observations, measurements, symbols, text, images, and other representations that can be interpreted to produce information.

Data is not necessarily unorganized. Some datasets follow strict schemas, while others have flexible structures or no predefined model suitable for conventional tables. One of the most common ways to classify data is therefore according to its structure.

The three major categories are:

1. Structured data
2. Semi-structured data
3. Unstructured data

This classification helps data engineers determine how data should be stored, processed, queried, governed, and analyzed.

What Determines the Structure of Data?

Data structure describes how consistently a dataset is organized and whether it follows a predefined model.

The classification is based on questions such as:

• Does every record contain the same fields?
• Are the data types defined in advance?
• Can the data be represented naturally as rows and columns?
• Does the data contain tags, keys, or metadata?
• Is specialized processing required to interpret its primary content?

The boundaries are not always absolute. A source can contain more than one type of data, and its classification may depend on which part is being analyzed.

Structured Data

Structured data follows a predefined schema or data model.

It is commonly organized into tables in which:

• Each row represents a record.
• Each column represents an attribute.
• Each field has an expected data type.
• Relationships and constraints may be defined in advance.

For example, a customer table might look like this:

Every record follows the same schema. The Customer ID column contains an identifier, while Registration Date contains a date.

Characteristics of Structured Data

Structured data generally has:

• A predefined schema
• Consistent field names
• Defined data types
• Predictable relationships
• Standard validation rules
• Straightforward query capabilities

Because its structure is explicit, structured data is relatively easy to filter, sort, aggregate, join, and validate.

Common Sources of Structured Data

Structured data may originate from:

• Relational databases
• Transaction-processing systems
• Spreadsheets
• Online forms
• Customer relationship management systems
• Enterprise resource planning systems
• Financial applications
• Inventory systems
• GPS measurements
• RFID systems
• Properly standardized sensor records

The source alone does not guarantee structure. For example, a spreadsheet may contain a well-designed table, but it may also contain notes, merged cells, and several unrelated layouts.

Relational Databases

Relational databases are among the most common repositories for structured data.

Examples include:

• PostgreSQL
• MySQL
• Microsoft SQL Server
• Oracle Database
• IBM Db2

They organize information into related tables and commonly use SQL for data definition, retrieval, and manipulation.

OLTP Systems

Online Transaction Processing systems record frequent operational transactions.

Examples include:

• Bank transfers
• ATM withdrawals
• Online purchases
• Airline reservations
• Inventory changes
• Customer account updates

OLTP data is typically structured because transactions must follow well-defined rules. However, modern operational applications may also use non-relational databases.

Advantages of Structured Data

Structured data offers several benefits:

• Easy querying with SQL
• Strong validation
• Efficient aggregation
• Clearly defined relationships
• Compatibility with standard analytical tools
• Easier enforcement of constraints
• Predictable application behavior

Limitations of Structured Data

A rigid schema may also create limitations:

• Schema changes can require careful migration.
• Irregular records may not fit easily.
• Complex documents may require many related tables.
• Images, audio, and free-form text cannot be represented naturally as ordinary fields.

Structured systems work best when the information has stable and clearly defined attributes.

Semi-Structured Data

Semi-structured data has recognizable organizational properties but does not conform to a fixed tabular schema.

Instead of relying entirely on rows and columns, it commonly uses:

• Keys
• Tags
• Attributes
• Delimiters
• Nested objects
• Metadata
• Hierarchical relationships

Different records may contain different fields while still following a recognizable overall format.

JSON Example

Consider the following JSON records:

{
  "customer_id": 1001,
  "name": "Mina Park",
  "email": "mina@example.com"
}

{
  "customer_id": 1002,
  "name": "Daniel Smith",
  "phone": "+1-555-0102",
  "preferences": {
    "language": "English",
    "notifications": true
  }
}

Both documents describe customers, but they do not contain exactly the same fields. The second document also contains a nested object.

This flexibility is characteristic of semi-structured data.

XML Example

XML uses tags and attributes to describe content:

<customer id="1001">
    <name>Mina Park</name>
    <state>Arizona</state>
</customer>

The tags communicate the meaning and hierarchy of the values without requiring the document to be stored as a conventional table.

Characteristics of Semi-Structured Data

Semi-structured data commonly has:

• A flexible or evolving schema
• Tags, keys, or metadata
• Nested or hierarchical structures
• Records with varying fields
• Machine-readable organization
• Less rigid validation than traditional relational tables

It is often described as self-describing because structural information appears within the data itself.

Common Sources of Semi-Structured Data

Examples include:

• JSON documents
• XML documents
• API responses
• Application events
• Email headers and metadata
• Web and application logs
• Network packets
• Configuration files
• Message-queue events
• Data exchanged between systems

Some examples require qualification. An email contains structured header fields but usually has an unstructured message body. A compressed ZIP file is a container that may hold structured, semi-structured, or unstructured files; it is not itself a structural category.

Storage for Semi-Structured Data

Semi-structured data may be stored in:

• Document databases
• NoSQL databases
• Object storage
• Data lakes
• Search platforms
• Streaming platforms
• Relational databases with JSON or XML support

Examples of document-oriented databases include MongoDB and Couchbase.

Querying Semi-Structured Data

Semi-structured information can be accessed with:

• Document-database query languages
• JSON path expressions
• XPath or XQuery for XML
• SQL extensions for JSON and XML
• Search and indexing tools
• Programming languages such as Python

Before analysis, nested documents are sometimes flattened into tables. However, flattening can remove useful hierarchy if it is performed without understanding the data.

Advantages of Semi-Structured Data

Semi-structured data provides:

• Schema flexibility
• Support for nested information
• Easier integration with web APIs
• Accommodation of varying records
• Convenient exchange between applications
• Faster adaptation to some changing requirements

Limitations of Semi-Structured Data

Its flexibility can also create challenges:

• Records may contain inconsistent fields.
• Data types may vary unexpectedly.
• Deep nesting can complicate queries.
• Validation may be less standardized.
• Schema changes may occur without notice.
• Integrating data from different producers can be difficult.

Semi-structured does not mean that governance and schema management are unnecessary. Production systems still benefit from documented contracts and validation rules.

Unstructured Data

Unstructured data lacks a predefined schema that represents its primary content in conventional rows and columns.

Examples include:

• Free-form text
• Images
• Audio
• Video
• Social media posts
• Documents
• Presentations
• Scanned records
• Customer conversations

Unstructured data may still contain metadata. An image can have a creation date, file type, dimensions, and location. These attributes are structured, even though the visual content of the image is unstructured.

Common Sources of Unstructured Data

Unstructured data may come from:

• Web pages
• Social media feeds
• Word-processing documents
• PDF documents
• Presentations
• Images such as JPEG, PNG, and GIF files
• Video recordings
• Audio recordings
• Call-center conversations
• Open-ended survey responses
• Media and communication archives

A web page is often a combination of structures. Its HTML markup is semi-structured, while its written content and embedded media may be treated as unstructured.

Storing Unstructured Data

Unstructured content is commonly stored in:

• File systems
• Object storage
• Data lakes
• Content-management systems
• Document-management systems
• Search indexes
• Specialized media repositories

Some NoSQL databases can store documents or metadata associated with unstructured content. However, large media files are frequently stored in object storage, with their identifiers and metadata maintained in a database.

Analyzing Unstructured Data

Unstructured data requires methods capable of interpreting its content.

Text analysis

Free-form text may be analyzed using:

• Keyword extraction
• Sentiment analysis
• Topic modeling
• Classification
• Named-entity recognition
• Semantic search
• Large language models

Image analysis

Images may be analyzed through:

• Object detection
• Image classification
• Facial recognition
• Optical character recognition
• Image segmentation

Audio analysis

Audio processing may include:

• Speech recognition
• Speaker identification
• Sound classification
• Sentiment or emotion analysis

Video analysis

Video analysis may combine:

• Image processing
• Object tracking
• Action recognition
• Speech transcription
• Scene detection

These tasks often use machine learning or deep learning.

Advantages of Unstructured Data

Unstructured data can preserve rich contextual information that structured tables cannot capture easily.

It can provide insight into:

• Customer opinions
• Product experiences
• Visual conditions
• Spoken interactions
• Social behavior
• Document contents
• Media engagement

Limitations of Unstructured Data

Challenges include:

• Larger storage requirements
• More complex processing
• Difficult searching without metadata or indexing
• Inconsistent quality
• Privacy and copyright concerns
• Expensive model training or inference
• Difficulty validating extracted information

Unstructured data can be extremely valuable, but converting its contents into analyzable features usually requires additional processing.

Comparing the Three Categories

The Categories Can Overlap

Real-world datasets do not always fit neatly into one category.

Email

An email may contain:

• Structured sender and timestamp fields
• Semi-structured headers
• An unstructured message body
• Unstructured attachments

Web Page

A web page may contain:

• Semi-structured HTML
• Unstructured written content
• Structured product metadata
• Unstructured images and video

PDF

A PDF may contain:

• Document metadata
• Structured form fields
• Tabular information
• Free-form text
• Scanned images

Describing a PDF as unstructured is often convenient, but its actual content may contain several forms of organization.

Sensor Data

Sensor readings are frequently structured as timestamped measurements. Their surrounding event messages may be semi-structured, while associated audio or images may be unstructured.

Classification should therefore be based on the specific content and intended processing method—not merely the name of the source or file type.

How Data Type Influences Engineering Decisions

The structure of data affects several architectural choices.

Storage

Structured records may fit naturally into relational databases. Flexible documents may be better suited to document stores, while large media files may belong in object storage.

Processing

Structured data can often be transformed directly with SQL. Semi-structured data may require parsing and flattening. Unstructured content may require specialized extraction or machine-learning models.

Validation

Structured data can use strict constraints. Semi-structured data may use schema contracts. Unstructured data may require validation of file formats, metadata, dimensions, or content characteristics.

Search

Structured data supports field-based queries. Semi-structured records can be searched through keys and paths. Unstructured content often requires full-text indexing, embeddings, or extracted metadata.

Governance

Sensitive information may appear in any category. An image, document, JSON response, or database table can all contain private data. Governance must therefore consider content, not just format.

Transforming Data Between Categories

Data may move from one structural category to another during processing.

From unstructured to structured

A receipt image can be processed with optical character recognition to extract:

• Merchant
• Date
• Items
• Prices
• Total amount

The extracted fields can then be stored in a structured table.

From semi-structured to structured

Nested JSON events may be flattened into rows and columns for analytical queries.

From structured to semi-structured

Application data from several relational tables may be assembled into a JSON document for delivery through an API.

The classifications describe representations, not permanent properties. Data engineers frequently transform information into the structure most appropriate for a particular use.

Choosing the Right Storage Approach

Selecting a storage system requires more than matching one data category to one database type.

Data engineers should consider:

• How the data will be accessed
• Whether records are frequently updated
• How quickly the volume will grow
• Whether transactions are required
• How complex the relationships are
• Whether the schema changes frequently
• How long the data must be retained
• What security controls are required
• Whether full-text or semantic search is needed
• How much the system will cost to operate

The same data may be stored in more than one form. An organization might retain raw JSON events in a data lake while loading selected fields into a warehouse for reporting.

Practical Example

Suppose an online retailer collects information from its website.

Structured data

• Customer accounts
• Product prices
• Orders
• Payment records
• Inventory quantities

Semi-structured data

• JSON website events
• API responses
• Application logs
• Product attributes with varying fields

Unstructured data

• Product images
• Customer reviews
• Support conversations
• Promotional videos

The data engineering platform may:

1. Store transactions in a relational database.
2. Stream JSON events to a data lake.
3. Store images and videos in object storage.
4. Extract review sentiment with a language model.
5. Load curated sales and engagement metrics into a warehouse.

A single business application can therefore generate and use all three categories.

Key Takeaways

• Data can be classified as structured, semi-structured, or unstructured.
• Structured data follows a predefined schema and is commonly represented in tables.
• Semi-structured data uses keys, tags, metadata, or hierarchies without requiring a rigid tabular schema.
• Unstructured data lacks a predefined model for its primary content.
• JSON and XML are common semi-structured formats.
• Text, images, audio, video, and many documents are commonly treated as unstructured.
• Data sources and file formats can contain more than one structural category.
• Data structure influences storage, processing, validation, querying, and governance.
• Data can be transformed from one structural category into another.
• The correct repository depends on the workload and access requirements—not only the data category.

Conclusion

Structured, semi-structured, and unstructured data require different approaches, but all three are essential within modern data platforms.

Structured data offers consistency and direct querying. Semi-structured data provides flexibility while retaining machine-readable organization. Unstructured data preserves rich information that often requires specialized processing to interpret.

Understanding these distinctions helps data engineers choose appropriate formats, repositories, validation methods, and analytical tools.

One-sentence summary: Structured data follows a fixed schema, semi-structured data uses flexible organizational markers, and unstructured data requires specialized methods to interpret its primary content.