DEV Community: Gloria Adhiambo Awinja

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.