Can a table contain text or images?

It can contain text, references to images or more complex cell values, although many models require further transformation.

Is a CSV file the same as tabular data?

CSV is one file format for representing tables; tabular data also appear in databases, spreadsheets and other formats.

Does adding more columns always help a model?

No. Extra columns can add noise, leakage, redundancy or information unavailable when predictions are made.

AI Glossary / Mathematics and optimization / Beginner

Tabular data

Definition

Tabular data organize observations into rows and shared attributes into columns. Each cell records a value for a particular observation and attribute, making the structure useful for storage, comparison, analysis and many machine-learning tasks.

What it means

A customer table might have one row per customer and columns for region, account age and service plan. A transaction table might instead have one row per purchase. Defining what one row represents is essential: two tables can look similar while describing different units of analysis.

Columns can contain numerical values, categories, dates, text or missing-value markers. A table is therefore not necessarily a numerical matrix ready for a model. Encoding and interpretation are often needed first.

A rectangular layout does not guarantee quality. Duplicate records, inconsistent units, mixed meanings and unavailable-at-prediction-time values can all fit neatly into rows and columns. The table's schema and provenance matter as much as its appearance.

How it works

Start by defining the row unit, column meanings and data types. Identify keys that distinguish records and explain how tables relate. A customer identifier can connect tables, but it is not automatically an appropriate predictive feature.

Validate values against their definitions: dates should have a clear time zone or calendar convention where relevant, measurements need units and categories need consistent labels. Treat missing values according to their meaning rather than silently replacing every absence with zero.

For supervised learning, separate prediction inputs from the target and from administrative columns. Determine when each value became available. A field recorded after the predicted event can leak the answer into training.

When joining tables, check relationship cardinality. A one-to-many join can legitimately create several rows per original observation, changing counts and weights. Aggregation may be needed before the resulting table matches the intended learning unit.

Three practical examples

A retailer analyzes one row per transaction to study basket values and purchase timing.
A maintenance model uses one row per equipment inspection, with measurements and a later outcome kept in distinct roles.
A service team creates one row per support ticket, combining numerical fields, categories and a text description.

Think of it this way

Think of a set of standardized forms stacked together: each form becomes a row, and each consistently named question becomes a column.

The analogy explains shared structure. Real tables can include linked records, repeated observations and missing answers, and putting information in the same column does not ensure that everyone interpreted the question consistently.

Worked example

A join changes the unit of analysis

An orders table has three rows: order A has total 30, order B has total 40 and order C has total 50. The correct average order total is (30 + 40 + 50)/3 = 40.

A separate items table contains two item rows for order A, one for B and three for C. Joining orders to items produces six rows. The order totals now appear as 30, 30, 40, 50, 50 and 50.

A naive average of that joined total column is 250/6, approximately 41.67. It is not the average order total; orders with more items receive more weight. The join has changed the row unit from order to order-item combination.

To answer the original question, retain one record per order or aggregate item information to order level before joining. If the task instead concerns items, six rows may be appropriate, but the interpretation must change. A technically successful join can therefore produce a misleading analysis when row meaning is ignored.

Illustrative case study

A fictional subscription business prepares a churn dataset from account and support-ticket tables. Accounts with many tickets appear repeatedly after a join, while accounts with no ticket are accidentally omitted by an inner join.

The team returns to its intended unit: one account at a defined prediction date. It summarizes prior ticket activity, preserves accounts with no tickets and separates future cancellation information from available input features.

It then checks account counts and date boundaries before training. The lesson is that preparing tabular data is a modeling decision, not just file conversion. A clean-looking table can encode selection bias or leakage unless its rows and time references are deliberate.

Common misconceptions and mistakes

Every table row is an independent observation. Repeated customers, devices or time periods can create dependence.
Numerical-looking identifiers are quantities. Their digits may carry no arithmetic meaning.
A blank cell means zero. It may mean unknown, not applicable or not yet collected.
A successful join preserves the original row count. One-to-many relationships can multiply rows.
Tabular data are automatically model-ready. Types, timing, encoding and target separation still require work.

Business use

Tabular data are common in business because operational systems naturally record customers, events and transactions. Useful AI work starts with a data dictionary that defines the row unit, keys, units, allowed values and availability times.

Review transformations by checking counts, key uniqueness and representative records before and after each step. Keep preprocessing fitted only where appropriate within the training workflow. When evaluating a model, split data in a way that respects repeated entities and chronology. These practices connect the table's technical structure to the question the organization actually needs answered.

Check your understanding

Why did the joined orders table produce an average of about 41.67 instead of 40?

Answer: Orders were repeated according to their item counts. The calculation weighted orders with more items more heavily instead of averaging one value per order.

Related terms

Learn next

Read data leakage and feature engineering. Choose a business prediction task and write a one-sentence definition of one row. Then label every column as an input, target, identifier or administrative field and record when it becomes available.

Sources

Aalto Dictionary of Machine Learning, tabular data: https://aaltodictionaryofml.github.io/ADictML_Main.pdf. Common-attribute and row/column definition.

W3C, Model for Tabular Data and Metadata on the Web: https://www.w3.org/TR/tabular-data-model/. Structural model for tables and metadata. The order calculation and fictional account-preparation case are original examples.

Previous: Tabu search Next: Tabular Q-learning