Newsgroup: it.comp.software.database
Titolo: Forme normali

Ciao a tutti,
non riesco bene a capire le differenze fra la seconda formale, la terza 
forma normale e la forma normale di Boyce e Codd.
Se non ho capito male queste sono le definizioni:
2a forma normale: Una tabella è in seconda forma normale quando ogni 
attributo non primo (cioè non appartenente alla chiave primaria) dipende 
funzionalmente, e in maniera minima, da una chiave.
3a forma normale: Una tabella è in terza forma normale quando per ogni 
dipendenza funzionale non banale X -> Y, si verificano una di queste 
proprietà:
X è una chiave;
Y è un attributo primo.
Forma di Boyce e Codd: Una tabella è in forma normale di Boyce e Codd 
quando per ogni dipendenza funzionale non banale X -> Y, X è una chiave.
Non riesco a capire la differenza ad esempio fra 2a forma normale e 
forma di Boyce e Codd. Fra Boyce e Codd e 3a forma normale capisco la 
differenza, cioè che per la 3a forma normale si accetta il fatto che un 
attributo della chiave (primaria?) puo' dipendere da altri attributi 
della chiave.
Poi non ho capito se nelle definizioni si parla di chiavi o di chiavi 
primarie.
Grazie in anticipo per l'aiuto.


La seconda forma normale, rispetto alla terza, puo' avere dipendenze 
transitive (la terza le esclude).
La forma di Boyce-Codd, invece, puo' non preservare le dipendenze 
funzionali (cosa invece garantita dalla terza forma normale che e' piu' 
"rilassata").
Nella terza forma normale si ammettono dipendenze funzionali (ma con la 
convenzione che usi sopra allora X non e' chiave e Y e' attributo primo).
-- 
Fabrizio Magni
fabrizi...@mycontinent.com
replace mycontinent with europe

 Grazie in anticipo per l'aiuto.
E ricorda:
"The key, the whole key, and nothing but the key; so help me Codd"
:-)

 
Non prenderla come voglia di far scoppiare una polemica ma la 
definizione della 3NF (e della BCNF) e' solo una e anche abbastanza 
rigorosa.
Nella definizione non si fa riferimento alla chiave primaria.
Si parla solo di dipendenze funzionali e di super chiave.
Ciao


 transitive (la terza le esclude).
Mi dispiace gettare un po' di scompiglio, specie per chi ha aperto il
thread, ma...
Questo sembra essere un comune fraintendimento della 3NF, dovuto
probabilmente al fatto che negli esempi non si considerano
dipendenze multicolonna.
La 3NF ha come conseguenza l'eliminazione delle dipendenze transitive
degli attributi non primi _tra_di_loro, ma si possono ancora avere
dipendenze transitive nei confronti di parti di chiave (attributi primi,
quindi tecnicamente in 3nf).
Celko nel suo libro (Data & Databases, p.299 e 311) porta tre esempi di
dipendenze transitive multi attributo benché tecnicamente in 3NF;
alcune erano veramente difficili da vedere.
Da notare, che molte definizioni di 3nf contengono già una preclusione in
tal senso, in quanto richiedono che la 3nf non abbia dipendenze
transitive, mentre la formulazione "originale" (come data anche dall'op)
non contiene una dichiarazione in tal senso.
Potrebbe essere anche questo un motivo che ha richiesto la BCNF,
la quale garantisce l'assenza di dipendenze transitive (e usa la parola
"determinante" anziché "chiave", in tal modo non facendosi mettere nel
sacco dalle combinazioni di attributi non key).

 Si parla solo di dipendenze funzionali e di super chiave.
Io sono più che d'accordo che si 'dovrebbe' formulare la definizione
in modo che riguardi qualunque chiave e non solo la pk; ma comunque
volevo mettere in guardia l'op che alcune formulazioni delle forme
normali sono fatte avendo in mente la pk; la mia deve essere considerata
come una nota _interpretativa_ e _storica_ di ciò che l'op si troverà a
leggere; infatti le prime versioni del modello relazionale parlavano
di primary key, è solo recentemente che si è dato atto che una pk è
solo una _preferenza_ del dba, e che quindi solo di "chiavi" in senso
generale bisognerebbe parlare.
E adesso cito solo due che mi sembrano significative:
"An introduction to Database Systems" C.Date, collaboratore e coautore
di chi ha inventato il modello relazionale, settima edizione p.356:
[Capitolo sulle forme normali]
"Throughout this section, we assume for simplicity that each relvar has
exactly one candidate key, thich we further assume is the primary key"
[...]
"Professional Sql Server 2000 Database Design", Louis Davidson p.162
"As I have mentioned before, a key can be _any_ candidate key, whether
the primary key or an alternate key. However, the main concern of the
Second Normal Form and the Third Normal Form is the primary key."
Saluti


L'unica vera definizione che mi risulta:
Uno schema relazionale R e' in 3NF se per ogni dipendenza funzionale X 
-> A tale che A non appartiene a X vale:
1) X e' una superchiave di R
2) A e' attributo primo.
Vedo in rete molte "traduzioni" o "interpretazioni" che non possono 
essere certo chiamate definizioni.
Puoi citare libri e definizioni?
Nota che la definizione di CBNF e' identica tranne per la condizione 2) 
che non e' presente.
Di chiavi primarie non si parla.
Se l'OP ha a disposizione un testo universitario (come il Ceri) credo 
trovera' la stessa definizione.
Visto che citi Date ecco cosa scrive:
"And now we come to an overriding point:  Namely, it's meaningless to 
say simply that some table T either is or is not in 3NF--rather, we can 
say only that T is or is not in 3NF with respect to a certain set of 
functional dependencies (once again, see the above mentioned book). 
Here's a definition (a precise definition!) of 3NF that makes this point 
clear.
Let T be a table and let S be the set of functional dependencies (FDs) 
that are satisfied by T; let X be any subset of the columns of T, and 
let C be any single column of T.  Then T is in 3NF with respect to S if 
and only if, for every FD X _ C in S, at least one of the following is 
true:
X contains C;
X is a superkey for T;
C is contained within a candidate key of T."
Anche qui nessun riferimento alla primary key.


 
Che se non mi sbaglio equivale a cio' che ho scritto nel post precedente:
"Nella terza forma normale si ammettono dipendenze funzionali (ma con la 
convenzione che usi sopra allora X non e' chiave e Y e' attributo primo)."
Lo leggi anche nel libro di Celko che hai citato:
"if X -> Y, X doesn't have to be a key if Y is part of a candidate key."
Ciao


 primo)."
??? Scusa ma in quanti modi si può interpretare quello che hai scritto:
"La seconda forma normale, rispetto alla terza, puo' avere dipendenze
transitive (la terza le esclude)."
Adesso mi dici che intendevi ammettere dipendenze transitive nella 3nf?
Bon meglio, problema risolto.

 Anche qui nessun riferimento alla primary key.
E infatti questa mi sembra la ri-citazione di Zaniolo (o perlomeno è
del tutto simile a quella che ne fa a fine capitolo), nella mia edizione
p.375.
Comunque, dato che hai il libro di Date (p.360):
-"Second normal form (definition assuming only one candidate key, which
we assume is the *primary key*), a Relvar is in 2nf if [...] dependent
on the *primary key*.
-(p.362) 3NF (definition assuming only one candidate key, which we
further assume is the *primary key*)"
Come vedi, Date stesso parla esplicitamente di pk.
Sul perché tanta enfasi alla pk:
(p.260) "...it is possible for a given relvar to have more than one
candidate key. In such a case, the relational model has historically
required [...] one of those keys be chosen as the primary key [...]
Now, choosing one candidate key as primary might be a good idea but [...]
the choice of which is essentialy arbitrary.
Ripeto quello che ho scritto:
"la mia deve essere considerata come una nota _interpretativa_ e
_storica_ di ciò che l'op si troverà a leggere; infatti le prime versioni
del modello relazionale parlavano di primary key".
Sperando di aver esaurito l'argomento, cordialmente saluto.

 
E' quanto ho scritto: "Nella terza forma normale si ammettono dipendenze 
funzionali".


 
Spero tu non la stia prendendo personalmente come gia' un'altra 
discussione che abbiamo avuto. Personalmente non ho nulla contro di te.
Uno scambio di idee e conoscenze e' il modo migliore per imparare e 
questo tipo di thread e' tra i piu' interessanti in quanto costringe a 
rivedere la teoria di base.
Nel caso.. alla prossima.


 la teoria di base.
Figurati, io non me la prendo assolutamente, al massimo mi infervoro
sulle mie passioni; anzi, uno dei motivi per cui scrivo con un alias
č che voglio cancellare ogni traccia di ego: a me interessa farmi
solo qualche chiacchierata sul mio argomento preferito, imparare
qualcosa di nuovo e soprattutto aiutare qualcuno.
Davvero mi auguro di non dare un'impressione negativa, dato che questo
getterebbe biasimo su di me e sugli argomenti che intendo portare avanti;
nel caso sia stato cosě, me ne rammarico profondamente.
In riferimento al thread passato, desidero esplicitare di aver fatto
solo considerazioni generali, e sicuramente nulla su di te, che ti sei
dimostrato preparatissimo e competente interlocutore.
Cordialmente saluto

 
Mi sarebbe dispiaciuto il contrario.
Come ti ho detto da discussioni del genere tendo ad imparare.
Sono persino arrivato a vedere un'utilita' nella distinzione 
fisico-logica per schemi E-R che ora uso quando ho scambi con gli 
sviluppatori (anche se ritengo la divisione troppo grezza per chi vede 
l'intero stack tecnologico come un DBA).
Spero di ritrovarti alla prossima discussione (non scontro).
Buona serata.
