E. F. Codd, wówczas młody programista w IBM, wymyślił relacyjną bazę danych w 1970 roku. W swoim artykule „A Relational Model of Data for Large Shared Data Banks” Codd zaproponował przejście od przechowywania danych w strukturach hierarchicznych lub nawigacyjnych do organizowania danych w tabelach zawierających wiersze i kolumny.
Każda tabela, zwana czasem relacją, w relacyjnej bazie danych zawiera jedną lub więcej kategorii danych w kolumnach lub atrybutach. Każdy wiersz, zwany również rekordem lub krotką, zawiera unikalną instancję danych — lub klucz — dla kategorii zdefiniowanych przez kolumny. Każda tabela ma unikalny klucz główny, który identyfikuje informacje w tabeli. Relacje pomiędzy tabelami mogą być ustalone poprzez użycie kluczy obcych — pole w tabeli, które łączy się z kluczem głównym innej tabeli.
Na przykład typowa biznesowa baza danych do wprowadzania zamówień zawierałaby tabelę opisującą klienta z kolumnami dla nazwiska, adresu, numeru telefonu i tak dalej. Inna tabela opisuje zamówienie, zawierając informacje takie jak produkt, klient, data i cena sprzedaży.
Użytkownik może otrzymać raport z bazy danych pokazujący dane, których potrzebuje. Na przykład kierownik oddziału może chcieć uzyskać raport dotyczący wszystkich klientów, którzy kupili produkty po określonej dacie. Kierownik działu finansowego w tej samej firmie mógłby, na podstawie tych samych tabel, uzyskać raport dotyczący rachunków, które wymagają zapłaty.
Podczas tworzenia relacyjnej bazy danych użytkownicy określają domenę możliwych wartości w kolumnie danych oraz ograniczenia, które mogą dotyczyć tej wartości danych. Na przykład domena możliwych klientów może dopuszczać do 10 możliwych nazw klientów, ale w jednej tabeli jest ograniczona do umożliwienia określenia tylko trzech z tych nazw klientów.
Dwa ograniczenia odnoszą się do integralności danych oraz kluczy głównych i obcych:
- Integralność encji zapewnia, że klucz główny w tabeli jest unikalny, a jego wartość nie jest ustawiona na null.
- Integralność referencyjna wymaga, aby każda wartość w kolumnie klucza obcego znalazła się w kluczu podstawowym tabeli, z której pochodzi.
Ponadto relacyjne bazy danych posiadają fizyczną niezależność danych. Odnosi się to do zdolności systemu do wprowadzania zmian w wewnętrznym schemacie bez zmiany zewnętrznych schematów lub programów aplikacji. Zmiany w schemacie wewnętrznym mogą obejmować:
- zastosowanie nowych urządzeń do przechowywania danych;
- modyfikację indeksów;
- zmiana z określonej metody dostępu na inną;
- wykorzystanie innych struktur danych;
- stosowanie różnych struktur pamięci masowej lub organizacji plików.
Logiczna niezależność danych to zdolność systemu do zarządzania schematem pojęciowym bez zmiany schematu zewnętrznego lub programów aplikacyjnych. Zmiany schematu koncepcyjnego mogą obejmować dodawanie lub usuwanie nowych relacji, podmiotów lub atrybutów bez zmiany istniejących schematów zewnętrznych lub przepisywania programów użytkowych.