SQL and database tutoring, from your first SELECT to third normal form

What we cover in SQL and database sessions

Database modules have two halves, and most students struggle with one more than the other. There's the SQL half, where you write queries and the database tells you, very bluntly, when you're wrong. Then there's the design half, where you model data on paper and nobody tells you anything until the marks come back.

I help with both. Database Development, which covers data modelling and SQL, is one of the modules I've studied, so I've sat with the same diagrams and error messages you're looking at now. Whether your module is called Database Systems, DBMS or just Databases, we start with whichever half is costing you marks.

• Queries: SELECT, WHERE, ORDER BY and the logic of filtering
• Joins: INNER, LEFT and RIGHT, and knowing which one you actually need
• Grouping: COUNT, SUM, AVG, GROUP BY and HAVING
• Subqueries, and when a join does the job better
• ERDs: entities, attributes, primary and foreign keys, cardinality
• Normalisation: first, second and third normal form, with reasons, not just rules

Where SQL queries and joins usually go wrong

Most SQL problems come down to a handful of patterns. Forget the join condition between a table of 50 customers and a table of 40 orders and you get 2,000 rows: every customer paired with every order. A GROUP BY query complains about a column you didn't think mattered. A WHERE clause tries to filter on a COUNT, which only HAVING can do.

Then there's NULL. Writing WHERE phone = NULL looks reasonable and returns nothing, because NULL isn't a value you can compare with an equals sign. You need IS NULL. These aren't silly mistakes. They're the places where SQL works differently from how the English reads, and once you see why, you stop making them.

So in a session I'll ask you to predict what a query will return before we run it. If your prediction and the result don't match, that gap is exactly what we need to fix. It's slower than me just correcting your code, but it's the skill that still works under exam pressure.

ERDs and database design help

Entity relationship diagrams are where database design either clicks or doesn't. A case study describes a business in a few paragraphs, and you have to turn it into entities, attributes and relationships. The usual trouble is deciding what counts as an entity, and getting the cardinality right: is it one-to-many, or many-to-many?

I teach it by reading the case study with a pencil. Nouns that need their own details become candidate entities. Verbs between them become relationships. Then we test each relationship from both sides, one sentence at a time: one customer can make many bookings, but each booking belongs to exactly one customer. A many-to-many relationship gets a linking table, and the diagram almost draws itself.

A worked example: normalising a bookings table

Say you're given one big table for a small business that takes bookings: BookingID, BookingDate, CustomerName, CustomerPhone, ServiceName and ServicePrice. It works, until a regular customer changes their number and you have to update it in 30 rows. Miss one, and the database now disagrees with itself. That's an update anomaly, and it's the whole reason normalisation exists.

So we pull out what repeats. Customers get their own table with a CustomerID primary key. Services get their own table with a ServiceID. The Bookings table keeps BookingID, BookingDate and the two IDs as foreign keys. Now each phone number and each price lives in exactly one place. In exam language, CustomerPhone depended on the customer, not on the booking: a transitive dependency, which is what third normal form removes.

Draw that as an ERD and the relationships are clear: one customer makes many bookings, and one service appears in many bookings. A JOIN puts the original view back together whenever you need it. That's how I teach normal forms, whether your textbook spells it normalisation or normalization: start from a real problem, fix it, then name the rule.

How SQL tutoring works, online or in Durban

Sessions run online over video call with screen sharing, so I see your query, your error and your ERD exactly as you do, wherever you are in South Africa. If you're looking for an SQL tutor in Durban and would rather sit at the same table, in-person sessions can be arranged in the Durban area.

A session is usually 60 to 90 minutes. Bring whatever is giving you trouble: a practical, a homework exercise, a query that won't run, a diagram you're unsure of, or the topic list for a test. With an assignment, I'll help you understand the brief and check your reasoning, but I won't write the queries for you. Here's how assignment guidance works.

Before a database test or exam we switch gears: targeted revision, past paper walkthroughs and practice queries you write on your own, so you find the gaps before the exam does. I can also put together structured notes on joins or normal forms for you to keep. See exam preparation for the details.

Why students work with me on databases

I started my degree with no coding experience at all, so everything I teach about databases I once had to learn from zero. I'm now a second-year IIE Bachelor of Computer and Information Sciences (Application Development) student, and I graduated top of a class of 200+ in the IIE Higher Certificate in Mobile Application and Web Development.

I also received the Full Stack Impact Award 2025 at the Emeris Durban North Student Top Achiever Awards, and my story was featured in IOL Education. What matters for you is simpler: in 2+ years of tutoring I've guided 150+ students, and no SQL question is too basic to ask. You can read what students say in the reviews.