[DB] Normalizzazione

[anonimizzato]

Ciao a tutti,

avrei una domanda da fare circa il processo di normalizzazione.

Ho un DB che presenta tra le altre cose una tabella apposita per i PROGRAMMI dei CORSI di un'associazione.

Questa tabella è composta da:

-PROGRAMMI-
ID programma
ID Livello (chiave esterna presa dalla tabella dei Livelli dei vari corsi)
Oraro di inizio
Orario di fine

es:

"Corso di Inglese"

"Programma1":
-Livello Base
-dalle 17.00 alle 18.00
-martedì e giovedì.

Quello che vorrei sapere è relativo ai GIORNI ovvero, un programma si può tenere in 1 o più giorni alla settimana per tutto l'anno così come, ovviamente, i vari giorni saranno associati a diversi programmi.

Quella che si viene a creare è quindi una relazione MOLTI a MOLTI M:N (tra programmi e giorni) ma la domanda è:

Come si gestiscono le relazioni M:N per quegli intervalli di valori FINITI e comuni come appunto i giorni della settimana o i mesi dell'anno ecc.


io ho creato 3 tabelle
PROGRAMMI (vedi sopra)
PROGRAMMI_GIORNI (ID programma, ID giorno)
GIORNI (ID giorno, nome_del_giorno).

ma avrei forse potuto anche fare:
PROGRAMMI (vedi sopra)
PROGRAMMI_GIORNI (ID programma, nome_del_giorno)

avrei una ridondanza nei nomi dei giorni es:
1 - lunedì
1 - giovedì
2 - martedì
3 - lunedì
3 - martedì
...

ma una tabella in meno!

oppure:
PROGRAMMI (ID programma,ora inizio,ora fine,livelloID,lunedì,martedì,mercoledì ....)

con 7 campi da "spuntare" a seconda dei giorni interessati dal programma.


In definitiva:

In un caso "normale" laddove la seconda tabella può aumentare i propri valori il modo più corretto è quello di avere i valori in una tabella a parte e risolvere M:N con una tabella di collegamento ma in questo caso che sò per certo che i valori non cambiano come si procede nel modo più corretto con l'opera di normalizzazione?

GIORNI può essere definito a tutti gli effetti un "SOGGETTO" della base dati e quindi meritare una tabella a se?!

Spero di essere stato sufficientemente chiaro e vi ringrazio anticipatamente per le risposte.

[giannola]

in linea concettuale si, nel senso che i giorni sono entità, però poichè non variano(ovvero sono al massimo 7), nella normalizzazione fai prima a fare due campi testuali uno relativo agli orari ed uno relativo ai giorni. ;)

[cionci]

PROGRAMMI (vedi sopra)
PROGRAMMI_GIORNI (ID programma, nome_del_giorno)
Va bene così, a meno che tu non voglia determinare un vincolo sull'inserimento dei dati nella relazione...

[giannola]

Va bene così, a meno che tu non voglia determinare un vincolo sull'inserimento dei dati nella relazione...

se segui il consiglio di cionci non dimenticare di aggiungere nella tabella PROGRAMMI_GIORNI anche ora_inizio e ora_fine ;)

[cionci]

se segui il consiglio di cionci non dimenticare di aggiungere nella tabella PROGRAMMI_GIORNI anche ora_inizio e ora_fine ;)
Se l'orario è costante va bene dove l'ha messo, anzi è la selta migliore...
La tabella PROGRAMMI_GIORNI diventa tuttachiave...

[anonimizzato]

Se l'orario è costante va bene dove l'ha messo, anzi è la selta migliore...
La tabella PROGRAMMI_GIORNI diventa tuttachiave...

In che senso se l'orario è costante?

Grazie a tutti per le risposte.

Alla luce di tutto ciò mi pare che chiaro allora che alla fine quando si lavora con una base dati i cui i dati incrociano spesso con elementi temporali come appunto GIORNI, MESI, ANNI (in range fisso) essi vanno trattati come Entità a parte e quindi scomposti in singole tabelle giusto?

Scusate ma sono niubbo ed autodidatta su ste cose.

;)

[anonimizzato]

Va bene così, a meno che tu non voglia determinare un vincolo sull'inserimento dei dati nella relazione...

Uhm ... nel senso di accettare solo i valori che IO ho definito nella tabella GIORNI e non tramite l'input dell'utente?

Teoricamente questa cosa sarebbe bypassabile dall'interfaccia utente ad esempio una select con valori predefiniti o meglio ancora vista la scelta multipla dei checkbox.

[cionci]

Teoricamente questa cosa sarebbe bypassabile dall'interfaccia utente ad esempio una select con valori predefiniti o meglio ancora vista la scelta multipla dei checkbox.
Sì ;)

[cionci]

In che senso se l'orario è costante?

Costante rispetto ai giorni... Cioè se per tutti i giorni in cui c'è un determinato corso l'orario è sempre lo stesso...

[anonimizzato]

Costante rispetto ai giorni... Cioè se per tutti i giorni in cui c'è un determinato corso l'orario è sempre lo stesso...

Si è così l'orario è fisso per il CORSO o meglio il singolo PROGRAMMA perchè per corso intedo la categoria dei vari livelli disponibili.

Cmq ok capito.

P.S.
Avreste qualche buona risorsa sia sul web che digitale da indicarmi circa il processo di progettazione e normalizzazione di un DB?

Ho già letto "Progettare Database" di M.Hernandez (davvero ottimo) ma vorrei andare oltre. Nulla di troppo complicato però non ho conoscenze ed esigenze di tipo universitario.

Bye.

[cionci]

Quel libro che hai studiato tratta le forme normali ?

[anonimizzato]

Quel libro che hai studiato tratta le forme normali ?

Diciamo di si, anche se non in modo "accademico" o per meglio dire scentifico:

es:
"Una base dati si può definire in 1NF se ... ecc."

Nel libro, indicato per chi non abbiamo conoscienze specifiche, viene trattato il processo di progettazione con un metodo "innovativo" di linee guide basate sul "prototipo di tabella ottimale".

Da ciò ne derivano comunque le indicazioni sulla risoluzione dei campi multivalore, delle relazioni M:N come si tratterebbero in ogni altro caso.

Mi piacerebbe andare, se possibile, più sul tecnico senza addentrarmi in dettagli matematici troppo ostici come algoritmi ecc.

Diciamo che per il momento conosco l'ABC, ora vorrei impare "DEF".

Grazie ancora.