Keyboard Shortcuts N Next post
P Previous post
S Save / unsave
R Read aloud
T Toggle theme
/ Focus search
Esc Close panels
🔥
Ready to read...
Data Analytics Course data fundamentals Phase 1 — Understanding Data structured data

Rows, Columns, Records, and Variables — The Building Blocks

Reviewed & accurate
AI Summary

What You Will Learn

  • The vocabulary used to describe a table of data
  • Why different fields (Excel, SQL, statistics) use different words for the same thing
  • How to read any table confidently using the right terms

Why This Topic Matters

Every later lesson in this course assumes you can read a table and point to "a row" or "a column" without hesitation. Search results, documentation, and co-workers will use these words interchangeably. If you do not have them straight, simple instructions will sound confusing.

The Simple Idea

Structured data lives in tables. A table has rows going across and columns going down. Different professions call these by different names, but the underlying idea is the same everywhere.

The Same Table, Three Vocabularies

Here is one small table. We will use it to anchor every term:

order_idcustomercityamount
001AnitaMumbai500
002RaviChennai1200
003MiraKolkata750

Spreadsheet vocabulary (Excel, Google Sheets)

  • Row: a horizontal line of data (one order)
  • Column: a vertical line of data (all the cities, all the amounts)
  • Cell: the intersection of a row and a column (the value "Mumbai")
  • Header row: the first row, which labels each column

Database vocabulary (SQL)

  • Table: the whole thing
  • Row = record: one order
  • Column = field: one kind of information across all records

Statistics vocabulary

  • Observation: one row (one entity you measured)
  • Variable: one column (one thing you measured about each entity)

The Translation Table

SpreadsheetDatabase (SQL)StatisticsMeaning
TableTableDatasetThe whole grid
RowRecord / RowObservationOne entity (one order, one customer)
ColumnField / ColumnVariableOne kind of info across all rows
CellValueDatumA single value at row + column
HeaderColumn nameVariable nameThe label of a column

When you read SQL documentation and it says "aggregates records by the city field", that is the same as saying "groups rows by the city column" in spreadsheet terms. Same idea, different word.

Why Different Fields Use Different Words

Because the fields grew up separately. Spreadsheets were designed for accountants. Databases were designed for software engineers. Statistics was designed for scientists. Each chose words that fit their own context, and now analysts need all three vocabularies.

The good news: once you internalize the translation table above, you can read any documentation in any of the three fields.

How to Read a Table Like an Analyst

When you see a new table, ask these questions in order:

  1. What is one row? (One order? One customer? One day?)
  2. What is one column? (A property of that row — the order's amount, the customer's city.)
  3. What does each cell mean? (A single fact about one row, for one column.)
  4. Is the header row clear? (If a column is called "x1" you cannot analyze it; rename it.)

Worked example

Look again at the small table above. One row = one order. Columns describe that order: its ID, customer, city, and amount. Each cell is a single fact (e.g., order 002 was placed by Ravi, who lives in Chennai, for ₹1200).

Common Mistakes

  1. Confusing rows and columns when filtering. Beginners often say "filter the row called city" when they mean "filter the column called city". The right phrasing: filter rows based on the value in a column.
  2. Using the header row as data. If you accidentally treat the header as the first data row, every calculation will be wrong. Always check the first row of any dataset.
  3. Mixing entities in one table. If one row is "an order" and another row is "a customer", you cannot analyze the table. Each row must be the same kind of entity.
  4. Naming columns ambiguously. A column called value could mean anything. Rename it to order_amount_inr so the meaning is unambiguous.

Practical Exercise (5 minutes)

Open a spreadsheet — any one will do. For the first sheet you see, write down:

  1. What one row represents (e.g., "one transaction", "one student")
  2. The names of all columns
  3. For each column, what kind of value it holds (refer back to lesson 03 — qualitative or quantitative)

If you cannot answer question 1 in one sentence, the table is poorly designed and that is itself a useful finding.

Mini Challenge

Take a single YouTube video page. Imagine turning it into a table where one row = one video. List at least 8 columns you would include. Then ask: if instead one row = one comment on the video, would the columns change? (Yes — they would. This is why picking the unit of analysis matters before designing a table.)

Key Takeaways

  • Spreadsheet "row/column", database "record/field", and statistics "observation/variable" describe the same idea.
  • One row = one entity (one order, one customer, one event).
  • One column = one property measured for every row.
  • Always ask "what does one row represent?" before analyzing any table.
Course continuity
Previously learned: Lessons 01, 02, 03 covered what data is, its shape, and its type.
Today: You learned the shared vocabulary for talking about a table.
Next: In lesson 05 — Data Types Every Analyst Must Know, you will go one level deeper and learn the storage-level types (integer, text, date, boolean) that databases and programming languages use.
Test Your Knowledge
How did you find this?

Comments

Join the discussion! Sign in with your Google or Blogger account, or comment as Anonymous - no account needed. For quick questions, also reach me on Telegram @cytestch.

Comments