Appunti di Sistemi informativi

Formattazione del testo

X EXCEPTIONBEGINSELECT QTA-DISP, QTA-RIORD INTO Q1, Q2FROM MAGAZZINO WHERE COD-PROD = PROD;IF Q1 < QUANT THEN RAISE(X); RAISE è un'istruzione per sollevareUPDATE MAGAZZINO un'eccezione e far terminare il programmaSET QTA-DISP = QTA-DISP - QUANT con una condizione di errore.WHERE COD-PROD = PROD;IF Q1 - QUANT < Q2 THEN INSERT INTO RIORDINOVALUES(PROD, SYSDATE, Q2) SYSDATE è una variabile di sistema che contieneEND la data di quando viene eseguita la query.Esempio di invocazione:PRELIEVO(4,150) → PROD=4, QUANT=150 → Q1 = 170, Q2 = 50→ → 28REGOLE ATTIVE (TRIGGER): Moduli di programma che svolgono una specifica attività dimanipolazione dei dati.Non standard in SQL2 ma presenti nei principali sistemi relazionale.Sono simili alle procedure, ma l'invocazione è automatica.Seguono il paradigma ECA (EVENTO-CONDIZIONE-AZIONE):
• evento: modifica alla base di dati
• condizione: predicato
• azione: modifica

alla base di dati, segnalazione agli utenti

Quando accade l'evento, se la condizione è vera, allora si esegue l'azione.

Esempio: gestione automatica del riordino

1. evento: il trigger si metterà in preallarme ogni volta che l'utente andrà a modificare la colonna QDISP della tabella MAGAZZINO.
2. Condizione: la nuova quantità disponibile è inferiore alla (nuova) quantità di riordino.
3. Azione:
• Se la quantità disponibile è insufficiente: eccezione (annullando l'update).
• Emissione di un ordine

Trigger:

CREATE TRIGGER GESTIONE-RIORDINO
AFTER UPDATE OF QTA-DISP ON MAGAZZINO -- evento
WHEN (NEW.QTA-DISP < NEW.QTA-RIORD) -- condizione
FOR EACH ROW
BEGIN
    IF NEW.QTA-DISP < 0 THEN RAISE(X);
    INSERT INTO RIORDINO
    VALUES(NEW.COD-PROD, SYSDATE, NEW.QTA-DISP);
END;

Esecuzione dell'applicazione:

UPDATE MAGAZZINO
SET QTA-DISP = QTA-DISP - 150
WHERE ...

La forma normalizzata presenta ridondanze e si presta a comportamenti poco desiderabili (anomalie) durante gli aggiornamenti.

Le forme normali sono di solito definite sul modello relazionale, ma hanno senso anche in altri contesti, ad esempio nel modello E/R.

L'attività che permette di trasformare schemi non normalizzati in schemi che soddisfano una forma normale è detta normalizzazione.

La normalizzazione va utilizzata come tecnica di verifica dei risultati della progettazione di una base di dati (verifica a posteriori di uno schema già progettato). Non costituisce quindi una metodologia di progettazione.

Relazione non normalizzata (con anomalie):

• Lo stipendio di ciascun impiegato è ripetuto in tutte le tuple relative: ridondanza.
• Se lo stipendio di un impiegato varia, è necessario modificare il valore in diverse tuple: anomalia di aggiornamento.
• Se un impiegato interrompe la partecipazione a tutti i progetti, dobbiamo cancellarlo: anomalia di cancellazione.

anomaliadi cancellazione (perdo traccia dell'impiegato, è come se lo licenziassi).
• Un nuovo impiegato senza progetto non può essere inserito: anomalia di inserimento.
Analizziamo la relazione:
Ogni impiegato ha un solo stipendio (anche se partecipa a più progetti).
Ogni progetto ha un (solo) bilancio.
Ogni impiegato in ciascun progetto ha una sola funzione (anche se può avere funzioni diverse in progetti diversi).
Ma abbiamo usato un'unica relazione per rappresentare tutte queste informazioni eterogenee:
- gli impiegati con i relativi stipendi
- i progetti con i relativi bilanci
- le partecipazioni degli impiegati ai progetti con le relative funzioni
Per formalizzare i problemi visti si introduce un nuovo tipo di vincolo, la dipendenza funzionale.
Consideriamo:
- Un'istanza r di uno schema R(X)
- Due sottoinsiemi (non vuoti) di attributi Y e Z di X
Diciamo che in r vale la dipendenza funzionale (FD) Y → Z (Y determina funzionalmente Z) se:

• Impiegato → Stipendio
• Progetto → Bilancio
• Impiegato, Progetto → Funzione

• Impiegato, Progetto → ProgettoY
• Y → A è non banale se A non appartiene a Y.
• Y → Z è non banale se nessun attributo in Z appartiene a Y.

• Impiegato → Stipendio
• Progetto → Bilancio

• La terza FD ha sulla sinistra una chiave e non causa anomalie.
• Le prime due FD non hanno sulla sinistra una chiave e causano anomalie.

Attributi che non formano una chiave. Per evitare le anomalie viste si può introdurre la Seconda Forma Normale (2NF).

Seconda Forma Normale (2NF) → Uno schema R(X) è in seconda forma normale se e solo se ogni attributo non-primo (ovvero non appartenente a nessuna chiave) dipende completamente da ogni chiave (ovvero non dipende solamente/parzialmente da una parte di chiave).

Esiste in realtà anche una 1NF:

Prima Forma Normale (1NF) → Richiede semplicemente che tutti gli attributi dello schema abbiano domini "atomici" (ovvero non siano composti o multi-valore).

Ma per evitare anche altre anomalie è meglio ricorrere alla:

Forma Normale di Boyce-Codd (BCNF) → Uno schema R(X) è in forma normale di Boyce e Codd se e solo se, per ogni dipendenza funzionale (non banale) Y → Z definita su di esso, Y è una superchiave di R(X).

Si noti che, come al solito, i vincoli si riferiscono allo schema, in quanto dipendono dalla semantica degli attributi.

attributi. Un'istanza può pertanto soddisfare "per caso" il vincolo, ma ciò non garantisce che lo schema sia normalizzato. In altri termini, le FD non si "ricavano" dall'analisi dei dati, ma ragionando sugli attributi dello schema.

Normalizzazione in BCNF: Se uno schema non è in BCNF, la soluzione è "decomporlo" in sottoschemi, sulla base delle FD. Attenzione! La soluzione non è sempre così semplice, bisogna fare anche altre considerazioni. Una decomposizione è corretta quando, facendo il JOIN tra le relazioni, si riottiene la relazione di partenza (decomposizione senza perdita).

La decomposizione non deve assolutamente alterare il contenuto informativo del DB! Si introduce pertanto il seguente requisito: Decomposizione senza perdita (lossless) → Uno schema R(X) si decompone senza perdita negli schemi R1(X1) e R2(X2) se, per ogni istanza legale r su R(X), il join naturale delle proiezioni di r