[SQL-forme normali] campo letterale come chiave esterna. viola qualche forma normale?

[ndakota]

ciao a tutti ho un database di un piccolo forum semplicissimo fatto da me per la maturità.

utenti(username, password, cognome, nome, data_iscrizione, tipo_utente, cancellato)
post(id, messaggio, autore, topic)
topic(id, titolo, sezione, autore)
sezioni(id, nome, autore)

in corsivo le chiavi esterne. visto che ho come chiave primaria di utenti una stringa con lo username e me lo ritrovo come chiave esterna nelle altre tabelle, vorrei sapere se questo viola qualche forma normale. o se in generale questo db non vi sembra normalizzato.

grazie

[-MiStO-]

vado a memoria:direi di no...
io ricordo, per le forme normali, vincoli su:
campi multivalore
dipendenza parziale dalla chiave
campi con dipendenza "indiretta" dalla chiave

[ndakota]

ti ringrazio, vediamo se qualcuno conferma

[MarcoGG]

Originariamente inviato da ndakota

utenti(username, password, cognome, nome, data_iscrizione, tipo_utente, cancellato)
post(id, messaggio, autore, topic)
topic(id, titolo, sezione, autore)
sezioni(id, nome, autore)

1. tipo_utente non sarebbe meglio fosse scorporato ulteriormente, con una tabella "tipi_utente" ? ( direttore, moderatore, vip, utente_senior, ecc... ).

2. autore in "sezioni" non è un tantino ridondante ? Poi, dipende, se solo il direttore o anche altri utenti possano o meno creare sezioni...

[ndakota]

Originariamente inviato da MarcoGG

1. tipo_utente non sarebbe meglio fosse scorporato ulteriormente, con una tabella "tipi_utente" ? ( direttore, moderatore, vip, utente_senior, ecc... ).

non so, sarebbe una tabella con due campi: tipo utente e username, mi sembra uno spreco.

2. autore in "sezioni" non è un tantino ridondante ? Poi, dipende, se solo il direttore o anche altri utenti possano o meno creare sezioni...

questo si è vero, se ne può fare sicuramente a meno, è solo un dettaglio.

grazie

[MarcoGG]

Non penso sia da considerare uno spreco, anzi.
Io intendevo questo :

utenti > username(PK), password, cognome, nome, data_iscrizione, tipo_utente (FK), cancellato)

tipi_utente > tipo_utente (PK), descrizione, ..., ...

La relazione è : 1 tipo_utente --> molti utenti.

Immagina di dover gestire, ad esempio, il numero di post necessari per passare dallo status di "junior member" a quello di "member" ecc...
Ecco un'informazione da mettere nella tabella "tipi_utente", e NON direttamente nella tabella "utenti". Tutto ciò va proprio nella direzione della normalizzazione, non credi ?

[ndakota]

è vero hai ragione.. però nel mio caso posso dire che è normalizzato? spero di si perchè ormai il forum l'ho fatto tutto così, mi serve dire che è normalizzato per parlare della normalizzazione altrimenti sarebbe un argomento da non tirare in mezzo

[MarcoGG]

Originariamente inviato da ndakota

è vero hai ragione.. però nel mio caso posso dire che è normalizzato? spero di si perchè ormai il forum l'ho fatto tutto così, mi serve dire che è normalizzato per parlare della normalizzazione altrimenti sarebbe un argomento da non tirare in mezzo

E' una questione di interpretazione : così com'è sì, ma quella tabella utenti lascia pensare che in teoria posso inserire un qualsiasi "tipo_utente", anche inventato di sana pianta, esattamente come posso inserire nome, cognome, password ecc. inventati.
A livello di database ad es. non c'è controllo su nome e cognome. Potrei inserire il classico "Ayeye Brazorf", senza sollevare eccezioni.
Ma che io possa fare lo stesso con tipo_utente mi pare un punto debole del DB abbastanza grave. Mettiamola così : se fossi un "esaminatore" non te la passerei liscia.

[ndakota]

Originariamente inviato da MarcoGG

E' una questione di interpretazione : così com'è sì, ma quella tabella utenti lascia pensare che in teoria posso inserire un qualsiasi "tipo_utente", anche inventato di sana pianta, esattamente come posso inserire nome, cognome, password ecc. inventati.
A livello di database ad es. non c'è controllo su nome e cognome. Potrei inserire il classico "Ayeye Brazorf", senza sollevare eccezioni.
Ma che io possa fare lo stesso con tipo_utente mi pare un punto debole del DB abbastanza grave. Mettiamola così : se fossi un "esaminatore" non te la passerei liscia.

vabbè ma scusa allora lo stesso si può dire per la data e ora di registrazione.. ma in realtà uno non può mica metterci quelle che vuole perchè nella query userò NOW() così come nella creazione di un nuovo utente inserirò sempre utente_normale come tipo utente.. poi potrà essere cambiato chessò in moderatore o amministratore da un amministratore sbaglio?

[MarcoGG]

Originariamente inviato da ndakota

vabbè ma scusa allora lo stesso si può dire per la data e ora di registrazione.. ma in realtà uno non può mica metterci quelle che vuole perchè nella query userò NOW() così come nella creazione di un nuovo utente inserirò sempre utente_normale come tipo utente.. poi potrà essere cambiato chessò in moderatore o amministratore da un amministratore sbaglio?

Non ho proprio detto che tu abbia "sbagliato", sicuramente a mio modo di vedere è una leggerezza che qualcuno potrebbe far notare.
E' come se tu avessi, che so, un DB di una videoteca, senza avere una tabella dei "generi" ( azione, drammatico, commedia, ecc... ), un DB di un magazzino senza una tabella "tipi_prodotto", e così via.
tipo_utente sottende un elenco preesistente da cui scegliere un elemento, mentre nome, cognome, password, data, sono dati puri.
L'elenco dei tipi_utente possbili, tu dici, lo gestisco dall'applicazione. E se poi vorrò eliminare/aggiungere un tipo_utente ? O peggio ancora, se vorrò modificare un tipo_utente ? Mettiamo che io, amministratore oggi decida che l'utente "senior" debba chiamarsi "superuser". Che faccio ? Vado in giro per il DB e modifico tutti gli utenti che erano senior...
Una tabella elenco, tipi_utente, generi, tipi_prodotto, ovunque ci siano elenchi definiti da gestire è la scelta migliore, tutto qui. Era un consiglio, più che altro, ma se hai già scritto anche il Forum... Ma non insegnano che prima di scrivere codice bisognerebbe prima avere definito/normalizzato al 100% il DB ?

[ndakota]

lo so, ci ho pensato dopo ad aggiungere la normalizzazione

comunque il problema l'ho "risolto" elegantemente.. semplicemente nella tesina scritta ho tolto l'attributo tipo_utente.. questo perché non c'è nient'altro che ne giustifichi la presenza, se ne può fare anche a meno. Ovviamente nel forum rimane, se qualcuno mi chiede qualcosa dico che sono aggiunte fatte dopo per renderlo più usabile ma non credo proprio che qualcuno si metta a guardare il codice

grazie comunque

[gugoXX]

Originariamente inviato da ndakota

lo so, ci ho pensato dopo ad aggiungere la normalizzazione

comunque il problema l'ho "risolto" elegantemente.. semplicemente nella tesina scritta ho tolto l'attributo tipo_utente.. questo perché non c'è nient'altro che ne giustifichi la presenza, se ne può fare anche a meno. Ovviamente nel forum rimane, se qualcuno mi chiede qualcosa dico che sono aggiunte fatte dopo per renderlo più usabile ma non credo proprio che qualcuno si metta a guardare il codice

grazie comunque

Un po' come un mio collega-amico alla tesina di calcolatori elettronici.
Il professore aveva imposto "Mi raccomando, usate interrupt ed IRQ senno' non ve la passo"

E il suo codice iniziava con tutta una serie di EQU costanti per pilotare Interrupt, IRQ, DMA
e poi non li ha usati, perche' non aveva capito come usarli.

E' passato lo stesso, secondo te hanno letto il codice?

[ndakota]

provo a indovinare: no

comunque ho capito la lezione ma non ho alternativa, è tardi.. e per inciso, il motivo perché non ho voglia di mettere a posto le cose è che la mia tesina mi fa schifo, avrei voluto fare tutt'altro.. ormai è andata è così

[=KaTaKliSm4=]

Utenti potresti scorporarlo ulteriormente....

in :

Login(NomeUtente,Password,IdUtente)

Con vincolo non duplicabile su NomeUtente

Utenti(IDUtente,Nome,Cognome,Data,ecc,ecc...)

Cosi avresti un'anagrafica con le relative informazioni di login

[ndakota]

Originariamente inviato da =KaTaKliSm4=

Utenti potresti scorporarlo ulteriormente....

in :

Login(NomeUtente,Password,IdUtente)

Con vincolo non duplicabile su NomeUtente

Utenti(IDUtente,Nome,Cognome,Data,ecc,ecc...)

Cosi avresti un'anagrafica con le relative informazioni di login

ti ringrazio

[=KaTaKliSm4=]

Originariamente inviato da ndakota

ti ringrazio

Non è troppo tardi non rpeoccuparti hai tempo ancora.....non tantissimo ma ne hai!

Comunque se vuoi parlare della normalizzazione leva quel Tipo_Utente....

Se lo lasci cosi ci sarebbero delle anomalie di inserimento in quanto....ti faccio un'esempio, con l'attuale modello E/R se io volessi aggiungere il tipo utente "Appena Iscritto" come dovrei fare?Aggiungere una nuova anagrafica ed un nuovo login? Non va bene

P.S 2) Togli quel "cancellato" nella pratica reale è poco corretto!L'utente che elimina la registrazione non fa piu parte del database, ne consegue che, dovresti creare o una tabella "Storico Anagrafica/Login" o meglio ancora "spostare" i record cancellati su un'altro database(magari annuale) che fa da storico! Io qualche idea te l'ho buttata giu....tocca a te ora

E non demordere....in 4 giorni ho scritto tutto il sorgente in Vb.net e creato il database per la gestione di una palestra....l'ho fatto io...puoi farlo tu

Buona maturità!Anche a me ahhahahahahah

[ndakota]

Originariamente inviato da =KaTaKliSm4=

Non è troppo tardi non rpeoccuparti hai tempo ancora.....non tantissimo ma ne hai!

Comunque se vuoi parlare della normalizzazione leva quel Tipo_Utente....

Se lo lasci cosi ci sarebbero delle anomalie di inserimento in quanto....ti faccio un'esempio, con l'attuale modello E/R se io volessi aggiungere il tipo utente "Appena Iscritto" come dovrei fare?Aggiungere una nuova anagrafica ed un nuovo login? Non va bene

P.S 2) Togli quel "cancellato" nella pratica reale è poco corretto!L'utente che elimina la registrazione non fa piu parte del database, ne consegue che, dovresti creare o una tabella "Storico Anagrafica/Login" o meglio ancora "spostare" i record cancellati su un'altro database(magari annuale) che fa da storico! Io qualche idea te l'ho buttata giu....tocca a te ora

E non demordere....in 4 giorni ho scritto tutto il sorgente in Vb.net e creato il database per la gestione di una palestra....l'ho fatto io...puoi farlo tu

Buona maturità!Anche a me ahhahahahahah

buona maturità a entrambi allora e grazie