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

Un esempo di notazione "formale" per i modelli E-R

Basta fare un “giro” sul web per vedere che ci sono letteralmente centinaia di diverse notazioni formali per i diagrammi E-R ed i diagrammi relazionali.

Per i modelli relazionali c’è addirittura un vero e proprio linguaggio standard: lo SQL ANSI Standard. Lo SQL standard è sicuramente completo, ma un po’ troppo verboso. La notazione qui sotto, presa dal web, si fa invece apprezzare per la sua sinteticità.

Customer(Customer ID, Tax ID, Name, Address, City, State, Zip, Phone)

Order (Order No, Customer ID, Invoice No, Date Placed, Date Promised, Terms, Status)

Order Line(Order No, Order Line No, Product Code, Qty)

Invoice (Invoice No, Customer ID, Order No, Date, Status)

Invoice Line(Invoice No, Invoice Line No, Product Code, Qty Shipped)

Product(Product Code, Product Description)

Nell’esempio precedente, il nome di ogni tabella del modello relazionale è seguito dall’elenco delle sue colonne. Le colonne chiave sono in neretto. E’ facile verificare che questa notazione “funziona” anche per rappresentare le entità e le relazioni di un modello E-R.

Il diagramma E-R qui sotto è interessante perché “suggerisce” una notazione simbolica molto simile a quella precedente.

Partiamo da questo esempio per introdurre un esempio di notazione "formale" per un modello E-R.

Entity: Titolo( CodiceISIN, DescrizioneTitolo, CodiceEmittente, AnnoEmissione, Scadenza, Importo )

In questo esempio, l’entità Titolo è seguita dall’elenco degli attributi. Gli attributi chiave sono in grassetto. Di solito, l’elenco degli attributi racchiuso tra parentesi sta ad indicare una notazione posizionale, o "vettoriale". In questo tipo di notazione si ha:

(a, b) ≠ (b, a)

Introduciamo ora una notazione differente, insiemistica, nella quale gli oggetti di un elenco non hanno un ordine predefinito. Cioè:

{ a, b } = { b, a }

Applichiamo ora la notazione “insiemistica” per rappresentare l’insieme degli attributi di un’entità o una relazione. Ecco un esempio.

Entity: Titolo { CodiceISIN, DescrizioneTitolo, CodiceEmittente, AnnoEmissione, Scadenza, Importo }

In questa seconda rappresentazione dell’entità Titolo, gli attributi sono racchiusi tra parentesi graffe, come si usa per gli insiemi, in modo da sottolineare che il loro ordine non è importante. Gli attributi chiave (in questo caso, CodiceISIN) sono sottolineati. Ecco un altro esempio delle due notazioni (posizionale ed insiemistica).

Entity: Cedola( CodiceISIN, ProgressivoCedola, Scadenza, Importo )

Entity: Cedola{ CodiceISIN, ProgressivoCedola, Scadenza, Importo }

I due attributi chiave della cedola (CodiceISIN, ProgressivoCedola) sono sottolineati.

Nel seguito useremo tutte e due queste notazioni: quella con le parentesi "tonde" ("posizionale") e quella con le parentesi "graffe" ("insiemistica"). In questo modo sarà facile chiarire, nelle varie situazioni, se l’ordine degli attributi di una entità o relazione è importante o meno.

Osserviamo che, cambiando l’ordine degli attributi, con le due notazioni si hanno risultati differenti:

Cedola( CodiceISIN, ProgressivoCedola, Scadenza, Importo ) ≠ Cedola(ProgressivoCedola, CodiceISIN, Scadenza, Importo )

Mentre gli insiemi degli attributi, anche cambiano il loro ordine, sono coincidenti. Cioè

Cedola{ CodiceISIN, ProgressivoCedola, Scadenza, Importo} = Cedola{ ProgressivoCedola, CodiceISIN, Scadenza, Importo}

Introduciamo ora altre due notazioni per indicare identificare i soli attributi chiave di un’entità. Data un’entità E con attributi chiave K1, K2, … Kn ed attributi non chiave A1, A2 … Am:

E ( K₁, K₂, … K_n; A₁, A₂, … A_m )

indichiamo con K(E) la n-upla ordinata con i soli attributi chiave di E:

K(E) = ( K₁, K₂, … K_n )

ed indichiamo con { K(E) }, o con KS(E), l’insieme dei soli attributi chiave di E:

{ K(E) } = KS(E) = { K₁, K₂, … K_n }

Ecco alcuni esempi.

Entity: Titolo ( CodiceISIN, Scadenza, Importo )

K(Titolo) = ( CodiceISIN )

{ K(Titolo) } = KS(Titolo) = { CodiceISIN }


Entity: Cedola ( CodiceISIN, ProgressivoCedola,Scadenza, Importo )

{ K(Cedola) } = KS(Cedola) = { CodiceISIN, ProgressivoCedola } = { ProgressivoCedola, CodiceISIN }

Ovviamente, detta E un’entità, vale sempre la relazione:

{ K(E) } ⊆ { E }

cioè l'insieme degli attributi chiave dell'entità è un sottoinsieme dei suoi attributi. Ad esempio:

{ K(Titolo) } ⊆ { Titolo }

Riferimenti esterni

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

Notazioni grafiche e "formali" per i modelli E-R

Il “Modello Entità-Relazioni (E-R)” per la rappresentazione e l’analisi dei dati è ancora un “modello di riferimento” per l’analisi dei dati. I cosiddetti “Class Diagram”, usati nel linguaggio UML (Uniform Modeling Language), sono un’evoluzione dei diagrammi E-R: ma i concetti fondamentali restano gli stessi.
Ci sono diverse “notazioni grafiche”, o “dialetti”, per rappresentare graficamente i diagrammi E-R.
Ecco qui sotto un esempio di diagramma E-R preso dal web.




Praticamente in tutte le “notazioni” per i diagrammi E-R, le entità sono rappresentate con dei rettangoli, le relazioni con dei rombi. Sulle linee che connettono le entità e le relazioni ci sono le “cardinalità” delle relazioni. Le cardinalità più comuni sono "0..1" (opzionale), "1" (obbligatoria), "1.. n" (uno a molti obbligatoria), "0.. n" (uno a molti opzionale).
I diagrammi E-R, così come quelli relazionali, possono essere rappresentati usando una notazione matematica, formale, basata su semplici concetti di teoria degli insiemi. Nella figura qui sotto c’è qualche esempio di definizioni fornite da Chen in un suo articolo sul modello E-R.



La possibilità di rappresentare le entità e le relazioni usando un linguaggio matematico, formale, permette ai “CASE tools” usati per l’analisi ed il disegno dei dati di rappresentare i diagrammi E-R all’interno dei computers. Forse qualche manager potrebbe restare sorpreso scoprendo che i coloratissimi diagrammi E-R creati dal “CASE tool” che ha appena acquistato per la sua azienda non sono in formato JPEG nativo, e per modificarli non è necessario un software di "fotoritocco".

Riferimenti esterni
§ Peter P. Chen , Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned.
§ All for One, One for All, by C. J. Date, May 31st, 2006

I modelli dei dati all’epoca dell’”invenzione” dei Function Points.

Per capire come sono nati gli ILF, è necessario tornare ai tempi pionieristici della nascita dei Function Points: alla fine degli anni ‘70, ai tempi dei computer mainframe e delle schede perforate.
A quell’epoca, quasi tutte le applicazioni si basavano, per i loro dati, su “files piatti”. I databases DL/1, che da qualche anno l’IBM ha abbandonato, negli anni ’70 erano strumenti d’avanguardia. Il modello relazionale dei dati, che oggi domina incontrastato nel mondo del software, era stato studiato e proposto da Edgar F. Codd, nel 1969. Ma i databases relazionali erano al massimo un oggetto di studio accademico.
Un tema molto interessante per gli studiosi d’informatica era quello di scegliere il “modello dei dati” più adatto per rappresentare i dati del mondo reale all’interno delle applicazioni software.



Il “modello relazionale” era estremamente “potente” e basato su solidi concetti matematici, ma un po’ astratto.



Nel 1975 Peter Chen, uno studioso americano, propose il “Modello Entità-Relazioni (E-R)” per la rappresentazione e l’analisi dei dati. Il modello E-R, come anche il modello relazionale, sono modelli astratti, indipendenti dalla tecnologia, un pò come la “macchina di Turing”. Per questo, mentre i computers del 1975 sono oggetti da museo, il modello E-R ed il modello relazionale sono ancora modelli di riferimento per l’analisi dei dati.
Il modello E-R è, da un punto di vista logico, ancora più astratto del modello relazionale. Ma i diagrammi E-R sono, di solito, molto più comprensibili agli “umani” rispetto ai diagrammi relazionali. In altre parole, anche se i due modelli veicolano le stesse informazioni, il modello E-R è il più valido dal punto di vista “semantico”.
Per questo, il modello E-R è diventato il “modello principe” per l’analisi dei dati fatta dagli “umani”, mentre il modello relazionale è il modello più diffuso per la rappresentazione dei dati sui computers.



Al di là delle apparenze, il modello E-R ed il modello relazionale sono molto simili. Per tutti e due i modelli, è possibile passare dai diagrammi ad una notazione matematica, formale, basata su semplici concetti di teoria degli insiemi. Tutti e due i modelli, essendo basati su concetti matematici, sono indipendenti dalla tecnologia, e quindi, in qualche modo, “eterni”.
Man mano che si passa dalla realtà “umana”, fatta di concetti, alla realtà dei computers, fatta di bits, i concetti perdono il loro significato semantico e diventano sempre più astratti. La figura che segue rappresenta la gerarchia tra i modelli dei dati usati nel mondo dell’informatica.



Il “modello concettuale” è quello più vicino alla realtà “umana”. Ci sono diversi tipi di modelli concettuali, ma il “modello concettuale” per antonomasia è il modello E-R di Chen.
Al di sotto del modello concettuale, un po’ più vicino al computer, c’è il “modello logico” dei dati. Il “modello logico” imperante nei nostri giorni è quello “relazionale”, introdotto da Edgar F. Codd nel 1969. In passato, ai tempi del mainframe, c’era anche un altro “modello logico” molto in voga: il “modello gerarchico”, che corrispondeva al modo in cui il DL/1, il più diffuso tipo di database che c’era all’epoca, rappresentava i dati sui computer. Il “modello gerarchico” non ha mai avuto successo tra gli accademici, perché corrispondeva ad un modo troppo limitato, troppo vincolato, di rappresentare la realtà. Un “modello logico” più recente, che però non è riuscito a soppiantare il “modello relazionale”, è il modello “object oriented”.
Il “Modello Fisico” corrisponde al modo in cui il modello logico è rappresentato fisicamente sul computer. Nel caso di un modello logico relazionale, il modello fisico corrisponde al DDL (Data Definition Language) che definisce, in SQL (il “linguaggio standard” del mondo relazionale) la struttura delle tabelle, le chiavi, gli indici, ecc.
Qual è il “migliore” tra il modello E-R di Chen, ed il modello relazionale di Codd? Credo che la polemica tra Chen e gli “eredi” di Codd (in particolare, Chris Date) sia tuttora in corso; ma di solito, quando bisogna fare il primo passo nell’analisi dei dati per una nuova applicazione, la maggior parte degli analisti usano quadratini, rombi e linee (cioè il modello E-R). Quando le idee di base sono state chiarite, si passa a disegnare dei rettangoli con un po’ di righe e colonne dentro, collegandoli con delle linee (cioè tabelle: il modello relazionale).
Tutti e due i modelli sono quindi molto validi, anche se di solito sono usati in fasi diverse dell’analisi. Ed è possibile rappresentare tutti e due i modelli usando delle notazioni sintetiche, di tipo “formale”.

Riferimenti esterni
§ http://en.wikipedia.org/wiki/Relational_model
§ Peter P. Chen , Entity-Relationship Modeling: Historical Events, Future Trends, and Lessons Learned.
§ All for One, One for All, by C. J. Date, May 31st, 2006