Concetti di base dati

Rosario Turco

Una base dati è un insieme di dati: • logicamente congruenti, cioè aderenti alla realtà che rappresentano • minimamente ridondanti • Indipendenti dalla applicazione e dalla tecnologia Le basi dati sono progettate a partire dalla realtà che devono rappresentare, con tecniche ER o Object Oriented, bottom up o top-down. I concetti di dato e di oggetto (entità) coincidono. La tecnologia può fornire, invece, meccanismi diversi per la memorizzazione dei dati (persistenza, etc.) Le uniche ridondanze ammesse in modalità controllata sono: • per motivazioni prestazionali: un dato viene ripetuto (o «denormalizzato») per evitare sprechi di tempo • per motivi di integrità: copie di backup, registrazione dei soli aggiornamenti

Nel seguito approfondiremo l’Analisi Dati.

2

Una base dati si realizza attraverso l’ANALISI DATI. L’Analisi dati produce una rappresentazione, in termini di «astrazione», della realtà o del mondo del cliente, in modo da descrivere: • I dati coinvolti nelle funzionalità/servizi offerti dal sistema • Le relazioni tra i dati • Le caratteristiche quantitative e di struttura dei dati Il concetto di «astrazione», determina tutte le caratteristiche/attributi della realtà che possono aver senso o meno nel contesto del cliente. Ad esempio l’oggetto/entità auto per un meccanico avrà attributi/entità di interesse come: • Km percorsi dall’auto (per il cambio d’olio) • cliente (per l’emissione della fattura e il cliente non necessariamente è il proprietario) Per il Registro Automobilistico per l’auto avranno interesse alcuni attributi/entità come: • Numero di targa • Proprietario dell’auto
3

L’Analisi dei dati è, quindi, un processo di indagine col quale si descrive la realtà, attraverso: • I fenomeni in essa coinvolti • Le loro inter-relazioni Per le basi dati si utilizzano tecniche di Modellizzazione a tre livelli distinti: • Livello concettuale (Analisi dati) • Livello logico (Progettazione dati) • Livello fisico (Implementazione dati)

I database in generale sono almeno di due tipologie: • Database operazionali (OLTP=Online Transactional Processing) Caratterizzati dal dettaglio di ogni operazione di business • Datawarehouse (OLAP=OnLine Analytic Processing) Caratterizzati dall’aggregazione dei dati e la quantificazione delle operazioni, secondo determinati fatti, viste, aspetti, con possibilità di drill-down
Tipicamente i dati di uno o più database OLTP fanno da sorgenti ad un datawarehouse. Nel seguito faremo riferimento a database OLTP.
4

Nel livello concettuale si realizza, in ambito analisi dati, il cosiddetto Schema Concettuale, procedendo in due modalità alternative (viste): • Top-down • Bottom-up Top-down Nel top-down il punto di partenza sono i fenomeni che caratterizzano la realtà, gli oggetti/entità con le loro proprietà/attributi e le relative associazioni Fattura Cliente(Nome, Cognome, Indirizzo, PIVA) Indirizzo( Via, Città, CAP) Bottom-up Nel bottom-up il punto di partenza sono i dati elementari che raggruppati portano all’entità

Spesso per verifica e per individuare tutti i dati necessari si utilizzano entrambe le viste.

5

Lo schema concettuale è rivolto all’efficacia della base dati, nell’ambito dell’astrazione scelta. Lo schema logico è la traduzione dello schema concettuale individuato in modo Gerarchico, Relazionale, Reticolare, ad Oggetti, cioè in entità/oggetti tipici del particolare DBMS (DataBase Management System) disponibile. Un DBMS è un prodotto per gestire una base dati (ad esempio Oracle, MySQL, SQLServer). Lo schema logico è già rivolto in parte all’efficienza dell’applicazione. Lo schema logico è descritto tramite il DDL (Data Definition Language) del DBMS adottato. Lo schema fisico è la traduzione dello schema logico in modo da garantire aspetti di efficienza e prestazionali, di gestione e manutenzione della base dati (partizionamenti delle tabelle, svecchiamenti, backup, etc.)

Per interagire con i dati dello schema fisico si usano istruzioni descritte tramite il DML (Data Manipolation Language).

6

Un linguaggio strutturato e standard è l’SQL (Structured Query Language, standard ANSI SQL 92 ) L’SQL è un linguaggio per RDBMS cioè per DBMS Relazionali ed offre: • Istruzioni DDL (Data Definition Language) per creare database • Istruzioni DML (Data Manipolation Language) per le operazioni I,U,D,R e gestire il DB • Istruzioni DQL (Data Query Language) per effettuare query • Istruzioni DCL (Data Control Language) per creare, gestire strumenti di controlli dei dati • Istruzioni CTL (Control Transaction Language per gestire le transazioni)

• http://it.wikipedia.org/wiki/SQL

7

La progettazione di una base dati è basato sul modello di rappresentazione ER (Entity-Relation) di Chen e la teoria di normalizzazione di Codd. ER Il modello ER è basato su tre concetti: • Entità • Relazione • Attributo Entità Un qualsiasi oggetto, concreto o astratto, rilevante per la realtà del cliente, identificato univocamente con una semplice definizione. E’ rappresentato graficamente con un rettangolo.

Nel linguaggio della realtà è individuato da un «sostantivo».

Occorre distinguere tra il concetto di entità (concetto generalizzante, es: Società) e possibili valori dell’entità (valori=Fiat, Poste Italiane, Telecom, etc.), che rappresentano le occorrenze dell’entità. Entità Premio, Occorrenze: Nobel, Strega, Bancarella
8

Relazione E’ il legame tra una o più entità, per semplicità si disegna come un rombo, Nel linguaggio della realtà è individuato da un «verbo». Notaio, Stipula contratti, Acquirente, Venditore (3 entità in relazione) Esame, è propedeutico, Esame (relazione tra occorrenze diverse di una stessa entità) Scrittore Libro

scrive

Impiegato

lavora

Reparto

È capo di
9

Il verso della relazione, se non indicato, è da sinistra a destra, altrimenti viene indicato con una freccia. Si possono esprimere sia relazioni dirette che inverse. Esempio: Uno Scrittore «scrive» un Libro. Un libro «è scritto» da uno Scrittore.

10

Attributo E’ un elemento di informazione dell’Entità. Esempio: età, nome Una Entità ha uno o molti attributi. E’ indicato nell’ER con un piccolo cerchio. Occorre sempre distinguere tra attributo e valore dell’attributo. cognome Cliente

nome PIVA
acqui sta

Prodotto

11

Contesto e astrazione L’astrazione (cose di interesse) dipendono dal contesto; questo condiziona anche se un fenomeno è una entità o una relazione. Esempio: Contesto Direzione del Personale (HR): Un Impiegato contrae matrimonio (ad una data) con un Impiegato (es. relazione) Contesto Ufficio Anagrafe del Comune di appartenenza: Un Cittadino contrae Matrimonio (ad una data)

(es. entità)

Notare il diverso ruolo di matrimonio (prima di relazione, poi di entità) ed anche come la stessa entità abbia semantica diversa in contesti diversi (Impiegato, Cittadino)

12

Gerarchia is-a Una gerarchia is-a («è un») esplicita le specializzazioni di una entità. Può essere completa, quando ci sono tutte le specializzazioni possibili, altrimenti è incompleta.

Medico

Is-a

Pediatra

Chirurgo

13

Esempio Dipendente

cognome nome matricola salario

Is-a
qualifica Dirigente Impiegato effettua quantità straordinario

data In una gerarchia is-a la specializzazione eredita gli attributi della generalizzazione Altro es: Una Risorsa umana è un dipendente o un consulente
14

Semantica delle relazioni Entità deboli Una entità è debole se per definirla necessita di una relazione che la leghi ad un’altra entità. Si marca la relazione con una «E» accanto al rombo proprio ad indicare una relazione di esistenza e l’entità debole con due sbarre verticali (una a destra e una a sinistra) nel rettangolo. Es: Persona chiede Prestito (Prestito da solo non può esistere: debole)

Se per identificare l’entità debole è necessario anche di avvalersi di «attributi non propri» (cioè non dell’entità debole) allora la relazione si indica con «E&I», cioè è di Esistenza e Identificazione.
Es: Libro ha Copia.

Qui Copia non ha senso da sola, quindi ha è una relazione di E ma Copia per essere identificata ha bisogno anche di uno o più attributi di Libro cioè Titolo, Autore. Per cui la relazione è «E&I»
15

Molteplicità E’ il rapporto esistente tra le occorrenze di ogni entità che partecipa alle relazioni Sono tipicamente 1:1 1:N N:M Esempi

Un Capitano «comanda» una Nave (1:1)
Un armatore «possiede» N Navi (1:N) N Nave «fanno scalo» in M Porto (N:M)

16

Opzionalità Una relazione è opzionale nei confronti di una entità («può» e non «deve») se almeno una delle sue occorrenze può non partecipare alla relazione.

Questo vuol dire che una relazione rispetto ad una entità è: • Obbligatoria («deve») e indicata con un pallino nero sul rombo dal lato dell’entità • Opzionale («può») senza indicare nulla
Esempio Una Persona «abita in» Appartamento

«abita in» è opzionale nei confronti di Persona, perché non tutte le persone abitano in un appartamento, ma anche opzionale nei confronti di Appartamento, perché esistono appartamenti sfitti o vuoti.
Una entità può essere opzionale o obbligatoria anche rispetto ad una sola entità della relazione.
17

Un Calciatore «comanda» una Squadra «comanda» è obbligatoria nei confronti di Squadra, perché una Squadra va comandata da un tecnico; «comanda» è opzionale rispetto a Calciatore perché non tutti i calciatori sono anche i tecnici della squadra Esercizio A di Modello Concettuale. Realtà da rappresentare:

In un museo sono custodite delle opere d’arte di vari autori. Il museo è suddiviso in sezioni. Ogni opera fa parte di una sezione d’arte. Una sala ha varie sezioni. Per visitare ogni sezione si paga un biglietto dal bigliettaio. Ci sono vari custodi per ogni sala. Un biglietto fa accedere ad una sala con varie sezioni.
Modellare con ER l’esercizio A
18

Esercizio A - svolgimento

19

Modello Relazionale Nel seguito ci interessiamo solo del Modello Relazionale di maggiore utilizzo insieme a quello a Oggetti.

Il Modello Relazionale fu proposto da Codd e si basa sull’Algebra Relazionale, cioè su un modello matematico che permette di descrivere formalmente (da un punto di vista di rigore matematico) le entità e le relazioni tra esse.
I due concetti matematici fondamentali sono:

Entità=Insieme
Relazione=Sottoinsieme del prodotto cartesiano tra N insiemi, non necessariamente distinti e i cui domini possono essere solo di tipo semplice («rappresentazione piatta»). Le relazioni, quindi, non possono avere tipi aggregati o liste. Esempio Età è definita sul dominio degli interi
20

Definizione formale di Relazione Siano T gli insiemi D1, …,DT, non necessariamente distinti, R allora è una relazione sugli insiemi Di, se R è un insieme ordinato di tuple tale che:

(d1,…,dT)  al prodotto cartesiano D1 x D2 x … x DT Dove Dj è il dominio (j=1…T) T è il grado della relazione R.
D1 … DT

Una relazione è rappresentata con una tabella come in figura.

Ogni riga della tabella è una tupla o n-upla.
Ogni colonna della tabella è un dominio La tabella è NxT dove N è il numero di righe o di tuple e T è la cardinalità di R.
21

Dominio Il ruolo svolto da un dominio nell’ambito di una relazione si dice Attributo. L’attributo è il significato che gli elementi del dominio assumono nella relazione. Caratteristiche fondamentali delle relazioni Le caratteristiche fondamentali delle relazioni sono: • Atomicità dell’attributo • Indipendenza dall’ordine delle tuple nella relazione • Indipendenza dall’ordine delle colonne nella relazione

Chiave di una relazione
Chiave candidata è un attributo semplice o composto (più attributi), che individua univocamente una ricorrenza del fenomeno della realtà.

Tra le chiavi candidate si sceglierà metodicamente la chiave primaria (Primary Key)

22

Chiave esterna (Foreign Key)

Siano assegnate due Relazioni R1 e R2.
Un insieme di attributi x  R1 è chiave esterna (Fk) in R2 se e solo se x può assumere valori definiti per y  R2 e y è chiave primaria in R2.

Regole di integrità
Entity Integrity: Ogni attributo di una Pk deve sempre assumere valore noto (not null).

Referenzial Integrity: Se Fk è chiave esterna in R2 (quindi anche chiave primaria in R2) allora Fk in R1 può assumere come valori: • Quelli della Pk in R2 • Essere omessa, cioè non c’è legame della tupla tra R1 e R2
23

Vincoli o Constraint I Vincoli o Constraint sono delle regole che restringono i valori ammessi dal campo della entità o della relazione. I campi di una relazione possono essere soggetti a vincoli di vario tipo: • Il tipo con cui sono dichiarati • Primary Key • Foreign Key • UNIQUE (più righe non possono avere per quel campo lo stesso valore) • NOT NULL (il campo non può essere NULL richiede di essere valorizzato) • NULL (il campo può non essere valorizzato) • CHECK (il valore deve rispettare una condizione) • DEFAULT (il valore se non inserito assume un default)

24

Normalizzazione

Scopo: • Rendere le tabelle indipendenti dagli aggiornamenti • Rendere le basi dati indipendenti dagli applicativi • Ridurre la necessità di ristrutturazione del DB quando si introducono nuovi tipi di dati Per comprendere la «normalizzazione» occorre introdurre delle definizioni.
Attributi funzionalmente dipendenti Un attributo B  R è funzionalmente dipendente da A  R se ogni a  A ha non più di un valore associato in B e si indica con la scrittura: R.A -> R.B (si legge «funzionalmente dipendenti»)

25

Prima Forma Normale (PFN)

Sia W l’insieme totale degli attributi di R. Una relazione R è in PFN se per ogni chiave candidata k (uno o più attributi) della relazione R risulta che: 1.Il valore di k individua univocamente la tupla (R.k -> R.W) 2.Nessun attributo di k può essere eliminato senza violare la 1. Seconda Forma Normale (SFN) Una relazione R è in SFN se 1.R è in PFN 2.Ogni attributo di R non primario (non appartenente a chiave candidata) è pienamente dipendente da ogni chiave candidata. Assegnati due sottoinsiemi D,E degli attributi di R, si dice che E è pienamente o totalmente dipendente da D in R se E non è funzionalmente dipendente da D. La dipendenza totale va indicata col simbolo -/>.

26

Esempio Prendiamo Dipendente, Reparto, Divisione Ogni dipendente lavora in un solo reparto Ogni reparto appartiene ad una sola divisione

Quindi
R.Dipendente -> R.Reparto R.Reparto -> R.Divisione C’è l’implicazione R.Dipendente ->R.Divisione

Cioè
R.(Dipendente, Reparto) -> R.Divisione dipendenza immediata

27

Esempio Seconda Forma Normale

Sia assegnata una relazione R di grado T=3
R(Fornitore, Prodotto, Città) Si sa che: Un fornitore lavora in una sola città Un fornitore vende più prodotti Un prodotto è venduto da più fornitori Per esercizio: - Fare il modello ER concettuale (a carico del lettore) - Scrivere le dipende funzionali e non - Individuare la chiave primaria - Scrivere lo schema in SFN

28

R.Fornitore R.Fornitore R.Prodotto

-> -/> -/>

R.Città R.Prodotto R.Fornitore

La chiave è (Fornitore, Prodotto)

Ridurre R in SFN significa sostituirla con due sue proiezioni
R1 = Proiez(Forn, Prod) ( R ) R2 = Proiez(Forn, Città) ( R )

29

Terza Forma Normale (TFN)

Siano A,B,C gli attributi di R, inoltre sia: R.A -> R.B R.B -/> R.A R.B -> R.C Questo implica che: R.A -> R.C R.C -/> R.A Cioè C è transitivamente dipendente da A (pienamente dipendente) in R. Si dice che R è in TFN se: 1.R è in SFN 2.Ogni attributo non primario di R non è pienamente dipendente da ogni chiave candidata

30

Esempio Terza Forma Normale

Sia R una relazione di quarto grado R( Impiegato,CodiceLavoro,Direzione,Manager,TipoContratto)
• • • • Un Impiegato può svolgere una sola mansione/attività (CodiceLavoro) Ogni Impiegato svolge la sua attività presso un’unica Direzione Ogni Direzione ha un solo Manager Per le persone che lavorano presso una stessa direzione è previsto lo stesso tipo di contratto (TipoContratto)

Svolgere l’esercizio facendo: • Modello ER (a carico del lettore) • Dipendenze funzionali e Dipendenza piena (totale) • TFN

31

Svolgimento Esercizio precedente

R.Impiegato -> R.CodiceLavoro R.Impiegato -> R.Direzione R.Direzione -> R.Manager R.Direzione->R.TipoContratto implicazioni R.Impiegato -> R.Manager R.Impiegato -> R.TipoContratto
Per rendere R in TFN dobbiamo sostituirla con due sue proiezioni: R1 = Proiez ( Impeigato, CodiceLavoro, Direzione) ( R ) R2 = Proiez (Direzione, Manager, TipoContrato) ( R )

32

Regole standard per ottenere un DB normalizzato dallo schema concettuale

A.Creare una relazione (=tabella) per ogni entità: essa eredita tutti gli attributi semplici dell’entità
B.Creare una relazione per ogni attributo non semplice: i suoi attributi saranno gli attributi di tipo non semplice e la chiave primaria quella dell’entità di provenienza C.Creare una relazione per ogni associazione: avrà come attributi le chiave primarie dell’entità collegate dalla associazione e gli eventuali attributi definiti sulla associazione stessa. D.[opzionale] Se l’associazione è 1 a N si può porre la chiave esterna dalla parte dell’associazione univoca

33

Esempi di applicazione delle regole standard pk

Attributo non semplice
C1 1 M C indi rizz o C2 N 1

Attributo semplice

Esempio 1

X

Y

matr no me

te le fo ni via città

a 1

a 2

a Li 4 st a

34

Regola A X ( matr, nome) Y (a1, a2, a4) Regola B X1 ( matr, via, città) X2 ( matr, telefono) Y1 (a1, a3) Regola C C ( matr, a1, c1,c2)

35

pk

Attributo non semplice
C1 1 M C N 1

Attributo semplice

Esempio 2

A

B

a1

a2 a3

b 1

b 2

36

Regola A A ( a1, a2,a3) B ( b1, b2) Regola C C ( a1,b1, c1)

In realtà potremmo avere nel caso N a M anche A(a1,a2,a3,b1,b2,c1)

La scelta della soluzione dipende anche dalla performance che si vuole ottenere.

37

pk

Attributo non semplice
C1 1 1 C N 1

Attributo semplice

Esempio 2

A

B

a1

a2 a3

b 1

b 2

38

Regola A e D A ( a1, a2,a3, b1,c1) B ( b1, b2) Processo classico DAFNE Per ottenere la giusta soluzione nella modellazione del database si devono mettere insieme quattro viste, con rispettiva integrazione: • • • • • Analisi delle funzionalità richieste Analisi dei dati Disegno delle funzionalità Disegno dei dati Integrazione dati e funzionalità (in analisi e disegno)

39

Processo DAFNE

Analisi Funzioni

Analisi Dati

Disegno Funzioni

Disegno Dati

40

ANALISI DATI Input: • Requisiti • Interviste • Specifiche di processo • Specifiche di architettura • Specifiche funzionali Output: • Modello ER dei dati e Schema Concettuale • Specifica di ogni entità e sua lista di attributi • Specifica di ogni relazione tra entità e lista di attributi della relazione L’ANALISI DATI è iterativa: nella prima fase si individua lo schema concettuale in base all’analisi del sistema di alto livello; poi lo schema concettuale si affina grazie alle ulteriori specifiche che si aggiungono nel processo produttivo.

41

INTEGRAZIONE DATI-FUNZIONE Input: •Specifiche funzionali Output: •Matrice dati-funzioni; dove: 1. Le righe della matrice evidenziano le transazioni del sistema 2. Le colonne della matrice evidenziano e descrivono le entità e le relazioni 3. Le caselle di incrocio della matrice indicano il tipo di accesso all’entità o alla relazione (I=insert, R=read, U=update, D=Delete)

L’ANALISI DATI è iterativa: nella prima fase si individua lo schema concettuale in base all’analisi del sistema di alto livello; poi lo schema concettuale si affina grazie alle ulteriori specifiche che si aggiungono nel processo produttivo.

42

DISEGNO LOGICO Input: •Schema concettuale •Matrice Dati-Funzione •Specifiche funzionali

Output: •Schema logico 1. Descrizione in DDL delle tabelle 2. Descrizione delle chiavi (pk, fk, indici) 3. Descrizione dei vincoli di integrità dei campi e delle relazioni
Anche il Disegno Logico è iterativo

43

DISEGNO FISICO Input: •Schema Logico •Specifiche funzionali •Specifiche di dettaglio •Esigenze prestazionali •Esigenze di operatività di esercizio (svecchiamento dati, etc)

Output:
1. Descrizione in DDL di particolari indici, partizionamento, dimensionamenti di oggetti del DB e del DBMS (memoria, parametri di sistema, etc) 2. Creazione trigger, funzioni e procedure 3. Implementazione di store-procedure (PL-SQL, etc) che implementino delle funzionalità, sia ad utilizzo del sw del sistema, sia come job automatico del DBMS 4. Analisi delle query (EXPLAIN) e loro ottimizzazione 5. Tuning del database, dei volumi e delle transazioni Anche il Disegno Fisico è iterativo. . In queste fasi sono molto importanti strumenti di sviluppo e test (editor, test dei dati, di EXPLAIN etc …)

44

Tutto quello finora esaminato è il cosiddetto processo forward, cioè che nasce dall’analisi e ci permette di arrivare allo schema fisico. A supporto della metodologia è necessario avere strumenti di modellazione che consentino anche di produrre automaticamente le DDL in base al DBMS scelto (es: TOAD Data Modeler per Oracle o altri Open Source). Questo permette l’analista di concentrarsi sul modello e se, lo stesso modello viene passato al DBA (DataBase Administrator), quest’ultimo dettagliando il tutto è in grado a partire dal modello di prodursi le DDL. Spesso serve fare il processo di reverse di uno schema fisico presente in produzione, oppure il reverse a fine degli sviluppi per ridocumentare il tutto. Anche qui conviene avere strumenti che lo consentano (ad esempio Toad Data Modeler).

Sign up to vote on this title
UsefulNot useful