SQL (Structured Query Language) is the standard language for defining, querying, and manipulating data in a relational database — creating tables, inserting/updating/deleting rows, and asking questions of the data with SELECT. It's declarative: you describe the result you want, and the database's query optimizer figures out how to actually get it, rather than you writing step-by-step retrieval logic yourself.

SELECT first_name, last_name, department
FROM employees
WHERE hire_date >= '2024-01-01'
ORDER BY last_name;

SELECT retrieves data from one or more tables without modifying it — the only DML statement that's purely read-only. Its clauses execute in a logical order that's the opposite of how you type them: FROM/JOIN first, then WHERE, then GROUP BY, then HAVING, then SELECT's own column list, then ORDER BY last.

A JOIN combines rows from two or more tables based on a related column between them — the whole point of a relational model, where data is normalized across tables instead of duplicated in one giant sheet.

A primary key uniquely identifies every row in a table — it can't be NULL and can't repeat, and a table has exactly one (though it may span multiple columns as a composite key). It's also what foreign keys in other tables point back to, forming the actual relationships in a relational schema.

CREATE TABLE orders (
    id INT PRIMARY KEY,
    customer_id INT NOT NULL,
    FOREIGN KEY (customer_id) REFERENCES customers(id)
);

A foreign key column references another table's primary key, enforcing referential integrity — the database physically won't let you insert an order for a customer_id that doesn't exist, and by default won't let you delete a customer who still has orders (unless ON DELETE CASCADE/SET NULL says otherwise).

-- Vulnerable: string-concatenated user input becomes part of the query text
-- "SELECT * FROM users WHERE username = '" + input + "'"

-- Safe: a parameterized query — the value is bound, never parsed as SQL
SELECT * FROM users WHERE username = ?;   -- or @username / :username depending on driver

• Always use parameterized queries / prepared statements — never string-concatenate user input into SQL text
• Apply the principle of least privilege to the DB account your app connects with (it shouldn't be able to DROP TABLE if it only ever needs SELECT/INSERT)
• Validate and constrain input at the application layer too, as a second line of defense
• Use an ORM's parameter binding rather than its raw-SQL escape hatches for anything touching user input

Normalization organizes data to eliminate redundancy and prevent update anomalies, by progressively splitting data into related tables. 1NF requires atomic values (no comma-separated lists in a cell); 2NF removes partial dependencies (every non-key column depends on the whole primary key, not just part of a composite one); 3NF removes transitive dependencies (a non-key column can't depend on another non-key column) — e.g. storing a customer's city in the orders table when it really belongs to a customers table is a 3NF violation.