Comunque, in estrema sintesi:

un database relazionale è composto prima di tutto da tabelle; ogni tabella ha ovviamente delle colonne (in linea di massima fissate al momento della creazione della tabella) e delle righe.

Ogni riga è un record, che (di base) rappresenta un "oggetto" contenuto nella tabella; ogni record a sua volta è composto dai vari campi che corrispondono alle colonne (per cui tutti gli "oggetti" di una tabella sono composti alla stessa maniera).

Le tabelle (e le colonne in esse contenute) e le relazioni che intercorrono tra le tabelle costituiscono la struttura del database - ovvero, ciò che si imposta all'inizio e si cambia di rado (idealmente mai). Le righe, invece, vengono continuamente aggiunte/modificate/lette/filtrate/...

Per stabilire delle relazioni tra gli elementi di diverse tabelle si fa uso di chiavi; in particolare, una chiave primaria (che può essere costituita da una o più colonne) serve ad identificare univocamente un record in una tabella, in modo che da una tabella si possa fare riferimento in maniera univoca ad elementi di un'altra tabella.

Mi spiego meglio con un esempio. Supponiamo di avere il classicissimo database delle fatture: avremo (tra le altre cose) una tabella contenente le fatture e una contenente l'anagrafica dei clienti. Ad ogni fattura ovviamente corrisponde un cliente, in una relazione "uno a molti" (ad un cliente possono corrispondere molte fatture, ma non viceversa).
Si identifica quindi una chiave primaria per fare riferimento ad elementi della tabella dei clienti: si può usare ad esempio il codice fiscale, o, in casi in cui non ci sia già una colonna (o un'unione di colonne) "naturalmente univoca", si usa un campo ID generato appositamente.

A questo punto, la tabella delle fatture avrà una colonna che fa riferimento al cliente a cui è relativa, che sarà una "chiave esterna", ovvero una colonna che contiene il codice fiscale del cliente e che quindi fa riferimento alla chiave primaria della tabella dei clienti.
In questa maniera:
- data una fattura, è possibile risalire "al volo" all'intera anagrafica del cliente, andando a cercare nella tabella clienti l'unico record che ha quel valore di chiave primaria;
- viceversa, si possono cercare tutti i clienti che corrispondono ad un certo criterio (che so, zona geografica) e recuperare le fatture relative;
- il DBMS può verificare se non si fanno errori di inserimento dei dati - se si cerca di inserire una fattura per un cliente non in anagrafica l'inserimento può essere bloccato, oppure può bloccare la cancellazione di un cliente per cui esistono già delle fatture in database;
- ... e un mucchio di altre cose

Tramite le query è possibile interrogare il database, facendo operazioni che vanno dal "forniscimi tutti i record di questa tabella" ad operazioni complesse, che selezionano solo determinate colonne e coinvolgono più tabelle, collegate tra loro tramite relazioni (ad esempio, appunto, "somma tutti i totali delle fatture relative ai clienti di Milano" - operazione che coinvolge come minimo due tabelle, unite dalla relazione citata prima).

Altre query consentono di modificare/eliminare record, e infine ci sono dei comandi per la "gestione" del DB (da creare tabelle/modificarne la struttura fino alla gestione degli utenti per i DB che la supportano).

Questo ovviamente è giusto per dare un'idea "di base" e per sapere che keyword cercare in giro, ovviamente c'è dietro un mondo e dubito che ci si possa fare un "modello mentale" di cosa sia effettivamente un DB relazionale in cinque minuti da un post scritto al volo su un forum.