Come modellare correttamente un database? Cosa sono e come si usano - nella pratica - le regole di normalizzazione? Che tipo di scelte dobbiamo fare quando andiamo a creare una tabella? Che impatto hanno sulle performance? In questa sessione andremo a capire come modellare correttamente un database, affrontando il problema dal punto di vista del modello logico (dove le performance sono un problema trascurabili) e riportandolo quindi sul modello fisico (dove invece le performance sono il problema principale).

1. Template designed by
Database Design
Davide Mauri
dmauri@solidq.com
www.davidemauri.it

2. brought to you by

3. Works with SQL Server from 6.5, on BI from 2003
Specialized in Data Solution Architecture, Database Design,
Performance Tuning, BI
Microsoft SQL Server MVP
President of UGISS (Italian SQL Server UG)
Mentor @ SolidQ
Regular Speaker @ SQL Server events
Consulting & Training
Davide Mauri
3

4. The relational model is simply the application of logic to
database management.
[…] databases are collections of predicates and DBMS are
essentially logic inference engines.[…] logic is what
guarantees correctness of the information recorded in
databases, and the answers obtained from them (with
correctness defined as consistency—internal, and with the
business rules in effect).
Fabian Pascal
Mi serve la teoria?
4

5. Performance Pyramid (Development POV)
5

6. Un database modellato male memorizza comunque i dati!
Perché dovrei spendere soldi nella modellazione?
Gli effetti negativi si vedono (e si amplificano) con il passare del
tempo
Impossibilità di ricavare informazioni utili dai dati
Difficoltà nella scrittura delle applicazioni
• Un DB ha un periodo di vita che è ALMENO il triplo di quello di un’applicazione
Enormi difficoltà nella creazione di soluzioni di Reportistica e BI
Difficolta di integrazione
Modellare costa! Qual è il ROI?
6

7. Relazioni (relations) – Le tabelle
Attributi – Le colonne
Tuple – Le righe
Le tuple, gli attributi non sono nè ordinati nè numerati.
Non possono esistere tuple o attributi duplicati
Le tabelle definiscono la struttura dell’entità che rappresentano
I dati sono i valori “concreti” delle entità (le “instanze”)
I dati sono le informazioni di business
Overview informale del modello relazionale
7

8. Ogni riga è identificabile tramite la sua primary key
I dati sono mantenuti consistenti tramite constraints (vincoli)
Attraverso i vincoli assicuriamo la correttezza dell’implementazione delle nostre regole di business
Ogni tabella deve contenere informazioni su una ed una sola entità
Le tabelle sono ―collegate‖ tra di loro tramite relazioni (relationships)
Overview informale del modello relazionale
8

9. Due tipi di relazioni
Binary
• 1:1
• 1:N
• N:M
N-ary 
• Coinvolgono più di due tabelle (entita) (Es: Speaker, Sessione, Sala, Orario)
Le relazioni si ―creano‖ tramite (primary) key / foreign key
Le forme normali aiutano ad arrivare ad un design corretto
Overview informale del modello relazionale
9

10. Il modello relazione E’ ―AGILE―
Un DB modellato correttamente è in grado di rispondere velocemente ai
cambiamenti
• Es. Memorizzare dati MAI previsti in precedenza
Codd rule #10: Integrity indipendence
I database SONO LOSELY COUPLED con le applicazioni
che li usano
Codd rule #8: Physical data indipendence
Codd rule #9: Logical data indipendence
Precisazioni sul modello relazionale
10

11. Un database è un motore di inferenza logica
La logica è basata sul concetto di predicato
Un predicato è una frase generica
Es: “Il libro ‘Abissi d’Acciaio’ di Isaac Asimov, codice ISBN 12345, è
stato preso in prestito da Davide Mauri in data 13 Aprile 2013
La generalizzazione di questa frase (PROPOSIZIONE) è “il libro <nomelibro> dell’autore <autore>,
codice <codicelibro> è stato preso in prestito da <nomeutente> in data <dataprestito>
La versione generica prende il nome di PREDICATO
La Normalizzazione
11

12. Definito e fissato un predicato posso memorizzare solo i
valori:
{Abissi d’Acciaio, Isaac Asimov, 12345, Davide Mauri, 13 Aprile 2013}
• Rappresenta la PROPOSIZIONE definita in precedenza
Quindi
Una tabella, tramite la sua struttura, definisce il predicato
Le righe di ogni tabella sono le “entità” i cui valori definiscono una proposizione
Ogni riga in ogni tabella rappresenta un “fatto vero”
• Ossia una Proposizione Vera
La Normalizzazione
12

13. Esiste un modo per capire se le tabelle che abbiamo creato sono
―corrette‖?
Esiste un processo che ci permette di capire se dobbiamo creare altre
tabelle?
Esite una modo per validare ―formalmente‖ il lavoro che ho fatto?
La risposta è ―La Normalizzazione‖ 
La Normalizzazione
13

14. Supponiamo di dover implementare un’applicazione (e
quindi un DB) che permetta la gestione di una semplice
biblioteca
Via alle idee!
Quali entità creiamo?
Perché?
Interaction Time! 
14

15. Lo scopo comune è stato quello di
Minimizzare la dimensione delle tabelle
Fare una tabella per ogni entità
Tutte le scelte sono state basate su ―sensazioni‖
Quindi esperienza
Abbiamo appena dimostrato che la normalizzazione ci aiuta a formalizzare un processo mentale
che GIA METTIAMO IN ATTO per una buona parte
Esistono delle regole che permettono di far si che il processo
sperimentato non sia SOLAMENTE basato sull’esperienza e le
―sensazioni‖
La Normalizzazione
15

16. E’ un processo di ―nonloss decomposition‖
Permette di arrivare ad avere ―one-fact-per-table‖
Ossia: ci permette di decomporre il nostro data model in oggetti
piccoli (quindi di facile manipolazione) assicurandoci che su
richiesta potremo ricomporre la tabella originale, senza perdita di
dati
Riduzione delle problematiche legate a “update anomalies”
Riduzione dei vincoli da dover imporre a posteriori per poter essicurare la veridicità delle
nostre proposizioni
La Normalizzazione
16

17. Partiamo da ZERO, semplicemente mappando i placeholder
del nostro predicato in una tabella
La Normalizzazione ―Live‖ 
17

18. Una tabella è in 1° FN se:
Gli attributi di ogni entità hanno valori atomici
Tutte le righe anno lo stesso numero di valori
Non esistono righe duplicate
“Gli attributi di ogni entità hanno valori atomici”
Non dobbiamo inserire dati “multivalue”
Es. dati separati da virgola
“Tutte le righe anno lo stesso numero di valori”
NON C’E’ POSTO PER I NULL
Introducono una 3-Value Logic che NON E’ APPLICABILE NEL MODO REALE
Prima forma normale
18

19. ―Non esistono righe duplicate‖
Tutte le tabelle hanno una Primary Key
• NON BASTA METTERE UN “ID”…dobbiamo ragionare a livello logico prima di tutto!
Prima forma normale
19

20. Candidate key:
Una colonna o una serie di colonne che permettono l’identificazione univoca di una
riga
Ce ne possono essere più di una per tabella
Primary key:
Una particolare Candidate Key che è
• Stabile
• Minimale
Keys: Candidate & Primary
20

21. Ecco come si presenta la nostra tabella in 1FN:
Prima forma normale
21

22. Che problemi ci evita la 1FN?
Abbassa la difficolta della scrittura della query
Permette all’optimizer di un RDBMS di lavorare bene
• A volte di lavorare in assoluto 
Evita spiacevoli “update anomalies”
• Aggiornamento parziale di dati
Prima forma normale
22

23. Che problemi ci sono ancora?
Non posso rimuovere un utente dal mio database SENZA dover rimuovere anche
l'informazione che il libro è stato preso in prestito
Se voglio modificare il nome di un Autore devo aggiornare TUTTE le righe che
interessano quell’autore
Non posso tenere traccia dei libri a meno che non siano stati presi in prestito
Non posso avere libri scritti da più autori
• E non posso risolvere questo problema semplicemente aggiungendo “Autore2” perché altrimenti
tornerei a violare la 1FN…
Prima forma normale
23

24. Tra due attributi X e Y esiste una dipendenza funzionale se
Per ogni valore di X esiste uno ed un solo valore di Y
• Non si applica il contrario
Quindi
Y ha una dipendenza funzionale da X
X determina Y
Es: Codice Fiscale e Nome
Per per ogni valore del CF è associato uno ed un solo valore del Nome utente, mentre per
uno stesso nome utente ci possono essere CF diversi
Dipendenze Funzionali
24

25. Una tabella è in 2FN se
E’ in 1FN
Tutti gli attributi descrivono un realtà legata alla chiave
Più formalmente
E’ in 1FN
Ogni attributo non chiave dipende funzionalmente dalla chiave completa (e quindi
non solo da un parte di essa, nel caso di chiavi composte)
Seconda forma normale
25

26. Risultato:
Seconda forma normale
26

27. Che problemi rimangono ancora aperti?
Non posso modificare i dati di un autore senza andare a toccare tutte le righe in cui
l’autore è presente nella tabella “Libri”
• Ancora una volta questo significa che dobbiamo scrivere query più complesse
• Ancora una volta questo rappresenta una potenziale incongruenza nei dati…cosa succede se ho
due libri dello stesso autore e solo in un caso aggiorno i dati? Come posso poi sapere quale
delle due righe è corretta?
Un libro non può essere scritto da più autori
Seconda forma normale
27

28. Una tabella è 3FN se
È in 2FN
Non esistono attributi che descrivono una realtà della chiave in modo indiretto (ossia
riferendosi ad un attributo intermedio)
Più formalmente
E’ in 2FN
Ogni attributo non chiave dipende direttamente dalla chiave completa
Terza forma normale
28

29. Risultato:
Terza forma normale
29

30. Che problemi ci sono ancora?
Non siamo riusciti a modellare la necessità di avere più autori per ogni libro
Perché è un problema legato alla prima forma normale! 
Proviamo ad immaginare di aggiungere IdAutore1, IdAutore2, ecc.
Rifacciamo il processo di normalizzaione su questa nuova condizione
• A questo punto per la prima forma normale creiamo una nuova tabella “AutoriLibri”
Terza forma normale
30

31. Data Model Finale
31

32. Rispetto alla situazione di partenza posso:
Catalogare libri anche se nessuno li prende in prestito
Far iscrivere gli utenti anche se non prendono in prestito libri
Ricercare tutti i libri fatti da un autore in modo efficiente
• E modificare i dati dell’autore solo in un punto
Ricercare tutti i libri prelevati da un utente in modo efficiente
• E modificare i dati dell’utente in un solo punto
• E modificare i dati del libri in un solo punto
Scrivere query in modo MOLTO più semplice ed ottimizzabile
Che cosa ho ottenuto?
32

33. Ed in più:
Ho “scoperto” l’entità AutoriLibri
• Posso ampliarla per sapere che tipo di contributo ha dato un autore al libro (ad esempio)
Seguendo le regole di normalizzazione possiamo quindi avere
DB molto flessibile che permettono un facile aggiornamento del
db per seguire nuove regole di business
In una parola: siamo AGILI!
• Ricordiamoci però di non legare in modo indivisibile le nostre applicazioni al db…ossia: usiamo viste e
sp per garantirci un livello di astrazione dal db fisico, oltre che una semplificazione per l’utente che
usa il db
Che cosa ho ottenuto?
33

34. Conoscendo abbastanza bene il problema da modellare,
avremmo potuto bypassare la normalizzazione fatta ―step-
by-step‖ perché il buon senso ci avrebbe portato a creare un
modello corretto
Ma quando non conosciamo COSI BENE il tema?
E quando il buon senso non basta?
Conclusioni
34

35. La normalizzazione è un processo ITERATIVO
Basato sulla “creazione” di nuove entità
Permette di creare entità che all’inizio non erano “visibili” nelle nostre proposizioni
Permette di CAPIRE MEGLIO il processo che stiamo modellando
Conclusioni
35

36. Grazie a tutti per la partecipazione
Riceverete il link per il download a slide e demo via email nei
prossimi giorni
Per contattarmi
dmauri@solidq.com
Grazie