Template designed by

Database Design

Davide Mauridmauri@solidq.com www.davidemauri.it

brought to you by

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

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

Performance Pyramid (Development POV)

5

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 tempoImpossibilità 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

Relazioni (relations) – Le tabelleAttributi – 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 rappresentanoI dati sono i valori “concreti” delle entità (le “instanze”)

I dati sono le informazioni di business

Overview informale del modello relazionale

7

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

Due tipi di relazioniBinary

• 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

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 usanoCodd rule #8: Physical data indipendence

Codd rule #9: Logical data indipendence

Precisazioni sul modello relazionale

10

Un database è un motore di inferenza logica

La logica è basata sul concetto di predicatoUn 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 2013La 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

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

QuindiUna 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

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

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

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

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 datiRiduzione 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

Partiamo da ZERO, semplicemente mappando i placeholder del nostro predicato in una tabella

La Normalizzazione “Live”

17

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

“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

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

Ecco come si presenta la nostra tabella in 1FN:

Prima forma normale

21

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

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

Tra due attributi X e Y esiste una dipendenza funzionale sePer ogni valore di X esiste uno ed un solo valore di Y

• Non si applica il contrario

QuindiY ha una dipendenza funzionale da X

X determina Y

Es: Codice Fiscale e NomePer 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

Una tabella è in 2FN seE’ in 1FN

Tutti gli attributi descrivono un realtà legata alla chiave

Più formalmenteE’ 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

Risultato:

Seconda forma normale

26

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

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ù formalmenteE’ in 2FN

Ogni attributo non chiave dipende direttamente dalla chiave completa

Terza forma normale

28

Risultato:

Terza forma normale

29

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

Data Model Finale

31

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

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 businessIn 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

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 correttoMa quando non conosciamo COSI BENE il tema?

E quando il buon senso non basta?

Conclusioni

34

La normalizzazione è un processo ITERATIVOBasato 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

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