Il diagramma seguente è un modello logico relazionale che rappresenta alcuni aspetti della gestione dei conti dei clienti di una banca.
Usiamo il diagramma precedente per richiamare i concetti principali dei modelli logici relazionali:
- le tabelle del modello sono rappresentate da rettangoli; il diagramma contiene le seguenti tabelle: Cliente, IntestazioneConto (è prevista la possibilità di cointestare i conti), Conto, Movimento, TesseraBancomat, ContoDiRisparmio (per depositi di risparmio), ContoCorrente (prevede la possibilità di usare una tessera Bancomat e di disporre di un fido);
- ogni tabella è caratterizzata da una o più colonne, elencate all’interno del riquadro associato alla tabella stessa; ad esempio, le colonne di Cliente sono: CodiceCliente, CodiceFiscale, Nome, Cognome, Indirizzo;
- le colonne che individuano in modo univoco una riga di una tabella (campi chiave) sono elencate all’inizio del riquadro della tabella, e sono separate dalle altre colonne da una linea orizzontale; ad esempio: la chiave di Cliente è CodiceCliente; la chiave di IntestazioneConto è formata dalla coppia di colonne CodiceCliente e NumeroConto;
- una freccia che collega due tabelle indica l’esistenza di una dipendenza tra le due tabelle (ovvero, tra alcuni campi delle due tabelle); ad esempio, la freccia che collega Movimento a Conto indica che Movimento dipende da Conto; ovvero, che Movimento ha, come chiave esterna, la colonna NumeroConto della tabella Conto.
Dal punto di vista della Function Point Analysis, ognuna delle entità di un modello logico relazionale rappresenta un gruppo logico di dati visibili all’utente finale dell’applicazione, cioè un RET (Record Element Type). Vale quindi il seguente criterio generale:
Ad ogni tabella di un modello logico relazionale deve corrispondere un RET del modello FPA.
Nel diagramma del nostro esempio possiamo quindi individuare i RET: Cliente, IntestazioneConto, Conto, Movimento, TesseraBancomat, ContoDiRisparmio, ContoCorrente.
Analizziamo ora i criteri di aggregazione dei vari RET in ILF/EIF.
Tabelle che rappresentano entità deboli non associative.
Consideriamo due tabelle del modello relazionale precedente: Conto e Movimento. La tabella
Movimento rappresenta un’entità “debole”, che dipende dall’entità Conto.
Questi sono gli elementi che, nel diagramma, caratterizzano Movimento come tabella associata a un’entità “debole”:
- all’interno del rettangolo associato a Movimento, il nome della colonna chiave NumeroConto è seguito dalla sigla FK (Foreign Key), per indicare il fatto che si tratta di una chiave esterna;
- la freccia che collega le due tabelle Movimento e Conto indica la dipendenza di Movimento da Conto.
Nel diagramma dell’esempio precedente, la chiave di Movimento dipende solo dalla chiave esterna NumeroConto della tabella Conto. In generale, una tabella può avere non una sola, ma due o più chiavi esterne (Foreign Keys), presenti in altrettante tabelle del diagramma; in questo caso, la tabella rappresenta un’entità “debole di tipo associativo”, perché associa due o più altre entità. Ad esempio, nel diagramma dell’esempio precedente, la tabella IntestazioneConto rappresenta un’entità “debole” di tipo “associativo”, che connette Cliente e Conto.
La chiave primaria delle tabelle é fondamentale per individuare quelle che rappresentano entità “deboli”. Ad esempio, la tabella TesseraBancomat dipende dalla tabella Intestazione Conto (ovvero dai due campi CodiceCliente e NumeroConto di IntestazioneConto), ma la chiave di TesseraBancomat (CodiceTessera) non dipende da IntestazioneConto; TesseraBancomat non è quindi associata a un’entità “debole”.
Dal punto di vista della Function Point Analysis, vale il seguente criterio:
Consideriamo una tabella le cui chiavi esterne (foreign keys) dipendano da una sola altra tabella del modello relazionale. Nel modello FPA, i RET corrispondenti alle due tabelle dovranno appartenere allo stesso ILF.
Applicando il criterio precedente, risulta che le tabelle Movimento e Conto dovranno corrispondere a RET dello stesso ILF.
Tabelle che rappresentano sottotipi di entità.
Consideriano ora altre tabelle del modello logico relazionale: Conto, ContoDiRisparmio e ContoCorrente. Vediamo che ContoDiRisparmio e ContoCorrente rappresentano, nel diagramma, dei sottotipi di Conto.
Le tabelle che rappresentano sottotipi di entità sono caratterizzate da da diversi elementi:
- al di sotto della tabella “madre” Conto è presente il simbolo “Categoria” (contraddistinto dall’etichetta “TipoConto”) per indicare la connessione con le tabelle che rappresentano i due sottotipi ContoDiRisparmio e ContoCorrente;
- all’interno dei rettangoli che rappresentano i due sottotipi di Conto, l’attributo NumeroConto è seguito dalla sigla FK (Foreign Key), per indicare che l’attributo è stato “ereditato” dalla tabella Conto.
In generale, le tabelle che rappresentano i sottotipi ereditano tutte le colonne della tabella “madre” (nel caso di Conto, le colonne sono: NumeroConto, TipoConto, TassoAttivo, Saldo), e possono avere altre colonne proprie. Ad esempio, ContoCorrente ha, come ulteriori colonne, TassoPassivo e Fido.
Dal punto di vista della Function Point Analysis, vale il seguente criterio:
Consideriamo una tabella del modello logico relazionale che possieda uno o più sottotipi. Nel modello FPA, i RET corrispondenti alla tabella “madre” ed alle tabelle che rappresentano i suoi sottotipi dovranno appartenere allo stesso ILF.
Applicando il criterio precedente, risulta che le tabelle Conto, ContoDiRisparmio e ContoCorrente dovranno essere associate RET dello stesso ILF.
Dal modello logico relazionale agli ILF.
Ora applichiamo tutti i criteri che abbiamo elencato al modello logico relazionale dell’esempio iniziale, che riportiamo qui per comodità.
Partendo dal modello relazionale, possiamo individuare i RET del modello FPA, ed aggregare i RET in ILF:
- ad ogni tabella del modello deve corrispondere un RET del modello FPA; avremo quindi i RET: Cliente, IntestazioneConto, Conto, Movimento, TesseraBancomat, ContoDiRisparmio, ContoCorrente;
- la tabella Movimento rappresenta un’entità di tipo “debole non associativo”, che dipende da Conto; quindi, Movimento e Conto dovranno essere associate a RET dello stesso ILF;
- le tabelle ContoDiRisparmio e ContoCorrente rappresentano sottotipi di Conto; i RET corrispondenti a tutte queste tabelle dovranno quindi appartenere allo stesso ILF.
A questo punto possiamo aggregare in ILF i RET individuati in precedenza. Tutte le tabelle che non soddisfano nessun criterio di aggregazione corrisponderanno a ILF composti da un solo RET: la tabella stessa. Indicheremo ogni ILF con il nome corrispondente al RET più “significativo” tra quelli che lo compongono:
- ILF Cliente, composto dal solo RET Cliente;
- ILF IntestazioneConto, composto dal solo RET IntestazioneConto;
- ILF Conto, composto dai RET Conto, Movimento, ContoDiRisparmio, ContoCorrente;
- ILF TesseraBancomat, composto dal solo RET TesseraBancomat.
Nessun commento:
Posta un commento