Dal modello logico relazionale agli ILF: l’esempio del conto in titoli.

Dal modello logico relazionale agli ILF: l’esempio del conto in titoli.

Il diagramma seguente rappresenta un esempio di “modello logico relazionale” per un conto di gestione titoli obbligazionari.





Dal diagramma precedente possiamo vedere che:

• le tabelle del modello logico (rappresentate dai rettangoli) sono: ContoTitoli, Movimento, SaldoPerTitolo, Titolo, Cedola, TitoloTassoFisso, TitoloTassoVariabile, TitoloZeroCoupon;
• la chiave della tabella Movimento (acquisto o vendita) dipende dalla chiave esterna NumeroConto; la tabella Movimento rappresenta quindi un’entità “debole”; per identificare un movimento, sono necessari anche altri attributi: una data e un progressivo;
• la chiave della tabella SaldoPerTitolo dipende dalle due chiavi esterne NumeroConto e CodiceISIN; la tabella SaldoPerTitolo rappresenta quindi un’entità “debole” di tipo “associativo”;
• la chiave della tabella Cedola dipende dalla chiave esterna CodiceISIN; la tabella Cedola rappresenta quindi un’entità “debole”;
• le tabelle TitoloTassoFisso, TitoloTassoVariabile e TitoloZeroCoupon sono associate a sottotipi della tabella Titolo; esse “ereditano” tutte le colonne della tabella “madre”, e in più possono avere altre colonne proprie; nel diagramma, la tabella TitoloTassoVariabile ha, come propria colonna specifica, Spread.

Dal punto di vista della Function Point Analysis, ognuna delle tabelle 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 del modello logico relazionale deve corrispondere un RET del modello FPA.

Nel diagramma precedente possiamo quindi individuare i RET: ContoTitoli, Movimento, SaldoPerTitolo, Titolo, Cedola, TitoloTassoFisso, TitoloTassoVariabile, TitoloZeroCoupon.
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: Titolo e Cedola. Cedola rappresenta un’entità “debole”, che dipende dall’entità Titolo.





Questi sono gli elementi che, nel diagramma, caratterizzano Cedola come una tabella che rappresenta un’entità “debole”:

• all’interno del rettangolo associato a Cedola, l’attributo chiave CodiceISIN è seguito dalla sigla FK (Foreign Key), per indicare il fatto che si tratta di una chiave esterna;
• la freccia che collega le tabelle Titolo e Cedola rappresentata la dipendenza della chiave di Cedola dalla chiave di Titolo.

Nel diagramma precedente, la tabella Cedola dipende solo dalla tabella Titolo. In generale, una tabella può dipendere non da una sola, ma da due o più altre tabelle del diagramma; in questo caso, si dice essa rappresenta un’entità di tipo “associativo”, perché associa due o più entità. Ad esempio, nel diagramma dell’esempio precedente, SaldoPerTitolo rappresenta un’entità di tipo “associativo”, che dipende sia da ContoTitoli sia da Titolo.
Dal punto di vista della Function Point Analysis, vale il seguente criterio:
Consideriamo una tabella che rappresenti un’entità “debole” non “associativa”, cioè che dipenda da una ed una sola altra tabella del modello logico relazionale. Nel modello FPA, i RET corrispondenti alle due tabelle dovranno appartenere allo stesso ILF.
Applicando il criterio precedente, risulta che Titolo e Cedola dovranno essere RET dello stesso ILF.

Tabelle associate a sottotipi di entità.

Consideriano ora altre tabelle del modello logico relazionale: Titolo, TitoloTassoFisso, TitoloTassoVariabile, TitoloZeroCoupon. Nel modello, TitoloTassoFisso, TitoloTassoVariabile e TitoloZeroCoupon rappresentano dei sottotipi di Titolo.





Le tabelle che rappresentano sottotipi di entità sono caratterizzate, nel modello logico relazionale, da da diversi elementi:

• al di sotto della tabella Titolo è presente il simbolo “Categoria” per indicare la connessione con i sottotipi TitoloTassoFisso, TitoloTassoVariabile e TitoloZeroCoupon;
• all’interno dei rettangoli che rappresentano i tre sottotipi di Titolo, la colonna chiave CodiceISIN è seguita dalla sigla FK (Foreign Key), per indicare è stata “ereditata” dalla tabella Titolo.

In generale, le tabelle che rappresentano dei sottotipi ereditano tutte le colonne delle tabella “madre” (nel caso di Titolo, le colonne sono: CodiceISIN, Descrizione, Emittente, Scadenza, ValoreNominale, Tasso) e possono avere altre colonne proprie. Ad esempio, TitoloTassoVariabile ha, come ulteriore colonna propria, Spread.
Dal punto di vista della Function Point Analysis, vale il seguente criterio:

Consideriamo una tabella del modello relazionale che possieda uno o più sottotipi. Nel modello FPA, i RET corrispondenti alla tabella “madre” ed ai suoi sottotipi dovranno appartenere allo stesso ILF.

Applicando il criterio precedente, risulta che Titolo, TitoloTassoFisso, TitoloTassoVariabile, e TitoloZeroCoupon dovranno essere RET dello stesso ILF.

Dal modello logico relazionale agli ILF.

Ora applichiamo tutti i criteri che abbiamo elencato al modello logico relazionale complessivo dell’esempio precedente, 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: ContoTitoli, Movimento, SaldoPerTitolo, Titolo, Cedola, TitoloTassoFisso, TitoloTassoVariabile, TitoloZeroCoupon;
• la tabella Movimento rappresenta un’entità di tipo “debole”, e dipende da ContoTitoli; quindi, Movimento e ContoTitoli dovranno essere RET dello stesso ILF;
• la tabella Cedola rappresenta un’entità “debole”, e dipende da Titolo; quindi, Cedola e Titolo dovranno essere RET dello stesso ILF;
• la tabella SaldoPerTitolo rappresenta un’entità di tipo “debole associativo”, che dipende sia da ContoTitoli sia da Titolo; SaldoPerTitolo non soddisfa il criterio d’aggregazione per le entità “deboli non associative”;
• le tabelle TitoloTassoFisso, TitoloTassoVariabile, e TitoloZeroCoupon rappresentano sottotipi dell’entità Titolo; 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. Tutti i RET che non soddisfano nessun criterio di aggregazione corrisponderanno a ILF composti da un solo RET. Indicheremo ogni ILF con il nome corrispondente al RET più “significativo” tra quelli che lo compongono:

• ILF ContoTitoli, composto dai RET ContoTitoli e Movimento;
• ILF SaldoPerTitolo, composto dal solo RET SaldoPerTitolo;
• ILF Titolo, composto dai RET: Cedola, TitoloTassoFisso, TitoloTassoVariabile, e TitoloZeroCoupon.

© Copyright by Nicola La Monaca, 2010

All rights reserved