Data Modeling — Cheat Sheet

Tag: database, sql, nosql, schema, normalization, erd, architecture

Livello: intermedio

TL;DR: Il data modeling è il processo di creazione di una rappresentazione strutturata dei dati e delle loro relazioni. Serve a garantire integrità, scalabilità e performance del sistema.

Concetti chiave

I modelli di dati si dividono in: concettuali (high-level), logici (struttura e attributi) e fisici (implementazione specifica per il DB).

L'Entity-Relationship Diagram (ERD) mappa entità (tabelle), attributi (colonne) e relazioni (1:1, 1:N, M:N).

La normalizzazione (1NF, 2NF, 3NF) riduce la ridondanza e migliora l'integrità dei dati dividendoli in tabelle correlate.

La denormalizzazione si usa in ambito analitico (OLAP) per ottimizzare le performance di lettura, riducendo i JOIN.

Le chiavi primarie (PK) identificano univocamente un record; le chiavi esterne (FK) definiscono i vincoli di integrità referenziale.

I modelli dimensionali (Star Schema, Snowflake Schema) sono lo standard nei Data Warehouse per aggregazioni veloci.

Nei database NoSQL, il data modeling è guidato dai pattern di accesso (query-driven) anziché dalle relazioni.

L'indicizzazione migliora i tempi di lettura, ma introduce un overhead sulle operazioni di scrittura.

Domande tipiche e risposte pronte

Q: Quando sceglieresti un database relazionale rispetto a uno NoSQL?R: Scelgo SQL quando ho dati strutturati, relazioni complesse e necessito di transazioni ACID rigorose. Opto per NoSQL se ho dati non strutturati, schema flessibile o esigenze di scalabilità orizzontale.

Q: Spiegami la differenza tra Star Schema e Snowflake Schema.R: Nello Star Schema le tabelle dimensionali sono denormalizzate e connesse direttamente alla fact table. Nello Snowflake, le dimensioni sono normalizzate in sotto-tabelle, risparmiando spazio ma richiedendo più JOIN.

Q: A cosa serve e quali problemi porta la denormalizzazione in un database OLTP?R: Serve a velocizzare le letture evitando JOIN costosi, ma in un sistema transazionale rischia di causare anomalie di aggiornamento e dati inconsistenti a causa della ridondanza.

Insidie e errori comuni

Progettare lo schema fisico NoSQL senza aver prima definito i pattern di accesso (access patterns) ai dati.

Dimenticare di implementare indici sulle colonne usate frequentemente nelle clausole WHERE o nei JOIN.

Usare UUID generati casualmente come Primary Key in database che usano indici clustered (es. MySQL InnoDB), causando grave frammentazione.

Creare tabelle "god object" con decine di colonne che violano il principio di singola responsabilità dei dati.

Snippet e comandiSQL

```-- Creazione di tabelle con vincoli e relazioni

CREATE TABLE users (

user_id UUID PRIMARY KEY,

email VARCHAR(255) UNIQUE NOT NULL

);

CREATE TABLE orders (

order_id SERIAL PRIMARY KEY,

user_id UUID NOT NULL,

amount DECIMAL(10, 2) NOT NULL,

FOREIGN KEY (user_id) REFERENCES users(user_id) ON DELETE CASCADE

);

-- Creazione di un indice composito per ottimizzare query frequenti

CREATE INDEX idx_orders_user_amount ON orders(user_id, amount);

```

Da ripassare

[ ] Differenza pratica tra BCNF (Boyce-Codd Normal Form) e 3NF.

[ ] Pattern di Single Table Design per database NoSQL (es. DynamoDB).