Dal modello logico relazionale agli ILF: l’esempio della libreria online.

 

Il modello logico relazionale permette di descrivere il modello dei dati di un’applicazione in modo conciso e indipendente dalla tecnologia. C’è una corrispondenza molto forte tra il modello logico relazionale di un’applicazione, il suo modello Entità-Relazioni (modello E-R), e il suo modello dei dati secondo la Function Point Analysis (modello dei dati FPA). Se si dispone del modello logico relazionale di un’applicazione, è quindi possibile individuarne gli ILF/EIF applicando alcuni semplici criteri.

 

 

Dal modello logico relazionale agli ILF: l’esempio della libreria online.

Il diagramma seguente rappresenta un esempio di modello logico relazionale per un ipotetico sito web che venda (anche a rate) libri, CD e gadget.






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, Ordine, LineaOrdine, RataPagamento, Articolo, Libro, CD e Gadget;
• 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, 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 LineaOrdine è formata dalla coppia di colonne NumeroOrdine e CodiceArticolo;
• 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 Ordine a RataPagamento indica che RataPagamento dipende da Ordine; ovvero, che RataPagamenbto ha, come chiave esterna, la colonna NumeroOrdine della tabella Ordine.

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, Ordine, LineaOrdine, RataPagamento, Articolo, Libro, CD e Gadget.
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: Ordine e RataPagamento. La tabella RataPagamento è associata a un’entità “debole”, di tipo “non associativo”, che dipende dall’entità Ordine.







Questi sono gli elementi che, nel diagramma, caratterizzano RataPagamento come tabella associata a un’entità “debole”:

• all’interno del rettangolo associato a RataPagamento, il nome della colonna NumeroOrdine è seguito dalla sigla FK (Foreign Key), per indicare il fatto che si tratta di una chiave esterna;
• la freccia che collega le due tabelle RataPagamento e Ordine indica la dipendenza di RataPagamento da Ordine.

Nel diagramma dell’esempio precedente, la chiave di RataPagamento dipende solo dalla chiave esterna NumeroOrdine della tabella Ordine. 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 LineaOrdine rappresenta un’entità “debole” di tipo “associativo” tra Ordine e Articolo.

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 RataPagamento e Ordine dovranno corrispondere a RET dello stesso ILF.

 

Tabelle che rappresentano sottotipi di entità.

 

Consideriano ora altre tabelle del modello logico relazionale: Articolo, Libro, Cd e Gadget. Vedremo che Libro, Cd eGadget rappresentano, nel diagramma, dei sottotipi di Articolo.





Le tabelle che rappresentano sottotipi di entità sono caratterizzate da da diversi elementi:

• al di sotto della tabella Articolo è presente il simbolo “Categoria” (contraddistinto dall’etichetta “TipoArticolo”) per indicare la connessione con le tabelle che rappresentano i sottotipi Libro, CD e Gadget;
• all’interno dei rettangoli che rappresentano i tre sottotipi di Articolo, l’attributo CodiceArticolo è seguito dalla sigla FK (Foreign Key), per indicare che l’attributo è stato “ereditato” dall’entità Articolo;

In generale, le tabelle che rappresentano i sottotipi ereditano tutte le colonne della tabella “madre” (nel caso di Articolo, le colonne sono: CodiceArticolo, TipoArticolo, Immagine, Descrizione, Prezzo), e possono avere altre colonne proprie. Ad esempio, Libro ha, come ulteriori colonne, Autore e Titolo, mentre Gadget ha, come attributo specifico, Colore.
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 Articolo, Libro, CD e Gadget 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 complessivo dell’esempio precedente.







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, Ordine, LineaOrdine, RataPagamento, Articolo, Libro, CD e Gadget;
• la tabella RataPagamento rappresenta un’entità di tipo “debole non associativo”, che dipende da Ordine; quindi, RataPagamento e Ordine dovranno essere associate a RET dello stesso ILF;
• le tabelle Libro, CD e Gadget rappresentano sottotipi di Articolo; 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 Ordine, composto dai RET Ordine e RataPagamento;
• ILF LineaOrdine, composto dal solo RET LineaOrdine;
• ILF Articolo, composto dai RET: Articolo, Libro, CD e Gadget.