Lesson 1.1: What data is, in rows, columns and types

Learn to read any table of data: what a row, a column and a data type are, and the one question to ask before you touch a single number.

By the end of this lesson you will be able to look at any table, from a bank statement to a sales sheet to an export from a government portal, and say exactly what it holds: what one row stands for, what each column measures, what kind of value sits in each, and what could be wrong before you trust a single total. You need nothing except a spreadsheet and a little curiosity. We will use one small table from a neighbourhood sweet shop throughout, so every number you see can be checked by hand.

This is the first lesson of the Data Science track for a reason. Almost every data mistake that reaches a meeting, a report or a loan decision was made here, in the first minute, when someone assumed they knew what the table meant and did not check. Learn to read a table slowly and the rest of data science gets easier.

Why this comes first

Imagine two analysts handed the same sheet of a company's monthly sales. The first one scrolls for a few seconds, spots a column called amount, adds it up and reports the total. The second one first asks what each row is, whether amount is in rupees or thousands of rupees, whether some rows are repeated, and whether the last row is a total that would be counted twice. The second analyst takes two extra minutes. The first can be wrong by a factor of two, and will not know it.

None of the mistakes in this lesson needs advanced mathematics. They need a habit: before you calculate, understand the table. The habit has three parts, and they give this lesson its shape.

Rows and columns: what one row is, and what each column says about it. Types: what kind of value each column holds, because the type decides what you may do with it. Grain: the single most important idea in the lesson, what one row stands for, and why counting rows is not always counting things.

Here is the sweet shop's table. It lists what the shop sold over two days, one line per item sold. Read it slowly, then we will take it apart. orderid · date · item · kg · priceperkg · paidby · customer101 · 2026-10-01 · Kaju katli · 2 · 900 · UPI · Meera 101 · 2026-10-01 · Barfi · 1 · 640 · UPI · Meera 102 · 2026-10-01 · Jalebi · 1 · 320 · Cash · Arjun 103 · 2026-10-02 · Kaju katli · 0.5 · 900 · UPI · Meera 104 · 2026-10-02 · Jalebi · 2 · 320 · Cash · Sana 104 · 2026-10-02 · Kaju katli · 1 · 900 · Cash · Sana ## A table is a list of things, described

A table is a list of things, with the same facts recorded about each one. Each row is one thing. Each column is one fact about every thing in the list. The very first line, the header, holds the names of the columns and is not data itself.

In the sweet shop table, one row is one item sold within one order. Order 101 appears twice because Meera bought two items, kaju katli and barfi, in one visit. The columns are facts about each item sold: the order it belonged to, the date, what it was, how many kilograms, the price per kilogram, how it was paid for and who bought it.

Where a row and a column meet there is a cell. The cell in the third row and the item column holds "Jalebi". A table with 6 rows and 7 columns has 42 cells. That count matters later, because many problems in real data live in individual cells: a blank, a typo, a number typed as text.

Predict first: how many rows does the sweet shop table have, and how many columns? Count before you read the next paragraph.

The answer is 6 rows and 7 columns. If you counted 7 rows, you included the header, which is the most common counting slip in the whole subject. The header names the columns; it is not a thing in the list. When a tool tells you a file has "10,000 rows", find out whether it counts the header. Most data tools do not, and most spreadsheet screens do.

A second habit worth building now: read the column names aloud as questions. kg asks "how many kilograms?", priceperkg asks "how much per kilogram?", paidby asks "how did they pay?". If you cannot turn a column name into a question, you do not yet understand the column, and you should find the person who made the table and ask. That conversation is part of the job, not a sign of weakness.

Every column has a type

A column holds one kind of value, and the kind decides what you can sensibly do with it. This is called the column's type. Five types cover almost everything you will meet. Type · Example in the table · What you can do with it · What goes wrongNumber · kg, priceperkg · Add, average, compare, multiply · Stored as text, so it will not add up Date or time · date · Sort, subtract (days between), group by month · Typed as text, or day and month swapped Category · item, paidby · Count, group, compare shares · Spelling variants ("UPI", "upi", "Upi") split one group into three Identifier · orderid · Look up, match across tables · Treated as a number and averaged True or false · (a column like isfestivalday) · Count, filter · Stored as "Y", "yes", 1 and "TRUE" in the same column ### Numbers

Numbers are the type people think of first. They come in two flavours that are worth telling apart. Whole numbers, such as the number of orders in a day, can only be whole. Decimals, such as 0.5 kg of kaju katli, can be fractions. Both can be added, averaged and compared, and multiplying kg by priceperkg gives the amount for that row. Before you do any of this, check the unit. If one shop records weight in kilograms and another in grams, a column named weight means different things in the two sheets, and combining them gives nonsense.

Dates and times

Dates look like text but behave like a different type altogether. A real date can be sorted into order, and one date can be subtracted from another to give a number of days. Dates also have a nasty ambiguity. The text 03/04/2026 means 3 April in India and in most of the world, and 4 March in the United States. A file exported from one system and read by another can quietly swap day and month for every date that has a day of 12 or below. The safest format for sharing is year, month, day, such as 2026-10-01, because it sorts correctly even as plain text and cannot be misread.

Categories

A category is a label that puts a row in a group: item and paidby are categories. You do not add categories; you count them and compare how often each appears. The classic problem is inconsistent spelling. If one person types "UPI", another types "upi" and a third types "U.P.I.", a tool will count three groups where there is one. Fixing this is called cleaning, and the first step is simply listing the distinct values in a column to see what is really in it.

Identifiers

An identifier names a thing rather than measuring it. orderid is an identifier. It looks like a number, which is exactly why it is dangerous: a spreadsheet will happily average the order numbers in our table and tell you the average order is 102.5. That figure is meaningless, because order 104 is not "more" of anything than order 101. Identifiers have one job, which is to point at one particular thing so it can be found or matched elsewhere. Aadhaar numbers, PAN numbers, account numbers, PIN codes and phone numbers are all identifiers, even though they are made of digits. Store them as text, so a leading zero is not dropped and nobody can accidentally add them up.

True or false

Some columns hold only yes or no: was the order a delivery, was the payment successful, was the customer new. These are simple to work with once they are consistent, and a real mess if the same column holds "Y", "Yes", "TRUE", "1" and a blank. Pick one form and convert the rest.

The first chart: one table, three answers

Here is what the grain of a table does in practice. Ask three simple questions of the sweet shop table: how many rows does it have, how many orders does it show, and how many customers bought something? The counts are different, even though they all come from the same six rows.

Six rows, four orders, three customers. Order 101 has two rows and Meera, the customer, appears in three rows across two orders. If you counted rows and called the result "customers", you would be wrong by a factor of two. This is not a rare edge case. It is the normal state of real data, and it is the reason the next idea is the most important in this lesson.

The question before the analysis: what does one row stand for?

Always ask: what does one row stand for? The answer is called the grain of the table. Grain is a word from photography and printing, and it fits: it is how fine the detail is.

In the sweet shop table, the grain is one item sold within one order. We know that because order 101 repeats, once per item. If the shop had instead kept a table with one row per order, with a column listing "total amount", the grain would be one order, and the table would have four rows. Same shop, same two days, a different table, and different correct answers to the question "how many rows are there?"

Why does this matter so much? Because every count, total and average you calculate silently depends on the grain. Take the question "what is the average sale?"

If you average the amount per row, you get the average sale per item sold. If you first add up each order and then average, you get the average sale per order.

Let us work it out with our table. The amount for each row is kg times priceperkg: 1,800, 640, 320, 450, 640 and 900 rupees. They add to ₹4,750 in total. Averaged per row, that is about ₹792. Averaged per order, there are four orders, so ₹4,750 divided by 4 is ₹1,187.50. Both numbers are correct. They answer different questions: "how much is a typical item sold worth?" and "how much does a typical order bring in?" A shopkeeper deciding how many staff to put on the counter cares about orders. A shopkeeper deciding how much kaju katli to make cares about items. If you do not know the grain, you cannot know which answer you have just produced.

Try it now: the shop says "we had 6 customers on those two days." Looking at the table, is that right? What would you ask?

It is not right. There were 4 orders and 3 distinct customers (Meera, Arjun and Sana). Someone has probably counted rows. The question to ask is "what do you mean by customer?" If you meant visits, the answer is 4. If you meant different people, it is 3. Neither is 6.

The next widget lets you change the numbers behind this and watch how far apart rows and orders drift as orders get bigger.

Try setting items per order to 1. The overcount disappears, and so does the gap between the two averages. That is the situation in many beginner datasets, which is partly why people forget grain exists, right up until they meet a table where it matters.

Counting the right thing

Once you know the grain, a small habit keeps you safe: say what you are counting in words, and then choose the count that matches. Here is how that works for our table. The question · What to do with the table · AnswerHow many items were sold? · Count rows · 6 How many orders were there? · Count distinct orderid · 4 How many different customers bought? · Count distinct customer · 3 How many kilograms were sold? · Add the kg column · 7.5 How much money came in? · Add kg times priceperkg · ₹4,750 What was the average order? · Total money divided by distinct orders · ₹1,187.50 Two words in that table do a lot of work: distinct and add. Counting rows counts every line. Counting distinct values counts each different value once, however many times it repeats. Adding a numeric column sums the values. Most "wrong number" arguments in offices come down to someone counting when they should have counted distinct, or summing when they should have averaged.

Next, look at where the money came from. This is a different cut of the same table, grouped by item. Grouping is how you turn a list of things into a summary, and it only works when each column is the type you expect: here, item is a category and the amount is a number.

Kaju katli brought in two-thirds of the money from three of the six rows. A chart like this can only be trusted if the rows and types underneath it are right. If one of the item names had been typed as "Kaju Katli" with a capital K, a tool might have drawn four slices instead of three, and a quarter of a shop's best seller would have looked like a separate, small item.

Identifiers and how tables connect

In real work you rarely have one table. A shop might keep a table of orders, a table of customers with their phone numbers and a table of products with their cost prices. Tables are joined using a shared identifier. Our table has orderid, and the shop's customer list might have a customerid for each person. Matching the two on that identifier is how you look up the phone number behind Meera's orders.

This is the real job of an identifier: it is the key that connects tables. Two things go wrong. First, the same thing can have two identifiers, for example if a customer is registered twice with different phone numbers; then you will count her as two people. Second, an identifier can be stored in different forms in different tables, such as 00123 in one and 123 in the other, which means the match silently fails. Check that identifiers are text, are the same length and have no stray spaces before you join anything.

You can often spot a table's grain by looking at which columns repeat. In the sweet shop table, orderid repeats and customer repeats, but no single column is unique per row. A combination, orderid plus item, is unique: no order contains the same item twice. When you can find which column or combination is unique, you have found the grain. If nothing is unique, there are probably duplicate rows, which is the next problem.

Missing values: the blanks that eat your table

Real tables have gaps. A customer did not give a phone number. A sensor failed for an hour. A form field was optional. A blank cell is called a missing value, and how you treat it changes your results. Three rules of thumb apply from the first day.

A blank is not a zero. A missing sales figure for a shop that was closed is different from a sales figure of zero from a shop that was open and sold nothing. If you add them up, the totals look the same, but if you average them, the closed shop drags the average down. Find out why it is blank. Blank because the question did not apply? Blank because nobody entered it? Blank because of a system error? Each means something different. Do not quietly delete rows with blanks. The most common first instinct is to drop every row that has a gap. It often throws away far more than people expect, because gaps add up across columns.

That last point is worth seeing with numbers. Suppose each column independently has a small chance of being blank. For a table with only a few columns, that barely matters. For a table with many columns, the chance that a row has no gap at all shrinks quickly. Try it below.

At a blank rate of just 3 per cent per column and 20 columns, only about 54 per cent of rows are fully complete. Nearly half of the table would vanish if you dropped every row with any gap. Now slide the blank rate up to 10 per cent, and the complete rows fall to around 12 per cent. This is why experienced analysts look at blanks column by column before deciding anything. The right answer is often to leave the rows in and handle the one or two columns that really are blank a lot.

Reading a table in five steps

Put the ideas together into a routine you can use on any table. It takes five minutes and prevents most of the problems above.

1. Read the header and say each column as a question. What does it measure, and in what unit? 2. Find the grain. What does one row stand for? Look for the column, or the pair of columns, that is unique for each row. 3. Check the types. Is each column the kind of value you expect? Look for numbers stored as text, dates that will not sort, identifiers that look like numbers. 4. Look for gaps and duplicates. How many blanks are in each column? Are any rows repeated exactly? Is there a total row at the bottom that would be counted twice? 5. Check the time and the source. What period does the table cover? Who produced it, and was it filtered before it reached you? A table "of all orders" that has already been filtered to one city will answer a different question than you think.

Only after these five steps is the table ready to be summarised. Notice that nothing here involves a formula. It is looking, asking and checking, and it is the part of data work that separates people who produce trusted numbers from people who produce impressive ones.

Three worked examples

The habit becomes natural with practice, so here are three more tables from ordinary life, read the same way.

A bank statement

A statement has a date, a description, a debit amount, a credit amount and a balance. The grain is one transaction. Types: date, text, number, number, number. The traps: the description is free text with no fixed format ("UPI/1234/Chai"), so you cannot count categories without cleaning it; debits and credits are in separate columns, so "total spent" means adding the debit column only; and the balance column is a running total, so adding it up makes no sense. A good reader notices that the balance is derived from the other columns and leaves it alone.

A school marks sheet

One row per student, one column per subject, and a final column with the total. The grain is one student. Types: an identifier (roll number), a category (section), numbers (marks) and a derived number (total). The traps: a student absent for an exam might have a blank or a zero, and these mean different things; and a row at the bottom with class averages looks like a student unless you notice it. Averaging the column including that row would be wrong.

Trips from a ride-hailing app

One row per trip, with a trip identifier, a start time, an end time, a distance in kilometres and a fare. The grain is one trip. Types: identifier, two timestamps, two numbers. The trap is that trip duration is not in the table, but you can work it out by subtracting the start time from the end time, which only works if both columns are real timestamps and not text. If a trip crosses midnight, a careless calculation that ignores the date will give a negative duration.

In all three tables, the work happened before any total: find the grain, check each type, and look for the rows that are not what they seem.

Common mistakes

These are the errors that most often turn up in beginners' first analyses. Each takes a minute to avoid once you know it.

Counting the header as a row. Check whether your tool includes it. Treating an identifier as a number. If it names a thing and cannot meaningfully be added, it is an identifier. Store it as text. Mixing units. Kilograms and grams, rupees and thousands of rupees, minutes and hours. Write the unit into the column name, for example priceinr or weightkg. Day and month swapped. Use year-month-day when you share dates, and check that dates after the 12th of a month parse properly: that is a quick way to catch a swap. Numbers with currency symbols or commas stored as text. "₹1,800" will not add up until the symbol and the comma are removed. A total row inside the data. Totals and averages at the bottom of a table are not rows of the list. Remove them before you calculate. Merged cells and multi-line headers. They look tidy to humans and confuse every tool. A table should have one header row and no merged cells. Duplicate rows. The same order entered twice doubles its revenue. Check for exact repeats. Blank treated as zero, or zero treated as blank. Decide what each means and write it down. Counting rows when you meant to count things. The grain mistake from earlier in the lesson, and the most expensive.

Key takeaways

A row is one thing in a list, and a column is one fact about every thing. The header names the columns and is not data. Each column has a type, and the type decides what you may do with it: numbers can be added, dates subtracted, categories counted, identifiers matched but never averaged. The grain is what one row stands for. Counts, totals and averages all depend on it, and the same table can give different correct answers to "how many?". Say what you are counting in words, then choose the right count: all rows, distinct values, or a sum. Blanks are not zeros. Dropping every row with a gap can throw away far more of a wide table than you expect. A five-minute reading routine before any calculation prevents most data mistakes.

Check yourself

1. A table has one row per product sold, and an order for three products appears as three rows. If you count the rows, are you counting orders? No. You are counting products sold. To count orders, count distinct order identifiers. 2. Why should a PIN code or phone number be stored as text and not as a number? They are identifiers, so adding them means nothing, and a number format drops leading zeros. 3. A column contains "UPI", "upi" and "Upi". What is the problem, and what is the first step to fix it? They will count as three groups. List the distinct values and convert them to one spelling. 4. In our sweet shop table, what is the average sale per row, and why is it different from the average per order? About ₹792 per row against ₹1,187.50 per order, because orders contain more than one row. 5. A table of 10,000 rows has 3 per cent of its cells blank in each of 20 columns. Roughly how many rows are completely filled, and what does that tell you about dropping rows with gaps? About 54 per cent, so around 5,400 rows. Dropping every row with a gap would lose almost half the table.

Try this

Pick one real table you can open today: a bank statement, a fitness log, a marks sheet, a household expense sheet or a work report. Set aside forty minutes and do the following, writing short notes as you go.

1. Write down the number of rows and columns, checking whether you counted the header. 2. Read every column name aloud as a question and note its unit. Mark any column whose meaning you are not sure of. 3. Decide what one row stands for, and find the column or pair of columns that is unique for each row. If nothing is unique, look for duplicates. 4. Label each column as a number, date, category, identifier or true-or-false. Mark every column where the spreadsheet's guess about the type looks wrong. 5. For each column, count the blanks. Use the missing-rows simulator above with your own number of columns and your own blank rate to see how many rows you would lose by deleting every row with a gap. 6. Write three questions about the table, such as "how many different people?" or "what is the average per day?". For each one, say whether the answer is a count of rows, a count of distinct values, a sum or an average.

A good result is a half-page note that a colleague could read and understand what the table is, what could go wrong with it and which questions it can safely answer. Keep it: it is the first page of any analysis you do with that table.

Tags: Data Science Data basics Spreadsheets Data types Beginner