Note su archivi e data base

Note su archivi e data base
Cesare Maioli - 2002
Ogni programma opera su dati che sono memorizzati su supporti fisici di vario tipo: nastri, floppy
disc, hard disc o dischi fissi, compact disc a sola lettura (cd-rom), compact disc riscrivibili.
I dati sono visti dai programmi come costituiti da campi (per esempio nome, facoltà, esami
sostenuti) , destinati a contenere singoli valori delle variabili, record, cioè insieme di campi correlati
per l’utilizzo che ne fa l’utente (per esempio il record studente) e file o archivi (per esempio il file
anagrafica studenti, il file iscrizioni) che sono una raccolta di record.
Dal punto di vista logico è importante definire la chiave come il campo che è utile per individuare i
singoli record e in base al quale i record sono organizzati e acceduti; quale tra i record sia la chiave
deriva dalle classi di dati e dagli utilizzi che il sistema informativo aziendale fa delle informazioni:
per esempio, in un’anagrafe fiscale il campo codice fiscale è la chiave che consente di individuare
record costituiti da numerosi altri campi, come in un file del sistema informativo ospedaliero, la
chiave è di solito rappresentata dal cognome e nome della persona ricoverata.
I file sono organizzati in maniera sequenziale o in maniera diretta (random) nel senso che l’ordine
con cui i record si susseguono sul supporto magnetico o ottico destinato a contenerli può essere di
contiguità o seguire criteri di successione legati ad algoritmi che associano la chiave dei singoli
record agli indirizzi fisici dei supporti.
L’accesso ai file può avvenire in modo sequenziale (per esempio la stampa delle bollette, una volta
al trimestre, da parte di aziende che forniscono servizi di base ai cittadini) o in modo random (per
esempio l’accesso ai dati di un conto corrente da parte di una procedura bancaria di sportello).
Le diverse modalità di organizzazione e accesso, avvengono tramite la consultazione di una
directory facente parte del file stesso che indica il posizionamento dei record all’interno del file e
che quindi regola l’associazione tra record “simbolici” cioè rappresentati nei programmi applicativi
e record fisici cioè la rappresentazione dei dati su supporti hardware.
Dal punto di vista applicativo, gestire archivi di dati significa svolgere una seri di azioni che
trattano di:
• definizione dei campi, loro caratteristiche di rappresentazione (per esempio i nomi sono
successioni di lettere dell’alfabeto che non supererà le 20, le date sono nella forma gg/mm/aa,
gli eventi sono rappresentati da codici di 5 caratteri e tre cifre)
• definizione dei record aggregando i campi, predisponendo le azioni possibili sul campo chiave
• definizione di procedure organizzative per la gestione e la modifica delle definizioni precedenti;
esse comprendono l’individuazione dei formati, delle frequenze temporali di intervento, del
controllo di qualità
• gestione di varie azioni sul file e i record come: inserimento di nuovi record (talora detta
‘creazione’), aggiornamento (update) di campi in record esistenti, eliminazione di record,
reperimento (retrieval) di campi in seguito a una richiesta (query), redazione di report, copia,
detta ‘salvataggio’, di un intero file su altro supporto fisico (backup) per prevenire eventuali
perdite o danni, ripristino (recovery) di un file da una copia opportunamente salvata
Per transazione si intende, operativamente, l’interazione tra utilizzatore e sistema software che sia
di senso compiuto per l’utilizzatore e che lasci il sistema in uno stato coerente con la sua
impostazione precedente. Una transazione è costituita tipicamente di alcune fasi come:
• introduzione dei dati di richiesta da parte dell’utilizzatore
• conferma che i dati sono stati o no recepiti
•
•
•
accesso (lettura/scrittura) dei dati nell’archivio
elaborazione dei dati per rispondere alla richiesta
uscita con cui il sistema comunica i dati all’utilizzatore
Concetti applicativi diffusi alla gestione di archivi di dati, che prescindono dalle tecnicalità, sono:
• le modalità di individuazione di record tramite chiave e indici
• la modalità di rappresentazione dei dati come, per esempio, tabelle, strutture, record
• le procedure di update di file, aggiunta e cancellazione di record
• le procedure di ordinamento (sort) dei record in base a campi diversi dalla chiave
• le procedure di gestione tecnica degli archivi come il backup/recovery, la protezione dei dati, la
sicurezza delle transazioni
• le modalità di interrogazione ai dati cioè i linguaggi di interrogazione
I linguaggi di interrogazione variano in uno spettro di difficoltà di utilizzo crescente; si va dalla
possibilità di effettuare le query in linguaggio naturale (al momento esistente per sotto insiemi di
settori applicativi per esempio in campo bancario e di sicurezza logistica) alla tradizionale modalità
di accesso tramite linguaggi di programmazione o loro insiemi specializzati per le query.
I più diffusi sono quelli della famiglia dei linguaggi basati su SQL (Structured Query Language), un
linguaggio commerciale di interrogazione strutturata con cui tipicamente si selezionano archivi e
campi da interrogare (per esempio campo anno-di-nascita nel file anagrafe-dipendenti) e si
specificano alcuni predicati (come data-di-nascita compresa tra il 1960 e 1965, laurea in
ingegneria) ottenendo rapporti che presentano i dati selezionati elaborati secondo criteri di varia
complessità (per esempio ordinamenti, aggregazioni e applicazione di formule).
Con la diffusione delle interfacce grafiche e dei browser di internet sempre più diffuse sono le
modalità di interrogazione definite QBO (query-by-example), basate cioè su moduli in cui sono
evidenziati alcuni campi tra cui scegliere e opzioni di elaborazione.
Storicamente sono stati sviluppati dagli anni 60 insiemi di programmi applicativi che forniscono
servizi all’utente dove ogni programma definisce e gestisce i suoi dati.
I limiti di questo approccio sono:
• la separazione e isolamento dei dati; gli utenti di un programma non hanno possibilità di
accedere a dati utili gestiti da altri programmi
• data dependance; la struttura dei file è definita nel codice del programma
• la duplicazione dei dati; gli stessi dati sono gestiti da programmi diversi.
• format diversi per lo stesso dato e talora incompatibili per via delle diverse piattaforme
tecnologiche utilizzate da programmi diversi
• spazio di memoria sprecato
• proliferazione dei programmi applicativi per rispondere a esigenze che si vanno manifestando
nel tempo, per esempio per effettuare query
E’ capitato così che in grosse aziende esistessero anche alcune decine di master file, archivi
centrali diversi solo per un campo, sorti in periodi diversi per rispondere a crescenti
esigenze di informazione.
La definizione dei dati era incorporata nei programmi applicativi piuttosto che essere
memorizzata separatamente e indipendentemente e non vie era alcun controllo sugli accessi
e la manipolazione di dati se non quella imposta dal programma applicativo.
La concezione organizzativa per cui dati e informazioni sono considerati una risorsa
aziendale al pari delle persone, delle finanze, della logistica, della immagine, dei prodotti,
dei clienti, dell’ambiente ha portato ad accentuare la necessità di definire meglio le
architetture logiche che legano i dati tenendo conto del loro ciclo di vita e valore.
Parimenti, come rilevato, a livello aziendale sono andate crescendo, per l’accesso agli
archivi di dati, le necessità di rapidità, aggregazione per più livelli aziendali, incrocio di dati
da archivi diversi, l’integrazione di funzioni per unità organizzative diverse, l’importanza di
proiezioni e previsioni a supporto delle decisioni.
Sono sorti allora (anni 70) i data base che sono sistemi di gestione di archivi integrati in cui
i dati sono mantenuti in modo non ridondante, che garantiscono l’integrità delle
informazioni e dove l’utente può attivare con un comando unico una transazione anche
complessa tra più archivi logici.
(dal libro di Sartor, 2002)
“La progettazione di basi di dati relazionali presuppone quindi la costruzione di un
modello concettuale di tipo entità-rapporti (entity-relationship)1.
Modello entità-rapporti: rappresentazione di un certo ambito della realtà mediante insieme
di entità e di loro rapporti.
Entità e rapporti sono caratterizzati da determinate informazioni, che ne costituiscono
gli attributi. Consideriamo un semplice esempio: si supponga di voler rappresentare le
informazioni riguardanti i corsi frequentati dagli studenti di una ipotetica università. Vi sono
tre tipi di entità rilevanti:
• i docenti,
• gli studenti,
• i corsi.
L’entità Docenti ha gli attributi Nome e Qualifica; Nome è la chiave di tale entità, cioè
l’attributo (o l’insieme di attributi) che identifica univocamente ogni istanza di tale entità
(ogni singolo docente). L’entità Corsi ha gli attributi Titolo e Orario, che indicano
rispettivamente la denominazione del corso (diritto privato I, diritto privato II, ecc.) e il
tempo delle relative lezioni. In questo caso la chiave è costituita dall'attributo Titolo.
L’entità Studenti ha gli attributi Nome e Matricola (che ne costituisce la chiave). Il rapporto
Insegna collega ciascun docente ai corsi da questo insegnati. Si tratta di una relazione da
uno a molti nel senso che ogni docente può insegnare più corsi, ma per ogni corso c’è un
solo docente. Il rapporto Frequenta collega ogni studente ai corsi seguiti. Si tratta di un
rapporto da molti a molti, nel senso che ogni studente può seguire più corsi e ogni corso
può essere seguito da più studenti.
Un modello entità-rapporti può essere trasferito facilmente in una base di dati
relazionale:
1 Preferiamo tradurre l’espressione inglese entity-relationship come entità-rapporto (anziché
entità-relazione) per evitare confusioni con la nozione di relazione come tabella, nozione che dà il
nome al modello dei database relazionali.
• ogni entità e ogni rapporto è rappresentato mediante una distinta tabella;
• ogni riga (record) della tabella rappresenta un’istanza dell’entità (ad esempio un
determinato docente);
• ogni colonna della tabella rappresenta i valori di un determinato attributo (ad esempio,
la seconda colonna della tabella docenti riporta i valori dell’attributo qualifica)
Per realizzare una base di dati relazionale è fondamentale la definizione di un buon
modello concettuale. Ciò significa che le entità e i rapporti definiti nel modello debbono
rispecchiare la struttura della realtà: non si debbono costruire entità artificiose che
conglobano informazioni relative a diversi oggetti. Ad esempio, avremmo potuto costruire
l’entità Corsi in modo che essa inglobasse le informazioni relative al docente del corso
stesso.
Ciò avrebbe però comportato due problemi:
• la ridondanza delle informazioni, poiché nel caso di docente che insegni più corsi, si
sarebbero dovuti riportare più volte i dati relativi a tale docente (uno volta per ogni corso
da insegnato dal docente);
• la conseguente moltiplicazione delle operazioni di modifica, poiché per registrare la
modifica di un’unica informazione relativa ad un docente (ad esempio la promozione di
Verdi da professore associato a professore ordinario), si sarebbe dovuti intervenire su
tutte le righe della tabella che riguardano quel docente.”
DBMS
Un DBMS (Data Base Management System) è un sistema software che consente all’utilizzatore di
definire, creare e mantenere il database e fornisce un accesso controllato ad esso.
Un database si presenta come:
• una raccolta condivisa di dati logicamente correlati (e di una loro descrizione) progettata per
rispondere alle esigenze informative di un’organizzazione
• un catalogo (data dictionary o metadata) fornisce la descrizione dei dati per consentire la
indipendenza dai programmi
• una organizzazione logica in cui i dati correlati comprendono entità, attributi e relazioni tra le
informazioni di un’organizzazione
Si definiscono strumenti software funzionali a questa nuova modalità di organizzare i dati; esistono
almeno due famiglie di linguaggi:
• DDL - Data Definition Language che permette la specifica di tipi di dati, strutture e vincoli tra
essi. Tutte tali specifiche sono memorizzate nel database stesso
• DML - Data Manipulation Language che fornisce funzionalità generali per effettuare le query ai
dati
L’accesso controllato al database comprende:
• un sistema di sicurezza che garantisca da intrusioni e alterazioni accidentali
• un sistema di integrità dei dati che assicuri l’attendibilità delle situazioni rappresentate, la
persistenza nel tempo
• un sistema per il controllo della concorrenza da parte di più transazioni contemporaneamente
che assicuri l’isolamento di ogni singola transazione durante la sua effettuazione
• un sistema di software di base che consenta efficienti procedure di gestione di errori durante le
transazioni e di ripristino del database
•
un catalogo accessibile all’utente, organizzato per livelli e con sofisticati legami tra dati,
procedure applicative, dispositivi fisici, autorizzazioni per fasce di utenti.
(dal libro di Sartor, 2002)
“Coerenza dei dati Il DBMS permette a diverse applicazioni di utilizzare gli stessi dati,
integrandoli ed eliminando la ridondanza L'eliminazione della ridondanza permette di
garantire una maggiore coerenza: se lo stesso fatto viene registrato una sola volta nella
base dei dati, non vi è il rischio che vi siano registrazioni discordanti (cosa che si verifica
se si ha ridondanza, ogni qual volta non si aggiornino tutte le registrazioni relative al dato
modificato). Tuttavia, non sempre è opportuno eliminare completamente le ridondanze,
poiché un certo grado di duplicazione dei dati può permettere di conseguire una maggiore
efficienza. Tale aumento di efficienza, specialmente nella ricerca di informazioni, può
compensare il lavoro necessario per mantenere la coerenza (controlli, contemporanei
aggiornamenti, ecc.), e la spesa richiesta dall’occupazione di un maggiore spazio di
memoria.
Integrità Il DBMS assicura che la base di dati sia integra, cioè contenga solo dati
corretti. Ovviamente il DMBS non può garantire la verità dei dati, ma può imporre la loro
coerenza rispetto ad un certo insieme di vincoli (vincoli di integrità). I1 controllo
centralizzato facilita la definizione di procedure di convalida da eseguire prima di effettuare
le operazione di memorizzazione. Per esempio, si può controllare che nelle date non
venga indicato, per il giorno, un numero superiore al 31 o che l’età di una persona non sia
superiore a 150 anni, ecc. Un altro aspetto dell'integrità è costituito dal coordinamento dei
programmi che vogliono modificare contemporaneamente la stessa parte della base dei
dati (uso concorrente).
Ripristino
Il DBMS comprende procedure automatiche per il ripristino della base
dei dati in caso di errori e malfunzionamenti imputabili all'hardware o al software. La
ricostruzione di uno stato anteriore della base di dati si rende possibile memorizzando
periodicamente una seconda copia completa della stessa (data base dump), effettuando
con frequenza una ricopiatura dello stato completo della macchina (checkpoint), e
registrando le transazioni avvenute nel sistema e le variazioni apportate ai dati
(transaction log).
Sicurezza. Avendo tutti i dati sotto il proprio controllo il DBMS può garantire che alla
base dei dati si acceda solo secondo certe modalità e procedure, e dopo aver ottenuto
idonee autorizzazioni (che possono essere diverse per diversi tipi di dati).”
Schema e sottoschema
Dal punto di vista logico un DBMS consente alle applicazioni software aziendali di avere viste
diverse sulla stessa base di dati; in altri termini ogni unità organizzativa avrà una visione efficace e
sensata dei dati (sottoschema delle schema complessivo) di sua competenza e “proprietà” che si
rifletterà sugli accessi agli archivi senza tuttavia che le informazioni siano fisicamente memorizzate
come il sottoschema intende; si ha cioè la data independence tra software applicativi e dati
memorizzati.
Schema e sottoschema consentono accessi in maniera “personalizzata” da parte di utenti diversi agli
stessi dati e le relazioni virtuali che esistono sono prodotte su richiesta in seguito a query.
Quando si parla di ambiente DBMS si intendono, di solito un insieme di componenti eterogenee che
concorrono a una efficiente gestione delle informazioni aziendali, come:
• hardware; esistono DBMS per grandi mainframe ma anche per personal computer dalle
prestazioni limitate
• software; il DBMS e i programmi applicativi che lo utilizzano sono spesso associati a
componenti del sistema operativo specifiche per l’accesso ai dati, a componenti software di
controllo delle telecomunicazioni
• dati; le informazioni dell’organizzazione viste con schema e sottoschema
• modalità organizzative; procedure, regole, metodologie, strumenti da applicare al progetto e
all’utilizzo dei database
• personale; specialisti nella progettazione del database; programmatori delle applicazioni, gestori
dei dati per i diversi settori e, funzione chiave, il data base administrator che funge da filtro tra
le rappresentazioni logiche e quelle fisiche; dal lato utenti l’adozione di un DBMS porta a
razionalizzazioni d’uso e a ridefinizioni dei ruoli di chi accede agli archivi
I vantaggi che derivano dall’adozione di un sistema database sono:
• Controllo della ridondanza
• Coerenza dei dati
• Più informazioni dagli stessi dati
• Condivisione di dati
• Miglioramento dell’integrità dei dati
• Miglioramento della sicurezza
• Rafforzamento degli standard
Punti critici si sono rilevati essere:
• la necessità di adottare un approccio più disciplinato alla gestione della risorsa dati e
informazioni per tutta l’azienda
• la maggiore complessità di una volontà di gestire unitariamente tutti i dati
• l’ampiezza e la mole di dati da affrontare unitariamente
• i costi del software e della conversione
Le architetture dei DBMS si sono evolute dagli anni 70 a oggi seguendo alcuni paradigmi affermati
sul mercato che hanno cercato di descrivere e rappresentare le modalità di relazione tra le
informazioni di un’azienda.
La chiave di lettura è l’alternativa tra metodi che si basano sulla potenza della struttura dati e
metodi che si basano sulla potenza del software. Infatti si è assistito dapprima alla definizione di
modalità che sfruttavano la potenza delle strutture dati intrinseche nelle relazioni tra i dati (per
esempio gerarchia, grafo, indice invertito tra entità informative) per poi vedere la nascita di
modalità che, sfruttando la maggiore potenza elaborativa dei computer, realizzano la integrazione
dei dati secondo le richieste dell’utente, al momento della richiesta partendo da tabelle
‘razionalmente’ predisposte.
Alla prima modalità appartengono gli approcci detti gerachici e reticolare, alla seconda l’approccio
relazionale.
Il metodo gerarchico richiede che le relazioni tra i dati (e le prevedibili query) siano modellate
utilizzando strutture dati come gli alberi (radice, nodi, rami, foglie) dove le entità sono messe in una
gerarchia padre-figlio tra loro ovvero fratello-fratello.
Esistono gerarchie specifiche per le entità informative dei vari settori aziendali e, facendo previsioni
sulle loro possibili correlazioni di interesse nelle query, si introducono strutture addizionali che
rendono possibile, per esempio, la rappresentazione di relazioni molti-a-molti (ogni studente segue
più corsi e ogni corso è seguito da più studenti) in strutture ad albero, che tipicamente
rappresentano relazioni uno-a-molti (gli studenti di un corso, i corsi seguiti da uno studente).
Il modello gerarchico è efficace quando le query sono stabili e prevedibili.
Il metodo reticolare richiede che le relazioni tra i dati siano preferibilmente quelle che ci sono in un
grafo; i percorsi di accesso strutturati sono gli stessi del modello gerarchico; qui in più sono
possibili percorsi ad accesso multiplo e vengono facilmente rappresentate le relazioni molti-a-molti;
tuttavia il collegamento tra entità informative diverse avviene tramite navigazione (una curiosità è
la informazione che il termine “navigazione” tra le informazioni nacque nei sistemi DBMS
reticolari negli anni 70) da un elemento all’altro e, se i cammini sono imprevisti, i tempi di risposta
aumentano e le prestazioni divengono inefficaci.
Il modello relazionale, nella sostanza, aggrega le entità informative in tempo reale al momento della
query senza presupporre la definizione di cammini preferenziali ma partendo da un insieme di
tabelle (dette “relazioni”) costituite da righe (i record) e colonne (i campi) che rappresentano le
entità informative aziendali e le relazioni tra esse. L ’aggregazione di righe di più di una di tali
tabelle, la selezione di alcune di esse e l’eliminazione delle colonne irrilevanti in base ai parametri
della query, consente di rispondere con la stessa prestazioni a richieste comunque articolate.
Si tratta dunque di un modello molto semplice basato su tabelle cui si accede tramite poche
operazioni (select, project, join) espresse in un linguaggio algebrico.
L’affermarsi dei DBMS relazionali deriva da un fattore tecnologico (la potenza degli elaboratori
che collegano durante la transazione archivi anche molto articolati) e da uno logico legato alla
modalità con cui si costruiscono tali tabelle.
Tale processo è detto normalizzazione delle relazioni: si osserva come la normalizzazione sia
necessaria anche là dove si adottino gli approcci gerarchici e reticolari; infatti una volta costruite le
tabelle normalizzate, esse divengono rispettivamente i nodi della gerarchia ad albero e i nodi della
rete.
Il processo di normalizzazione viene descritto facendo riferimento a un esempio. La tabelle
seguente illustra un frammento dell’archivio dati relativo agli ordini che sono ricevuti per i prodotti
che un’azienda vende.
I campi Num e Ord sono sottolineati in quanto sono considerati campi chiave: la cultura
organizzativa dell’azienda ha individuato in essi gli identificatori delle classi di dati che
rappresentano la sua attività. Termini come Prodotto e Ordine rappresentano le entità caratteristiche
e dal significato non ambiguo per le varie unità organizzative che operano nell’azienda.
Num
151
248
Desc
Tavoli
Sedie
Qta
70
120
Ord
61
38
90
Clt
234
340
201
Prio
B
D
C
Qord
25
40
20
…
…
61
50
…
…
234
340
…
B
D
…
15
30
…
Num - Numero identificativo del prodotto
Desc - Descrizione del prodotto
Qta - Quantità disponibile
Ord - Numero dell’ordine da parte di un cliente
Clt - Numero identificativo di un cliente
Prio - Priorità del cliente
Qord - Quantità ordinata
Un Ordine consta di Ord, CLT, Prio, Qord e
un Prodotto consta di Num, Desc, Qta, (uno o più) Ordine.
Si osserva che nella tabella tra i campi relativi al prodotto vi sono ordini che sono record ripetuti e
vi sono informazioni relative all’ordine che non sono in domini atomici (cioè costituiti da un solo
dato).
Il processo di normalizzazione comprende tre passaggi; il primo prevede di rendere ogni campo non
ulteriormente decomponibile e dipendente dalla chiave. Occorre pertanto rendere atomici tutti i
campi e far dipendere i campi dell’Ordine da una combinazione di chiavi costituite da Num e Ord
assieme.
La prima forma normale richiede che tutti i domini (attributi) contengano solo valori atomici.
La versione in Prima forma Normale è dunque:
Num
Desc
151
Tavoli
248
Sedie
Relazione: Prodotto
Qta
Ord
Num
151
61
151
38
248
90
248
61
248
50
Relazione: Ordine
Clt
234
340
201
234
340
70
120
Prio
B
D
C
B
D
Qord
25
40
20
15
30
Si osserva che questa rappresentazione dei dati presenta vari criticità per una gestione generalizzata
delle operazioni; esse sono:
• aggiornamento; il campo Prio di un cliente non può essere modificato a meno che esso non
abbia emesso un ordine (si arriva a Prio solo tramite Num + Ord)
• inserimento; i dati su un nuove cliente possono essere inserti solo se esso ha emesso un ordine
• eliminazione; eliminando un prodotto (per esempio 248), si eliminano tutti i dati relativi a un
cliente (per esempio 201)
Occorre quindi passare a una forma delle relazioni di utilizzo più generale.
Per dipendenza funzionale di un dominio D2 da un dominio D2 legati da una relazione R si intende
il fatto che ogni valore di D1 è associato a uno e a un solo valore di D2 in R.
La relazione tra D1 e D2 è una dipendenza funzionale se è del tipo uno-a-uno a molti-a-uno. Per
esempio Ord e Clt, Clt e Prio, Num e Desc, Num e Qta.
Un dominio può dipendere funzionalmente da un dominio composto (cioè più di un dominio
contemporaneamente) come Qord e la composizione di Num e Ord.
Per dipendenza funzionale completa si intende il fatto che D2 dipende funzionalmente da D1 e non
dipende funzionalmente da alcun altro sottoinsieme di D1.
Quindi la dipendenza funzionale di Qta da Num + Ord è completa, quella di Qta da Num + Desc
non lo è in quanto Qta dipende funzionalmente da Num + Desc ma anche solo da Num.
La seconda forma normale richiede che tutte le relazioni siano in prima forma normale e che tutti
gli attributi, cioè i domini non chiave, siano funzionalmente dipendenti da tutti i domini chiave,
che si abbia cioè una dipendenza funzionale completa.
Si arriva così alle seguenti tre tabelle:
Desc
Num
151
Tavoli
248
Sedie
Relazione: Prodotto
Qta
70
120
Ord
Qord
Num
151
61
25
151
38
40
248
90
20
248
61
15
248
50
30
Relazione: Prodotti che sono stati ordinati
Ord
Clt
Prio
61
234
B
38
340
D
90
201
C
61
234
B
50
340
D
Relazione: Ordini dei clienti
Si osserva che permangono alcune criticità legate al fatto che vi sono dipendenze transitive: nella
relazione Ordini dei clienti Prio dipende da Ord solamente in quanto dipende da Clt; questo porta
all’inconveniente che la modifica della Prio di un cliente richiede molti interventi sulle tabelle se si
tratta di un cliente che emette molti ordini.
Si effettua l’eliminazione delle dipendenze funzionali transitive per addivenire alla terza forma
normale in cui i domini non chiave, se esistono, dipendono funzionalmente dalla chiave e sono
mutuamente indipendenti.
Si hanno quindi le seguenti quattro relazioni:
Num
Desc
151
Tavoli
248
Sedie
Relazione: Prodotto
Qta
70
120
Num
Ord
Qord
151
61
25
151
38
40
248
90
20
248
61
15
248
50
30
Relazione: Prodotti che sono stati ordinati
Prio
Clt
234
B
340
D
201
C
234
B
340
D
Relazione: Clienti
Ord
Clt
61
234
38
340
90
201
61
234
50
340
Relazione: Ordini
La terza forma normale richiede che ogni riga della relazioni consista del valore di una chiave
primaria che identifica un’entità e di un insieme di attributi mutuamente indipendenti che la
descrivono.
Schema concettuale
Il processo di normalizzazione delle relazioni è volto a costruire uno schema logico delle
informazioni presenti in azienda; questo, come è emerso dalle considerazioni sulla scelta dei campi
chiave, è preceduto da un’attività di analisi del sistema informativo che porta allo schema
concettuale ed è seguito da attività per la descrizione della struttura fisica del database nelle
memorie dell’elaboratore che individua lo schema fisico.
Lo schema concettuale viene ottenuto tramite l’esame delle descrizioni delle attività e delle entità
effettuate in linguaggio naturale o risultante da sistemi software precedentemente acquisiti da
un’azienda e tramite un processo di astrazione, atto a isolare le caratteristiche rilevanti dei processi
aziendali e delle classi di dati porta a un modello del funzionamento dell’azienda.
I meccanismi di astrazione utilizzati sono:
• la classificazione; si raggruppano gli oggetti di interesse per l’azienda che hanno proprietà
comuni
• l’aggregazione; si definiscono nuove entità a partire da entità esistenti più dettagliatamente
rappresentate
• la generalizzazione; si definiscono relazioni di sottoinsiemi
Information Retrieval
I database spesso sono confusi con le banche dati o con altri termini il cui significato è quello di
rappresentare una raccolta di dati, spesso contenuta in più file correlati tra loro, utilizzabile da più
utenti tramiti programmi software applicativi e che sono comprensibili come descrizione astratta
agli utenti.
Banche dati sono anche le raccolte di documenti i cui record hanno campi non così strutturati come
in precedenza che contengono informazioni, anche multimediali, nel campo giornalistico,
comunicativo, legale.
In tali sistemi documentari il record non è strutturato in campi e contiene righe di testo oppure
paragrafi, sezioni, capitoli. Le sequenza di dati elementari che vengono memorizzate non ricavano il
significato dalla loro collocazione in una struttura predeterminata.
Si classificano quindi le banche dati in due grandi famiglie: i database e i sistemi di information
retrieval o documentari destinati alla consultazione e al reperimento di dati come avvenimenti,
comunicati, norme, voci di enciclopedie.
Nei sistemi documentari i record (detti anche unità documentarie) consistono di alcuni campi
identificativi e caratterizzanti il documento oltre al suo contenuto.
Le relazioni tra i campi dei contenuti sono limitate mentre quelle tra i campi identificativi
obbediscono alla logica dei DBMS.
Le query sono qui basate su elaborazioni linguistiche di norma full-text cioè sul testo integrale;
esistono anche elaborazioni e query semantiche che si basano su sistemi di thesaurus, livelli di
indici, raccolte di termini spesso sofisticate e adattive rispetto all’evoluzione delle terminologie (per
esempio nel settore giornalistico).
I sistemi documentari sono di fondamentale importanza nell’informatica giuridica di cui
rappresentano una delle realizzazioni informatiche più significative.
Avendo un testo contenuto in un archivio normativo, identificato da campi strutturati come tipo,
data, titolo e da un campo a lunghezza indefinita che contiene il testo, un sistema di information
retrieval accetta query contenenti tipicamente parole presenti nel testo congiunte da operatori logici
elementari (and, or, not) e fornisce l’elenco degli identificativi dei documenti in cui sono presenti
quei termini.