SQL Course in Telugu: Learn Primary Keys, Foreign Keys, and Table Relationships
Introduction
Relational databases become powerful when information is divided into meaningful tables and connected through clear relationships. Instead of repeating customer details for every order, a database can store the customer once and link future orders to that customer. Keys make these relationships possible.
A SQL Course in Telugu can help beginners understand primary keys, foreign keys, one-to-one, one-to-many, and many-to-many relationships through practical examples. These concepts form the foundation for joins, normalization, data integrity, and database design.
Start with a Customer Table
Imagine a table:
Customers
Columns:
Customer_ID
Customer_Name
City
Two customers might have the same name.
Therefore, Name is not always a safe identifier.
A unique Customer_ID provides a more reliable way to identify each row.
What Is a Primary Key?
A primary key uniquely identifies each record in a table.
Example:
CREATE TABLE Customers (
Customer_ID INT PRIMARY KEY,
Customer_Name VARCHAR(100),
Email VARCHAR(150)
);
The database should not allow two rows with the same primary-key value.
This guarantees uniqueness.
Primary Keys Should Be Stable
A good primary key should not change frequently.
Using:
phone number
employee name
can create problems because these values may change.
A generated or stable business identifier is often more reliable.
The exact strategy depends on application requirements.
Primary Keys Cannot Be Duplicated
Suppose Customer_ID 101 already exists.
Trying to insert another record with Customer_ID 101 should fail.
This prevents ambiguity.
Without unique identification, SQL operations such as:
UPDATE
DELETE
JOIN
could affect the wrong record.
Primary Keys and NULL
A primary key must identify the row.
Therefore, it cannot be NULL.
If Customer_ID were missing, the record would not have a reliable identity.
This is one reason primary keys are central to database integrity.
What Is a Foreign Key?
A foreign key creates a relationship with another table.
Suppose the database has an Orders table.
CREATE TABLE Orders (
Order_ID INT PRIMARY KEY,
Customer_ID INT,
Amount DECIMAL(10,2),
FOREIGN KEY (Customer_ID)
REFERENCES Customers(Customer_ID)
);
Customer_ID in Orders refers to Customer_ID in Customers.
This connects each order to a customer.
Foreign Keys Protect Referential Integrity
Suppose someone tries to create an order for:
Customer_ID = 999
but Customer 999 does not exist.
A foreign-key constraint can reject the invalid order.
This prevents orphan records.
The database protects the relationship automatically.
One Customer Can Have Many Orders
This is a one-to-many relationship.
One customer:
Customer_ID 101
may have:
Order 5001
Order 5002
Order 5003
Each order stores Customer_ID 101.
The customer information itself does not need to be repeated.
One-to-Many Is Extremely Common
Examples include:
Department → Employees
Customer → Orders
Course → Lessons
Author → Books
Category → Products
In each case, one record in the parent table can relate to many records in the child table.
Foreign keys usually appear on the “many” side.
One-to-One Relationships
Sometimes one record relates to only one record in another table.
Example:
Employee
Employee_Passport_Details
or:
User
User_Profile_Settings
A one-to-one design may use:
unique foreign key
shared primary key
depending on the schema.
These relationships are less common than one-to-many but still useful.
Many-to-Many Relationships
Suppose:
one student can join many courses.
one course can contain many students.
This is many-to-many.
A direct foreign key in only one table is not enough.
Instead, create a bridge table.
Bridge Table Example
Tables:
Students
Courses
Enrollments
Enrollments may contain:
Enrollment_ID
Student_ID
Course_ID
Enrollment_Date
Student_ID references Students.
Course_ID references Courses.
The bridge table records each student-course relationship.
Many-to-Many in E-Commerce
Orders and Products also have a many-to-many relationship.
One order contains many products.
One product can appear in many orders.
A bridge table called:
Order_Items
may contain:
Order_ID
Product_ID
Quantity
Unit_Price
This structure is common in transactional systems.
Composite Keys
Sometimes more than one column together uniquely identifies a row.
For example, in Enrollments:
Student_ID + Course_ID
could form a composite primary key if one student can enroll in one course only once.
Example:
PRIMARY KEY (Student_ID, Course_ID)
Composite keys are useful when uniqueness naturally depends on several columns.
Surrogate vs Natural Keys
A natural key has business meaning.
Examples:
national identifier
product code
A surrogate key is generated primarily for database identification.
Examples:
Customer_ID
Order_ID
Employee_ID
Surrogate keys can remain stable even when business attributes change.
However, natural keys may still need UNIQUE constraints.
Cascading Actions Need Care
Foreign keys can sometimes define behavior when parent rows change.
Possible actions may include:
CASCADE
SET NULL
RESTRICT
Suppose a customer is deleted.
Should all orders also be deleted?
Usually, historical orders may need to remain.
Therefore, cascade deletion should be used only when it matches business rules.
Avoid Deleting Important Parent Data Blindly
Imagine deleting one Department row.
If hundreds of Employees reference it, the database may block the delete.
This is useful.
Before changing parent data, understand:
which child tables depend on it
whether historical information matters
Database integrity should reflect business reality.
Practical Example: College Database
Tables:
Students
Departments
Courses
Enrollments
Relationships:
Department → Students
Department → Courses
Student ↔ Course through Enrollments
Questions now become easier:
Which students belong to CSE?
Which students enrolled in SQL?
How many courses does each student have?
Keys make these joins reliable.
Practical Example: Hospital Database
Tables:
Patients
Doctors
Appointments
Each appointment can contain:
Appointment_ID
Patient_ID
Doctor_ID
Appointment_Date
Patient_ID references Patients.
Doctor_ID references Doctors.
Appointments becomes the relationship between patients and doctors over time.
Keys Help Joins
Suppose a report needs customer name and order amount.
SELECT c.Customer_Name,
o.Order_ID,
o.Amount
FROM Customers c
JOIN Orders o
ON c.Customer_ID = o.Customer_ID;
The relationship is clear because:
primary key
and
foreign key
were designed correctly.
Keys Improve Data Quality
Without foreign keys, an Orders table may contain:
Customer_ID 9999
even though the customer does not exist.
Without a primary key, duplicate orders may appear accidentally.
Keys provide structural rules that applications alone should not be expected to enforce.
Constraints and Keys Work Together
A table may combine:
PRIMARY KEY
FOREIGN KEY
UNIQUE
NOT NULL
CHECK
Example:
Email may be UNIQUE.
Customer_ID may be PRIMARY KEY.
City may be NOT NULL.
Each constraint protects a different rule.
Good schemas use several controls together.
Database Diagrams Help
An Entity Relationship Diagram, or ERD, can display:
tables
primary keys
foreign keys
relationships
For beginners, drawing relationships visually is extremely useful.
Example:
Customers
1 → many
Orders
many → many through
Order_Items
Products
The diagram makes join paths easier to understand.
Avoid Circular Relationships Without Need
Complex schemas sometimes create tables that depend on each other in confusing ways.
Before adding a foreign key, ask:
What business relationship does this represent?
Should one record exist without the other?
Which table owns the relationship?
Clear design reduces future maintenance problems.
Keys Also Support Indexing
Primary keys are commonly indexed automatically by database systems.
Foreign-key columns may also benefit from indexes when frequently used in:
joins
deletes
updates
However, indexing behavior differs between database engines.
Learners should verify how their chosen system handles keys and indexes.
Why Telugu-Based Learning Can Help
Database relationships introduce terms such as primary key, foreign key, parent table, child table, one-to-many, many-to-many, composite key, bridge table, and referential integrity.
A SQL Course in Telugu can explain these concepts in Telugu while keeping database terminology in English.
This can make relational design easier to visualize.
Frequently Asked Questions
What is a primary key?
A primary key uniquely identifies each row in a table.
What is a foreign key?
A foreign key links one table to a key in another table and helps maintain valid relationships.
What is a many-to-many relationship?
It is a relationship where records on both sides can connect to multiple records on the other side.
Why use a bridge table?
A bridge table stores the individual relationships in a many-to-many design.
Conclusion
Primary keys and foreign keys form the structural backbone of relational databases.
Primary keys give every record a clear identity. Foreign keys connect related tables and protect referential integrity. Relationship models such as one-to-many and many-to-many allow complex business data to remain organized without excessive duplication.
Understanding these concepts makes joins, normalization, constraints, and database design much easier to learn.