Progettazione concettuale

La progettazione concettuale è la prima fase che viene eseguita nella costruzione di una base di dati,e in essa si produce, uno schema concettuale che rappresenta la realtà di interesse.

Nel seguente capitolo illustreremo questo processo e i modelli dati che permettono di realizzare lo schema concettuale suddetto, in particolare, il modello entità-relazione che è al momento il più diffuso. Prima di ciò, però, vediamo la metodologia di progettazione.

La progettazione di una base dati costituisce solo una componente del processo di sviluppo,all’interno di una organizzazione, di un sistema informativo complesso e va quindi inquadrata in un contesto più ampio, quello del ciclo di vita dei sistemi informativi.

Come illustrato in figura 2.1, il ciclo di vita di un sistema informativo comprende, generalmente, le seguenti attività.

· Studio di fattibilità. Serve a definire, in maniera per quanto possibile precisa, i  costi delle varie alternative possibili e a stabilire le priorità di realizzazione delle varie componenti del sistema.

· Raccolta e analisi dei requisiti. Consiste nella individuazione e nello studio   delle proprietà e delle funzionalità che il sistema informativo dovrà avere. Questa fase richiede una interazione con gli utenti del sistema e produce una descrizione completa, ma generalmente informale, dei dati coinvolti (anche in termini di previsione sulla loro frequenza). Vengono inoltre stabiliti i requisiti software e hardware del sistema informativo.

· Progettazione. Si divide generalmente in progettazione dei dati e progettazione delle applicazioni. Nella prima si individua la struttura e l’organizzazione che i dati dovranno avere, nell’altra si definiscono le caratteristiche dei programmi applicativi. Le due attività sono complementari e possono procedere in parallelo o in cascata. Le descrizioni dei dati e dei programmi prodotte in questa fase sono formali e fanno riferimento a specifici modelli.

· Implementazione. Consiste nella realizzazione del sistema informativo secondo la struttura e le caratteristiche definite nella fase di progettazione. Viene costruita e popolata la base di dati e viene sviluppato il codice dei programmi.

· Validazione e collaudo. Serve a verificare il corretto funzionamento e la qualità del sistema informativo. La sperimentazione deve prevedere, per quanto possibile, tutte le condizioni operative.

· Funzionamento. In questa fase il sistema informativo diventa operativo e richiede, a meno di malfunzionamenti o revisioni delle funzionalità del sistema, solo operazioni di gestione e manutenzione.

Va detto che accanto alle attività citate, viene oggi spesso effettuata anche una attività detta di prototipizzazione, che consiste nell’uso di specifici strumenti software per la realizzazione rapida di una versione semplificata del sistema informativo, con la quale sperimentare le sue funzionalità. La verifica del prototipo può portare a una modifica dei requisiti e una eventuale revisione del progetto.

Poiché i dati hanno un ruolo centrale nei sistemi informativi si giustifica uno studio autonomo relativo alla progettazione delle basi di dati che si individua nella terza fase del ciclo di vita riportato in figura 2.1.

Nel corso degli anni, nell’ambito delle basi di dati, si è consolidata una metodologia di progetto articolate in tre fasi principali da effettuare in cascata. Essa si fonda su un principio molto semplice ma efficace: quello di separare in maniera netta le decisioni relative a "cosa" rappresentare in una base dati (prima fase), da quelle relative a "come" farlo (fasi successive).

Ogni fase si riferisce a un livello di astrazione nella rappresentazione dei dati e delle relazioni tra essi, e ha lo scopo di separare le attività di risoluzione dei problemi e di garantire la possibilità di modificare delle soluzioni adottate ai livelli inferiori senza dover riprogettare quanto definito nei livelli superiori.

A ciascuna fase di progettazione corrispondono diversi modelli per la rappresentazione dei dati, ovvero tecniche per la rappresentazione degli aspetti rilevanti della realtà da modellare, definite da strumenti e vincoli specifici. La rappresentazione generata seguendo le regole del modello viene definita schema (vedi fig. 2.2).

Le fasi riconosciute fondamentali nella progettazione di un database sono le seguenti: progetto concettuale, progetto logico e progetto fisico (vedi figura 2.3).

Obiettivo della fase di progettazione concettuale è la rappresentazione completa (formale) della realtà di interesse (informale) ai fini informativi, in maniera indipendente da qualsiasi specifico DBMS e quindi senza tenere conto degli aspetti implementativi. Tale rappresentazione, detta schema concettuale (che fa riferimento a un modello concettuale dei dati), è la rappresentazione più astratta, ovvero più vicina alla logica umana, nella definizione di dati e relazioni.

I modelli dei dati usati nella progettazione concettuale vengono definiti modelli semantici. Nel corso degli anni sono stati definiti diversi modelli dei dati ad iniziare da quelli reticolari e gerarchici seguiti da quello entità-relazione e infine quelli orientati agli oggetti e alla logica.

2.2.1.1 Livello vista

Una vista, sottoschema, o subschema, è una parte del database concettuale o un’astrazione di parte del database concettuale. In un certo senso, la costruzione delle viste è l’inverso del processo di integrazione di un database: per ogni collezione dei dati che hanno contribuito alla costruzione del database concettuale globale, possiamo costruire una vista che contenga proprio quei dati. Le viste sono importanti anche per far valere la sicurezza in un sistema di database, permettendo solo agli utenti che ne hanno l’autorizzazione di osservare i sottoinsiemi dei dati.

Spesso una vista è proprio come un piccolo database concettuale ed ha lo stesso livello di astrazione. Però, in un certo senso, una vista può essere "più astratta" di un data base concettuale, in quanto i dati in essa coinvolti possono essere costruiti a partire dal database concettuale, senza però essere effettivamente presenti in quel database.

Quando si progetta un database si è interessati al suo schema, quando invece si usa si è interessati ai dati effettivamente presenti in esso. Si noti che i dati nel database cambiano frequentemente, mentre gli schemi rimangono gli stessi per lungo tempo.

Il contenuto corrente del database si chiama istanza del database (o estensione del database o stato del database).

Come visto, il termine schema è usato nelle varie fasi della progettazione di un database, così avremo schema concettuale per riferirsi al livello di progettazione concettuale del database, schema logico per il progetto logico, schema fisico per il progetto fisico e semplicemente sottoschema per il livello delle viste.

La fase di progettazione logica del database ha lo scopo di tradurre lo schema concettuale espresso mediante un modello semantico in una rappresentazione mediate un modello logico dei dati. La rappresentazione che si ottiene viene definita schema logico del database.

A differenza dello schema concettuale, lo schema logico dipende strettamente dal tipo di DBMS utilizzato e in particolare del suo modello logico dei dati. Un modello logico dei dati è quindi la tecnica di organizzazione e di accesso ai dati utilizzata da specifiche categorie di DBMS. In particolare, in riferimento al modello logico dei dati su cui si basano, vengono distinti DBMS gerarchici, reticolari, relazionali, ad oggetti e basati sulla logica.

Un ulteriore compito della progettazione logica è quello di dichiarare le viste, tramite il DDL o gli specifici linguaggi di definizione dei dati del sottoschema. Successivamente per presentare interrogazioni ed operazioni su tali viste, può essere previsto un linguaggio di manipolazione del sottoschema altrimenti viene usato il DML generico.

Nel progetto fisico viene stabilito come le strutture a livello logico debbano essere organizzate negli archivi e nelle strutture del file system: esso dipende quindi non solo dal tipo di DBMS utilizzato, ma anche dal sistema operativo e in ultima istanza dalla piattaforma hardware del sistema che ospita il DBMS.

E’ pertanto il livello di progettazione in cui si può far uso del minor livello di astrazione, dovendo rispettare i vincoli tecnici imposti dal sistema ospite.

2.2.4 Indipendenza dei dati

La catena di astrazione della figura 2.3, dal database concettuale, a quello logico e a quello fisico, fornisce due livelli di "indipendenza dei dati". E’ ovvio che in un database ben progettato, lo schema fisico possa essere modificato senza alterare quello logico e senza richiedere una ridefinizione dei sottoschemi. Questa indipendenza è nota come indipendenza fisica dei dati. Ciò implica che le modifiche all’organizzazione del database fisico possono alterare l’efficienza dei programmi applicativi, ma non sarà mai chiesto di riscrivere tali programmi solo perché lo schema fisico ha modificato l’implementazione dello schema logico.

Anche la relazione tra vista e il database concettuale, fornisce un tipo di indipendenza chiamata indipendenza logica dei dati. L’uso del database può rendere necessario modificare lo schema concettuale, per esempio aggiungendo informazioni su diversi tipi di entità o altre informazioni su entità già esistenti. Lo schema concettuale può subire molte modifiche, senza coinvolgere i sottoschemi esistenti, mentre altri tipi di variazione allo schema concettuale possono essere fatte solo ridefinendo la corrispondenza tra sottoschema e schema concettuale. Ancora una volta non sono necessari variazioni ai programmi applicativi. L’unico tipo di variazione dello schema concettuale che non si riflette in una semplice ridefinizione della corrispondenza col sottoschema, si verifica quando vengono cancellate alcune informazioni del sottoschema. Naturalmente tali variazioni richiederanno la riscrittura o l’eliminazione di alcuni programmi applicativi.

Lo scopo del modello Entity-Relationship (Entità-Relazione E-R) è quello di permettere la descrizione dello schema concettuale di una situazione reale senza preoccuparsi dell’efficienza o della progettazione del database fisico, che ci si aspetta invece nella maggior parte dei modelli fisici. Di solito si pensa che lo schema entità-relazione così costruito sia poi tradotto in uno schema logico di un modello logico dei dati, ad esempio quello relazionale, che al momento è il più diffuso.

Il modello entità-relazione, prevede come prima attività della progettazione concettuale, la individuazione delle entità.

Una entità è qualcosa che esiste ed è distinguibile: possiamo cioè riconoscere un’entità tra le altre.

Ad esempio ogni persona è un’entità, così come ogni automobile.

Un gruppo composto da entità tutte "simili" forma un set di entità. Esempi di set di possono essere:

                   1) tutte le persone

                   2) tutte le persone coi capelli rossi

                   3) tutte le automobili

Negli esempi 1) e 2), osserviamo persone e persone coi capelli rossi: il termine "entità simili" non è definito in modo preciso e si possono stabilire infinite proprietà diverse con cui definire set di entità.

Nella progettazione del modello concettuale di un database, la scelta dei set di entità, è una operazione fondamentale così come è importante individuare tutte le proprietà caratteristiche di un set di entità che vengono descritte mediante gli attributi. Dalla "somiglianza", quindi, nasce la necessità dell’individuazione di un insieme di caratteristiche comuni a tutti gli elementi del set di entità.

Il set di entità è un concetto a livello di schema, mentre il corrispondente concetto a livello di istanza è il relativo sottoinsieme corrente di tutti gli elementi del dato set di entità nel database.

Ad esempio il Pubblico Registro Automobilistico può progettare il suo schema di database avente il set di entità Automobili. L’istanza corrente di questo set di entità riguarderà tutte le automobili immatricolate sino ad ora in Italia, ma non tutte le automobili del mondo o tutte le automobili mai esistite.

Lo schema entità-relazione ha una rappresentazione grafica che permette di avere immediatamente la visione globale dello schema concettuale del database. La rappresentazione grafica che si ottiene, a volte, invece di schema, viene chiamata diagramma entità-relazione (Entity-Relationship Diagram – ERD). In questa rappresentazione grafica si usa una convenzione per rappresentare i vari oggetti. I set di entità vengono rappresentate con dei rettangoli con il nome del set di entità all’interno.

Come già detto, i set di entità possiedono delle proprietà, chiamate attributi, le quali associano ad ogni entità del set un valore appartenente al dominio dei possibili valori per quell’attributo. Di solito il dominio sarà un insieme di interi, numeri reali, stringhe di caratteri, valori booleani ma anche immagini, audio e video come nei più recenti database multimediali.

La scelta degli attributi caratteristici per i set di entità è un punto abbastanza critico nell’ideare lo schema concettuale di un database. Tra tutti gli attributi di un particolare set di entità ne va scelto uno o un insieme, i cui valori identificano in modo univoco ogni entità del set. Questo attributo o insieme di attributi è chiamato chiave per quel dato set. In linea di principio ogni set di entità possiede una chiave soddisfacendo la richiesta che ogni entità sia distinguibile da ogni altra. Ma se per un set di entità scegliamo un insieme di attributi tra i quali non si possa individuare una chiave, non saremo in grado di distinguere una entità dall’altra. Però è possibile fornire un codice identificativo arbitrario da usare come chiave.

La rappresentazione grafica degli attributi è un’ellisse con il nome dell’attributo scritto all’interno e si collega con il rispettivo set di entità con dei segmenti (non orientati). Agli attributi che fanno parte della chiave per il rispettivo set, viene aggiunta una sottolineatura al nome. Nel caso speciale di set di entità con un singolo attributo, a volte si identifica il set con l’attributo stesso, chiamando il set col il nome dell’attributo. In tal caso, invece che con un rettangolo, il set di entità è rappresentato con un’ellisse collegata a qualunque relazione con cui sia coinvolto il set di entità.

Le dipendenze o associazioni di interesse informativo tra i dati da rappresentare vengono espresse nel modello entity-relationship mediante relazioni tra le corrispondenti entità. Le relazioni dello stesso tipo compongono l’insieme di relazioni (relation set) tra i due insiemi di entità. Per ottenere un modello adeguato del mondo reale, spesso è necessario classificare le relazioni a seconda del numero di entità associabili tra un set di entità e l’altro.

La relazione più semplice, e più rara, fra le relazioni che collegano due set è quella uno-a-uno, cioè che ogni entità di un set è legata con al più un elemento dell’altro set.

Le relazioni vengono rappresentate graficamente con dei rombi e vengono collegati ai propri set di entità con dei segmenti orientati o non a seconda del tipo di relazione. Nel caso di relazione uno-a-uno il segmento è orientato in entrambi i versi. Un’alternativa all’utilizzo dei segmenti orientati è quella di mettere sui segmenti che collegano la relazione ai set dei numeri che indicano la cardinalità della relazione.

Un esempio di relazione 1:1 è la relazione tra nazioni e capitali. Ogni nazione ha un’unica capitale, ad una capitale corrisponde un’unica nazione (fig. 2.4).

Due set E1 ed E2 sono in relazione uno-a-molti da E1 ad E2 se una entità nel set E1 è associata con zero o più entità nel set E2, ma ogni entità in E2 è associata con al più una entità in E1.

Un esempio di relazione 1:N è la relazione tra madri e figli. Una madre può avere più figli, mentre ad un figlio corrisponde un’unica madre (fig. 2.5).

La rappresentazione grafica della relazione 1:N è un rombo con segmenti che uniscono i set di entità coinvolti e orientati soltanto nella direzione del set di entità con cardinalità uno.

Due set E1 ed E2 sono in relazione molti-a-molti se ad ogni elemento di E1 possono corrispondere più elementi di E2 e viceversa.

Sulle relazioni molti-a-molti è da notare il fatto che non esistono efficienti strutture dati per la loro implementazione, spesso è richiesto di scomporre tali relazioni con varie relazioni molti-a-uno.

Un esempio di relazione N:M è la relazione tra corsi e studenti. Un corso è seguito da più studenti, e lo stesso studente segue più corsi.

Un altro esempio di relazione N:M è quella tra libri e autori. Un libro può essere scritto da più autori, un autore può aver scritto più libri (fig. 2.6).

La rappresentazione grafica della relazione N:M è un rombo con segmenti non orientati che uniscono i set di entità coinvolti.

2.3.8 Gerarchia ISA

Un tipo particolare di relazione è quella chiamata ISA o sottotipo/supertipo. Diciamo che A ISA B, cioè "A è un B" (A è il sottotipo e B è il supertipo), se il set di entità B è una generalizzazione di entità del set A, o in modo equivalente se A è un tipo particolare di B. Lo scopo principale per dichiarare le relazioni ISA tra i set di entità A e B è che in tal modo A eredita gli attributi di B, ma avrà anche attributi che non avrebbero necessariamente significato per gli elementi di B che non siano anche elementi di A.

La rappresentazione grafica della gerarchia ISA è un rombo con etichetta ISA con segmenti orientati nella direzione del set supertipo.

Un esempio di relazione ISA è quello di una società che può avere un set di entità Dipendenti con attributi Matricola, Nome e Stipendio. Se la società fosse una squadra di calcio, alcuni dei dipendenti, i Giocatori, avrebbero altri importanti attributi come Ruolo (portiere, difensore, attaccante), che non riguarderebbero gli altri dipendenti. Il modo migliore per progettare questo schema, è quello di avere un altro set di entità, Giocatori, legato con la relazione ISA al set Dipendenti. Gli attributi (anche le chiavi) che appartengono a Dipendenti (Matricola, Nome, Stipendio), verrebbero ereditati da Giocatori, ma solo Giocatori avrebbe un attributo come Ruolo (fig. 2.7).

Il modello entità-relazione prevede che anche gli insiemi delle relazioni abbiano degli attributi che ne specificano le caratteristiche. Tali attributi vengono rappresentati graficamente con una ellisse, cioè come per gli attributi di un set di entità, con un segmento orientato nel verso che va dal rombo all’ellisse (fig. 2.8).

Adesso viene proposto un esempio di schema concettuale che sarà usato anche nel successivo capitolo per vedere come uno schema concettuale si traduce in uno schema logico.

L’esempio che si introduce è quello del database Mobili Componibili, che fa parte del sistema informativo di un mobilificio e che rappresenta la seguente situazione:

· gli articoli, di cui interessa archiviare la descrizione, il prezzo, l’aliquota IVA e le spese di trasporto, sono suddivisi in categorie:

· ciascun articolo è costituito da una serie di componenti, di cui vengono archiviati la descrizione e il costo;

· i componenti vengono prodotti da singoli laboratori; di ogni laboratorio viene memorizzato l’indirizzo, la città e il telefono;

· gli articoli possono comparire negli ordini; di ogni ordine viene archiviata la data;

· infine gli ordini sono effettuati dai negozi di cui viene archiviato il nome, l’indirizzo, la città, e il telefono.

Nel progetto concettuale vengono individuate i seguenti set di entità con rispettivi attributi e chiavi.

Tra tali set di entità sussistono le seguenti relazioni:

· Categoria e Articolo hanno una relazione di tipo 1:N, in quanto ciascuna categoria può contenere più articoli, mentre un articolo può appartenere ad una solo categoria. Chiamiamo questa relazione Appartiene;

· Articolo e Componente sono in relazione N:M, in quanto ciascun articolo è composto da più componenti e ciascun tipo di componente può entrare nella composizione di più articoli; può poi essere necessario utilizzare più pezzi di un certo componente per comporre un determinato articolo, per cui un attributo della relazione è la quantità. Chiamiamo questa relazione Composto;

· Laboratorio e Componente sono in relazione 1:N in quanto un laboratorio può costruire più componenti, mentre un determinato componente viene prodotto da un solo laboratorio. Chiamiamo questa relazione Prodotta;

· Negozio e Ordine sono in relazione 1:N, in quanto un negozio può effettuare più ordini, mentre ciascun ordine è relativo a un unico negozio. Chiamiamo questa relazione Effettuato;

· Ordine e Articolo sono in relazione N:M, in quanto in un ordine possono essere richiesti più articoli e un articolo può comparire in più ordini; la relazione ha come attributo la quantità nella quale un certo articolo viene richiesto nell’ordine. Chiamiamo questa relazione Richiesto.

La figura 2.10 mostra la rappresentazione dello schema concettuale del database Mobili Componibili mediante il modello entità-relazione.

1) Perfetta comprensione della realtà che si vuole rappresentare.

2) Individuazione dei set di entità.

· Studiare la descrizione del Contesto a cui ci si riferisce e la definizione degli Obiettivi del Progetto.

· Individuare i Nomi degli Obiettivi/Concetti che è indispensabile citare per descrivere Contesto e Obiettivi.

· Valutare se si tratta di Nomi di Entità che dovranno essere gestite (o referenziate) dal sistema in esame.

3) Individuazione degli attributi che caratterizzano i set di entità trovati al passo precedente, e scelta (o definizione) della chiave per ogni set di entità.

4) Individuazione delle relazioni tra i vari set di entità e definizione della loro cardinalità.

· Studiare la descrizione del Contesto a cui ci si riferisce e la definizione degli Obiettivi del Progetto.

· Individuare le frasi che legano fra loro due set di entità con un verbo (Entità soggetto + verbo + Entità oggetto).

· Valutare se il verbo rappresenta un fatto che fa nascere una relazione fra due set di entità.

· Verificare che non esistano relazioni duplicate o ingannevoli.

· Definire la cardinalità delle relazioni.

· Individuare eventuali attributi delle relazioni.

5) Disegno del diagramma entità-relazione.

Ai set di entità, agli attributi e alle relazioni devono essere assegnati dei nomi rappresentativi della realtà che esprimono e non devono essere ambigui.

Perché dovremmo essere interessati al modello dati di un sistema? In primo luogo perché le strutture di dati e le relazioni possono essere così complesse che vogliamo evidenziarle ed esaminarle indipendentemente dall’elaborazione che avrà luogo. In effetti, ciò è particolarmente vero quando il modello del sistema viene mostrato agli utenti esecutivi di livello superiore in un’organizzazione (ad esempio, i vicepresidenti o direttori di reparto). Tali utenti sono spesso interessati ai dati: quali dati servono per condurre gli affari? In che modo i dati sono correlati ad altri dati? Chi possiede i dati? A chi è consentito l’accesso ai dati?

La risposta ad alcune di queste domande – ad esempio, l’accesso ai dati e l’identificazione dei proprietari – è fornita dai DA. Ogni volta che si inizia a costruire un nuovo sistema informativo, si ha bisogno di parlare con queste persone in modo da poter coordinare le proprie informazioni sul sistema col loro modello di informazioni globale a livello aziendale.

Si dovrà altresì conversare con il gruppo dei DBA, situato solitamente nel reparto di elaborazione dati (mentre i DA non vi appartengono necessariamente), il cui compito è quello di garantire che i database computerizzati siano organizzati, gestiti e controllati efficacemente. Quindi essi costituiscono spesso la squadra di implementazione che ha la responsabilità di prendere un modello essenziale (cioè, un modello indipendente dalla tecnologia specifica) e convertirlo in un progetto di database fisico efficace ed efficiente per Oracle, Informix, DB2 o qualche altro sistema di gestione di database.

In base alle informazioni presentate dal diagramma E-R, il gruppo di amministrazione del database può iniziare a determinare i tipi di chiave o di indici o di puntatori che servono per accedere efficientemente ai record del database.

Quindi il modello dei dati fornisce, oltre alla rappresentazione dei dati del sistema che si vuole gestire, un utile strumento di conversazione con gli altri gruppi di lavoro che interagiscono in un progetto. Ma esso riguarda esclusivamente dati e relazioni tra i dati, senza fornire alcuna informazione sulle funzioni che creano e utilizzano i dati. Queste informazioni sono fornite da un altro tipo di diagramma, chiamati Data Flow Diagram (DFD), che modellano le funzioni svolte da un sistema (vedi appendice A).

Prima dell’arrivo dei sistemi relazionali i DBMS si basavano su modelli reticolari o gerarchici che non sono altro che dei casi particolari del modello relazionale.

Successivamente al modello relazionale sono arrivati i sistemi orientati agli oggetti e alla logica che costituiscono l’ultima tendenza nell’ambito dei modelli dati e ancora oggi non è disponibile uno standard che ne regoli la definizione.

Anche se il modello entità-relazione è attualmente il più diffuso, in alcuni contesti, si possono adattare meglio i sistemi gerarchici e reticolari, però scegliere lo schema concettuale che offra la migliore efficienza può essere piuttosto difficile e richiede una profonda comprensione del progetto del modello desiderato.

E’ da tenere comunque presente che esistono degli algoritmi che permettono di passare da uno schema di database di un modello dati ad un altro in modo più o meno semplice.

Vediamo adesso brevemente gli altri suddetti modelli dati.

A grandi linee il modello dati reticolare è un modello entità-relazione in cui le relazioni sono vincolate ad essere binarie e del tipo uno-a-molti. Tale vincolo consente di usare, per i dati, il modello di grafo orientato.

Al posto di set di entità, il modello reticolare parla di tipo record logico. Un tipo record logico è il nome di un insieme di record, chiamati record logici. I record logici sono composti da campi con i quali vengono rappresentati gli equivalenti degli "attributi" del modello entità-relazione.

Le "relazioni binarie uno-a-molti", vengono chiamati collegamenti o link.

Per rappresentare i tipi record e i loro collegamenti si disegna un grafo orientato, chiamato rete, che in realtà è un diagramma semplificato entità-relazione. I nodi corrispondono ai tipi di record logici, e gli archi rappresentano i collegamenti. I nodi e gli archi sono battezzati rispettivamente coi nomi dei loro tipo record logico e dei link. Gli archi sono orientati nella direzione uno-a-molti e sono percorribili in entrambe le direzioni.

Il record logico che si trova nella direzione "uno" della relazione uno-a-molti si chiama owner mentre l’altro si chiama member (vedi fig. 2.11).

L' esempio precedente è un caso molto semplice di rete, uno schema più generico è mostrato nella figura 2.12.

Nel modello dati gerarchico (sottoinsieme del modello reticolare) lo schema del database è vincolato ad essere costituito da una struttura ad albero (uno o più, foresta) nelle quali sono rappresentate bene le relazioni uno-a-molti ma non quelle molti-a-molti, quindi si adatta bene a certe realtà ma non a tutti i possibili contesti.

Nel modello dati gerarchico vale ancora la terminologia del modello reticolare come ad esempio "tipo record logico" ma alcuni termini della teoria degli alberi si adattano meglio al caso, come ad esempio, l’owner è chiamato più comunemente padre e il member figlio. La restrizione fondamentale rispetto alle reti è che un tipo di record può essere figlio solo su un collegamento mentre un tipo di record può essere padre su più collegamenti (gerarchia). 

La figura 2.13 mostra un esempio di struttura gerarchica.

Al contrario del modello reticolare, nel modello gerarchico i collegamenti sono percorribili solo in un verso, da padre a figlio, ma questa limitazione può essere superata con delle tecniche particolari che portano all’introduzione di due nuovi oggetti "tipo record virtuali" e "tipo record combinati".

Essi, nel primo caso sono semplicemente dei puntatori, nel secondo, sono dei puntatori più dei dati, che permettono di arrivare direttamente al nodo di interesse senza passare dai nodi intermedi e creare dei cammini arbitrari tra alberi differenti. Queste tecniche permettono anche di gestire le relazioni molti-a-molti (fig. 2.14).

Nell’ambito dei DBMS successivi al modello relazionale un accenno particolare va fatto ai modelli object oriented (OO-DBMS). Essi hanno la capacità di un DBMS e insieme alla combinazione DML/Linguaggio host hanno le seguenti caratteristiche:

· Oggetti complessi: avere la capacità di definire tipi di dati con strutture nidificate,

· Incapsulamento dell’informazione: cioè la capactà di definire procedure che si applicano solo a oggetti di un determinato tipo e la possibilità di richiedere che tutti gli accessi a questi oggetti avvengano attraverso l’applicazione di una di queste procedure (viene occultata la struttura interna degli oggetti),

· Identità degli oggetti: capacità del sistema di distinguere due oggetti che sembrano gli stessi (componenti primitive uguali, ma indirizzo diverso),

· Gerarchia di tipi: permettere ai tipi di avere dei sottotipi con caratteristiche proprie.

Nella teoria dei sistemi object oriented un oggetto è un insieme di dati, più le procedure per operare su questi dati. In termini rigorosamente informatici, un oggetto è un tipo di dato astratto (Abstract Data Type – ADT) composto per l’appunto dai dati e dalle procedure per operare su di essi, e tale che l’unico accesso possibile avviene tramite queste procedure. Queste procedure vengono chiamate metodi e vengono attivati dai messaggi che corrispondono a chiamate di funzioni dei linguaggi di programmazione tradizionali. L’insieme di tutti i metodi forniti per un oggetto è detta la sua interfaccia o il protocollo di accesso. Una classe invece è l’implementazione di un tipo di dato astratto basata sui concetti di ereditarietà, incapsulazione e polimorfismo. Per ereditarietà si intende il meccanismo di derivazione delle caratteristiche tra le classi di oggetti. Mentre polimorfismo è la possibilità di definire con lo stesso nome procedure su oggetti diversi e gestire quindi variabili non tipizzate.

Introduciamo adesso una notazione per definire la struttura degli oggetti, cioè il formato per i tipi.

Notiamo prima di tutto che l’insieme di strutture ad oggetto definibili nel modello ad oggetti è molto simile all’insieme dei possibili schemi per i database record del modello gerarchico, è possibile definire il modo ricorsivo l’insieme dei tipi oggetti permessi.

· Un ente di tipo elementare, ad esempio un intero, un reale, o stringa di caratteri, è di tipo oggetto. Un tale tipo corrisponde al tipo di dato per un "campo" nelle reti o nelle gerarchie.

· Se T è un tipo oggetto, allora SETOF(T) è un tipo oggetto.

· Se T1, … , Tk sono tipi oggetto allora RECORDOF(T1, …, Tk) è un tipo oggetto.

Facciamo un esempio. Supponiamo per semplicità che i soli tipi elementari siano string e integer.

Allora un tipo di un prodotto può essere rappresento dal record:

TipoProd = RECORDOF(nome:string, NumProd:integer)

dove i campi del record sono stati rappresentati dalla coppia (<nomecampo>:<tipo>).

Se vogliamo gestire gli ordini, dobbiamo rappresentare le coppie prodotto/quantità, allora necessitiamo creare il seguente tipo di oggetto:

PQTipo = RECORDOF(prodotto:TipoProd, quant:integer)

In questo caso il primo campo è un oggetto di tipo non elementare, e va pensato come un puntatore a un prodotto.

Adesso possiamo definire il tipo di un ordine come:

TipoOrd = RECORDOF(NumOrd:integer, comprende:SETOF(PQTipo))

Da notare all’interno della definizione di TipoOrd vi è quella di un altro tipo di oggetto, comprende.

SETOF(PQTipo) è equivalente alla due dichiarazioni:

SPTipo = SETOF(PQTipo)

TipoOrd = RECORDOF(NumOrd:integer, comprende:SPQTipo)

Uno schema di database per un ipotetico DB per un negozio è rappresentato nella figura 2.15.

2.7.4 Modelli basati sulla logica

Alcuni sistemi chiamati Knowledge Base Management Systems (KBMS) si basano su regole logiche o conoscenza.

Un sistema KBMS è il risultato dell’integrazione di un DBMS e della tecnologia dell’intelligenza artificiale (AI). I modelli e la tecnologia dei DB attuali, in particolare quella relazionale, non sono appropriate per questa integrazione.

Si è quindi studiata una nuova tecnologia e nuovi modelli di cui necessita introdurre alcune definizioni.

Una base di conoscenza è un insieme strutturato di:

· Dati rappresentanti i fatti circa gli aspetti del dominio del discorso che si vuole modellare (alcune volte chiamato extensional database o fact base);

· Conoscenza che rappresenta un alto livello di interpretazione e comprensione del dominio del discorso (alcune volte chiamato intensional database o rule base).

Un knowledge base management system è uno strumento il quale fornisce:

· Funzionalità per operare sia sull’intensional che sull’extensional database,

· Un linguaggio che permetta di accedere alla base di conoscenza,

· Meccanismi per l’applicazione della conoscenza ai dati per ottenere risposte a delle richieste di ragionamento circa i fatti.

Nei modelli dati basati sulla logica uno schema di database (o semplicemente schema) è definito come la coppia (IDB, IC) dove IDB è l’intensional database e IC è un insieme finito di regole chiamate vincoli di integrità (o semplicemente integrità). I vincoli usualmente esprimono informazioni in forma negativa che restringono l’ammissibilità delle informazioni del database.

Per uno schema (IDC, IC), uno stato del database e una tripla (IDB, IC, EDB) dove EDB è l’extensional database.

Vediamo adesso alcune necessarie definizioni sulle regole logiche.

Un predicato è una funzione booleana (risultato vero o falso) costituito da un nome e da un insieme di argomenti. Gli argomenti possono essere costituiti da costanti, variabili e simboli di funzioni. Le

funzioni forniscono come risultato valori del tipo da noi scelto.

Le regole logiche sono delle istruzioni logiche del tipo: "se A1 e A2 e … An sono vere, allora B è vera" e si scrive:

B :- A1 & A2 & … & An.

il simbolo ":-" si legge "se".

Le regole logiche forniscono informazioni sui dati del database ed è utile notare l’analogia tra nozione logica di predicato coi sui argomenti e il nome di relazione con i suoi attributi. Cioè possiamo pensare che un predicato sia vero in corrispondenza dei suoi argomenti, se e solo se tali argomenti formano una tupla della relazione corrispondente.

Vista la brevità della trattazione invece di continuare con il formalismo introduciamo qualche esempio.

Supponiamo di avere uno schema di relazione Impiegati con attributi Nome, Ufficio, Stipendio e Indirizzo. Possiamo definire una vista pertutti attraverso la regola logica:

pertutti(N, U, I) :- impiegati(N, U, S, I).

La regola afferma che per tutti i nomi degli impiegati N, uffici U e indirizzo I, (N, U, I) è una proprietà del predicato pertutti se esiste uno stipendio S tale che (N, U, S, I) sia un’istanza del predicato impiegati. Notare che in generale una variabile come S, che compare alla destra del simbolo" :-", ma non alla sua sinistra, è trattata come esistenzialmente quantificata, quindi la regola si legge "esiste qualche S", dopo aver detto il "se" che corrisponde al simbolo ":-".

Vediamo un altro esempio di come sia possibile esprimere in termini logici le informazioni sui dati:

supponiamo di avere la relazione Impiegati con i soli attributi Nome e Uff. e la relazione Uffici con gli attributi Uff. e Capo. Possiamo allora definire il predicato capo_di(I, C) col significato intuitivo che il capo C comanda l’impiegato I, espresso da:

capo_di(I, C) :- impiegati(I, U) & uffici(U, C). (2.1)

Cioè (I, C) è una istanza di capo_di tale per cui esiste un ufficio U tale che (I, U) sia un’istanza di impiegati e (U, C) una di uffici. In sostanza abbiamo usato la precedente regola logica per creare la vista capo_di che è analoga a una relazione con gli attributi nome e capo.

La ricercare del capo dell’impiegato Rossi Mario si esprimere in termini del predicato capo_di semplicemente come:

capo_di(‘Rossi Mario’, X) (2.2)

La ricerca dei valori di X che rendono vera la 2.2 si trovano con un algoritmo sostanzialmente identico a quello indicato in 2.3, ma la regola logica 2.1 ha un ruolo importante nel permettere al sistema di interpretare il significato dell’interrogazione. In senso generico possiamo dire che la 2.1 rappresenta la "conoscenza" a proposito della relazione capo_di.

              select capo

              from impiegati, uffici (2.3)

              where impiegati.nome = ‘Rossi Mario’

                                         and impiegati.uff = uffici.uff;

Un esempio di schema di database è:

Dove abbiamo un unico predicato, capo_di, ed una unica regola di integrità, icl. Essa afferma che tutti gli impiegati devono appartenere ad un ufficio esistente.