Appunti Basi di Dati

UN PROGRAMMA SI DIVIDE IN DIVERSE FASI, PER ESSERE CREATO CORRETTAMENTE, TRA QUESTE TROVIAMO:

1. STUDIO DI FATTIBILITÀ

IN CUI SI VERIFICANO LE SITUAZIONI DI PARTENZA E DI ARRIVO, SI STUDIANO I DIVERSI MODI DI RISOLUZIONE, IMPLEMENTAZIONE DI UN CALCOLORE (UN BASE ALLE ESIGENZE)

2. RACCOLTA DEI REQUISITI

LO SPECIALISTA DEVE CAPIRE LE ESIGENZE INFORMATICHE DELL’UTENTE E TENERE TECNICHE FORMATO E INFORMAZIONI, TENERE CONTO DURANTE L’IMPLEMENTAZIONE

3. PROGETTAZIONE

QUESTA FASE SI SUBDIVIDE IN:

1. PROGETTAZIONE DI PROCEDURE, SUA STRUTTURA BASE. QUESTE PERÒ NON HANNO UN RESO CODICE IN PROGRAMMAZIONE (OVVERO PROGRAMMARE UNA ICON È POI L’ALTRA OPERA)

4. IMPLEMENTAZIONE

SI IMPLEMENTANO I PROGRAMMI E SI POPOLANO LE BASI DI DATI

5. TESTING

UNA VOLTA CREATE LE PROCEDURE E LE POPOLATE LE BASI DI DATI, CONTROLLO SE FUNZIONANDO O MENO, SE POSSO EFFETTUARNE DELLE MIGLIORIE

6. FASE OPERATIVA

FASE DI MANUTENZIONE, CIOÈ CAPRICARE (INTANTO CHE UN PROGRAMMA NON FUNZIONA) CON DETERMINATI DATI, O CHE CAMBIANO I REQUISITI, DOVENDO AGGIORNARE IL SOFTWARE

L’INSIEME DI QUESTE FASI VIENE SEGUITO IN MANIERA SEQUENZIALE. CIÒ IMPLICA CHE SE IN UN DETERMINATO LIVELLO RISCONTRI DEI PROBLEMI; QUESTI, POTREBBERO ANCHE DERIVARE DA ERRORI NEI LIVELLI SUPERIORI. TALE APPROCCIO SEQUENZIALE VIENE DEFINITO COME APPROCCIO A CASCATA.

ESISTE PERÒ UN PROBLEMA: TEMPI TRA STUDIO DI FATTIBILITÀ E L’OPERATIVITÀ POSSONO ESSERE MOLTO LUNGHI. DA CIÒ SI DEDUCE CHE TALE APPROCCIO È FREQUENTE UTILIZZABILE SU PROBLEMI PICCOLI.

MA COSA FARE SE HO DEI PROBLEMI PIÙ AMPI E COMPLESSI? UTILIZZO UNA PARTICOLARE TECNICA, LA PROTOTIPAZIONE! LA QUALE SI SERVE COME UN PASSAGGIO ALTERNATIVO ALLA IMPLEMENTAZIONE NELLO SCHEMA SOPRA.

TALE TECNICA APPAR PRESENTATA, UTILIZZA UN CICLO SULLA RACCOLTA DELLE INFORMAZIONI (O REQUISITI), OVVERO SI OTTIENE UNA REALIZZAZIONE DI UN PROTOTIPO COMPLETO, MA NON UTILIZZABILE (SPESSO VIRTUALE FRATTO).

TALE ESECUZIONE RIDUCE AL NICO I TEMPI DI UN PARLATO PRIMO.

Il corso di basi di dati si basa sulla progettazione (3^a fase) di database. Per questo motivo studiamo il livello 3 dello schema della pag. precedente, vedendo come esso si struttura.

1. Progettazione concettuale: si descrive sottoforma di schemi o di algoritmi la realtà che si vuol rappresentare. Tale progettazione ha in input l'analisi di requisiti, rilasciando in output gli "schemi concettuali".
2. Progettazione logica: si vengono a definire dei sistemi che gestiscono basi di dati basate su dei modelli. Ha in input il risultato della prog. concettuale, gli schemi concettuali, e ha come output gli "schemi logici".
3. Progettazione fisica: serve per scrivere e memorizzare i dati su disco. Ha in input gli schemi logici, risultato della prog. logica, e rilascia in output degli "schemi fisici".

Indipendenza Logica

• Consente di cambiare lo schema logico
• La gestione dello schema deve dipendere dal sistema e non dai programmi applicativi

Finiti questi lunghi elenchi, sorge spontanea una domanda: "come si possono risolvere questi ultimi problemi e necessità?" La risposta sta nella base di dati, ovvero in quei insiemi di dati, organizzati in archivi, non duplicati (ma condivisi), logicamente correlati, utilizzabili contemporaneamente da diversi utenti (concorrenza).

La base di dati, inoltre, si struttura in tre livelli, descritti nella architettura ANSI-SPARC (standard americano).

Livello esterno mapping esterno logico Livello concettuale mapping logico interno Livello interno

Schema concettuale Schema interno

In questo tipo di architettura l'utente accede solo al livello esterno: questo gli consente di visualizzare un sottoinsieme di dati che gli interessa, impedendogli la visualizzazione dei restanti. Lo schema concettuale, invece, contiene la descrizione complessiva, non solo dei dati, ma anche dei legami tra questi ultimi. Tali descrizioni vengono centralizzate nello "schema logico centralizzato" per concludere vediamo che l'ultimo livello, il "livello fisico (o interno)" è quello in cui sono fisicamente contenuti i dati e gli archivi, qui quindi è tutte le organizzazioni possibili dei dati

Il modello principale per i nostri studi, è il modello relazionale, in cui i DBMS si differenziano per le componenti, per le funzionalità e per i modelli con cui gestire la memorizzazione dei dati e delle strutture (con le relative operazioni) che usano.

Ricordiamo inoltre, per rinfrescare l'idea, che il modello relazionale elimina il livello ibrido e rappresenta tutto su livello logico.

Passiamo ora alla definizione di modello relazionale.

Dominio

Un dominio D è un insieme di valori atomici. Per atomico intendiamo un valore indivisibile.

Alcuni esempi possono essere:

• Città: Firenze, Matera, Sassari, Chieti, ...
• Regione: Puglia, Molise, Basilicata, ...
• Telefono: {insieme dei num. telefonici a 10 cifre validi in ITA}
• Codice#: {valore compreso tra 1 e 2000}
• Orario: {insieme di ore e minuti che scandiscono il giorno}

Il dominio del modello relazionale, è facile capirlo, è da intendere come tipo logico (infatti non è importante la tipologia del dato, quanto un campo di esistenza).

Informalmente stiamo affermando che, nel dominio, vale di più identificare un campo di esistenza e non un'ultrasì a dire:

• Città - CHAR (15)

Poiché in questo caso verrebbe accettato anche il valore

• Basilicata

quando, questa, non è una città (ottengo quindi dati privi di significato per un determinato campo).

Ciò però non toglie il fatto che ogni dominio considera anche il tipo di dato (o formato).

VINCOLI DI INTEGRITÀ

Tali vincoli sono delle regole le quali vengono definite a livello di schema, ovvero sono un vero e proprio passo della progettazione della base di dati (si noti che ogni istanza deve rispettare i vincoli imposti).

I vincoli di integrità possono essere di diversi tipi:

1. Sul dominio
2. Semantici
3. Chiavi
4. D'integrità dell'entità
5. D'integrità referenziale
6. Dipendenze funzionali
7. Dipendenze multivalore

Visualizzandoli più da vicino:

1. Vincoli sul dominioIl valore di ogni attributo A deve essere atomico nel dominio di A, dom(A).

2. Vincoli di integrità semanticiNon tutte le combinazioni del prodotto cartesiano dei termini hanno senso da un punto di vista semanticoPrendendo un esempioTreni (cod#, cittap, cittaa, orariop, orarioa)

Questo esempio chiarisce come, ad esempio, la combinazione del prodotto cartesiano Firenze - Firenze sia priva di senso, così come lo è 19,00 - 19,00 su un treno che viaggia da Chieti a Matera.

Formalmente abbiamo:

R₁      R₁(X₁)      FK ⊆ X₁

R₂      R₂(X₂)      PK ⊆ X₂

dom(A_i) = dom(B_i)

[Si noti che FK = Foreign Key (chiave esterna) mentre PK = Primary Key (chiave primaria)]

FK = { A₁, A₂, ..., A_n } ⊆ X₁

PK = { B₁, B₂, ..., B_n } ⊆ X₂

∀ t_A ∈ r₁

t₁[FK]   ⊈   hull

 ➙                      ] t₂[r₂ ]

 ➘                      t₁[FK] = t₂[PK]

Quindi, se t₁[FK] si trova nel caso 2 abbiamo che

t₁[A₁] = t₂[B₁]

t₁[A₂] = t₂[B₂]

...

t_i[A_n] = t₂[ ][ B_n]