DEV Community: Faith

Filtering Data in SQL: A Beginner’s Guide to WHERE using AND, OR, LIKE and Friends

Faith — Tue, 27 Oct 2026 16:43:58 +0000

Introduction

As they say SQL is the backbone or foundation of data not really sure which one it is but, all that to say SQL forms a crucial part in data and data projects. At the moment there is tans and tans of data being produced all the time, increasing the scope of work for any data professional. Hence the need for filtering and that why we need the WHERE clause in SQL alongside its partners that make work easier and bearable.

The WHERE clause is used to filter rows based on one or more conditions. It ensures that queries return or modify only the required records.

Filters data based on specified conditions.
Used with SELECT, UPDATE and DELETE statements.
Works with comparison and logical operators.

Filtering using WHERE

Comparison Operators

They come in handy when comparing two values and filters the result set based on a specific condition as well as help check for equality, range, or inequality
Make SQL queries powerful and precise
They include: =, >, <, >=, <=, <>

Syntax

SELECT * FROM TABLE_NAME 
WHERE ATTRIBUTE CONDITION_OPERATOR GIVEN_VALUE;

Examples from our fictional hospital dataset:

Listing all patients from Kisumu county. ( = , equal to )
select * from patients where county ='Kisumu';

ListIng all patients who are not in the General department. ( <> or != , note equal to)
select * from patients where department <> 'General';

Showing the first name, department and bill amount of patients whose bill is greater than 100,000.
select first_name, department, bill_amount from patients where bill_amount > 100000;

Showing patients aged 18 or younger. ( <= , less than)
select * from patients where age <= 18;
Lising patients admitted on or after 1 April 2026. ( >= on a date)
select * from patients where admission_date >= '2026-04-01';

All these examples demonstrate comparison of one variable from another in the same column.

Logical operators AND, IN and BETWEEN

Used to test conditions in queries, returning results as TRUE, FALSE or UNKNOWN. They help in combining, negating and comparing conditions, enabling precise data retrieval and filtering. i.e IN,

AND Operator

AND combines multiple conditions in an SQL query and returns only the records that satisfy all the specified conditions.

Example: Listing female patients in the Maternity department. ( AND )
select * from patients where gender = 'Female' and department = 'Maternity';

Output:

NOT Operator

NOT is used to reverse the result of a condition, returning TRUE when the condition is FALSE. It is typically used to exclude records that match a specific condition, making it useful for filtering out unwanted data.

An example would be,
Listing patients who are not in Cardiology, Orthopedics or Emergency.

Query
select * from patients where department not in ( 'Cardiology');

Output

OR Operator

OR combines multiple conditions in a SQL query and returns TRUE if at least one of the conditions is satisfied. It is ideal for situations where you want to retrieve records that meet any of several possible conditions.

Example: Listing patients from Nairobi or Mombasa, written with OR .
select * from patients where county = 'Mombasa' or county ='Nairobi';
Output

Range/List

IN Operator

IN checks whether a value matches any value in a specified list, providing a concise alternative to multiple OR conditions.

Example: Listing patients covered by SHA, AAR or Britam.
select * from patients where insurance in('SHA', 'AAR', 'Britam');
Output:

BETWEEN OPERATOR

BETWEEN in SQL checks whether a value lies within a specified range, including both the lower and upper limits.

Example
Listing patients who are not aged between 18 and 60.
select * from patients where age not between 18 and 60;

Output

Query
Listing patients who are not in Cardiology, Orthopedics or Emergency.
select * from patients where department not in ( 'Cardiology');

Output

NULL

If a field in a table is optional, it is possible to insert or update a record without adding any value to this field. This way, the field will be saved with a NULL value.

A NULL value represents an unknown, missing, or inapplicable data in a database field. It is not a value itself, but a placeholder to indicate the absence of data.

IS NULL Syntax

SELECT column_names
FROM table_name
WHERE column_name IS NULL;

Example: Listing patients with no email address.
select * from patients where email is null;

Output

IS NOT NULL Syntax

SELECT column_names
FROM table_name
WHERE column_name IS NOT NULL;

Example Listing the first name, last name and insurance of patients who have insurance. (
select first_name, last_name, insurance from patients where insurance is not null;

Output

Conclusion

LIKE and ILIKE

PostgreSQL is a case-sensitive language in order to make it a case-insensitive language during pattern matching we make use of the ILIKE operator.

ILIKE operator works the same way as a LIKE operator but makes the language case-insensitive. Both the operators are used for pattern matching in PostgreSQL.

Example Listing patients whose first name starts with K.
select * from patients where first_name like 'K%';
Gives this Output

While
select * from patients where first_name like 'k%';
Returns zero rows as there are no rows where the first_name starts with lowercase k.

Instead we can use this query;
select * from patients where first_name ilike 'k%';
As it returns the same number of columns as the first query we tried.
select * from patients where first_name like 'K%';

Exploring Window Functions, Joins, Subqueries and CTEs in SQL

Faith — Sun, 18 Oct 2026 09:34:01 +0000

Introduction

As I explore databases and SQL as part of my learning curve in becoming a data analyst. It is inevitable to learn about Functions in SQL. Today, I land at exploring Window Functions, Joins, Subqueries and Common Table Expressions. These functions and tools come in handy when writing queries that are necessary in answering pertinent questions using data. I'll be using a fictional Hospital Data set to demonstrate the said functions and methods.

SQL Window Functions

SQL window functions allow performing calculations across a set of rows that are related to the current row, without collapsing the result into a single value. They are commonly used for tasks like aggregates, rankings and running totals. The OVER clause defines the “window” of rows for the calculation.

PARTITION BY: It divides the data into groups using Partition by.
ORDER BY: It specifies the order of rows within each group using order by.

With this, functions such as SUM(), AVG(), ROW_NUMBER(), RANK() and DENSE_RANK() can be applied in a controlled way.

Syntax:

SELECT column_name1, 
       window_function(column_name2) 
       OVER ([PARTITION BY column_name3] [ORDER BY column_name4]) AS new_column
FROM table_name;

window_function: Function used for calculation/ranking

column_name1: Column(s) to display
column_name2: Function column
column_name3: PARTITION BY column
column_name4: ORDER BY column
new_column: Result alias
table_name: Source table

SQL window functions are mainly of two types: aggregate window functions and ranking window functions.

Aggregate Window Functions

Aggregate window functions calculate aggregates over a window of rows while retaining individual rows. Common aggregate functions include:

SUM(): Sums values within multiple rows.
AVG(): Calculates the average value a window
COUNT(): Counts the rows within a window.
MAX(): Returns the maximum value in the window.
MIN(): Returns the minimum value in the window.

Example: Using AVG(), we will calculate the average hospital bill along side different insurance providers.

Query:

SELECT patient_id, ward_id, insurance_provider, total_bill_kes,
       AVG(total_bill_kes) OVER (
           PARTITION BY insurance_provider
       ) AS avg_bill
FROM visits;

Output:

This average value is displayed for each patient belonging to the same insurance_provider.

Ranking Window Functions

These functions provide rankings of rows within a partition based on specific criteria. Common ranking functions include:

RANK(): Assigns ranks to rows, skipping ranks for duplicates.
DENSE_RANK(): Assigns ranks to rows without skipping rank numbers for duplicates.
ROW_NUMBER(): Assigns a unique number to each row in the result set.
PERCENT_RANK(): Shows the relative rank of a row as a percentage between 0 and 1.

RANK() Function are used to assign ranks to rows within a group based on a specific order. Ranking functions are commonly used to organize and analyze data. Some common ranking functions include:

Example: Using RANK(), we will rank payment_method _by _total_bill, allowing gaps in ranks when total_bills are equal.

SELECT patient_id, total_bill_kes, payment_method,
       RANK() OVER (
           PARTITION BY payment_method
           ORDER BY total_bill_kes DESC
       ) AS bill_rank
FROM visits;

output:

DENSE RANK() gives the same rank to rows with equal values. It then continues with the next number without skipping, keeping the ranking sequence continuous.
DENSE_RANK() works like RANK(), but it ensures the ranking sequence has no gaps.

ROW NUMBER() Function gives a unique number to each row in the result set. It increments by 1 for every row, even if values are the same, so no two rows have the same number.

Example: Using ROW_NUMBER(), we will assign a unique number to each row based on years_of_experience order.

--Rownumber()
SELECT doctor_name, doctor_gender, doctor_specialty, doctor_experience_years,
       ROW_NUMBER() OVER (
           PARTITION BY doctor_specialty
           ORDER BY doctor_experience_years DESC
       ) AS experience_row_no
FROM doctors;

output:

PERCENT RANK() shows where a row stands compared to others in the same group.

SQL Joins

SQL Joins are used to combine data from two or more tables based on a related column.

Matching records using common columns.
Improving data analysis by combining related information.
Creating meaningful result sets from separate tables.z

INNER JOIN

INNER JOIN is used to retrieve rows where matching values exist in both tables. It helps in:

Combining records based on a related column.
Returning only matching rows from both tables.
Excluding non-matching data from the result set.
Ensuring accurate data relationships between tables.

Syntax:

SELECT A.column1, A.column2, B.column1, ...
FROM tableA AS A
INNER JOIN tableB AS B
ON A.matching_column = B.matching_column;

Example of INNER JOIN:

To find doctors with patients with follow up needs.

SELECT A.doctor_id, A.follow_up_required
FROM visits AS A
INNER JOIN doctors AS B
ON A.doctor_id = B.doctor_id;

output:

LEFT JOIN

LEFT JOIN is used to retrieve all rows from the left table and matching rows from the right table. It helps in:

Returning all records from the left table.
Showing matching data from the right table.
Displaying NULL values where no match exists in the right table.

Syntax:

SELECT A.column1, A.column2, B.column1, ...
FROM tableA AS A
LEFT JOIN tableB AS B
ON A.matching_column = B.matching_column;

In this example, the LEFT JOIN retrieves all rows from the patients table and the matching rows from the visits table based on the patient_id column.

select A.patient_id, A.patient_name, A.county
from patients as A
left join visits as B
on A.patient_id = B.patient_id;

output:

RIGHT JOIN

RIGHT JOIN is used to retrieve all rows from the right table and the matching rows from the left table. It helps in:

Returning all records from the right-side table.
Showing matching data from the left-side table.
Displaying NULL values where no match exists in the left table.
Performing outer joins, also known as RIGHT OUTER JOIN.

Syntax:

SELECT A.column1, A.column2, B.column1, ...
FROM tableA AS A
RIGHT JOIN tableB AS B
ON A.matching_column = B.matching_column;

Example:

select A.diagnosis_id, A.diagnosis_name, B.total_bill_kes
from diagnosis as A
left join visits as B
on A.diagnosis_id = B.diagnosis_id;

output:

FULL JOIN

FULL JOIN is used to combine the results of both LEFT JOIN and RIGHT JOIN. It helps in:

Returning all rows from both tables.
Showing matching records from each table.
Displaying NULL values where no match exists in either table.
Providing complete data from both sides of the join.

Syntax:
SELECT A.column1, A.column2, B.column1, ...
FROM tableA AS A
FULL JOIN tableB AS B
ON A.matching_column = B.matching_column;

Example:

select A.procedure_id, A.procedure_name, B.patient_id, B.total_bill_kes
from procedures as A
left join visits as B
on A.procedure_id = B.procedure_id;

Full join combines the contents of both the procedures table as well as the visits table connecting the two tables with a common column procedure_id.

output:

Self Join

Self-join allows us to join a table itself. It is useful when a user wants to compare the data (rows) within the same table.

Cross Join

Cross join allows us to join each and every row of both the tables. It is similar to the cartesian product that joins all the rows

Common Table Expression (CTE) in SQL

A Common Table Expression (CTE) is a temporary result set in SQL that you can reference within a single query. CTEs simplify complex queries, make them easier to read and can be reused multiple times within the same query. It is used for:

Performing recursive operations, such as traversing hierarchical data.
Breaking down multi-step calculations into manageable parts.
Replacing nested subqueries in complex data retrieval tasks.
Consider our visits table containing patient visits details such as visit_id, patient_id, diagnosis_id, total_bill_kes and patient_satisfaction_score. We will use this table to demonstrate Common Table Expression (CTE) examples.

Example: Calculate Average bill by patient admission type
This example uses a CTE to find the average bill of the different admission types the patients were under, making the query simpler and easier to read.

Syntax:

WITH cte_name AS (
    SELECT query
)
SELECT *
FROM cte_name;

cte_name: A unique name for the CTE expression.
query: A valid SQL query that returns a result set, which will be treated as a virtual table within the main query.
SELECT: The main query that can reference the CTE by its name.

Query:

WITH avg_total_bill_kes AS (
    SELECT admission_type, AVG(total_bill_kes) AS avg_bill
    FROM visits
    GROUP BY admission_type
)
SELECT *
FROM avg_total_bill_kes;

Output:

The WITH clause defines a CTE named avg_total_bill_kes.
The main query references this CTE to retrieve the average bill for each admission type.

Recursive Common Table Expression

A recursive CTE references itself to retrieve hierarchical data, such as employee-manager relationships. Use MAXRECURSION to prevent infinite loops. It consist of two parts:

Anchor member: The initial query that selects the base case (e.g., top-level managers).
Recursive member: The query that references the CTE itself, pulling the next level of data.

Uses of CTEs

CTEs (Common Table Expressions) help simplify and organize complex SQL queries.

Breaks complex queries into small, reusable parts.
Makes queries easier to read and understand.
Helps work with hierarchical data using recursion.
Limitations
While useful, CTEs come with a few practical constraints.

Temporary: A CTE works only while the query runs, then it disappears.
Performance: On very large data, CTEs can be slower if reused many times.
Restrictions: Some databases limit using CTEs with INSERT, UPDATE or DELETE.

CTE vs. Subqueries

CTE Can be referenced multiple times while Subqueries are typically used once.
CTE Improves readability for complex queries. Subqueries can become difficult to read when nested.
CTEs are Optimized for multiple references. On the other hand, subqueries may be less efficient for repeated operations.

SQL Subquery

A subquery in SQL is a query nested inside another SQL query. It allows complex filtering, aggregation and data manipulation by using the result of one query inside another. They are an essential tool when we need to perform operations like:

Apply aggregate functions like SUM, COUNT or AVG dynamically.
Update data using values from other tables.
Delete rows based on conditions returned by another query.

Query:

SELECT * FROM visits
WHERE total_bill_kes > ( SELECT AVG(total_bill_kes) FROM visits );

output:

SQL Clauses for Subqueries

Clauses that can be used with subqueries are:

Filters rows in the outer query based on the results returned by the WHERE clause.
Treats the subquery as a temporary (derived) table that can be queried like a normal table using the FROM clause.
Filters grouped or aggregated results using values produced by the HAVING clause.

Single-Row Subquery

A single-row subquery is a subquery that returns only one value.

Returns exactly one row as the result.
Commonly used with comparison operators such as =, >, <
Example:

SELECT * FROM patients
WHERE patient_age = (SELECT MAX(patient_age) FROM patients);

Multi-Row Subquery

A multi-row subquery is a subquery that returns more than one value.

Returns multiple rows as the result.
Requires operators that can handle multiple values, such as IN, ANY or ALL

-- Multi-Row Subquery
SELECT * FROM patients
WHERE patient_id IN (SELECT patient_id FROM patients WHERE county = 'Nairobi');

output:

Correlated Subquery
A correlated subquery is a subquery that depends on the outer query for its values.

A dependent subquery: it references columns from the outer query.
Executed once for each row of the outer query, making it slower for large datasets.

SELECT A.patient_id, A.patient_name
FROM patients A
WHERE A.patient_age > (SELECT AVG(patient_age) 
                  FROM patients
                  WHERE patient_id = patient_id);

output:

Fetching Data Using Subquery in WHERE Clause

This example uses a subquery in the WHERE clause. The inner query finds roll numbers of students in Section 'A' and the outer query displays their details from the Student table.

Scalar Subqueries

When a subquery returns only a single data value, which will be a single row with single column, then it is called a Scalar subquery.

Nested Subqueries

When there are SQL SELECT queries inside a Subquery then it can be called Nested Subqueries. There can be upto 32 levels of nested queries in a single Outer or Main SQL Query statement.

Query:

Select * from visits Where patient_id IN (Select patient_id from patients where patient_age > 
(Select patient_id from patients where patient_id=10));

output:

Benefits of Using Subqueries in SQL Server

Helps to avoid Code duplication

Subqueries are useful in avoiding Code duplication or not repeating complex logic in multiple places. This reduces the risk of errors and improves code maintainability.

Subqueries improve Code Readability

Subqueries can break large code and complex logic into easy to understand and more manageable code blocks.

Useful to perform Complex calculations or data manipulations

Subqueries can be used to perform complex calculations or logic by dividing a single statement query into subqueries to get data from different tables or calculating aggregate values based on dynamic business cases.

Helps increase Flexibility

Subqueries can be used to filter data dynamically based on the result from other queries, which provides greater flexibility.

Provides data retrieval from multiple tables
Subqueries are useful when we need to combine data from multiple tables in a single query.

Conclusion

Subqueries and functions are an important part of data analysis and querying. Here are a few thing I have taken note
While using Window Function Partition carefully: Without Partition by, the whole table is treated as one group.
Check Order by : It controls the calculation order in the window.
Optimize performance: Window functions can be slow on large datasets; use indexes if needed.

As for JOINS We can also write JOIN instead of INNER JOIN. JOIN is same as INNER JOIN. Same case for LEFT OUTER JOIN and RIGHT OUTER JOIN instead of LEFT JOIN or RIGHT JOIN, we can use JOIN, since they are the same.

Some databases such as MySQL does not support FULL OUTER JOIN. To get the same result, you can simulate it using a UNION of a LEFT JOIN and a RIGHT JOIN.

All in all there is no end to learning, everyday as I practice I learn something and or refine my skills. Which is excepted. Sometimes the weight of what lies ahead can be heavy but as long as I am building skills day by day that is what matters.

JCars Logistics Power BI project.

Faith — Sun, 27 Sep 2026 12:00:47 +0000

Introduction

JCars Logistics is a fictional business that imports, sells, and delivers vehicles to customers across different regions in Kenya. We have a dataset that contains information about its sales transactions, vehicles, customers, branches, sales representatives, payments, deliveries, logistics costs, returns, cancellations, and customer experiences.
It operates a diverse network with 276 orders across 10 sales representatives, 14 branches, and 272 car makes serving 276 unique customers.
Using this dataset, I have cleaned, analyzed, modeled and finally prepared an excecutive dashboard on the performance and status of the business in terms of different metrics, all of this in PowerBI.

Data Cleaning

While the business demonstrates operational scale, critical data quality issues and operational challenges require immediate attention to ensure sustainable growth and accurate performance measurement. The presented data was so messy with numerous inconsistencies and blanks through out most of the columns.

Inconsistent formatting

This format gave me the most headache, starting us strong is formatting, most columns had variables written in different formats. The order ID column having mixed numbers and varied alphabets eg LC1000, LCL1001, ORD1004. All of which have to be standardized in order to proceed with analysis. The different Date columns proved the most inconsistent with some dates being numerical figures for instance. The currency for revenue, unit cost and delivery fees were in different currencies and numeric formats.
other text columns contain numeric data such as 3 cars. Finally, different naming conventions. Example: "Toyota," "toyota," "TOYOTA," "Toyta" treated as different car makes
Example: "Rift Valley," "RIFT VALLEY," "Rift-Valley," "rift valley," "Riftvalley" counted as separate regions

Cleaning this data, involved manual formulas due to the many discrepancies, mostly including Replacing Values and Errors in Power Query.

Data Modelling

After cleaning my data, I created relationships on power query connecting my fact table to the ** 7 dimension tables** namely:

Dim Customers
Dim Sales Rep
Dim Car Qualities
Dim Location
Dim Lead Source
Dim Dates
Dim Payments

On Power Query, I created the Dimension Tables by referencing my clean data instead of Duplicating. Thereafter I selected only the columns I needed in the particular tables and removed other columns. To only retain unique values in my dimension tables I removed duplicates and created new Indexes.
The new Indexes acted as my Primary Key In my created Dim Tables for all the tables I created since none was provided in the flat table that was provided.
In order, to create relationships between the Fact table and the Dimension tables. I merged the Fact table with every dimension table with the corresponding common Column, thereafter doing away with the other columns and retaining the foreign key in the fact table.
I maintained a Left Outer join since I used the Fact table as my left table and the dimension tables as the table on the right.
Six of the relationships created were many to one, with only one, Customers Table having One to One cardinality, since the number of customers matched the number of transactions. Mapping the specific columns from both tables together.

Luckily having created the relationships the right way after so many attempts, Power BI picked up on the relationship, so I did not have to do it manually.

Dashboard

Recommendations and Business Insights

To uphold Data Governance measures, standardization of all data entry mechanisms is necessary by:

Replace free-text fields with dropdown selections where possible
Implement validation rules that reject non-standard entries and variables

Audit historical data: Run de-duplication scripts on region, car make, and branch names Reconcile currency entries (establish single currency or documented conversion rates)

Flag and correct negative values and #VALUE! errors
System implementation:
Deploy data quality rules in point-of-entry systems
Establish monthly data audits

Key Findings

Phone-based leads outperform by generating higher ratings

Payment status showed that a whooping 55%of the cars being fully paid.

Prado TX had the most revenue recorded of 135B.

Toyota as a brand, dominates with 20% of all orders, as compared to other car brands.
As for the Sales Representatives, Faith Achieng records the most units sold as Grace Njeri records the most profit of 35M.

Diesel and Hybrid supremacy: Both fuel types generate 4.0+ average satisfaction, significantly exceeding petrol (3.1-3.85)
Petrol dominance but mediocrity: ~47% of order volume but lowest satisfaction metric commodity market with undifferentiated product
EV emerging market: Only 3 orders but environmental trends and government incentives will drive growth

Referral returns: High-expectation customers referred by existing buyers who learn vehicle has issues
Instagram returns: Young demographic with higher return rates, possibly due to online purchase impulse or photo-reality mismatch
Corporate Tender: Large-volume orders with complex negotiations may lead to specification mismatches

CONCLUSION

JCars operates a substantial business with 276 orders, 276 customers, and 10 sales representatives across 14 branches. However, the organization faces critical challenges across data quality, payment collection, operational delivery, and sales performance consistency.
The immediate priority is implementing standardized data governance without it, all performance metrics remain suspect. Simultaneously, urgent intervention is required for Nairobi HQ's 37.5% return rate, Mombasa Port Yard's operational failures, and the concerning 18.5% payment cancellation rate.

The organization has strong underlying assets (high-volume branch network, competent sales leaders like Grace Njeri, quality products like Nissan. Focused execution on these recommendations will lead to exponential growth.

Data Modelling, Relationships & Joins

Faith — Sat, 12 Sep 2026 12:52:11 +0000

Data Modelling in Power BI

Data modeling is the process of analyzing and defining all the different data types a business collects and produces, as well as the relationships between those bits of data. By using text, symbols, and diagrams, data modeling concepts create visual representations of data as it’s captured, stored, and used at the business.
As business determines how data is used and when, the data modeling process becomes an exercise in understanding and clarifying data requirements.

By modeling data, you can document what types of data you have, how you use it, and the data management requirements surrounding its usage, protection, and governance. The benefits of data modeling include:

Creating a structure for collaboration between different teams.
Revealing opportunities for improving business processes by defining data needs and uses.
Saving time and money on IT and process investments through appropriate planning.
Reducing errors (and error-prone redundant data entry) while improving data integrity.
Increasing the speed and performance of data retrieval and analytics by planning for capacity and growth.
Setting and tracking target key performance indicators tailored to your business objectives.

Types of Schemas

A snowflake schema is another way of organizing data. In a schema, dimension tables are split into smaller sub-dimensions to keep data more organized and detailed, just like snowflakes in a large lake.

Star Schema

Structure: A star schema resembles a star with a central fact table containing transactional data (e.g., sales data) surrounded by dimension tables (e.g., product details, customer information, time hierarchy ). These dimension tables are connected to the fact table through foreign keys.
Focus: Optimized for analytical workloads. The pre-aggregated data and clear relationships between tables enable efficient querying and analysis of trends and patterns.
Pros: Fast and efficient for complex analytical queries, reduces redundancy compared to fully flat tables, simplifies data modeling for data warehouses.
Cons: Might not be ideal for storing highly granular data or handling frequent schema changes, can be less efficient for operational tasks like real-time data updates.

Flat tables

Structure: Flat tables store all relevant data points for an entity (e.g., a product) within a single table, often with numerous columns to represent various attributes. This approach prioritizes ease of data access and flexibility.

Focus: Optimized for operational tasks and handling large volumes of detailed data. The denormalized structure allows for faster reads and writes of individual entities.
Pros: Simpler data access for specific entities, efficient for writes and reads of detailed data, can be flexible to accommodate schema changes.
Cons: Can lead to significant data redundancy, potentially slower for complex analytical queries that require joins across multiple tables, requires careful management to avoid data inconsistency.

Snowflake Schema

Structure Snowflake Schema is also a type of multidimensional model used for data warehouses. In the snowflake schema, the fact tables, dimension tables and sub-dimension tables are included. This schema forms a snowflake structure with fact tables, dimension tables and sub-dimension tables
Focus Best for Flexibility and Data Integrity: If we need to handle large datasets with multiple levels of hierarchy and a high degree of normalization, the Snowflake Schema offers greater flexibility. It’s perfect for maintaining data integrity across complex datasets.
Pros : Ideal for large organizations dealing with large, normalized datasets or those with frequent updates, like customer or inventory management systems. It minimizes redundancy and improves storage efficiency.
Storage Considerations: Snowflake is more storage-efficient due to its normalized structure, making it a great choice for scenarios with complex, high-volume data.

Fact Tables and Dimension Tables

In data warehousing, fact tables and dimension tables are key components of star or snowflake schemas. Fact tables store numeric data like sales or order amounts and include foreign keys linking to dimension tables. Dimension tables provide context with descriptive details like product names or customer demographics. The main difference between Fact or Reality table and the Dimension table is that dimension table contains attributes on that measures are taken actually table. Below are the main differences between the two:

Relationships in Power BI

A model relationship propagates filters applied on the column of one model table to a different model table. Filters will propagate so long as there's a relationship path to follow, which can involve propagation to multiple tables.

Relationship paths are deterministic, meaning that filters are always propagated in the same way and without random variation. Relationships can, however, be disabled, or have filter context modified by model calculations that use particular Data Analysis Expressions (DAX) functions.

Cardinality

Each model relationship is defined by a cardinality type. There are three cardinality type options, representing the data characteristics of the "from" and "to" related columns. The "one" side means the column contains unique values; the "many" side means the column can contain duplicate values.

The three) options, together with their shorthand notations, are described in the following list:

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

When you create a relationship in Power BI Desktop, the designer automatically detects and sets the cardinality type. Power BI Desktop queries the model to know which columns contain unique values. For import models, it uses internal storage statistics; for DirectQuery models it sends profiling queries to the data source. Sometimes, however, Power BI Desktop can get it wrong. It can get it wrong when tables are yet to be loaded with data, or because columns that you expect to contain duplicate values currently contain unique values. In either case, you can update the cardinality type as long as any "one" side columns contain unique values (or the table is yet to be loaded with rows of data).

One-to-many (and many-to-one) cardinality

The one-to-many and many-to-one cardinality options are essentially the same, and they're also the most common cardinality types.

When you configure a one-to-many or many-to-one relationship, choose the one that matches the order in which you related the columns. Consider how you would configure the relationship from the Product table to the Sales table by using the ProductID column found in each table. The cardinality type would be one-to-many, as the ProductID column in the Product table contains unique values. If you related the tables in the reverse direction, Sales to Product, then the cardinality would be many-to-one.

One-to-one cardinality

A one-to-one relationship means both columns contain unique values. This cardinality type isn't common, and it likely represents a suboptimal model design because of the storage of redundant data.

Many-to-many cardinality

A many-to-many relationship means both columns can contain duplicate values. This cardinality type is infrequently used. It's typically useful when designing complex model requirements. You can use it to relate many-to-many facts or to relate higher grain facts. For example, when sales target facts are stored at product category level and the product dimension table is stored at product level.

Filter Direction

Relationship Filters

In Power BI, when two tables are connected, filters can flow between them to control which data is visible in visuals. This flow is determined by the filter direction in the relationship settings.

There are two types:

Single-direction filter:

Allows filter context to flow from one table to another (most common).
Bi-directional filter: Allows filter context to flow in both directions between connected tables.
Single-Direction Filters
Best For:
Star schema models (fact and dimension tables)
Maintaining predictable filter behavior
Optimizing model performance
In a star schema, filter direction should typically flow from the dimension tables (e.g., Customers, Products) to the fact tables (e.g., Sales, Transactions). This setup reflects how users usually analyze data: e.g., sales by customer, not customers by sale.

Example:
You have a Sales table and a Products table. You want to filter sales by product category. The relationship should allow filters to flow from Products to Sales (one-to-many).

Bi-Directional Filters

Use with Caution:
Complex reporting scenarios
Many-to-many relationships
Role-based security (RLS) configurations
Bi-directional filtering lets two tables filter each other. While powerful, it can cause:

Ambiguous relationships
Unexpected results in visuals
Performance degradation, especially on large datasets
Example:
Imagine you have a Sales table and a Regions table, but not every sale is assigned to a region. A bi-directional filter might seem helpful, but it can lead to wrong totals or slow down the report.

Best Practices
Default to Single Direction
It’s simpler, faster, and more stable in most cases.

Use Bi-Directional Filters Sparingly
Only when absolutely necessary, and understand the impact on model performance.

Consider Using DAX Instead
Functions like USERELATIONSHIP() or CROSSFILTER() can give you more control without needing a full bi-directional relationship.

Watch Out for Ambiguity
If Power BI warns you about ambiguous paths — check your filter directions. Simplify relationships where possible.

Common Mistakes to Avoid

Using bi-directional filters to fix visuals instead of fixing the data model
Forgetting to evaluate performance after enabling both-direction filters
Not testing RLS impact when filter directions change
Creating circular filter paths, which Power BI won’t allow

Joins in Power Query

Allows you to combine data from different sources, offering comprehensive insights. Here’s an overview of the most common merge options in Power Query, explained with simple analogies and real-life examples.

Join Types

Now we will go into the different types of join functions Power Query has made available to us

Left Outer Join (All from first, matching from second)
• Analogy: Imagine you’re planning a wedding. You have a guest list (Table 1), and then you collect RSVPs (Table 2). A left outer join ensures that everyone from your guest list (Table 1) will be included, even if they didn’t RSVP. For those who did RSVP, you’ll also have their response.
• Practical Example: In a company, if you have a list of all employees (Table 1) and another list of their completed training sessions (Table 2), a left outer join shows all employees, whether or not they have completed any training (Table 2).
Right Outer Join (All from second, matching from first)
• Analogy: Now, you’re only interested in the RSVPs (Table 2). You still want to know if they were on the original guest list (Table 1), but you also want to include people who RSVP’d without being invited. A right outer join shows you all RSVPs, whether or not they were on the guest list.
• Practical Example: If you have a list of all customers who placed orders (Table 2) and another list of all potential customers (Table 1), a right outer join will show all customers who placed orders, even if they weren’t on the original prospect list.
Full Outer Join (All rows from both)
• Analogy: Now you want to see both your guest list and RSVPs entirely. You want to know who was invited and who RSVP’d, and also see if anyone RSVP’d who wasn’t on your list. A full outer join shows all the data from both tables, matching where possible and leaving blanks where there are no matches.
• Practical Example: If you have a list of products sold (Table 1) and a list of products in inventory (Table 2), a full outer join will give you all products, both sold and in inventory, even if some products were sold but are not in inventory and vice versa.
Inner Join (Only matching rows)
• Analogy: You’re only interested in the people who were on your guest list and RSVP’d. If someone was invited but didn’t RSVP, or RSVP’d without being on the guest list, you don’t want to see them. An inner join only shows rows that exist in both tables.
• Practical Example: If you have a list of current employees (Table 1) and a list of people who completed mandatory training (Table 2), an inner join will show only those who are both current employees and have completed the training.
Left Anti Join (Rows only in first)
• Analogy: You want to see who was on your guest list but didn’t RSVP. A left anti join shows only the people who are in Table 1 (your guest list) but have no matching record in Table 2 (RSVPs).
• Practical Example: If you have a list of all employees (Table 1) and another list of those who completed training (Table 2), a left anti join will show you the employees who haven’t completed the training.
Right Anti Join (Rows only in second)
• Analogy: Now you want to see who RSVP’d but wasn’t on the original guest list. A right anti join shows only the people who are in Table 2 (RSVPs) but have no match in Table 1 (the guest list).
• Practical Example: If you have a list of employees who signed up for a training session (Table 2) but weren’t originally required to take the training (Table 1), a right anti join will show you the unexpected attendees.

Key Insights:
• Use left outer join to retain all the data from the first table and match as much as you can from the second.
• Use right outer join to retain all the data from the second table and match as much as you can from the first.
• Use full outer join to combine everything from both tables, regardless of matching.
• Use inner join when you only care about data that exists in both tables.
• Use left anti join and right anti join to find rows that exist only in one of the tables but not both.

Power Query Joins vs Power BI Relationships

Performance
One of the distinguishing features of a reporting system is the performance of it. If you are building a reporting system, and the loading the report takes five minutes, then what is the benefit of this report over doing it in the operational system? because it would have taken that much in the operational system anyway!

When you build a reporting system, you should target creating reports that load fast. Having extra relationships, doesn’t help with the performance. The DAX queries behind the scene would be longer.

Another big deterministic of a good reporting model is the ability to make it easy-to-understand for data visualizers. If a data visualizer have 500 tables in a model all inter-related, anyone would have a hard time to understand the model.

Relationships come with a cost of complexity. You might need a both-directional relationship sometimes, or you might get into the problem of having an inactive relationship and trying to resolve that. Less relationship means fewer problems of this type when it is unnecessary.

Recommended Power BI Model

You should not have tons of relationships, and you should not create one big table with everything in it. The recommended thing is to design a totally different schema. A new layout of tables and relationships. Something that is different from the operating system’s database. Something that helps to get the best of both worlds.

This model, has many names; dimensional model, star schema, data warehouse etc. Through the process of creating this model, you combine some of the tables (dimensions), and keep some of them to be connected through the relationships (dimension to fact table relationships).

What if you don’t have a reference table that you can use as a dimension? what if there are only mapping tables in your data source? Many, have faced the same challenges. If you don’t have a reference table, you can create them from your mapping tables.
Just because you can load all the tables into the model and then create relationship, it doesn’t mean it is the best thing to do. Just because you can merge all the tables using Power Query, it doesn’t mean you should do it.

Power BI modeling starts with a pen and paper. This is very important that you start your modeling by a pen and paper. Yes, no tools or services needed. Just a pen and paper. You need to draw the dimensional model, the layout of the tables. You need to list fields in your dimension and fact tables. All of these are much better to be done using a pen and paper. You can then take the next step of implementing it using Power BI.

A good model should consider many things. It should first start with the requirement. How are you going to build a database diagram of a reporting system, when you don’t know what values should be shown in the report?

A good model also requires an understanding of the existing data, and how that data can be transformed into the star-schema model.

Don’t build your model on this rule that; this is the format that I get data, so can’t really do much about it. This is wrong! You need to transform that format.

My report works just fine, why bother?
Why bothering if your report is running just fine? or if it doesn’t have any performance problems? Do you really need to think about the model if you got only a few tables and everything works as it should? Why spending time on something that the users won’t see?

Yes, you need to work on your model. If you didn’t do that from the beginning of your implementation, do it now. Your model gets bigger and bigger every time. You will have more tables, more relationships, bigger challenges.

Building a proper data model is like building a base for a 100 stories building. would you first build the 100 stories and then come and fortify the base?! of course not. You should do it as soon as possible, or your whole building might collapse at some point.

Your Power BI data model is your world. It is up to you to decide in which world you want to live in. Would you prefer to have a model that is too complicated that every time someone asks for a change it ends up with hours and often days of work because it is not designed in the way it should? Or do you prefer to build a model that is a high performance, simple, easy to change, and simple to integrate? That is your choice; your model, your world.

Data Analysis and Reporting Using Excel

Faith — Fri, 04 Sep 2026 21:14:31 +0000

Introduction

As part of my Data Science course at LuxDevHQ we covered Excel as our first tool. It seemed unnecessary to me at first but the more we covered the more I realized I didn't know as much as is required of me as a data professional. Moreover, I was impressed by the capabilities of Excel, beyond what I normally used it for as a Finance professional who never got structured Excel training.
I used Jumia Discount Dataset for my analysis. Practised everything we covered for the last two weeks from data cleaning, analysis, pivot tables, charts to dashboarding.

Importing

Below is the process I used to import the data after downloading it on my machine.

Open a blank workbook.
Select Data > Get Data > From Text/CSV.
Choose Excel_jumia_dataset.csv and verify that the comma delimiter is detected.
Load the source into Raw_Data.
Duplicate the query or sheet before cleaning and load the result into Cleaned_Data.

Data Cleaning

I first of all had to scan through the entire data to see what it contains and maybe spot mistakes that could be easily corrected. Started off with obvious errors that I tabulated for tracking as shown below:

To avoid being overwhelmed with scattered data, I created these worksheets in my workbook for different purposes during the project;

Raw_Data — an original copy of the CSV;
Cleaned_Data — cleaned fields, derived columns, and an Excel Table;
Analysis — descriptive statistics, correlation, and ranked product tables;
Pivot_Tables — all PivotTables that support the visuals;
Dashboard — KPIs, charts, slicers
Data_Dictionary — field definitions, a cleaning log.

Among others that I realized I needed along the way for further analysis and insights that bore the names of the specific metrics I analyzed.

Analysis

Analyzing data seems a bit easy when you are being taught or when someone else is doing it, its only when you do it that you appreciate the logic that goes into this process. Found out that I need to add some columns to enable analysis on my part, which was a bummer who knew that trick, I didn't, anyway we live we learn.

I realized I wasn't going anywhere without additional columns in my data since I had only a few columns to work with and by themselves they weren't going to be of much help. I created the Price Category, Discount Status, Review Status, and Ratings Status columns, that came in handy especially when I created pivot tables to summarize data for insights and recommendations. Maintained my options between 2 to 4 categories in each newly created column.
Applied the Nested IFs and ISBLANK formula to create my categories as indicated here;

Price Category =IF([@[Current price]]<500,"Economical",IF([@[Current price]]<=1000,"Affordable","High Cost"))

Discount Status =IF([@Discount]<20%,"Low Discount",IF([@Discount]<=40%,"Medium Discount","High Discount"))

Review Status =IF(ISBLANK([@Review]),"No Review", IF([@Review]<10,"Poor Review",IF([@Review]<=20,"Good Review","Excellent Review")))

Ratings Status = =IF(ISBLANK([@Ratings]),"Not Rated",IF([@Ratings]<3,"Poor Review",IF([@Ratings]<=4.5,"Average","Excellent")))

The thing with the analysis part there is no right way or wrong way to do it there is only how you choose to do it, I found this method to be the most straight forward and fast since I am also training to ensure I use the least amount time possible to create a report start to finish.

Pivot Tables and Charts

After creating necessary columns and coming to the conclusion that my analyzed data is sufficient for drawing inference I proceeded to create Pivot tables based on some objectives:

which products may need a different pricing or marketing strategy

On the pivot table for this category, I placed the product and price on the rows field but made sure to group by 500, then added Average of Review to the values field and finally, Rating status to the columns as well as a slicer for the rating status.

As for the other Pivot tables, I was a bit experimental, tried different variables in different field until I found was fitting to what I intended to represent.

Used two bar charts, two column chart and a pie chart for the visualization. Created a bar and column chart interchangeably on data that represented a numerical variable along side a categorical variable. For instance, when I needed to visualize the relationship between product pricing and review:

Dashboard

Finally the dashboard!
Made the KPI's and the charts form the analysis I made on the data. My dashboard includes what I thought is of importance from the data I analyzed, sure you don't have to include every chart made, It should only have that which is essential to the stakeholders and maybe what they wish to know or what you wish to communicate as an analyst.

Recommendation and Insights

Do Larger Discounts Drive More Reviews?

From the data it seems as though higher discount drive more review as shown in the figure. High discounts which were discounts ranging from 41%-100%, but the highest recorded discount was 64%, so essentially the discount range from 41%-64% generated 30 reviews, which is the highest of the three categories.
This suggests that aggressive discounting can build customer trust or volume.

Do Highly Rated Products Attract More Engagement?

Yes, but the gap is modest.

Excellent-rated products lead in reviews, but interestingly, poorly-rated products carry the highest average discount (43%), suggesting discounts may be used to compensate for weak ratings, rather than reflecting genuine value.

Do Price and Rating Move Together?

There's a gentle positive relationship between price and rating. However, not sufficient for us to make an inference form this data only.

Best Performing Products (Ratings + Reviews)

The standout performers combining both high ratings and strong review counts:

Products Needing a Strategy Rethink

20 products have zero ratings and zero reviews. These span all price categories and carry discounts averaging ~38%, which clearly isn't working.

another category would be the products with the lowest reviews and ratings such as:

Recommended actions:

Run targeted campaigns to seed initial reviews
Consider bundling with top-performing products
Reassess whether the product-market fit is right before deepening discounts further.

Conclusion

This will serve as my lesson learnt from the whole process as I have gained one or two tips for later.
It seems like a ton of work but I believe it gets easier with time, so I will hold on to that. As long as something works use that, don't go over your head trying to remember what you learnt to apply it, and always remember you can consult, no man is an Island we all need each other at some point.

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

Faith — Sun, 30 Aug 2026 14:23:33 +0000

I just came to the realization that Microsoft Excel is one of the most commonly tools used at the workplace. Not for anything else but for data analysis. I have never thought of it this way. Given my background in Finance, we use Excel for bragging rights depending on how many formulas you created and run on excel to make your your financial models run.

Data Cleaning

Before any analysis, most data requires to be cleaned or adjusted in a way that it is easily used for any analytical work. Data collection sometimes comes with variant responses that make it hard to use the data as it is. Making it necessary to clean data before usage. A really cool tool I learnt this week was Data Validation. This helps restrict the type of feedback you get per column making it easier when you use the data later. An example would be to restrict product categories that one can enter or maximum and minimum limits. Enforcing it is a easy as:

Selecting the necessary cells
On the ribbon, click Data then Data Validation
Under Allow, select List
In Source, type values separated by commas
Click OK

Applied Data Validation on the Employee column Validation to ensure that only whole numbers are allowed after removing duplicates from the dataset.

Filtering

Another important tool in Excel has to be filtering, thinking of it now I should have started with this one.
This gives an over view of how the data looks like, if you actually need to apply changes to the data or leave it as it and so on. I believe it is impossible to use excel especially when interacting with tons of data and not use filtering.
It's like a sneak peek of the data displaying only the rows that meet criteria while the rest stay hidden.

How do we exactly do that:

Click anywhere in the dataset
On the Home tab, go to Sort and Filter, Filter
Click on a dropdown on the header row
Choose the values to show or use

Before I realized that some columns have entries that are wrongly spelt and written, I filtered my data to see that and replaced the entries with what aligned with the options available.

Data Formatting and Cleaning

Number formatting

This function of Excel would come in handy when you probably are trying to perform a mathematical operation but it just wouldn't work. Chances are the formatting isn't appropriate of the data type. A hint that would help to determine if the formatting is appropriate is; numerical data aligns to the right while text to the left. However, this sometimes isn't enough.

Let's now get to how it is done:

Percentage formatting

Select cells
Home > Number group> Click % symbol
Numbers convert to %

Currency formatting steps

Select the cells with numbers
Home tab > Number group
Click the dropdown arrow on the number format box
Select Currency or Accounting
Change the currency by clicking the small dialog launcher

A simpler way to do it on the Home tab to go to the number segment and click on the drop down on the bottom right and any changes can be made from there

Conditional Formatting

This is a useful tool especially if you need to pay attention to a criterion or a group of data. It highlights cells automatically based on the rules set, helping with locating with trends and that which you wish.
An example is when handling credit data and if the loan is way past due time, conditional formatting can be used to categories the different classes of default.

Go to Home > Conditional Formatting
Choose a rule type:

Highlight Cell Rules (Greater than, Less than)
Top/Bottom Rules
Data Bars, Color Scales, Icon Sets

For example, select Highlight Cell Rules > Less Than
Enter a value
Choose a formatting style (e.g., green fill)
Click OK

There is so much that one can do when it comes to data analysis. However, I have focused on the ones that I use a lot more, but on the contrary they don't seem to be that obvious such as removing duplicates and data sorting.
Hope this makes data analysis on Excel a bit lighter and faster for you as it did for me.
On a lighter note, I would always recommend videos incase anything isn't clear, practice does it better than any other way.

My First GitHub Project: From a Local Folder to GitHub Using Git and SSH

Faith — Sat, 22 Aug 2026 17:29:53 +0000

It took me to set up my Git and GitHub to realize how technology is sometimes not that straight forward at least for beginners. I mean setting up an account should be the easiest part of technology right? However Git and GitHub are packaged differently, forcing us to bear the brunt of its's convolution.

I'll break down the process to make it ingestible without intimidating a soul, because this too shall pass. Later, we will look back and be astonished of how something simple got our necks on a chokehold.

1. Installation

First things first, you have to set up a GitHub account on GitHub and then download git and Git Bash. I'll share a more detailed guide of this process don't worry. Git Bash is sort of the terminal that we'll use to write our commands while connecting our git to Git Bash. Git runs locally and keeps track of changes during the project while GitHub is an online version that does the same. Depending on your Operating System there are different ways to download Git. Alternatively, VS Code can be used to push your projects to GitHub and that's what we'll focus on, since its the simplest one. At this point I'm assuming we have a project that needs pushing to GitHub.

2. Creating a folder locally

There are shortcuts to create and edit files using Git Bash when doing projects and I thought it best to include them here for posterity and experiment as well.

mkdir makes a directory/creates a folder eg mkdir Analytics Project

Make sure not to include space on the name of the folder, use hyphens or underscore instead. Alternatively, enclose the name of the folder in quotation marks if spaces are used in naming the folder, then and add the your data set into the folder created.

These commands are useful in Git Bash depending on which stage of the process you are in.

cd changes to another directory (cd "Analytics Project') cd/path/to/your/repository
cd .. takes you back to previous directory
ls lists down what's in the folder
rm deletes document in the folder
rm -r deletes the folder in the folder

Creating a README file

touch creates a README document (touch README.md)

A readme file is important for documenting the process of a project. It usually acts as a contact point with anyone interacting with the your digital product.

On Git bash or terminal, access the folder cd Analytics Project

To edit content in README.md file, we'll use the command echo "Analytics Project" >README.md
To check what is written, we'll use the command cat README.md
Nano can be used to simplify editing. This has to be my preferred method of editing as it is the easiest to use, especially when you are a beginner.
Running the command nano README.md will make a text editor appear where in we shall edit our content.
To Save content, press Control + O,
Press Enter Key to confirm the file, then press Control + X to exit._

3. Git Configuration

This is probably the simplest part of this process after creating a GitHub account. On Git Bash, check user name user email by running

git config --global --list

If the account that exists isn't yours or you'd like to use a different one we can overwrite the existing account by using

git config --global user.name "YourGitHub Profile Name"

Then you'll be prompted to add a passphrase which is basically a password, it's advisable not to write one incase you forget it. So just *ENTER * to move to the next step.

Incase you'd like to change your branch from master to main run;

git config --global init.defaultBranch main

4. Key Generation using SSH

In this part we'll be generating a SSH key that we'll use to connect our Git and GitHub. SSH helps us with security because our computer needs a secure way to prove to GitHub that it is authorized to access our GitHub account
SSH stands for: Secure Shell
With SSH authentication, you create a pair of cryptographic keys.
GitHub requires the public key to be added to your account, while the corresponding private key stays on our computer. Now, this is where things a bit technical.

When we generate an SSH key, you will normally get 2 keys:

id_ed25519 - private key
id_ed25519.pub - Public key

But, I'd like us to generate a public key using a shortcut:

ssh-keygen -t ed25519 -C "your_email@example.com"

Then a prompt to overwrite will appear, write "y" meaning yes and press Enter. If you chose to have a password input, if you didn't press Enter then run

clip < /c/Users/user/.ssh/id_ed25519.pub to save they public key in a file.

Testing

We've already generated a key, now we use an IDE in this case VS Code to push our project to GitHub.

To confirm if we've connected our Git to GitHub using the SSH Key that we have generated. Go to Git Bash terminal and run
ssh -T git@github.com

There shouldn't be any problem with this but if anything isn't seeming right, you can always Chat GPT.

Okay now let's copy our generated key to GitHub

Open your GitHub account
Go to settings
Click SSH and GPG
Delete and add new or simply add the generated key if there are no keys yet

Using VS Code

You can create a folder or choose a folder through VS Code.

Go to file
Open your folder containing your project
select your folder

Connecting Git to GitHub

Now we'll configure GitHub by;

Clicking Source control on the left side
Choose Manage work trust
Initialize repository - this is the equivalent of git innit when using Git Bash. It creates a hidden .Git directory which contains information that our Git uses to track the developments and changes.
Initializing the repository allows our project folder to become a Git Repository.
Add change - this is a write up of the content you would like to indicate in present tense eg "Add Dataset". This is analogous to writing git commit -m " ", while using terminal or Git Bash.
Against commit on the far right click the drop down and choose commit and sync. Comparable to this is git push origin main

After pushing our project to GitHub, you can run command Git status to confirm everything is as you wanted it to be and maybe adjust accordingly.

From here you'll see a number of prompts, only click "Always", "Add remote", "Publish Branch", "Allow- if configuring for the first time."

Lastly, choose a browser of your choice and authorize access remembering to chose between creating a public or private key depending on your choice and preference, Sign in and viola, The project is posted on GitHub.

Something to note the name of the repository will bear the name of the folder used.

Conclusion

That's it imagine, there are other ways to push your projects to GitHub if that's something you are interested in , be sure to find that out, there's also a lot more to know in GitHub and GitHub Configuration but baby steps, right? That's all for today all and the best at pushing your projects on GitHub.

Build A Calculator Using Python

Faith — Mon, 10 Aug 2026 17:41:52 +0000

Using Loops

This has to be the easiest way to apply your python skills after learning the basics. The best and only way to learn anything is through rolling your sleeves and practicing, python for this case is no exception. Just like any other rookie, I did really struggle with what to start with given some projects online are quoted "beginner" but ended up not being beginner friendly to me.
Yeah, I know this project is not all that, but it helps retain the concepts learnt and keeps the spark alive, at least it does for me.

Lines of Code

print("===== Advanced Calculator =====")
print("Basic: +, -, *, /")
print("Adv: power (^) and Modulus (%)")
print("Sci: sqrt, log")
print("Trig: sin, cos, tan")

# get the operator
op = input("\nEnter Operator: ")

# Binary operations
if op in ['+', '-', '*', '/', '^', '%']:
    num1 = float(input("Enter 1st num: "))
    num2 = float(input("Enter 2nd num: "))

    if op == '+':
        print(f"result: {num1 + num2}")
    elif op == '-':
        print(f"result: {num1 - num2}")
    elif op == '*':
        print(f"result: {num1 * num2}")
    elif op == '/':
        print(f"result: {num1 / num2}")
    elif op == '^':
        print(f"result: {math.pow(num1 , num2)}")
    elif op == '%':
        print(f"result: {num1 % num2}")

This are lines of code that can be used to explore loops in python because theory alone doesn't cut it. The first part of the code, the one consisting of print() at the beginning, are an explanation of the arithmetic operators used, you don't really need to have it.