modello concettuale database entità relazioni

22
La teoria dello schema concettuale Entity Relationships II° parte Presentazione del Prof Silvano Natalizi fatta per la classe VA liceo tecnico Itis A.Volta 20 ottobre 2008

Upload: silvano-natalizi-itis-alessandro-volta-perugia

Post on 05-Dec-2014

9.213 views

Category:

Education


1 download

DESCRIPTION

 

TRANSCRIPT

Page 1: modello concettuale database entità relazioni

La teoria dello schema concettuale Entity

Relationships II° parte

Presentazione del Prof Silvano Natalizifatta per la classe VA liceo tecnico

Itis A.Volta

20 ottobre 2008

Page 2: modello concettuale database entità relazioni

Studiamo la procedura di modellizzazione con un esempio

concreto Un nuovo ipermercato

“AffariEnergetici” è stato appena inaugurato a Perugia, Umbria Italia. Ha molti clienti e negozi. Per questo ipermercato occorre realizzare un database che memorizzi i suoi negozi, i proprietari e i dipendenti.

1. Occorre memorizzare il nome dell’ipermercato, il suo indirizzo, i nomi dei suoi negozi.

2. L’ipermercato deve contenere uno o più negozi

3. Per ogni negozio occorre sapere la sua collocazione, il nome, i suoi reparti, il proprietario, il direttore.

4. Ogni negozio può avere uno o più reparti5. Ciascun reparto ha un solo direttore e un

direttore dirige un solo negozio6. Ciascun negozio ha un solo proprietario7. Ciascun negozio è collocato in un solo

ipermercato8. Occorre memorizzare i dati di ogni

direttore: nome, codice fiscale, il salario e il negozio per il quale lavora

9. Il proprietario del negozio è una persona con i seguenti dati: nome, codice fiscale, indirizzo, numero telefono dell’ufficio.

10.Il proprietario ha almeno un negozio e può possederne più di uno.

Page 3: modello concettuale database entità relazioni

I° step: identificazione della entità dominante dalla descrizione del

documento della richiesta In questo caso è del tutto

evidente che da una lettura sia pur superficiale della richiesta del committente del database emerge come entità primaria lo stesso

ipermercato per il quale vanno memorizzati i valori di alcuni attributi

In questo caso l’entità ipermercato avrà una sola istanza. Per cui è questionabile la sua utilità. Ma in prospettiva può tornare utile e addirittura necessaria se si vuole estendere questo database alla gestione di più ipermercati.

Page 4: modello concettuale database entità relazioni

identificata l’entità dominante, scegliamone gli attributi

Dal paragrafo n. 1 del testo ricaviamo gli attributi dell’ipermercato: nome, indirizzo, nome dei negozi: disegnamo lo schema con un quadrato per l’entità, un ovale per gli attributi elementari e un ovale con doppio perimetro per gli attributi multivalori ( con più valori). Dal paragrafo n. 2 del testo sappiamo che l’attributo nomeNegozi è multivalore.

Page 5: modello concettuale database entità relazioni

Chiave primaria

Gli esempi specifici di entità sono chiamate istanze. Un’istanza è simile ad una riga di una tabella.

Ogni entità deve avere uno o più attributi i cui valori possano individuare univocamente le sue istanze

Questi attributi che sono identificatori univoci delle istanze di un’entità sono chiamati chiavi primarie e vengono sottolineati nel disegno del modello entity relationship

Page 6: modello concettuale database entità relazioni

La chiave primaria dell’entità ipermercato

In questo caso l’attributo nome può essere sufficiente per distinguere un ipermercato da un altro; quindi è la sua chiave primaria e viene sottolineata nel disegno

Page 7: modello concettuale database entità relazioni

2° step della procedura di modellizzazione:

Esaminiamo gli attributi dell’entità primaria per scoprire eventuali attributi per i quali è necessario memorizzare più di un valore

Gli attributi multivalori ricadono immediatamente in questa categoria

Questi attributi diventono entità e devono essere collegati all’entità padre con una relazione

Di conseguenza l’attributo multivalore (nomiNegozi) diventà l’entità [negozio]

Page 8: modello concettuale database entità relazioni

Identificata la nuova entità, individuiamo i suoi attributi

Dal paragrafo n. 3 del testo ricaviamo gli attributi collocazione, il nome, i suoi reparti, il proprietario, il direttore. Dal paragrafo n. 4 sappiamo che l’attributo (reparto) è multivalore. Assumiamo il numero del negozio come chiave primaria.

Page 9: modello concettuale database entità relazioni

Ripetiamo il 2° step della procedura di modellizzazione finchè troviamo attributi da

trasformare in entità

Esaminando gli attributi dell’entità negozio scopriamo che l’attributo “proprietario” dal paragrafo n.9 del testo ha a sua volta più di due attributi e quindi non può essere un’informazione elementare e deve diventare un’entità

La stessa cosa vale per l’attributo “direttore” come si ricava dal paragrafo n. 8 del testo e quindi anche “direttore” diventa un’entità.

Inoltre “i reparti” sono tante informazioni e quindi anche l’attributo multivalore diventa un’entità. Anzi possiamo affermare come regola generale che ogni attributo multivalore deve essere sempre trasformato in entità.

Pertanto abbiamo tre nuove entità: Proprietario Direttore Reparto

Page 10: modello concettuale database entità relazioni

L’entità Proprietario

Dal paragrafo n. 9 del testo determiniamo gli attributi nome, codice fiscale, indirizzo, telefono dell’entità proprietario. Il codice fiscale è un codice univoco per ogni istanza di proprietario e pertanto può esserne la chiave primaria.

Page 11: modello concettuale database entità relazioni

L’entità Direttore

Dal paragrafo n.8 del testo ricaviamo gli attributi dell’entità direttore: nome, codice fiscale, il salario e il negozio per il quale lavora. Naturalmente già sappiamo che negozio è un’entità.

Page 12: modello concettuale database entità relazioni

Concetto di entità debole

Un’entità debole è tale perchè la sua esistenza dipende da un’altra entità

In una entità debole non è possibile trovare una chiave primaria

Un’entità debole ha solo una chiave parziale (nel disegno il suo attributo è sottolineato tratteggiato)

Generalmente le istanze di una entità debole sono parti componenti dell’entità da cui dipendono, ad esempio appartamenti in un palazzo, o i reparti di un negozio come in questo esempio.

Le entità deboli sono disegnate con un rettangolo avente un doppio perimetro

Page 13: modello concettuale database entità relazioni

L’entità debole Reparto

Il reparto è un’entità perché attributo multivalore di negozio, debole perché non ha una esistenza indipendente dal negozio nel quale è contenuto.

Nel testo si parla genericamente di dipendenti del reparto e non si specificano altri attributi.

Tuttavia ipotizziamo che sia ragionevole aggiungere il nome del reparto ed un numero progressivo arbitrario per identificare i reparti del negozio.

Questo numero reparto è una chiave parziale.

Page 14: modello concettuale database entità relazioni

L’entità Dipendente

l’attributo multivalori dipendenti è un’entità Nel testo non si specifica quali siano gli attributi di questa

entità Ipotizziamo che serva il nome e il codice fiscale e che

quest’ultimo sia la chiave primaria

Page 15: modello concettuale database entità relazioni

Abbiamo determinato tutte le entità ?

Abbiamo determinato tutte le entità.Siamo sicuri che non ci siano altre entità ?

Se esaminiamo tutti gli attributi delle entità precedentemente determinate vediamo che questi sono in effetti delle proprietà elementari non ulteriormente scomponibili in più elementi, per lo meno nel contesto di questo problema.

Di conseguenza possiamo smettere di ricercare le entità perché quelle trovate sono esaurienti.

Ora dobbiamo invece ricercare le loro relazioni

Page 16: modello concettuale database entità relazioni

Le relazioni tra le entità

Se pensiamo alla tecnica seguita per scoprire le entità, vediamo che abbiamo creato un albero binario

Page 17: modello concettuale database entità relazioni

Le relazioni

Le entità del precedente albero binario sono collegate tramite relazioni binarie

Una relazione binaria è un legame tra due sole entità

Quindi abbiamo le seguenti coppie di relazioni:

(Ipermercato, Negozio)(Negozio, Proprietario)(Negozio, Direttore)(Negozio, Reparto)(Reparto, Dipendente)

Page 18: modello concettuale database entità relazioni

Proprietà delle relazioni

Ipermercato – Negozio Dal paragrafo n.2 e n. 7 del testo

ricaviamo che questa relazione è uno a molti

Infatti ad uno specifico ipermercato devono corrispondere uno o più negozi concreti

Un’istanza di ipermercato è collegata ad una o più istanze di negozio

Alla relazione occorre dare anche un nome

Page 19: modello concettuale database entità relazioni

Relazione di Negozio con Proprietario

Un proprietario viene memorizzato in questo database perché è proprietario di almeno un negozio

Può essere proprietario anche di più negozi per il paragrafo n.10

Un negozio ha un solo proprietario per il paragrafo n. 6 del testo

Page 20: modello concettuale database entità relazioni

Relazione di Negozio con Direttore

Un direttore deve dirigere uno ed un solo un negozio per come specificato nel paragrafo n. 5 del testo

Pertanto la relazione è uno ad uno

perché ad un’istanza di direttore corrisponde una sola istanza di negozio e viceversa

Page 21: modello concettuale database entità relazioni

Relazione di Negozio con Reparto

Questa relazione identifica l’entità debole Reparto

La relazione è uno a molti come specificato nel paragrafo n. 4 del testo

questa relazione identificativa è disegnata con un rombo avente un doppio segno di perimetro

Page 22: modello concettuale database entità relazioni

Relazione Reparto Dipendente

Questa relazione è uno a molti, per ipotesi ragionevole. Normalmente un reparto impiega uno o più dipendenti