Entità intrinsecamente deboli

In molti casi una stessa entità può essere “forte” in un certo modello Entità-Relazioni, “debole” in un altro. Queste differenze rispecchiano sia i differenti modelli di business dai quali i modelli E-R sono stati derivati, sia un certo margine di soggettività da parte di chi definisce il modello E-R.

Sui modelli E-R ci sono inevitabili margini di soggettività, dovuti al fatto che sia l’utente che definisce la sua visione del business, sia l’analista che definisce il modello E-R, sono “umani”, quindi possono avere visioni differenti, soggettive, di una stessa realtà.

Esistono però diversi esempi di entità “intrinsecamente deboli”, cioè entità che sono

“predestinate” ad essere “deboli” in qualunque modello E-R. Si tratta delle entità che già nel mondo reale devono necessariamente essere identificate per mezzo di altre entità.

Ecco alcuni esempi.

CAP, Via e NumeroCivico. Tutti sappiamo, quando ad esempio scriviamo una cartolina, che il solo numero civico del destinatario non basta, da solo, a individuarlo: sono necessari anche il Codice di Avviamento Postale (CAP) e la via. A sua volta, anche la via non può essere individuata, in modo univoco, senza il CAP.
In qualunque modello E-R che contenga degli indirizzi, Numero Civico sarà un’entità “debole”, dipendente dalle entità CAP e Via. Anche l’entità Via sarà un’entità “debole”, dipendente da CAP.

Specie e Genere. Nella “classificazione binomiale” delle specie viventi, introdotta da Linneo, le varie specie sono identificate da un genere (ad esempio, Homo) e dal nome della specie stessa (ad esempio, Sapiens). Il nome di una specie (ad esempio, Homo Sapiens) non basta, da solo, a identificare una specie: infatti esistono (rari) casi di specie con lo stesso nome appartenenti a generi diversi.
In qualunque modello E-R, l’entità Specie sarà, inevitabilmente, un’entità debole: per essere identificata, avrà bisogno della chiave dell’entità sovrastante, il Genere.

Titolo e Cedola. Nel mondo della finanza, le obbligazioni (bonds) sono individuate da un codice univoco (codice ISIN). Le cedole (coupons) sono individuate dal codice dell’obbligazione e da un progressivo. Le cedole sono un’entità intrinsecamente debole: non hanno, nel mondo reale, una chiave che le identifichi in maniera univoca indipendentemente dal codice dell’obbligazione a cui appartengono. Questa situazione sarà inevitabilmente rispecchiata da qualunque modello E-R che rappresenti le entità Obbligazione e Cedola.

Riassumendo: alcuni concetti del mondo reale possono essere associati, in un modello E-R, a entità “deboli” o “forti”, a seconda della visione di chi definisce il modello. Ad esempio, abbiamo visto in un esempio precedente, che le entità Impiegato e Figlio possono essere rappresentate, in un modello E-R, in modo diverso. Altre entità (ad esempio, il numero civico di un indirizzo postale sono “intrinsecamente deboli”: in qualunque modello E-R, l’entità Numero Civico sarà sempre dipendente dall’entità Via e dall’entità CAP.

Il significato delle chiavi in un modello E-R

Il modello concettuale dei dati (modello E-R) deve rispecchiare, per definizione, la visione dei dati che ha l’utente finale dell’applicazione, senza alcun vincolo di tipo “tecnico”. In quest’ottica, le chiavi delle entità del modello hanno un ruolo fondamentale. Il fatto che un analista definisca due entità del modello E-R con la stessa chiave non può essere una scelta casuale, perché deve rispecchiare il significato, il valore semantico, che le entità hanno per l’utente finale.

Dire che due entità sono in gerarchia IsA implica che, nel modello, le due entità debbano avere la stessa chiave. Viceversa, il fatto che, in un modello E-R-, due entità del modello abbiano la stessa chiave, non può essere casuale: deve rispecchiare il fatto che, nella visione dell’utente, le due entità partecipano alla stessa gerarchia IsA, oppure una è attributiva dell’altra.

Se, come nella figura precedente, l’analista decide che due entità partecipano ma una gerarchia IsA (Impiegato IsA Dipendente, Dirigente IsA Dipendente) allora le due entità dovranno avere, nel modello E-R, la stessa chiave. In questo esempio, il nome della chiave comune alle due entità Impiegato e Dirigente potrebbe essere, ad esempio, (CodiceDipendente).

Si noti che, nella fase di realizzazione di un modello E-R ci sono notevoli margini di soggettività. Partendo dagli stessi business requirements, analisti diversi potrebbero creare modelli E-R diversi che li rappresentino. Ad esempio, si può immaginare un modello E-R dove Impiegato e Dirigente non partecipino nella stessa gerarchia IsA. Ma, in questo caso, l’analista dovrà scegliere, per le due entità, due chiavi differenti: ad esempio, (CodiceImpiegato) e (Codice Dirigente).

Ricapitolando: se l’analista del modello E-R decide che due entità (Impiegato e Dirigente) devono far parte di una stessa gerarchia IsA, nel modello E-R dovrà necessariamente dare alle due entità la stessa chiave.

Passiamo ora a un altro concetto: il significato delle chiavi nella rappresentazione della dipendenza tra due entità del modello. Le entità di un modello E-R che dipendono da altre entità si dicono “entità deboli”. In molti casi, il concetto di dipendenza, o “debolezza”, è relativo: una stessa entità può essere indipendente da altre entità (ovvero, “forte”) in un certo modello E-R, e invece essere dipendente da altre entità (ovvero, “debole”) in un altro modello E-R.

Vediamo un esempio: le entità Impiegato e Figlio (dell’impiegato) memorizzate in un modello E-R per un’applicazione aziendale. L’analista dell’applicazione ha diverse scelte per individuare le chiavi primarie delle due entità. Ad esempio, l’entità Impiegato potrebbe avere la chiave primaria (CodiceImpiegato), e l’entità Figlio potrebbe avere la chiave primaria (CodiceFiscale). In questo caso, le due entità sarebbero indipendenti tra loro, e la rappresentazione del legame tra un impiegato ed i suoi figli richiederebbe un relazione “molti a molti” con chiave (CodiceImpiegato, CodiceFiscaleFiglio).

Una seconda possibilità è quella di dare alle due entità Impiegato e Figlio la stessa chiave primaria, ad esempio (CodiceFiscale). Anche in questo caso, le due entità sarebbero indipendenti, ma farebbero parte di una stessa gerarchia IsA, che possiamo, ad esempio, chiamare Persona. In questo caso, la rappresentazione del legame tra impiegato e figlio richiederebbe una relazione “molti a molti”

riflessiva tra Persona e Persona, la cui chiave si potrebbe chiamare (CodiceFiscalePadre, CodiceFiscaleFiglio).

Una terza possibilità è quella di individuare l’impiegato con la chiave (CodiceImpiegato), ed i figli con una chiave dipendente da quella di Impiegato: ad esempio, (CodiceImpiegato, ProgressivoFiglio). In questo caso, basandosi sulla relazione di inclusione tra le chiavi delle due entità Impiegato e Figlio,

Figlio sarebbe, per definizione, un’entità debole.

Riassumendo, in molti casi è possibile disegnare modelli E-R che rappresentano le stesse entità (ad esempio, Impiegato e Figlio) in modi differenti. E un’entità (in questo caso, Figlio) può essere “debole” o “forte”, secondo le scelte fatte da chi definisce il modello E-R.

Documento "Pensare in Function Points - Le funzioni di tipo dati" (bozza del 17.12.2009)

Il documento contiene indicazioni, suggerimenti e spunti di discussione sul conteggio delle "funzioni di tipo dati" secondo la versione 4.2 del Manuale di Conteggio IFPUG.

L'ultima bozza del documento può essere scaricata da uno dei seguenti links:

Pensare in Function Points: le “funzioni di tipo dati” - bozza del 17.12.2009

Pensare in Function Points: le “funzioni di tipo dati” - bozza del 17.12.2009

Ancora su entità "forti" ed entità "deboli"

Parliamo ancora di "entità forti" ed "entità deboli". Pensiamo al modello E-R associato ad una ”Anagrafica Titoli”. Due entità del modello saranno sicuramente “Titolo” e “Cedola”.



Per rappresentare questi oggetti “materiali” su un sistema informatico, dobbiamo introdurre delle chiavi. Ad esempio, le chiavi potrebbero essere:


K ( Titolo ) = ( NomeEmittente, DataEmissione )
K ( Cedola ) = ( NomeEmittente, DataEmissione, NumeroCedola )

Passiamo ora agli insiemi degli attributi chiave.


KS ( Titolo ) = { NomeEmittente, DataEmissione }
KS ( Cedola ) = { NomeEmittente, DataEmissione, NumeroCedola }

Possiamo osservare che


{ NomeEmittente, DataEmissione } ⊆ { NomeEmittente, DataEmissione, NumeroCedola }

cioè


KS ( Titolo ) ⊆ KS ( Cedola )

In base alle definizioni precedenti, “Cedola” è un’entità debole, e dipende da “Titolo”.
La figura precedente rappresenta un’obbligazione, con le relative cedole, emessa nel 1863, durante la Guerra Civile, dagli Stati Confederati d’America. Questa figura permette di fornire un chiarimento su una “definizione informale”, un po’ troppo generica, che a volte si sente dare per le “entità deboli per esistenza”. Secondo questa definizione, un’entità “debole per esistenza”, dipendente da un’altra entità “forte”, “perde di significato” se l’entità “forte” scompare dal modello E-R.
E’ chiaro che la definizione di “entità debole per esistenza” va applicata alle chiavi di un modello E-R, non alla realtà. Se prendiamo l’obbligazione della figura precedente, emessa dagli Stati Confederati nel 1863, poi con un paio di forbici ritagliamo il foglio dell’obbligazione e lo distruggiamo, lasciando solo le cedole, queste ultime non “perdono di significato”. Se l’obbligazione non fosse scaduta, forse potremmo anche andare in banca per riscuoterle.
Allo stesso modo, se nel nostro modello E-R ”Anagrafica Titoli” cancelliamo l’entità Titolo, l’entità Cedola non “perde di significato”. Per applicare in maniera corretta la definizione di “entità debole per esistenza”, bisogna quindi seguire solo fino ad un certo punto i concetti “divulgativi”, ed è meglio affidarsi alle definizioni “formali”. Nel caso del modello E-R ”Anagrafica Titoli” del nostro esempio, l’entità Cedola è “debole per esistenza” per definizione, perché vale la relazione:

{ NomeEmittente, DataEmissione } ⊆ { NomeEmittente, DataEmissione, NumeroCedola }
cioè

KS (Titolo ) ⊆ KS ( Cedola )
Cercare di spiegare il concetto di “dipendenza per esistenza” tra le entità a parole, senza usare una notazione formale, è un po’ come cercare di spiegare la meccanica quantistica nei programmi TV divulgativi, come fa a volte il fisico Antonino Zichichi. E’ divertente, interessante, ma credo che ognuno di quelli che lo ascoltano (a parte i fisici) si sia fatto una sua, personale, visione della meccanica quantistica (io comunque ancora non l’ho capita). Ed è probabile che queste visioni personali siano in contrasto tra loro.
Il linguaggio formale dell’insiemistica, invece, è universale, e non dà luogo ad incomprensioni. Nel caso delle “entità deboli per esistenza”, poi, per usarlo basta davvero poco: i concetti di base dell’insiemistica, insegnati da decine d’anni anche nelle scuole elementari.

Riferimenti esterni
§ http://en.wikipedia.org/wiki/Relational_model

Entità "forti" ed entità "deboli"

Una volta costruito il modello E-R di un’applicazione, si può passare ad analizzarlo. Uno dei tanti concetti usati nell’analisi dei modelli E-R è in concetto di “entità debole” (o “entità debole per esistenza”), contrapposto al concetto di “entità forte” (“entità forte per esistenza”).
Prima del 2001, il concetto di “entità debole per esistenza” non appariva nei manuali IFPUG per il conteggio dei Function Points. Nel 2001, con la pubblicazione dell’”Addendum” al Manuale di Conteggio IFPUG 4.1.1, si è scoperto che classificare le entità del modello concettuale di un’applicazione come “deboli”, piuttosto che come “forti”, aveva significative ripercussioni sul conteggio degli ILF associati dell’applicazione. Da allora, i dibattiti sul concetto di “entità debole” si sono ampliati a tutta la vasta e variegata comunità degli informatici che hanno a che fare con i Function Points.
Ma cosa sono le “entità deboli”? Si tratta di entità di un modello E-R la cui chiave dipende dalla chiave di un’altra entità del modello. Ad esempio, se in modello E-R ci sono le entità Fattura {NumeroFattura} e RigaFattura {NumeroFattura, Numero Riga}, l’entità RigaFattura si dice “debole”, perché la sua chiave dipende da quella di Fattura.

Ecco una definizione formale.

In un modello E-R, si dice “entità debole per esistenza” un’entità la cui la cui chiave dipende da quella di un’altra entità del modello.Le entità la cui chiave non dipende da quella di nessun’altra entità del modello si dicono, invece, “entità forti”.
Ecco un esempio preso dal web.



In questo sottoinsieme di modello E-R abbiamo due entità: Movie e MovieCopy. Forse il modello E-R proviene da una delle prime fasi dell’analisi del sistema informatico di un negozio BlockBuster. Ora rappresentiamo le due entità con la notazione "formale" introdotta in precedenza.


Entity: Movie { MovieNumber, Title }
Entity: Movie { MovieNumber, CopyNumber, ShelfLocation }

L'insieme degli attributi chiave dell'entità Movie è, ovviamente, {MovieNumber}; l'insieme degli attributi chiave dell'entità MovieCopy è, invece, {MovieNumber, CopyNumber}.
La chiave dell'entità MovieCopy dipende da quella dell'entità Movie; MovieCopy è, per definizione, un’entità “debole per esistenza”. La chiave di Movie, invece, non dipende da nessuna altra chiave all’interno del modello. Movie è quindi, per definizione, un’entità “forte per esistenza”.
Il concetto di dipendenza tra chiavi può essere espresso in modo molto sintetico usando la notazione "insiemistica" introdotta in precedenza: l'insieme degli attributi chiave di un’entità "debole" deve comprendere l'insieme degli attributi di un’altra entità del modello. Usando la notazione "insiemistica", gli insiemi degli attributi chiave delle due entità Movie e MovieCopy sono:


KS ( Movie ) = { K ( Movie ) } = { MovieNumber }
KS ( MovieCopy ) = { K ( MovieCopy )} = { MovieNumber, CopyNumber }

E’ facile osservare che l'insieme degli attributi chiave di Movie, { K ( Movie ) }, è un sottoinsieme degli attributi chiave di MovieCopy, { K ( MovieCopy ) }:


{ MovieNumber } ⊆ { MovieNumber, CopyNumber }

cioè


{ K ( Movie ) } ⊆ { K ( MovieCopy ) }

oppure (le due notazioni sono equivalenti):


KS ( Movie ) ⊆ KS ( MovieCopy )

L’insieme degli attributi chiave di MovieCopy è un superinsieme proprio dell’insieme degli attributi chiave di Movie. E’ possibile generalizzare questo esempio, e dare una definizione "insiemistica" per le chiavi delle entità "deboli per esistenza".


Def. Dato un modello E-R con due entità A e B, ed i rispettivi insiemi degli attributi chiave KS(A) e KS(B), si dice che B è un’entità “debole per esistenza” rispetto ad A se

KS(B) ⊆ KS(A)

Cioè se l’insieme degli attributi chiave di B è un superinsieme proprio dell’insieme degli attributi chiave di B.


Riferimenti esterni
http://en.wikipedia.org/wiki/Relational_model