Datový model není jen způsob strukturování dat: definuje také sadu operací, které lze na datech provádět. Relační model například definuje operace jako select, project a join. Ačkoli tyto operace nemusí být explicitní v konkrétním dotazovacím jazyce, poskytují základ, na kterém je dotazovací jazyk postaven.
Pro modelování datové struktury se používají různé techniky. Většina databázových systémů je postavena na jednom konkrétním datovém modelu, i když je stále běžnější, že produkty nabízejí podporu pro více než jeden model. Pro každý jeden logický model mohou být možné různé fyzické implementace a většina produktů nabídne uživateli určitou úroveň kontroly při ladění fyzické implementace, protože volby, které jsou prováděny, mají významný vliv na výkon. Příkladem je relační model: všechny seriózní implementace relačního modelu umožňují vytvoření indexů, které poskytují rychlý přístup k řádkům v tabulce, pokud jsou známy hodnoty určitých sloupců.
To nemusí být striktně kvalifikováno jako datový model, jak je definováno výše.
Plochý (nebo tabulkový) model se skládá z jednoho, dvourozměrného pole datových prvků, kde se předpokládá, že všechny členy daného sloupce jsou podobné hodnoty, a předpokládá se, že všechny členy řádku jsou navzájem propojeny. Například sloupce pro jméno a heslo, které mohou být použity jako součást databáze zabezpečení systému. Každý řádek by měl mít specifické heslo přidružené k jednotlivému uživateli. Sloupce tabulky mají často přidružený typ, který je definuje jako znaková data, informace o datu nebo čase, celá čísla nebo čísla s plovoucí desetinnou čárkou.
V hierarchickém modelu jsou data uspořádána do stromové struktury, což znamená jeden odkaz nahoru v každém záznamu, který popisuje vnoření, a třídící pole, které uchovává záznamy v určitém pořadí v každém seznamu stejné úrovně. Hierarchické struktury byly široce používány v raných mainframových systémech pro správu databází, jako je Information Management System (IMS) od IBM, a nyní popisují strukturu XML dokumentů. Tato struktura umožňuje jeden vztah 1:N mezi dvěma typy dat. Tato struktura je velmi efektivní pro popis mnoha vztahů v reálném světě; recepty, obsah, řazení odstavců/veršů, jakékoliv vnořené a seřazené informace. Hierarchická struktura je však neefektivní pro některé databázové operace, když úplná cesta (na rozdíl od odkazu nahoru a třídícího pole) není zahrnuta také pro každý záznam.
Jedním z omezení hierarchického modelu je jeho neschopnost efektivně reprezentovat redundanci v datech.
Síťový model (definovaný specifikací CODASYL) organizuje data pomocí dvou základních konstruktů, nazývaných záznamy a množiny. Záznamy obsahují pole (která mohou být uspořádána hierarchicky, jako v programovacím jazyce COBOL). Sady (nezaměňovat s matematickými množinami) definují vztahy jedna ku mnoha mezi záznamy: jeden vlastník, mnoho členů. Záznam může být vlastníkem v libovolném počtu množin a členem v libovolném počtu množin.
Síťový model je variací na hierarchický model do té míry, že je postaven na konceptu více větví (struktury nižších úrovní) vycházejících z jednoho nebo více uzlů (struktury vyšších úrovní), zatímco model se liší od hierarchického modelu tím, že větve mohou být připojeny k více uzlům. Síťový model je schopen reprezentovat redundanci v datech efektivněji, než je hierarchický model.
Operace síťového modelu jsou navigační ve stylu: program udržuje aktuální pozici a naviguje z jednoho záznamu do druhého sledováním vztahů, kterých se záznam účastní. Záznamy lze také lokalizovat zadáním klíčových hodnot.
Ačkoli to není základní vlastnost modelu, síťové databáze obecně implementují nastavené vztahy pomocí ukazatelů, které přímo adresují umístění záznamu na disku. To poskytuje vynikající výkon při načítání na úkor operací, jako je načítání a reorganizace databáze.
Většina databází Object používá navigační koncept k zajištění rychlé navigace mezi sítěmi objektů, obecně používá Object Identifiers jako „chytré“ ukazatele na související objekty. Objectivity/DB například implementuje pojmenované 1:1, 1:many, Many:1 a Many:Many pojmenované vztahy, které mohou procházet databázemi. Mnoho databází objektů také podporuje SQL, kombinuje silné stránky obou modelů.
Relační model byl zaveden v akademické práci E. F. Codda v roce 1970 jako způsob, jak učinit systémy správy databází nezávislejší na konkrétní aplikaci. Je to matematický model definovaný z hlediska predikátové logiky a teorie množin.
Produkty, které jsou obecně označovány jako relační databáze, ve skutečnosti implementují model, který je pouze aproximací k matematickému modelu definovanému Coddem. V relačních databázových modelech se hojně používají tři klíčové pojmy: relace, atributy a domény. Relace je tabulka se sloupci a řádky. Pojmenované sloupce relace se nazývají atributy a doména je množina hodnot, které mohou atributy nabývat.
Základní datovou strukturou relačního modelu je tabulka, kde jsou informace o konkrétní entitě (například zaměstnanci) zastoupeny ve sloupcích a řádcích (také nazývaných tuples). Tedy „relace“ v „relační databázi“ odkazuje na různé tabulky v databázi; relace je množina tuplů. Sloupce obsahují výčet různých atributů entity (například jméno, adresa nebo telefonní číslo zaměstnance) a řádek je aktuální instancí entity (konkrétního zaměstnance), která je reprezentována relací. Výsledkem je, že každá tupla tabulky zaměstnance představuje různé atributy jednoho zaměstnance.
Všechny relace (a tedy i tabulky) v relační databázi musí dodržovat některá základní pravidla, aby se kvalifikovaly jako relace. Za prvé, pořadí sloupců je v tabulce nepodstatné. Za druhé, v tabulce nemohou být identické n-tice nebo řádky. A za třetí, každá n-tice bude obsahovat jednu hodnotu pro každý ze svých atributů.
Relační databáze obsahuje více tabulek, z nichž každá je podobná té v „plochém“ databázovém modelu. Jednou ze silných stránek relačního modelu je, že v zásadě každá hodnota vyskytující se ve dvou různých záznamech (patřících do stejné tabulky nebo do různých tabulek) implikuje vztah mezi těmito dvěma záznamy. Přesto, za účelem vynucení explicitních omezení integrity,
mohou být vztahy mezi záznamy v tabulkách také definovány explicitně, identifikací nebo neidentifikováním vztahů mezi rodičem a dítětem charakterizovaných přiřazením kardinality (1:1, (0)1:M, M:M). Tabulky mohou mít také určený jediný atribut nebo sadu atributů, které mohou fungovat jako „klíč“, který může být použit k jedinečné identifikaci každé tuple v tabulce.
Klíč, který lze použít k jednoznačné identifikaci řádku v tabulce, se nazývá primární klíč. Klíče se běžně používají ke spojení nebo kombinování dat ze dvou nebo více tabulek. Například tabulka Zaměstnanec může obsahovat sloupec s názvem Umístění, který obsahuje hodnotu odpovídající klíči tabulky Umístění. Klíče jsou také kritické při vytváření indexů, které usnadňují rychlé načítání dat z velkých tabulek. Každý sloupec může být klíčem nebo lze seskupit více sloupců do složeného klíče. Není nutné předem definovat všechny klíče; sloupec lze použít jako klíč i v případě, že jím původně neměl být.
Klíč, který má vnější, reálný význam (například jméno osoby, ISBN knihy nebo sériové číslo automobilu), se někdy nazývá „přirozený“ klíč. Pokud není vhodný žádný přirozený klíč (vzpomeňme na mnoho lidí jménem Brown), může být přiřazen libovolný nebo náhradní klíč (například přidělením identifikačních čísel zaměstnanců). V praxi má většina databází vygenerované i přirozené klíče, protože vygenerované klíče mohou být interně použity k vytvoření vazeb mezi řádky, které se nemohou prolomit, zatímco přirozené klíče mohou být použity méně spolehlivě k vyhledávání a integraci s jinými databázemi. (Například záznamy ve dvou nezávisle vyvinutých databázích by mohly být porovnávány podle čísla sociálního zabezpečení, s výjimkou případů, kdy jsou čísla sociálního zabezpečení nesprávná, chybí nebo se změnila.)
Uživatelé (nebo programy) požadují data z relační databáze tak, že jí zašlou dotaz, který je napsán ve speciálním jazyce, obvykle dialektu SQL. Ačkoli SQL byl původně určen pro koncové uživatele, je mnohem běžnější, že SQL dotazy jsou vloženy do softwaru, který poskytuje jednodušší uživatelské rozhraní. Mnoho webových stránek, jako například Wikipedia, provádí SQL dotazy při generování stránek.
V odpovědi na dotaz databáze vrací množinu výsledků, což je jen seznam řádků obsahujících odpovědi. Nejjednodušší dotaz je jen vrátit všechny řádky z tabulky, ale častěji jsou řádky nějakým způsobem filtrovány, aby vrátily právě požadovanou odpověď.
Často se data z více tabulek spojí do jedné, a to spojením. Koncepčně se to dělá tak, že se vezmou všechny možné kombinace řádků (kartézský součin) a pak se odfiltruje všechno kromě odpovědi. V praxi relační systémy správy databází přepisují („optimalizují“) dotazy, aby se prováděly rychleji, a to pomocí různých technik.
Flexibilita relačních databází umožňuje programátorům psát dotazy, které návrháři databází nepředpokládali. Výsledkem je, že relační databáze mohou být využívány více aplikacemi způsoby, které původní návrháři nepředpokládali, což je zvláště důležité u databází, které mohou být využívány po desetiletí. To učinilo myšlenku a implementaci relačních databází velmi populární u firem.
Vztahy jsou klasifikovány podle typů anomálií, vůči kterým jsou zranitelné. Databáze, která je v první normální formě, je zranitelná vůči všem typům anomálií, zatímco databáze, která je v doménové/klíčové normální formě, nemá žádné modifikační anomálie. Normální formy jsou svou povahou hierarchické. To znamená, že nejnižší úroveň je první normální forma a databáze nemůže splnit požadavky na vyšší úroveň normálních forem, aniž by nejprve splnila všechny požadavky nižších normálních forem.
Dimenzionální model je specializovaná adaptace relačního modelu používaného k reprezentaci dat v datových skladech tak, aby data mohla být snadno shrnuta pomocí OLAP dotazů. V dimenzionálním modelu se databáze skládá z jedné velké tabulky faktů, které jsou popsány pomocí dimenzí a ukazatelů. Dimenze poskytuje kontext faktu (například kdo se účastnil, kdy a kde se to stalo a její typ) a používá se v dotazech ke seskupování souvisejících faktů. Dimenze bývají diskrétní a často hierarchické; například umístění může zahrnovat budovu, stát a zemi. Míra je veličina popisující fakt, například výnosy. Je důležité, aby ukazatele mohly být smysluplně agregovány – například výnosy z různých míst mohou být sečteny.
V OLAP dotazu jsou zvoleny dimenze a fakta jsou seskupena a sečtena, aby vznikl souhrn.
Dimenzionální model je často implementován nad relačním modelem pomocí hvězdicového schématu, které se skládá z jedné tabulky obsahující fakta a okolních tabulek obsahujících rozměry. Zvláště komplikované rozměry mohou být reprezentovány pomocí více tabulek, což vede ke schématu sněhové vločky.
Datový sklad může obsahovat více hvězdicových schémat, která sdílejí dimenzionální tabulky, což umožňuje jejich společné použití. Důležitou součástí dimenzionálního modelování je přijít se standardní sadou dimenzí.
V posledních letech se v databázové technologii uplatňuje objektově orientované paradigma, které vytváří nový programovací model známý jako objektové databáze. Tyto databáze se snaží přiblížit databázový svět a aplikační programovací svět, zejména tím, že zajišťují, aby databáze používala stejný typový systém jako aplikační program. To má za cíl vyhnout se režii (někdy označované jako impedanční nesoulad) při převodu informací mezi jejich reprezentací v databázi (například jako řádky v tabulkách) a jejich reprezentací v aplikačním programu (typicky jako objekty). Objektové databáze se zároveň snaží zavést do světa databází klíčové myšlenky objektového programování, jako je zapouzdření a polymorfismus.
Pro ukládání objektů do databáze byla vyzkoušena celá řada těchto způsobů. Některé produkty přistupují k problému z programovacího konce aplikace tak, že objekty manipulované programem jsou trvalé. To také obvykle vyžaduje přidání nějakého druhu dotazovacího jazyka, protože konvenční programovací jazyky nemají schopnost vyhledávat objekty na základě jejich informačního obsahu. Jiné zaútočily na problém z databázového konce tím, že definovaly objektově orientovaný datový model pro databázi a definovaly databázový programovací jazyk, který umožňuje plné programovací schopnosti i tradiční dotazovací prostředky.
Objektové databáze trpěly nedostatkem standardizace: přestože standardy byly definovány ODMG, nikdy nebyly implementovány tak dobře, aby zajistily interoperabilitu mezi produkty. Objektové databáze byly nicméně úspěšně využívány v mnoha aplikacích: obvykle specializované aplikace jako inženýrské databáze nebo databáze molekulární biologie spíše než běžné komerční zpracování dat. Nápady s objektovými databázemi však byly zachyceny relačními dodavateli a ovlivnily rozšíření těchto produktů a vlastně i jazyka SQL.