Basi Di Dati

FAI ESERCIZI

Risposte crocette esercizi.pdf (controlla 7)

1b 2b 3a 4b 5c 6b 7c Basi Di Dati Pagina 13

Progettazione di DB: Metodologie e modelli

giovedì 31 marzo 2016 09:13

Ora che abbiamo analizzato il modello relazionale, è chiaro che è molto difficile costruirne un modello partendo dal

nulla, o da una semplice chiaccherata con un cliente: abbiamo bisogno di trovare un modello per progettare il modello

relazionale. La progettazione è una componente fondamentale nei processi di sviluppo

nei sistemi informativi: non c'è un modo giusto per farlo, ma

semplicemente un modo "più furbo" dell'altro.

Analizziamo ora i passi "Requisiti della base di

dati" e "progettazione": Dai requisiti (che ci

fornirà il nostro cliente) faremo una

progettazione concettuale. (Analisi di "che

cosa") Una volta eseguita, avremo uno schema

concettuale, da cui poi andremo ad effettuare la

progettazione logica, che darà vita allo schema

logico (il modello relazionale). Il passaggio da

progettazione concettuale a progettazione logica

è una "traduzione" dello schema concettuale.

Infine avremo la progettazione fisica (che non

faremo in questo corso) (che corrisponderebbe

al "come") Le progettazioni concettuale e logica si effettuano

entrambe attraverso un tipo di modello concettuale,

ed un tipo di modello logico. Per modello logico

intendiamo un modello utilizzato nei DBMS per

organizzare i dati. (es, relazionale, reticolare, ecc)

Per modello concettuale si intende un modello che

permette di rappresentare i dati in modo

indipendente da ogni sistema.

Per la progettazione concettuale utilizzeremo il modello E-R (Entity-Relationship). Esso è un modello concettuale, ossia

un modello che permette di rappresentare i dati in modo indipendente da ogni sistema, cercando di sescrivere i concetti

del mondo reale.

Questo modello concettuale ha dei costrutti principali, ossia l'entità e la relazione (chiamata anche associazione per

evitare confusione con il modello relazionale).

Passiamo ad analizzarle:

Entità

Per entità intendiamo una classe di oggetti (persone, cose) con proprietà comuni e con esistenza autonoma. Es:

impiegato, città, ordine, ecc.

Ogni entità ha un nome che la identifica univocamente nello schema. Deve essere un nome espressivo, singolare.

Associazione (Relazione)

Un'associazione è un legame logico fra due o più entità, rilevante nell'applicazione di interesse

La relationship non ha necessariamente un legame con il modello relazionale. (non si traduce in un elemento concreto

del modello relazionale) Basi Di Dati Pagina 14

Es: Residenza (legame tra persona e città), Esame (legame fra studente e corso)

Anche nel modello E-R vi è il concetto di "schema-istanza":

più precisamente, avremo un'entità (classe di oggetti) ed

un'occorrenza di entità (un elemento della classe).

Nello schema concettuale rappresenteremo le entità, non le singole istanze. TUTTAVIA si può anche adoperare sulle

singole occorrenze, in modo da ottimizzare il database.

Un'occorrenza di un'associazione binaria è la coppia di occorrenze dell'entità, una per ciascuna entità coinvolta. Più in

generale, un'occorrenza di una relationship n-aria è una n-upla di occorrenze di entità.

In una relationship non possono esserci occorrenze (n-uple) ripetute.

Tuttavia, ora analizziamo la relazione "Esame": visto le regole che

abbiamo detto poco fa, quindi questo db non prevede che uno

studente ripeta più di una volta lo stesso esame: perché se no

succederebbe questo:

E ciò violerebbe la relazione. Quindi come risolviamo questo

problema?

Possiamo risolvere "promuovendo" la relationship. Quindi la mia relazione "Esame" la trasformo in un'entità.

In questo modo, nessuna regola viene violata.

Le relazioni binarie sono quelle più comuni, ma vi sono anche relazioni "n-arie", e anche relazioni con un'entità sola.

(relazioni ricorsive)

NOTA BENE: per capire di che grado è una relazione, basta guardare gli archi uscenti dalla relazione stessa.

Attributo

Un attributo è una proprietà elementare di un'entità o di una relationship. Associa ad ogni occorrenza di entità o

relationship un valore appartenente ad un insieme detto dominio dell'attributo.

NOTA BENE 2 LA VENDETTA: anche se intuitivamente possiamo pensare che mettendo due date o voti diversi vado a

rispettare le condizioni per avere due occorrenze di esame con le stesse entità, CIO' NON E' POSSIBILE. Anche se in

un'occorrenza di relazione ho gli attributi data o voto diversi, per una coppia uguale studente-corso, questa relazione

viola ugualmente le proprietà della relazione. (eh? Controlla)

Gli attributi composti raggruppano attributi di una medesima entità o relationship che presentano affinità nel loro

significato o nel loro uso. (Es: Via, Numero civico e CAP formano un indirizzo)

Altri costrutti del modello E-R

• Cardinalità

• Identificatore

• Generalizzazione

Cardinalità

Una cardinalità (di Relationship) è una coppia di valori associati ad ciascuna entità che partecipa alla relazione.

Specificano il numero minimo o massimo di occorrenze della relationship su cui ciascuna occorrenza di un'entità può

partecipare.

Per semplicità utilizziamo 3 simboli: 0 e 1 per la cardinalità minima, (0 -> partecipazione "opzionale", 1 -> partecipazione

"obbligatoria), e 1 e N per la massima. (N non pone alcun limite.)

Ad esempio, nell'immagine qui a fianco consideriamo

l'entità Incarico e l'associazione "Assegnamento". Quel

(0, 50) significa: "Ogni incarico può essere assegnato a 0

impiegati (minimo) oppure al massimo 50"

In base alle cardinalità noi dividiamo le relationship in 3 categorie:

1. Uno a uno

2. Uno a molti

3. Molti a molti Basi Di Dati Pagina 15

Un esempio di relationship molti a molti è la seguente: v

"Molti studenti possono dare molti esami"

Es. relationship "uno a molti":

"in una località possono trovarsi più cinema"

Es relationship "uno ad uno"

"Un professore può avere una cattedra, e una cattedra è posseduta da un solo professore"

NB: quando non vi è specificata la cardinalità, è sempre (1,1)

Cardinalità di attributi È possibile associare delle cardinalità anche agli attributi, con

due scopi:

• Indicatore opzionalità

• Indicare attributi multivalore

Identificatore

l'identificatore è uno strumento per l'identificazione univoca delle occorrenze di un'entità.

Esso è costituito da: Attributi dell'entità (identificatore interno), e attributi + entità esterne attraverso relationship

(identificatore esterno)

A sinistra e a destra abbiamo rispettivamente un esempio di identificatore interno ed identificatore esterno.

Nel caso dell'identificatore esterno, è possibile che ci siano studenti con la stessa matricola in più università: l'unico

modo per risolvere questo problema correttamente è di associare, come chiave, la matricola e l'ateneo di iscrizione.

Questo è l'identificatore esterno.

(Si può fare solo quando la cardinalità è (1,1))

Osservazioni

Ogni entità deve possedere almeno un identificatore, ma in generale può averne più di uno.

Una identificazione esterna può coinvolgere un'entità che è a sua volta identificata esternamente, purchè non si

generino cicli.

Generalizzazione

La generalizzazione è un costrutto che mette in relazione una o più entità E1, E2,…En in un'unica entità E. le entità

E1,R2, ecc. sono dei "casi particolari" dell'entità E.

Più in particolare E è una generalizzazione di E1, E2, En; E1, E2, … En sono specializzazioni (sottotipi, sottoclassi) di E.

Se E (genitore) è una generalizzazione di E1, … , En Ogni occorrenza di E1, … , En sarà anche occorrenza di E, ed ogni

Basi Di Dati Pagina 16

Se E (genitore) è una generalizzazione di E1, … , En Ogni occorrenza di E1, … , En sarà anche occorrenza di E, ed ogni

proprietà di E è significativa per E1, … , En.

I seguenti sono esempi grafici di generalizzazioni:

Vi sono due tipi di generalizzazioni:

• Generalizzazione Totale (a destra) se ogni occorrenza dell'entità genitore è occorrenza di almeno una delle entità

figlie, altrimenti è parziale.

• Generalizzazione Parziale (a sinistra) se ogni occorrenza dell'entità genitore è occorrenza di al più una delle entità

figlie, altrimenti è sovrapposta.

Una generalizzazione può anche essere esclusiva se ogni occorrenza dell'entità genitore è al più un'occorrenza di una

delle entità figlie, altrimenti è sovrapposta (ossia, se un'occorrenza dell'entità genitore può essere due o più occorrenze

di entità figlie, allora è sovrapposta, sennò è esclusiva)

NB: Esistono generalizzazioni a più livelli. Se una generalizzazione ha solo un'entità figlia si parla di sottoinsieme.

Documentazione associata agli schemi concettuali

Lo schema E-R deve essere corredato di descrizioni dei concetti rappresentati e vincoli non esprimibili in E-R.

Queste descrizioni comprendono il dizionario dei dati, che è composto dalla descrizione di entità e relationship. Inoltre

se vi è un vincolo non rappresentabile nello schema E-R, semplicemente si scrivono.

Dato il seguente schema E-R, ecco un esempio di dizionario dei dati:

E qui sotto abbiamo un a descrizione dei vincoli non esprimibili e delle regole di derivazione (regole per ottimizzare il

database): Basi Di Dati Pagina 17

Basi Di Dati Pagina 18

Progettazione Concettuale

giovedì 7 aprile 2016 09:31

Per raccolta dei requisiti s'intende la completa individuazione dei problemi che l'applicazione da realizzare deve

risolvere. I requisiti vengono inizialmente raccolti in specifiche espresse in linguaggio naturale e proprio per questo

motivo sono ambigue e disorganizzate. l'analii dei requisiti consiste nel chiarimento e nell'organizzazione delle specifiche

dei requisiti.

Molto spesso un testo o un colloquio con il cliente è ambiguo e impreciso. Per ottenere una specifica dei requisiti p