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 represents one customer and contains that customer's attribute values; a column defines one attribute across customers. Neither axis represents a separate data store, an entire schema, or an unrelated binary file.

A primary key identifies one instance, and another table can use its value to reference that instance. The key does not fold an entire table 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 varying number of values does not by itself make data semi-structured. A relational schema can hold no email address, one, or several in a related table, while a semi-structured document can carry them in a self-describing array inside the record. The distinguishing feature is flexible record shape, not cardinality alone.

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

Read the middle rows as the test. If instances share an organization but their fields are allowed to differ, the data is semi-structured. A varying count of related values alone does not settle the classification.

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 and illustrate a flexible shape. JSON can also hold structured data, when a fixed schema requires every document to carry the same fields. So classify the data by how its instances are organized and allowed to vary, not by the file format alone.

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 shared predefined data model is the deciding feature, not the file size, medium, or whether an application can open it. Native images, audio, video, and binary documents are common unstructured examples when their contents do not follow such a model.

Setting the extremes side by side sharpens the contrast.

The common mistake is to swap 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 add fields, with no single fixed schema enforced on all of them. One record carries a name and an age, and the next one drops the age and adds a hobby. Repeated related values alone are not sufficient, because a fixed relational schema can model them in child rows.

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, which 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 their fields are free to vary between instances.
• 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, in rows and columns: this is structured. Keys identify instances and can link related tables; they do not let fields vary.

A customer export preserves address and contact sections, but no single schema is enforced and the records are allowed to differ: some addresses include a unit field, and some contact collections hold one email while others hold both phone and email. Organization survives while each record is free to take its own shape: this is semi-structured. Read the second half of that sentence carefully. The records keep a recognizable organization while their fields vary between instances, and that combination is the semi-structured test.

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 each instance is free to take its own shape; 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.