Excel, SQL or straight into Power BI and Tableau? Where to start

You can begin learning data analysis in Power BI or Tableau. You do not need to master Excel first or write a hundred SQL queries before opening a BI tool. I would set one condition: learn what the data means from the first report. What does a row represent, what are you adding, how does a filter work and how do you know the result makes sense? An attractive screen can conceal a mistake remarkably well.

I would not choose a learning route using an unsupported claim that 80% of recruitment tasks involve Excel or SQL. I have no source establishing that proportion. Look instead at particular roles, the tools available to you and the work you want to do. Below is my proposed decision process, followed by one small exercise that can develop across several environments without requiring you to learn everything at once.

Separate the tool from the skill

Excel, SQL, Power BI and Tableau cover different parts of working with data, with some overlap. That does not establish a compulsory sequence for every beginner. If your team reports in Power BI, learning that environment may immediately give you somewhere to practise. If you only have a spreadsheet, you can still complete a worthwhile project and learn the basic rules. Start from the work you can actually do rather than an imagined universal curriculum.

I would separate applications from activities. Activities include checking a source, selecting records, combining tables, calculating a measure and explaining a result. Applications are where you perform those activities. Mixing the two lists makes it tempting to believe that another interface will solve a problem you do not yet understand. An undefined measure, however, can travel into the new tool with you. Its output may look more polished while remaining just as ambiguous.

Write down one task you want to perform independently. For example, prepare a weekly report of open order value by region. That has an input, an output and a reader. It gives you more guidance than a general intention to learn BI. You can then decide whether the next lesson should address importing, filtering or visualisation. There is a reason for each step instead of four unrelated courses competing for the same evening.

Power BI lets you start with a file

Microsoft’s Power BI Desktop getting-started guide covers bringing in data, preparing it and creating a report. Excel data is one possible starting point. SQL knowledge is not a technical prerequisite for drawing your first chart from such a file. I want to make that explicit so that a beginner does not postpone all practical work until every item on an intimidating skills list has been completed.

You still need to understand the import. Are you selecting a table, a worksheet or a file containing additional explanatory rows? Are dates and amounts interpreted correctly? I would start with a source small enough to inspect completely. Once the result matches the expectation, add more records and preparation steps. This gives you a chance to recognise what changed. Starting with an unfamiliar model containing many tables can hide where an incorrect assumption first entered the process.

Building a report on your own computer also differs from delivering it to a team. Establish the intended environment, connections, refresh process and publishing conditions separately. A local project using synthetic data is enough for an initial exercise. If the purpose is workplace reporting, investigate how readers will receive updates. Sending a file may be appropriate for a small task, but it does not automatically settle every question about maintaining a recurring report.

Tableau does not require prior SQL either

Tableau’s connection documentation includes files and databases. Your first analysis can therefore use a table from a file. You can practise choosing fields, aggregation and building a view without writing a custom query. I would choose an environment you can access regularly and use for your own project. A beautiful demonstration is less useful if you cannot return to the tool and try the same decisions yourself.

The edition and saving method matter. Publishing to Tableau Public makes published workbooks and data publicly accessible. Use synthetic material or data you are allowed to share for a public exercise. An employer’s export may remain unsuitable for publication even after a name column has been removed. Decide what material belongs in a public learning project before uploading it, rather than treating visibility as an afterthought.

I would not attempt to name a universally better tool here. Access to a colleague’s explanation or an established reporting process may matter more for your learning. If you are studying independently, choose one tool and finish a small project. Rebuilding it in another environment later can be instructive. Beginning both simultaneously can make it harder to recognise whether a difficulty comes from the data model or from learning two interfaces at the same time.

Choose synthetic data for the first project

Use four fictional orders. North has an open order worth 100 and a closed order worth 200. South has two open orders worth 50 and 150. Each has its own identifier and date. One row represents an entire order, and every amount uses the same arbitrary unit. These assumptions let you inspect the result without first learning an unfamiliar business system, currency conversion process or order-line model.

Ask for open order value by region. North contributes 100, South contributes 200 and the combined open value is 300. All orders together total 500. Seeing 500 under an open filter therefore signals a discrepancy that needs an explanation. That reference result is useful whether you are working in Excel, Tableau, Power BI or SQL. It gives you a stable question while you learn how a particular environment expresses the answer.

Later, add an unpriced order or a customer with two orders. Avoid starting with hundreds of columns whose meanings you cannot explain. At first, you want to see the consequences of your own choices. Small data does not assess every performance concern, but it reveals filter mistakes and repeated sums very effectively. That is a useful type of practice in its own right, even though another exercise will be needed for large-scale performance work.

What is worth learning in Excel

A spreadsheet is a convenient place to inspect records row by row. I would practise headers, a proper table, data types, sorting complete records and producing a summary. In this example, you can point to each of the four orders and explain whether it contributes. Macros can wait. First establish that you can keep a small register consistent and distinguish the source records from the report made from them.

Practise adding a record as well. Does the summary include the new order, and does it need refreshing? Then alter one region label and inspect the result. That shows how category spelling affects grouping. The underlying understanding transfers to BI, even when keyboard shortcuts and menu names do not. A learning exercise becomes more useful when you deliberately change something and explain why the output follows, instead of merely reproducing an instructor’s finished screen.

If you prefer to begin directly in Power BI, you do not have to reproduce the entire exercise in Excel first. You can return to a spreadsheet when you need to inspect a small extract or work with someone using that environment. My Excel learning plan offers another route through those activities. Select the parts needed for your present project rather than treating the whole plan as a prerequisite for trying anything else.

When SQL becomes useful

SQL is especially helpful when the source is a relational database and the task requires deliberate selection and combination of records. I would begin with SELECT, filtering, aggregation and joins. Each concept can connect to the same small report. You do not need to design a database server before understanding why joining an order-line table changes the number of records. Focus initially on what the query asks the database to return.

Connecting a BI tool to a database does not by itself establish that you understand the source relationships. Identify which table describes orders, which describes lines and which describes customers. Equally, every first assignment does not require a custom query. You may receive a prepared view. Read its definition and limitations before treating it as a complete account of the business process. A convenient source still has a scope and assumptions that somebody chose.

If the jobs you are targeting require daily SQL writing, put that into your learning plan. Use their actual duties rather than a universal percentage of recruitment exercises. Review a small set of relevant vacancies and identify the evidence they ask for. My guide to SQL beyond syntax explains the reasoning involved. It can support the project while you learn BI, without becoming a condition you must satisfy before opening a reporting application.

Learn the model alongside the report

Adding a region description to orders introduces a question about matching keys. If the relationship assumes one description per region, the data needs to support that assumption. Two descriptions for one code may change the result. I would sketch the tables and matching fields before reacting to the modelling interface. A simple drawing can reveal the intended relationship and give you a clearer question to investigate when the tool reports a problem.

Microsoft’s star-schema guide distinguishes facts from dimensions. Tableau’s relationship guide describes how its tables relate during analysis. Both are useful in their respective environments. An apparently similar connecting line does not guarantee that every mechanism behaves identically. Read the documentation for the environment you are using rather than transferring a mental shortcut from another product without checking it.

One table and one correct measure are enough for an initial project. Add a small lookup next, then introduce a missing match and a repeated key. Change one thing at a time so you can connect a different result to a particular decision. Importing a complete model immediately may provide plenty of ready-made charts. It offers fewer chances to understand why those charts contain those numbers and what would happen if a source assumption changed.

Design the view after defining the measure

Two regions and one amount need only a readable table or a simple bar chart. Label the measure as open order value, state its unit and identify the source date. I would postpone animation and elaborate colour choices. The reader should be able to find the result and recognise the active filter. You can practise that principle in any of these applications; it does not depend on access to an advanced visualisation feature.

Change the filter to closed. Our dataset now has one North order for 200. Does the reader understand why South disappeared or displays an empty amount? Choose how empty categories appear deliberately. Make active filters visible as well. A report retaining a previous selection can be read in a different context from the one the author intended. Its headline number needs enough surrounding information for the next reader to interpret it correctly.

Ask another person to answer one question without explaining the entire interface first. If they cannot find the number, improve the layout or label. If they find it but interpret it differently, clarify the measure’s definition. These are separate problems. Another chart type cannot establish whether the amount covers all orders, only open orders or the outstanding portion of partly fulfilled orders. Settle that meaning before spending more time on presentation.

Define the denominator before showing a percentage

Our initial data contains three open orders out of four, giving 75% by count. Open value is 300 out of 500, giving 60% by amount. Both are correct for the synthetic example. The label must identify which one you mean. A percentage card alone does not tell the reader whether you counted orders, amounts or customers.

Now filter to North. One of its two orders is open, so the within-region share by count is 50%. Asking for North’s contribution to all open order value is different: 100 out of 300, or one third. Decide whether selecting a region should also restrict the denominator. You can define that context before learning the application’s calculation syntax.

Write the measure’s full name and denominator, then ask someone else to interpret the output. If their interpretation differs, improve the label. This is a useful example of learning data foundations directly in BI: you learn the interface alongside how filtering changes a number’s meaning, without first collecting every possible percentage formula.

Separate a learning exercise from a team deliverable

A first project can use manually prepared input and have one reader. A team report introduces additional questions: who owns the source, when is it ready, how often is it refreshed and who explains discrepancies? Identify these before planning publication. Otherwise, you can finish a dashboard only to discover that nobody can obtain its required export regularly.

Check the computer, applications and sharing process actually available to you. These are practical constraints, not a lack of ambition. Daily access to a spreadsheet can be a sound starting point. A colleague offering Tableau guidance can be another. Regular practice on a real question is more useful than an impressive platform you cannot access.

Explain your contribution

For a portfolio project based on a course, identify the source exercise. Then show one independent decision: another filter, a missing-value check or a comparison of percentage definitions. You do not need to imply that you designed the entire original material. I want to see where following instructions developed into understanding. A small variation provides something concrete to discuss, including why the result changed and what remains unresolved.

Plan around one completed process

I would organise learning into short stages with a concrete outcome. Begin with a table and definitions, then a correct summary, then a second file and refresh, and finally a handover with instructions. Adjust the pace to your available time. None of these stages needs a promise that employment will follow after a fixed number of days. Each needs evidence that you can perform another part of the work independently and explain your choices.

Record one limitation at each stage. Perhaps the project does not handle multiple currencies, has no status history or relies on manually entered records. That description helps select the next lesson. If importing becomes the obstacle, study preparation. If the source requires queries, develop SQL. If a reader needs interaction, work on the BI environment. The sequence follows the task, with a clear reason to learn something new and a place to apply it.

Finally, repeat the report with five orders. Explain the change from the initial version and show your control process. You can then decide more deliberately which tool to add. I would happily begin with Excel and SQL when they are close to your work. I would also begin with Power BI or Tableau when that is where you can practise. Learn the foundations of data alongside a project you can actually finish and discuss.