Ultima modifica da un moderatore:
Salve popolo di inforge 
,
bentornati, dopo un giorno di pausa, ogni tanto ci sta, a scrivere di basi di dati!
C'eravamo lasciati con una panoramica sulla progettazione e le tre fasi cui e' divisa, no!? Avete studiato? Avete letto? Avete approfondito? Sicuro NO! Vabeh chissenefrega io continuo poi al massimo ve li rivedete con calma... dicevo, abbiam accennato alle tre fasi della progettazione, adesso ne vedremo una, ovvero la progettazione concettuale!
Prima di iniziare a scrivere ininterrottamente vi ricordo come al solito che e' buona cosa approfondire per conto proprio gli argomenti che tratteremo all'interno di queste guide, che non sono la bibbia assoluta del mondo ma che sono comunque cose corrette e reali, con cui un informatico ha spesso a che fare! Come sempre tentero' di semplificare alcuni concetti e rendere il tutto molto discorsivo e accattivante con l'utilizzo di qualche immaginetta che creo di volta in volta... ma prima di iniziare voglio condividere con voi parte di questo momento, ovvero mentre scrivo... anzi, quando ho iniziato a scrivere
(tralasciando il fatto che ogni volta faccio tipo 2-3 bozze di tutta l'intera guida per correggere errori imbarazzantissimi 
, pero' vabe' se ne trovate, sopratutto di ortografia segnalatemeli, sono le 5.30 e la mia lucidita' mentale non e' proprio al massimo per rileggermi tutto tutto, per quelli di battitura invece chissene....)
Ok iniziamo subito dai, buona lettura!
La progettazione concettuale e' una delle tre progettazioni che viene svolta durante tutta la fase di progettazione di una base dati.
In generale e' la fase che segue la raccolta e l'analisi dei requisiti, che c'e' da dire NON e' un'attivita' standardizzabile e non esistono metodologie definite da seguire.
L'obiettivo e' quello di stendere una relazione che descriva la realta' di riferimento, cioe' la realta' che il sistema informativo dovra' in qualche modo informatizzare.
Per raccolta dei requisiti s'intende, in parole povere eh, la definizione delle caratteristiche che l'applicazione deve avere e delle problematiche che deve risolvere.
Per quanto riguarda invece l'analisi dei requisiti invece intendiamo lo studio delle informazioni raccolte al fine di organizzarle come si deve affinche' poi la descrizione sia effettivamente comprensibile dai progettisti.
Per quanto riguarda la raccolta delle informazioni vedremo di procedere seguendo specifiche fasi!
Beh, c'e' da chiedersi innanzitutto da chi otteniamo determinate informazioni, no?!
Ovviamente dagli utenti dell'applicazione, ovvero gli operatori finali, da chi seno'...
All'interno di un'azienda e' chiaro che e' possibile "interrogare" operatori che stanno su livelli differenti, non so ad esempio gli operatori finali o i dirigenti per dire, ma ad "alto livello", consultando comunque personale che non e' direttamente coinvolto nell'uso dell'applicazione (vedi i dirigenti ad esempio) otterremo delle risposte ed informazioni molto generiche in quanto appunto a differenza di un operatore finale non sara' in grado di fornirci informazioni dettagliate relative ai processi che dovranno successivamente essere informatizzati, ed e' normale questo eh.. e' un dato di fatto che i dirigenti si occupino di tutt'altro ed anche se in alcuni casi "ne sanno di piu'", spesso invece si interessano poco di tecnicismi.
E' ovviamente possibile che le informazioni ottenute possano essere incomplete o addirittura contrastanti, in quel caso bisogna perseverare in questa sorta di indagine al fine di avere maggiore chiarezza intorno alle singole informazioni ottenute.
Altra forma di documentazione e' la documentazione esistente.
Nel momento in cui si effettua la raccolta delle informazioni, e' buona norma avere anche tutti i documenti su cui in genere si lavora.
Piccola nota: In genere durante queste fasi comunque e' anche possibile affiancare sul campo l'operatore al fine di comprendere al meglio il processo da informatizzare. Comunque, per documentazione esistente s'intende anche la raccolta dei report che si producono, oppure i moduli che bisogna compilare e cosi' via.
L'ultima forma di informazione e' il software pre-esistente (se esiste).
Se c'e' un software che sta gia' operando e' utile conoscerlo ed ottenerne piu' informazioni possibili in quanto appunto avra' di sicuro "subito" tutta la trafila di cui stiamo parlando, poiche' appunto sara' stata realizzato basandosi su una pregressa analisi dei requisiti, e progettazione.
Bene, il prodotto finale sara' dunque, una volta raccolte tutte queste informazioni (che verranno analizzate ed organizzate), si produrra' una relazione scritta che sara' realizzata in un linguaggio naturale... una roba semi-tranquilla quindi
Sostanzialmente all'interno della relazione scritta avremo le:
- specifiche sui dati
- specifiche sulle operazioni
Benche' non esista una standardizzazione di questa fase comunque la relazione scritta segue delle regole che in genere sono sostanzialmente di buon senso, innanzitutto bisognerebbe che la relazione abbia un corretto livello di astrazione, non deve essere ne' troppo specifica, per non perdersi in dettagli inutili, ne' troppo generica, perche' altrimenti rischia di non far comprendere o non riportare le informazioni complete.
E' necessario usare un linguaggio estremamente chiaro e comprensibile e si evitera', se possibile, l'uso di sinonimi, ad esempio, se ci riferiremo ad un dato concetto con un dato nome, per tutta la relazione lo esprimeremo sempre col medesimo nome! In caso di omonimie fra piu' concetti e' bene separarli, e questo lo si fa praticamente realizzando un vero e proprio glossario di termini dove si riporteranno i vari concetti fondamentali e l'uso di eventuali sinonimi se non si e' riusciti ad eliminarli, ed eventuali associazioni.
Completata la fase di analisi e raccolta dei requisiti si passa alla fase successiva, la progettazione.
L'obiettivo finale della progettazione concettuale sara' quello di produrre un documento detto "Schema concettuale" e sara' uno schema Entita' Relazione (E/R) in quanto il modello concettuale a cui faremo riferimento e' proprio quello Entita'/Relazione.
Il procedimento realizzativo prevede che si prenda in considerazione la documentazione realizzata nella fase precedente e la si studi al fine di individuarne all'interno dei concetti che saranno poi tradotti e schematizzati attraverso i costrutti dello schema E/R.
In particolare, se all'interno della documentazione si individuera' un concetto che rappresenta una "classe di oggetti", tale concetto si tradurra' in una entita', e pertanto a livello schematico sara' rappresentato da un rettangolo all'interno del quale verra' inserito il nome dell'entita' (ricordate le entita' no? ne abbiamo scritto l'altro ieri un papiro infinito* andate a rileggervelo nel caso in cui abbiate dubbi!)
Se invece dai concetti si estrae un concetto semplice, atomico, che da solo probabilmente non fornira' alcuna informazione ma e' utile aggregandolo solo ad altri concetti sara' tradotto in un attributo! Pertanto l'attributo verra' poi associato alla relazione, vediamo un'immaginetta con un attributo per la relazione A e due per la relazione B
E' possibile poi che un concetto associ altri concetti, e in questo caso viene tradotto in relazione, pertanto a livello grafico verra' rappresentato da un rombo legato alle relazioni che pone in associazione.
Infine e' possibile che un concetto rappresenti casi particolari di altri, in questo caso la traduzione sara' una generalizzazione, la rappresentazione grafica della generalizzazione come sappiamo (si spera) sara' una freccia e delle linee che legano le specializzazioni, in particolare B e' la generalizzazione di C e D o che C e D sono le specializzazioni di B.
Ecco, l'immaginetta finale rappresenta uno schema E/R molto semplice, che comunque richiama tutti i concetti estraibili dalla documentazione ottenuta al termine della fase di raccolta e analisi dei requisiti.
La realizzazione di questo schema puo' essere effettuata attraverso una serie di strategie di progetto, che adesso vedremo in breve:
- Strategia Top-down:
Il progettista descrive attraverso uno schema molto generale l'intera realta' di riferimento e via via, nei passi successivi, attraverso delle trasformazioni elementari definite come "primitive di trasformazione top-down" e successivamente "raffina" lo schema aggiungendo dei dettagli. Al termine si avra' uno schema che descrivera' completamente la realta' di riferimento.
- Strategia Bottom up:
In questo caso, invece, il progettista divide la realta' di riferimento in sezioni, e si preoccupa di risolvere le singole sezioni, quindi ne realizza lo schema concettuale per ciascuna, ed alla fine li riunira' tutti in un unico schema.
- Mista:
Nella realta' si preferisce usare pero' una strategia mista, strategia nella quale il progettista cerca di utilizzare meccanismi dell'una e dell'altra strategia, ad esempio potrebbe iniziare con il rappresentare l'intera realta' di riferimento, come richiede la Top-down, per poi concentrarsi su un singolo aspetto..
Ma, aldila' della strategia adottata, lo schema concettuale finale dovra' soddisfare alcuni criteri, ed e' fondamentale che questi siano soddisfatti al fine di definire' "di qualita'" lo schema ottenuto.
La qualita' di uno schema concettuale viene valutata attraverso quattro proprieta':
1) Correttezza
2) Completezza
3) Leggibilita'
4) Minimalita'
Innanzitutto lo schema concettuale deve soddisfare il criterio di correttezza.
I vari costrutti non devono essere stati utilizzati inadeguatamente e devono descrivere i concetti per il quale sono stati immaginati e pensati.
La correttezza si divide in:
- Semantica
- Sintattica
Non e' possibile, ad esempio, che una generalizzazione sia applicata ad una relazione (brutto errore semantico)
Seconda caratteristica e' la completezza.
Tutta l'informazione estraibile e ottenuta attraverso la fase di raccolta e analisi dei requisiti, deve essere contenuta all'interno dello schema concettuale, quest'ultimo infatti deve essere esaustivo e qualsiasi informazione voglio ottenere devo poterlo fare attraverso lo schema.
In terzo luogo deve essere leggibile..
Ma questa proprieta' dipende puramente dagli aspetti grafici e dalla capacita' grafica del progettista..Uno schema e' leggibile se non e' confuso, se vengono distribuite in maniera corretta tutti i vari elementi e appunto come detto un secondo fa, se non c'e' "confusione".
Infine, uno schema, deve essere anche minimale!
Cioe' deve soddisfare i criteri di minimalita', ovvero, le informazioni contenute in esso non devono essere ripetute piu' volte poiche', uno schema ridondante, produce una base dati ridondante che puo' facilmente incappare in un problema molto grave, ovvero l'inconsistenza e pertanto questo criterio e' particolarmente importante che va soddisfatto sin dall'inizio.
A questo punto si puo' fare riferimento ad uno schema concettuale semi-serio
Qui si rappresenta la gestione di una biblioteca:
All'interno della realta' di riferimento abbiamo l'entita' libro e l'entita' utente, poste in relazione tra loro attraverso l'associazione prestito.
Nella fattispecie l'utente non e' altro che una generalizzazione di utente occasionale e utente associato. Se l'utente e' associato avra' anche un numero di tessera, se e' occasionale avra' un numero progressivo. L'utente e' individuato univocamente dagli identificatori chiave: tipo documento e numero documento, sono contrassegnati infatti dal costrutto identificatore chiave.
La relazione prestito ha anche una proprieta' data ed infine e' stato aggiunta un'entita' editore che e' posta in relazione con l'entita' libro attraverso la relazione edizione che possiede come proprieta' il numero dell'edizione.
L'editore ha un nome, un telefono e una citta'. Il libro ha tre proprieta', in particolare concentriamoci sulla proprieta' autore!
Questa puo' essere rappresentata anche in maniera diversa ma la posizione dell'immaginetta e' una scelta precisa e discende dall'analisi effettuata in precedenza. Questo schema soddisfa e schematizza la realta' di riferimento ottenuta nella fase di raccolta e analisi e requisiti effettuata in precedenza.
In un'altra situazione potrebbe essere necessario che dell'autore si debbano conoscere anche altre informazioni (come la data di nascita, di morte, nazionalita' ecc..) tutte informazioni che aggregate insieme danno origine alla nuova entita' autore. In tal caso, autore, sarebbe posta in relazione con l'entita' libri!
Cioe' in questo caso, il fatto che autore sia semplicemente una proprieta' di libro e' qualcosa che discende dall'analisi e dallo studio della documentazione ottenuta nella fase di raccolta ed analisi dei requisiti.
Non ho messo volutamente le cardinalita', le famo adesso!
Vediamo che, un utente, ad esempio, potrebbe essere appena iscritto alla biblioteca e potrebbe quindi non avere ancora preso in prestito alcun libro, potrebbe avere una tessera ma non essere ancora coinvolto nella relazione prestito (cioe' non ha preso ancora alcun libro). Siamo nel caso di (0,n), ovvero non avrebbe potuto prendere libri o avrebbe potuto prenderne n.
Un libro poi, puo' essere stato preso da 0 (da nessuno), oppure potrebbe essere stato preso da m persone. (0,m)
Nella definizione generale quindi potremmo definire la relazione come (n,m)
Su edizione invece abbiamo una relazione (1,n), poiche' l'editore, se c'e', ha almeno prodotto un libro ma potrebbe averne editato n.
Un libro invece, se c'e', e' stato editato da almeno 1 editore ed al massimo da 1 editore, quindi questa relazione sara' di tipo (1,1)
Tuttavia, l'aspetto importante di questa roba e' che un qualsiasi schema concettuale non va bene per tutto, poiche' ognuno discende da un'analisi dei requisiti a se, e quindi da una realta' specifica! Ripetiamo quindi... questo schema potrebbe non essere applicato ad un'altra gestione di una biblioteca, perche' magari un'analisi dei requisiti ad un'altra biblioteca si scopre che ci sono esigenze diverse.
Questo e' il caso della produzione di database e applicazioni di tipo "verticale", in questo caso non sara' generalistica e non risolvera' i problemi "per tutte le biblioteche" in questo caso, e' pertanto necessario capire che lo schema concettuale deve necessariamente discendere dallo studio e dalla lettura della documentazione ottenuta in fase di analisi dei requisiti.. senza questa rischieremmo di ottenere schemi concettuali completamente inaffidabili, o comunque che non rispondano a caratteristiche di completezza, correttezza e quindi siano di qualita' scadente!
Quindi, per concludere tengo a ribadire nuovamente che. la fase di analisi e di raccolta dei requisiti e' una fase estremamente importante, come tutte le altre ovviamente eh, ma se si fa male questa probabilmente si andranno ad inficiare tutte le altre...
Bene, se ci sono domane potete scrivermi tranquillamente un messaggio privato, o se vi serve qualche altra informazione in merito o volete insultarmi pesantemente mandatemi un messaggio privato
Il prossimo argomento e' facile da intuire.. basta aver seguito l'introduzione sulla progettazione, adesso la progettazione concettuale quindi la prossima sara' la p........!? lo lascio dire a voi, siete abbastanza svegli ed intelligenti da arrivarci, tranne ovviamente quando mi pokkate nhoya in teamspeak che vi fa un rm -rf e vi guarda soffrire in silenzio finche' non vi si spenga il computer perche' non ci sara' piu' nulla...
Bon si so fatte quasi le sei, basta nerdare e scrivere cose ...
Godetevi il meritato weekenddddddd!
Pertanto ovviamente non aspettatevi guide da me in questi due giorni
Ci rivedremo lunedi o martedi' con una nuova guida!
,bentornati, dopo un giorno di pausa, ogni tanto ci sta, a scrivere di basi di dati!
C'eravamo lasciati con una panoramica sulla progettazione e le tre fasi cui e' divisa, no!? Avete studiato? Avete letto? Avete approfondito? Sicuro NO! Vabeh chissenefrega io continuo poi al massimo ve li rivedete con calma... dicevo, abbiam accennato alle tre fasi della progettazione, adesso ne vedremo una, ovvero la progettazione concettuale!
Prima di iniziare a scrivere ininterrottamente vi ricordo come al solito che e' buona cosa approfondire per conto proprio gli argomenti che tratteremo all'interno di queste guide, che non sono la bibbia assoluta del mondo ma che sono comunque cose corrette e reali, con cui un informatico ha spesso a che fare! Come sempre tentero' di semplificare alcuni concetti e rendere il tutto molto discorsivo e accattivante con l'utilizzo di qualche immaginetta che creo di volta in volta... ma prima di iniziare voglio condividere con voi parte di questo momento, ovvero mentre scrivo... anzi, quando ho iniziato a scrivere
(tralasciando il fatto che ogni volta faccio tipo 2-3 bozze di tutta l'intera guida per correggere errori imbarazzantissimi , pero' vabe' se ne trovate, sopratutto di ortografia segnalatemeli, sono le 5.30 e la mia lucidita' mentale non e' proprio al massimo per rileggermi tutto tutto, per quelli di battitura invece chissene....)
La progettazione concettuale e' una delle tre progettazioni che viene svolta durante tutta la fase di progettazione di una base dati.
In generale e' la fase che segue la raccolta e l'analisi dei requisiti, che c'e' da dire NON e' un'attivita' standardizzabile e non esistono metodologie definite da seguire.
L'obiettivo e' quello di stendere una relazione che descriva la realta' di riferimento, cioe' la realta' che il sistema informativo dovra' in qualche modo informatizzare.
Per raccolta dei requisiti s'intende, in parole povere eh, la definizione delle caratteristiche che l'applicazione deve avere e delle problematiche che deve risolvere.
Per quanto riguarda invece l'analisi dei requisiti invece intendiamo lo studio delle informazioni raccolte al fine di organizzarle come si deve affinche' poi la descrizione sia effettivamente comprensibile dai progettisti.
Per quanto riguarda la raccolta delle informazioni vedremo di procedere seguendo specifiche fasi!
Beh, c'e' da chiedersi innanzitutto da chi otteniamo determinate informazioni, no?!
Ovviamente dagli utenti dell'applicazione, ovvero gli operatori finali, da chi seno'...
All'interno di un'azienda e' chiaro che e' possibile "interrogare" operatori che stanno su livelli differenti, non so ad esempio gli operatori finali o i dirigenti per dire, ma ad "alto livello", consultando comunque personale che non e' direttamente coinvolto nell'uso dell'applicazione (vedi i dirigenti ad esempio) otterremo delle risposte ed informazioni molto generiche in quanto appunto a differenza di un operatore finale non sara' in grado di fornirci informazioni dettagliate relative ai processi che dovranno successivamente essere informatizzati, ed e' normale questo eh.. e' un dato di fatto che i dirigenti si occupino di tutt'altro ed anche se in alcuni casi "ne sanno di piu'", spesso invece si interessano poco di tecnicismi.
E' ovviamente possibile che le informazioni ottenute possano essere incomplete o addirittura contrastanti, in quel caso bisogna perseverare in questa sorta di indagine al fine di avere maggiore chiarezza intorno alle singole informazioni ottenute.
Altra forma di documentazione e' la documentazione esistente.
Nel momento in cui si effettua la raccolta delle informazioni, e' buona norma avere anche tutti i documenti su cui in genere si lavora.
Piccola nota: In genere durante queste fasi comunque e' anche possibile affiancare sul campo l'operatore al fine di comprendere al meglio il processo da informatizzare. Comunque, per documentazione esistente s'intende anche la raccolta dei report che si producono, oppure i moduli che bisogna compilare e cosi' via.
L'ultima forma di informazione e' il software pre-esistente (se esiste).
Se c'e' un software che sta gia' operando e' utile conoscerlo ed ottenerne piu' informazioni possibili in quanto appunto avra' di sicuro "subito" tutta la trafila di cui stiamo parlando, poiche' appunto sara' stata realizzato basandosi su una pregressa analisi dei requisiti, e progettazione.
Bene, il prodotto finale sara' dunque, una volta raccolte tutte queste informazioni (che verranno analizzate ed organizzate), si produrra' una relazione scritta che sara' realizzata in un linguaggio naturale... una roba semi-tranquilla quindi
Sostanzialmente all'interno della relazione scritta avremo le:
- specifiche sui dati
- specifiche sulle operazioni
Benche' non esista una standardizzazione di questa fase comunque la relazione scritta segue delle regole che in genere sono sostanzialmente di buon senso, innanzitutto bisognerebbe che la relazione abbia un corretto livello di astrazione, non deve essere ne' troppo specifica, per non perdersi in dettagli inutili, ne' troppo generica, perche' altrimenti rischia di non far comprendere o non riportare le informazioni complete.
E' necessario usare un linguaggio estremamente chiaro e comprensibile e si evitera', se possibile, l'uso di sinonimi, ad esempio, se ci riferiremo ad un dato concetto con un dato nome, per tutta la relazione lo esprimeremo sempre col medesimo nome! In caso di omonimie fra piu' concetti e' bene separarli, e questo lo si fa praticamente realizzando un vero e proprio glossario di termini dove si riporteranno i vari concetti fondamentali e l'uso di eventuali sinonimi se non si e' riusciti ad eliminarli, ed eventuali associazioni.
Completata la fase di analisi e raccolta dei requisiti si passa alla fase successiva, la progettazione.
Il procedimento realizzativo prevede che si prenda in considerazione la documentazione realizzata nella fase precedente e la si studi al fine di individuarne all'interno dei concetti che saranno poi tradotti e schematizzati attraverso i costrutti dello schema E/R.
In particolare, se all'interno della documentazione si individuera' un concetto che rappresenta una "classe di oggetti", tale concetto si tradurra' in una entita', e pertanto a livello schematico sara' rappresentato da un rettangolo all'interno del quale verra' inserito il nome dell'entita' (ricordate le entita' no? ne abbiamo scritto l'altro ieri un papiro infinito* andate a rileggervelo nel caso in cui abbiate dubbi!)
Se invece dai concetti si estrae un concetto semplice, atomico, che da solo probabilmente non fornira' alcuna informazione ma e' utile aggregandolo solo ad altri concetti sara' tradotto in un attributo! Pertanto l'attributo verra' poi associato alla relazione, vediamo un'immaginetta con un attributo per la relazione A e due per la relazione B
E' possibile poi che un concetto associ altri concetti, e in questo caso viene tradotto in relazione, pertanto a livello grafico verra' rappresentato da un rombo legato alle relazioni che pone in associazione.
Infine e' possibile che un concetto rappresenti casi particolari di altri, in questo caso la traduzione sara' una generalizzazione, la rappresentazione grafica della generalizzazione come sappiamo (si spera) sara' una freccia e delle linee che legano le specializzazioni, in particolare B e' la generalizzazione di C e D o che C e D sono le specializzazioni di B.
Ecco, l'immaginetta finale rappresenta uno schema E/R molto semplice, che comunque richiama tutti i concetti estraibili dalla documentazione ottenuta al termine della fase di raccolta e analisi dei requisiti.
La realizzazione di questo schema puo' essere effettuata attraverso una serie di strategie di progetto, che adesso vedremo in breve:
- Strategia Top-down:
Il progettista descrive attraverso uno schema molto generale l'intera realta' di riferimento e via via, nei passi successivi, attraverso delle trasformazioni elementari definite come "primitive di trasformazione top-down" e successivamente "raffina" lo schema aggiungendo dei dettagli. Al termine si avra' uno schema che descrivera' completamente la realta' di riferimento.
- Strategia Bottom up:
In questo caso, invece, il progettista divide la realta' di riferimento in sezioni, e si preoccupa di risolvere le singole sezioni, quindi ne realizza lo schema concettuale per ciascuna, ed alla fine li riunira' tutti in un unico schema.
- Mista:
Nella realta' si preferisce usare pero' una strategia mista, strategia nella quale il progettista cerca di utilizzare meccanismi dell'una e dell'altra strategia, ad esempio potrebbe iniziare con il rappresentare l'intera realta' di riferimento, come richiede la Top-down, per poi concentrarsi su un singolo aspetto..
Ma, aldila' della strategia adottata, lo schema concettuale finale dovra' soddisfare alcuni criteri, ed e' fondamentale che questi siano soddisfatti al fine di definire' "di qualita'" lo schema ottenuto.
La qualita' di uno schema concettuale viene valutata attraverso quattro proprieta':
1) Correttezza
2) Completezza
3) Leggibilita'
4) Minimalita'
Innanzitutto lo schema concettuale deve soddisfare il criterio di correttezza.
I vari costrutti non devono essere stati utilizzati inadeguatamente e devono descrivere i concetti per il quale sono stati immaginati e pensati.
La correttezza si divide in:
- Semantica
- Sintattica
Non e' possibile, ad esempio, che una generalizzazione sia applicata ad una relazione (brutto errore semantico
)Seconda caratteristica e' la completezza.
Tutta l'informazione estraibile e ottenuta attraverso la fase di raccolta e analisi dei requisiti, deve essere contenuta all'interno dello schema concettuale, quest'ultimo infatti deve essere esaustivo e qualsiasi informazione voglio ottenere devo poterlo fare attraverso lo schema.
In terzo luogo deve essere leggibile..
Ma questa proprieta' dipende puramente dagli aspetti grafici e dalla capacita' grafica del progettista..Uno schema e' leggibile se non e' confuso, se vengono distribuite in maniera corretta tutti i vari elementi e appunto come detto un secondo fa, se non c'e' "confusione".
Infine, uno schema, deve essere anche minimale!
Cioe' deve soddisfare i criteri di minimalita', ovvero, le informazioni contenute in esso non devono essere ripetute piu' volte poiche', uno schema ridondante, produce una base dati ridondante che puo' facilmente incappare in un problema molto grave, ovvero l'inconsistenza e pertanto questo criterio e' particolarmente importante che va soddisfatto sin dall'inizio.
A questo punto si puo' fare riferimento ad uno schema concettuale semi-serio
Qui si rappresenta la gestione di una biblioteca:
All'interno della realta' di riferimento abbiamo l'entita' libro e l'entita' utente, poste in relazione tra loro attraverso l'associazione prestito.
Nella fattispecie l'utente non e' altro che una generalizzazione di utente occasionale e utente associato. Se l'utente e' associato avra' anche un numero di tessera, se e' occasionale avra' un numero progressivo. L'utente e' individuato univocamente dagli identificatori chiave: tipo documento e numero documento, sono contrassegnati infatti dal costrutto identificatore chiave.
La relazione prestito ha anche una proprieta' data ed infine e' stato aggiunta un'entita' editore che e' posta in relazione con l'entita' libro attraverso la relazione edizione che possiede come proprieta' il numero dell'edizione.
L'editore ha un nome, un telefono e una citta'. Il libro ha tre proprieta', in particolare concentriamoci sulla proprieta' autore!
Questa puo' essere rappresentata anche in maniera diversa ma la posizione dell'immaginetta e' una scelta precisa e discende dall'analisi effettuata in precedenza. Questo schema soddisfa e schematizza la realta' di riferimento ottenuta nella fase di raccolta e analisi e requisiti effettuata in precedenza.
In un'altra situazione potrebbe essere necessario che dell'autore si debbano conoscere anche altre informazioni (come la data di nascita, di morte, nazionalita' ecc..) tutte informazioni che aggregate insieme danno origine alla nuova entita' autore. In tal caso, autore, sarebbe posta in relazione con l'entita' libri!
Cioe' in questo caso, il fatto che autore sia semplicemente una proprieta' di libro e' qualcosa che discende dall'analisi e dallo studio della documentazione ottenuta nella fase di raccolta ed analisi dei requisiti.
Non ho messo volutamente le cardinalita', le famo adesso!
Vediamo che, un utente, ad esempio, potrebbe essere appena iscritto alla biblioteca e potrebbe quindi non avere ancora preso in prestito alcun libro, potrebbe avere una tessera ma non essere ancora coinvolto nella relazione prestito (cioe' non ha preso ancora alcun libro). Siamo nel caso di (0,n), ovvero non avrebbe potuto prendere libri o avrebbe potuto prenderne n.
Un libro poi, puo' essere stato preso da 0 (da nessuno), oppure potrebbe essere stato preso da m persone. (0,m)
Nella definizione generale quindi potremmo definire la relazione come (n,m)
Su edizione invece abbiamo una relazione (1,n), poiche' l'editore, se c'e', ha almeno prodotto un libro ma potrebbe averne editato n.
Un libro invece, se c'e', e' stato editato da almeno 1 editore ed al massimo da 1 editore, quindi questa relazione sara' di tipo (1,1)
Tuttavia, l'aspetto importante di questa roba e' che un qualsiasi schema concettuale non va bene per tutto, poiche' ognuno discende da un'analisi dei requisiti a se, e quindi da una realta' specifica! Ripetiamo quindi... questo schema potrebbe non essere applicato ad un'altra gestione di una biblioteca, perche' magari un'analisi dei requisiti ad un'altra biblioteca si scopre che ci sono esigenze diverse.
Questo e' il caso della produzione di database e applicazioni di tipo "verticale", in questo caso non sara' generalistica e non risolvera' i problemi "per tutte le biblioteche" in questo caso, e' pertanto necessario capire che lo schema concettuale deve necessariamente discendere dallo studio e dalla lettura della documentazione ottenuta in fase di analisi dei requisiti.. senza questa rischieremmo di ottenere schemi concettuali completamente inaffidabili, o comunque che non rispondano a caratteristiche di completezza, correttezza e quindi siano di qualita' scadente!
Quindi, per concludere tengo a ribadire nuovamente che. la fase di analisi e di raccolta dei requisiti e' una fase estremamente importante, come tutte le altre ovviamente eh, ma se si fa male questa probabilmente si andranno ad inficiare tutte le altre...
Bene, se ci sono domane potete scrivermi tranquillamente un messaggio privato, o se vi serve qualche altra informazione in merito o volete insultarmi pesantemente mandatemi un messaggio privato
Il prossimo argomento e' facile da intuire.. basta aver seguito l'introduzione sulla progettazione, adesso la progettazione concettuale quindi la prossima sara' la p........!? lo lascio dire a voi, siete abbastanza svegli ed intelligenti da arrivarci, tranne ovviamente quando mi pokkate nhoya in teamspeak che vi fa un rm -rf e vi guarda soffrire in silenzio finche' non vi si spenga il computer perche' non ci sara' piu' nulla...
Bon si so fatte quasi le sei, basta nerdare e scrivere cose ...
Godetevi il meritato weekenddddddd!
Pertanto ovviamente non aspettatevi guide da me in questi due giorni
Ci rivedremo lunedi o martedi' con una nuova guida!
