Database Design

523
-1

Published on

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).

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
523
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
18
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Rule 0: The system must qualify as relational, as a database, and as a management system.For a system to qualify as a relational database management system (RDBMS), that system must use its relational facilities (exclusively) to manage the database. Rule 1: The information rule:All information in the database to be represented in one and only one way, namely by values in column positions within rows of tables. Rule 2 : The guaranteed access rule:All data must be accessible with no ambiguity. This rule is essentially a restatement of the fundamental requirement for primary keys. It says that every individual scalar value in the database must be logically addressable by specifying the name of the containing table, the name of the containing column and the primary key value of the containing row. Rule 3:Systematic treatment of null values:The DBMS must allow each field to remain null (or empty). Specifically, it must support a representation of "missing information and inapplicable information" that is systematic, distinct from all regular values (for example, "distinct from zero or any other number," in the case of numeric values), and independent of data type. It is also implied that such representations must be manipulated by the DBMS in a systematic way. Rule 4:Active online catalog based on the relational model:The system must support an online, inline, relational catalog that is accessible to authorized users by means of their regular query language. That is, users must be able to access the database's structure (catalog) using the same query language that they use to access the database's data. Rule 5: The comprehensive data sublanguage rule:The system must support at least one relational language that (a) Has a linear syntax (b) Can be used both interactively and within application programs, (c) Supports data definition operations (including view definitions), data manipulation operations (update as well as retrieval), security and integrity constraints, and transaction management operations (begin, commit, and rollback). Rule 6: The view updating rule:All views that are theoretically updatable must be updatable by the system. Rule 7:High-level insert, update, and delete:The system must support set-at-a-time insert, update, and delete operators. This means that data can be retrieved from a relational database in sets constructed of data from multiple rows and/or multiple tables. This rule states that insert, update, and delete operations should be supported for any retrievable set rather than just for a single row in a single table. Rule 8:Physical data independence:Changes to the physical level (how the data is stored, whether in arrays or linked lists etc.) must not require a change to an application based on the structure. Rule 9:Logical data independence:Changes to the logical level (tables, columns, rows, and so on) must not require a change to an application based on the structure. Logical data independence is more difficult to achieve than physical data independence. Rule 10:Integrity independence:Integrity constraints must be specified separately from application programs and stored in the catalog. It must be possible to change such constraints as and when appropriate without unnecessarily affecting existing applications. Rule 11:Distribution independence:The distribution of portions of the database to various locations should be invisible to users of the database. Existing applications should continue to operate successfully : (a) when a distributed version of the DBMS is first introduced; and (b) when existing distributed data are redistributed around the system. Rule 12: The nonsubversion rule:If the system provides a low-level (record-at-a-time) interface, then that interface cannot be used to subvert the system, for example, bypassing a relational security or integrity constraint. Retrieved from "http://en.wikipedia.org/wiki/Codd%27s_12_rules"
  • Database Design

    1. 1. Template designed byDatabase DesignDavide Mauridmauri@solidq.comwww.davidemauri.it
    2. 2. brought to you by
    3. 3. Works with SQL Server from 6.5, on BI from 2003Specialized in Data Solution Architecture, Database Design,Performance Tuning, BIMicrosoft SQL Server MVPPresident of UGISS (Italian SQL Server UG)Mentor @ SolidQRegular Speaker @ SQL Server eventsConsulting & TrainingDavide Mauri3
    4. 4. The relational model is simply the application of logic todatabase management.[…] databases are collections of predicates and DBMS areessentially logic inference engines.[…] logic is whatguarantees correctness of the information recorded indatabases, and the answers obtained from them (withcorrectness defined as consistency—internal, and with thebusiness rules in effect).Fabian PascalMi serve la teoria?4
    5. 5. Performance Pyramid (Development POV)5
    6. 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 deltempoImpossibilità di ricavare informazioni utili dai datiDifficoltà nella scrittura delle applicazioni• Un DB ha un periodo di vita che è ALMENO il triplo di quello di un’applicazioneEnormi difficoltà nella creazione di soluzioni di Reportistica e BIDifficolta di integrazioneModellare costa! Qual è il ROI?6
    7. 7. Relazioni (relations) – Le tabelleAttributi – Le colonneTuple – Le righeLe tuple, gli attributi non sono nè ordinati nè numerati.Non possono esistere tuple o attributi duplicatiLe tabelle definiscono la struttura dell’entità che rappresentanoI dati sono i valori “concreti” delle entità (le “instanze”)I dati sono le informazioni di businessOverview informale del modello relazionale7
    8. 8. Ogni riga è identificabile tramite la sua primary keyI dati sono mantenuti consistenti tramite constraints (vincoli)Attraverso i vincoli assicuriamo la correttezza dell’implementazione delle nostre regole di businessOgni tabella deve contenere informazioni su una ed una sola entitàLe tabelle sono ―collegate‖ tra di loro tramite relazioni (relationships)Overview informale del modello relazionale8
    9. 9. Due tipi di relazioniBinary• 1:1• 1:N• N:MN-ary • Coinvolgono più di due tabelle (entita) (Es: Speaker, Sessione, Sala, Orario)Le relazioni si ―creano‖ tramite (primary) key / foreign keyLe forme normali aiutano ad arrivare ad un design correttoOverview informale del modello relazionale9
    10. 10. Il modello relazione E’ ―AGILE―Un DB modellato correttamente è in grado di rispondere velocemente aicambiamenti• Es. Memorizzare dati MAI previsti in precedenzaCodd rule #10: Integrity indipendenceI database SONO LOSELY COUPLED con le applicazioniche li usanoCodd rule #8: Physical data indipendenceCodd rule #9: Logical data indipendencePrecisazioni sul modello relazionale10
    11. 11. Un database è un motore di inferenza logicaLa logica è basata sul concetto di predicatoUn predicato è una frase genericaEs: “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 PREDICATOLa Normalizzazione11
    12. 12. Definito e fissato un predicato posso memorizzare solo ivalori:{Abissi d’Acciaio, Isaac Asimov, 12345, Davide Mauri, 13 Aprile 2013}• Rappresenta la PROPOSIZIONE definita in precedenzaQuindiUna tabella, tramite la sua struttura, definisce il predicatoLe righe di ogni tabella sono le “entità” i cui valori definiscono una proposizioneOgni riga in ogni tabella rappresenta un “fatto vero”• Ossia una Proposizione VeraLa Normalizzazione12
    13. 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 altretabelle?Esite una modo per validare ―formalmente‖ il lavoro che ho fatto?La risposta è ―La Normalizzazione‖ La Normalizzazione13
    14. 14. Supponiamo di dover implementare un’applicazione (equindi un DB) che permetta la gestione di una semplicebibliotecaVia alle idee!Quali entità creiamo?Perché?Interaction Time! 14
    15. 15. Lo scopo comune è stato quello diMinimizzare la dimensione delle tabelleFare una tabella per ogni entitàTutte le scelte sono state basate su ―sensazioni‖Quindi esperienzaAbbiamo appena dimostrato che la normalizzazione ci aiuta a formalizzare un processo mentaleche GIA METTIAMO IN ATTO per una buona parteEsistono delle regole che permettono di far si che il processosperimentato non sia SOLAMENTE basato sull’esperienza e le―sensazioni‖La Normalizzazione15
    16. 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 oggettipiccoli (quindi di facile manipolazione) assicurandoci che surichiesta potremo ricomporre la tabella originale, senza perdita didatiRiduzione delle problematiche legate a “update anomalies”Riduzione dei vincoli da dover imporre a posteriori per poter essicurare la veridicità dellenostre proposizioniLa Normalizzazione16
    17. 17. Partiamo da ZERO, semplicemente mappando i placeholderdel nostro predicato in una tabellaLa Normalizzazione ―Live‖ 17
    18. 18. Una tabella è in 1° FN se:Gli attributi di ogni entità hanno valori atomiciTutte le righe anno lo stesso numero di valoriNon 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 NULLIntroducono una 3-Value Logic che NON E’ APPLICABILE NEL MODO REALEPrima forma normale18
    19. 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 normale19
    20. 20. Candidate key:Una colonna o una serie di colonne che permettono l’identificazione univoca di unarigaCe ne possono essere più di una per tabellaPrimary key:Una particolare Candidate Key che è• Stabile• MinimaleKeys: Candidate & Primary20
    21. 21. Ecco come si presenta la nostra tabella in 1FN:Prima forma normale21
    22. 22. Che problemi ci evita la 1FN?Abbassa la difficolta della scrittura della queryPermette all’optimizer di un RDBMS di lavorare bene• A volte di lavorare in assoluto Evita spiacevoli “update anomalies”• Aggiornamento parziale di datiPrima forma normale22
    23. 23. Che problemi ci sono ancora?Non posso rimuovere un utente dal mio database SENZA dover rimuovere anchelinformazione che il libro è stato preso in prestitoSe voglio modificare il nome di un Autore devo aggiornare TUTTE le righe cheinteressano quell’autoreNon posso tenere traccia dei libri a meno che non siano stati presi in prestitoNon posso avere libri scritti da più autori• E non posso risolvere questo problema semplicemente aggiungendo “Autore2” perché altrimentitornerei a violare la 1FN…Prima forma normale23
    24. 24. 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 contrarioQuindiY ha una dipendenza funzionale da XX determina YEs: Codice Fiscale e NomePer per ogni valore del CF è associato uno ed un solo valore del Nome utente, mentre peruno stesso nome utente ci possono essere CF diversiDipendenze Funzionali24
    25. 25. Una tabella è in 2FN seE’ in 1FNTutti gli attributi descrivono un realtà legata alla chiavePiù formalmenteE’ in 1FNOgni attributo non chiave dipende funzionalmente dalla chiave completa (e quindinon solo da un parte di essa, nel caso di chiavi composte)Seconda forma normale25
    26. 26. Risultato:Seconda forma normale26
    27. 27. Che problemi rimangono ancora aperti?Non posso modificare i dati di un autore senza andare a toccare tutte le righe in cuil’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 hodue libri dello stesso autore e solo in un caso aggiorno i dati? Come posso poi sapere qualedelle due righe è corretta?Un libro non può essere scritto da più autoriSeconda forma normale27
    28. 28. Una tabella è 3FN seÈ in 2FNNon esistono attributi che descrivono una realtà della chiave in modo indiretto (ossiariferendosi ad un attributo intermedio)Più formalmenteE’ in 2FNOgni attributo non chiave dipende direttamente dalla chiave completaTerza forma normale28
    29. 29. Risultato:Terza forma normale29
    30. 30. Che problemi ci sono ancora?Non siamo riusciti a modellare la necessità di avere più autori per ogni libroPerché è 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 normale30
    31. 31. Data Model Finale31
    32. 32. Rispetto alla situazione di partenza posso:Catalogare libri anche se nessuno li prende in prestitoFar iscrivere gli utenti anche se non prendono in prestito libriRicercare tutti i libri fatti da un autore in modo efficiente• E modificare i dati dell’autore solo in un puntoRicercare 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 puntoScrivere query in modo MOLTO più semplice ed ottimizzabileChe cosa ho ottenuto?32
    33. 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 avereDB molto flessibile che permettono un facile aggiornamento deldb 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 esp per garantirci un livello di astrazione dal db fisico, oltre che una semplificazione per l’utente cheusa il dbChe cosa ho ottenuto?33
    34. 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 unmodello correttoMa quando non conosciamo COSI BENE il tema?E quando il buon senso non basta?Conclusioni34
    35. 35. La normalizzazione è un processo ITERATIVOBasato sulla “creazione” di nuove entitàPermette di creare entità che all’inizio non erano “visibili” nelle nostre proposizioniPermette di CAPIRE MEGLIO il processo che stiamo modellandoConclusioni35
    36. 36. Grazie a tutti per la partecipazioneRiceverete il link per il download a slide e demo via email neiprossimi giorniPer contattarmidmauri@solidq.comGrazie

    ×