Ultima modifica da un moderatore:
Salve popolo di inforge
,
ben tornati a leggere il vostro poco amato syscall che anche oggi vi sfracassera' con le sue boiate.
C'eravamo lasciati parlando di modello relazionale (http://www.inforge.net/community/ma...uida-base-di-dati-il-modello-relazionale.html), quindi di tabelle e relazioni per la rappresentazione di una base di dati.
Nel post ancora precedente invece avevamo iniziato con un'introduzione sulle basi di dati ed una panoramica generale sull'argomento (http://www.inforge.net/community/ma...65181-guida-introduciamo-le-basi-di-dati.html).
Prima di proseguire con la lettura vi invito a rileggervi i due post in modo da comprendere meglio quanto leggerete adesso, ricordando comunque che e' sempre buona cosa approfondire tutti gli argomenti e i concetti che scrivo. In caso di problemi o in caso non sappiate dove reperire determinato materiale non esitate a contattarmi scrivendomi un messaggio privato, saro' ben lieto di aiutarvi a risolvere ogni genere di problema, o comunque ci si prova
Bene, iniziamo subito a trattare l'argomento di oggi, che c'ho messo un botto a scrivere perche' pur non essendo lunghissimo e' pieno di immagini che ho fatto io di sana pianta, spero apprezzerete !
Ok, basta cosi', come avevamo promesso nel post precedente parliamo di progettazione di una base di dati, ne definiremo le caratteristiche, la struttura ed i contenuti.
Diciamo subito che la progettazione di una base di dati e' articolata in tre fasi, individuiamo quindi:
- La progettazione Concettuale;
- La progettazione Logica;
- La progettazione Fisica
La progettazione va pero' inclusa all'interno di un'attivita' molto piu' complessa relativamente alla realizzazione di un sistema informativo, che include sei fasi, ed e' solo una fase di un ciclo di vita di cui adesso scriveremo.
Nella prima fase abbiamo:
- Lo studio di fattibilita', che consiste nell'individuare le possibili alternative e stabilirne i costi. Sostanzialmente dobbiamo capire se la realizzazione del sistema informativo e' "fattibile", studiandone costi e benefici.
Una volta stabilito che il sistema informativo e' fattibile e che quindi le spese sono sostenibili e i tempi di realizzazione sono accettabili si passa alla seconda fase, quale la:
- Raccolta ed analisi dei requisiti: In questa fase si studia la realta' di riferimento, si cercano di individuare le funzionalita' che il sistema informativo deve soddisfare e compiere, si cercano di capire le caratteristiche e quindi si cerca di descrivere in qualche modo la realta' di riferimento, che avviene attraverso un documento informale e si tratta di una descrizione di un documento all'interno della quale si discute proprio "a parole" della realta' di riferimento evidenziandone proprieta', caratteristiche e funzionalita' che ci si aspetta. In questa fase ovviamente ci sara' la possibilita' di interagire con gli utenti del sistema informativo stesso, facendo ad esempio dei questionari o affiancando gli operatori che lo andranno ad utilizzare, magari raccogliendo documentazioni specifiche al fine appunto di dar vita a questa relazione che sara' l'input della fase successiva, ovvero la fase di:
- Progettazione: in cui, appunto, si acquisisce il documento creato nella fase precedente e si tenta di formalizzare la descrizione della realta' di riferimento.
In questa fase formalizzeremo il tutto e sara' necessario individuare una metodologia che ci permetta di formalizzare appunto la struttura della base di dati.
Completata la fase di progettazione si passa alla successiva:
- Implementazione: nella quale saranno coinvolti i programmatori e sostanzialmente verra' creato del codice, sulla base del progetto ottenuto nella fase di progettazione.
La scrittura di codice pero' non e' immune da errori, anzi molto spesso, a suo malgrado, il programmatore introduce involontariamente dei bug all'interno del proprio codice. Normalmente non e' esso stesso che individua tali problemi ma ci saranno dei "beta tester", ovvero degli specialisti atti all'analisi del codice prodotto dai programmatori al fine appunto di trovare degli errori.
Si passa quindi alla fase successiva:
- Validazione e Collaudo: il programmatore rilascia il codice e i beta tester provvedono a collaudarlo e validarlo, cioe' analizzarlo e capire se contiene degli errori, per poi successivamente richiederne la correzione al programmatore.
Queste fasi, ovviamente, non sono necessariamente sequenziali, e' possibile che siano anche effettuate in parallelo, non bisogna aspettare il completamente di tutto il codice per iniziare a testarlo. Completata la fase di test c'e' il primo rilascio, e si procedera' con la fase successiva.
- Funzionamento: il sistema sara' utilizzato dai vari utenti ed operatori.
Anche in questa fase si potranno individuare ancora degli errori, e pertanto distinguiamo due modalita' di manutenzione:
+ Manutenzione riparativa: che consiste nel riparare gli errori sfuggiti durante la fase di testing (validazione e collaudo)
+ Manutenzione migliorativa: che consiste nell'aggiungere ulteriori funzionalita' non previste durante la fase di progettazione, ma che sono comunque utili ed eventualmente migliorare anche quelle esistenti in termini di prestazioni.
Non affronteremo tutto il ciclo di vita dei sistemi informativi, perche' come da titolo ci concentreremo solo sulla fase di progettazione!
Questa fase si articola in tre tipologie di progetto, in particolare individuiamo:
- progetto concettuale
- progetto logico
- progetto zare la realta' i riferimento all'interno dello schema.
Nella sotto fase di progettazione concettuale il progettista tentera' di formalizzare la realta' di riferimento attraverso strumenti e metodologie particolari.
Il risultato della progettazione concettuale sara' uno schema concettuale che si basa sul modello concettuale.
Durante la progettazione concettuale, il progettista non si cura minimamente di dove e come sara' implementate la base di dati. Lo schema concettuale sara' l'input per la progettazione logica e, durante questa, il progettista cerchera' di tradurre lo schema concettuale in uno schema logico, basandosi su uno schema logico! Nel nostro caso ci baseremo sul modello relazionale che abbiamo visto nel post precedente che, qualora non lo abbiate ancora fatto, vi invito a leggere!
A termine della progettazione logica si otterra' uno schema logico, che nella progettazione fisica verra' corredato da dei parametri fisici per la descrizione e implementazione della nostra base di dati.
Con la progettazione fisica si conclude la progettazione della base di dati.
Il prodotto della progettazione concettuale e' dunque uno schema concettuale che si basa su un modello concettuale. Quest'ultimo, al fine di realizzare lo schema, deve fornire dei costrutti atti a schematizzare la realta' di riferimento all'interno dello schema.
Lo schema concettuale non fa altro che descrivere la struttura e l'organizzazione delle occorrenze della base di dati. Le occorrenze sono l'insieme dei valori esistenti all'interno di una base di dati in un determinato momento.
I costrutti sono di vario tipo, vediamoli singolarmente e con qualche esempio per semplificarne la comprensione (ps: tutte le immagini le ho fatte io, in rete potreste trovarle un po diverse, ma comunque queste sono, avevo voglia di farle cosi e bon)
Innanzitutto individuiamo il costrutto "entita'"
Questo, rappresenta una classe di oggetti, individuata all'interno della realta' di riferimento.
Se ad esempio stiamo progettando una base di dati per gestire una universita', e' possibile che le entita' di riferimento saranno ad esempio i docenti, gli studenti, i corsi; ovviamente le entita' hanno un nome e vengono rappresentate come vedete in figura, da un rettangolo, all'interno del quale ci andra' un nome!
Se vogliamo progettare ad esempio una base di dati per una biblioteca, dall'analisi, discende che esistera' un'entita' autori e un'entita' libri che potrebbero avere determinati valori, ad esempio autori: "autore1, autore2" (occorrenza dell'entita' autori), nei libri invece "titolo_libro1, titolo_libro2", e cosi' via...
Autori e libri sono dunque delle entita' che in qualche modo sono descritti da proprieta', il modello entita' relazione ci permette di descrivere le proprieta' delle varie entita' attraverso un costrutto specifico, definito attributi:
Un autore, ad esempio, e' descritto dal Nome, Cognome, Nazionalita' e quel che vogliamo!
Gli attributi vengono collegati all'entita' di riferimento e quindi l'insieme degli attributi e dell'entita' stessa descrive una porzione della nostra base di dati.
Tra le varie entita' possono sussistere dei legami logici, che vengono definiti relazioni o associazioni:
Una relazione non e' altro che un collegamento logico tra due o piu' entita'! Nel caso in cui l'associazione collega due entita' si parla di "relazione binaria".
La relazione viene rappresentata come un rombo all'interno del quale si scrive il nome della relazione, ed e' possibile che abbia degli attributi, potremmo chiamarla, rifacendoci al nostro esempio, "prodotto".
Ovvero, l'autore ha prodotto dei libri e quest'ultimi sono stati prodotti da vari autori.
Una relazione potrebbe essere anche rappresentata attraverso due insiemi e dal legame che esiste tra gli elementi di un insieme e gli elementi dell'altro, ad esempio, in questo caso vediamo che un autore ha scritto due libri, ad esempio, un altro un libro soltanto e via dicendo!
Notiamo che un'associazione e' di fatto un sotto insieme del prodotto cartesiano delle occorrenze delle entita'. Sostanzialmente quindi un'associazione e' una relazione matematica!
Consideriamo infine che, i vari attributi, possono essere raggruppati e, in tal caso, si parla di attributo composto:
Un attributo composto ad esempio potrebbe essere dato dal "domicilio", costituito dagli attributi: via, cap e citta':
Quelli che abbiam visto sino ad ora, ovvero entita', relazione, attributo e attributo composto, sono i costrutti principali del modello entita' relazione che sono comunque gia' sufficienti per descrivere e schematizzare a livello concettuale anche realta' di riferimento piuttosto complesse, diciamo infine che le relazioni possono essere tra due o piu' entita' ma si possono avere anche relazioni ricorsive, sulla stessa entita'. Facciamo un esempio:
Se noi andiamo a considerare ad esempio una classe di studenti, sull'entita' potrebbe esserci una relazione di tipo ricorsivo, cioe' sulla stessa entita' studenti, che chiamiamo "compagno", cioe' in una realta' di riferimento in cui definiamo una classe di studenti, nella stessa classe ci sono definiti anche i compagni di scuola.
Completiamo il quadro relativo allo schema concettuale e al modello concettuale, in particolare entita' relazione, prendendo in considerazione i costrutti rimanenti ed in particolare vediamo: il costrutto cardinalita':
Puo' essere di tue tipi, minima e massima.
Sostanzialmente la cardinalita' minima e massima rappresentano rispettivamente il numero di volte minimo e massimo che un'occorrenza puo' partecipare ad una determinata relazione. Sostanzialmente indicano quindi quante volte e' possibile ritrovare quella determinata occorrenza coinvolta all'interno della relazione, ma facciamo subito un'esempio per comprendere al meglio quello che abbiam appena detto!
In questo caso vediamo coinvolte due entita': studente e tesi.
Tra studente e tesi esiste una relazione "lavoro".
Chiaramente, uno studente potrebbe ancora non aver fatto la tesi, e questo significa che potrebbe non essere quel determinato studente, quindi una determinata occorrenza potrebbe essere coinvolta nessuna volta nella relazione lavoro, in questo caso indichiamo la cardinalita' minima 0! Se invece uno studente ha fatto la tesi, normalmente dovrebbe averne 1 soltanto, per cui, la cardinalita' massima (cioe' il numero di volte che l'occorrenza studente puo' essere al massimo coinvolta nella relazione lavoro della tesi) e' 1.
Dall'altra parte possiamo andare ad analizzare il numero di volte in cui un'occorrenza di tesi e' coinvolta nella relazione lavoro. Se una tesi esiste deve essere almeno di 1 studente, e se esiste, e' al massimo e' di 1 studente (se diciamo ovviamente che uno studente fa una tesi e una tesi e' fatta solo da uno studente!).
In questo caso abbiamo quindi impostato la cardinalita' minima e massima per le occorrenze studente coinvolte nella relazione lavoro e per le occorrenze di tesi coinvolte nella stessa relazione.
Possiamo continuare l'esempio immaginando sempre un'entita' studente e l'entita' esami.
In tal caso, tra studente ed esami, esistera' una relazione "prova" (la prova d'esame appunto).
Uno studente potrebbe esser appena iscritto, e quindi non aver sostenuto alcun esame, quindi ha una cardinalita' minima 0, al massimo invece potra' averne sostenuto quanti ne prevede il suo dato corso di studio, facciamo essere 30.
Viceversa, un determinato esame, se c'e', e' stato sostenuto da uno ed un solo studente.
Infine, teniamo presente che, quando parliamo di esame, stiamo parlando dell'entita' descritta dalle proprieta': data, voto, titolo, domande fatte, ecc.., s(i parla quindi di un determinato esame sostenuto da un determinato studente).
Infine, possiamo prendere le entita' studente da un altro e corsi dall'altro.
In questo caso uno studente, se iscritto, segue un determinato corso ed al massimo ne seguira' 30, quanti sono gli esami da sostenere, con relazione "frequenza".
Un corso invece sara' seguito al limite da uno studente ed al massimo dal numero di tutti gli iscritti a quel dato corso di laurea per quel dato anno, ad esempio 200!
In genere, la cardinalita' massima, non viene specificata da un numero specifico ma indicata con "m" o "n".
La cardinalita' minima normalmente non si prende in considerazione e si classificano le varie relazioni in funzione della cardinalita' massima delle due entita' poste in relazione. Nel caso della prima immagine (relazione lavoro), e' di tipo 1 a 1 (1:1), poiche' uno studente ha una tesi specifica e quella tesi e' di quel determinato studente.
Nel secondo caso: lo studente ha sostenuto n esami e quell'esame e' sostenuto da un solo studente. Quindi in questo caso la relazione e' uno a molti (1:n)
Infine, nella terza abbiamo una relazione di tipo n a m (n:m).
Normalmente, quando si realizza uno schema concettuale, si tende a ridefinire lo schema in modo tale che le relazioni siano ricondotte tutte a queste tre tipologie, ricordatevelo
Oltre alle cardinalita' di relazione esistono anche le cardinalita' di attributo, che indicano il numero di valori che un attributo puo' avere.
Facciamo un esempio:
Se prendiamo in considerazione una persona, questa potrebbe avere ad esempio tre attributi, un cognome, una patente e una targa di un qualche mezzo.
- L'attributo cognome sara' un attributo obbligatorio, che avra' cardinalita' 1:1 (quando la cardinalita' minima e massima sono 1, in genere, si omette).
- Invece, la patente potra' non averla, ma se ce l'ha e' solo una (intenso come solo un numero di patente).
- Infine, per quanto riguarda il mezzo, potrebbe non averne o averne n.
Quando la cardinalita' minima e' 0 l'attributo e' opzionale, quando e' 1 e' obbligatorio. Quando invece la cardinalita' massimo e' n siamo di fronte ad un attributo multi valore.
Quest'ultimi sono un po "delicati" generalmente si tende di sostituirli con nuove entita' poste in relazione con l'entita'' da cui l'attributo viene estratto!
Completiamo il quadro relativo ai costrutti dello schema concettuale del modello entita' relazione (stanchi?), osservando gli utlimi due!:
Parliamo dei costrutti: identificatore delle entita', e del costrutto generalizzazione.
L'identificatore delle entita' e' un costrutto estremamente importante, ogni entita' deve avere un identificatore, che e' costituito da uno o piu' attributi dati i quali si possono ricavare le altre informazioni... ricordate il concetto di chiave di cui abbiamo parlato nel post precedente?!?
Tante' che, nel caso in cui l'identificatore e' costituito da uno o piu' attributi contenuti nella stessa entita', si parla proprio di identificatore interno o chiave.
L'identificatore, nel caso in cui sia costituito da un unico attributo, si rappresenta con il costrutto dell'attributo ma con un pallino pieno. Invece, quando non e' sufficiente un unico attributo per descrivere l'identificatore, allora il costrutto si descrive selezionandoli con una linea che coinvolge le proprieta' appartenenti all'identificatore ed un pallino pieno che rappresenta appunto l'identificatore stesso!
Possiamo fare un esempio andando a considerare l'entita' studente, che potrebbe essere descritto dalle proprieta': matricola, nome, cognome, data di nascita, e cosi' via..
E' chiaro che in un caso del genere l'identificatore potrebbe essere la matricola, quindi trasformeremo il costrutto di attributo in identificatore delle entita'!
Questa scelta e' ovviamente funzionale nel caso in cui stesso descrivendo gli studenti di un'unica universita'. Se dobbiamo gestire piu' studenti, di piu' univerrsita' all'interno della base dati, ci sara' una relazione di appartenenza ad una universita', esistera' quindi l'entita' universita' e l'entita' studenti.
La scelta della matricola nel nostro caso ovviamente non e' la soluzione migliore, poiche' ad universita' differenti potrebbero corrispondere matricole uguali, pertanto l'esempio della matricola non e' piu' un elemento identificativo in quanto appunto potrebbe non essere univoco!
In tal caso, il problema si risolve coinvolgendo l'entita' universita'.
Quando non abbiamo la possibilita' di individuare all'interno della stessa entita' uno o piu' attributi per descrivere l'identificatore e dobbiamo coinvolgere una entita' esterna, si parla di identificatore esterno. (che sarebbe il secondo disegnino dell'immagine sopra, non quello subito sopra, quello ancora :°D, o son cotto co sti disegni non ci sto piu' a capi nulla manco io ahahah), si vabe va, lo riposto e famo prima, il secondo di questa immagine:
Realizzato lo schema concettuale e' fondamentale individuare per ciascuna identita' i vari identificatori, gli identificatori sono fondamentali (chiavi), e servono per individuare in maniera univoca l'occorrenza all'interno dell'identita' stessa.
Siam quasi alla fine! Un ultimo sforzo, susu!
L'ultimo costrutto e' invece il costrutto generalizzazione (vedi ultima parte dell'immagine subito sopra)
Una generalizzazione e' una relazione logica fra entita', in particolare e' un collegamento logico fra un'entita' generale e delle entita' specifiche.
Un esempio e' il seguente:
Immaginiamo d'avere l'entita' persona, che puo' essere specializzata nell'entita' uomo e donna (generalizzazione dell'entita' uomo e donna), viceversa le entita' uomo e donna saranno specializzazione dell'entita' persona!
Nella fattispecie, il costrutto relativo alla generalizzazione, si rappresentera' in questo modo:
Valgono naturalmente alcune regole, in particolare se consideriamo la specializzazione, ciascuna possiede le stesse proprieta' della generalizzazione quindi, le proprieta' di persona sono anche proprieta' della specializzazione donna, e questo e' sostanzialmente dovuto alla proprieta' di ereditarieta'.
La seconda regola e' che una occorrenza di una specializzazione e' anche un'occorrenza della generalizzazione!
Bene, anche per oggi abbiamo concluso, la prossima volta, se riesco, parleremo di progettazione concettuale, intanto godetevi i tre post sulle basi di dati e, per qualsiasi cosa, come al solito, non esitate a contattarmi tramite messaggio privato!
PS: Scusate se trovate qualche piccolo errore di battitura durante la lettura di TUTTE le mie guide, in genere ci metto ore a scriverne ognuna e alla fine quando ho finito la voglia di ricontrollare i singoli paragrafi e' pari a 0, in genere do una ripassata in blocco a tutte dopo qualche giorno...
Ciao, ciao o/
,ben tornati a leggere il vostro poco amato syscall che anche oggi vi sfracassera' con le sue boiate.
C'eravamo lasciati parlando di modello relazionale (http://www.inforge.net/community/ma...uida-base-di-dati-il-modello-relazionale.html), quindi di tabelle e relazioni per la rappresentazione di una base di dati.
Nel post ancora precedente invece avevamo iniziato con un'introduzione sulle basi di dati ed una panoramica generale sull'argomento (http://www.inforge.net/community/ma...65181-guida-introduciamo-le-basi-di-dati.html).
Prima di proseguire con la lettura vi invito a rileggervi i due post in modo da comprendere meglio quanto leggerete adesso, ricordando comunque che e' sempre buona cosa approfondire tutti gli argomenti e i concetti che scrivo. In caso di problemi o in caso non sappiate dove reperire determinato materiale non esitate a contattarmi scrivendomi un messaggio privato, saro' ben lieto di aiutarvi a risolvere ogni genere di problema, o comunque ci si prova
Ok, basta cosi', come avevamo promesso nel post precedente parliamo di progettazione di una base di dati, ne definiremo le caratteristiche, la struttura ed i contenuti.
Diciamo subito che la progettazione di una base di dati e' articolata in tre fasi, individuiamo quindi:
- La progettazione Concettuale;
- La progettazione Logica;
- La progettazione Fisica
La progettazione va pero' inclusa all'interno di un'attivita' molto piu' complessa relativamente alla realizzazione di un sistema informativo, che include sei fasi, ed e' solo una fase di un ciclo di vita di cui adesso scriveremo.
Nella prima fase abbiamo:
- Lo studio di fattibilita', che consiste nell'individuare le possibili alternative e stabilirne i costi. Sostanzialmente dobbiamo capire se la realizzazione del sistema informativo e' "fattibile", studiandone costi e benefici.
Una volta stabilito che il sistema informativo e' fattibile e che quindi le spese sono sostenibili e i tempi di realizzazione sono accettabili si passa alla seconda fase, quale la:
- Raccolta ed analisi dei requisiti: In questa fase si studia la realta' di riferimento, si cercano di individuare le funzionalita' che il sistema informativo deve soddisfare e compiere, si cercano di capire le caratteristiche e quindi si cerca di descrivere in qualche modo la realta' di riferimento, che avviene attraverso un documento informale e si tratta di una descrizione di un documento all'interno della quale si discute proprio "a parole" della realta' di riferimento evidenziandone proprieta', caratteristiche e funzionalita' che ci si aspetta. In questa fase ovviamente ci sara' la possibilita' di interagire con gli utenti del sistema informativo stesso, facendo ad esempio dei questionari o affiancando gli operatori che lo andranno ad utilizzare, magari raccogliendo documentazioni specifiche al fine appunto di dar vita a questa relazione che sara' l'input della fase successiva, ovvero la fase di:
- Progettazione: in cui, appunto, si acquisisce il documento creato nella fase precedente e si tenta di formalizzare la descrizione della realta' di riferimento.
In questa fase formalizzeremo il tutto e sara' necessario individuare una metodologia che ci permetta di formalizzare appunto la struttura della base di dati.
Completata la fase di progettazione si passa alla successiva:
- Implementazione: nella quale saranno coinvolti i programmatori e sostanzialmente verra' creato del codice, sulla base del progetto ottenuto nella fase di progettazione.
La scrittura di codice pero' non e' immune da errori, anzi molto spesso, a suo malgrado, il programmatore introduce involontariamente dei bug all'interno del proprio codice. Normalmente non e' esso stesso che individua tali problemi ma ci saranno dei "beta tester", ovvero degli specialisti atti all'analisi del codice prodotto dai programmatori al fine appunto di trovare degli errori.
Si passa quindi alla fase successiva:
- Validazione e Collaudo: il programmatore rilascia il codice e i beta tester provvedono a collaudarlo e validarlo, cioe' analizzarlo e capire se contiene degli errori, per poi successivamente richiederne la correzione al programmatore.
Queste fasi, ovviamente, non sono necessariamente sequenziali, e' possibile che siano anche effettuate in parallelo, non bisogna aspettare il completamente di tutto il codice per iniziare a testarlo. Completata la fase di test c'e' il primo rilascio, e si procedera' con la fase successiva.
- Funzionamento: il sistema sara' utilizzato dai vari utenti ed operatori.
Anche in questa fase si potranno individuare ancora degli errori, e pertanto distinguiamo due modalita' di manutenzione:
+ Manutenzione riparativa: che consiste nel riparare gli errori sfuggiti durante la fase di testing (validazione e collaudo)
+ Manutenzione migliorativa: che consiste nell'aggiungere ulteriori funzionalita' non previste durante la fase di progettazione, ma che sono comunque utili ed eventualmente migliorare anche quelle esistenti in termini di prestazioni.
Non affronteremo tutto il ciclo di vita dei sistemi informativi, perche' come da titolo ci concentreremo solo sulla fase di progettazione!
Questa fase si articola in tre tipologie di progetto, in particolare individuiamo:
- progetto concettuale
- progetto logico
- progetto zare la realta' i riferimento all'interno dello schema.
Nella sotto fase di progettazione concettuale il progettista tentera' di formalizzare la realta' di riferimento attraverso strumenti e metodologie particolari.
Il risultato della progettazione concettuale sara' uno schema concettuale che si basa sul modello concettuale.
Durante la progettazione concettuale, il progettista non si cura minimamente di dove e come sara' implementate la base di dati. Lo schema concettuale sara' l'input per la progettazione logica e, durante questa, il progettista cerchera' di tradurre lo schema concettuale in uno schema logico, basandosi su uno schema logico! Nel nostro caso ci baseremo sul modello relazionale che abbiamo visto nel post precedente che, qualora non lo abbiate ancora fatto, vi invito a leggere!
A termine della progettazione logica si otterra' uno schema logico, che nella progettazione fisica verra' corredato da dei parametri fisici per la descrizione e implementazione della nostra base di dati.
Con la progettazione fisica si conclude la progettazione della base di dati.
Il prodotto della progettazione concettuale e' dunque uno schema concettuale che si basa su un modello concettuale. Quest'ultimo, al fine di realizzare lo schema, deve fornire dei costrutti atti a schematizzare la realta' di riferimento all'interno dello schema.
Lo schema concettuale non fa altro che descrivere la struttura e l'organizzazione delle occorrenze della base di dati. Le occorrenze sono l'insieme dei valori esistenti all'interno di una base di dati in un determinato momento.
I costrutti sono di vario tipo, vediamoli singolarmente e con qualche esempio per semplificarne la comprensione (ps: tutte le immagini le ho fatte io, in rete potreste trovarle un po diverse, ma comunque queste sono, avevo voglia di farle cosi e bon
)Innanzitutto individuiamo il costrutto "entita'"
Questo, rappresenta una classe di oggetti, individuata all'interno della realta' di riferimento.
Se ad esempio stiamo progettando una base di dati per gestire una universita', e' possibile che le entita' di riferimento saranno ad esempio i docenti, gli studenti, i corsi; ovviamente le entita' hanno un nome e vengono rappresentate come vedete in figura, da un rettangolo, all'interno del quale ci andra' un nome!
Se vogliamo progettare ad esempio una base di dati per una biblioteca, dall'analisi, discende che esistera' un'entita' autori e un'entita' libri che potrebbero avere determinati valori, ad esempio autori: "autore1, autore2" (occorrenza dell'entita' autori), nei libri invece "titolo_libro1, titolo_libro2", e cosi' via...
Autori e libri sono dunque delle entita' che in qualche modo sono descritti da proprieta', il modello entita' relazione ci permette di descrivere le proprieta' delle varie entita' attraverso un costrutto specifico, definito attributi:
Un autore, ad esempio, e' descritto dal Nome, Cognome, Nazionalita' e quel che vogliamo!
Gli attributi vengono collegati all'entita' di riferimento e quindi l'insieme degli attributi e dell'entita' stessa descrive una porzione della nostra base di dati.
Tra le varie entita' possono sussistere dei legami logici, che vengono definiti relazioni o associazioni:
Una relazione non e' altro che un collegamento logico tra due o piu' entita'! Nel caso in cui l'associazione collega due entita' si parla di "relazione binaria".
La relazione viene rappresentata come un rombo all'interno del quale si scrive il nome della relazione, ed e' possibile che abbia degli attributi, potremmo chiamarla, rifacendoci al nostro esempio, "prodotto".
Ovvero, l'autore ha prodotto dei libri e quest'ultimi sono stati prodotti da vari autori.
Una relazione potrebbe essere anche rappresentata attraverso due insiemi e dal legame che esiste tra gli elementi di un insieme e gli elementi dell'altro, ad esempio, in questo caso vediamo che un autore ha scritto due libri, ad esempio, un altro un libro soltanto e via dicendo!
Notiamo che un'associazione e' di fatto un sotto insieme del prodotto cartesiano delle occorrenze delle entita'. Sostanzialmente quindi un'associazione e' una relazione matematica!
Consideriamo infine che, i vari attributi, possono essere raggruppati e, in tal caso, si parla di attributo composto:
Un attributo composto ad esempio potrebbe essere dato dal "domicilio", costituito dagli attributi: via, cap e citta':
Quelli che abbiam visto sino ad ora, ovvero entita', relazione, attributo e attributo composto, sono i costrutti principali del modello entita' relazione che sono comunque gia' sufficienti per descrivere e schematizzare a livello concettuale anche realta' di riferimento piuttosto complesse, diciamo infine che le relazioni possono essere tra due o piu' entita' ma si possono avere anche relazioni ricorsive, sulla stessa entita'. Facciamo un esempio:
Se noi andiamo a considerare ad esempio una classe di studenti, sull'entita' potrebbe esserci una relazione di tipo ricorsivo, cioe' sulla stessa entita' studenti, che chiamiamo "compagno", cioe' in una realta' di riferimento in cui definiamo una classe di studenti, nella stessa classe ci sono definiti anche i compagni di scuola.
Completiamo il quadro relativo allo schema concettuale e al modello concettuale, in particolare entita' relazione, prendendo in considerazione i costrutti rimanenti ed in particolare vediamo: il costrutto cardinalita':
Puo' essere di tue tipi, minima e massima.
Sostanzialmente la cardinalita' minima e massima rappresentano rispettivamente il numero di volte minimo e massimo che un'occorrenza puo' partecipare ad una determinata relazione. Sostanzialmente indicano quindi quante volte e' possibile ritrovare quella determinata occorrenza coinvolta all'interno della relazione, ma facciamo subito un'esempio per comprendere al meglio quello che abbiam appena detto!
In questo caso vediamo coinvolte due entita': studente e tesi.
Tra studente e tesi esiste una relazione "lavoro".
Chiaramente, uno studente potrebbe ancora non aver fatto la tesi, e questo significa che potrebbe non essere quel determinato studente, quindi una determinata occorrenza potrebbe essere coinvolta nessuna volta nella relazione lavoro, in questo caso indichiamo la cardinalita' minima 0! Se invece uno studente ha fatto la tesi, normalmente dovrebbe averne 1 soltanto, per cui, la cardinalita' massima (cioe' il numero di volte che l'occorrenza studente puo' essere al massimo coinvolta nella relazione lavoro della tesi) e' 1.
Dall'altra parte possiamo andare ad analizzare il numero di volte in cui un'occorrenza di tesi e' coinvolta nella relazione lavoro. Se una tesi esiste deve essere almeno di 1 studente, e se esiste, e' al massimo e' di 1 studente (se diciamo ovviamente che uno studente fa una tesi e una tesi e' fatta solo da uno studente!).
In questo caso abbiamo quindi impostato la cardinalita' minima e massima per le occorrenze studente coinvolte nella relazione lavoro e per le occorrenze di tesi coinvolte nella stessa relazione.
Possiamo continuare l'esempio immaginando sempre un'entita' studente e l'entita' esami.
In tal caso, tra studente ed esami, esistera' una relazione "prova" (la prova d'esame appunto).
Uno studente potrebbe esser appena iscritto, e quindi non aver sostenuto alcun esame, quindi ha una cardinalita' minima 0, al massimo invece potra' averne sostenuto quanti ne prevede il suo dato corso di studio, facciamo essere 30.
Viceversa, un determinato esame, se c'e', e' stato sostenuto da uno ed un solo studente.
Infine, teniamo presente che, quando parliamo di esame, stiamo parlando dell'entita' descritta dalle proprieta': data, voto, titolo, domande fatte, ecc.., s(i parla quindi di un determinato esame sostenuto da un determinato studente).
Infine, possiamo prendere le entita' studente da un altro e corsi dall'altro.
In questo caso uno studente, se iscritto, segue un determinato corso ed al massimo ne seguira' 30, quanti sono gli esami da sostenere, con relazione "frequenza".
Un corso invece sara' seguito al limite da uno studente ed al massimo dal numero di tutti gli iscritti a quel dato corso di laurea per quel dato anno, ad esempio 200!
In genere, la cardinalita' massima, non viene specificata da un numero specifico ma indicata con "m" o "n".
La cardinalita' minima normalmente non si prende in considerazione e si classificano le varie relazioni in funzione della cardinalita' massima delle due entita' poste in relazione. Nel caso della prima immagine (relazione lavoro), e' di tipo 1 a 1 (1:1), poiche' uno studente ha una tesi specifica e quella tesi e' di quel determinato studente.
Nel secondo caso: lo studente ha sostenuto n esami e quell'esame e' sostenuto da un solo studente. Quindi in questo caso la relazione e' uno a molti (1:n)
Infine, nella terza abbiamo una relazione di tipo n a m (n:m).
Normalmente, quando si realizza uno schema concettuale, si tende a ridefinire lo schema in modo tale che le relazioni siano ricondotte tutte a queste tre tipologie, ricordatevelo
Oltre alle cardinalita' di relazione esistono anche le cardinalita' di attributo, che indicano il numero di valori che un attributo puo' avere.
Facciamo un esempio:
Se prendiamo in considerazione una persona, questa potrebbe avere ad esempio tre attributi, un cognome, una patente e una targa di un qualche mezzo.
- L'attributo cognome sara' un attributo obbligatorio, che avra' cardinalita' 1:1 (quando la cardinalita' minima e massima sono 1, in genere, si omette).
- Invece, la patente potra' non averla, ma se ce l'ha e' solo una (intenso come solo un numero di patente).
- Infine, per quanto riguarda il mezzo, potrebbe non averne o averne n.
Quando la cardinalita' minima e' 0 l'attributo e' opzionale, quando e' 1 e' obbligatorio. Quando invece la cardinalita' massimo e' n siamo di fronte ad un attributo multi valore.
Quest'ultimi sono un po "delicati" generalmente si tende di sostituirli con nuove entita' poste in relazione con l'entita'' da cui l'attributo viene estratto!
Completiamo il quadro relativo ai costrutti dello schema concettuale del modello entita' relazione (stanchi?), osservando gli utlimi due!:
Parliamo dei costrutti: identificatore delle entita', e del costrutto generalizzazione.
L'identificatore delle entita' e' un costrutto estremamente importante, ogni entita' deve avere un identificatore, che e' costituito da uno o piu' attributi dati i quali si possono ricavare le altre informazioni... ricordate il concetto di chiave di cui abbiamo parlato nel post precedente?!?
Tante' che, nel caso in cui l'identificatore e' costituito da uno o piu' attributi contenuti nella stessa entita', si parla proprio di identificatore interno o chiave.
L'identificatore, nel caso in cui sia costituito da un unico attributo, si rappresenta con il costrutto dell'attributo ma con un pallino pieno. Invece, quando non e' sufficiente un unico attributo per descrivere l'identificatore, allora il costrutto si descrive selezionandoli con una linea che coinvolge le proprieta' appartenenti all'identificatore ed un pallino pieno che rappresenta appunto l'identificatore stesso!
Possiamo fare un esempio andando a considerare l'entita' studente, che potrebbe essere descritto dalle proprieta': matricola, nome, cognome, data di nascita, e cosi' via..
E' chiaro che in un caso del genere l'identificatore potrebbe essere la matricola, quindi trasformeremo il costrutto di attributo in identificatore delle entita'!
Questa scelta e' ovviamente funzionale nel caso in cui stesso descrivendo gli studenti di un'unica universita'. Se dobbiamo gestire piu' studenti, di piu' univerrsita' all'interno della base dati, ci sara' una relazione di appartenenza ad una universita', esistera' quindi l'entita' universita' e l'entita' studenti.
La scelta della matricola nel nostro caso ovviamente non e' la soluzione migliore, poiche' ad universita' differenti potrebbero corrispondere matricole uguali, pertanto l'esempio della matricola non e' piu' un elemento identificativo in quanto appunto potrebbe non essere univoco!
In tal caso, il problema si risolve coinvolgendo l'entita' universita'.
Quando non abbiamo la possibilita' di individuare all'interno della stessa entita' uno o piu' attributi per descrivere l'identificatore e dobbiamo coinvolgere una entita' esterna, si parla di identificatore esterno. (che sarebbe il secondo disegnino dell'immagine sopra, non quello subito sopra, quello ancora :°D, o son cotto co sti disegni non ci sto piu' a capi nulla manco io ahahah), si vabe va, lo riposto e famo prima, il secondo di questa immagine:
Siam quasi alla fine! Un ultimo sforzo, susu!
L'ultimo costrutto e' invece il costrutto generalizzazione (vedi ultima parte dell'immagine subito sopra)
Una generalizzazione e' una relazione logica fra entita', in particolare e' un collegamento logico fra un'entita' generale e delle entita' specifiche.
Un esempio e' il seguente:
Immaginiamo d'avere l'entita' persona, che puo' essere specializzata nell'entita' uomo e donna (generalizzazione dell'entita' uomo e donna), viceversa le entita' uomo e donna saranno specializzazione dell'entita' persona!
Nella fattispecie, il costrutto relativo alla generalizzazione, si rappresentera' in questo modo:
Valgono naturalmente alcune regole, in particolare se consideriamo la specializzazione, ciascuna possiede le stesse proprieta' della generalizzazione quindi, le proprieta' di persona sono anche proprieta' della specializzazione donna, e questo e' sostanzialmente dovuto alla proprieta' di ereditarieta'.
La seconda regola e' che una occorrenza di una specializzazione e' anche un'occorrenza della generalizzazione!
Bene, anche per oggi abbiamo concluso, la prossima volta, se riesco, parleremo di progettazione concettuale, intanto godetevi i tre post sulle basi di dati e, per qualsiasi cosa, come al solito, non esitate a contattarmi tramite messaggio privato!
PS: Scusate se trovate qualche piccolo errore di battitura durante la lettura di TUTTE le mie guide, in genere ci metto ore a scriverne ognuna e alla fine quando ho finito la voglia di ricontrollare i singoli paragrafi e' pari a 0, in genere do una ripassata in blocco a tutte dopo qualche giorno...
Ciao, ciao o/
