BASE DI DATI - unicas.itwebuser.unicas.it/fontanella/dida/LabInfo0708/Appunti/DB/... · 2010. 11....

Basi di DatiF. Tortorella Università degli Studi di Cassino

BASE DI DATI

(accezione generica)collezione di dati, utilizzati per rappresentare le informazioni di interesse per una o più applicazioni di una organizzazione.

(accezione specifica)

collezione di dati gestita da un DBMS


SISTEMA DI GESTIONE DI BASI DI DATI DATABASE MANAGEMENT SYSTEM - DBMS

Sistema informativo in grado di gestire collezioni di dati

che siano (anche):• grandi (di dimensioni (molto) maggiori della memoria centrale

dei sistemi di calcolo utilizzati)• persistenti (con un periodo di vita indipendente dalle singole

esecuzioni dei programmi che le utilizzano)• condivise (utilizzate da applicazioni diverse)

garantendo affidabilità (resistenza a malfunzionamenti hardware

e software) e privatezza (con una disciplina e un controllo degli

accessi).


Condivisione

• Una base di dati è una risorsa integrata, condivisa fra vari settori.

• L'integrazione e la condivisione permettono di ridurre la ridondanza(evitando ripetizioni) e, di conseguenza, le possibilità di incoerenza (o inconsistenza) fra i dati.

• Poiché la condivisione non è mai completa (o comunque non opportuna) i DBMS prevedono meccanismi di definizione della privatezza dei dati e di limitazioni all'accesso (autorizzazioni).

• La condivisione richiede un opportuno coordinamento degli accessi: controllo della concorrenza.


A B C D E

Applicazione 1 Applicazione 2 Applicazione 3

A B C D E

Archivi originali

Archivi modificati

DBMS vs. file system


Applicazione 1 Applicazione 2 Applicazione 3

A B C D E


DBMS



• La gestione di insiemi di dati grandi e persistenti è possibile anche attraverso sistemi più semplici - gli ordinari file system dei sistemi operativi, che permettono di realizzare anche rudimentali forme di condivisione.

• I DBMS estendono le funzionalità dei file system, fornendo più servizi ed in maniera integrata (maggiore efficacia).

• I file system prevedono forme di condivisione, permettendo accessi contemporanei in lettura ed esclusivi in scrittura: se è in corso un'operazione di scrittura su un file, altri utenti non possono accedere affatto al file. Nei DBMS, c’è maggiore flessibilità: si può accedere contemporaneamente a record diversi di uno stesso file o addirittura allo stesso record (in lettura).


DBMS vs. file system (2)

• Nei programmi tradizionali che accedono a file, ogni programma contiene una descrizione della struttura del file stesso, con i conseguenti rischi di incoerenza fra le descrizioni (ripetute in ciascun programma) e i file stessi.

• Nei DBMS, esiste una porzione della base di dati (il catalogo o dizionario) che contiene una descrizione centralizzata dei dati, che può essere utilizzata dai vari programmi.


• Esistono descrizioni e rappresentazioni dei dati a livelli diversi, che permettono l'indipendenza dei dati dalla rappresentazione fisica: i programmi fanno riferimento alla struttura a livello più alto, e le rappresentazioni sottostanti possono essere modificate senza necessità di modifica dei programmi.

• Precisiamo attraverso il concetto di modello dei dati.

Descrizioni dei dati nei DBMS


•Tradizionalmente, esistono tre modelli logici:– gerarchico– reticolare– relazionale

I modelli gerarchico e reticolare sono più vicini alle strutturefisiche di memorizzazione, mentre il modello relazionale è piùastratto:– nel modello relazionale si rappresentano solo valori —anche i riferimenti fra dati in strutture (relazioni) diverse sonorappresentati per mezzo dei valori stessi;– nei modelli gerarchico e reticolare si utilizzano riferimentiespliciti (puntatori) fra record.

• Più recentemente, è stato introdotto il modello a oggetti


Una relazione è costituita su un insieme di domini, non necessariamente distinti.

1983GiuseppeVerdi2910

1980AlfredoBianchi2176

1978LuigiRossi1528

Anno di nascita

NomeCognomeMatricolaRelazione

“Studente”

ennuple

attributi

grado

card

ina

lità

Il modello relazionale è basato su valori: i riferimenti fra dati in relazioni diverse sono rappresentati tramite valori dei domini presenti nelle ennuple.


Esempio


Chiave di una relazione

E’ un sottoinsieme K degli attributi che soddisfa le proprietà:

unicità

in qualunque istanza di R, non possono esistere due tuple

distinte la cui restrizione su K sia uguale

minimalità

non è possibile sottrarre a K un attributo senza violare la

condizione di unicità

In generale una relazione può avere più di una chiave


Nella definizione di un insieme di tabelle, sono riconoscibili delle relazioni esistenti tra attributi di tabelle diverse.

Queste possono essere di diverso tipo:

• uno a molti (1:N)

• uno a uno (1:1)

• molti a molti (N:N)

Relazioni tra attributi di tabelle diverse

reparto impiegati1 N

stato capitale1 1

studenti esamiN N


003GiuseppeGialli1571

015AldoNeri1803

021RobertoRossi2004

015GiuseppeVerdi2910

021AlfredoBianchi2176

015LuigiRossi1528

Cod. reparto

NomeCognomeMatricola

Distribuzione021

Produzione010

Marketing015

Contr. Qualità025

Forniture005

Progettazione003

FunzioneCodice

N 1

Chiave esterna

Per le chiavi esterne della relazione Impiegato sono ammissibili solo valori che appaiono come chiavi primarie nella relazione Reparto.

RepartoImpiegato


LisbonaPortogallo

RomaItalia

ParigiFrancia

CapitaleStato

3.1Barcellona

1.5Lisbona

3.0Milano

9.3Parigi

2.8Roma

0.5Lione

Milioni abitanti

Città

1 1


N

N


Esempi

1:N

1:1

N:N


Normalizzazione

• Non sempre la progettazione di una relazione porta ad una forma efficiente

• Ci possono essere anomalie che non sono sempre evidenti ad un primo esame, ma che pregiudicano il buon uso del database

• E’ quindi necessaria una fase di analisi che porti ad una forma della relazione che risolva tali problemi (normalizzazione)


il valore dello stipendio di ciascun impiegato è ripetuto in tutte le tuple in cui questo è presente => ridondanza

se lo stipendio di un impiegato varia, è necessario aggiornarlo in tutte le tuple => anomalia di aggiornamento

se un impiegato interrompe la partecipazione a tutti i progetti senza lasciare l’azienda, sarebbero cancellate tutte le tuple a lui relative, senza lasciare traccia dei suoi dati => anomalia di cancellazione

se si hanno informazioni su un nuovo impiegato, non potranno essere inserite finchè non lo si inserisce in un progetto => anomalia di inserimento

Problemi simili si hanno anche con la gestione dei progetti


Alcune considerazioni…

il numero di telefono dipenda unicamente dall’impiegato

lo stipendio di ogni impiegato dipende unicamente dalla funzione svolta

la descrizione di un progetto dipende unicamente dal nome del progetto

il dipartimento di appartenenza dipende dal solo impiegato

la funzione di un impiegato all’interno di un progetto dipende dall’impiegato e dal nome del progetto

Queste proprietà si definiscono dipendenze funzionali


Impiegato → Telefono

Funzione → Stipendio

Progetto → Descrizione progetto

Impiegato Progetto → Funzione

Impiegato Progetto → Telefono Stipendio Funzione Descrizione progetto

Dove si presentano le anomalie ?In corrispondenza delle relazioni che non dipendono dalla chiave

Quali sono le cause ?Inclusione di concetti eterogenei in un’unica relazione


Possibili soluzioni ?

Le anomalie sarebbero evitate se tutti i concetti fossero omogenei, cioè se tutte le dipendenze derivassero da una chiave. In questo caso la relazione sarebbe in forma normale

La relazione non è attualmente in forma normale perché ci sono delle dipendenze che non derivano dalla chiave

Soluzione: separare la relazione


Nell’esempio, la decomposizione è stata molto semplice: sono state le dipendenze a suggerire la decomposizione. Purtroppo non è sempre così facile.

Tutte le decomposizioni sono ammissibili?Solo quelle che permettono la completa ricostruzione delle informazioni originarie

BASE DI DATI - unicas.itwebuser.unicas.it/fontanella/dida/LabInfo0708/Appunti/DB/... · 2010. 11....

Documents

Transcript of BASE DI DATI - unicas.itwebuser.unicas.it/fontanella/dida/LabInfo0708/Appunti/DB/... · 2010. 11....