Ultima modifica da un moderatore:
Salve popolo di inforge 
,
superato ormai il weekend e' ora di rimettersi a studiare, o almeno tentare di capire quello che si fa quando si parla di database e simili, c'eravamo lasciati a discutere di basi di dati con la progettazione concettuale,
continueremo a trattare l'argomento parlando di progettazione logica!
Vi ricordo comunque che e' buona cosa rileggersi anche le guide successive che trovate sempre all'interno di questa sezione precedute dal tag "[Guide] Basi di dati"
Bene, veniamo a noi!
La fase successiva alla progettazione concettuale, e' la progettazione logica.
L'obiettivo principale della progettazione logica e' appunto creare uno schema logico. Questo tipo di progettazione ha come input la documentazione ottenuta nella fase precedente (progettazione concettuale), in sostanza abbiamo certamente lo schema E/R ma non e' l'unico input nell'informazione di progettazione logica, abbiamo anche il "carico applicativo" e un "modello logico" di riferimento su cui basare l'intera progettazione logica e di conseguenza lo schema logico finale.
La progettazione logica passa attraverso due importanti step, lo schema concettuale realizzato nella fase precedente (quello E/R per intenderci) rappresenta e descrive nel dettaglio l'intera realta' di riferimento ma che pero', cosi' com'e' fatto, non puo' essere "convertito" in uno schema logico equivalente, per fare questo e' necessario apportare delle piccole modifiche che adesso vedremo!
Il primo passo consiste nel ristrutturare lo schema entita'/relazione acquisito, per far questo ovviamente ci sono delle operazioni da fare che comunque sono piu' o meno standard, vedremo anche questo
Il prodotto finale di questo passaggio sara' uno schema E/R ristrutturato, che verra quindi tradotto in uno schema logico finale.
Lo schema logico non sara' l'unico prodotto finale della progettazione logica, infatti avremo anche i vincoli di integrita' ed una documentazione di supporto!
Possiamo contestualizzare quanto appena letto servendoci di un'immagine che chiarira' sicuramente quanto visto
Nella fase di ristrutturazione dello schema E/R si potranno compiere determinate operazioni, in particolare si prevedono quattro tipologie di analisi/ristrutturazione:
1) Analizzare e e valutare le ridondanze, ovvero quelle informazioni contenute sotto piu' forme e contenute piu' volte all'interno dello schema stesso (possiamo ricavare un'informazione in modo diversi, ad esempio ricavarla perche e' presente come attributo in relazioni diverse, o potrebbe essere calcolata (gia' presente) con il conteggio delle occorrenze in una determinata entita', ecc..)
2) Eliminare le generalizzazioni, sostanzialmente le generalizzazioni inserite in uno schema E/R non sono direttamente traducibili in uno schema logico equivalente e non esiste una struttura che ci permetta di effettuare questa sorta di traduzione, per cui vanno eliminate.
L'eliminazione di una generalizzazione puo' procedere in tre modi diversi:
In questo caso abbiamo un'entita' padre E0 e due entita' figlie E1 ed E2.
Esistono poi due entita' E3 ed E4 poste in relazione rispettivamente con una relazione R1 con E0 ed E4, attraverso la relazione R2, con E2.
Una prima possibilita' e' quella di trasferire le proprieta' dell'entita' figlio nell'entita' padre ed aggiungere un attributo "tipo" che contraddistingua i due casi. In questo caso le n-uple in corrispondenza degli attributi delle singole entita' una volta in valore NULL (quando ci si riferisce all'altra entita').
Una traduzione di questo tipo produce uno schema abbastanza veloce:
Un'altra possibilita' e' data dall'eliminazione dell'entita' padre trasferendone gli attributi all'interno delle due identita' figlie e aggiungendo la relazione R1 sia con l'entita' E1 che con E2.
Questa traduzione e' molto conveniente quando E1 ed E2 sono molto distanti tra loro, cioe' due concetti che possono essere intuitivamente separati.
L'ultima possibilita' e' quella di tradurre la generalizzazione con delle associazioni. In questo caso si aggiungono due relazioni RG1 ed RG2 che si pongono in relazione con l'entita' padre e si aggiunge un vincolo, ovvero che un'occorrenza di E0 non puo' essere contemporaneamente posta in relazione sia con E1 sia con E2.
Bene, generalizzazioni eliminate! Torniamo a noi:
3) Abbiamo poi la necessita' di partizionare e accorpare entita' e associazioni.
Questo e' molto utile quando una entita' puo' essere espressa in concetti diversi, invece l'accorpamento e' normalmente realizzato quando vi sono due entita' poste in relazione (1,1), molto spesso in questo caso si decide di accorparle (anche se e' possibile decidere di lasciare separate le entita' e lasciare la relazione (1,1) all'interno dello schema).
4) L'ultima operazione e' quella della scelta degli identificatori principali, questa avviene secondo dei criteri di "buon senso", in particolare bisognerebbe preferire un insieme di identificatori minimo, se esistono piu' identificatori e magari esiste un identificatore costituito magari da un unico attributo sceglieremo quello, diventa tutto molto piu' semplice sia in fase di traduzione che di gestione della base di dati.
Al termine delle operazioni si ottiene quindi lo schema entita' relazione ristrutturato! Ole' :-D
Passiamo allo step successivo..
Lo schema ristrutturato verra' tradotto nello schema logico equivalente e per fare cio' e' necessario che ogni relazione contenuta nello schema E/R ristrutturato sia analizzata e tradotta nello schema logico equivalente, cioe', sappiamo che le relazioni alle entita' possono essere di tre tipi: molti a molti, uno a molti e uno a uno.
Consideriamoli singolarmente:
1) Molti a molti
Abbiamo le relazioni E1 ed E2 poste in associazione tramite la relazione R che ha un attributo a5, in tal caso (molti a molti), vengono generate tre tabelle, una per ciascuna entita' e una per l'associazione stessa. Abbiamo quindi l'entita' E1 che viene tradotta con la relazione E1 costituita dagli attributi dell'entita' E1, l'entita' E2 tradotta con la relazione E2 costituita dagli attributi dell'entita' E2 e la relazione R, una nuova relazione quindi, costituita dalle chiavi delle singole entita' e dagli eventuali attributi dell'associazione stessa.
In uno schema E/R si spera che comunque il numero di relazioni molti a molti sia molto ridotto, perche' la gestione di questo tipo di relazioni e' un po complicata, reperire informazioni attraverso schemi di questo tipo e' un po' piu' dispendioso (in termini di tempo), normalmente si spera quindi che le relazioni siano di tipo 1 a molti :-D
2) Uno a molti
In questo caso abbiamo due possibilita':
Relazione uno a molti con partecipazione obbligatoria e con partecipazione opzionale.
Vediamo innanzitutto il primo caso:
E1 e' con partecipazione obbligatoria alla relazione R e la traduzione avviene realizzando due relazioni R1 (costituita da tutti gli attributi di E1 piu' la chiave di E2 piu' gli eventuali attributi dell'associazione stessa), E2 invece e' costituita dai singoli attributi dell'entita' E2.
Con partecipazione opzionale invece:
La traduzione puo' essere di tue tipi, nel primo caso e' identica a quella del caso uno a molti (tre relazioni: la prima traduce E1, seconda E2 e si individuano nella relazione i rispettivi attributi e si aggiunge relazione R costituita dalle chiavi di E1 ed E2 e naturalmente gli eventuali attributi dell'associazione stessa), oppure possiamo tradurre la stessa relazione con due sole relazioni, normalmente da preferire poiche' c'e' una relazione in meno xD, il dispendio di tempo diminuisce quindi, in tal caso e' tradotta con una relazione E1 costituita dagli attributi di E1 piu' la chiave di E2 piu' gli eventuali attributi opzionali di R e da una relazione E2 che traduce appunto l'entita' E2, che e' costituita dai singoli attributi di E2!
3) Uno a uno
In questo caso ci sono tre possibili casi, il primo:
Con partecipazione obbligatoria per entrambe le entita'
In tal caso ci sono due possibili traduzioni simmetriche, nel primo caso si traduce con la generazione di due relazioni: E1 che traduce l'entita E2 costituita dagli attributi di E1, dalla chiave di E2 e dagli eventuali attributi di R e la seconda relazione E2 e' costituita dai soli attributi di E2
Poiche' siamo appunto in un caso simmetrico e' possibile che E2 sia costituito dagli attributi di E2 e dalla chiave di E2 e da eventuali attributi esistenti dell'associazione, ed E1 sara' costituito in questo caso dai soli attributi dell'entita' E1!
Il secondo caso invece, uno a uno prevede una partecipazione opzionale per una sola entita':
La traduzione prevede la generazione di una tabella E1 costituita dagli attributi dell'entita' E1, dalla chiave di E2 e dagli eventuali attributi di R.
E2 invece e' costituita dai soli attributi della relazione E2
Ultimo caso e' che esista una relazione sempre uno a uno ma con partecipazione opzionale per entrambe le entita':
Le prime due traduzioni sono simmetriche (uguali al caso precedente), oppure si possono generare due relazioni che traducono le due rispettive entita' E1 ed E2 con i rispettivi attributi e una nuova relazione R che traduca l'associazione R e che contenga le chiavi di E1 ed E2 piu' gli eventuali attributi della relazione stessa.
Con questo si conclude la traduzione dello schema E/R nello schema logico equivalente e si puo' procedere con la validazione dello schema, cioe' si verifica che lo schema ottenuto soddisfi determinati criteri, e' interessante capire la qualita' dello schema ottenuto!
Uno schema e' valido se le relazioni contenute in esso soddisfano determinate proprieta', tali proprieta' vengono dette "forme normali".
Ma consideriamo questa tabella:
Sono riportati i docenti che afferiscono ad un determinato dipartimento, che tengono dei corsi, ogni corso ha un determinato numero di ore e viene tenuto in una determinata aula.
Analizzando la tabella possiamo dire che un dato docente afferisce ad un unico dipartimento e dato un corso e' possibile risalire al numero di ore, indipendentemente da chi tiene il corso!
Esempio fisica1 (tenuto da docente Neri) e' costituito da 45 ore.. Un altro fisica1 (tenuto da Bianchi) ha sempre lo stesso numero di ore. In pratica e' possibile che in qualche modo un attributo definisca poi il valore di un altro attributo (oppure un insieme di attributi definisca il valore di un altro insieme di attributi), in questo caso facciamo riferimento all'attributo docente che definisce l'attributo dipartimento, quindi sostanzialmente dipartimento dipende da docenti, esistono quindi all'interno dello schema delle dipendenze, chiamate "dipendenze funzionali".
La definizione di dipendenza funzionale ve la andate a leggere su wikipedia perche' non "trovo" altre parole per spiegarla, vi lascio il link: Dipendenza funzionale - Wikipedia (leggetevela oh, non fate i furbi altrimenti mi tocca fare il copia incolla *gh*).
In questo caso esiste una dipendenza funzionale tra docente e dipartimento e tra corso e ore, esprimiamola quindi cosi':
Docente -> Dipartimento
Corso -> Ore
Ecco, la presenza di dipendenze funzionali "e' un po' na merd*", ok torniamo seri e sobri LOL, perche' rende uno schema logico di scarsa qualita', in quanto puo' creare problemi abbastanza seri ed essere causa di anomalie e ridondanze, quindi si preferisce che le relazioni non abbiano dipendenze funzionali di tipo problematico.
Se non hanno dipendenze funzionali di tipo problematico vuol dire che sono una forma normale particolare detta "forma normale di Boyce e Cood".
Una relazione r e' in forma normale di questo tipo se per ogni ciascuna dipendenza funzionale di X e Y definita su di essa, X contiene una chiave K di r, cioe' X e' superchiave per r. E' evidente quindi che esistono delle dipendenze funzionali che non creano problemi, ovvero quelle per le quali l'insieme X di attributi e' proprio superchiave per r. L'obiettivo di una progettazione logica e' quello di definire uno schema logico ma di cui le relazioni definiscano la forma normale di Boyce e Cood (letturina qui Normalizzazione (informatica) - Wikipedia che non guasta)
Anyway, per ottenere questo (se si ottengono relazioni NON in forma "normale") e' possibile procedere, con delle operazioni, alla trasformazione di Boyce e Cood, tali operazioni prendono il nome di "normalizzazioni".
La normalizzazione prevede che i vari concetti vengano separati dalla tabella, per questo motivo esistevano le dipendenze funzionali.. se separiamo i concetti realizziamo per ogni concetto una nuova relazioni cosi' da ottenere delle relazioni che soddisfino la forma normale di Boyce e Cood.
Nel nostro caso ri-prendendo in considerazione la tabella di prima adesso avremo:
Abbiamo decomposto la tabella in tre relazioni, una contiene i docenti e dipartimenti a cui afferiscono, un'altra i corsi e le ore relativi al corso stesso e l'ultima contiene i docenti, i corsi che tengono e l'aula in cui si tiene il corso. Queste tre relazioni sono in forma normale di Boyce e Cood e quindi non esistono piu' dipendenze funzionali problematiche, ole'
Vero e' pero' che non tutte le relazioni possono essere trasformate in relazioni che soddisfino la relazione normale di Boyce e Cood, attualmente (nel nostro caso di esempio) possiamo risalire a tutte le informazioni originarie, la decomposizione e' quindi senza perdita, ecco, bisognerebbe fare in modo che sia sempre senza perdita, ottenere quindi relazioni che ci permettano di risalire alle informazioni originali, ma non sempre questo e' possibile e allora bisogna essere "piu' tolleranti", bisogna che alla fine le relazioni del nostro schema siano in "terza forma normale"
Questa e' una forma meno restrittiva della Boyce e Cood!
Una relazione r e' in terza forma normale se per ogni dipendenza funzionale tra X e Y definita su di essa, e' verificata almeno una delle seguenti condizioni:
- X contiene una chiave K di r; (e in questo caso sarebbe in forma normale di Boyce e Cood)
- ogni attributo in Y e' contenuto in almeno una chiave di r. (ecco, questo rende la forma normale meno restrittiva della precedente).
Lo schema logico e' quindi di una qualita' "accettabile", se le relazioni contenute in esso sono in terza forma normale, ottenuto quindi lo schema logico dove tutte le relazioni sono in terza forma normale, allora lo schema logico potra' definirsi valido.
Oh, e diciamo anche con quest'ultima "roba" abbiamo concluso con la progettazione logica
Ci vedremo, spero presto, a leggere di un nuovo argomento!
PS: pardon se troverete qualche errore di battitura che mi sara' sfuggito, ma non ho voglia di ricontrollarla tutta nuovamente che son sfinito dopo aver fatto duemila disegnini
Ciao, ciao o/
,superato ormai il weekend e' ora di rimettersi a studiare, o almeno tentare di capire quello che si fa quando si parla di database e simili, c'eravamo lasciati a discutere di basi di dati con la progettazione concettuale,
continueremo a trattare l'argomento parlando di progettazione logica!
Vi ricordo comunque che e' buona cosa rileggersi anche le guide successive che trovate sempre all'interno di questa sezione precedute dal tag "[Guide] Basi di dati"
Bene, veniamo a noi!
La fase successiva alla progettazione concettuale, e' la progettazione logica.
L'obiettivo principale della progettazione logica e' appunto creare uno schema logico. Questo tipo di progettazione ha come input la documentazione ottenuta nella fase precedente (progettazione concettuale), in sostanza abbiamo certamente lo schema E/R ma non e' l'unico input nell'informazione di progettazione logica, abbiamo anche il "carico applicativo" e un "modello logico" di riferimento su cui basare l'intera progettazione logica e di conseguenza lo schema logico finale.
La progettazione logica passa attraverso due importanti step, lo schema concettuale realizzato nella fase precedente (quello E/R per intenderci) rappresenta e descrive nel dettaglio l'intera realta' di riferimento ma che pero', cosi' com'e' fatto, non puo' essere "convertito" in uno schema logico equivalente, per fare questo e' necessario apportare delle piccole modifiche che adesso vedremo!
Il primo passo consiste nel ristrutturare lo schema entita'/relazione acquisito, per far questo ovviamente ci sono delle operazioni da fare che comunque sono piu' o meno standard, vedremo anche questo
Il prodotto finale di questo passaggio sara' uno schema E/R ristrutturato, che verra quindi tradotto in uno schema logico finale.
Lo schema logico non sara' l'unico prodotto finale della progettazione logica, infatti avremo anche i vincoli di integrita' ed una documentazione di supporto!
Possiamo contestualizzare quanto appena letto servendoci di un'immagine che chiarira' sicuramente quanto visto
Nella fase di ristrutturazione dello schema E/R si potranno compiere determinate operazioni, in particolare si prevedono quattro tipologie di analisi/ristrutturazione:
1) Analizzare e e valutare le ridondanze, ovvero quelle informazioni contenute sotto piu' forme e contenute piu' volte all'interno dello schema stesso (possiamo ricavare un'informazione in modo diversi, ad esempio ricavarla perche e' presente come attributo in relazioni diverse, o potrebbe essere calcolata (gia' presente) con il conteggio delle occorrenze in una determinata entita', ecc..)
2) Eliminare le generalizzazioni, sostanzialmente le generalizzazioni inserite in uno schema E/R non sono direttamente traducibili in uno schema logico equivalente e non esiste una struttura che ci permetta di effettuare questa sorta di traduzione, per cui vanno eliminate.
L'eliminazione di una generalizzazione puo' procedere in tre modi diversi:
In questo caso abbiamo un'entita' padre E0 e due entita' figlie E1 ed E2.
Esistono poi due entita' E3 ed E4 poste in relazione rispettivamente con una relazione R1 con E0 ed E4, attraverso la relazione R2, con E2.
Una prima possibilita' e' quella di trasferire le proprieta' dell'entita' figlio nell'entita' padre ed aggiungere un attributo "tipo" che contraddistingua i due casi. In questo caso le n-uple in corrispondenza degli attributi delle singole entita' una volta in valore NULL (quando ci si riferisce all'altra entita').
Una traduzione di questo tipo produce uno schema abbastanza veloce:
Un'altra possibilita' e' data dall'eliminazione dell'entita' padre trasferendone gli attributi all'interno delle due identita' figlie e aggiungendo la relazione R1 sia con l'entita' E1 che con E2.
Questa traduzione e' molto conveniente quando E1 ed E2 sono molto distanti tra loro, cioe' due concetti che possono essere intuitivamente separati.
L'ultima possibilita' e' quella di tradurre la generalizzazione con delle associazioni. In questo caso si aggiungono due relazioni RG1 ed RG2 che si pongono in relazione con l'entita' padre e si aggiunge un vincolo, ovvero che un'occorrenza di E0 non puo' essere contemporaneamente posta in relazione sia con E1 sia con E2.
Bene, generalizzazioni eliminate! Torniamo a noi:
3) Abbiamo poi la necessita' di partizionare e accorpare entita' e associazioni.
Questo e' molto utile quando una entita' puo' essere espressa in concetti diversi, invece l'accorpamento e' normalmente realizzato quando vi sono due entita' poste in relazione (1,1), molto spesso in questo caso si decide di accorparle (anche se e' possibile decidere di lasciare separate le entita' e lasciare la relazione (1,1) all'interno dello schema).
4) L'ultima operazione e' quella della scelta degli identificatori principali, questa avviene secondo dei criteri di "buon senso", in particolare bisognerebbe preferire un insieme di identificatori minimo, se esistono piu' identificatori e magari esiste un identificatore costituito magari da un unico attributo sceglieremo quello, diventa tutto molto piu' semplice sia in fase di traduzione che di gestione della base di dati.
Al termine delle operazioni si ottiene quindi lo schema entita' relazione ristrutturato! Ole' :-D
Passiamo allo step successivo..
Lo schema ristrutturato verra' tradotto nello schema logico equivalente e per fare cio' e' necessario che ogni relazione contenuta nello schema E/R ristrutturato sia analizzata e tradotta nello schema logico equivalente, cioe', sappiamo che le relazioni alle entita' possono essere di tre tipi: molti a molti, uno a molti e uno a uno.
Consideriamoli singolarmente:
1) Molti a molti
Abbiamo le relazioni E1 ed E2 poste in associazione tramite la relazione R che ha un attributo a5, in tal caso (molti a molti), vengono generate tre tabelle, una per ciascuna entita' e una per l'associazione stessa. Abbiamo quindi l'entita' E1 che viene tradotta con la relazione E1 costituita dagli attributi dell'entita' E1, l'entita' E2 tradotta con la relazione E2 costituita dagli attributi dell'entita' E2 e la relazione R, una nuova relazione quindi, costituita dalle chiavi delle singole entita' e dagli eventuali attributi dell'associazione stessa.
In uno schema E/R si spera che comunque il numero di relazioni molti a molti sia molto ridotto, perche' la gestione di questo tipo di relazioni e' un po complicata, reperire informazioni attraverso schemi di questo tipo e' un po' piu' dispendioso (in termini di tempo), normalmente si spera quindi che le relazioni siano di tipo 1 a molti :-D
2) Uno a molti
In questo caso abbiamo due possibilita':
Relazione uno a molti con partecipazione obbligatoria e con partecipazione opzionale.
Vediamo innanzitutto il primo caso:
E1 e' con partecipazione obbligatoria alla relazione R e la traduzione avviene realizzando due relazioni R1 (costituita da tutti gli attributi di E1 piu' la chiave di E2 piu' gli eventuali attributi dell'associazione stessa), E2 invece e' costituita dai singoli attributi dell'entita' E2.
Con partecipazione opzionale invece:
La traduzione puo' essere di tue tipi, nel primo caso e' identica a quella del caso uno a molti (tre relazioni: la prima traduce E1, seconda E2 e si individuano nella relazione i rispettivi attributi e si aggiunge relazione R costituita dalle chiavi di E1 ed E2 e naturalmente gli eventuali attributi dell'associazione stessa), oppure possiamo tradurre la stessa relazione con due sole relazioni, normalmente da preferire poiche' c'e' una relazione in meno xD, il dispendio di tempo diminuisce quindi, in tal caso e' tradotta con una relazione E1 costituita dagli attributi di E1 piu' la chiave di E2 piu' gli eventuali attributi opzionali di R e da una relazione E2 che traduce appunto l'entita' E2, che e' costituita dai singoli attributi di E2!
3) Uno a uno
In questo caso ci sono tre possibili casi, il primo:
Con partecipazione obbligatoria per entrambe le entita'
In tal caso ci sono due possibili traduzioni simmetriche, nel primo caso si traduce con la generazione di due relazioni: E1 che traduce l'entita E2 costituita dagli attributi di E1, dalla chiave di E2 e dagli eventuali attributi di R e la seconda relazione E2 e' costituita dai soli attributi di E2
Poiche' siamo appunto in un caso simmetrico e' possibile che E2 sia costituito dagli attributi di E2 e dalla chiave di E2 e da eventuali attributi esistenti dell'associazione, ed E1 sara' costituito in questo caso dai soli attributi dell'entita' E1!
Il secondo caso invece, uno a uno prevede una partecipazione opzionale per una sola entita':
La traduzione prevede la generazione di una tabella E1 costituita dagli attributi dell'entita' E1, dalla chiave di E2 e dagli eventuali attributi di R.
E2 invece e' costituita dai soli attributi della relazione E2
Ultimo caso e' che esista una relazione sempre uno a uno ma con partecipazione opzionale per entrambe le entita':
Le prime due traduzioni sono simmetriche (uguali al caso precedente), oppure si possono generare due relazioni che traducono le due rispettive entita' E1 ed E2 con i rispettivi attributi e una nuova relazione R che traduca l'associazione R e che contenga le chiavi di E1 ed E2 piu' gli eventuali attributi della relazione stessa.
Con questo si conclude la traduzione dello schema E/R nello schema logico equivalente e si puo' procedere con la validazione dello schema, cioe' si verifica che lo schema ottenuto soddisfi determinati criteri, e' interessante capire la qualita' dello schema ottenuto!
Uno schema e' valido se le relazioni contenute in esso soddisfano determinate proprieta', tali proprieta' vengono dette "forme normali".
Ma consideriamo questa tabella:
Sono riportati i docenti che afferiscono ad un determinato dipartimento, che tengono dei corsi, ogni corso ha un determinato numero di ore e viene tenuto in una determinata aula.
Analizzando la tabella possiamo dire che un dato docente afferisce ad un unico dipartimento e dato un corso e' possibile risalire al numero di ore, indipendentemente da chi tiene il corso!
Esempio fisica1 (tenuto da docente Neri) e' costituito da 45 ore.. Un altro fisica1 (tenuto da Bianchi) ha sempre lo stesso numero di ore. In pratica e' possibile che in qualche modo un attributo definisca poi il valore di un altro attributo (oppure un insieme di attributi definisca il valore di un altro insieme di attributi), in questo caso facciamo riferimento all'attributo docente che definisce l'attributo dipartimento, quindi sostanzialmente dipartimento dipende da docenti, esistono quindi all'interno dello schema delle dipendenze, chiamate "dipendenze funzionali".
La definizione di dipendenza funzionale ve la andate a leggere su wikipedia perche' non "trovo" altre parole per spiegarla, vi lascio il link: Dipendenza funzionale - Wikipedia (leggetevela oh, non fate i furbi altrimenti mi tocca fare il copia incolla *gh*).
In questo caso esiste una dipendenza funzionale tra docente e dipartimento e tra corso e ore, esprimiamola quindi cosi':
Docente -> Dipartimento
Corso -> Ore
Ecco, la presenza di dipendenze funzionali "e' un po' na merd*", ok torniamo seri e sobri LOL, perche' rende uno schema logico di scarsa qualita', in quanto puo' creare problemi abbastanza seri ed essere causa di anomalie e ridondanze, quindi si preferisce che le relazioni non abbiano dipendenze funzionali di tipo problematico.
Se non hanno dipendenze funzionali di tipo problematico vuol dire che sono una forma normale particolare detta "forma normale di Boyce e Cood".
Una relazione r e' in forma normale di questo tipo se per ogni ciascuna dipendenza funzionale di X e Y definita su di essa, X contiene una chiave K di r, cioe' X e' superchiave per r. E' evidente quindi che esistono delle dipendenze funzionali che non creano problemi, ovvero quelle per le quali l'insieme X di attributi e' proprio superchiave per r. L'obiettivo di una progettazione logica e' quello di definire uno schema logico ma di cui le relazioni definiscano la forma normale di Boyce e Cood (letturina qui Normalizzazione (informatica) - Wikipedia che non guasta
)Anyway, per ottenere questo (se si ottengono relazioni NON in forma "normale") e' possibile procedere, con delle operazioni, alla trasformazione di Boyce e Cood, tali operazioni prendono il nome di "normalizzazioni".
La normalizzazione prevede che i vari concetti vengano separati dalla tabella, per questo motivo esistevano le dipendenze funzionali.. se separiamo i concetti realizziamo per ogni concetto una nuova relazioni cosi' da ottenere delle relazioni che soddisfino la forma normale di Boyce e Cood.
Nel nostro caso ri-prendendo in considerazione la tabella di prima adesso avremo:
Abbiamo decomposto la tabella in tre relazioni, una contiene i docenti e dipartimenti a cui afferiscono, un'altra i corsi e le ore relativi al corso stesso e l'ultima contiene i docenti, i corsi che tengono e l'aula in cui si tiene il corso. Queste tre relazioni sono in forma normale di Boyce e Cood e quindi non esistono piu' dipendenze funzionali problematiche, ole'
Vero e' pero' che non tutte le relazioni possono essere trasformate in relazioni che soddisfino la relazione normale di Boyce e Cood, attualmente (nel nostro caso di esempio) possiamo risalire a tutte le informazioni originarie, la decomposizione e' quindi senza perdita, ecco, bisognerebbe fare in modo che sia sempre senza perdita, ottenere quindi relazioni che ci permettano di risalire alle informazioni originali, ma non sempre questo e' possibile e allora bisogna essere "piu' tolleranti", bisogna che alla fine le relazioni del nostro schema siano in "terza forma normale"
Questa e' una forma meno restrittiva della Boyce e Cood!
Una relazione r e' in terza forma normale se per ogni dipendenza funzionale tra X e Y definita su di essa, e' verificata almeno una delle seguenti condizioni:
- X contiene una chiave K di r; (e in questo caso sarebbe in forma normale di Boyce e Cood)
- ogni attributo in Y e' contenuto in almeno una chiave di r. (ecco, questo rende la forma normale meno restrittiva della precedente).
Lo schema logico e' quindi di una qualita' "accettabile", se le relazioni contenute in esso sono in terza forma normale, ottenuto quindi lo schema logico dove tutte le relazioni sono in terza forma normale, allora lo schema logico potra' definirsi valido.
Oh, e diciamo anche con quest'ultima "roba" abbiamo concluso con la progettazione logica
Ci vedremo, spero presto, a leggere di un nuovo argomento!
PS: pardon se troverete qualche errore di battitura che mi sara' sfuggito, ma non ho voglia di ricontrollarla tutta nuovamente che son sfinito dopo aver fatto duemila disegnini
Ciao, ciao o/
