1. panoramica
1.1. input
1.1.1. schema concettuale
1.1.2. carico della base di dati
1.1.3. modello logico scelto
1.1.3.1. relazionale
1.1.3.1.1. il più diffuso
1.1.3.1.2. slegato da implementazione fisica
1.1.3.1.3. value-based
1.1.3.2. reticolare
1.1.3.3. gerarchico
1.1.3.4. ...
1.2. fasi
1.2.1. ristrutturazione schema ER
1.2.1.1. motivi
1.2.1.1.1. costrutti non sopportati
1.2.1.1.2. ottimizzazioni
1.2.1.2. sotto-fasi
1.2.1.2.1. analisi carico del database
1.2.1.2.2. analisi ridondanze
1.2.1.2.3. rimozione generalizzazioni
1.2.1.2.4. rimozione attributi multi-valore
1.2.1.2.5. rimozione attributi composti
1.2.1.2.6. partitioning/merging di entità e relazioni
1.2.1.2.7. selezione primary key
1.2.2. traduzione in uno schema logico
1.3. output
1.3.1. schema logico
1.3.2. vincoli d'integrità
1.3.3. documentazione
2. schema e istanza
2.1. schema relazionale: R=(A1, A2, ...An) dove A1, A2, ... An sono gli attributi
2.1.1. "descrizione di una tabella (senza dati)"
2.2. istanza della relazione: valori attuali di una relazione
2.2.1. "una tabella con i suoi dati"
2.3. database schema = insieme di schemi relazionali
2.3.1. "tutte le descrizioni delle tabelle (senza dati)"
2.4. database instance = dati nel database in un certo istante
2.4.1. "tabelle con dati"
3. database relazionale
3.1. database è composto da tabelle con nome
3.2. tabella composta da righe e colonne
3.3. colonna = attributo (nome + tipo)
3.4. riga = una relazione tra valori
3.4.1. ! non confondere con relationship set
3.4.2. riga = tupla, individuo, entità
4. carico del database
4.1. stime partendo da functional requirements
4.2. volume di dati
4.2.1. numero di entità x entity set e relazioni x relationship set
4.2.2. >>> tabella dei volumi
4.3. storage requirements
4.3.1. quanti byte necessari?
4.4. tipo di operazioni e frequenza
4.4.1. interattive (risposta "immediata")
4.4.2. batch (tempi lunghi)
4.4.3. >>> tabella delle operazioni
4.5. complessità operazioni
4.5.1. numero entità coinvolte
4.5.2. >>> tabella degli accessi (1 x ogni operazione)
5. Vincoli d'integrità (segue)
5.1. sono regole per mantenere i dati consistenti
5.2. possibili vincoli
5.2.1. domain di un attributo: valori ammessi
5.2.2. unicità dei valori di un attributo
5.2.3. esistenza di valori
5.2.4. integrità referenziale fra dati di differenti tabelle
5.3. comportamento del DBMS se vincolo violato
6. ristrutturazione digramma ER
6.1. ridondanze: lasciare o eliminare?
6.1.1. attributi derivati
6.1.2. relazione derivate da altre
6.1.3. pro: accessi più veloci
6.1.4. contro: mantenere dati aggiornati
6.2. rimuovere attributi multi-valore
6.2.1. creazione entity set dedicato per ogni attributo multi-valore
6.3. rimuovere attributi composti
6.3.1. attributi che compongono l'attributo composto aggiunti direttamente a entity set
6.4. rimuovere generalizzazioni
6.4.1. collasso entità figlie nell'entità mare
6.4.1.1. aggiungere attributo "tipo"
6.4.1.2. valori NULL negli attributi non comuni a entità di partenza
6.4.2. collasso entità madre nelle entità figlie
6.4.2.1. solo se generalizzazione totale!
6.4.3. sostituzione con relazioni
6.5. ev. patitioning o merging di entità e relazioni
6.5.1. separazione o unioni di entity set o relazioni per migliorare efficienza
6.6. selezione primary key
7. traduzione nel modello logico conversione in tabelle
7.1. principio: per ogni entity set e ogni relationship set viene creata una tabella con un nome.
7.2. ogni tabella ha colonne con i nomi degli attributi
7.3. strong entity set E con n attributi
7.3.1. una tabella con nome E
7.3.2. n colonne, una per ogni attributo
7.3.3. ogni riga rappresenta una entità dell'entity set E
7.3.4. primary key dell entity set diventa primary key della tabella
7.4. weak entity set W con n attributi che dipende da strong entity set S. s1, ... sm formano la prinary key di S
7.4.1. una tabella con nome W
7.4.2. n+m colonne, una per ogni attributo di W e per ogni attributo parte della primary key di S
7.4.3. primary key di S più discriminator di W formano primary key della tabella
7.5. relationship set R fra entity set A e B a1, ..an formano primary key di A b1..bm formano primary key di B
7.5.1. una tabella con nome R
7.5.2. tabella necessaria se R ha cardinalità N:N
7.5.3. n+m colonne, una per ogni attributo parte della primary key di A e di B
7.5.4. se N:N unione delle primary key di A e B formano primary key della tabella
7.6. relationship set R fra entity set A e B cardinalità 1:1 o 1:N o N:1
7.6.1. non è necessaria una tabella
7.6.2. aggiundere attributi che formano primary key del lato "one" al lato "many"