Newsgroup: it.comp.software.database
Titolo: Attrbuti opzionali

Salve a tutti. Sto finendo la progettazione del mio primo database e mi
stanno venendo alcuni dubbi. Uno di questi è dovuto al fatto che ho
alcuni attributi che sarebbero di fatto opzionali. Ossia, io ho scritto
per bene lo schema ER, ed ho inserito nelle entità questi attributi,
cui però non ho dato alcuna indicazione sulla cardinalità, in pratica
sono (1,1) sottointeso. Ora però mi rendo conto che molti di essi
potrebbero anche non essere inseriti, cioè, diciamo che non è che un
loro non inserimento possa causare problemi, quindi forse mettere not
null nello schema fisico non sarebbe corretto. Che dite? Se io volessi
che un attributo possa anche non essere inserito, eviterei di
impostarlo come not null nello schema fisico, ma secondo voi dovrei
anche andare a cambiare schema ER, ristrutturazione e schema logico?
Cioè, andare nello schema ER e specificare cardinalità (0,1), poi
ristrutturare correttamente ecc... Oppure è accettabile anche lasciare
così, tanto dopotutto l'attributo c'è sempre, solo che può assumere
valori nulli. Cosa fate voi di solito?
Grazie mille per qualsiasi consiglio.
Luca

 valori nulli. Cosa fate voi di solito?
Dire "valore" null è errato. Se esiste un attributo, esiste il suo
valore.
Senza sapere le specifiche concettuali, nulla si può dire sulla
correttezza di uno schema di database; altrimenti si apre la solita
discussione, teoria relazionale vs resto del mondo.

 discussione, teoria relazionale vs resto del mondo.
Dato che sto scrivendo il database come progetto per un corso direi che
tutto deve essere consistente con il modello concettuale che ho
scritto.
Faccio un esempio molto semplice, senza entrare tanto nei dettagli tanto
il problema è abbastanza semplice. Ho una entità persona nel modello
ER, e questa ha come attributi nome, cognome, indirizzo. Ammettiamo che
io voglia assolutamente costringere un inserimento del nome e del
cognome diverso da null, ma che non mi interessi che necessariamente
sia conosciuto l'indirizzo.
Il mio problema è che in realtà nel modello ER ho messo come
molteplicità di quell'attributo sempre (1,1). Avrei forse dovuto
mettere (0,1) come molteplicità?
La domanda mi sorge perchè tutto sommato mi parrebbe molto più semplice
lasciare una (1,1) e permettere nello schema fisico valori null, a
significare che il campo in questione non è conosciuto ad esempio, o
che comunque non è disponibile.
L'altra constatazione che mi sorge è questa, che proviene da quanto ho
studiato durante il corso. Se io mettessi (0,1) come molteplicità,
avrei una decisione da prendere durante la traduzione in schema
relazionale. Se metto una relazione esterna, con una chiave referente
alla chiave primaria di persona, diciamo il codice fiscale, avrei
qualcosa così:
persona(codice fiscale (CP), nome, cognome)
indirizzo(codice fiscale (CE e CP), indirizzo)
quindi se avessi idirizzi per ogni persona avrei sempre due campi
memorizzati su disco (quelli della relazione indirizzo).
Se invece decidessi di usare un solo campo nei record di persona:
persona(codice fiscale (CP), nome, cognome, indirzzo)
avrei che avendo indirizzo memorizzati per ogni persona, solo un campo
sarebbe memorizzato per ogni persona, con minore occupazione di spazio.
Questa soluzione coincide con la possibilità di avere una molteplicità
(1,1) nello schema ER.
E' corretto questo che dico? Cioè, ho dei pro e dei contro in entrambi i
casi. E' solo una questione di scelta, giusto? Ma posso comunque avere
molteplicità (1,1) ma permettere valori null per il campo?
Grazie mille.
Luca

 E' solo una questione di scelta, giusto?
Humm...
La vera scelta la potrei avere solo se il motore di database mi
permettesse di decidere come voglio organizzare i dati su disco in
maniera completamente disgiunta dalla rappresentazione logica.

 l'implementazione fisica.
Beh, ovviamente io non sto cercando di realizzare sul DBMS la
realizzazione concettuale, prima sono passato per la ristrutturazione e
poi ho progettato lo schema logico. Da li sono passato a schema fisico
sul DBMS. Così mi è stato insegnato.

Si, perfetto. questo era proprio quello su cui stavo riflettendo. Il
fatto è che in pratica durante il corso mi sono state spiegate delle
traduzioni "standard", solo che per ciascun caso in pratica solo una
era proposta in modo completo. In realtà mi sono reso conto che ci sono
altre possibilità, come mi hai mostrato ora. Sembra proprio che avessi
capito.
Grazie mille, così posso anche motivare bene sul progetto.
Luca