Data Representation Types

Facts, entities, and attributes

Data is a collection of facts — numbers, descriptions, and observations that record information. On its own a fact is inert; it becomes useful once it is organized.

Data structures usually organize facts around entities, the things an organization cares about: customers, products, sales orders. An entity typically has one or more attributes that describe it. A customer's name, address, and phone number are attributes of that customer.

Everything in this concept turns on one question: how consistently do the instances of an entity organize those attributes? Answer that and you have the representation type. The subject of the data — customers, products, anything — does not decide it.

Structured data has a fixed schema

Structured data adheres to a fixed schema. That single sentence contains the whole test: because the schema is fixed, every instance has the same fields or properties. No instance can quietly add one, and none can leave one out of the definition.

Its most common schema is tabular. Data is arranged in a table, and the table is what most people picture when they hear "structured".

Structured data is often stored in a database. In a relational model, multiple tables can reference one another through key values — a sales order table can point at the customer table instead of repeating the customer's details in every row.

Those keys are a convenience of the model, not a loosening of it. The defining feature for classification remains the fixed schema shared by all instances.

A worked example makes the rule concrete. A customer table places one customer in each row and keeps attributes such as name and address in columns.

Every row carries the same four attributes. If one customer had no phone number, the column would still exist for that row — the schema does not change to suit an instance. That is exactly what stops being true when data is semi-structured.

Read the tabular schema correctly

In a table, the two axes have fixed meanings, and swapping them is a common slip.

So a row is a whole customer and a column is one property shared by all of them. Rows do not hold attributes, columns do not hold separate data stores, and neither axis holds a schema or an unrelated binary file.

Key values are the third element: they reference an instance in another table so that related tables can be joined. A key value is a link to an entity, not an entire table folded into a column.

Semi-structured data permits variation

Semi-structured data has some structure but permits variation between entity instances. Both halves matter. There is a recognizable organization — the instances are clearly the same kind of thing — and yet instances need not carry exactly the same fields.

The classic illustration is contact details. Most customers might have one email address, another customer might have several, and another might have none at all.

A fixed schema cannot express that without waste or loss: it would need an Email2 and Email3 column that stay empty for nearly everyone. A semi-structured representation simply lets one record carry more email entries than another while both remain customer records.

So the difference from structured data is not the absence of organization. It is where the organization stops.

Read the middle two rows as the test. If instances share an organization but may omit or repeat selected fields, the data is semi-structured.

JSON is the common semi-structured format

JavaScript Object Notation, or JSON, is a common format for semi-structured data. It stores records as documents rather than rows, so each document carries its own field names.

JSON customer documents can all contain address and contact information while their specific fields differ. One address can include a unit field while another does not. One contact collection can contain both phone and email entries while another contains only an email.

{ "name": "A. Ferrer",
  "address": { "street": "12 Main St", "unit": "4B" },
  "contact": [ { "phone": "555-0101" }, { "email": "af@example.com" } ] }

{ "name": "B. Okafor",
  "address": { "street": "8 Park Ave" },
  "contact": [ { "email": "bo@example.com" } ] }

Both are recognizably customer documents; neither could sit in the other's fixed schema without change. That combination of recognizable organization and instance-level variation is the central semi-structured pattern.

Unstructured data has no specific structure

Unstructured data does not have a specific structure. Documents, images, audio, video, and binary files can all belong to this category.

Unlike a fixed-schema table, their contents are not organized as the same fields or properties for every entity instance. A photograph has no Name column; an audio recording has no row. Whatever internal format the file uses, it does not present recurring attributes that could be compared across instances.

The absence of a specific structure is the deciding feature — not the file size, not the medium, not whether an application can open it. A collection made of native images, audio recordings, videos, and application-specific binary documents is therefore an unstructured collection.

Setting the extremes side by side sharpens the contrast.

The trap is to invert one half of that table. Media files do not require identical attribute columns, and a fixed-schema table is not free to omit a field for one instance. Each side is defined by exactly what the other lacks.

Turn a structured set into a semi-structured one

It helps to see the boundary as a change rather than a label. Start from records that all share one fixed schema, and ask what single change would make them semi-structured.

The answer is variation between instances while the organization survives: allowing individual records to omit or repeat selected fields. As soon as one record can carry two email entries and another none, the fixed schema is gone and the recognizable organization is not.

Two changes that do not do it are worth naming. Keeping identical fields for every record leaves the data structured, and so does putting every instance in a row with attributes in fixed columns — that is the tabular form of the same rule. Replacing the records with native media files overshoots the boundary entirely and lands on unstructured.

Classify by the shape, not by the subject

Do not classify a representation merely because it contains customer or product information. The same kind of entity can be represented under different structural rules, and the classification follows the rules.

Inspect how each instance is organized and choose accordingly:

• Structured when all instances follow the same fields or properties, commonly as rows and columns.
• Semi-structured when instances retain some organization but differ in their specific fields, or in how many values an attribute holds.
• Unstructured when the data has no specific structure, as with documents, images, audio, video, and binary files.

Two scenarios show the rule doing real work.

A sales system requires every product instance to have the same properties, places each product in one row with each attribute in a column, and uses key values to reference related tables. Same properties for every instance plus rows and columns: this is structured, and the related tables change nothing — keys link instances, they do not let fields vary.

A customer export preserves address and contact sections, but some addresses include a unit field and some contact collections hold one email while others hold both phone and email. Organization survives, fields and value counts vary: this is semi-structured. One optional field does not remove all organization, and shared sections do not guarantee identical fields.

Key takeaways

• Structured data uses a fixed schema, so every instance carries the same fields or properties — most commonly as a table with rows for entity instances and columns for attributes.
• Semi-structured data keeps some organization while letting fields vary between instances, including how many values an attribute holds; JSON is the common format for it.
• Unstructured data has no specific structure, and includes documents, images, audio, video, and binary files.
• Classify by inspecting the instances, not by the entity the data happens to describe. Customers can be represented all three ways.