DEV Community: Gloria Adhiambo Awinja

JCars Logistics Analysis: Data Preparation, Modelling, and Business Insights

Gloria Adhiambo Awinja — Mon, 28 Sep 2026 11:25:59 +0000

Introduction

A Power BI dashboard is only as reliable as the data behind it.
For the JCars Logistics project, the starting point was not a clean analytical dataset. It was a single raw transactional export containing sales, customer, vehicle, branch, payment, delivery, logistics and customer-experience information. The dataset had 276 order lines and 32 columns, but it also contained inconsistent categories, mixed currencies, missing values, different date formats, numbers recorded as words, suspicious business values and an unreliable recorded revenue field.

The objective was therefore not simply to build a visually attractive dashboard. The real task was to take the raw export through a complete analytical process:

Raw data → Investigation → Cleaning → Validation → Modelling → DAX → Dashboard → Analysis → Insights → Recommendations

This article explains that journey, including the reasoning behind the major decisions made along the way.

1. Understanding the Raw Dataset

The project began with Jcars_data.csv, a flat file containing 32 columns.

Each row represented one vehicle sales order line: an order for one or more units of a particular vehicle configuration, sold by a sales representative to a customer through a branch.

The dataset covered areas including:

Customers
Locations and branches
Sales representatives
Lead sources
Vehicles
Prices and costs
Discounts
Payments
Deliveries
Logistics
Customer ratings
Returns

There were 276 order lines representing 466 units sold, with Order Dates spanning 1 January 2025 to 1 December 2026.

At first glance, this looked like a straightforward sales dataset. However, the first important decision was not to immediately start building visuals.

The dataset needed to be investigated first.

Why investigation came first

Building charts before understanding the underlying data can create a polished dashboard containing incorrect information.

For example, if Toyota, totoya and toyta are treated as three separate vehicle makes, the resulting Toyota sales figure would be understated.
Similarly, combining USD, EUR, ZAR and KES values without conversion would make revenue and profitability calculations meaningless.

The first stage therefore focused on finding out what was actually wrong with the raw data.

2. Data Quality Investigation

The investigation revealed that almost every part of the dataset had its own potential data-quality issue.

Some problems were simple formatting inconsistencies, while others could directly affect business calculations.

Examples included:

Misspelled categories such as totoya and toyta
Variations such as Mercedes Benz
Location variations such as cental and nrb
Model variations such as harier
Multiple currencies including KES, KSh, USD, EUR, ZAR and R
Monetary values using M to represent millions
Missing-value placeholders such as N/A, NULL, TBD, - and #VALUE!
Excel serial dates and inconsistent date formats
Units recorded as words such as one, two and three
Discounts recorded in different formats
Customer ratings recorded as excellent, 4/5 and 3 out of 5
Review counts recorded partly as words
Implausible customer ages
Typing errors in sales representative names
Zero logistics costs on delivered orders
Zero recorded revenue on active orders

The important distinction was that these were not all treated as the same type of problem.

Instead, each issue was considered in terms of how it could affect the analysis.

For example, a misspelled category affects grouping and aggregation, while a mixed currency affects the numerical meaning of the value itself.

This led to a more structured cleaning approach.

3. Cleaning the Data in Power Query

Power Query was used as the main data preparation layer.

Rather than manually correcting individual cells, reusable functions were created for different types of problems.

This was an important design decision because the goal was to make the cleaning process:

Repeatable
Transparent
Easier to audit
Easier to maintain
Capable of being rerun if the raw export changes

The main functions included:

`fnCat`

This function handled categorical data.

Instead of simply replacing one spelling at a time, the function used mapping tables to standardize known variations.

For example:

totoya → Toyota

toyta → Toyota

This ensured that different spellings of the same business category would be treated as one category in the analysis.

`fnDate`

Dates required their own logic because the dataset contained different date formats as well as Excel serial dates.

The function converted these values into a consistent date format so that transactions could be analysed correctly by year, quarter and month.

`fnMoneyKES`

Money required more complex treatment.

The function:

Identified the currency marker.
Removed formatting characters.
Detected the M shorthand.
Applied the appropriate currency conversion.
Returned null for invalid or placeholder values.

This meant that monetary fields could eventually be compared and aggregated using one common currency.

Other functions

Additional functions were created for:

Order IDs
Customer Age
Vehicle Year
Units Sold
Discount
Customer Rating
Review Count

The result was a cleaning process based on the type of data problem, rather than a long sequence of manual corrections.

4. Standardizing Currency

One of the most important cleaning decisions involved currency.

The dataset contained monetary values in different currencies, including:

Currency	Rate to KES
KES / KSh	No conversion
USD	129.54
EUR	147.84
ZAR	7.93

Values without an explicit currency marker were assumed to be KES.

This was necessary because revenue, selling price, unit cost and logistics cost eventually needed to be combined in profitability calculations.

The conversion was applied consistently throughout the project rather than using transaction-specific exchange rates.

The M shorthand was also handled. For example, a value such as 5M needed to be interpreted as 5,000,000 rather than simply 5.

The order of these operations mattered as well. Currency conversion was performed before downstream calculations so that all monetary values were on a common KES basis.

5. Dealing With Missing and Suspicious Data

Not every unusual value was simply deleted.

This was an important principle throughout the project.

For example, a logistics cost of zero on a delivered order may be technically valid in some circumstances, but from a business perspective it is suspicious enough to investigate.

Similarly, a recorded revenue of zero on an order that was not cancelled or refunded could distort revenue analysis.

These values were therefore flagged rather than silently accepted.

A Data Quality Flag was also introduced to identify records affected by issues such as:

Missing order dates
Missing delivery dates
Estimated selling prices
Estimated unit costs

Where missing values had to be filled so that calculations could continue, documented defaults were used.

However, the original data-quality issue was still retained through the flag.

This approach avoided a common problem in data cleaning: making the final dataset look complete while hiding how much of it had been estimated or corrected.

6. Rebuilding Revenue Instead of Trusting the Raw Field

One of the most important findings during the investigation was that the recorded revenue field could not simply be taken at face value.

Instead, revenue was independently rebuilt using:

Revenue = Units Sold × Unit Selling Price × (1 − Discount) + Delivery Fee

This created a calculated Revenue field that could be compared against the original Revenue Recorded value.

The reason for doing this was straightforward: if the raw revenue field contained errors, using it directly would carry those errors into every KPI, chart and profitability calculation.

The rebuilt revenue therefore became the basis for the analysis.

This was one of the key lessons from the project:

A financial field in a raw export should be validated against the underlying transaction logic before being used as a core KPI.

7. Data Validation Before Modelling

Cleaning was followed by validation.

The purpose was to confirm that the cleaned dataset was actually ready for modelling.

Several checks were performed.

Type validation

Dates were converted to date types and monetary fields to numeric/currency types.

This prevented numbers from silently remaining as text.

Row-count validation

The cleaned dataset was checked against the original dataset.

The row count remained at 276, confirming that records had not been unintentionally dropped during cleaning.

Business-rule validation

Business rules were used to identify suspicious values.

For example:

Logistics Cost = 0 on Delivered orders
Revenue Recorded = 0 on non-Cancelled/non-Refunded orders

Revenue validation

The rebuilt revenue calculation was compared with the recorded revenue.

Category coverage

Mapping tables were built from the distinct values found in the source data so that known variations were accounted for.

Only after these checks was the data considered ready for modelling.

8. Moving From a Flat File to a Star Schema

The cleaned data was initially still a flat transactional table.

That structure was not ideal for the final Power BI model because it mixed transaction-level measures with descriptive information such as customer, vehicle and sales representative attributes.

The next step was therefore to restructure the data into a star schema.

The central table became:

FACT TABLE 2

It retained the transaction-level information, including:

Dates
Units
Prices
Costs
Discounts
Fees
Payment information
Delivery information
Revenue
Cost of Goods Sold

Dimension tables were created around it:

DIM-CUSTOMER
DIM-VEHICLE
DIM-SALES REP
DIM-LEAD SOURCE

Each dimension was created using distinct combinations of its relevant attributes and given a surrogate index key.

Why use dimensions?

The purpose was to separate descriptive information from transactional data.

For example, vehicle information such as:

Make
Model
Vehicle Type
Vehicle Year
Fuel Type
Transmission
Colour

belongs naturally in a vehicle dimension rather than being repeatedly stored as descriptive information in the fact table.

The result was a model that was easier to filter, analyse and extend.

9. Building the Relationships

The fact table was connected to the dimension tables using the surrogate keys.

The relationships were configured as many-to-one relationships from the fact table to the dimensions.

Bidirectional filtering was enabled so that slicers and interactions could work across the report as intended.

This modelling stage was particularly important because the dashboard was designed to support interactive analysis rather than static charts.

A user should be able to select a vehicle type and see the rest of the report respond accordingly.

10. Developing the DAX Layer

Once the model was established, DAX was used to create the core business metrics.

The first measure was Total Revenue:

Total revenue =
SUM('FACT TABLE 2'[Revenue])

Total Units Sold was then used as the main volume measure:

Total Units Sold =
SUM('Jcars_data-CLEANED'[Units Sold])

To analyse profitability, Cost of Goods Sold was calculated at the transaction level:

Cost of goods Sold =
'FACT TABLE 2'[Unit Cost] *
'FACT TABLE 2'[Units Sold]

Gross Profit was then calculated as:

Total Gross Profit =
[Total revenue] -
SUM('FACT TABLE 2'[Cost of goods Sold])

Finally, Gross Profit Margin was calculated as:

Total Gross Profit Margin =
([Total Gross Profit] / [Total revenue]) * 100

These calculations established the core financial logic of the dashboard.

The business definitions were kept straightforward:

Revenue = Units × Price × (1 − Discount) + Delivery Fee

Gross Profit = Revenue − Cost of Goods Sold

Gross Profit Margin = Gross Profit ÷ Revenue

11. Designing the Executive Dashboard

With the data and calculations in place, the next challenge was deciding what management should see first.

The Executive Dashboard was designed as a high-level overview rather than an attempt to display every available field.

The first layer consisted of four KPI cards:

Total Units Sold
Total Revenue
Total Gross Profit
Total Gross Profit Margin

These were chosen because together they provide a quick view of:

volume → revenue → profit → profitability

The remaining visuals were selected to answer the natural follow-up questions:

Where is profit being generated?
Which vehicle makes perform best?
Which branches contribute the most?
Which lead sources generate profit?
How are sales distributed across representatives?
What is happening over time?
What delivery statuses are associated with sales?

Executive Dashboard screenshot

JCars Executive Dashboard showing the main KPI cards and supporting sales, profitability, branch, lead-source and delivery visuals.

The purpose of this page was not to show every possible analysis. It was to give management a starting point from which deeper questions could be identified.

13. Adding Interactivity With the Drill Through Page.

The report was designed to allow users to move from summary information into more specific questions.

A Vehicle Type slicer was used across the report so that selecting a vehicle category would update the relevant visuals.

Cross-filtering was also enabled between visuals.

Drill-through functionality was incorporated for:

City
County
Fuel Type
Returned Status

This meant that the report could be used as an investigation tool rather than simply as a presentation of fixed numbers.

For example, if a user noticed an unusual return pattern, they could move from the summary level into more detailed information rather than manually searching through the original dataset.

14. The First Major Finding: Profitability Was Highly Concentrated

Once the dashboard was interactive, the analysis moved beyond simply describing totals.

One of the clearest patterns was the concentration of Gross Profit.

Toyota and Volkswagen together generated approximately 69% of total Gross Profit.

At the branch level, Thika and Nairobi HQ together generated approximately 65% of total Gross Profit.

This changed the question from:

"Which brands and branches sell the most?"

to:

"How dependent is overall profitability on a small number of brands and locations?"

The concentration matters because a problem affecting one of these major contributors could have a much larger financial effect than an issue affecting a smaller contributor.

This became one of the main business-risk observations from the analysis.

15. The Second Finding: Volume and Profit Were Not the Same Thing

SUVs were the leading vehicle type by volume, accounting for 178 of the 466 units sold, or approximately 38%.

However, the analysis showed that volume leadership and profit concentration were not necessarily the same thing.

This distinction is important.

A vehicle category can sell many units without generating the highest amount of profit.

Therefore, inventory decisions based on units sold should not automatically be treated as profitability decisions.

The dashboard made it possible to examine both measures separately.

16. Investigating Lead Sources

The analysis also looked at profitability by lead source.

This revealed an unusual result:

WhatsApp-sourced orders produced an aggregate Gross Profit of approximately −KES 3.49 million.

It was the only lead source in negative territory.

By comparison, Walk-in and Website each contributed more than KES 140 million in Gross Profit.

This raised a business question rather than providing an immediate explanation.

Several possibilities needed to be considered:

Lower-margin deals may be coming through WhatsApp.
Discounts may be higher for that channel.
A small number of unusual transactions may be distorting the total.
There could be a data-recording issue affecting WhatsApp orders.

For that reason, the appropriate next step is investigation rather than assuming the channel itself is necessarily the problem.

17. Investigating Returns

Another notable finding was the number of records marked:

Returned = Yes: 88 orders, or 31.9%.

This is a large enough proportion to deserve further investigation.

However, the dataset alone does not establish why those returns occurred.

The analysis therefore did not treat the return percentage as proof of a vehicle-quality or fulfilment problem.

Instead, the recommended next step was to segment the returned population by:

Make
Model
Branch
Sales Representative

and compare it against delivery status and individual vehicle records.

This would help determine whether returns are concentrated in particular areas or simply reflect how the field was recorded.

18. Investigating the Late-2026 Drop

The quarterly analysis revealed another unusual pattern.

Order volume fell sharply after Q2 2026.

The dataset contained:

Only 1 order in Q3 2026
3 orders in Q4 2026

compared with approximately 34–84 orders per quarter through mid-2026.

At first glance, this could look like a major decline in business.

However, the analysis considered the data-collection context as well.

The pattern could be explained by the export having been taken partway through the later quarters.

Because the dataset itself could not prove which explanation was correct, the finding was treated as a data-completeness issue requiring confirmation, rather than automatically reporting it as a genuine business slowdown.

This is an important example of why data analysis requires context.

A chart can show a pattern, but the analyst still needs to determine whether the pattern represents the business or the way the data was collected.

19. Data Quality Became an Analytical Finding

Data quality was not treated purely as a technical cleaning issue.

It became part of the final business interpretation.

Out of the 276 order lines, 76 rows, or 27.5%, carried at least one data-quality flag.

These flags were largely associated with:

Missing dates
Estimated selling prices
Estimated costs

This meant that the dashboard could be used for analysis, but its results needed to be interpreted with the quality of the underlying records in mind.

This is particularly important when looking at small subsets.

For example, a percentage calculated for a single branch, sales representative or month could be heavily affected if only a few records make up that group and some of them contain estimated values.

20. Overall Financial Picture

After cleaning, validation and calculation, the analysis-ready dataset produced the following headline figures:

Metric	Result
Total Units Sold	466
Total Revenue	KES 1,897,538,016
Total Cost of Goods Sold	KES 1,482,051,475
Total Gross Profit	KES 415,486,541
Gross Profit Margin	21.9%
Orders Analysed	276
Data-Quality Flagged Rows	76 (27.5%)
Returned = Yes	88 orders (31.9%)
Delivery Status = Cancelled	37 orders (13.4%)
Payment Status = Cancelled	27 orders (9.8%)

These numbers formed the foundation of the Executive Dashboard and the subsequent business investigation.

21. From Findings to Management Insights

The purpose of the analysis was not simply to identify interesting charts.

The findings were translated into questions management could actually act on.

Profit concentration

Toyota and Volkswagen account for approximately 69% of Gross Profit, while Thika and Nairobi HQ account for approximately 65%.

This highlights concentration across both vehicle makes and branches.

Lead-source performance

Walk-in and Website generated more than KES 140 million each in Gross Profit, while WhatsApp was negative in aggregate.

This creates a reason to investigate how deals from different channels are priced, discounted and recorded.

Data quality

More than a quarter of order lines carried a data-quality flag.

This means that improving the quality of future exports could improve the reliability of management reporting.

Returns

The 31.9% returned rate deserves investigation by vehicle, location and sales representative before conclusions are drawn about the cause.

Volume versus profitability

SUVs lead in units sold, but profitability is more concentrated at the car-make level.

This demonstrates why operational decisions should use the appropriate metric rather than relying on volume alone.

22. Recommendations

The recommendations were directly linked to the findings rather than being generic suggestions.

1. Investigate the WhatsApp lead-generation channel

WhatsApp was the only lead source with negative aggregate Gross Profit.

Before changing investment in the channel, the business should determine whether the result comes from:

Lower-margin transactions
Higher discounts
A small number of outliers
A data-recording problem

The underlying transactions should be reviewed before deciding what action to take.

2. Review concentration in major vehicle makes and branches

Because Toyota and Volkswagen generate approximately 69% of Gross Profit, and Thika and Nairobi HQ generate approximately 65%, management should understand the level of dependency on these contributors.

This includes reviewing contingency plans around:

Vehicle supply
Branch operations
Staffing
Operational disruptions

3. Investigate returned orders

The 88 returned orders should be segmented by make, model, branch and sales representative.

This would help determine whether the returns are concentrated in particular parts of the business.

The definition of the Returned field should also be reviewed to make sure it is being recorded consistently.

4. Confirm the late-2026 data completeness

The sharp fall in Q3–Q4 2026 orders should be checked against the original export and data owner.

It should not be used to describe a genuine business slowdown until it has been confirmed that the dataset covers those quarters completely.

5. Improve future data-quality controls

The project identified recurring issues around categories, dates, prices, costs and business-rule inconsistencies.

The reusable Power Query functions created during this project provide a starting point for applying the same controls automatically to future exports.

23. What the Project Demonstrated

The most important lesson from the project was that the dashboard itself was only the final layer.

The majority of the analytical work happened before the first visual was created.

The process moved through several stages:

Raw JCars Export
       ↓
Data Quality Investigation
       ↓
Power Query Cleaning
       ↓
Currency Standardization
       ↓
Business-Rule Validation
       ↓
Independent Revenue Calculation
       ↓
Star Schema Modelling
       ↓
DAX Measures
       ↓
Executive Dashboard
       ↓
Detailed Investigation
       ↓
Business Questions
       ↓
Insights
       ↓
Recommendations

Each stage solved a different problem.

Cleaning made the values usable.

Validation established confidence in the cleaned data.

Modelling created a structure suitable for analysis.

DAX translated business definitions into reusable metrics.

The dashboard made the information accessible.

The investigation turned the visuals into questions.

And the final recommendations connected those findings back to business decisions.

24. Challenges and Lessons Learned

The biggest challenge was the variety of problems in the raw dataset.

There was no single cleaning rule that could solve everything.

Categorical errors required mapping.

Dates required parsing.

Currencies required detection and conversion.

Numbers written as words required transformation.

Missing values required documented treatment.

Business-rule violations required investigation rather than simple replacement.

This led to one of the most useful lessons from the project: data cleaning should be designed around the problems found in the data, not around a generic checklist.

The use of reusable functions such as fnCat, fnDate and fnMoneyKES made the process much easier to maintain than a large collection of manual Power Query steps.

Another important lesson was the importance of independently validating business metrics.

The recorded Revenue field could not simply be assumed to be correct. Rebuilding revenue from units, price, discount and delivery fee provided an independent check and helped expose anomalies that might otherwise have flowed directly into the dashboard.

25. Conclusion

The final JCars Logistics solution transformed a messy flat-file export into an interactive Power BI reporting model.

The final model provided:

A cleaned and standardized dataset
Reusable Power Query transformations
A star-schema data model
Surrogate-key dimensions
DAX-based business metrics
An Executive Dashboard
A detailed analysis page
Cross-filtering and slicers
Drill-through analysis
Business-quality checks
Documented assumptions
Management insights
Data-driven recommendations

The resulting analysis showed that JCars Logistics generated KES 1.90 billion in revenue and KES 415.5 million in Gross Profit, with a 21.9% Gross Profit Margin across 276 analysed order lines.

More importantly, the project showed where that performance came from and where further investigation was needed: profitability was concentrated in a small number of vehicle makes and branches, WhatsApp-sourced orders were negative in aggregate Gross Profit, returns represented a significant share of orders, and a substantial portion of the dataset required data-quality intervention.

The project therefore moved beyond simply answering "What happened?"

It created a framework for asking:

"Why did it happen, where is it happening, how reliable is the underlying data, and what should be investigated next?"

That is ultimately what turned the JCars dataset from a raw transactional export into a management analysis tool.

GITHUB:https://github.com/gee-999/JCARS-LOGISTIC-ANALYSIS-PROJECT

POWER BI: Data Modelling, Relationships & Joins

Gloria Adhiambo Awinja — Sun, 13 Sep 2026 12:16:31 +0000

Introduction

When working with data in Power BI, having the data is only the beginning. The way that data is organized and connected can make a big difference in how easily we can analyze it and how reliable our reports become. In a real business environment, information is rarely stored in one simple table. Sales, customers, products, dates, and locations are often stored separately, which means Power BI needs to understand how these different pieces of information relate to each other.
This is where data modelling, relationships, and joins come in. Data modelling involves structuring tables and defining how they connect so that the data can be used effectively for reporting and analysis. Relationships allow Power BI to move filters between related tables, while Power Query joins allow us to combine data during the data preparation stage.
In this article, I will explore the main data modelling approaches used in Power BI, including flat tables, star schemas, and snowflake schemas. I will also explain the difference between fact and dimension tables, how relationships and cardinality work, and how filter direction affects the way data behaves in a report. In addition, I will look at the different join types available in Power Query and explain how they differ from relationships in the Power BI data model.

Rather than looking at these concepts only from a theoretical point of view, I will use a practical sales example throughout the article. This will help demonstrate not only what these concepts mean, but also why choosing the right structure and relationships matters when building a Power BI solution.

Data Modelling in Power BI

Data modelling in Power BI is the process of organizing your data into tables and creating relationships between those tables so that Power BI can understand how the data is connected.

In our article today, we will be referencing electronic sales with entries like Sales ID, Date, Customer, Region, Product, Category, and Quantity.

The purpose of data modelling is not simply to separate tables. It is to create a structure that allows Power BI to correctly filter, calculate, analyze, and present your data.

Importance of a well-designed data model.

A good data model provides the foundation for your entire Power BI report.

1. Reporting

A proper model helps your charts, tables, slicers, and filters return the correct results.

For example, if you data contains quantity of phones sold and you want to know the quantity sold at a particular region for example in California, Power BI needs to understand the relationship between the sales and region information. With the correct relationships, selecting California automatically filters the relevant sales.

2. Analytics

A good model makes it easier to look at your data from different perspectives.

Using the same sales data, you might want to analyze:

Quantity sold by region
Quantity sold by customer
Quantity sold by phone version
Sales over time
Performance of different products

You can do this without creating completely separate datasets for every analysis.

3. DAX calculations

Data modelling is especially important when creating DAX measures.

For example:

Total Quantity = SUM(Sales[Quantity])

The measure can then be used with different fields such as Region, Customer, Version, or Date.

If the relationships between your tables are correct, Power BI knows how those filters should affect the calculation. If the model is poorly designed, your DAX calculations can produce unexpected or incorrect results.

4. Performance

The way you structure your data can affect how quickly Power BI processes calculations and displays your reports.

A clean model avoids unnecessary duplication and complicated relationships, which can help Power BI work more efficiently, especially when dealing with large datasets.

5. Scalability

A good model should still work when your data grows.
For example, you might start with a few thousand sales records but later have hundreds of thousands or millions. You may also want to add information such as price, discount, payment method, or salesperson.
A well-designed model makes it easier to add this information without rebuilding the entire report.

6. Maintainability

Finally, a good model makes your Power BI project easier to understand and maintain.

If you or another analyst needs to modify the report later, it should be clear:

What each table represents
What each column means
How the tables are related
Which calculations are being used
Where the data is coming from

This makes troubleshooting and future changes much easier.

data model is described as the foundation of your Power BI report.

You can have beautiful dashboards and complicated DAX formulas, but if the underlying model is poorly designed, you can still end up with incorrect results, slow reports, and difficult-to-maintain solutions.

So the basic idea is:

Organize the data → Create the right relationships → Build DAX calculations → Create visualizations → Get reliable insights.

A well-designed data model therefore supports accurate reporting, meaningful analytics, reliable DAX calculations, better performance, future growth, and easier maintenance.

So, we are going to look at different approaches when it comes to data modelling.

1. Flat Table
A flat table stores all the information in one table. Instead of separating information into fact and dimension tables, everything is kept together in a single dataset.

There are no relationships between separate tables because all the information is stored together.

Advantages

Simple to understand, especially for beginners.
Easy to import into Power BI.
Does not require creating relationships between tables.
Suitable for small and simple datasets.
Quick to set up for simple reports.

Disadvantages

Can contain a lot of duplicated information.
The dataset can become very large.
Changes to descriptive information may have to be repeated in many rows.
More difficult to maintain as the dataset grows. Can use more memory. It is not ideal for complex DAX calculations and large Power BI models.

Instances flat table is Appropriate
A flat table can be appropriate when:
1.The dataset is small.
2.The analysis is relatively simple.
3.There are no complicated relationships between entities.
4.A quick report or prototype is required.
5.The source data is already provided as a single table.
6.Power BI performance and complexity

For small datasets, a flat table can perform reasonably well because there are no relationships to manage. However, as the number of rows and columns increases, the repeated information can increase the size of the model.

Therefore, although a flat table is simple, it is generally less scalable than a well-designed dimensional model.

2. Star Schema
A star schema is a data model where a central fact table is connected directly to several dimension tables.

It is called a star schema because the structure looks like a star: the fact table is in the center while the dimension tables surround it.

Structure

For example, our sample business could have:

                  ┌──────────────────────┐
                  │       Dim Date       │
                  ├──────────────────────┤
                  │ PK  | Date Key       │
                  │     | Date           │
                  │     | Month          │
                  │     | Year           │
                  └──────────┬───────────┘
                             │ 1
                             │
                             │ N
┌──────────────────────┐  1  ▼  N ┌──────────────────────┐ N  1 ┌──────────────────────┐
│     Dim Customer     ├─────────►│      Fact Sales      │◄────────┤     Dim Product      │
├──────────────────────┤          ├──────────────────────┤         ├──────────────────────┤
│ PK  | Cust Key       │          │ FK  | Cust Key       │         │ PK  | Prod Key       │
│     | Cust Name      │          │ FK  | Prod Key       │         │     | Prod Name      │
│     | Segment        │          │ FK  | Date Key       │         │     | Category       │
└──────────────────────┘          │ FK  | Loc Key        │         │     | Brand          │
                                  │     | Quantity       │         └──────────────────────┘
                                  │     | SalesAmt       │
                                  └──────────┬───────────┘
                                             │ N
                                             │
                                             │ 1
                                  ┌──────────▼───────────┐
                                  │     Dim Location     │
                                  ├──────────────────────┤
                                  │ PK  | Loc Key        │
                                  │     | County         │
                                  │     | Region         │
                                  └──────────────────────┘

The Fact Sales table contains the business events, while the dimension tables provide information that describes those events.

Advantages
1.Simple and easy to understand.
2.Works very well with Power BI.
3.Reduces unnecessary duplication.
4.Makes relationships easier to manage.
5.Makes DAX calculations easier to write.
6.Generally provides good query performance.
7.Easier to maintain than a large flat table.
8.Scales better as the amount of data increases.

Disadvantages
1.Requires more planning than a flat table.
2.Requires relationships between tables.
3.Poorly designed relationships can produce incorrect results.
4.Users need to understand basic concepts such as primary keys, foreign keys, dimensions and facts.

When to use a star schema

Star schemas are particularly suitable for:
1.Business intelligence dashboards.
2.Sales analysis.
3.Financial reporting.
4.Customer analytics.
5.Inventory analysis.
6.Marketing analytics.
7.Power BI reports with multiple dimensions and measures.
8.Power BI performance and complexity

The star schema is generally the recommended approach for Power BI models because it separates business events from descriptive information.

For example, instead of storing the customer's name thousands of times in a sales table, the fact table can store a Customer Key and retrieve the customer's details from Dim Customer.

This reduces unnecessary duplication and gives Power BI a more structured model.

3. Snowflake Schema
Definition
A snowflake schema is an extension of the star schema where dimension tables are further divided into additional related tables.

In a star schema, dimensions are usually denormalized. In a snowflake schema, they are more normalized.

Structure

For example:

Advantages
1.Reduces duplication within dimension tables.
2.Provides a more normalized structure.
3.Can be useful when dimensions contain complex hierarchies.
4.Easier to manage certain large and complex datasets.
5.Can improve data consistency because information is maintained in one place.

Disadvantages

1.More tables and relationships.
2.More complicated than a star schema.
3.Can make the Power BI model harder for users to understand.
4.More relationships can increase modelling complexity.
5.Queries may require more joins.
6.Can make DAX and report development more complicated.

When to use snowflake schema .
A snowflake schema may be useful when:

Dimension data is very large.
Dimensions have multiple levels of hierarchy.
There is substantial duplication within dimensions.
Data consistency is particularly important. 5.The organization already uses highly normalized databases.

Although a snowflake schema can reduce duplicated data, it introduces additional relationships. This can make the model more complex and potentially require Power BI to perform more relationship traversals.

For many Power BI reporting scenarios, a star schema is preferred over a snowflake schema because it provides a good balance between performance, simplicity, and maintainability.

Feature	Flat Table	Star Schema	Snowflake Schema
Number of Tables	One	Several	Several (including sub-dimensions)
Relationships	None	Fact → Dimensions	Fact → Dimensions → Sub-dimensions
Complexity	Low	Medium	High
Data Duplication	High	Lower	Very low
Ease of Understanding	Very easy	Easy	More difficult
Power BI Suitability	Small/simple models	Excellent	Good for complex models
Performance	Good for small data	Generally very good	Can be affected by additional relationships
Scalability	Low	High	High
Maintenance	Simple initially	Easy	More complex
Typical Use	Simple analysis	BI / Reporting	Complex normalized data

A flat table is the simplest approach but becomes difficult to manage as data grows.

A star schema provides a good balance between simplicity, performance, and scalability and is therefore commonly recommended for Power BI.

A snowflake schema provides greater normalization but introduces more relationships and therefore more complexity.

Relationships, Filter Direction and Joins in Power BI

Creating tables is only part of building a good Power BI data model. The next important step is making sure Power BI understands how those tables are connected. This is where relationships become important.

In a typical electronic sales project, data is usually stored in several tables rather than one large table. For example, a sales system may have a Fact Sales table containing transactions, a Dim Customer table containing customer information, a Dim Product table containing product information, and a Dim Date table containing dates.

Relationships tell Power BI how these tables are connected and allow filters and calculations to work across them.

1. Relationships in Power BI

A relationship in Power BI is a connection between two tables based on a column that the tables have in common.

For example, Dim Customer may contain:

Customer ID	Customer Name	Region
C001	John	Nairobi
C002	Mary	Mombasa
C003	Peter	Kisumu

While Fact Sales may contain:

Sales ID	Customer ID	Product	Quantity
S001	C001	Phone	2
S002	C002	Laptop	1
S003	C001	Tablet	3
S004	C003	Phone	1

Both tables contain Customer ID. Power BI can use this column to establish a relationship.

               ┌─────────────────────┐
               │     Dim Customer    │
               ├─────────────────────┤
               │ PK | Customer ID    │
               │    | Customer Name  │
               │    | Region         │
               └──────────┬──────────┘
                          │
                          │ 1  (One)
                          │
                   Key: CustomerID
                          │
                          │ *  (Many)
                          ▼
               ┌─────────────────────┐
               │      FactSales      │
               ├─────────────────────┤
               │ PK | SalesID        │
               │ FK | CustomerID     │
               │    | Product        │
               │    | Quantity       │
               └─────────────────────┘

Without this relationship, Power BI would not automatically know that C001 in the sales table refers to John in the customer table.

2. Primary Keys and Foreign Keys

Understanding keys is important when creating relationships.

Primary Key

A primary key is a column that uniquely identifies each record in a table.

For example:

Dim Customer

Customer ID
C001
C002
C003
C004

Each Customer ID appears only once, making it suitable as a primary key.

Foreign Key

A foreign key is a column used to refer to a record in another table.

In FactSales, the same CustomerID can appear many times:

Fact Sales

Customer ID
C001
C002
C001
C003
C001

This happens because one customer can make multiple purchases.

Therefore:

Dim Customer[Customer ID]  →  unique
Fact Sales[Customer ID]    →  can repeat

This is what creates a typical one-to-many relationship.

3. Relationship Cardinality

Cardinality describes how many records in one table can be associated with records in another table.

The main relationship types are:

One-to-Many (1:*)
One-to-One (1:1)
Many-to-Many (:)

3.1 One-to-Many (1:*)

One-to-many is the most common relationship in a Power BI star schema.

It means that one record in one table can be related to many records in another table.

For example, one customer can make many sales.

Dim Customer                         Fact Sales

Customer ID                         Customer ID
C001 ─────────────────────────────► C001
                                    C001
                                    C001
C002 ─────────────────────────────► C002
                                    C002
C003 ─────────────────────────────► C003

The relationship is:

Dim Customer        Fact Sales
     1                 *
     │                 │
     └─────────────────┘

The 1 side contains unique values, while the * side can contain repeated values.

Practical example

A company may have one customer record:

C001 | John | Nairobi

but John may have purchased several products:

C001 | Phone
C001 | Laptop
C001 | Headphones
C001 | Tablet

Therefore:

Dim Customer → Fact Sales = 1:*

When to use it.

This is normally the preferred relationship when working with a star schema.

Typical examples include:

Dim Customer → Fact Sales
Dim Product → Fact Sales
Dim Date → Fact Sales
Dim Location → Fact Sales

When to use it.

It should not be used simply because two tables have a similar column name. The values and meaning of the keys must actually represent a valid relationship.

3.2 One-to-One (1:1)

A one-to-one relationship means that one record in one table corresponds to only one record in another table.

Table A                     Table B

ID 1 ─────────────────────► ID 1
ID 2 ─────────────────────► ID 2
ID 3 ─────────────────────► ID 3

For example, an organization might have:

Employee
Employee ID| Employee Name
001        | Jane
002        | Peter
003        | Mary

and a separate table containing employee payroll information:

Employee Payroll
Employee ID| Salary
001        | 80,000
002        | 75,000
003        | 90,000

Each employee has one corresponding payroll record.

When to use it.

A 1:1 relationship can be useful when:

A table contains additional information that logically belongs to the same entity.
Sensitive or restricted information is kept separately.
A very wide table has been intentionally split into smaller tables.

When not to use it.

If the two tables represent essentially the same information and can be combined without creating problems, a 1:1 relationship may unnecessarily complicate the model.

3.3 Many-to-Many (:)

A many-to-many relationship occurs when many records in one table can be related to many records in another table.

For example, students and courses:

Students                       Courses

Student A ───────────────────► Course 1
Student A ───────────────────► Course 2

Student B ───────────────────► Course 1
Student B ───────────────────► Course 3

One student can take many courses, while one course can have many students.

Students             Courses
   *                    *
    \                  /
     \                /
      ────────────────

In a real database, this type of relationship is often handled using a bridge/junction table:

DimStudent
     │
     │ 1:*
     ▼
BridgeStudentCourse
     │
     │ *:1
     ▼
DimCourse

When to use it.

Many-to-many relationships can be useful when the underlying business relationship genuinely allows multiple matches on both sides.

When not to use it.

They should not be used as a quick solution for a poorly designed model.

Direct many-to-many relationships can make filter propagation and DAX calculations more difficult and may produce unexpected results.

Where possible, a bridge table or a clearer star-schema design is usually preferable.

4. Referential Integrity

Referential integrity means that values used as foreign keys should correspond to valid records in the related table.

For example, if Fact Sales contains:

Customer ID
C001
C002
C003

then those customers should normally exist in Dim Customer.

Dim Customer
C001 ✓
C002 ✓
C003 ✓

Fact Sales
C001 ✓
C002 ✓
C003 ✓

If the sales table contains C999, but C999 does not exist in Dim Customer, the relationship has a missing match.

This can lead to blank or unexpected results in reports.

Good data modelling therefore involves checking that keys are valid and that relationships make business sense.

5. Active and Inactive Relationships

Power BI can have relationships between the same tables that are not all active at the same time.

An active relationship is the relationship Power BI uses automatically when filtering and calculating data.

For example:

Dim Date[Date] ───────► Fact Sales[Order Date]

This could be the active relationship.

However, a sales table might also contain:

Order Date
Shipping Date

The date table could therefore have two possible relationships:

Dim Date ───────► Fact Sales[Order Date]       ACTIVE

Dim Date ───────► Fact Sales[Shipping Date]    INACTIVE

The inactive relationship can still be used in specific DAX calculations when required.

This is useful when the same fact table contains different dates that need to be analyzed separately.

6. Filter Direction

Relationships do more than connect tables. They also determine how filters move between tables.

Suppose we have:

Dim Product
     │
     │
     ▼
Fact Sales

If the relationship uses single-direction filtering, selecting Phone from Dim Product filters the related records in Fact Sales.

For example:

Dim Product

Product
-------
Phone      ← Selected
Laptop
Tablet

          ↓ filter

Fact Sales

Product    Quantity
Phone         2
Phone         1
Phone         4

The sales table now shows only sales associated with the selected product.

Single-Direction Filtering

Single-direction filtering normally moves from the dimension table towards the fact table.

Dim Product
     │
     │ Filter
     ▼
Fact Sales

This is generally the preferred approach for a star schema because the direction of filtering is clear and predictable.

For example:

Dim Customer ───────► Fact Sales
Dim Product  ───────► Fact Sales
Dim Date     ───────► Fact Sales
Dim Location ───────► Fact Sales

The dimensions filter the fact table.

7. Bidirectional Filtering

Bidirectional filtering allows filters to move in both directions.

Dim Product
     ▲
     │
     ▼
Fact Sales

This can sometimes be useful, but it should be used carefully.

For example, if a product is selected, the sales table can be filtered. With bidirectional filtering, filters can also travel back from the sales table towards the product table.

Reason it may cause a problem.

Consider a model with several connected tables:

Dim Customer ───► Fact Sales ◄─── Dim Product
       ▲                         ▲
       │                         │
       └──────────────┬──────────┘
                      │
                 Other tables

If filters are allowed to travel in both directions, Power BI can end up with multiple possible paths between tables.

This can create:

Ambiguous filter paths.
Unexpected filtering.
More complicated DAX behavior.
Difficult-to-debug reports.
Additional model complexity.

Therefore, single-direction filtering is generally preferred unless there is a clear reason to use bidirectional filtering.

8. Joins in Power Query

Relationships are not the only way to work with multiple tables.
Power Query provides another approach called Merge Queries.
A join combines two tables based on one or more matching columns.

For example, suppose we have:

Customers

Customer ID	Customer Name
C001	John
C002	Mary
C003	Peter
C004	Jane

Orders

Order ID	Customer ID	Amount
O001	C001	50,000
O002	C002	30,000
O003	C001	20,000
O004	C005	15,000

The tables can be merged using Customer ID.

Power Query provides several join types.

9. Left Outer Join

A Left Outer Join keeps all records from the left table and matching records from the right table.

Customers                    Orders

C001 ─────────────────────── C001 ✓
C002 ─────────────────────── C002 ✓
C003 ─────────────────────── no match
C004 ─────────────────────── no match

Expected result:

Customer ID	Customer Name	Order ID	Amount
C001	John	O001	50,000
C002	Mary	O002	30,000
C003	Peter	null	null
C004	Jane	null	null

The customers table determines which records are retained.

When to use it.

A company wants a list of all customers, including customers who have never placed an order.

10. Right Outer Join

A Right Outer Join keeps all records from the right table and matching records from the left table.

Customers                    Orders

C001 ─────────────────────── C001 ✓
C002 ─────────────────────── C002 ✓
C003
C004
                             C005 ← no customer match

Expected result:

Customer ID	Customer Name	Order ID	Amount
C001	John	O001	50,000
C002	Mary	O002	30,000
C001	John	O003	20,000
C005	null	O004	15,000

When to use it.

This could be useful when the orders table is the primary table and the objective is to retain every order, even where customer information is missing.

In practice, a left join is often easier to understand because you can simply place the table you want to preserve on the left.

11. Full Outer Join

A Full Outer Join keeps all records from both tables, whether they match or not.

Customers                    Orders

C001 ─────────────────────── C001 ✓
C002 ─────────────────────── C002 ✓
C003 ─────────────────────── no match
C004 ─────────────────────── no match

                             C005 ← no customer match

Expected result:

Customer ID	Customer Name	Order ID	Amount
C001	John	O001	50,000
C002	Mary	O002	30,000
C001	John	O003	20,000
C003	Peter	null	null
C004	Jane	null	null
C005	null	O004	15,000

When to use it.

A full outer join can be useful when checking data quality and identifying unmatched records on both sides.

For example, it can help identify:

Customers without orders.
Orders without valid customers.

12. Inner Join

An Inner Join keeps only records that have a match in both tables.

Customers                    Orders

C001 ─────────────────────── C001 ✓
C002 ─────────────────────── C002 ✓
C003                         no match
C004                         no match

                             C005

Expected result:

Customer ID	Customer Name	Order ID	Amount
C001	John	O001	50,000
C002	Mary	O002	30,000
C001	John	O003	20,000

Customers without orders are removed, and orders without a matching customer are also removed.

When to use it.

An inner join is appropriate when only records that exist in both datasets are relevant.

13. Left Anti Join

A Left Anti Join returns records from the left table that do not have a matching record in the right table.

Customers                    Orders

C001 ─────────────────────── C001
C002 ─────────────────────── C002
C003  ← retained
C004  ← retained

                             C005

Expected result:

Customer ID	Customer Name
C003	Peter
C004	Jane

These are customers who have no matching orders.

When to use it.

This is particularly useful for data quality checks.

For example:

Which customers have registered but never placed an order?

14. Right Anti Join

A Right Anti Join returns records from the right table that do not have a matching record in the left table.

In our example:

Customers                    Orders

C001 ─────────────────────── C001
C002 ─────────────────────── C002
C003
C004

           C005 ← retained

Expected result:

Customer ID	Order ID	Amount
C005	O004	15,000

This identifies an order whose customer does not exist in the Customers table.

When to use it.

It can be used to identify:

Invalid customer IDs.
Orphan transactions.
Data entry errors.
Missing master data.

15. Summary of Power Query Join Types

To summarize this we ould say:

Join Type	Records Retained
Left Outer	All left + matching right
Right Outer	All right + matching left
Full Outer	All records from both tables
Inner	Only matching records
Left Anti	Left records with no match
Right Anti	Right records with no match

16. Power Query Joins vs Power BI Relationships

Although joins and relationships both involve connecting tables, they do fundamentally different things.

Power Query Merge

A Merge Query happens during the data preparation stage.

It can physically bring columns from one table into another.

For example:

Customers
Customer ID| Customer Name
C001       | John

        +

Orders
Customer ID| Order ID| Amount
C001       | O001    | 50,000

        ↓ Merge

Combined Table
Customer ID| Customer Name| Order ID| Amount
C001       | John         | O001    | 50,000

The result is a new table containing information from both sources.

Power BI Relationship

A relationship does not physically merge the tables.

Instead, the tables remain separate:

Dim Customer                   Fact Sales

Customer ID                    Customer ID
Customer Name                  Sales ID
Region                         Product ID
                               Amount

       1 ───────────────── *

Power BI understands that the tables are connected and uses the relationship when filtering and calculating.

17. When to Merge Instead of Create a Relationship.

A merge is useful when two pieces of information logically belong together and you want them available in the same table.

For example, if a product table contains:

Product ID
Product Name
Category ID

and a small lookup table contains:

Category ID
Category Name

you may merge the category name into the product table during Power Query transformation.
However, you should not automatically merge every table.
For example, it is usually better to keep:

Dim Customer
Dim Product
Dim Date
Dim Location
Fact Sales

as separate tables rather than creating one enormous table.

18. Why Excessive Merging Can Be a Problem

Imagine taking:

Fact Sales
+
Customer
+
Product
+
Date
+
Location

and merging everything into one table.

The result may be a very wide table containing repeated information.

For example, if John makes 1,000 purchases, his customer information could be repeated across many rows.

This can:

Increase redundancy.
Make the model harder to maintain.
Increase the number of columns in the fact table.
Make the data model less intuitive.
Make changes to dimensions more difficult.
Move the model away from a clean star schema.

Therefore, merging should be done when there is a genuine data-preparation reason, not simply because tables are related.

19. Recommended Power BI Model

For a typical business intelligence project, I would generally recommend a star schema rather than a flat table or a highly normalized snowflake schema.

A typical model could look like this:

                         ┌───────────────┐
                         │    Dim Date   │
                         └───────┬───────┘
                                 │ 1:*
                                 ▼
┌───────────────┐        ┌───────────────┐        ┌───────────────┐
│ Dim Customer  │        │   Fact Sales  │        │  Dim Product   │
│               │ 1:*    │               │    *:1 │               │
└───────┬───────┘───────►│ Customer ID    │◄───────┴───────────────┘
        │                 │ Product ID    │
        │                 │ Date Key      │
        │                 │ Location ID   │
        │                 │ Quantity      │
        │                 │ Sales Amount  │
        │                 └───────┬───────┘
        │                         │ *:1
        │                         ▼
        │                 ┌───────────────┐
        └────────────────►│ Dim Location  │
                          └───────────────┘

The fact table contains the transactions, while the dimensions describe those transactions.

Reasons to choose a star schema?

Performance:
A well-designed star schema generally works efficiently in Power BI because the model has clear relationships and avoids unnecessary duplication.

DAX simplicity:
Measures such as:

Total Sales = SUM(Fact Sales[Sales Amount])

can be easily evaluated and then analyzed using dimensions such as product, customer, or date.

Model readability:
It is easy to understand what each table does. Fact tables contain events, while dimensions provide context.

Scalability:
New products, customers, locations, or dates can be added to their respective dimensions without redesigning the entire model.

Maintainability:
If a customer's region changes, the customer information can be updated in the dimension rather than being repeated across thousands of transaction records.

Reduced redundancy:
Descriptive information is stored once instead of repeatedly in every transaction.

20. Recommended Relationships and Filter Direction

For a typical star schema, I would normally use one-to-many relationships:

Dim Customer  1 ───── * Fact Sales
Dim Product   1 ───── * Fact Sales
Dim Date      1 ───── * Fact Sales
Dim Location  1 ───── * Fact  Sales

The dimension tables would normally be on the one side, while the fact table would be on the many side.

I would also normally use single-direction filtering:

Dim Customer ───────► Fact Sales
Dim Product  ───────► Fact Sales
Dim Date     ───────► Fact Sales
Dim Location ───────► Fact Sales

This creates a clear filtering path.

For example, selecting Smartphones in Dim Product filters Fact Sales to only smartphone transactions. Selecting 2026 in Dim Date filters the sales to transactions occurring in that year.

Bidirectional filtering would only be introduced when there is a specific modelling requirement that cannot be handled cleanly with single-direction filtering.

Conclusion

Relationships, joins, and filter direction all play important but different roles in Power BI. A relationship connects tables in the Power BI data model without physically combining them. It allows filters and calculations to move between related tables.
A Power Query merge, on the other hand, combines data during the data preparation stage and can physically bring columns from one table into another.
For relationships, one-to-many is the most common cardinality in a well-designed star schema. One-to-one relationships can be useful in specific situations, while many-to-many relationships should be used carefully because they can introduce additional complexity.
Filter direction also matters. Single-direction filtering is normally preferred because it creates a predictable flow from dimensions to fact tables. Bidirectional filtering can be useful, but unnecessary use can create ambiguous filter paths and make the model harder to understand.
For Power Query, the different join types provide flexibility for combining and validating data. Inner joins keep matches, outer joins preserve records from one or both tables, while anti joins are particularly useful for finding unmatched records.
For a typical Power BI business intelligence solution, I would choose a star schema with one-to-many relationships and primarily single-direction filtering. This approach provides a good balance of performance, DAX simplicity, readability, scalability, low redundancy, and maintainability. More importantly, it keeps the model understandable: the fact table records what happened, while the dimension tables explain who, what, when, and where it happened.

Building an Interactive Excel Dashboard for E-commerce Product Analysis: A Case Study of Jumia Products

Gloria Adhiambo Awinja — Sat, 05 Sep 2026 21:44:47 +0000

Introduction

E-business platforms generate large amounts of product data, including prices, discounts, ratings, and customer reviews. When properly analyzed, this information can help sellers and businesses understand product performance and identify areas that may require attention.
For this project, I built an interactive Excel dashboard for Jumia product analysis. The project focused on transforming raw product data into a structured dataset, performing exploratory analysis, and presenting the results through an interactive dashboard.
The main objective was to investigate relationships between price, discount, rating, and customer reviews, while identifying products with strong or weak performance.

1. Project Objective

The main objective was to build an interactive Excel dashboard that could answer questions about Jumia product performance.
Specifically, I wanted to understand:
• Whether larger discounts were associated with more customer reviews.
• Whether highly rated products attracted stronger review engagement.
• Whether product price and rating appeared to move together.
• Which products had the highest and lowest ratings.
• Which products had the highest discounts.
• Which products generated the most reviews.
• Which products might require additional pricing, marketing, or product-quality attention.
An important consideration throughout the project was that reviews were treated as a proxy for customer engagement, not as a measure of sales or revenue.

2. Dataset and Business Questions

The dataset contained information about 112 Jumia products.
The analysis focused on product-level variables such as:
• Product
• Current Price
• Old Price
• Discount
• Rating
• Reviews
The business questions guiding the analysis were:

Does a higher discount correspond to more reviews?
Do highly rated products receive more reviews?
Is there a relationship between current price and rating?
Which products have the highest ratings?
Which products have the lowest ratings?
Which products have the highest discounts?
Which products have the highest number of reviews?
Are there products with high discounts but relatively weak ratings or engagement?

These questions helped determine which calculations, PivotTables, and visualizations were needed.

3. Initial Data-Quality Audit

Before making changes to the dataset, I performed a data-quality audit to understand the condition of the raw data.
The audit focused on:
• Number of rows and columns=116
• Blank or missing values =55 each for two columns
• Duplicate records =2
• Price ranges =2
• Misspelled column header=1
• Improperly written product names=1
One of the most important findings from the audit was the presence of missing ratings.
Out of the 112 products, 55 products had no recorded rating and review, meaning that approximately 49.1% of the products lacked rating and review information.
This was important because rating-based and review-based analysis could only be performed reliably on the products with available ratings.
The original dataset was preserved rather than overwritten so that the cleaning process remained traceable.

4. Cleaning and Preparation Decisions

The raw data was kept separate from the cleaned dataset. This ensured that the original data remained available for comparison and verification.
The cleaned dataset was then prepared for analysis by:
• Checking and correcting data types.
• Handling missing values where appropriate.
• Ensuring prices were treated as numerical values.
• Ensuring discount values were represented consistently as percentages.
• Checking rating and review fields.
• Creating additional analytical fields.
• Converting the cleaned range into an Excel Table for easier reference and analysis.
The cleaned table was named cleaned

5. Excel Formulas and Enrichment Fields

After cleaning the dataset, I created additional fields to support the analysis. Some of these tables were:
Discount Amount
The discount was calculated from the difference between the old price and current price.
For example:
= [Old Price]- [Current Price]]
Rating Categories
Products were also classified according to their rating to make it easier to analyze rating quality.
The categories were designed to distinguish products with poor, average, and excellent ratings.
For example:

=IF([Rating]="","Missing”, IF([@Rating] <3,"Poor”, IF([@Rating] <=4.5,"Average","Excellent")))

This classification made it easier to summarize rating performance using PivotTables.

These enrichment fields transformed the original variables into categories that could be used for business-oriented analysis.

6. PivotTable and Analysis Workflow

After preparing the cleaned dataset, I created PivotTables to summarize the data. This was vital because some of these tables would bring about slicers and graphs that would be used to represent data on the dashboard.
The PivotTables were used to investigate:
• Distribution Rating.
• Discount distribution.
• Price versus rating.
• Engagement by discount category.
• Top products by rating.
• Bottom products by rating.
• Top products by discount.
• Top products by reviews.

7. Relationship Analysis

To investigate relationships between numerical variables, I created scatter plots with trendlines.
The three relationships analyzed were:
Discount vs Reviews
The calculated correlation for this was 0.0440, which indicated a very weak relationship.
The analysis therefore did not suggest that discount percentage strongly explained differences in review engagement.
Rating vs Reviews
The calculated correlation was 0.0572, indicating a very weak positive relationship.
This suggested that rating alone did not strongly explain differences in review engagement.
Current Price vs Rating
The calculated correlation was 0.1101, indicating a very weak relationship.
The analysis therefore provided limited evidence of a meaningful relationship between current price and rating.
These analyses however, reinforced an important lesson, that a single variable should not automatically be treated as the main driver of product performance.

8. Dashboard Design and Slicer Connections

The final stage of the project was to transform the analysis into an interactive dashboard. At the topmost of the Dashboard was the heading/header written in bold formart and a large font size. Beneath it was 5 key performance indicators commonly known as KPI's. They included
• Total Products: 112
• Average Current Price: Ksh 1,186.89
• Average Discount: 0.365089286
• Average Rating: 3.889474
• Total Reviews: 723
Beneath this KPI's were three slicers that allowed the dashboard to be filtered interactively. To do these it was paramount to Report connection by right clicking while your cursor is on a slicer and choosing "Report connection" , The slicers used were:

Price Category-it categorized data into High price, Low price and Medium Price.
Discount Category-it categorized data into High discount, Low discount, and Medium discount
Rating Category- that categorized data into average, excellent, poor and missing for missing values.

Charts were located beneath these slicers and used to communicate patterns in the data.
The dashboard was designed to allow users to move from an overall view of product performance to more specific product-level analysis.

Besides the chart I created a recommendation table that would inform the Jumia sellers.
It is also important to note that when building a dashboard, Presentability and neatness are key, the colors used in the graphs, dashboard background and headings must be consistent.

9. Key Findings

High-Engagement Products
The top 10 products by reviews accounted for 388 of the 723 total reviews, representing approximately 53.7% of all reviews in the dataset.
The 120W Cordless Vacuum Cleaner had the highest review count with 69 reviews, followed by the 137 Pieces Cake Decorating Tool Set with 55 reviews.
This shows that review engagement was concentrated among a relatively small group of products.
Top-Rated Products
The top 10 products by rating had an average rating of 4.94/5.
Seven of these products had a rating of 5.0, while the remaining three had ratings of 4.8.
These products could provide useful benchmarks for understanding characteristics associated with positive customer experiences.
Low-Rated Products
The bottom five products by rating had an average rating of 2.12/5, compared with the overall dataset average of 3.89/5.
The lowest-rated product was the Wall-Mounted Sticker Punch-Free Plug Fixer, with a rating of 2.0/5.
These products may require investigation before additional marketing or promotional resources are allocated to them.
Highly Discounted Products
The top 10 products by discount had an average discount of 54%.
The highest individual discount was 61%, recorded for the Pen Grips for Kids Pen Grip Posture Correction Tool for Kids.
However, the relationship analysis showed that discount percentage had only a very weak relationship with reviews. Therefore, larger discounts should not automatically be assumed to produce stronger engagement.

Screenshot of original data, cleaned data, pivot tables, and Dashboard.

To to attach a face to our long article I have uploded the four most vital images that were generated in this analysis but most of all a view of the dashboard that was created.

a) The original data

b) The Cleaned Data

c) Pivot tables

d) Dashboard

10. Business Recommendations

Based on the analysis, several recommendations can be made.
1. Prioritize High-Engagement Products
Since the top 10 products accounted for approximately 53.7% of all reviews, sellers could identify what these products have in common and prioritize similar products for visibility, promotion, and inventory planning.
2. Test Targeted Discounts
Medium-discount products recorded the highest total reviews at 348. However, the correlation between discount and reviews was very weak.
Rather than relying on large discounts across all products, sellers should test targeted promotional strategies and evaluate their results using multiple performance indicators.
3. Investigate Low-Rated Products
Products with consistently low ratings should be investigated before receiving additional promotional investment.
Possible areas for investigation include product quality, product descriptions, customer expectations, and fulfillment experience.
4. Use Highly Rated Products as BenchmarksThe highest-rated products can be examined to identify practices that may contribute to positive customer experiences.
These could include product quality, accurate descriptions, competitive pricing, and reliable fulfillment.
5. Use Multiple Metrics for Decision-Making
Because the relationships between price, discount, rating, and reviews were weak, sellers should avoid relying on a single metric when making business decisions.
A broader analysis incorporating sales, revenue, listing age, customer feedback, and other product-level factors would provide stronger evidence.

11. Limitations

This analysis has several limitations.

No sales or revenue data: The dataset does not contain actual sales, revenue, profit, or conversion data. Reviews were therefore used only as a proxy for customer engagement.
Missing ratings: 55 of the 112 products, or 49.1%, had no recorded rating. This limits rating-based comparisons.
No listing-age information: The dataset does not indicate how long each product had been available. Older listings may naturally have more reviews.
Correlation does not imply causation: The correlation analysis identifies relationships between variables but cannot establish that discounts, prices, or ratings directly cause changes in review engagement.
Limited customer information: The dataset does not contain detailed review comments, product-quality measures, seller information, or delivery performance.
Dataset size: The analysis covers 112 products and therefore should not automatically be generalized to every product on Jumia or the wider e-commerce market.

Conclusion

The Jumia Product Performance Dashboard transformed raw e-commerce product data into an interactive analytical tool covering 112 products.
The analysis showed that discount, rating, and current price had only weak relationships with the available review data. At the product level, however, engagement was concentrated among a smaller group of products, while a separate group of products had notably low ratings.
At the same time, the limitations of the dataset highlighted the importance of combining reviews with additional business information such as sales, revenue, listing age, and customer feedback. Additionally, the importance of having a good dashboard in a business was seen.

Project Resources

The complete project files are available in my GitHub repository and include original data, cleaned dataset, analysis, PivotTables, dashboard, and supporting documentation.

GitHub Repository link
https://github.com/gee-999/JUMIA-PRODUCT-PERFORMANCE-PROJECT

Getting Started with Excel for Data Analytics: From Basics to Data Cleaning.

Gloria Adhiambo Awinja — Sun, 30 Aug 2026 20:26:55 +0000

Introduction

Microsoft Excel is an application that was developed by Microsoft as a tool for organizing information in rows and columns, performing calculations and presenting data. Overtime, excel has evolved into a powerful tool for data analysis.
Data specialist adopted excel and begun using it for various purposes including data entry, cleaning, organizing, storing, calculating, and validating data among others.
In this article we will be learning the basics of excel and data cleaning in the process of data analysis. We will use example to see how we can convert raw data into meaningful data that can be used to generate powerful insights.

Overview

1.Understanding the Excel Interface
2.Data Types
3.Functions
4.Data Analysis

i) Understanding the Excel Interface.

The first time you open an excel worksheet you will be met by a book like image with a toolbar panel at the top referred to as a ribbon, beneath it on the left a bar referred to as a name box, and next to it is what is referred to as a formular bar, at the center and what covers the main area is a worksheet frame with rows and columns, with each having a column and row header. The rows are numbered from 1 to 1,048,576 while the Columns are named from A to XFD.

An example of a worksheet would be like the one bellow.

The different parts of a worksheet are precisely named in the image below:

For a better understanding we shall define the parts labelled in our image above.

Control Menu/Box- Opens a menu with commands for controlling the Excel window, such as minimizing, maximizing, or closing it.

Quick Access Toolbar-Provides quick access to frequently used commands, such as Save, Undo, and Redo.

Ribbon-The main area at the top of Excel that contains the different commands and tools used to work with a workbook.

Ribbon Category/Tab- Organizes Excel commands into different tabs, such as Home, Insert, Page Layout, Formulas, Data, and Review.

Title Bar- it displays the name of the current workbook along with the name of the Excel program.

Help Button- Opens Excel's help and support features, allowing users to find information or guidance when needed.

Worksheet Frame- This is the main part of the Excel window where the worksheet grid and its contents are displayed.

Select All Button- Selects the entire worksheet at once, including all rows and columns.

Name Box- Shows the location or name of the currently selected cell, such as A1. It can also be used to move quickly to a specific cell.

Active Cell-The cell that is currently selected and ready for data entry or editing.

Dialog Box Launcher- A small button that opens a dialog box containing additional settings and options for a particular group of commands.

Insert Function Button (fx)- Helps users find and insert functions into formulas without having to type the entire function manually.

Column Headings- The letters at the top of the worksheet that identify each column, such as A, B, C, and D.

Row Headings-The numbers along the left side of the worksheet that identify each row.

Formula Bar- Displays the contents of the selected cell and allows users to enter or edit data, text, and formulas.

Category Groups- Groups related commands together on the Ribbon, making it easier to find and use the tools needed for a particular task.

Worksheet Area- The main grid made up of rows and columns where users enter, organize, and view their data

workbook- is an excel file that contains one or more worksheets.

Split Boxes- Divide the worksheet window into separate sections so that different parts of the worksheet can be viewed or scrolled at the same time.

Scroll Bars- Allow users to move around the worksheet vertically or horizontally to view areas that are not currently visible.

Sheet Tabs- Allow users to switch between different worksheets within the same Excel workbook.

Insert Worksheet Button-Adds a new worksheet to the current workbook, making it possible to organize information on separate sheets.

Status Bar-Located at the bottom of the Excel window and displays useful information about the current worksheet, selected cells, and other activities.

View Buttons-Allow users to change how the worksheet is displayed on the screen.

Normal View-The standard Excel view used for entering, editing, and working with data in a worksheet.

Page Layout View- Shows the worksheet in a format similar to how it will look when printed, including page boundaries and margins.

Page Break Preview- Shows where Excel will divide the worksheet into separate pages when the document is printed.

Zoom Slider- Allows users to increase or decrease the size of the worksheet displayed on the screen, making it easier to view the data.

Data Types

Now having understood the excel interface we will look at the different data types catered for in the excel working space.
They include:

Numeric-data type that contains only numbers.
Text-data types that contain text and strings
Date-contains date which includes, days, months, and years.
Time-contains the time
Currency-contains the different currency like KES and $
Boolean-refers to the data that generates TRUE and FALSE values.

Functions

Functions refer to predefined formulas in excel that perform specific calculations.
In our article today we are going to look at text, numeric, date and COUNT Functions used in excel.

a.)Text function

In excel you will encounter text function like
Upper function, Upper()-is used to change a given text into uppercase.
Lower function, Lower()-is used to convert a given text into lowercase.

Proper function, Proper()- is used to convert a given text into proper case E.g. Mary Ann

Find function, Find()-its a function that is used to find a certain text within another text.

Left function, by Left()-is used to extract a specified number of text to the left of a text string.

Right function, right()-is used to extract a specified number of text to the right of a txt string.

Length function, Len()-is used to count the number of characters in a cell or text including spaces.

Mid function, mid()-extracts a specific number of characters from the middle of a string.

CONCAT function, CONCAT()-it is used to combine text from two or more cells into one

b.) Numeric Functions and Operators

Operators refer to symbols used in excel to perform calculations.
These operators include:

Arithmetic Operators which involve: i) Addition (+) ii) Subtraction (-) iii) multiplication (*) iv) Division (/) v) Exponent (^)

c.) Mathematical functions

i) Power()
ii) sqrt()

d.) Aggregate Functions

In addition we have aggregate functions which can be used to work on a group or range of numbers and give one output.
PRODUCT()
MIN()
MAX()
MODE()
MEDIAN()
SUM()
AVERAGE()

e.) Date Function

These are functions used to create, extract, calculate, or manipulate dates and times in excel
They include:
TODAY()
NOW()
DAY()
MONTH()
YEAR()
DATEDIF()
NETWORK()

f.)Counting Functions

These are functions that are used to count cells or values in a range.
They include
COUNT()
COUNTA()
COUNTBLANK()

e.)Conditional Aggregation Functions

We also have another set of functions that are used to calculate or summarize data only when certain conditions are met.
This functions can be used with both numerical and text data types. They include:
SUMIF()
SUMIFS()
COUNTIF()
COUNTIFS()
AVERAGEIF()

Data analysis

The process of analyzing data in excel begins with having data, then cleaning the data and ensuring each entry is in the correct order, and finally analyzing it to get answers to the questions at hand. We shall define some more labels that will be paramount in our journey to analysis our data.

Data cleaning: This is the process of finding and correcting or removing inconsistencies in a dataset so that the data is accurate and ready for analysis.

Data validation: refers to a feature that is in excel that controls the type of data that a user can enter into a cell, and if entered at a later time when we have our data it prevents entry of current data that is not coherent with the type of data specified.

Conditional Formatting : this refers also to an excel feature that automatically changes the outlook of a cell when they meet a specified condition.
Sorting: these refers to arranging data in a particular order.
sorting is unique for numeric, text, and date data types and custom filter where you use your own condition.
In numeric Sorting numbers are sorted from largest to smallest or smallest to largest
In text sorting sorting occurs either from A to Z or Z to A
While in date sorting its done from oldest to newest or newest to oldest.
Above that we have multilevel sorting where we sort data using more than one criterion, one after another.

Filtering: is the process of displaying only the data that meets specific conditions while temporarily hiding the other data.

Just like sorting filtering depends on the data type, where we have text filters having criterions like equals, does not equal, Begins with, Ends with, Contains, Does not contain, meanwhile number filters have criterions like Equals, Does not Equal, greater than, less than, less than or Equal to, Between, Top 10 and

date filters containing criterions like equals, before, after, Between, Today, Tomorrow, Yesterday, This week, Last week etc.
custom filters on the other hand is used where you use your own conditions.

Now we shall look at an example that puts to practice every information that has been discussed in the article.

Lets say we have a data called Nurses salary. Our data contains different column entries including Nurses id, first name, last name, age, country, year of employment, salary and the type of shift each does.

The image below shows a sample of the data we are working with.

It is important to note that before begin anything with your data you must have two worksheets, one which contains the original data, and the other named cleaned which you will be cleaning and carrying out your analysis

i) cleaning the data

The first thing is to remove duplicates- Select your data range or press Ctrl + A to select the whole table. Go to the Data tab on the top ribbon. Click Remove Duplicates.

1.cleaning numeric data example

Point to note in our data set is that the age column seems to have age appearing on the left side of the column instead of the right. All text appear on the left and numeric data to the right. Our data seems to have a problem with data type so we will go to Home-Number tab-select numeric

after correction

In the salary column you will also note blanks, where there is no entry, for numeric we leave it like that.

2.Cleaning date example

the first entry contains a different format of the date so we are required to change it into one format

3. An Example of cleaning Text Data

Firstly, check if there are any blanks in text columns and convert them to unknown Using ctrl+H that enables you to find the blanks and replace them.

then click on replace all

The text data my contain text not written in proper format like names.
for example look at our screenshot below.
we are required to right click in the columns header-insert column, and use the function Proper to change the names into proper format.

create yet another final column that you will copy the entries from the column first name p to, to avoid having reference errors when the column first name is tampered with.

delete the other columns and remain with the last created column named first name proper.

Conclusion

Excel provides a simple and practical starting point for data analytics because it allows users to organize, examine, clean, and prepare data within a single application. Understanding basic concepts such as rows, columns, cells, cell references, formulas, and functions creates a strong foundation for working with datasets. Through the practical dataset used in this article, it has been demonstrated that Excel can be used to identify and correct common data-quality problems such as missing values, duplicate records, inconsistent text entries, and incorrect data formats. Features such as sorting, filtering, tables, and functions make the cleaning process more efficient and help ensure that the resulting dataset is accurate and consistent. Overall, data cleaning is an important step in the data analytics process because the quality of analysis depends largely on the quality of the data being analyzed. By mastering these basic Excel skills, beginners can confidently move from raw data to a clean, structured dataset that is ready for further analysis and visualization.

PUSHING A LOCAL FOLDER TO GITHUB USING GIT AND SSH.

Gloria Adhiambo Awinja — Sat, 22 Aug 2026 21:30:01 +0000

Introduction

As a beginner in the data industry it is paramount to understand that projects are often created and stored locally on a computer before being shared or backed up online. Therefore, the first step into the journey of a data specialist becomes to learn the simplest yet most important thing: How to transfer these folders or files in your local PC into GitHub. This article will show you how to transfer locally created directory to GitHub using Git and a SSH key.
Git Bash commonly known as Git is a tool installed on your computer that tracks and manages changes made to your projects' files and folders. GitHub on the other hand, is an online platform where you can store your Git projects. The platform enables you to access, share, and collaborate on the project from anywhere. Meanwhile, an SSH key is a secure digital key that allows your computer to connect to your GitHub account without repeatedly entering a password.
In this article I will show you how to create or access your local folders and files using git and transfer them to a GitHub platform with the use of a SSH key.

Overview

The article will contain:

How to create a local Directory
Initializing Git
Adding Local Directories to the Staging Area
Committing the Project
Connecting the Local Repository to a Remote Repository
Understanding the SSH KEY
Pushing the Project to GitHub Using a SSH key

A. Creating a Local Directory

Steps to Creating a Local Directory.

NB: We will use Sales Project as an example of our project directory.

The first step in creating your local project directory is to check your current working directory. This is done by opening the Git terminal and writing the command:

pwd

This command simply asks, where am I right now?

After knowing where you are, you can now create a project directory in the location you are currently in or open a new location you would like the directory to appear.

Lets say we want to create a directory called Sales Project, and we would like it to be located in the Desktop directory. What we require is to open the desktop directory and create our sales project directory there.
To open the Desktop Directory we use a command cd which allows us to enter into a directory of our choice as long as the directory exists in our local PC. So our code would be:

cd Desktop

Now, having opened the desktop folder, we want to create our sales project directory. To create a folder we are required to use the command mkdir.The code appears as:

mkdir "sales Project"

Now, when you check your Desktop, you should be able to see a folder called Sales Project.

You can also check for the presence of the folder by using ls under the directory Desktop. ls is simply a command we use to show the files and folders in your current location.

After creating our sales project directory we are required to create a README.md file. A README.md file is a document that is created using markdown language and is used to explain what the project is about, the tools used, how it works, and other important information concerning the project. It helps users understand a project without having to read the code.

To create it we use the command touch , the code appears as:

touch README.md

Afterwards we can create a folder That will contain all the data used in the project in question. For example our data could entail excel files, screenshots and pictures. Lets say our folder is called DATA, then we will have to create it by coding:

mkdir DATA

With these steps we would have successfully created our folder called Sales Project, which contains a README.md file and a folder where we can place the data we are working on called DATA. So in summary the codes of creating this directory in our PC would be:

pwd
cd Desktop
mkdir "Sales Project"
cd Sales Project
touch README.md
mkdir DATA

B. Initializing Git

When we say Git initialization we refer to the process of enabling Git to start tracking a particular folder as a Git repository.
In our example, when we initialize git we are enabling the ordinary directory we called Sales Project to be turned into a git repository where changes made to it can be tracked.
To enable this we use the command:

git init

c. Adding Files to the Staging Area

After initializing, we are required to tell Git which changes we want to include in our next commit. For this to be possible we use the command:

git add

Now depending on the changes in the directory you want to stage you will use different ways to initialize. For instance, if you want to add everything in the directory and its subdirectories to the staging area we use the command:

git add .

if you want to select specific changes then you select the specific areas you want to add to the staging area. For example, we want to add the changes in the README.md file alone we will initiate a:

git add README.md

if we need changes committed in the DATA folder only we will have:

git add DATA/

D. Committing the Project

A commit refers to a saved checkpoint of the project. It records the changes that you had prepared in the staging area.
The command used to commit is:

git commit -m " what you are committing"

The message inside the quotation marks describes what the commit contains and helps in understanding the project later.
taking the example of our project we could write

git commit -m "Sales project"

E. Connecting the Local Repository

After committing we are now required to create a repository on GitHub. GitHub, acts as a remote location where we can store and access the project online.

The remote repository can be given a name , and a description, and it will generate a SSH key URL which will be used in connecting the local repository to GitHub. The command used will be:

git remote add origin

Here origin means the name given to GitHub repository connected to the local project. If we use the example of our project the command would appear as:

git remote add origin git@github.com:username/repository.git

with the URL written after origin being an SSH remote URL that connects the local Git repository to the GitHub repository.

Understanding the SSH KEY

To connect your local Git repository to GitHub securely, you require a key called the secure shell key or commonly called the SSH key.
It is generated and obtained after you have configured the Git Bash, the key is generated using the command:

ssh-keygen -t ed25519 -C "Your email@example.com"

Consequently, Git bash will ask you to enter a passphrase twice for the purpose of confirmation. Then it will generate a private key and a public key, which helps us to connect the local Git repository to GitHub securely.
For safety purposes we will use the public key written with .pub which stands for public.

The command
cat ~/.ssh/id_ed25519.pub|clip

shows us how to copy and clip the key.

After acquiring this public key we are required to go to the GitHub account, and open settings then click SSH key, then New SSH Key and add the SSH key there.

Afterwards return to Git Bash and test the connection using the command

ssh -T git@github.com

Once the connection is successful, we now know we will be able to connect the local repository with the remote repository using the command;

git remote add origin git@github.com:username/repository.git

Allowing GitHub to verify that the computer is authorized to access the repository.

F. Pushing the Project to GitHub

After connecting the project to GitHub, check what your branch is called using the command:

git branch

A branch in this context refers to a separate version of Git project that allows you to make changes without directly affecting the main branch. Meanwhile, the main branch is the primary branch of a Git repository which contains the main, stable version of your project.

Its important that the local branch and remote branch you are pushing to match. In the past the branch was commonly referred to as master but with time the modern GitHub default branch evolved and begun to be called main.

So for instance if your default branch is master and your remote branch was created as main you will be required to change it to main and hence, use the command

git branch -M main

This changes your branch to main.

Now after dealing with the branch, the next step is to push the project and it is done using the command:

git push -u origin main
or

git push -u origin master

depending with what your remote repository is called. After pushing your project successfully, the repository will appear in your GitHub account marking the end of the process of creating and pushing a directory to become a repository from the local PC to a remote GitHub repository.

This image shows the steps of pushing a local directory to GitHub using git.

Now lets have a code example showing the flow of events in the process of pushing a locally created directory to GitHub using the SSH key:

example
Lets consider that we already set up our SSH key and we want to push a locally generated project from the git bash to GitHub using the SSH key.
While using our example of Sales Project as our directory, this is how the flow of creating a directory and pushing it would look like:


pwd 
cd Desktop
mkdir "Sales Project"
cd "Sales Project"
touch README.md
mkdir DATA
cd .. ##this allows you to go a step back from current directory.
     ## this one for instance will take you back to README.md
echo "sales" >README.md # enables writing text into a file
cat README.md # displays contents of a file in the terminal
nano README.md # enables editing of README.md file
git init
git status ##Helps check what is happening in your git project
git add .  
git commit -m "Sales Project"
git remote add origin git@github.com:username/repository.git                                                   
git branch
git push -u origin main

Conclusion

In conclusion, moving a project from a local computer to GitHub involves a clear sequence of steps which involve creating and initializing the repository, staging and committing changes, establishing an SSH connection, linking the local repository to a remote repository, and pushing the committed work to GitHub. Each stage serving a specific purpose in maintaining a reliable version-controlled project. Understanding this workflow provides a practical foundation for managing projects, tracking changes, and collaborating through Git and GitHub.