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

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

ndakota

17-06-2009, 12:39

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-

17-06-2009, 12:50

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

17-06-2009, 12:53

ti ringrazio, vediamo se qualcuno conferma :)

MarcoGG

17-06-2009, 15:43

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

17-06-2009, 16:48

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

17-06-2009, 18:38

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

17-06-2009, 19:24

MarcoGG

17-06-2009, 21:12

è 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 :p

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. :D
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. :D

ndakota

18-06-2009, 01:03

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. :D
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. :D

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 :p sbaglio?

MarcoGG

18-06-2009, 13:42

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 :p 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 ? :D

ndakota

18-06-2009, 13:51

gugoXX

18-06-2009, 14:29

lo so, ci ho pensato dopo ad aggiungere la normalizzazione :doh:

comunque il problema l'ho "risolto" elegantemente.. :D 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 :p

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

18-06-2009, 15:31

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ì :muro: :muro:

=KaTaKliSm4=

20-06-2009, 18:13

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

20-06-2009, 18:19

=KaTaKliSm4=

20-06-2009, 20:49

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 :D

ndakota

20-06-2009, 21:21

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 :D

buona maturità a entrambi allora e grazie :D