Data Base Management System (1)



Scaricare 98.5 Kb.
12.12.2017
Dimensione del file98.5 Kb.

data base management system (1)

s i s t e m i i n f o r m a t i v i


Col termine Sistema Informativo (SI) suol intendersi un insieme organizzato di “risorse” umane (persone e relative competenze e professionalità), logiche (informazioni, procedure, norme organizzative, flussi informativi, sistemi di rappresentazione e di comunicazione) e materiali (strumenti automatici e manuali, hardware e software) orientato alla gestione delle informazioni (acquisizione - codifica - archiviazione - trattamento - distribuzione) ai fini di far conseguire nel miglior modo possibile i propri fini ad una organizzazione (azienda).

Il ruolo principale di un SI aziendale è quello di fornire informazioni, o meglio una base informativa, in modo completo, tempestivo e sicuro, alla persona nel luogo e nel momento in cui queste sono necessarie o utili, ciò ai fini del saper prendere decisioni ed amministrare la propria organizzazione secondo criteri di razionalità ed efficienza.

Tale base informativa, per essere completa ed efficace, deve poter riguardare ogni livello di una struttura aziendale, in modo da consentire il migliore svolgimento delle attività strategiche, tattiche ed operative sia in forma settoriale che integrata.

In prima istanza, si possono identificare 3 livelli decisionali (ai quali competono relative funzioni ed attività) di una struttura aziendale cui occorre fornire una base informativa: livello operativo, settoriale e direzionale.

La slide DBMS01 esemplifica una possibile struttura di SI aziendale, in relazione ai livelli decisionali ed alle funzioni operative suddette (potrebbe trattarsi di un’azienda manufatturiera di dimensioni medio-grandi).


  • Livello Operativo

A livello operativo le decisioni da prendere sono, in genere, più strettamente legate all’attività immediata ed ai piani a breve termine e, di norma, sono vincolate ad aree decisionali e di responsabilità ben definite (rapporti con clienti e fornitori, controllo giacenze, ecc.). A tale livello i flussi di dati sono piuttosto intensi e gestiti in modo preciso e tempestivo.

  • Livello Settoriale

Decisioni relative alle direzioni dei settori aziendali (attività di tipo tattico, pianificazione ed ottimizzazione delle risorse di settore), vincolate dagli obiettivi e dalle direttive provenienti dall’alta direzione. Necessita di una base informativa che presuppone un’organizzazione delle comunicazioni aziendali (integrazione delle procedure e centralizzazione degli archivi) almeno a livello settoriale. Il flusso dei dati sarà meno intenso e dettagliato che nel livello operativo, pur esigendo una certa tempestività.

  • Livello Direzionale

Decisioni globali circa le strategie aziendali (piani a lungo termine). Necessita di una base informativa completamente integrata, costituita da dati storici e consuntivi dell’azienda (dati di sintesi) nonchè di sofisticati strumenti di analisi e pianificazione (estrapolazione e correlazione dei dati, ricerca operativa, simulazione, ecc.).

In sintesi, il sistema informativo dovrà tendere a far conseguire ad una certa organizzazione i migliori risultati (soprattutto) in termini di:



  • Gestione delle attività operative e di servizio (operazioni tipiche di quella certa organizzazione);

  • Efficacia e rapidità nell'espletare le funzioni di governo (decisioni);

  • Efficacia e rapidità nella gestione e comunicazione delle informazioni;

  • Ottimizzazione generale delle risorse e del "throughput" aziendale.


sistemi informatici


Col termine Sistema Informatico si intende quella parte di un SI realizzato tramite strumenti automatici di gestione dell'informazione.

In particolare, qualora l'informazione venga rappresentata mediante dati digitali (secondo dati codici), si tende ad identificare il sistema informatico come sistema EDP (Electronic Data Processing).



In pratica, gli odierni sistemi informatici sono essenzialmente basati sull'elaboratore elettronico (digitale) e, contestualmente e a vari livelli, possono garantire vantaggi quali i seguenti:

  • Disponibilità dell'informazione in "real time", sia nel tempo (rapidità dei processi) che nello spazio (rapidità nelle comunicazioni, p.es. trasmissioni tra stazioni remote ad alta velocità, reti ad estensione geografica per trasmissioni dati, ecc.);

  • Disponibilità di fonti di informazioni estese ed approfondite (banche dati) nonchè integrate (dati - immagini - suoni);

  • Elaborazione delle informazioni pressochè istantanea (la velocità di un elaboratore si misura in MIPS - Milioni di Istruzioni Per Secondo) e loro rappresentazione nella forma desiderata (tabelle, grafici, animazioni, ipermedia, ecc.);

  • Archiviazione delle informazioni su supporti di registrazione permanente ad alta capacità e di dimensioni ridotte (dischi magnetici ed ottici, memorie a bolle magnetiche), in modo strutturato e/o multimediale;

  • Accessibilità delle informazioni da qualunque luogo ed in ogni istante (p.es. home computer + collegamento via onde);

  • Sviluppo delle comunicazioni (p.es. electronic mail);

  • Possibilità di simulare sistemi e di controllare processi (studi di fattibilità, analisi di previsione, office automation, progettazione, regolazione automatica, ecc.);

  • Migliore gestione delle risorse umane.


classificazione dei sistemi informativi


Le possibilità offerte dall’evoluzione delle tecnologie elettronico-informatiche hanno consentito la realizzazione di SI via via più complessi e sofisticati; in base a tali sviluppi si può dare una prima classificazione dei SI ripartendoli in categorie di base come di seguito.

  • Base Informativa Semplice

L’integrazione delle procedure e degli archivi di dati è pressochè inesistente o al massimo approcciata a livello di settore. In pratica, si hanno diversi file, i dati non hanno correlazioni e le applicazioni sono orientate al file, cioè si ha un rapporto quasi biunivoco tra applicazione e file (o modesto archivio) e non si può parlare di un effettivo SI.

  • SI Settoriali (o a componenti indipendenti)

L’integrazione delle procedure e degli archivi di dati è sviluppata (solo) a livello settoriale, il sistema di gestione e comunicazione intersettoriale delle informazioni non è integrato e deve prevedere appositi meccanismi di interfacciamento e sincronizzazione per ottenere un minimo livello di automazione. Si ha una non trascurabile ridondanza dei dati, con rischi di produrre incongruenze informative e procedurali.

  • SI Integrati (MIS - Management Information System)

L’integrazione è spinta a livello globale, in modo da far apparire l’azienda non come un sistema statico in cui il SI costituisce il flusso delle informazioni basato sugli eventi aziendali bensì come un sistema dinamico complesso in cui apposite funzioni di feedback possono agire sui dati (in relazione alle loro anomalie) introducendo automaticamente opportune azioni correttive sulla base di un eventuale modello gestionale.

  • SI ad Architettura Modulare

Costituiscono un ibrido tra SI settoriali e integrati (di non facile implementazione), allo scopo di raggiungere un buon compromesso tra vantaggi e svantaggi di tali SI. L’integrazione settoriale viene realizzata a livello logico-funzionale ma non sul piano fisico: opportune interfacce si occupano di garantire la comunicazione tra moduli (settori), rendendo trasparente il loro reale funzionamento e mantenendone l’indipendenza fisica. Suddividendo appropriatamente i moduli in sottomoduli indipendenti si possono realizzare SI Modulari a Struttura Gerarchica.


progettazione dei sistemi informativi


La necessità di disporre di SI complessi e di informazioni in modo completo e tempestivo ha determinato lo sviluppo o il perfezionamento di diverse metodologie di progettazione dei SI (sistemi informatici inclusi). Prima di entrare nel merito di tali metodologie (riconducibili a 2 filoni principali: basate sulle Procedure o sulla Modellazione dei Dati) diamo uno schema introduttivo circa la progettazione dei SI.

La slide DBMS02 illustra le principali fasi di progettazione di un SI.

Si noti l’importanza delle Astrazioni nella progettazione, astrazioni che (come si vedrà meglio nel seguito) consentono di scindere aspetti concettuali, logici e fisici di una certa realtà che si vuole rappresentare tramite informazioni organizzate e loro correlazioni, fornendo al tempo stesso validi metodi per dare a classi di utenti quelle rappresentazioni di tale realtà e quegli strumenti ad essi più congeniali ed utili ai fini utilizzativi.

Come si può vedere dalla figura, la progettazione di un SI consiste in un processo di tipo ciclico in cui le necessarie verifiche che intervengono nelle varie fasi (la verifica in fase implementativa è sottintesa) devono tendere all’ottimizzazione generale del SI, visto come un sistema dinamico in cui nuove esigenze richiedono una sempre maggiore e più spinta informatizzazione (le verifiche suddette saranno più intense soprattutto nelle prime fasi).

Questa dinamica deve poter essere adeguatamente gestita progettando il SI in modo aperto e flessibile, cioè tale che la sua crescita non implichi stravolgimenti della sua architettura e funzionalità (almeno in un tempo ragionevolmente lungo e soprattutto per quanto concerne il livello implementativo).

A puro titolo indicativo, diamo un sintetico elenco di alcune attività che riguardano le prime due fasi e alcune delucidazioni basilari sulla progettazione dei SI.



  • Esigenze di Automazione e Definizione dei Requisiti

  • Analisi del SI preesistente;

  • Analisi circa l’introduzione di un nuovo SI (condotta sia a livello tecnico che socio-economico);

  • Individuazione e classificazione dei dati e dei relativi vincoli (tipi, correlazioni, congruenza, privatezza, tasso di crescita, ecc.);

  • Individuazione e descrizione delle procedure da automatizzare e dei relativi vincoli (dati coinvolti, relazioni ingresso/uscita, modalità di impiego, interfacce di I/O, tempi di risposta, frequenza d’uso, flessibilità, sicurezza, ecc.);

  • Valutazioni inerenti il ciclo di vita del SI;

  • Produzione della documentazione ed individuazione delle risorse necessarie alla progettazione.

  • Progettazione Concettuale

è orientata alla ricerca di un Modello Astratto di SI, cioè di un modello che astrae da considerazioni di efficienza (non inerenti il modello stesso!) e di implementazione. Per descrivere tale modello (che essendo più vicino alla mentalità ed alle conoscenze dell’utente presuppone per l’appunto un alto livello di astrazione) in genere si utilizzano linguaggi di tipo informale (linguaggi di progetto, linguaggi concettuali o semantici), relazioni, schemi o diagrammi, organizzazioni di dati espresse in termini di insiemi e relazioni, documenti esprimenti vincoli sui dati e sulle procedure (congruità, riservatezza, sicurezza, norme o standard da seguire, vincoli inerenti i tempi di risposta dal punto di vista utente), risultati di analisi di natura economica e sociale e così via.

  • Progettazione Logica

Consiste nella conversione del progetto concettuale in progetto logico. Il progettista logico (sistemista o analista-programmatore) dovrà in definitiva produrre Software, tramite opportuni linguaggi formali, per creare procedure applicative, definire strutture di dati e relative correlazioni, progettare l’interfaccia utente e via dicendo. In questa fase le considerazioni di efficienza ed implementazione assumono, almeno al livello logico del software, rilevanza ed il grado di astrazione è meno alto (efficienza del software, portabilità dei programmi, ecc.). La progettazione logica dovrebbe astrarre, quanto più possibilmente, dalle risorse fisiche (indipendenza dei programmi dai dati effettivi e dai dispositivi, indipendenza delle strutture logiche dei dati dalle corrispondenti strutture fisiche che le implementano, ecc.).

  • Progettazione Fisica

Consiste nell’organizzazione fisica dei dati sui supporti di memorizzazione permanente, con annesse e connesse questioni correlate (tecniche di memorizzazione e struttura dei supporti, metodi di accesso, dimensioni e caratteristiche interne dei files, tipo di sistema operativo, ecc.). Questa fase di progettazione (implementazione) presuppone notevoli conoscenze del sistema hardware/software su cui si impianta il SI, gli strumenti implementativi sono normalmente a basso livello di astrazione ed il lavoro è tipicamente affidato ad esperti o agli addetti ai lavori.

Caratteristiche Generali dell'Informazione


Vedasi la dispensa SICUREZZA, ove si parla di:

  • Sicurezza nei CED

  • Sicurezza in Rete

  • Ergonomia

  • Diritto e Informatica

organizzazioni tradizionali dei dati: problematiche

La logica di base delle organizzazioni tradizionali dei dati può essere fondamentalmente riassunta nei seguenti punti:



  • i dati sono generalmente organizzati in file omogenei (blocchi/record/campi);

  • i file-dati sono organizzati in funzione dei programmi che li devono elaborare;

  • i programmi devono precisare i file, la loro organizzazione ed i dati da elaborare;

  • l’individuazione dei dati (ricerca) e la loro organizzazione logica (ordinamento) sono basate su dei campi chiave.

Questa impostazione tradizionale dei dati presenta una serie di svantaggi, che esaminiamo in rapida sintesi:

  • Molteplicità dei file: dovuta sia al fatto che procedure diverse possono richiedere tipi di record diversi, quindi nuovi file, sia al fatto che nuove procedure possono richiedere nuovi file specifici;

  • Ridondanza dei dati: dovuta alla molteplicità dei file;

  • Riorganizzazione dei dati al cambiare dei programmi: dovuta al fatto che l’organizzazione dei file-dati è orientata al programma;

  • Molteplicità degli aggiornamenti: dovuta alla ridondanza dei dati;

  • Fusione dei file: spesso necessaria quando l’elaborazione richiede in input molti file di unità periferiche diverse le quali non siano disponibili in configurazione macchina.

Le problematiche poste da tale impostazione pongono la necessità di escogitare soluzioni più efficienti che prevedano l’integrazione dei file e delle procedure, soluzioni che, come vedremo, sono ottenibili tramite i Data Base.

dati e modelli di dati



dati


Vedasi la dispensa DATI, ove sono esposti i seguenti argomenti basilari:

  • Informazione – Dato - Tipo di Dato

  • Dati Astratti e Concreti

  • Strutture Informative

modelli di dati

Come già visto, uno Schema o Modello di Dati consiste in una rappresentazione del significato intensionale dei dati, a prescindere dalle particolari istanziazioni di esso; un modello fornisce una descrizione degli oggetti reali da rappresentare attraverso i dati in termini di talune proprietà formali tramite le quali essi sono individuati.

Uno Modello di Dati identifica:


  • Le Categorie che individuano e suddividono i dati (classi di oggetti della realtà da rappresentare);

  • Gli Attributi di ciascuna categoria (proprietà interessanti tramite le quali si individuano e caratterizzano gli oggetti di una data classe);

  • Le Associazioni eventualmente definite tra categorie (relazioni tra classi di oggetti) e gli eventuali attibuti di ciascuna associazione (proprietà informative interessanti relative alle relazioni);

  • I Vincoli di Integrità cui sono soggetti i dati (restrizioni cui sono soggetti i dati). Tali vincoli possono essere:

Impliciti: in quanto imposti dalla categoria cui i dati appartengono;

Espliciti: in quanto imposti dall’esterno tramite esplicite dichiarazioni.

Diamo a questo punto una definizione più rigorosa di Modello di Dati.

Un Modello di Dati M è una coppia (R, O), M = (R, O), ove:


  • R è un insieme di Regole o Costrutti per generare schemi; R costituisce pertanto un meccanismo di astrazione per la modellazione della realtà, cioè la notazione per descrivere i dati. Tale meccanismo si può identificare in un Linguaggio di Descrizione dei Dati (DDL-Data Description Language);

  • O è un insieme di Operazioni definite sullo schema per la manipolazione dei dati; O si può identificare in un Linguaggio di Manipolazione dei Dati (DML-Data Manipolation Language).

È chiaro che al variare di M ed O si ottengono diversi modelli di dati. La scelta di un modello sarà dunque stabilita sulla base del tipo di SI che si intende realizzare e delle conoscenze dei progettisti.

Una semplice analogia coi linguaggi di programmazione:

Schema S Tipo di dato T

Istanza x di S Variabile x di tipo T

DDL Set Dichiaratori di Tipo

DML Set Istruzioni Manipolazione Variabili



Esempio
Modellare una realtà costituita di persone maggiorenni che frequentano club privati di Roma
Uno Schema potrebbe esemplificarsi nel modo seguente.

Categorie


PERSONA, CLUB

Attributi


PERSONA(Nome, DataNascita, Indirizzo, Telefono)

CLUB(Nome, NumeroSoci)



Relazioni


Potrebbe risultare utile stabilire le seguenti relazioni:

  • R1(PERSONA-CLUB) = ”è socio di” con attributi:

DataIscrizione, QuotaVersata

  • R2(CLUB-CLUB) = “è affiliato a” senza attributi

Vincoli di Integrità Impliciti


Sono vincoli del tipo:

  • Gli elementi di PERSONA devono essere maggiorenni

  • Gli elementi di CLUB devono avere sede a Roma

Vincoli di Integrità Espliciti


Potrebbero essere del tipo:

  • Gli elementi di PERSONA devono essere laureati

  • Gli elementi di PERSONA devono essere residenti nel Lazio

  • Gli elementi di CLUB devono avere almeno 100 soci.

Istanze


Una istanza di PERSONA potrebbe essere:

Bianchi Ivo, 12/11/1958, Via Piave 34 00150 Roma, 5699648
Rossi Dario, 10/08/1960, Via Verdi 84 00128 Roma, 6455688

Verdi Maria, 23/12/1964, Via Adige 70 00135 Rieti, 5977568

ecc.

(tutti laureati, quindi maggiorenni, residenti nel Lazio).

Una istanza di CLUB potrebbe essere:

Lyons, 380

Rotary, 250
Montevecchio, 120

ecc.

(tutti con sede a Roma ed almeno 100 soci).

Una istanza di R1 potrebbe essere data da un sottoinsieme del prodotto cartesiano PERSONA x CLUB (i cui elementi sono coppie) costituito da tutte le persone di PERSONA soci di uno specifico club di CLUB (il prodotto cartesiano PERSONA x CLUB senza restrizioni costituisce un’istanziazione completa).

A ciascuna di tali coppie competono le informazioni date dagli attributi DataIscrizione e QuotaVersata.

Una istanza di R2 potrebbe essere data da tutti i club di CLUB affiliati ad uno specifico club (cioè un s.i. del prodotto cartesiano CLUB x CLUB le cui coppie di elementi rappresentano club tali che il primo risulti affiliato al secondo).

Pagina intenzionalmente lasciata bianca.

Siccome uno degli scopi fondamentali dell’attività di modellazione dei dati in ambito EDP è quello di fornire alle varie classi di utenti quelle rappresentazioni più consone al loro modo di percepire la realtà, in tale ambito si possono distinguere (in analogia con le fasi di progettazione dei SI) 3 classi di modelli di dati, individuabili in relazione al livello di astrazione cui ci si pone rispetto alla macchina.



  • Modelli Concettuali

In tali modelli (detti anche semantici) si astrae completamente dalla macchina, costrutti ed operazioni (DDL e DML) sono ad alto livello di astrazione e riflettono la logica più naturale per l’uomo o più idonea nel contesto. Un modello concettuale particolarmente interessante (che vedremo nel seguito) è il Modello Entità-Relazione.

  • Modelli Logici

I modelli logici sono ad un livello di astrazione inferiore di quelli concettuali, essi devono infatti disporre di meccanismi di astrazione ed operatori che consentano sia una facile modellazione della realtà che la debita considerazione di fattori inerenti l’efficienza delle implementazioni. I linguaggi DDL e DML di tali modelli sono abbastanza vicini ai linguaggi di programmazione ad alto livello di quarta generazione (HLL - High Level Language) e rientrano nella classe dei linguaggi VHLL (Very HLL). I tradizionali e più importanti modelli logici (che vedremo nel seguito) sono i seguenti:

  • Modello Gerarchico;

  • Modello Reticolare;

  • Modello Relazionale.



  • Modelli Fisici

I modelli fisici sono modelli a basso livello di astrazione, in essi i meccanismi di astrazione e gli operatori sono molto più vicini alla logica della macchina ed all’organizzazione fisica delle informazioni che alla logica dell’uomo (assume rilevanza la considerazione di elementi quali: struttura delle memorie fisiche, interfacciamento col SO, tipi di files, indici, liste, puntatori, alberi, metodi d’accesso, ecc.). I linguaggi dei modelli fisici sono normalmente dei DDL abbastanza specializzati e/o specifici linguaggi, chiamati Linguaggi di Descrizione del Supporto di Memorizzazione (DMCL-Device Media Control Language) o pure DSL (Data Storage Language).

Sottoschemi

Una volta definito un modello di dati potrebbe essere utile, per questioni connesse con problematiche applicative, di efficienza o riservatezza, far percepire a determinate classi di utenti visioni diverse del modello.

Una visione diversa del modello non deve necessariamente essere limitativa, infatti si possono prevedere 2 situazioni non disgiunte:


  1. Il modello viene limitato in alcune parti ad un certo utente, definendo per esso opportuni vincoli sulla struttura dei dati (categorie, attributi, associazioni). p.es. si potrebbero “nascondere” all’utente alcuni attributi o alcune associazioni. Dal punto di vista estensionale ciò significa rendere “invisibili” parte delle effettive informazioni al suddetto utente in quanto rese inaccessibili.

  2. A partire dal modello, per un certo utente si costruiscono nuovi dati operando su quelli del modello (tramite le operazioni ammesse); in questo modo si compie un’astrazione sul modello e la visione che ne risulta all’utente può essere addirittura più astratta del modello stesso. Dal punto di vista estensionale ciò significa rendere “visibili” al sudddetto utente informazioni (risultati di elaborazioni) che nel modello non esistono (p.es. si potrebbe applicare la seguente formula: Età = DataNascita - DataAttuale sulla base del solo attributo DataNascita presente nel modello ed acquisendo DataAttuale dall’orologio di sistema o da input).

In base alle considerazioni precedenti si può introdurre una nuova definizione: si dice Sottoschema o Vista una parte dello schema dei dati o un’astrazione di parte dello schema.

I concetti di intensione ed estensione si applicano ai sottoschemi parimenti che negli schemi.



Esempio

Con riferimento all’esempio precedente, si può ottenere un Sottoschema limitando, p.es., gli attributi di PERSONA nel modo: PERSONA(Nome, Telefono). A livello estensionale l’istanza del Sottoschema sarebbe allora data dalla lista:



Bianchi Ivo, 5699648

Rossi Dario, 6455688
Verdi Maria, 5977568

ecc.

Si può ottenere altresì una Vista “più ampia” dello schema modificando in quest’ultimo i suddetti attributi nel modo: PERSONA(Nome, DataNascita, Indirizzo, Telefono, Età), ove l’attributo Età è derivato per calcolo da DataNascita (come già visto in precedenza). In maniera analoga si possono ottenere diverse Viste dello Schema, agendo sugli attributi oppure sulle relazioni o sui vincoli di integrità.

Si rifletta sulla varietà delle rappresentazioni (formali e istanziate) dei dati che si possono ottenere tramite i Sottoschemi.

data base e data base management system


Per rappresentare una certa realtà (ai fini della definizione del SI di una data organizzazione) occorre disporre di un insieme di dati opportunamente organizzati e correlati sui quali siano definite delle operazioni.

Tra i concetti che può avere in mente l’utente finale e i bit che ha in “mente” l’elaboratore vi sono molti livelli di astrazione; la visione dei dati (quindi della realtà che essi descrivono) è dunque diversa a seconda dell’ottica in cui essi vengono guardati (che va dal “punto di vista” della macchina a quello dell’utente finale).

Altrettanto si può dire circa le funzioni espletate da un elaboratore attraverso i programmi, potendosi riguardare le cose per livelli gerarchici di astrazione che vanno dalle complesse operazioni macchina alle semplici operazioni con cui l’utente finale riesce ad ottenere le funzionalità richieste.

Una Base di Dati o Data Base (DB) è qualcosa di molto più complesso di un insieme di file così come essi sono secondo le tradizionali organizzazioni, al punto da implicare la considerazione di un apposito meccanismo gestionale, cioè di un Sistema di Gestione di Basi di Dati o Data Base Management System (DBMS).

In base a quanto detto sopra, per dare una definizione di DB e di DBMS conviene pertanto fare una distinzione per livelli di astrazione, assumendo come livello “fisico” quel livello (di astrazione) che nel contesto database può utilmente ritenersi il più basso: il livello del file.

Possiamo individuare 3 livelli di astrazione, applicabili ai database sia in senso intensionale che estensionale.



Data Base Management System Data Base

- Livello Fisico (Interno) - DB Fisico

- Livello Logico - DB Logico (Schema)

- Livello Esterno (Concettuale) - Sottoschema

La slide DBMS03 dà un schema generale di un DBMS, pensato come costituito da 3 blocchi principali: sistema di gestione, sistema di comunicazione, utility.

Si noti che si è evidenziato il fatto che le modalità di comunicazione col sistema sono diverse a seconda che le richieste provengano dai programmi applicativi o dai terminali, locali o remoti.

La slide DBMS04 illustra i livelli di astrazione e l’architettura generale per DB e DBMS.

Livello Fisico

Un Database Fisico è un archivio integrato di dati strutturati e correlati organizzati secondo un dato schema fisico, un insieme di dati (files, indici, puntatori e altre strutture di memoria usate per accedere in modo efficiente ai dati), memorizzato in forma permanente su supporti di registrazione.

Lo Schema Fisico di un DB consiste nella descrizione delle caratteristiche dei dati (files) utilizzati per modellare la realtà (DB logico) in forma di strutture fisiche di dati.

Una Istanza Fisica di un DB è data dal suo contenuto attuale, cioè da uno stato della memoria ove esso è conservato.

Il DBMS Interno (si rammenti che si è assunto quale livello fisico quello del file) si occupa della gestione dei DB fisici, della trasformazione degli aspetti logici in aspetti implementativi e delle interazioni col SO (metodi d’accesso, strutture fisiche di dati, formato dei record, ecc.).

Per definire l’organizzazione fisica dei dati (implementazione della loro organizzazione logica) si dispone di appositi strumenti, quali i linguaggi DDL-Data Definition Language e DMCL-Data Media Control Language (come vedremo, esistono diverse soluzioni per fornire le funzionalità tipiche dei DDL e DMCL per i DB, tra cui quella di integrare i due linguaggi).

Tale delicata funzione di strutturazione fisica è di norma di competenza del DBA-Data Base Administrator, il quale può avvalersi di diversi strumenti per ammministrare il database (programmi per effettuare operazioni globali, per gestire la sicurezza logica e fisica dei dati, per ottimizzare il sistema, ecc.). In particolare, il DBA può avvalersi del Data Dictionary, un mini database che contiene tutte le informazioni concernenti il database, oppure delle DDT-Data Description Table, per espletare la sua importante funzione.

Livello Logico

Un Database Logico è uno schema logico (concettuale) della realtà che si vuole descrivere, così come deve essere rappresentata per soddisfare tutte le possibili applicazioni richieste da una data organizzazione, cioè un’astrazione del mondo reale che (riguardando quella data organizzazione) in definitiva riguarda l’utente.

Lo Schema Logico di un DB è una descrizione dei dati e delle loro correlazioni in accordo con un modello di dati.

Un Modello di Dati è un insieme di strutture logiche di dati (caratteristiche del modello stesso) e un insieme di operatori definiti su tali strutture.

Una Istanza Logica di un DB è data dal suo contenuto attuale, cioè da un insieme di dati.

Un DB logico deve poter essere considerato come un tutto unico, nel senso che tutti i dati relativi alla data organizzazione sono visti nel loro assieme, cioè come una globalità coerente (quella descritta dallo schema logico) ottenuta raggruppando le informazioni di tutti i file (logici) dell’organizzazione (integrazione del SI).

Per costruire uno schema logico ed ottenere i vantaggi del suddetto raggruppamento (p.es. centralizzazione dei dati, irridondanza delle informazioni) occorre che le varie componenti dell’organizzazione raggiungano un accordo su una struttura unificata, il procedimento con cui si raggiunge tale obiettivo si chiama Integrazione del Database.

Il DBMS Logico può essere visto come un’interfaccia tra le applicazioni e il livello fisico, tale da rendere trasparente quest’ultimo alle prime.

Il DBMS logico deve fornire all’utente (ed anche al DBA) la visione logica che esso ha del DB, cioè quell’insieme di meccanismi (linguaggi) per operare sul DB con semplicità e naturalezza (sarà compito del DBMS fisico trasformare poi le richieste logiche dell’utente in effettive operazioni sul DB fisico).

Per descrivere il DB logico in termini di modello di dati da implementare tramite uno schema fisico di dati generalmente si dispone di un apposito DDL-Data Definition Language. Tale delicata funzione di strutturazione logica è di norma di competenza del DBA.

Per consentire agli utenti di manipolare le informazioni contenute nel DB (operazioni locali: interrogazioni, inserimenti, cancellazioni, aggiornamenti) generalmente viene fornito un apposito DML-Data Manipolation Language (come vedremo, esistono diverse soluzioni per fornire le funzionalità tipiche dei DDL e DML per i DB).

Livello Esterno

Il Livello Esterno è un livello puramente concettuale che, astraendo a sua volta dal livello concettuale dato dal DB logico (per il quale il DB è visto come una globalità di dati), consente di definire visioni diverse dei dati, cioè apposite percezioni particolari di essi (per l’appunto chiamate Viste) per appositi utenti o classi di utenti.

In questo senso, si può parlare di Database Logico e Database Concettuale, identificandoli coi concetti di Schema e Sottoschema.

La definizione di sottoschemi è molto utile, in quanto consente di far vedere agli utenti solo ciò che è interessante ai fini delle loro applicazioni e per il quale sono autorizzati ad operare, limitando l’accesso solo a quella parte del DB e a quelle funzioni del DBMS utili allo scopo. Ciò a beneficio dell’efficienza del sistema e della riservatezza dei dati.

Si può pensare al DBMS Esterno come ad un’interfaccia tra i sottoschemi e lo schema (non necessariamente omogenei come modello), tale da far apparire il DB logico come una Vista congruente con lo schema.

I sottoschemi possono essere definiti dall’utente, tramite un apposito DDL Esterno (sarà compito del DBMS Logico trasformare poi le richieste esterne in termini di schema logico).

In pratica, è proprio attraverso i sottoschemi che gli utenti finali operano col DB tramite il DML.

La slide DBMS05 illustra lo schema funzionale generale di un DBMS.

La slide DBMS06 illustra e commenta lo schema funzionale di un DBMS secondo CODASYL (Conference On Data Systems Languages).

DBMS: tipologie e requisiti

Si può fare una classificazione dei DBMS sulla base di alcuni loro aspetti che possono ritenersi determinanti, va comunque tenuto conto che i sistemi sono in evoluzione e che non raramente essi sono di natura mista.

Facciamo dunque una classificazione rispetto agli aspetti che seguono.

Gestione


  • DBMS Operativi: sono gestiti dai programmi dell’utente, i quali si occupano di operare sul DB per reperire, aggiornare e manipolare i dati; sono da considerarsi sistemi di tipo passivo, in quanto attivati appunto dai programmi utente.

  • DBMS Esecutivi: sono autogestiti, cioè orientati all’utente e non al programma; essi consentono di effettuare il dialogo con gli utenti tramite semplici linguaggi di interrogazione.

Linguaggio

  • Host Language: per eseguire le operazioni sul DB i programmi applicativi utilizzano linguaggi di programmazione preesistenti (Cobol, PL/1, C, ecc.), eventualmente ampliati con apposite istruzioni speciali.

  • Self Contained Language: per eseguire le operazioni sul DB i programmi applicativi sono realizzati tramite linguaggi di programmazione propri del sistema, generalmente semplici e ad alto livello.

Dati

  • Strutturati: il DB prevede la memorizzazione dei dati secondo schemi (formati) predefiniti, basati sul tipo di organizzazione data da record e campi; gli accessi ai dati avvengono mediante i campi chiave o i nomi dei campi.

  • Non strutturati: il formato dei dati non è predefinito ma flessibile, le registrazioni sono identificate tramite le informazioni in esse contenute (parole-chiave) e/o tramite descrittori (memorizzati in un apposito dizionario o Thesaurus). In pratica, tali sistemi non sono orientati alle elaborazioni gestionali e costituiscono i sistemi di Information Retrieval.

Un DBMS è un insieme integrato di componenti (essenzialmente moduli software controllati da un modulo supervisore) che consentono una efficiente gestione di uno o più DB (come vedremo, esistono diverse soluzioni per fornire le funzionalità tipiche di un DBMS).

Osservando (nuovamente) che un DB non può essere considerato come una semplice raccolta di file, almeno perchè le relative informazioni sono da considerarsi integrate, spartite e correlate e nelle loro gestione è vincolante il fattore efficienza, vediamo quali sono i principali requisiti richiesti ad un moderno DBMS.



Requisiti di un DBMS

  • Device Independence

I programmi devono essere indipendenti dalle unità hardware;

  • Data Independence

I programmi applicativi devono essere indipendenti dalla struttura logica e fisica dei dati (indipendenza logica e fisica dei dati);

  • Funzionamento in Multiutenza (locale e remota)

Un DBMS deve consentire l’accesso ai dati a più programmi o terminali concorrenti (locali o remoti) e garantire bassi tempi di risposta;

  • Sicurezza dei Dati

Occorre garantire la sicurezza logica e fisica dei dati, proteggendoli da accessi non autorizzati, invalidazioni dolose o accidentali, aggiornamenti incongruenti, guasti e malfunzionamenti del sistema;

  • Non Ridondanza dei Dati

La ridondanza dei dati deve essere nulla, minima o controllata;

  • Rappresentabilità di relazioni comunque complesse tra dati

Tale requisito deve esser conseguito in modo che i tempi di risposta siano rispondenti alle esigenze reali;

  • Semplicità d’uso e potenza dei linguaggi di interrogazione.

Database Machine (cenno)

Una DB Machine è un sistema dotato di un’architettura hardware/software adatta a soddisfare i requisiti di efficienza richiesti da un DBMS. In pratica, tali sistemi si basano su dei processori specializzati per eseguire ad alta velocità le operazioni di interrogazione di un DB. Le DB Macchine riescono a concentrare efficientemente su di loro le operazioni da effettuare sul DB e sono connettibili ad uno o più sistemi host, esse si sono rivelate particolarmente vantaggiose soprattutto per i DB relazionali.



Database Distribuiti (cenno)

Un DB distribuito può essere concepito come una collezione di nodi o siti interconnessi (cioè una rete dal punto di vista hardware) ognuno dei quali rappresenta un elaboratore e le sue unità periferiche e su ciascuno dei quali può risiedere una parte del DB ed anche del DBMS. La dispersione del DB (ed eventualmente del DBMS, che sarà distribuito tramite repliche) sui nodi potrà essere più o meno spinta (anche a livello dei record di uno stesso file) o variamente organizzata (nodi direzionali, operativi, con dati duplicati o sintetizzati, ecc.) ma il DB deve poter essere visto come logicamente unitario.



Banca Dati (cenno)

Col termine Banca Dati (Data Bank) suol indicarsi un insieme (generalmente numeroso) di DB parziali (gestito da un apposito sistema di gestione).



Linguaggi per Database

DDL - Data Definition (o description) Language

Il DDL è un linguaggio per definire o modificare il DB a livello strutturale (quindi non usato per accedere o modificare i dati), funzione che tipicamente compete al DBA.

Con riferimento ad un modello di dati, organizzati secondo una determinata struttura logica, tramite il DDL vengono globalmente descritti i dati, le loro correlazioni e strutturazioni, memorizzando nella DDT la rappresentazione logica delle loro caratteristiche (schema).

I DDL sono in genere linguaggi di tipo non procedurale (consistenti in una notazione per descrivere tipi di entità e relazioni tra essi), disponibili secondo diverse soluzioni:



  • Self Contained Language: il DDL è un linguaggio a sé stante, di norma compreso nel DBMS (soluzione attualmente più ricorrente);

  • Host Language

  • Estensioni: il DDL consiste in una estensione di un linguaggio di programmazione preesistente (occorre fare un programma, p.es. in Cobol, ove si specificano apposite istruzioni, aggiunte al linguaggio base, orientate al DB);

  • Chiamate: le funzioni del DDL vengono richiamate dai programmi applicativi, scritti in un linguaggio di programmazione tradizionale (p.es. Cobol, PL/1, C), tramite un’apposita interfaccia predisposta nel programma (chiamate al DBMS tramite istruzioni di tipo CALL).

DDL esterno

Per la descrizione di Sottoschemi (che possono essere definiti dall’utente e conformarsi a modelli anche diversi dallo Schema, cui saranno comunque ricondotti dal DBMS) in genere si fornisce un DDL esterno, spesso simile al DDL utilizzato dal DBA per definire lo schema ma con un set di istruzioni opportunamente limitato.



DML - Data Manipolation Language

Il DML è un linguaggio per la manipolazione dei dati, cioè lo strumento che consente all’utente di effettuare operazioni sul DB; spesso si usa anche il termine SQL-Structured Query Language come sinonimo di DML

Le operazioni consentite dal DML non sono di tipo strutturale ma agiscono sui dati, cioè sono operazioni di tipo locale sui dati: interrogazione (query), inserimento (insert), cancellazione (delete) e aggiornamento (update).

Le operazioni di tipo globale, quali la riorganizzazione e ristrutturazione del DB, sono normalmente riservate ad DBA.

A seconda della natura dell’utente - Terminale o Programma - le modalità di comunicazione col sistema si differenziano, percui anche i DML sono diversi.

Terminale: il DML sarà un linguaggio di programmazione generalizzato, orientato all’utente finale, cioè a facilitare e rendere quasi conversazionale il colloquio uomo-macchina, semplice da usare anche per scrivere normali programmi di elaborazione (il vantaggio della semplicità è pagato in velocità, dovendosi tradurre in comandi esecutivi le potenti istruzioni del DML).

Programma: il DML deve essere attivato in qualche modo da un programma utente scritto in un tradizionale linguaggio di programmazione, tramite istruzioni DML aggiunte al linguaggio o chiamate al sistema (il vantaggio della velocità, quindi di tempi di risposta migliori, dovuto alla velocità di conversione delle istruzioni del programma in comandi esecutivi, si paga in costi di programmazione).

Allo scopo di ottimizzare il rapporto velocità/semplicità e in generale le operazione di manipolazione dei dati anche i DML sono disponibili secondo diverse soluzioni .



  • Self Contained Language: il DML è un linguaggio a sé stante, di norma compreso nel DBMS, del tipo dianzi visto per gli utenti-terminali. Tali linguaggi si basano essenzialmente su specifiche del tipo:

  • Codice definizione (file/record inerente la richiesta);

  • Codice condizione (correlazioni logiche o valori inerenti record/campi);

  • Codice operativo (tipo di richiesta, quale query, insert, ecc.).

  • Host Language

  • Estensioni: il DML è un’estensione di un linguaggio di programmazione (analogamente a quanto detto per i DDL);

  • Chiamate: le funzioni del DML vengono richiamate dai programmi (analogamente a quanto detto per i DDL).

I DML si diversificano inoltre anche in due categorie:

  • DML Procedurali (o navigazionali): si caratterizzano per il fatto di offrire operatori di accesso al DB basati sul concetto di indicatore di posizione, tramite il quale si può “navigare” su o manipolare record singoli.

  • DML Dichiarativi (non procedurali): possiedono operatori indipendenti dal concetto di posizione e tali da far apparire i dati come una globalità in cui, per individuare un dato, si specifica la condizione da soddisfare, a prescindere dai dettagli inerenti la sua individuazione.



DMCL - Data Media Control Language

Il DMCL (o DSL-Data Storage Language) è un linguaggio per la definizione dell’organizzazione fisica dei dati, quindi per definire la corrispondenza tra schema e strutture fisiche dei dati. Il DMCL è uno strumento tipicamente riservato al programmatore di sistema o al DBA, esso può essere un linguaggio a sé stante oppure previsto nell’ambito del DDL.



Problematiche di Integrazione DML/Host

Il problema di integrare le capacità di un linguaggio DML con le possibilità di un linguaggio host general purpose può essere affrontato secondo due approcci diversi, che tengano però conto dell’aspetto intrinsecamente dichiarativo dei linguaggi SQL.

Riservandoci di trattare l’argomento più avanti, giova anticipare che tali approcci possono essere uno di tipo “object oriented”, basato sull’uso di linguagggi OOP (quindi non espressamente dichiarativi), e l’altro di tipo “logic oriented”, basato sull’uso di linguaggi di tipo logico, cioè dichiarativi.

Come vedremo, ciò porterà a considerare i concetti di:



  • Base di Oggetti (Object Base);

  • Sistema di Gestione di un Database Orientato agli Oggetti

(OO-DBMS - Object Oriented-DBMS);

  • Sistema di Conoscenza (Knowledge System);

  • Sistema di Gestione di una Base di Conoscenza

(KBMS - Knowledge Base Management System).

prof. Felice Zampini Data Base Management System (1) /




Condividi con i tuoi amici:


©astratto.info 2019
invia messaggio

    Pagina principale