CORSO DI BASI DI DATI E CONOSCENZA –

GESTIONE DEI DATI E DELLA CONOSCENZA

PRIMO EMICORSO - BASI DI DATI

Roberto Basili

a.a. 2011/10

1

SCOPI DEL EMICORSO 1:

Introduzione ai concetti di base dei Sistemi di gestione delle Basi di Dati (DBMS). Uso dei DBMS per la progettazione di Basi di Dati

nella applicazioni del software

Organizzazione ed Modelli dei dati a livello logico e fisico

Prospettive nell'uso dei DBMS nelle moderne applicazioni: Three-Tier Architectures

applicazioni alla condivisione dei dati ed alla modellazione concettuale (XML)

2

EMICORSO 1: SCOPI

Introduzione ai concetti di base dei Sistemi di gestione delle Basi di Dati (DBMS). Uso dei DBMS per la progettazione di Basi di Dati

nella applicazioni del software

Organizzazione ed Modelli dei dati a livello logico e fisico

Prospettive nell'uso dei DBMS nelle moderne applicazioni del software: Three-Tier Architectures

Cenni alla condivisione dei dati ed alla modellazione concettuale

3

EMICORSO 1: REQUISITI

Il corso e’ diretto agli studenti del Corso di

Laurea in Ingegneria Informatica (2 emisemestri 10 CFU)

Laurea in Ingegneria Gestionale (1 emisemestre 6 CFU)

Laurea Ing. Internet – Telecomunicazioni (9 CFU)

Prerequisiti: elementi di programmazione in C, C++ o Java

elementi di sistemi operativi (corso Sistemi Operativi).

4

EMICORSO 1: ORGANIZZAZIONE

Una particolare attenzione verra' dedicata ad

aspetti pratici legati a

utilizzo di piattaforme DBMS software esistenti (es.

MySQL o Oracle)

integrazione tra applicazioni sw e DBMS

Esercitazioni dedicate

Ing. gestionale:

Esame con progetto alla fine del primo ciclo di lezioni

(fine primo emisemestre)

5

ORARI DEL CORSO

Martedì- 9:30-11:15 - aula A4 Nuovi Edifici

Mercoledì - 14:00-15:45 - aula B2 Nuovi Edifici

Venerdì - 9:30-11:15 – aula B2 Nuovi Edifici

Ricevimento: Mercoledì dopo la lezione

Sito Web:

http://www.uniroma2.it/didattica/GdC/

6

TESTI CONSIGLIATI

Testo di Riferimento Sistemi di Basi di Dati,

di Raghu Ramakrishnan e Johannes Gehrke, Edizione Italiana, McGraw Hill, 2004

Risorse e Dispense distribuite dal docente, es. Introduzione a MySQL, PL/SQL

Uso delle librerie di JDBC

Slides delle lezioni anche disponibil al sito degli autori: http://www.cs.wisc.edu/~dbbook/

7

MODALITÀ D’ESAME

1 Esonero alla fine di ogni emicorso

Test a risposte chiuse (TRC)

Emi1: Prova di Progettazione di un Db (PDb)

Emi2: 2/3 Domande Aperte (DA)

1 Prova Finale (e di Recupero)

TRC+PDb+DA

8

MODALITÀ ESAME (2)

9

Esonero Emi1

Test Finale/Rec Esonero Emi2

Verbalizzazione

esito positivo

esito positivo

NO

NO

SI’

SI’

esito positivo NO

SI’

MODALITÀ ESAME (3)

10

TRC+PDb

TRC+PDb+DA TRC+DA

Verbalizzazione

esito positivo

esito positivo

NO

NO

SI’

SI’

esito positivo NO

SI’

MODALITÀ ESAME (4) - GESTIONALE

11

Esonero Emi1

Progetto Test Finale

(TRC+PDb)

Verbalizzazione

esito positivo

esito positivo

SI

NO

NO

SI’

verifica NO

SI’

SCOPI DI UN DATABASE

Unificare e generalizzare l’accesso ai dati

Consentire un accesso semplificato e …

efficiente

Proteggere i dati

Integrità e Riservatezza (Sicurezza)

Tolleranza a malfunzionamenti/guasti

Supportare la concorrenza

Facilitare lo sviluppo dei programmi

“utente” 12

DBMS

Un Data Base Management System(DBMS) è un sofware per la gestione e la registrazione di dati

Vantaggi: Indipendenza ed accesso efficiente ai dati Riduzione del tempo di sviluppo Integrita’ e sicurezza dei dati Gestione degli accessi ai dati Accesso concorrente Gestione delle transazioni Crashe recovery

13

DATABASE VS. FILES

Es. “Anagrafica di una compagnia

multinazionale” - taglia > 10 Gb

diverse funzionalita’ => molteplicita’ di librerie

di accesso

uso concorrente

impossibilita’ di un indirizzamento diretto e

sequenziale

sicurezza

robustezza dell’accesso

14

APPLICAZIONI E DATABASE

• Diverse applicazioni usano porzioni diverse dei dati

L’astrazione sui dati e’ diversa ma “coerente”

L’accesso ai dati e’ dipendente dalla astrazione (modello logico)

vincolato dalla natura fisica della memorizzazione

e’ necessario svincolare la natura logica dei dati dalla loro rappresentazione in memoria, cioè dalle forme di memorizzazione

15

PROSPETTIVA STORICA

Integrated Data Store (C.Bachman) ‘60

Standardizzazione del Network Data Model

(CODASYL)

Information Management System (IBM)

hierarchical data model

Modello Relazionale (Codd) 1970

SQL Standard ’80

DBMS distribuiti ‘90

16

17

DATA MODEL

Schema Fisico: definisce i dettagli legati alla memorizzazione dei dati (file, indici e ecc).

Schema Logico/Concettuale:Definisce i dati in base alla loro natura concettuale. E’ basato su un Modello Logico di definizione dei dati (ad esempio Modello Relazionale)

Schema esterno:Rappresentazione, basata sul modello logico, dei dati che sono utili/necessari e legali per un gruppo di utenti. Sottoinsieme delle informazioni descritte nello schema concettuale (spesso detto view)

18

E’ necessario svincolare la natura logica dei dati

dalla rappresentazione in memoria,

o meglio dalle forme di memorizzazione

19

SCHEMA CONCETTUALE

Schema Esterno 1

SCHEMA FISICO

Livelli di Astrazione Schema

Esterno 2

Schema Esterno N …

SCHEMA FISICO

Definisce i dettagli legati alla

memorizzazione

Es.

liste per rappresentare insiemi

liste per rappresentare alberi

alberi per rappresentare insiemi con chiavi

Determina la struttura dei files dedicati a

contenere i diversi dati

Definisce forme utili al ritrovamento (es.

indici) 20

SCHEMA CONCETTUALE ( O LOGICO)

Definisce i dati relativamente alla loro

natura concettuale, cioe’ legata al mondo

della/e loro applicazione/i

Viene realizzato all’interno di un modello

logico di definizione dei dati (per es. quello

relazionale)

In generale, descrive tutte le entita’ e le

relazioni tra di loro che si rendono

necessarie per descrivere completamente i

dati in modo logico 21

SCHEMA ESTERNO

Descrive i dati che sono utili/necessari e legali

per gruppi di utenti

Utilizza il modello logico di descrizione dei dati

E’ rappresentato da un sottoinsieme delle

informazioni dello schema concettuale, spesso

detto “vista”

22

PROGETTAZIONE CONCETTUALE

Modellare un mondo in cui le applicazioni utente operano richiede un linguaggio di specifica

Tale linguaggio e’ detto MODELLO dei DATI (DM) e’ una astrazione di tutte le possibili

informazioni che mondi possibili richiedono

La applicazione di un MODELLO dei DATI al mondo W produce lo SCHEMA LOGICO del risultante DB (relativo a W)

23

PROGETTAZIONE CONCETTUALE (2)

24

W Data Model

Schema Logico

DBW

PROGETTAZIONE CONCETTUALE

Il modello dei dati richiede competenze e linguaggi gia’ propri dell’informatica ma …

la progettazione logica parte dalle descrizioni che gli utenti finali (non informatici) fanno del loro mondo operativo

=> e’ necessario un modello (ed un sottostante linguaggio) piu’ adatto a catturare la semantica del dominio applicativo, cioe’ un modello semantico (indipendente a sua volta dal modello dei dati)

Il modello semantico e’ poi mappabile in un modello logico tramite processi semplici e per i quali esistono prassi standard

25

PROGETTAZIONE CONCETTUALE(3)

26

W Semantic Model

Schema Logico

DBW

Schema Concettuale

Data Model

INDIPENDENZA DEI DATI

I livelli logici di progettazione supportano

la Indipendenza Logica dei Dati ...

Cambiamenti del mondo W si

rifletteranno solo come

estensioni/ridefinizioni dello schema logico

minimizzando i cambiamenti nelle

applicazioni utente (tramite adattamento

degli schemi esterni)

27

INDIPENDENZA DEI DATI (2)

... e l’Indipendenza Fisica dei Dati

Cambiamenti nella struttura fisica delle rappresentazioni (ad es. nuovi dispositivi di memorizzazione) potranno essere resi invisibili (cioè trasparenti) alle applicazioni utente, mantenendo invariato lo schema logico

28

LA MANIPOLAZIONE DEI DATI

Gli utenti di un database hanno in generale

necessita’ di:

INSERIMENTO

AGGIORNAMENTO

CANCELLAZIONE

INTERROGAZIONE

delle singole “parti” di informazione

29

LE TRANSAZIONI

La realizzazione delle operazioni di accesso ai dati da luogo ad una molteplicita’ di azioni piu’ elementari sui dati es.

verifica dell’esistenza di un dato x <

aggiornamento del dato x <

preparazione dell’ouput <

avviso di terminazione

La successione delle operazioni determinate da una (sola) manipolazione e’ detta transazione

30

TRANSAZIONI (2)

Diverse operazioni (pur identiche) determinano diverse transazioni

La esecuzione di una transazione non e’ completa se non alla fine della sequenza di (micro)operazioni richieste

Le transazioni possono essere concorrenti, cioe’ determinare operazioni legali ma in contrasto tra loro (es. prelievo Bancomat)

Il completamento deve essere assicurato per mantenere l’integrita’ dei dati

31

TRANSAZIONI

32

ATOMICITA’ - La transazione viene eseguita

completamente o non viene eseguita affatto

CONSISTENZA - Le transazioni debbono conservare

la consistenza dei dati nel database

ISOLAMENTO - L’effetto di una transazione eseguita in

ambiente concorrente deve essere lo stesso della medesima

transazione eseguita singolarmente

DURABILITA’ - L’effetto di una transazione in un

Database deve essere persistente anche in caso di

crash del sistema

Una Transazione è un raggruppamento di operazioni

che deve avere le seguenti proprieta’:

33

SQL Interface

Data Files

Index Files

Plan Executor

Operator Evaluator

Parser

Optimizer

Query Evaluation

Engine

Transaction Manager

Lock Manager

Applications Front-Ends

WEB Forms

Files and Access Method

Buffer Manager

Disk Space Manager

Recovery Manager

DBMS

UTENTI DI UN DATABASE

Programmatori del DBMS

Utenti (diretti) esperti e non esperti

Programmi applicativi

Amministratore progetto degli schemi fisici e logici

gestione della sicurezza e dei criteri di autorizzazione

Manutenzione e prevenzione dei mafunzionamenti

Customizzazione

35