Appunti di Sistemi informativi

Formattazione del testo

FROM MAGAZZINO WHERE COD-PROD = PROD;

IF Q1 < QUANT THEN RAISE(X);

RAISE è un'istruzione per sollevare un'eccezione e far terminare il programma con una condizione di errore.

UPDATE MAGAZZINO SET QTA-DISP = QTA-DISP - QUANT WHERE COD-PROD = PROD;

IF Q1 - QUANT < Q2 THEN INSERT INTO RIORDINO VALUES(PROD, SYSDATE, Q2)

SYSDATE è una variabile di sistema che contiene la data di quando viene eseguita la query.

Esempio di invocazione: PRELIEVO(4,150) → PROD=4, QUANT=150 → Q1 = 170, Q2 = 50

REGOLE ATTIVE (TRIGGER): Moduli di programma che svolgono una specifica attività di manipolazione dei dati. Non standard in SQL2 ma presenti nei principali sistemi relazionali. 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. NEW.Q-DISP < NEW.Q-RIORD
3. Azione:
   • Se la quantità disponibile è insufficiente: eccezione (annullando l'update).
   • Emissione di un ordine

Trigger:

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

Esecuzione dell'applicazione:

UPDATE MAGAZZINO
SET QTA-DISP = QTA-DISP - 150 31
WHERE COD-PROD = 4

Esecuzione del trigger:

Evento: UPDATE(QTA-DISP) ON

MAGAZZINO

Condizione: vera.

Azione: IF NEW.QTA-DISP < 0 THEN RAISE(X) nonscatta.

INSERT INTO RIORDINO VALUES (NEW.COD-PROD, SYSDATE, NEW.QTA-RIORD)

Procedure e trigger e conseguenze del loro uso:

Permettono la decomposizione modulare delle applicazioni.

Paradigma di invocazione: esplicita (procedure), implicita (trigger)

Aumento di: efficienza, controllo, riuso (dal punto di vista del software).

Aumenta la responsabilità dell'amministratore della base di dati (rispetto al programmatore applicativo).

Si sposta "conoscenza" dalle applicazioni allo schema della base di dati (indipendenza di conoscenza).

NORMALIZZAZIONE DI SCHEMI RELAZIONALI

forma normale

Una è una proprietà di uno schema relazionale che ne qualità garantisce la " ”, cioè l'assenza di determinati difetti.

Normalizzare uno schema significa garantirne alcuni aspetti di qualità.

Una relazione non normalizzata:

- presenta ridondanze; anomalie

- si presta a

Comportamenti poco desiderabili 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 (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 se:

per ogni coppia di tuple t1 e t2 di r con gli stessi valori su Y, t1 e t2 hanno

Introdurre la Seconda Forma Normale (2NF)

Seconda Forma Normale (2NF) → Uno schema R(X) è in seconda forma non-primonormale se e solo se ogni attributo (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: 33Forma 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.

Un’istanza può pertanto soddisfare “per caso”

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 decompose 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 su X1 e X2 è uguale a r stessa: (r)⋈(r) = r

Una decomposizione

Sede non è conservata. Se una FD non si preserva diventa più complicato capire quali sono le modifiche del DB che non violano la FD stessa.

In generale si devono prima eseguire query SQL di verifica. Esempio di query di verifica:

Bisogna verificare che il progetto (Marte) sia presso la stessa sede dell'impiegato (Neri). A tal fine bisogna trovare un impiegato che lavora al progetto Marte.

SELECT * -> vuoto (nessuna tupla)
FROM Impiegati I
WHERE I.Impiegato = 'Neri'
AND Sede IN (SELECT I1.Sede -> Roma
FROM Impiegati I, ImpProg IP
WHERE I1.Impiegato = IP.Impiegato
AND IP.Progetto = 'Marte')

Una decomposizione:

deve essere senza perdita, per garantire la ricostruzione delle informazioni originarie.
dovrebbe conservare le dipendenze, per semplificare il mantenimento dei vincoli di integrità originari.

Nel nostro esempio, questo suggerisce di inserire anche lo schema (ridondanza tollerata):

Va sempre eseguita una query, ma più semplice:

SELECT

FROM Impiegati I, Progetti P

WHERE I.Impiegato = 'Neri' AND P.Progetto = 'Marte' AND I.Sede = P.Sede

Una limitazione non superabile... In funzione del pattern di FD, può non essere possibile decomporre in BCNF e preservare le FD.

Progetto, Sede → Dirigente

Dirigente → Sede

35Progetto, Sede → Dirigente coinvolge tutti gli attributi e quindi nessuna decomposizione può preservare tale dipendenza!